#ubuntu-devel 2005-01-17
<amu> mdz: working with the liveCD causes brain decrease, i have probably forgotten to say it :)
<seb128> mdz: new ncb available, should fix the device busy issue .. if you can confirm it :)
<sjoerd> seb128: did you also change the g_file_test from _EXIST to _EXECUTABLE (or something like that)
<seb128> sjoerd: no, why ?
<sjoerd> seb128: so it uses umount instead of pumount when the user isn't in group plugdev
<seb128> why ?
<seb128> is returns the first known entry
<seb128> which is pumount
<seb128> so it uses pumount
<sjoerd> seb128: yeah, but the user might not be able to run that
<seb128> and ?
<sjoerd> seb128: while if you check if it's executable it returns the first entry the user can actually run
<seb128> if an user not in plugdev runs pumount, what happens ?
<sjoerd> he can't run pumount, drive isn't unmounted, same problem stays
<seb128> sjoerd: you could have mentionned it before dude, I've just commited to the SVN, runned a pbuilder, build & uploaded 2 packages
<sjoerd> if it would fallback on umount and there is an fstab entry (which is normal in debian) stuff still works
<sjoerd> seb128: sorry, i just remembered it 5 minutes ago
<seb128> I thought than pumount was falling back to umount
<sjoerd> yeah, but if pumount isn't executable for the user then that doesn't help
<mdz> seb128: pumount does fall back to umount
<sjoerd> mdz: it uses umount when there is an fstab entry afaik 
<mdz> hmm, perhaps
<seb128> sjoerd: ok, feel free to update the Debian side so :p
<seb128> I've commited the changes on the SVN, you just have to update the patch,commit, build and upload :)
<sjoerd> seb128: i don't have commit rights in pkg-gnome remember :)
<seb128> sjoerd: wait a min
<seb128> that's easy to fix
<seb128> :p
<seb128> bah, I'll do that tomorrow, I'm too tired now to restart the pbuilder, etc
<sjoerd> haha
<seb128> next time try to think *before* :p
<sjoerd> seb128: at least i thought about it before somebody filed a bug :)
<seb128> ah ah
<seb128> I'm not even the Debian maintainer for ncb, I should kick ross :p
<sjoerd> oh it's not a team package ?
<seb128> yes, it is
<seb128> but team is an uploader, not the maintainer :)
<sjoerd> ah
<seb128> sjoerd: so we have the same bug in gnome-vfs ?
<seb128> libgnomevfs/gnome-vfs-volume-ops.c:             if (g_file_test (known_locations [i] , G_FILE_TEST_EXISTS))
<sjoerd> seb128: the patch i put in the debian bts checked it for being executable
<seb128> sjoerd: which one ?
* sjoerd checks
<sjoerd> the one that also adds pumount to the list
<sjoerd> -               if (g_file_test (known_locations [i] , G_FILE_TEST_EXISTS))
<sjoerd> +               if (g_file_test (known_locations [i] , G_FILE_TEST_IS_EXECUTABLE)
<seb128> right
<seb128> all right, I'll fix it now so that's done
<seb128> have you send this upstream ?
<sjoerd> nope
<seb128> bad guy
<sjoerd> i'm leaving that to the debian maintainer to decide ?
<sjoerd> it's not really usefull upstream though, unless they also add pumount
<seb128> right
<seb128> I'll push all that upstream
<seb128> and I'm not the gnome-vfs maintainer neither :p
<seb128> s/neither/either/
<sjoerd> hehe
<sjoerd> seb128: the pumount bit too ?
<seb128> yep
<seb128> doesn't hurt
<sjoerd> right
<sjoerd> but it's quite debian/ubuntu specific currently so
<seb128> BrowserDescription possible_browsers[]  = {
<seb128>         { N_("Debian Sensible Browser"),        "sensible-browser",     "sensible-browser %s", FALSE, FALSE },
<seb128> 
<seb128> that's in the control-center upstream code too :p
<sjoerd> hehe
<sjoerd> go seb :)
<sjoerd> most of the time i just put a bug in the bts and leave it up to the maintainer to sent it upstream if he thinks it's okay
<sjoerd> (and i really don't like putting patches in bugzilla)
<seb128> bah :p
<Nafallo> hi there everyone! I have a suggestion for a keybinding change, but I don't know what package to touch.
<Nafallo> volume up and down does atm change master volume, for laptops (and maybe stationed puters too) it would be great to let it control headphone volume aswell.
<lamont> moof
<jamesh> Nafallo: if you have your mixer settings set up correctly, you should only need to adjust the master volume.
<jamesh> Nafallo: ie. you adjust the input volumes so that each input is read at approximately the same level, and do similar for the output volumes
<jamesh> Nafallo: then you just need to adjust the master volume, and mute/unmute individual channels.
<Nafallo> jamesh: in what way will that make master master even when headphones is plugged in?
<jamesh> Nafallo: everything gets mixed by the master volume.
<jamesh> that's why it is called the master volume.
<Nafallo> jamesh: I just muted master. music still playing in my headphones
<Nafallo> jamesh: i.e. if headphones is plugged in; s/master/headphones/g
<jamesh> Nafallo: that sounds quite surprising
<Nafallo> jamesh: it was ;-)
<jamesh> Nafallo: the idea is that all sound is adjusted by the "master" volume settings, then adjusted by the volume settings for the particular output channel.
<Nafallo> jamesh: I know. but when headphones is plugged master becomes irrelevant. could this be an alsa-driver bug?
<jamesh> Nafallo: quite possibly.
<Nafallo> snd_via82xx, I should try to google :-P
<Nafallo> I sign a bug @ the alsa-driver project.
<Nafallo> s/driver\ //
* lamont goes back to merge-o-mnia
<lamont> mania
<lamont> sigh
<zul> hey
<lamont> keybuk: diff missing for howl... (4548).  Thoughts?
<lamont> doh. nm
<zul> lamont: is mono-mcs still failing?
<zul> lamont: nm...did some digging around
<lamont> zul: there's a buildlog for the failure
<lamont> zul: so once they upload the fixed mcs package, all should be bootstrappable?
<lamont> firecall
<jdub> mdz: OOo2 pre-release doesn't get a great review in lwn
<mdz> jdub: if it doesn't come together, it doesn't, but if it does, ROCK
* lamont returns
<mdz> whoa, 2.6.10 has online ext3 resize
<mdz> didn't know that
<mdz> rad
<mdz> one less reason to use ricerfs
<mdz> smurfix: someone has been testing on Ubuntu and uploading to Debian, hmm? :-)
<mdz> (#288873)
<sivang> mdz: couldn't you use lvm and resieze an XFS or reiser part?
<mdz> sivang: <mdz> one less reason to use ricerfs
<sivang> mdz: I saw that,  I was wondering if the same effect couldn't be achived via using reiserfs under lvm, as if the new rad feature was not so rad. :-) or is reicerfs != reiserfs ?
<aj> hrm, is elmo around atm?
<lamont> aj: he's been very silent for the last hour or 2
<lamont> which is to say, I don't think so.
<aj> well, it's 3am or something in the UK, so that's fair enough
<lamont> yeah
<aj> but he's not on vacation or irc free or anything?
<lamont> should be around if he's awake.
<lamont> hasn't said he's on vacation
<mdz> sivang: ricerfs = reiserfs
<mdz> sivang: reiserfs is online resizable; ext3 wasn't (until now) without kernel patches
<mdz> lamont: you heard from him 2 hours ago? I haven't seen him all (my) day
<sivang> mdz: wooa, so if I partition my hd only using reiserfs I do really need an lvm...cool.
<sivang> mdz:*don't
<lamont> mdz: I was gone for quite a while before that.
<mdz> sivang: no, you've misunderstood
<lamont> haven't heard from him since ~9AM your time
<lamont> although ISTR he dropped something on me about 3AM my time
<mdz> sivang: if you read a good FAQ about LVM or EVMS, it will be clear
<sivang> mdz: ok, I will. tnx.
<lamont> I take that back.  17:54 yesterday
<lamont> anybody with locale!=*US* wanna test something for me?
<lamont> sivang: ??
* lamont decides to delay libpaper's upload until tomorrow
<lamont> getting to be fall-in-bed time here.
<lamont> busy day
<lamont> mdz: 42 unassigned merge bugs
<mdz> lamont: nice
<lamont> I'll do a bunch more tomorrow
<lamont> then I'll run out of excuses and have to review the patches.
<lamont> :-)
<lamont> I think that's actually the right priority order, given that the merges affect the review
<lamont> I also plan to do a very targeted debian upload of postfix, which will contain only fixes for the ubuntu bugs, then another one that has additional fixes.  that way I can easily merge the first over to hoary
<lamont> but that's wearing both my hats.
<lamont> I'll even make sure that I run it through the process before I upload the hoary package with the new debian version number :-)
<lamont> anyway, off to bed I fear.
<mdz> where is my new rootskel...GRR
<mdz> lamont: are you really gone?
<mdz> the source is there, but no binaries and no build logs and it's been there for hours
<sivang> lamont: yes? :)
<lamont> well, I was.
<lamont> sivang: have a hoary box to test something on?
<sivang> lamont: sure am ! :)
<lamont> http://people.ubuntu.com/~lamont/libpaper1_1.1.14ubuntu6_i386.deb
<lamont> download that
<sivang> lamont: downlaoding...
<lamont> dpkg --purge --force-depends libpaper1; dpkg -i libpaper1_1.1.14ubuntu6_i386.deb
<lamont> then tell me what's in /etc/papersize
<sivang> ok, copying and pasting and execing.
<sivang> lamont: in a sec.
<lamont> mdz: 1.11ubuntu1?
<lamont> or newer than tat?
<sivang> lamont: ok, lemme see what's in /etc/papersize
<sivang> lamont: "a4" that's all
<sivang> lamont: is that ok?
<lamont> woot!
<sivang> lamont: ;-) Glad to be of service 
<mdz> lamont: ubuntu2
<sivang> lamont: does that mean that I can now print on a4 paper? couldn't I before?
<mdz> lamont: http://archive.ubuntu.com/ubuntu/pool/main/r/rootskel/rootskel_1.11ubuntu2.dsc
<mdz> (that one)
<lamont> mdz: for whatever reason, it doesn't appear to have shown up in wanna-build
<lamont> sivang: it will now default to a4.  Note that cupsys takes it's default from that file (at install time), etc, etc.
<sivang> lamont: cool :) and with that optimistic end to my day (night) I'll say g'night.
<lamont> thanks again
<sivang> lamont: no, prob, always ask if you have anything to test :)
<sivang> mdz: night
<lamont> mdz: sanae is down
<lamont> or appears to be down.
<mdz> lamont: does that mean all builds are broken?
<lamont> since about 0200 london time
<lamont> sanae would be our critical piece of infrastructure for uploads getting signed...
<lamont> and buildlog publishing
<lamont> I could shove rootskel through, but probably better to get someone to kick sanae, and all will just flow.
<lamont> bbiam
<lamont> b
<lamont> mdz: the builds are all happening, they're just not getting uploaded, and the log files are queueing up in the mail queue for delivery once sanae is back up
<mdz> lamont: ok
<mdz> I can use localudebs for now
<lamont> and as a side effect, the buildLogs web tree isn't updating, since that's fed from the received mail as well...
<lamont> kicking the machine needs to be high on someone's list for tomorrow morning london time
<lamont> if there's something that _needs_ to go in, say before the daily CD build, I can push it, but I'd rather not - tired, etc.
<lamont> anything more before I go fall into bed?
* lamont will ponder some ideas for how to make things a bit more redundant in the upload department
* lamont goes back to bed for real
<mdz> daniels: here?
<mdz> let me rephrase
<mdz> daniels: WHERE ARE YOU
<bob2> mako: any news about the Missing Cds of Doom?
<mako> bob2: not yet
<fabbione> morning
<fabbione> daniels: xorg is GO
<lifeless> mdz: want me to ring him ?
<fabbione> mdz: he has been around until a few hours ago (6/7)
* zenrox streaks across the entire network
<mdz> fabbione: good morning
<mdz> fabbione: I was about to make some changes to the kernel udebs
<mdz> though now I am not sure if it is the right approach
<mdz> basically, I need psmouse and mousedev for the live CD
<mdz> either they need to go in a udeb, or we should package a full set of modules in the live fs
<lifeless> mdz: so do you want me to ring him ?
<mdz> lifeless: it's 1700 or something over there, yes?
<mdz> no, earlier
<lifeless> 1717
<mdz> ok
<mdz> yes
<mdz> thanks
<lifeless> his phone is off or out of range
<fabbione> mdz: i can do that easily...
<mdz> fabbione: well, at first I thought that obviously they should be added to a udeb
<fabbione> mdz: what modules do you need exaclty in which udeb
<mdz> but then I started to wonder, how many other modules are there which are not present in any udeb at all?
<mdz> the live CD should have all modules available
<fabbione> tons
<fabbione> well the live CD should have a kernel installed
<fabbione> all of it
<fabbione> not just bits
<mdz> yes, that is what I am thinking
<mdz> I am going to hack around it for the moment, but long-term, the fs that lamont builds should have a kernel installed
<mdz> the actual kernel image will be a waste because it will never be used
<mdz> but at least all the modules will be there
<mdz> I am going to hack in mousedev and psmouse just to get things going
<mdz> and then the last thing remaining is X config
<mdz> which is why I was hunting daniels
<fabbione> mdz: he has the bug assigned
<fabbione> mdz: the only thing he needs is someway to know if X is running on livecd or not
<mdz> hmm?
<fabbione> and somehow trigger a reconfig..
<mdz> I just need to know what command to run to get a working X config
<fabbione> mdz: there is none that does what you need at the moment
<fabbione> probably..
<fabbione> you can try with:
<fabbione> export XORGFORCEPROBE=yes
<mdz> haha, cron.daily just started running on the live CD
<lifeless> rotfl
<fabbione> dpkg-reconfigure -pnoninteractive xserver-xorg
<fabbione> mdz: in anycase.. for simple tests.. since you are at the beginning.. just don't write any config file
<mdz> fabbione: should I move xorg.conf out of the way if it exists?
<mdz> or does it not matter?
<fabbione> xorg should be able to autoconfigure itself in a good bunch of cases
<mdz> hmm
<mdz> so just delete the file?
<mdz> (it already exists from xserver-xorg being installed)
<mdz> what will it use for a mouse device by default?
<fabbione> mdz: if you are using the dpkg-reconfigure approc just be sure that md5sum /etc/X11/xorg.conf will match /var/lib/xfree86/xorg.conf.md5sum or something like that
<fabbione> if you want to use the second approch kill /etc/X11/xorg.conf
<mdz> just tried with no config file; it doesn't work
<fabbione> mdz: yeah it's not that perfect.. but a look at the logs would be nice
<fabbione> it should try the ps2 mouse by default
<fabbione> definetely it will never probe serial mices
<mdz> sent
<fabbione> mdz: well i meant.. you can look yourself ;)
<fabbione> Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
<mdz> I looked; I don't know why it isn't working
<mdz> it seemed to recognize that it needed ati
<fabbione> but i think it got almost all the config
<mdz> but then it tried to use vesa instead
<mdz> and then complained about framebuffer
<fabbione> because it did load the fb extension
<fabbione> not knowning the config it has to probe everything
<fabbione> (II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
<fabbione> (II) FBDEV(1): using default device
<fabbione> (--) Assigning device section with no busID to primary device
<fabbione> it's like it finds 2 video cards
<fabbione> that's why is confused
<mdz> hmm
<mdz> dpkg-reconfigure -fnoninteractive didn't quite work
<mdz> I think because it used values from the debconf db
<mdz> which came from some other machine
<mdz> I need for it to start empty
<fabbione> hmm yes it does..
<fabbione> use the debconf values...
<fabbione> mdz: but i was thinking.. the kernel unpacked is not that big.
<fabbione> at the end is only the bzImage that you don't use
<mdz> it will waste about 1M
<fabbione> and that's the minimal part compared to the modules
<fabbione> yeah
<mdz> I guess the modules which are in udebs are also waste
<fabbione> in that case yes...
<fabbione> or we can create a big fat all-in-one.modules.udeb
<fabbione> and you don't install the kernel 
<fabbione> but it would be probably more waste in this way
<fabbione> since d-i still needs the modules in different little chunks
<jdub> mdz: i think the d-i based livecd idea is really clever.
<jdub> :-)
<mdz> jdub: want to try it out?
<jdub> sure! but depends on download size, really
<mdz> it boots up nicely, and gdm thrashes about trying to start X
<mdz> and then you can login on the console
<mdz> it's full-sized
<mdz> and will take me hours to upload
<jdub> ahr
<jdub> heh
<mdz> but I intend to start an upload when I go to sleep tonight
<jdub> what's your upstream?
<jdub> what's the problem starting X?
<mdz> 256k
<jdub> ah, this is why you're hammer-pinging daniels?
<mdz> yes
<mdz> the problem starting X is that it needs a config
<jdub> ugh, same as my upstream -> sucks :|
<mdz> we should be able to move to building these at the data center quite soon
<jdub> these won't be usefully rsyncable either, will they?
<fabbione> hey pitti
<pitti> Hi fabbione 
<mdz> I don't imagine so
<mdz> it's possible that someone could work the rsyncable magic on the cloop compression tool
<fabbione> pitti: should we enable the strip translation on the buildd?
<pitti> fabbione, mdz: since the last cap patch was wrong, I think we should go with the "compile in" approach
<jdub> heh, that would be cool
<mdz> it basically uses zlib
<pitti> fabbione: on sparc?
<mdz> and compresses fixed-size blocks
<fabbione> pitti: i am preparing the new patch now..
<fabbione> pitti: there was only one extra commit to bk
<jdub> mdz: do we have a non-bounty cool hacks page?
<pitti> fabbione: ah, okay. so it was correct in principle, but not complete?
<fabbione> pitti: yes.. for sparc. did lamont already enable it for *?
<pitti> fabbione: I don't think so
<fabbione> pitti: the commit to dummy.c was wrong in bk. nothing to blame to us :-)
<pitti> fabbione: otherwise we would lose all translations for newly uploaded packages
<fabbione> pitti: ok.
<pitti> fabbione: carlos promised me to mass-import hoary soon
<pitti> fabbione: and I will work on the automatic deb generation in the meantime
<fabbione> pitti: so i am going to cook up a patch today and send it out
<pitti> fabbione: but I think all in all this will take another week
<jdub> oh man
<mdz> fabbione: hah, it turns out that the fs that amu gave me already had a kernel on it
<jdub> we so need an /etc/alsatab or something
<mdz> it is just half-installed
<mdz> jdub: #1293?
<mdz> jdub: what sort of cool hacks?
<jdub> mdz: rsyncable cloop
<jdub> stuff like that
<fabbione> mdz: ah...
<jdub> vfat sync
<mdz> it failed to create the initrd
<mdz> probably because it was done in a chroot
<jdub> mdz: (yes re: bug)
<fabbione> mdz: mostlikely
<mdz> we need to make that work, for lamont's build process
<mdz> it doesn't even need an initrd
<fabbione> mdz: there is the need of /proc and a sane /dev
<fabbione> mdz: that's all is required...
<fabbione> to install the kernel properly i mean
<fabbione> i remember fixing that several times in chroots
<mdz> I am doing one more burn to test my busybox changes, and then I will upload the last change to the archive
<mdz> except d-i, of course
<fabbione> mdz: is there any kernel change you need or you have done?
<mdz> I don't think any kernel change is necessary now
<fabbione> ok
<mdz> the #1 pending issue is X
<fabbione> i don't plan to upload anything before 2/3 days anyway
<mdz> fabbione: did you see my IRQ / sound bug?
<fabbione> since yesterday was a fucked up day...
<mdz> it seems like a 2.6.10 regression
<fabbione> checking the bugs now...
<mdz> I found one similar bug on bugzilla.kernel.org
<fabbione> mdz: did it work with -2 as well?
<fabbione> i remember you showed me the same message with 2.6.9 and 2.6.10
<fabbione> or just 2.6.10
<mdz> I am unsure about 2.6.9
<mdz> but it definitely did not happen with 2.6.8.1
<mdz> I only ran 2.6.9 for a very short time on this machine
<fabbione> did you try to boot with the irqpoll stuff?
<mdz> because you released 2.6.10 shortly after I started upgrading it again
<mdz> I did not
<fabbione> please do.. so i can report to alan
<fabbione> the problem is not device driver dependent.. like audio or usb
<fabbione> it is a general irq routing problem
<mdz> right
<fabbione> point is that there is no fix around yet
<crimsun> those alsa issues are complicated
<crimsun> most people seem to prefer onboard sound over usb headsets, for instance
<crimsun> and most people prefer a sblive over onboard sound
<zenrox> crimsun,  or a autolgy 2
<zenrox> over sblive
<crimsun> thomas's proposal of using hal sounds promising
<mdz> I think readahead would speed up the live CD a hell of a lot, given sufficient ram
<mdz> it spends all its time seeking
<mdz> this is going to be so sweet when it works
<mdz> daniels wasn't planning to work on the X stuff until next week, but this went more smoothly than I anticipated
<mdz> and I am ready for those bits
<pitti> elmo: please sync pmount from sid. TIA
<fabbione> pitti: i am puzzled...
<pitti> fabbione: what about?
<fabbione> pitti: of that stuff that has been committed to bk
<pitti> fabbione: it doesn't make sense?
<fabbione> no
<fabbione> but that's because bk is sick
<fabbione> ChangeSet don't have a unique number for the same piece of patch
<pitti> ugh
<fabbione> and the changes between what i saw and what is in are different
<pitti> security patch fuzzy-o-matic?
<fabbione> pitti: ENOCLUE
<fabbione> try for example to grab the .log files for bk7 and bk8
<fabbione> and diff them
<fabbione> you will see that a lot of changeset have been renumbered
<fabbione> and there is no sign of changes in security/capability.c
<fabbione> while there was in the patch i did send you yesterday!
<pitti> hmm, that's odd. Was there something about this on lkml?
<pitti> did they revert a patch or something like that?
<fabbione> apparently...
<fabbione> i am going to check with a manual diff
<mdz> jdub: http://people.ubuntu.com/~mdz/ubuntu-live/hoary-live-i386-alpha1.iso
<mdz> should be up in about 3 minutes
<fabbione> pitti: well.. manual diff confirms that they didn't change capability.c, but only dummy.c
<fabbione> pitti: i am preparing the final patch, but it will be a good idea to test it before uploading.. just to be sure i didn't fuck up anything
<pitti> fabbione: can you prepare an unofficial kernel image deb for testing?
<fabbione> pitti: yes that's what i am doing already
<fabbione> i really need some help with the kernel
<fabbione> it's just too much to do
<mdz> jdub: yeah, I know I said it would take hours, but I am just so goddamn clever today and so I copied amu's image there and then rsynced mine up (they use the same compressed filesystem inside)
<fabbione> I GET IT!
<fabbione> i know why bk renumber the changesets!
<fabbione> this is sooooo sick
<pitti> fabbione: why? does it make sense eventually?
<fabbione> pitti: example:
<fabbione> head ----
<fabbione> somebody creates branch a
<fabbione> somebody creates branch b
<fabbione> branch a start developing foo at rev 10
<fabbione> branch b fixes bar at rev 9
<plovs> does the ubuntu kernel have posic acl's?
<fabbione> head is at let say 20
<fabbione> i merge branch a and i get 21
<fabbione> when i merge b
<pitti> okay, I could follow so far
<crimsun> plovs: grep POSIX_ACL=y /boot/config-`uname -r`
<fabbione> than bk assumes that a is newer than b
<fabbione> so basically it tries to sort by date
<plovs> crimsun: even better then yes or no, thanks
<crimsun> plovs: np
<fabbione> and once the conflicts are resolved
<fabbione> all the changeset are rediffed and recommitted again
<fabbione> so changing numbers
<fabbione> even if the original one is preserved
<pitti> ah, I see
<fabbione> this is sick.. trust me
<pitti> so originally you looked at the fixed _branch_
<pitti> and now you look at the fix committed to the mainline?
<pitti> this would make sense
<pitti> fabbione: this is exactly how arch's star-merge works, isn't it?
<fabbione> pitti: i dunno...
<fabbione> but it was all on the same branch
<fabbione> that's why is scary
<pitti> fabbione: oh, but your example involved three branches (head, a, b)
<pitti> fabbione: I understand your example, it makes sense
<fabbione> pitti: yes.. but the renumbering happens on head
<pitti> fabbione: but I don't see how it works with just one branch
<fabbione> that's what i was looking
<fabbione> pitti: it doesn't on one branch
<fabbione> they merged bits from different branches into head
<fabbione> and the renumbering took place in head
<fabbione> i did never tracked the branches
<pitti> but that makes perfect sense
<fabbione> pitti: uh?
<pitti> but the very first patch was not from head, but from a branch?
<fabbione> pitti: it was already merged in branch
<fabbione> ehm
<fabbione> in head
<fabbione> and took a number
<pitti> hmm, then I don't understand it either
<fabbione> head----20
<fabbione> i merge 10
<fabbione> i get 21
<fabbione> i merge 9
<fabbione> what do i get?
<pitti> I don't understand, you can merge head---10 into head---20?
<pitti> shouldn't it already be in there?
<fabbione> let me explain again
<fabbione> head----20
<fabbione> that's where i am now
<fabbione> i merge branch--a--10 date: 2005-01-01
<fabbione> head goes to 21
<fabbione> ok?
<pitti> ok
<fabbione> i merge branch--b--9 date: 2004-12-31
<fabbione> head goes to 22
<fabbione> but
<fabbione> you expect that head--21 is the merge of branch--a--10 date: 2005-01-01
<fabbione> right?
<pitti> right, so I would expect in arch
<fabbione> in bk that doesn't happen
<pitti> but bk renumbers it to keep chronologically?
<fabbione> 21 becomes the merge of branch-b
<fabbione> because of the commit date
<pitti> D'oh
<pitti> bk changes commit history then?
<fabbione> and 22 becomes the merge of branch-a rediffed on top of 21
<pitti> you are right, THAT's scary
<fabbione> it doesn't really.. it just rename the changeset references
<fabbione> and recalculate them 
<fabbione> assigning different numbers
<fabbione> that is scary
<pitti> but that means I can't say to somebody "please merge 21 to fix it"
<pitti> because 21 might not be 21 any more in a week?
<pitti> buhuuuu
<fabbione> pitti: no.. you can't.. you need to give it the new ChangeSet
<fabbione> but i think bk is clever enough to reassign with logic
<pitti> fabbione: hmm, in arch I can say, 'hey, please merge foo--main--21' and this will always stay the same cset
<fabbione> i didn't dig too much or i will be sued for reverse engineering
<pitti> *laugh*
<fabbione> no shit...
<fabbione> Larry is on me
<fabbione> I am scared!
* fabbione runs away screaming
<fabbione> ahaha
* pitti hands fabbione  the patent axe
<fabbione> ehhe
<fabbione> ogra, mvo: ping
<fabbione> mvo_: hey
<fabbione> http://people.ubuntulinux.org/~fabbione/mIDSN.tar
<fabbione> mvo_: there are 2 modules you want from there.. one is the fritz and i think mISDNcore
<fabbione> since i wasn't sure about the second one i included all of them
<fabbione> they have some more debugging stuff compiled in
<mvo_> fabbione: thanks
<mvo_> I will test them now in my isdn test machine
<fabbione> they are for 686 kernels
<fabbione> remember
<enrico> Hello.  Could someone point me to where I can get the "About Ubuntu" page?  (described here: http://wiki.ubuntu.com/AboutUbuntuPage)
<fabbione> and they will not fix anything.. just more debugging output
<mvo_> fabbione: ok. luckily my test-machine is a 686 :)
<fabbione> mvo_: good
<pitti> Hey mvo
<mvo_> hi pitti 
<crimsun> I would love to test the -hardened 686-smp, but it uses XFS :/
<pitti> crimsun: I try to sort that out
<crimsun> pitti: many thanks
<pitti> crimsun: it's a missing symbol somewhere at bootup, I've got no idea about that
<pitti> crimsun: I have some higher-priority things to do, but I will try to look into this asap
<fabbione> pitti: it's probably just missing a MODULE_EXPORT_SYMBOL or something like that
<pitti> fabbione: hmm, but -hardened does not build any additional modules
<pitti> fabbione: and otherwise I use the standard kernel config (I just disabled SELinux)
<pitti> fabbione: the dmesg error is "xfs: Unknown symbol protection_map"
<pitti> fabbione: however, I deal with that later
<fabbione> pitti: it's not question of extra modules
<fabbione> check the pax patch if it touches XFS
<pitti> fabbione: it certainly does to implement the grsec hooks
<fabbione> and what file has the protecion_map function.. in the latter add the EXPORTSYMBOL(protecion_map) thingy
<fabbione> that should be enough
<pitti> fabbione: thanks for that hint
<pitti> fabbione: I just checked
<pitti> fabbione: the patch only touches fs/xfs/linux-2.6/xfs_file.c
<pitti> fabbione: and only inserts two lines of code
<pitti> fabbione: it's pretty unintrusive
<pitti> fabbione: but it uses this very function (protection_map)
<fabbione> pitti: well if the symbol is not exported, the other code can't see it
<pitti> fabbione: right
<pitti> fabbione: odd, protection_map is used all over the place
<fabbione> pitti: a missing include?
<pitti> fabbione: I doubt; the symbol is already used in the unpatched xfs_file.c file
<fabbione> weird...
<pitti> fabbione: oh wait, this was the patched version
<fabbione> hmmm is it used in other modules too?
<pitti> fabbione: the unpatched version of xfs_file.c does not contain protection_map
<pitti> fabbione: so it could be a missing include
<pitti> however, I grepped the whole (patched) source for protection_map, this should have caught EXPORTSYMBOL(pm)
<pitti> however, it didn't
<pitti> fabbione: this is defined in mm/mmap.c
<enrico> Hello.  Is there something running Hoary? :)  I need a copy of the HTML file that shows up when you click on "About Ubuntu".  Could someone either mail it to me or tell me in which package I can find it?
<fabbione> pitti: hmmmmm
<fabbione> pitti: check the patch if it adds includes here and there
<fabbione> pitti: for something related to mmap
<pitti> fabbione: I think it could help to include linux/mmap.h
<pitti> sorry, linux/mm.h
<fabbione> pitti: just check the patch...
<pitti> this file defines protection_map
<fabbione> yeah..
<fabbione> enrico: gnome-panel?
<fabbione> file:///usr/share/ubuntu-artwork/home/index.html
<enrico> so, the ubuntu-artwork package.  I'm getting it, thanks!
<fabbione> Kamion: you around?
<fabbione> mdz: if you are still alive.. do you agree in start spreading the 2.6.10 love a bit more around (considering it will be the default kernel)?
<cartman> lamont: about http://people.ubuntulinux.org/~lamont/buildLogs/k/kdebase/4:3.3.1-2/ . You need libxinerama-dev
<ogra> fabbione: sorry, you will have to wait until tonight.....cant test earlier.....modules grabbed...
<fabbione> ogra: fine for me
<ogra> good :)
<ogra> pitti: hwfu is an awsome work.....not very much left to do....thank you :)
<pitti> ogra: oh, there is still lots to do
<ogra> pitti: yeah, but the upcoming stuff is quite easy with this nice infrastructure ;)
<pitti> ogra: yes, I hope so
<pitti> ogra: but all the backends are still missing
<pitti> ogra: I think we might need to change the infrastructure too
<ogra> pitti: huh ?
<ogra> pitti: why that ?
<pitti> ogra: e. g. if pci detector adds a new node
<pitti> ogra: and another backend wants to add attributes to an already existing PCI node
<pitti> ogra: there is currently no way to do that
<ogra> hmm
<pitti> ogra: you somehow need to identify and address the node you wnat to change
<ogra> ok, i'll think about it
<pitti> ogra: currently you need to put all backend programs which touch a common node into a single detector module
<pitti> this should even work
<pitti> but it is not that nce
<pitti> nice, evne
<pitti> even, even :-/
<ogra> heh
<Kamion> mdz: what's the rootskel change about?
<Kamion> mdz: please do '# CONFIG_BLOCKDEV is not set' in busybox, rather than 'CONFIG_BLOCKDEV=n'; the test suite looks for the former style
<Kamion> mdz: blockdev should use busybox's getopt stuff before being submitted to busybox upstream
<Kamion> fabbione: ?
<fabbione> Kamion: any plan to switch d-i to 2.6.10 ?
<Kamion> fabbione: only when it's the default kernel
<Kamion> or committed to becoming the default kernel
<fabbione> Kamion: ok. than i will bugger mdz again since we agreed to have 2.6.10 as default
<fabbione> Kamion: no rush
<Kamion> what does mdz need to do?
<fabbione> approve it again?
<fabbione> and probably stick it somewhere in the seeds?
<fabbione> or via ubuntu-meta...
<fabbione> can't really remember
<Kamion> if it's committed to being the default kernel for hoary, I'm happy to change d-i
<Kamion> but the 2.6.10 udebs need to be in main first
<fabbione> Kamion: it can wait one day
<fabbione> that's what i mean
<amu> moins 
<fabbione> morning amu
* fabbione starts the kernel hppa buildd dance
<amu> fabbione: moin fabbione ... s/dance/love ;-)
<fabbione> no no.. dance
<fabbione> pitti: you were asking about posix acl.. yes we compile them
<pitti> fabbione: I didn't ask :-)
<crimsun> fabbione: that was plovs. I answered him.
<fabbione> ah ok
<fabbione> sorry...
<fabbione> pitti: btw.. you got mail
<pitti> fabbione: cool patch, thanks
<fabbione> dude.. it's not like i did it.. you know that.. don't you?
<pitti> fabbione: I know
<fabbione> ok
<pitti> fabbione: however, thanks for the work of digging it out :-)
<fabbione> no problem man
<fabbione> lamont: those hppa might even have 8GB of ram, but they suck at disk I/O
<fabbione> tar takes 99% of one CPU
<thom> jdub: ack
<fabbione> hey thom
<thom> morning
<pitti> hi thom 
<fabbione> hmmm
<fabbione> why my background doesn't change anymore?
<smurfix> fabbione: I had that yesterday night too. Kill nautilus, it'll work afterwards.
<fabbione> smurfix: thanks will do. also tahnks for signing the key. i will look at your pic asair
<pitti> Hi seb128 
<seb128> hey
<fabbione> lamont: 15 minutes it unpacked only 24MB...
<fabbione> i think it's time to ask ggg to look at it :-)
<smurfix> fabbione: no prob. NB, just rereading the BK discussion ... changesets do have constand identifiers, they're just somewhat more complicated. (What happens in Arch when two people independently decide to name their branch --test-- ?)
<fabbione> smurfix: well... i did a test on bk
<fabbione> yesterday changeset 1.2097 was a patch for some driver
<fabbione> today is the gtk2.4 fix
<fabbione> so they get renamed somehow
<smurfix> BK inherited those numbers from SCCS.
<smurfix> In a distributed system, one of them HAS to be renamed when you're merging.
<smurfix> BK decides to consistently renumber (not rename...sorry) the one that's checked in later.
<fabbione> smurfix: i don't disagree for the reasons.. it's just more complicate to track them
<smurfix> The nice property of that is if two people have the same changes, no matter how they arrived there, the numbers end up the same too.
<smurfix> bk 
<smurfix> oops
<Kamion> smurfix: "What happens in Arch"> don't try to identify arch branches purely by category--branch--version then; archive/category--branch--version is unique even if two people pick --test--
<smurfix> Kamion: But what happens after a merge? Then they end up in the same archive.
<Kamion> yes, with new patch numbers
<smurfix> Ah.
<Kamion> the merge is a new change that happens to list the merged change in its merged-patches header (whatever it's called, I forget)
<lifeless> smurfix: they end up in the same tree, as patch logs.
<lifeless> smurfix: but the archive is part of the patch id.
<Kamion> which makes sense since you might have to munge the change to make it apply
<lifeless> Kamion: 'new-patches'
<Kamion> thanks
<smurfix> Hmm, are the patches you merge in still separate? That is, if you merge version 1..20 from some remote branch B, can you still easily get --B--15?
<Kamion> they're not separated in the merged change you commit, but getting them from the remote branch doesn't get any harder
<Kamion> if you want to be able to get them in the merged-to archive, merge the changes one at a time rather than all at once
<smurfix> Ah. This is simpler in bitkeeper then; bk allows you to locally roll back to any change whatsoever. That's very helpful for automated "find the exact change that introduced bug X" testing.
<Kamion> smurfix: what if each of those merged changes requires resolution in order to work when merged? how can bk know how to separate out the resolutions if you commit them all at once?
<Kamion> I'm assuming that bk does not write your code for you :-)
<lifeless> smurfix: tla can roll back equally
<lifeless> AFAIK in both systems there is a minimum granularity. in tla thats per-file-hunk, if you want to drill in that far.
<gicmo> hi everybode ..
<gicmo> sladen, hi and happy new year ... any news on the uslpash front?
<seb128> hey gicmo 
<cartman> [OT]  http://arstechnica.com/columns/linux/linux-20050102.ars/1
<gicmo> jo seb128 :) .. 
<cartman> Ubuntu won "Best Distro" and "Best Community"
<cartman> and also "Best newcomer to the community"
<gicmo_> re .. damn dsl reconnect ..
<seb128> jdub: what's going on exactly with usplash exactly ? gicmo is still interested to help on this but seems nobody is really replying to good willing people on this :/
<jdub> seb128: mdz and sladen know about it
<seb128> mdz: sleeping at this time I guess ? :)
<robtaylor> gicmo: http://81.113.230.186/kalatlug/phpwiki/index.php/UsplashHowDoesItWork
* gicmo_ is looking
<robtaylor> seb128: there's been some activity on debian-desktop about it. 
<seb128> right
<robtaylor> gicmo: may be worth you joining in on the thread there
<gicmo_> robtaylor, thanks ..
<seb128> gicmo_: http://lists.debian.org/debian-desktop/2005/01/msg00004.html
<gicmo_> seb128, and thank you of course
<seb128> np :)
<seb128> sorry you don't get more reply on this, I'll ping mdz when he'll be awake
<jdub> seb128: (what's it doing on debian-desktop...?)
<robtaylor> jdub: heh, there may be threads on other ml's too ;)
<seb128> jdub: debian guys interested to get a splash too
<jdub> seb128: mmm, but no thread on u-d... kinda whacked
<seb128> jdub: no, but when people try to ping on the ubuntu side they are ignored for months ...
<seb128> jdub: gicmo is trying to help for like 3 months
<smurfix> Kamion: In BK, rolling back to a change beyond a merge implies throwing away everything on the "other" branches. You reproduce the whole tree exactly as it was at the time, so there's nothing you might need to resolve.
<Kamion> that's not what I meant
<jdub> seb128: well yeah, if there's no thread on the ubuntu list, then of course people are going to wonder :)
<jdub> seb128: that's precisely the point :-)
<Kamion> but I think I thought you were claiming much more about BK than you actually were, so never mind
<seb128> jdub: yeah, right
<jdub> http://www.leftontheweb.com/archive/2005/01/05/bertie_and_ubuntu
<robtaylor> jdub: fancy posting a post on u-d pointing to the thread on d-desktop? =) 
<jdub> perhaps in the morning, or you can
<jdub> it's very much bed time here
<fabbione> hey stub
<stub> yo
<fabbione> amu was reporting a similar problem for the ipw2200
<fabbione> and the fail seems to be related to the firmware load
<fabbione> i need you to test a few things for me
<fabbione> do you have a standard 2.6.10 from ubuntu or did you compile it yourself?
<stub> From ubuntu
<fabbione> ok
<fabbione> edit /etc/hotplug/firmware.agent
<fabbione> and uncomment this line:
<fabbione> # DEBUG=yes export DEBUG
<fabbione> this will produce some extra noise in syslog
<fabbione> now.. after you have done that
<fabbione> i need to know what happens if you unload and reload the ipw2200 module
<stub> You will need to tell me the magic commands to do that
<fabbione> i think the easiest way is to reboot
<fabbione> but if you cannot reboot you need to do:
<fabbione> ifdown <interface>
<fabbione> rmmod ipw2200
<fabbione> hem sorry
<fabbione> modprobe -r ipw2200
<fabbione> wait a few secs that everything is quite
<fabbione> modprobe ipw2200
<fabbione> this will reload the stuff
<fabbione> and check what happens in syslog
<fabbione> after that
<fabbione> ifup <interface>
<stub> k. I'll give that a go and reboot if necessary
<fabbione> stub: well if you can reboot it will be much simpler
<fabbione> up to you
<stub> k
* stub boots
<fabbione> eitherway i need to know what happens in syslog
<stub> fabbione: There should be debug stuff in /var/log/syslog or /var/log/debug? Can't see anything interesting.
<fabbione> syslog
<fabbione> iirc each entry should have something like firmare.agent: blabla
<fabbione> try a grep for firmware
<fabbione> i am sure 100% it saves the stuff in syslog..
<fabbione> or grep for hotplug
<stub> fabbione: Can't see anything... 
* stub checks /etc/syslog.conf
<fabbione> hem no..
<fabbione> it should be in /var/log/syslog
<gicmo> hehe
<fabbione> did you remember to uncomment that line in /etc/hotplug/firmware.agent?
<fabbione> otherwise just send me the syslog via mail
<stub> I can email it, but it isn't very exciting. I can see the messages that dmesg gave me before in the syslog, right near the end. Just nothing new.
<fabbione> or try kern.log?
<fabbione> it has to be there....
<jordi> faaaaaaabio!
<fabbione> hem
<jordi> fabbione: can you hint me on how to use xdebconfigurator?
<fabbione> stub: .. i am on crack...
<fabbione> the line was correct
<fabbione> but it's missing the proper debug_* functions all over
<fabbione> hey jordi 
<fabbione> no because that is sooooo worng
<fabbione> wrong even
<fabbione> stub: please grub http://people.ubuntu.com/~fabbione/firmware.agent
<fabbione> and use it in place of the one you have
<fabbione> and yeah.. either you reboot or do the module stuff
<stub> ok - much more now
<fabbione> ok.. can you paste it in pvt please?
<fabbione> there should be a bunch of lines.. probably 5/6
<fabbione> congratulation stub :-)
<Kamion> MMM, baguette + farmhouse/mushroom pt + Austrian smoked cheese + paprika salami
<fabbione> slurp!
<fabbione> lamont: 2 hours and 35 minutes to unpack the kernel on that hppa....
<fabbione> i wonder when i am going to copy it 4 times to test the build...
<fabbione> no even better... the N times required to create the patches!
<fabbione> stub
<fabbione> ops
* Kinnison pops in to say "Mmm, poppyseed baguette; paprika salami; farmhouse mushroom pate and portsalut"
<Kinnison> ;-)
<Treenaks> Kinnison: sounds like death in a bag ;)
<jdub> www.apple.com/xsan/
<Treenaks> how is this done in Linux?
<jdub> gfs
<jdub> recently b(r)ought back from the brink of irrelevance by red hat
<Treenaks> jdub: didn't they open it up? (besides selling it for $much-a-piece)
<thom> linux doesn't have shiny xserve-raid boxen, though
<jdub> Treenaks: yes, they bought sistina
<Treenaks> thom: let the hardware vendors take care of that
<amu> fabbione: if you need still some help with the ipw2200, letme know  
<fabbione> amu: i will
<fabbione> i am trying to understand 2 problems here
<fabbione> one is HOW can the card work without the firmware
<fabbione> and HOW can the card load the firmware WITHOUT /sys entries.....
<fabbione> because the first can't happen without the latter
* lamont takes kids to schoool
<amu> fabbione: without firmware ? 
<fabbione> ah hold on a sec...
<fabbione> lamont: i need you to talk with ggg about those hppa man...
<fabbione> lamont: 2 hours and 45 minutes to dpkg-source -x the kernel
<amu> ok
<fabbione> amu: cd /sys/class/firmware && ls
<fabbione> what do you have there?
<amu> amu@amu:/sys/class/firmware $ ls
<amu> timeout
<fabbione> ook
<fabbione> now.. cd /proc/class/firmware/ && ls
<amu> fabbione: should i reboot with your kernel? 
<fabbione> amu no need to
<amu> ok
<fabbione> i will ask stub to do the last test for me
<fabbione> if he will still be awake...
<amu> amu@amu:~ $ cd /proc/class/firmware/ && ls
<amu> -bash: cd: /proc/class/firmware/: Datei oder Verzeichnis nicht gefunden
<fabbione> eh?
<amu> nothing found :) 
<fabbione> ok
<fabbione> cat /proc/mounts | grep sysfs
<amu> amu@amu:~ $ cat /proc/mounts | grep sysf
<amu> sysfs /sys sysfs rw 0 0
<pitti> seb128: here?
<fabbione> ok i found the problem
<fabbione> amu, stub: go and get some better hardware
<fabbione> the Fatal Error is not realted to the firmware
<seb128> pitti: yes
<fabbione> but an irq error of somekind
<lamont> fabbione: I know there are other people using that machine sometimes - dunno what the load average is.
<fabbione> the firmware is loaded properly even if i don't know how (yet)
<pitti> seb128: I just stumbled over a similar bug that mdz recently saw
<fabbione> lamont: it was only me and dave....
<fabbione> lamont: load is 2 now...
<pitti> seb128: I tried to shutdown, the dialog appears, I click on restart and click enter
<fabbione> lamont: there is something wrong with disk I/O there
<pitti> seb128: but it doesn't shutdown, my terminals hang (I cannot type into them any more)
<lamont> I'll mention it to him.
<pitti> seb128: but other apps (xchat, ffox) run okay
<pitti> seb128: and I can't click on the menu
<seb128> pitti: weird. Is that reproducible ? 
<fabbione> lamont: thanks
<pitti> seb128: neither I can click in the bottom bar
<pitti> seb128: there is a fourth window (a error dialog, I suppose), but I cannot click on the button to see it
<fabbione> lamont: btw.. the patch applied almost without any problem.. only a couple of offsets here and there
<pitti> seb128: oh wait
<pitti> seb128: alt+tab does the trick
<seb128> pitti: looks like the dialog is modal
<lamont> fabbione: cool
<seb128> and you have to close that first
<seb128> to click anywhere else
<pitti> seb128: I see a window list which shows apps that don't support setting save
<fabbione> lamont: yeah.. i didn't take pa6 because according to cvs there is a FTBFS
<pitti> seb128: however, I did not choose to save my session
<fabbione> lamont: also.. we are going to build 32 and 64.. do we need anything more than that?
<fabbione> lamont: like all the other flavours that cvs build?
<lamont> {32,64}{,-smp}
<elmo> anyone know why my win key is now mapped to Super_L and how I ask gnome nicely for it not to be?
<elmo> well, s/win/apple/, but YKWIM
<Kinnison> elmo: keyboard properties thingy probably
<elmo> yeah, there's nothing obvious in there - unless I'm missing some terminology confusion
<amu> fabbione: yeah using most time a extern pcmica-wlan, i'm wondered about what i'll do, if i meet once a time the guy who developed such stupid hardware/software like the ipw2200 .... my next laptop will be a non-intel hardware. 
<lamont> back in an hour or so
<lamont> fabbione: that's 4 kernels :-)
<Treenaks> amu: avoid apple as well then, their broadcom chip isn't supported very well either (or at all)
<pitti> seb128: okay, that worked :-)
<pitti> seb128: so I see two bugs here:
<pitti> seb128: first, the modal dialog should be at the top
<seb128> yeah, this is going to be fixed
<pitti> seb128: second, I did not choose to save my session, why did it try?
<seb128> I'm working with upstream on the top level issue
<pitti> crimsun: I have xfs working on my -hardened kernel :-)
<pitti> seb128: okay, thanks!
<pitti> fabbione: the EXPORT_SYMBOL(protection_map) trick works perfectly, thanks!
<seb128> pitti: system -> preferences -> session
<seb128> pitti: do you have the autosave set here ?
<pitti> seb128: no, I don't
<seb128> ok, so that's weird
<pitti> seb128: and I don't want it :-)
<seb128> really
<seb128> let me know if you get this again
<pitti> sure
<seb128> any chance you messed up with a keybinding to check the save option ?
<amu> Treenaks: already done, but apple do it in a better way, there's null support for it, with intel you feel like you'll be their beta-hardware-tester,  spend too much time in order that it works fine. 
<fabbione> lamont: yeah 4 kernels...
<fabbione> amu: well i just read all the code for the ipw2200
<amu> fabbione: firmware ....   
<fabbione> amu: the module fails badly if it cannot create the /sys entries and if it cannot load the firmware
<Treenaks> fabbione: ah that's the Smell of Undeadness
<pitti> lamont: can you please have a look why my tiff security update for warty does not build?
<fabbione> amu: the driver still can load, but it won't work
<fabbione> amu: so basically what i am saying is that the "Fatal error" you and stub can see is not related to the firmware but to an irq problem on your machine
<pitti> seb128: I use ctrl+alt+delete as a shortcut for shutting down
<fabbione> pitti: no problem.. :-)
<pitti> seb128: however, I installed this keybinding just before the shutdown
<seb128> oh
<seb128> you set ctrl/alt/delete for logout ?
<seb128> that may be an issue, there is some bug about such configs
<pitti> seb128: well, c+a+d doesn't do anything under X otherwise...
<pitti> seb128: shall I try with another keybinding?
<amu> fabbione: .. the other problem, the card just automatically switch off, if the signal is too low, it happens every 15-20 sec.   
<pitti> seb128: did mdz use a keybinding? or the menu?
<seb128> pitti: I've not asked, I assumed that he was using the menu
<seb128> almost nobody use a keybinding for this
<lamont> pitti: known issue, being dealt with (build is fine)
<pitti> okay
<pitti> seb128: but it is actually nice to have one...
<seb128> there is a patch for cc/metaticy upstream to open the logout dialog on ctrl-alt-del
<pitti> seb128: is the particular key combination the problem or the assignment of a shortcut to logout?
<seb128> there was a thread on ubuntu-devel (or user ?) some time ago about this 
<pitti> hmm, okay
<seb128> seems to work fine here with Ctrl-Alt-l
<seb128> lemme try c-a-d
<seb128> pitti: I'm not going to kill my xorg by doing this, right ? :p
* seb128 doesn't want to close of the stuff open
<pitti> seb128: no, it doesn't do anything normally
<pitti> seb128: x.org is control-alt-backspace :-)
<seb128> works fine here
<pitti> hmm
<seb128> at least it opens the dialog and the save is not checked
<pitti> seb128: I try to reproduce it the next time I shut down
<pitti> seb128: it was not checked for me either
<pitti> seb128: but after I clicked ok, the session dialog appeared in the bg
<pitti> seb128: you actually have to shutdown to try it, sorry :-/
<seb128> ok
<seb128> I don't want to close my session now
<seb128> will try later
<pitti> np
<pitti> thanks
<seb128> np
* amu spray his ipw2200 with holy water and tries it now with higher forces 
<fabbione> amu: is that with the upstream driver?
<fabbione> or only with the kernel one?
<fabbione> (our kernel i mean)
<amu> generally
<fabbione> ok
<pitti> trulux: hi
<trulux> pitti, hey!
<lamont> ,ppf
<lamont> moof, even
<cartman> lamont: got my message about kdelibs compile error?
<amu> fabbione: same problem ( ipw2200 ) with the liveCD ( d-i ) and the 2.6.9 i386 kernel, hotplug detect there's a wlan-card, dhcp runs without success 
<seb128_> elmo_away: here ?
<gicmo> Kamion, I have been told that you might know how to help me .. how do I "correct" langugage and country settings after the installation .. is there a clean way?
<gicmo> or anybody else?
<pitti> gicmo: sudo dpkg-reconfigure locales
<seb128> "sudo dpkg-reconfigure locales" for the default locale
<pitti> gicmo: well, that doesn't correct your country, but the language at least
<pitti> gicmo: otherwise you might try rerunning base-config
<Kamion> re-running base-config wouldn't do anything useful.
<pitti> no, base-config doesn't do that, sorry
<Kamion> about the only things that the country option is used for are (a) the locale and (b) /etc/apt/sources.list
<gicmo> pitti, the problem is I wanna have english as default lang but have paper size, units, date formats usw in german style
<Kamion> gicmo: man 7 locale
<Kamion> you can set LC_<stuff> separately in your environment
<pitti> gicmo: set this up in /etc/environment
<seb128> /etc/environment by hand ? or is it an UI for that ?
<Kamion> so LC_TIME=de_DE.UTF-8
<gicmo> Kamion, ahh thanks .. thats what I thought to do .. but I wanted to know if there is a debian way of doing that ..
<Kamion> why use /etc/environment? shell startup scripts much easier
<pitti> seb128: vi :-)
<Kamion> and this is a user-specific thing so doing it system-wide is probably not what you really want
<seb128> pitti: that's what I call "by hand" :p
<gicmo> yeah thats totally "by hand"
<pitti> seb128: just kidding :-)
<Kamion> maybe the default shell startup scripts etc. should source ~/.environment or something, and there could be a user-level UI to change that
<gicmo> thanks anyways
<Kamion> nice and per-user
<Treenaks> gicmo: I do: LANG=nl_NL and LC_MESSAGES=en_US
<Treenaks> gicmo: works great
<gicmo> yeah thats what I searched for ..
<seb128> Keybuk: that's the intended behaviour for the desktop file ...
<Keybuk> seb128: ah, I may have misunderstood.  I thought desktop files had to be made executable first
<seb128> no, that's what the guy would like to get
<Keybuk> right, I misunderstood the thread then :p
<seb128> you can say that you didn't read it :p
<Keybuk> I read it
<lamont> how do I get screen to actually _EXIT_?
<Keybuk> I think I just lost context
<seb128> there is a potential security issue in fact, but I've no real idea on how to fix it
<seb128> lamont: ctrl-D ?
<lamont> seb128: that doesn't just get passed through to the remote?
<Keybuk> .desktop files should definietly require +x
<Keybuk> as they're basically an arbitrary single-line shell script
<seb128> Keybuk: that would not make a big difference
<Keybuk> I'm just thinking of an interesting caveat
<seb128> you don't expect to get a question when you click on a panel launcher
<fabbione> amu: in 2.6.9 there were no ipw2200 updates
<Keybuk> "a question" ?
<seb128> "do you want to run or see this ..."
<Keybuk> anything in the panel or menus should be made +x by the panel/menu surely?
<seb128> you got that when you click on a +x file
<Keybuk> so here's an interesting other problem
<seb128> yeah, and what about my desktop_is_home ?
<Keybuk> a user sticks a .desktop file in their home directory, designed to look like a file
<Keybuk> and asks another user or even root to read that
<Keybuk> they double-click it, and it wipes their home directory
<Keybuk> should you be able to run .desktop files owned by other users?
<seb128> hum
<Keybuk> hell, you could make it look like a folder
<Keybuk> "in my shared directory, you'll find..."
<seb128> there is no interest to run a .desktop owned by somebody else
<lamont> unless they ask you to look at it...
<seb128> yeah, that need some thought ... but I fear it'll not be easy to change
<Keybuk> http://descent.netsplit.com/~scott/kill-root.desktop
<Keybuk> there's *no way* of knowing that's not a folder
<Keybuk> drop one of those in a gnome-user-share too
<seb128> yeah, any suggestion ? Putting an emblem on all the desktop files ?
<Keybuk> I don't think that's sufficient, you'd first need to train what the emblem means
<seb128> the executable or not issue doesn't change the result on a drive
<thom> seb128: what are we going to do about typeaheadfind in ephy?
<seb128> thom: that's a firefox bug
<Keybuk> I think it's better to make .desktop files only work if you own them, or they're attached to thinks like the panel etc.
<seb128> chpe said than a firefox guy was working on fixing the typeahed in firefox
<Keybuk> otherwise they'd show up as just a text/desktop file
<lamont> is this a nautilus thing, or what's executing the desktop file?
<seb128> and if that's not done by GNOME 2.10 time he'll try to fix it
<Keybuk> lamont: nautilus thing
<thom> seb128: has he heard any more? oh, right
* lamont makes a note to continue never using nautilus
<thom> or a graphical mail client
<seb128> thom: and somebody is working on a epiphany-extension like the firefox search stuff IIRC
<Keybuk> gnome-vfs sees them as .desktop files (in Open/Save etc.)
<thom> seb128: righty
<lamont> thom: ditto
<lamont> uploads are working again, logs are still pending
<__daniel> hai everyone
<__daniel> is already some lang-pack stuff going on in hoary? i was curious why anjuta failed to work and when i straced it, it gave me loads of messages like "stat("/usr/share/locale-langpack/de/LC_MESSAGES/anjuta.mo", 0x7fbffff300) = -1 ENOENT (No such file or directory)" - before it segfaulted
<__daniel> does anyone have an idea?
<fabbione> the stat shouldn't be fatal
<mvo_> __daniel: there is some langpack stuff going on 
<pitti> __daniel: yes
<mvo_> but it shouldn't segfault :)
<pitti> __daniel: our new libc6 already supports the alternative gettext tree
<fabbione> pitti: so did we enable the pkgtranslation stripping on the buildd?
<pitti> __daniel: right, is the segfault related to this?
<pitti> fabbione: no, at least I don't know about it
<fabbione> lamont: ?
<pitti> fabbione: this new libc6 is in hoary since Matar
<fabbione> yeah i know that...
* fabbione needs to run to the laywer
<fabbione> bbl
<__daniel> pitti: i cannot tell, if it really is
<pitti> __daniel: the ENOENT result is natural, there are no files there (yet)
<cartman> lamont: ping
<__daniel> pitti: i see
<pitti> __daniel: however, it should now behave exactly like Debian's libc6
<pitti> __daniel: try Debian's libc6
<pitti> __daniel: btw, would you be oppopsed to support my -hardened kernel in your next X.org upload?
<__daniel> pitti: i tried to learn gvim the last 2 hours, but i got stomach ache after trying too hard ;-)
<__daniel> pitti: erm... i'm not daniels :-)
<pitti> __daniel: why, what's wrong about it? (I use console vim)
<pitti> __daniel: oops, sorry :-)
<__daniel> pitti: no problem :-)
<cartman> daniels supposed to upload a new X.org yesterday
<cartman> hrhr
<__daniel> pitti: maybe i just need that vim mug :-)
<lamont> fabbione: I still need to understand what needs to be done on the buildds to enable it... thought pitti was sending me some mail
<lamont> cartman: yo
<cartman> lamont: any way I could help with Ubuntu kde packs?
<lamont> cartman: patches for the outstanding bugs there would be good...
<pitti> lamont: you need to install pkgstriptranslations in the build chroot and enable it in /etc/pkgstriptranslations.conf
<pitti> lamont: that's all, debhelper will automatically use it
<cartman> lamont: where would I see the outstanding bugs? Is there a list?
<lamont> cartman: but then, I'm not managing the kde side of things
<lamont> build logs are under http://people.ubuntu.com/~lamont/buildLogs/
<__daniel> bye *wave*
<lamont> and the status of builds is at .../Lists
<cartman> lamont: yesh you need to install libxinerama-dev
<cartman> I checked error log
<pitti> lamont: the earlier we enable it, the less packages we have to rebuild before the release, but we will lose all translations until rosetta has the necessary export support
<lamont> pitti: that's step 1... where do I put the extracted files? are they in the build directory? (that gets nuked after the build, you see...), etc, etc.
<pitti> lamont: the files are just deleted, don't worry about them
<pitti> lamont: as I said, install the package, enable it in the conffile, kthxbye
<cartman> lamont: so who is the person organising KDE side?
<pitti> lamont: we cannot use the extracted mo files for various reasons, so we throw them away
<lamont> pitti: E: Couldn't find package pkgstriptranslations
<pitti> $ apt-cache show pkgstriptranslations
<pitti> Package: pkgstriptranslations
<pitti> Priority: extra
<pitti> Section: universe/devel
<pitti> Installed-Size: 64
<pitti> Maintainer: Martin Pitt <martin.pitt@canonical.com>
<thom> pitti: you're far too polite to pull off KTHXBYE :-)
<pitti> lamont: I updated the seeds yesterday, they might not have been updated since then
<lamont> pitti: meaning universe?
<lamont> ok
<pitti> lamont: do you know when the seeds are recomputed?
<pitti> lamont: I updated the arch tree yesterday morning
<lamont> pitti: there's a manual step involved before it actually affects the archive
<pitti> lamont: I was asked to make it configurable
<pitti> lamont: so if users install it it won't break their source builds
<pitti> lamont: is the config default "off" a problem?
<lamont> pitti: 10/12 done, other 2 quiescing
<lamont> quiesceing
<lamont> given that it's installed in the chroot forever, no issue at all.
* pitti looks up this funny word
<lamont> the next question is, should it be in hoary.buildd, or not.
<pitti> lamont: what did you quiesce?
<lamont> buildds
<pitti> lamont: personally I'd say we can live with losing translations for some time
<pitti> lamont: but I think mdz should decide this
<lamont> pitti: at your request, I just enabled it in 10 buildds
<pitti> lamont: you mean you isntalled the package on 10 out of 12 buildds?
<lamont> now you're not sure???
<lamont> installed and enabled
<lamont> as you requested
<lamont> config file only cares about the 'enable: (true|false)' line, yes?
<pitti> lamont: yes
<lamont> and we do want it enabled everywhere starting now?
<pitti> lamont: ahem - you asked me what is _required_ to enable it, not wheter I actually wanted to enable it right now...
<lamont> ah, so I shouldn't do that then?
<pitti> lamont: I'd ask mdz before pulling the trigger
<pitti> lamont: he should be awake soon, I hope
<lamont> seb128: eta on a new vte?
<seb128> upstream or debian/ubuntu ?
<Keybuk> hmm, ACPI hotplug support
<lamont> ubuntu, python2.4
<lamont> specifically, #5139
<seb128> upstream dunno but a patch sent a heavy patched package on the gtk-gnome list, I've planned to review/use it
<seb128> oh, that
<seb128> is there any hurry ?
<seb128> I would say tomorrow if there is no hurry
<lamont> yeah - officially? no
<pitti> lamont: hmm, now tiff was built on amd64, but not on the other arches...
<lamont> if this week, I'm happy.  If it'd be next week, I'd volunteer to deal with it while I'm walking through everything
<lamont> pitti: it's possible that I missed some in my cleanup - let me check
<Keybuk> <len.brown@intel.com> (04/11/11 1.2044)
<Keybuk>    [ACPI]  CPU hotplug, use kobject_hotplug(), kobject_register()
<Keybuk> sladen: that should be useful for u :p
<lamont> pitti: i386 should arrive in about 20 minutes, ppc may actually finish building (damn kernel bugs)
<pitti> okay, thanks
<mdz> pitti: hmm?
<pitti> mdz: morning
<pitti> mdz: we discussed a bit about whether we should enable gettext stripping on the buildds now
<pitti> mdz: rosetta support for langpacks will still last a week or so
<pitti> mdz: but the earlier we enable it, the fewer packages we have to rebuild before the release
<pitti> mdz: so if we enable it now, we will gradually lose translations as packages are uploaded
<pitti> mdz: lamont installed pkgstriptranslations in the buildds, but did not yet enable it so far
<mdz> pitti: now that upstream version freeze has happened (I assume), it doesn't really matter, since the pace of builds will have dropped to nearly zero
<mdz> pitti: if it is easier to wait, then wait
<mdz> Kamion: the rootskel change is in order to reload init
<mdz> fabbione: I see no reason not to move to 2.6.10 as default; the IRQ routing thing will be fixed
<Kamion> mdz: reload init when?
<pitti> mdz: well, its as easy to do it now as at any other time
<Kamion> huh, where did mdz's base-config changes disappear to?
<pitti> mdz: the question is whether we can temporary live with missing translations
<pitti> mdz: (in hoary)
<mdz> pitti: it will break the translations for all users until the language packs are caught up, no?
<mdz> Kamion: what base-config changes?
<mdz> Kamion: reload init to get from the busybox init to the real sysvinit
<mdz> Kamion: if you try out the live CD I posted to -devel about, it'll be clear
<Kamion> mdz: ubuntu7 and ubuntu8 haven't made it to archive.u.c yet
<Kamion> and I want to upload ubuntu9 :)
<Kamion> mdz: oh, damn, I'm stupid, busybox-cvs got mapped to base-config in my brain, sorry
<Kamion> mdz: you mean on SIGUSR1?
<pitti> mdz: newly uploaded packages will not have translations any more until we supply langpacks, right
<mdz> Kamion: according to lamont, part of the build infrastructure is fucked
<mdz> Kamion: correct
<mdz> has elmo turned up yet?
<Kamion> he was around earlier, fighting with GNOME
<mdz> god dammit, we inherited the broken version of flac
<mdz> upstream version freeze was supposed to happen yesterday
<mdz> has anyone heard from elmo?  is he dead?
<lamont> mdz: that was fixed this am
<lamont> if any are missing, holler
<mdz> oh, that was base-config/busybox-cvs confusion
<lamont> mdz: when I chatted with elmo ~3 hours ago, he estimated 4 hours for him to be in london.
<Kamion> yeah
<mdz> Kamion: thanks for looking over my busybox mangling; I was fairly certain it was not ideal
<lamont> so I expect that he's on the road
<Kamion> mdz: I can probably do the getopt conversion; I'd actually started on it but you beat me to the upload :)
<lamont> Kamion: which package were you questioning?
<Kamion> lamont: it was PEBKAC, don't worry about it
<mdz> Kamion: I did?  I thought you were in deep sleep
<lamont> ok.
<lamont> mdz: you're bouncing really large files, if you didn't know..
<Kamion> mdz: I started shortly before finishing work, but left at about 8pm and only got back this morning
<seb128> Kamion: any problem with GNOME ?
<Kamion> seb128: no idea
<mdz> lamont: yes, over 10M I think, but who would send me such things via email?
<lamont> sarti
<mdz> Kamion: my config/local now has zero EXTRAFILES in it :-)
<Kamion> mdz: cool!
<Kamion> how much in localudebs?
<mdz> only one
<mdz> (casper)
<Kamion> casper?
<mdz> the tentative name for the magical bit
<Kamion> mdz: oh, what do you think about that cryptsetup thing on u-d?
<Kamion> the encrypted-swap-by-default proposal
<mdz> if it can get done by featurefreeze, sure
<mdz> though, someone else reported a bug that the bit which is supposed to configure it at boot had a bug
<mdz> and looking at it, it's insane
<mdz>                                 if test -e "$key" ; then
<mdz>                                         MODE=`ls -l $key | sed 's/^....\(......\).*/\1/'`
<mdz>                                         OWNER=`ls -l $key | sed 's/^[^ ] * *[^ ] * *\([^ ] *\).*/\1/'`
<Kamion> ick
<Kamion> ok, I'll work with him to see what we can get into partman, if possible
<pitti> Kamion: FWIW, if it is supportable, having cryptsetup in main would rock
<mdz> only two followups regarding live CD testing while I slept :'-(
<mdz> did anyone here try it?
<Kamion> mdz: is that cryptsetup code?
<mdz> Kamion: yes, that's from cryptsetup
<Kamion> my pipe is currently full of two weeks' worth of Ubuntu archive re-mirroring
<Kamion> the local mirror's been busted for a while ...
<mdz> lamont: where do we stand on the desktop fs builds?
<thom> i'm currently laptop only, and so no cd capability
<mdz> thom: you bastards and your X40s
<mvo_> mdz: I tried the one from amu at 2005-01-03 and it bootet for me
<mdz> mvo_: this is completely different
<thom> mdz: *g*
<mvo_> mdz: ok, I'll get the new one then 
<mdz> it's looking pretty sweet
<mdz> it already works unmodified on both ATA CD-ROMs and USB ones
<mdz> Kamion: do you have any idea why the console is messed up until I switch VCs?
<mdz> Kamion: does bterm or whatever not clean up when it's killed?
<mdz> it happens at a very awkward time, so I think I'd prefer to fix the cause rather than add some code to switch VCs or otherwise work around it
<lamont> mdz: looking at that today, actually
<Kamion> TBH it would surprise me if it cleaned up properly ...
<mdz> lamont: only new item is that it must include a kernel
<sladen> keybuk: interesting, we'll see.   I'm currently considering fetching the detection code from speedstep-lib, but even that falls back to checking the alphanumeric name at some points
<mdz> lamont: so, debootstrap + task: ubuntu-desktop (or metapackage ubuntu-desktop) + linux-foo
<lamont> ok
<lamont> for what value of foo, I wonder...
<mdz> Kamion: is there some way that lamont can easily borrow the kernel logic from base-installer?
<mdz> (I think it's base-installer)
<lamont> mdz: I think I just wind up populating a kernel or 3 (ppc) into the file system, and then it's the boot system's pain, not mine...
<lamont> no?
<lamont> because the buildd has no clue what machine you'll be booting on...
<mdz> lamont: the only bit which matters at all is /lib/modules
<mdz> lamont: anything else is a (tolerable) waste of space
<mdz> lamont: the kernel is already loaded by the time we get anywhere near that filesystem
<Kamion> mdz: base-installer/kernel/README documents the API ...
<lamont> so a non-tuned i468 kernel, for example
<Kamion> mdz: I'm not convinced the logic is appropriate though?
<mdz> yeah, I suppose it's overkill
<Kamion> don't we just want to hardcode an appropriate kernel for each arch? base-installer tries to pick the closest one to the hardware, which is different
<mdz> what we want is: i386 -> linux-386, powerpc -> all of them, I suppose, amd64 -> amd64-generic
<Kamion> the build machine's hardware will often be better than the machine the CD's running on
<Kamion> agreed
<lamont> mdz: do you want the vmlinux left present, or removed?
<mdz> lamont: if we get tight on space, I might ask you to terminate it with prejudice, but in the name of simplicity, let's leave it alone for now
<mdz> likewise for the initrds
<lamont> ;k
<mdz> hmm, speaking of which, won't that be a problem on powerpc?
<mdz> will it be able to generate all of the initrds properly?
<lamont> what? space?
<mdz> we might need to add some kernel-package magic to tell it not to worry about all that initrd business
<Kamion> (note that ext2 is not built into the powerpc kernels)
<lamont> do the initrd's come from the cloopfs?
* mvo_ has to leave to town now to get his glasses fixed. bbl
<mdz> if there is'nt such an option buried there already
<Kamion> don't see why it wouldn't be able to generate all the initrds?
<mdz> lamont: the system is booted using a kernel an initrd on the CD, like on the install CDs
<lamont> Kamion: which fstype should we use for ppc then?
<mdz> lamont: so the only thing of importance in the cloop fs is the modules
<lamont> mdz: right.  so you're just worried about install?
<lamont> install into the cloopfs, that is
<Kamion> lamont: actually ext2 could be loaded by the live CD infrastructure
<Kamion> so pretend I didn't say anything :)
<mdz> lamont: yeah, I'm pre-worrynig about problems you might run into, basically
<lamont> Kamion: heh
<mdz> Kamion: as long as ext2 is available in udeb form, we're OK
<Kamion> it is, d-i wouldn't work otherwise
<lamont> Kamion: if there's a better format for it, it's no problme to use that on ppc
<Kamion> nah, cramfs for a filesystem the size of the live CD's would suck, I expect
<mdz> ext2 is a natural choice
<Kamion> mdz: make sure to depend on ext2-modules
<lamont> Kamion: right.
<mdz> cramfs is no good; it needs to be writable
<mdz> Kamion: I'm thinking it might be best if you wrangled the d-i stuff, to be honest
<lamont> mdz: does it need to be created with extra space, or will that just magically show up in the course of things?
<Kamion> ok, I'm willing to do the administrivia on that front
<mdz> I have a feeling it would take me all day, and you a trivial amount of time
<mdz> lamont: make it big
<mdz> say 3G
<mdz> the slack will compress out
<Kamion> mdz: send me hacked packages with all the live-CD-specific logic, and I'll put it together?
* Kamion still kind of wonders how we're going to deal with the udeb namespacing thing, to make sure the live CD's anna doesn't load modules only appropriate for the install CD
<mdz> there's basically one udeb
<mdz> which I am sending to you
<mako> does someone know how i can get to the old wiki?
<mdz> Kamion: you already have the diff from amu, which is basically what I was using
<mdz> with two modifications:
<amu> mdz: the livecd-script ? 
<mdz> amu: we're talking about the d-i changes
<Kamion> mdz: what I'd like, actually, is to have a tiny udeb in the initrd which decides whether it's turning on live-CD functionality, and arranges for the appropriate udeb to be installed; the idea there is that we can use the same initrds for both install and live CDs
<mdz> casper is used instead of livecd-script
<amu> mdz: 
<Kamion> so the install CD would have a tiny extra bit of overhead which looks basically like rescue-check does
<mdz> Kamion: hmm, that'd be nice
<amu> <mdz> there's basically one udeb? 
<mdz> Kamion: I can have casper build an extra udeb for that, I suppose
<Kamion> mdz: look at the rescue source
<mdz> E: Unable to find a source package for rescue
<smurfix> mako: seems to be a server-side redirect => ENFW
<Kamion> svn://svn.debian.org/d-i/trunk/packages/rescue
<mdz> hmm
<mdz> subversion is still at python2.3?
<Kamion> subversion depends on python?!
<Kamion> subversion-tools, yeah ...
<mdz> Kamion: I'm also not so clear on which udebs should be pulled in by casper dependencies, and which should be in the pkg-lists lists
<mdz> probably casper should depend on dmsetup-udeb
<mdz> and cloop-modules
<mdz> er, loop-modules
<Kamion> mako: https://www.ubuntu.com/FrontPage
<mdz> and cdrom-detect
<Kamion> mdz: if we were going for same-initrd-for-both, then everything that isn't already in pkg-lists should be depended on by casper
<mdz> I think that's all that we added
<mdz> but we had to remove a bunch of stuff
<Kamion> cdrom-detect will be needed to load casper anyway, if it's not in the initrd
<mdz> how are we going to handle that if we use the same initrd?
<Kamion> what had to be removed?
<mdz> basically everything from partman onward
<mdz> so I don't need to depend on cdrom-detect, right?
<Kamion> that's not in pkg-lists, except for monolithic
<mdz> Depends: dmsetup-udeb, loop-modules
<mdz> ext2-modules?
<Kamion> hm, best depend on cdrom-detect anyway, it would be possible to netboot into casper
<Kamion> ext2-modules, yeah
<mdz> all kinds of fun things become possible :-)
<mako> Kamion: i would *never* have guessed that :)
<Kamion> basically the initrds other than monolithic are only supposed to contain enough stuff to retrieve more udebs
<Kamion> mako: I found it by way of a bug
<mdz> right
<mdz> Kamion: I can assume that busybox will be present, right?
<mdz> trying to think what else I use
<Kamion> mdz: absolutely
<mdz> I think that's it
<Kamion> mako: go to http://www.ubuntu.com/wiki/, and then try logging in ...
<Kamion> note how after you enter username and password it drops you into the old wiki :)
<Kamion> mdz: busybox is used for /sbin/init
<mdz> Kamion: what sequence number should I use for the d-i-startup.d script?
<mako> Kamion: ahhh.. 
<Kamion> mdz: anything from 50 or so onward should be fine
* mako buries his head in his hands
<mdz> Kamion: is it inappropriate to name it casper-udeb, since it's essentially d-i-specific maybe it should have a name like rescue-mode?
<cartman> vorbis-tools needs to be built against updated libflac
<Kamion> I only call stuff -udeb when it has a non-udeb equivalent
<Kamion> maybe just casper?
<mdz> there is likely to be a casper-utils or similar which is a normal deb
<Kamion> or casper-<whatever-it-does>
<mdz> to be installed in the target fs
<Kamion> casper-pivot?
<mdz> it's sort of a casper-mode
<mdz> cartman: more accurately, flac is just broken
<mdz> what we need is ELMO
<cartman> mdz: or that yes
<Kamion> I pondered calling rescue-mode rescue-shell actually, can't remember why I picked rescue-mode
<cartman> but looks l
<cartman> like library version is updated
<mdz> cartman: the library version was updated, but not the package name
<cartman> mdz: I see. my system sounds will be borked for some time :/
<mdz> that package was inadvertently uploaded by the moron maintainer
<mdz> followed shortly by a fixed version
<mdz> which has been helpfully sitting in Debian queue/new for 2 days
<cartman> guess archieve is not yet updated?
<mdz> Kamion: what does the .isinstallable bit do?
<mdz> cartman: it's waiting in queue/new
<cartman> mdz: ok, thanks
<Kamion> mdz: helps out monolithic images
<mdz> Kamion: should I have one?
<Kamion> mdz: in normal images, rescue-mode won't even be installed; in monolithic images you can't stop it being installed because it's in the initrd, but the .isinstallable file stops it doing anything
<Kamion> mdz: yeah, I'd recommend similar structure
<Kamion> it's cheap and you'll appreciate it later :)
* lamont must reboot.  sigh.  brb
<mdz> ok, I've cloned rescue-check onto casper
<mdz> now what?
<Kamion> put casper-check in the cdrom-live initrd
<Kamion> put casper-<whatever> on your CD and in the Packages file
<Kamion> make sure 'anna-install casper-<whatever>' is in casper-check's debian-installer-startup.d
<mdz> so at this point I need to endure debian-cd
<Kamion> marvel as it automatically pulls in casper-<whatever>
<mdz> [ "$RET" = true ]  && anna-install casper-udeb
<Kamion> oh, and include appropriate debconf variable setting in your bootloader config
<mdz> Kamion: how should we go about getting the big filesystem blob onto the CD?
<Kamion> mdz: personally I just take an existing CD and hack it ...
<mdz> Kamion: I mean on an automated basis
<Kamion> 17:31 < mdz> so at this point I need to endure debian-cd
<Kamion> I was replying to that, order aside
<Kamion> mdz: give me a place to pull the blob from and a location on the CD to put it, and I can make debian-cd copy it in
<mdz> Kamion: casper is currently at menu-item: 22
<Kamion> somewhere on the LAN would be good
<mdz> is that still OK?
<mdz> Kamion: the blob is inside the .iso on rookery, if you have loop-mount capability
<Kamion> won't work with netboot
<Kamion> I can't loop-mount stuff on little
<Kamion> mdz: don't you want disk detection?
<mdz> I don't know how to get it to you without uploading a 500M file
<mdz> Kamion: detection, yes
<Kamion> presumably it'll be built on the LAN soon enough
<mdz> but I seem to get that already for free, from hotplug
<Kamion> disk detection runs at 35
<Kamion> hmm, not on all macs as yet
<mdz> ok
<mdz> just tell me what number I ought to use
<mdz> and I'll change it
<Kamion> I'd use 40 I think
<Kamion> if you need to disable questions, I'd be inclined to make casper-check set whatever debconf questions are needed to make the questions go away
<mdz> the only one that has been a problem so far is the hostname
<mdz> the behaviour I want is that if it gets a hostname from dhcp, great, use it without questions, otherwise, use a default without questions
<Kamion> ok, sec
<mdz> perhaps lamont will have a new blob ready soon, and you can use that rather than me trying to upload mine
<mdz> though, with a little rsync magic I could make it fast to upload
<mdz> I need to work out how to test these changes now, though
<Kamion> perhaps: db_fset netcfg/dhcp_options seen true; db_set netcfg/get_hostname some-default-hostname; db_fset netcfg/get_hostname seen true
<mdz> get_hostname won't already be populated with a default?
<mdz> disk detection won't ask any questions at default priority, right?
<Kamion> yeah, it will, 'ubuntu', so leave that bit out
<mdz> I'll do a test here with the new setup, and then see about questions
<mdz> I think I need to walk through this in my head
<Kamion> disk detection> nope
<mdz> when does debian-installer-startup.d run?
<Kamion> it's equivalent to rcS
<mdz> ok, so casper-check runs
<Kamion> the flow is init -> debian-installer-startup.d -> for (;;) { debian-installer.d }
<mdz> it gets a value from debconf, which should be preseeded from the command line or a file
<Kamion> default to false
<mdz> yes, though that makes my testing more difficult
<mdz> if set, it anna-installs casper-udeb and its deps
<Kamion> default to true for testing purposes is fine too :)
<Kamion> (anna-install automatically follows deps)
<mdz> right
<Kamion> anna-install won't take effect immediately, it queues until anna runs
<mdz> will there be more udebs installed by the time casper runs, than there would have been before?
<mdz> or are the new ones mostly after casper in order?
<mdz> s/installed/run/ I suppose
<Kamion> hw-detect-full is not generally in the initrd, for example
<mdz> casper has this gross hack where it removes some of the bits from prebaseconfig.d and base-installer.d, and then does run-parts on them
<Kamion> and it would (in my theory) run before casper
<Kamion> I think you should present the live CD with a custom Packages file that does not include partman, base-installer, prebaseconfig, etc.
<mdz> so if there is any other stuff that I need to remove there, I can make those changes now
<mdz> (if you know of any off the top of your head)
<Kamion> are you currently installing base-installer and prebaseconfig
<Kamion> ?
<mdz> I am not
<mdz> (in the monolithic config)
<Kamion> ok, good
<mdz> but ideally, casper ought to cope
<mdz> to allow for a combo live/install DVD
<Kamion> yeah, I've been pondering that
<mdz> basically, anything after casper never gets a chance, if it runs
<Kamion> we could always have another tree of Packages files analogous to dists/hoary/main/debian-installer/
<Kamion> and use that instead
<mdz> because everything running on the initrd gets killed
<Kamion> the "debian-installer" bit there is hardcoded in the various *-retriever packages
<Kamion> it could be made customisable, and then a combo DVD would be easy
<mdz> alternatively, we could preseed hints to modify the "standard" selection
<Kamion> of course, that would be hard for netboot without archive cooperation
<Kamion> or require a particular OK-For-Live-CD: field
<mdz> what's my next step to test this out?
<Kamion> run with a custom Packages file with just the bits you need, IMO
<mdz> so pull down a hoary daily install CD
<Kamion> that approach is good enough for a first release
<mdz> add casper-udeb and casper-check to it
<mdz> mangle the Packages file
<mdz> copy the live fs in
<mdz> re-mkisofs
<Kamion> update Packages.gz and Release
<Kamion> you'll have to add casper-check to the initrd on the CD
<Kamion> (or copy in a completely new initrd)
<Kamion> make sure casper-udeb is Priority: standard
<Kamion> >=
<Kamion> actually, no, forget that last
<Kamion> (I'm stupid)
<mdz> ETA 40 minutes for a CD download
<Kamion> if nothing after casper gets a chance to run, of course, removing later stuff from the Packages file is not important
<mdz> casper-check standard, casper-udeb optional, is what I have now
<Kamion> ok, good
<mdz> tihs is starting to sound very painful for iterative testing
<Kamion> rescue works that way, you can include it on a standard image completely safely
<mdz> hopefully casper-check won't be buggy :-)
<mdz> do you have a script to sync up the Packages/Release stuff?
<Kamion> this approach is basically how I test d-i changes, you get into the habit of it
<Kamion> finger macros :)
<Kamion> sudo sh -c 'gzip -c Packages' > Packages.gz; cd ../..; apt-ftparchive release .; copy changes into Release
<Kamion> I should come up with an apt-ftparchive line that matches what debian-cd spits out
<Kamion> mdz: if you can make netboot work ...
<Kamion> this is one reason I'm suggesting generic d-i-like approaches, they take a little longer but adapting them to netboot etc. should be trivial
<Kamion> or even USB boot
<ogra> mdz: x configuration on your live cd is very weird....dpkg-reconfigure defaulted to ati (on a toshiba laptop with trident card which i selected then) and wrote a xorg.conf with nvidia in it....
<ogra> mdz: oh, no, stop...it didnt even touch the xorg.conf it seems.... hmm
<fabbione> mdz: ok. i am quite busy now.. mind to do the honours?
<fabbione> lamont: sorry.. i lost my scrollback..
<fabbione> lamont: did you enable the pkgstriptranslation on the buildd?
* fabbione runs away
<fabbione> lamont: please msg me about it... i have logs enabled this time :-)
<pitti> fabbione: I think he installed pkgstriptranslations, but did not activated it by now
<lamont> pitti: installed, enabled, disabled, waiting for someone to decide that they really, really, really want it enabled
<Kamion> hmm, kickstart has an 'auth --enablecache' command which enables nscd, but we don't support that
<Kamion> what's the right answer? support nscd? bomb out?
<pitti> mdz, lamont: personally I can live with fading translations for a while, but I think mdz should have the final word about it
<pitti> mdz, lamont: OTOH waiting for another week does not make much of a difference
<mdz> ogra: it has an nvidia xorg.conf on it, from amu's system I think
<mdz> fabbione: ok
<ogra> mdz: unfortunately its handeditet, so dpkg-reconfigure wont touch it anymore.....that makes X useless on this cd unless you know about the md5sum thing
<mdz> Kamion: should we give the user broken crap if they ask for it?
<mdz> ogra: ah
<Kamion> mdz: kickstart also supports NIS, LDAP, hesiod; if you're using any of those I can see why you might want to use nscd
<mdz> Kamion: yeah, because you're already out of your mind
<Kamion> :-)
<Kamion> or you're a sysadmin with existing machines to support that are already configured
<Kamion> and you want to integrate Ubuntu with that setup
<Kamion> this is the kickstart target market, remember ...
<mdz> Kamion: did you get this?
<mdz> Jan 05 12:43:51 <mdz>   Kamion: is there an easy way to skip the first CD scan? I'm curious as to whether it is actually pessimizing things
<Kamion> mdz: comment it out in /var/lib/dpkg/info/cdrom-detect.postinst before it runs
<trukulo> anyone using pbuilder on ubuntu?
<trukulo> sorry
<trukulo> think i was on #ubuntu
<mdz> Kamion: what do you think is a reasonable spot on the CD to keep the cloop image?
<mdz> perhaps /casper/filesystem.cloop
<Kamion> fine by me
<kent> Since Ubuntu is changing to UTF in Hoary, and the weather applet seems to have problems with that in Hoary (http://leviatan.kicks-ass.org/dump.png), should i report it as a bug?
<lamont> rm: cannot remove directory `chroot-test/tmp/dir.zVOlMH': Device or resource busy
* lamont grumbles
<mdz> kent: yes
<mdz> lamont: once you have the ext2 image, you'll want to install cloop-utils and use create_compressed_fs <file> 65536 > <file>.cloop
<seb128> kent: don't forget to provide details on your environment, the applet works fine here with utf-8
<mdz> as always :-)
<seb128> kent: ie, output of "locales", /etc/environment, what locale is picked in gdm, etc
<seb128> locale even
<lamont> mdz: yeah
<kent> seb128, will do that. I have to study tonight, so il take the time to write a report tomorrow. It might be my fault, but i think i followed the information about how to upgrade to Hoary step by step, so perhaps its a bug..  i fill know tomorow then.
* pitti tests new life CD, brb
<kent> seb128, the locale picked up by gdm,  is it the one in $LANG ?  gedit and other programs default to UTF when i save files, and $LANG is set to utf when i check in gnome-terminal. And locale, /etc/environment is also set to utf.
<mdz> yay pitti
<mdz> Kamion: what's the magic mkisofs command I need?
<seb128> kent: if you alt-F2 and "locale | zenity --text-info" here
<seb128> what is the locale ?
<seb128> kent: hum ok, you're right. There is a problem with the locations, but the rest of the string is fine. Please file a bug, just put the screenshot in it, that's fine 
<seb128> time to dinner now, bbl
<mdz> Kamion: and do I need to fudge Release.gpg or no?
<pitti> mdz: live cd boots fine for me
<pitti> mdz: is "FATAL: Module This not found." a known bug?
<mdz> Kamion: mkisofs -r -V 'Ubuntu 4.10 i386 Bin-1' -o warty-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table <dir>
<mdz> Kamion: is what I found in scrollback, hope that's right
<pitti> mdz: I chose German locale in the installer, still I have POSIX
<mdz> pitti: yeah, it's a powernowd bug I believe
<mdz> pitti: ok, good to know.  I think I need to do some manual work to carry that over
<pitti> mdz: this "This" modules sounds like a parsing bug of /etc/modules
<mdz> pitti: https://bugzilla.ubuntu.com/show_bug.cgi?id=5138
<mdz> it's already fixed; the snapshot is a week old
<lamont> sigh.  how do I force debconf to go non-interactive?
<sivang> life cd :)
<sivang> anybody know if there are the d-i po files already in rosetta?
<pitti> mdz: but I did not investigate this
<pitti> fine
<pitti> mdz: dpkg-reconfigure -plow xserver-xorg does not ask me for resolutions, but I guess it's a bit too early for X stuff :-)
<pitti> lamont: DEBIAN_FRONTEND=noninteractive?
* pitti got X running on the life cd :-)
<ogra> pitti: woah, i'm trying it since 1/2 hr
<pitti> mdz: do you have an idea why there is no /dev/input/mice on the life cd?
<mdz> pitti: yes, after copying in a working xorg.conf from my hard drive, it works quite nicely
<mdz> pitti: no, I don't, I would be forever grateful if you would inventigate
<mdz> it appears if you unload and reload mousedev
<pitti> mdz: usbhid is loaded and found my mouse
<pitti> yeah, now it's here
<pitti> cool, X with mouse and ubuntu desktop
<mdz> pitti: can you try to find out why it doesn't appear initially?
<mdz> mousedev is loaded via /etc/modules in the normal way
<pitti> mdz: I try
<mdz> I don't see why it should not appear until the second time it is loaded
<pitti> mdz: btw, my usb stick does nothing either
<pitti> mdz: maybe a general USB problem
<lamont> hrm.. there are some things that are done at install time that we really want to defer until boot time for the livecd...
<pitti> mdz: the lamp on it is not even enabled
* lamont is thinking of libpaper1's config, for starters.
<ogra> yay, got it !!#
<ogra> pitti, does your panel work ? its absolutely unresponsive here
<pitti> mdz, ogra: well, sort of
<pitti> mdz, ogra: I just tried to shutdown, clicked okay in the idalog, now everything hangs
<pitti> no, just the panel is hanging
<ogra> at least your menu responses
<ogra> i cant even open it :)
<mdz> pitti: odd, shutdown worked perfectly for me
<pitti> I reboot now to investigate the mouse and other issues
<pitti> but before I need some dinner, cya later
<ogra> heh, the nautilus tree view has 72px folder icons....funny
<amu> mdz: what's about sound? works also  
<amu> +?
<mdz> amu: I haven't tested yet
<mdz> amu: I am building a new non-monolithic CD image to test
<ogra> doesnt work here :(
<amu> mdz: downloaded just your iso, it's different than mine? 
<mdz> amu: yes, entirely different except for the /live-fs
<mdz> you should be able to rsync it against yours and save a lot of download, since the live-fs is large
<amu> ogra: with my i810x sound works also 
<ogra> hah, with /etc/init.d/gdm start my panel works, with startx it doesnt
<ogra> amu: i'm looking at it now...
<ogra> ARGH !
<mdz> ogra: then use gdm :-)
<mdz> that's what the final version will do
<ogra> please please please blacklist snd_intel810m by default !
<ogra> thats blocking my sound devices....again
<mdz> ogra: did you add your comments to the bug?
<sladen> mjg59: http://function.linuxpower.ca/patches/patch-netconsole ; would if it'd be worth modifying this and providing a central server to capture the panic.  When a users machine dies repeated, they can be told 'type this and enter a user-id, the next time your machine crashes, goto  panic.ubuntu.com/user-id  and the trace will be there
<amu> mdz: sound should be initalized by hotplug? atm it's done by the old alsa-autoconfig  
<mdz> amu: on my CD it is done by hotplug and alsa-base
<amu> mdz: which soundcard? 
<mdz> i810
<ogra> i8x0
<ogra> sorry
<mdz> amu: your filesystem has saved mixer settings for a different sound card
<ogra> -> m
<mdz> so the init script prints an error
<ogra> hmm, and you should delete bash.history ;)
<mdz> ogra: lamont is working on autobuilding new images
<mdz> elmo lives
<mdz> whoa
<mdz> Kamion: what prints "E: Unimplemented function"
<mdz> Kamion: (context: d-i initrd)
<mdz> seems to be in libdebconf
<cartman> mdz: any idea when will new flac packs will make it to archieve?
<mdz> cartman: no
<cartman> mdz: ok
<mdz> I sent email via bugzilla to elmo
<Kamion> mdz: that mkisofs command is fine; no, you don't need to fudge Release.gpg (yet)
<cartman> mdz: ok
<mdz> Kamion: I uncompressed and loop-mounted the initrd, udpkg --unpack'd casper-check onto it, recompressed it and booted it in qemu
<Kamion> mdz: yes, sounds like _confmodule_process() returned NULL
<mdz> and all hell broke loose
<Kamion> maybe the status file is screwed?
<mdz> it seems to be during casper-udeb.postinst
<mdz> the only change I made to it was to add: 
<mdz> . /usr/share/debconf/confmodule
<mdz> # Be nice to monolithic users.
<mdz> db_get casper/enable
<mdz> [ "$RET" = true ]  || exit 0
<mdz> at the top
<mdz> wait, hmm
<Kamion> did the .templates file get unpacked?
<mdz> it seems to be running much earlier than it should be
<mdz> hmm, no it didn't
<mdz> does udpkg --unpack not do that?
<Kamion> note that all /var/lib/dpkg/info/*.templates get removed early on in the boot process, to save memory; they get merged into /var/lib/cdebconf/templates.dat
<Kamion> the d-i initrd build process uses dpkg --unpack rather than udpkg ...
<mdz> I loop-mounted the initrd and it is not there
<mdz> Kamion: dpkg --root=/mnt ?
<mdz> hmm, no, that does'nt work
<mdz> dpkg: cannot scan updates directory `/mnt/var/lib/dpkg/updates/': No such file or directory
<Kamion> dpkg --force-overwrite --root=/mnt --unpack $udeb
<Kamion> you have to mkdir /var/lib/dpkg/updates and touch /var/lib/dpkg/available first
<Kamion>         # Only dpkg needs this stuff, so it can be removed later.
<Kamion>         mkdir -p $(DPKGDIR)/updates/
<Kamion>         touch $(DPKGDIR)/available
<mdz> guh
<Kamion> any reason you aren't just rebuilding the initrd?
<mdz> because I was waiting on you to do the wrangling :-)
<Kamion> udpkg calls debconf-loadtemplate directly rather than unpacking the .templates into /var/lib/dpkg/info
<mdz> though I suppose all that's needed now is to add casper-check to cdrom?
<Kamion> I don't have mail from you; am I supposed to have?
<mdz> you were supposed to have, but it's obsolete now
<mdz> since I've reworked casper to use -check and such
<mdz> it's still fucked
<Kamion> (hm, should I update the installer to 2.6.10 now?)
<mdz> yes
<mdz> let me take a screenshot of this
<mdz> and maybe you can tell what is going on
<mdz> seb128: is it expected that gnome-panel-screenshot --window --delay=N does not work?
<mdz> Kamion: http://dijkstra.csh.rit.edu/~mdz/temp/boom.png
<mdz> Kamion: that happens immediately after "Waiting for /dev/fb/0 to appear" or whatever
<seb128> mdz: hum, the --delay= seems to be broken :/
<seb128> mdz: but you have a keybinding to capture the current window
<mdz> seb128: oh, what is it?
<mdz> by default
<seb128> yep
<mdz> ah, shift+print
<seb128> should be that
<Kamion> guh, that looks very broken
<seb128> I was looking for it, I've changed mine
<mdz> Kamion: it's as if something is running twice which shouldn't be
<Kamion> why should mounting sysfs fail?
<Kamion> can you put the initrd somewhere?
<mdz> it's like debian-installer-startup.d is restarting
<mdz> it already mounted it once
<mdz> and loaded the acpi modules
<mdz> yes
<ogra> mdz: any reason why i got a fam running ?
<crimsun> pitti: great news! thanks. :)
<mdz> Kamion: http://dijkstra.csh.rit.edu/~mdz/temp/initrd.gz
<mdz> Kamion: will take a few minutes to upload
* Kamion contemplates removing those .UTF-8@euro locales
<cartman> anyone is able enter unicode text and delete them properly using backspace at login prompt?
<cartman> here entering works but can't delete them
<crimsun> cartman: using bash?
<mdz> Kamion: initrd is up
<cartman> crimsun: tty console login
<crimsun> cartman: there are reports of certain other shells not working properly with it, like zsh.
<mdz> cartman: works fine with bash, known buggy with zsh
<cartman> mdz, crimsun I am talking about initial login prompt at tty1
<Kamion> try 'unicode_start'
<cartman> Kamion: in an init script?
<cartman> - :)
<Kamion> no at the command line
<Kamion> experimentally
<cartman> hmm but  when I login I can use unicode fine
<cartman> and delete them
<Kamion> mdz: uh. are you sure that's the right initrd?
<Kamion> there is no /sbin/debian-installer-startup there
<Kamion> oh, never mind, PEBKAC
<Kamion> ah, I see
<Kamion> mdz: make S60casper-check executable
<Kamion> mdz: non-executable files in debian-installer-startup.d are sourced, and that makes very bad things happen when /usr/share/debconf/confmodule is sourced and re-execs the whole thing
<mdz> guh
<Kamion> executable files in debian-installer-startup.d are executed instead
<mdz> it would make me so much happier if it did the same thing as init
<mdz> .sh rather than non-exec
<mxpxpod> jdub: ping
<Kamion> that would work too, could try for that upstream post-sarge
<cartman> guess the bug is in /bin/login
<mdz> Kamion: once I get this working, I'd like for you to eyeball casper before I upload it
<Kamion> ok
<Kamion> I'll be out this evening, expect to be back at least briefly in a few hours
<mdz> when do you leave?
<Kamion> about 15 minutes
<kent> seb128, http://leviatan.kicks-ass.org/dump2.png   <- the output of the command you wrote.   
<Kamion> I can phone ahead and be later if need be
<seb128> kent: have you read what I said after ? :)
<seb128> but thanks :)
<mdz> Kamion: nah, don't let me delay you
<kent> seb128, now i did, sorry about that :)  Should i edit the screendumps with gimp to make them smaller when i attach the picture? (cut out unneeded stuff?) 
<seb128> kent: yeah, just the panel area with the string is fine
<mdz> Kamion: is there an anna-remove?  that seems like it would be a nice way for casper to get rid of partman
<mdz> hmm, doesn't seem to be
<mdz> hmm, this is doomed to fail
<mdz> no dmsetup-udeb on the CD
<mdz> oh, yes there is
<Kamion> no anna-remove
<Kamion> surely just reboot after casper is done
<Kamion> that's what rescue-mode does, works fine
<mdz> Kamion: I mean avoiding unpacking it at all
<mdz> it's a waste of time
<Kamion> well, umount stuff and reboot
<mdz> the shutdown process for casper is just a normal system shutdown :-)
<mdz> by the time it's finished, d-i is gone
<Kamion> it might be better to invent a way to tell anna not to install standard-priority packages
<mdz> gah, need a newer busybox on this CD
<mdz> I guess my busybox-cvs upload was too late for the daily CD
<mdz> or else delayed by the build mess
<Kamion> busybox-cvs uploads need new daily-installer-* which need BYHAND
<mdz> probably rootskel, too, then
<Kamion> could you file a bug on anna about the standard-priority thing and assign it to me?
<mdz> those both need to go in the initrd, yes?
<Kamion> yes
<mdz> ok
<Kamion> those two are totally foundational :)
<Kamion> anna/manual_only or something, maybe
<ogra_casper> mdz: is working suspend expected for this cd ?
<ogra_casper> s/for/from/
<amu> ogra_casper: i guess no, i've to implement this first :) with very very low prio  
<ogra_casper> ah, k
<amu> ogra_casper: if it works, that would be pure coincidence, or mdz is faster than light
<ogra_casper> nope, doesnt work....
<ogra_casper> and my panels+nautilus just dissapeared without any action from my side :-/
<amu> ogra_casper: that's normal pannel fun ;) *runsaway* 
<ogra_casper> oh....ps -ax input/output error.....
<ogra_casper> hmm, suspend seems to work.....half way *g*
<ogra_casper> my disk is absolutely sleeping....but funnily xchat still works from mem
<abelli> ogra?
<amu> ogra_casper: how much ram you have? 
<abelli> amu: how is it?
<ogra_casper> 384M
<ogra_casper> its a laptop
<amu> abelli: thx fine& happy new .... 
<abelli> blah blah blah... 
<abelli> thank you
<ogra_casper> heh
<amu> ogra_casper: any maschine with 64mb left? 
<abelli> amu: is the live cd up ?
<sivang> ogra_casper: what's that casper thing? :)
<ogra_casper> nope, but i can set one up (not before the weekend...sorry)
<amu> abelli: see u-devel, mdz announced last night, i woundert why you didnt tested it yet  
<abelli> i wasnt in my home.. sorry
<abelli> s/home/...
<mdz> ogra_casper: I've no idea; did you try it?
<ogra_casper> sivang: dunno, ask someone enlightened, xchat had casper_user in it....so i modified it
<mdz> ogra_casper: I wouldn't expect to need to do any extra work to get that to happen
<mdz> if the kernel bits work on your hardware, it should work
<abelli> amu: wowowwoowww
<ogra_casper> mdz: i tried it....but did only work half way it seems
<ogra_casper> abelli: yep, it seems to get very fine.....for an alpha this is awsome..... (kudos to amu and mdz)
<ogra_casper> abelli: (i'm using it currently)
<abelli> im going to try it with the xbox's bios thing we're working on...
<ogra_casper> amu: did you get X -configure sorted ?
<amu> nope, takes too long time, daniels is working on a xconfig, make no sense if i wast too many hours with it. 
<ogra_casper> i experienced a weird prob here....
<ogra_casper> did you ever edit the xorg.conf in your chroot by hand ?
<amu> yep
<ogra_casper> so thats your prob then i guess
<ogra_casper> (read the header of the xorg.conf)
<amu> no, do you have one ? 
<mdz> X -configure didn't seem to generate a working config for my laptop
<ogra_casper> X -configure doesnt even write a file if the original doesnt match the md5sum
<amu> ogra_casper: hehe, converted from XF86 ... 
<pitti> mdz: do you have this mouse /dev/input/mice problem as well?
<pitti> mdz: I spent some time debugging it, but somehow the whole USB system seems to be screwed up
<ogra_casper> its written in the header of the file :)
<ogra_casper> hal-device-manager seems broken
<pitti> mdz: my net connection keeps failing this evening; did you get my question "<pitti> mdz: do you have this mouse /dev/input/mice problem as well?"
<mdz> pitti: yes, I do
<mdz> it is not specific to usb
<pitti> mdz: I tried to stop hotplug and usb, unload all modules
<mdz> mousedev itself should cause that module to appear
<pitti> mdz: then started udev, module-init-tools and hotplug again
<mdz> s/that module/that device node/
<ogra> amu:  md5sum /etc/X11/xorg.conf >/var/lib/xfree86/xorg.conf.md5sum
<pitti> however, after this my mouse was not recognized at all any more
<mdz> ogra_casper: X -configure writes a file for me
<mdz> it just isn't a very good one
<ogra_casper> mdz: where does it write it ?
<mdz> /root/xorg.conf
<mdz> as it says in the output
<ogra_casper> mdz: ah, ok
<mdz> /root/xorg.conf.new tha tis
<ogra_casper> yup
<pitti> mdz: since I cannot restart the system I cannot play around with different /etc/modules versions :-(
<mdz> pitti: what do you mean?
<pitti> mdz: I suspected that usbhid must be loaded before mousedev, but actually this _should_ not be necessary
<mdz> no, usbhid is not necessary at all
<pitti> mdz: for me it is
<pitti> without usbhid I don't have a mouse
<pitti> however, it should not matter with /dev/input/mice, right
<lamont> mdz: actually, it's starting to look like just giving you lib/modules is going to be the easier route.
<lamont> mdz: how do you feel about doing dpkg --configure -a after mounting /?
<ogra> hmm.... * cannot execute "/sbin/shutdown"
<mdz> lamont: er, what?
<mdz> pitti: oh, I confused usbhid and usbkbd/usbmouse
<mdz> pitti: anyway, I am using psmouse
<mdz> usbhid should not be necessary to get /dev/input/mice
<mdz> it should appear as soon as mousedev is loaded
<mdz> even though there are no mice
<mdz> and that is not happening for some reason
<mdz> ogra: you have fam because it was in amu's image for some reason :-)
<lamont> mdz: turns out I appear to be stuck installing udev (which likes to mount things at install time, etc...
<pitti> mdz: hmm, drivers/input/mousedev.c creates the sysfs device unconditionally
<pitti> mdz: is it possible that udev does not yet run properly at the time mousedev is loaded?
<mdz> lamont: we might need to subvert it, then
<lamont> but actually installing the kernel seems to leave root/dev busy, etc.  and needs /proc mounted, and, and...
<pitti> mdz: right, so says the source
<pitti> mdz: however, the module creates the sysfs entry, so maybe this is an udev race
<mdz> lamont: in fact, I recommend you don't run any init scripts at all
<mdz> lamont: put in a dummy invoke-rc.d or whatever
<lamont> makes sense
<mdz> lamont: I don't think you'll be able to avoid mounting /proc, though. mkinitrd will need it
<lamont> why do I need to run mkinitrd in my filesystem?
<mdz> lamont: if you can avoid it, great, but generally the kernel postinst will run it
<lamont> figured I'd just unpack the kernel, and leave it at that... thoughts?
<mdz> I don't like that, because it'll cause problems when you try to install packages later
<mdz> if you want to fake mkinitrd, fine
<mdz> but all packages should be fully installed
<lamont> do you want the real mkinitrd on the final filesystem?
<mdz> mv mkinitrd mkinitrd.real; ln -s true mkinitrd; etc.
<mdz> yes
<lamont> right.
<mdz> any hackery like that (invoke-rc.d, mkinitrd) needs to be undone for the final image
<lamont> more inclined to dpkg-divert it during the install then.
<mdz> basically the same way debootstrap works, with start-stop-daemon etc.
<mdz> fine by me
<mdz> if everything you need to divert is installed by debootstrap, that should work fine
<mdz> if you need to tweak something installed with the desktop, that's tricker
<mdz> trickier
<mdz> lamont: does console-tools end up in your image?
<pitti> fabbione: here?
<lamont> mdz: yes
<lamont> == base
<mdz> for some reason, localechooser tries to install it
<mdz> lamont: also console-data and console-common?
<lamont> right between bzip2 and cpio
<lamont> :-)  that's a yes
<opi> anyone can tell me more about Rosetta status?
<opi> some polish user ask me why we double gnome.pl effort in translation
<lamont> mdz: how close are you to wanting this image?
* lamont kinda expects 'now'.
<mdz> lamont: it's not blocking me, but it's on the critical path
<lamont> right.
<lamont> it's ahead of merges today
<mdz> opi: you can ask on #rosetta
<opi> mdz: ok
<opi> mdz: because some translations are mostly ready, so we're wasting time on things that are already here
<lamont> opi: if the translations are available somewhere, I would hope that rosetta would just import them
<opi> lamont: yeah, I hope that, too
<lamont> brb
<opi> lamont: I wasn't Gnome guy before Ubuntu, so I wasn't aware of Gnome.pl efforts
<mvo__> hmmm ... the live-cd hangs here with "/dev/vc/1" does not exist
<mdz> lamont: the fact that the current image has a half-installed kernel on it is causing problems
<mdz> lamont: so sooner rather than later
<mdz> seb128: how much work would it be to create a small GNOME applet with a progress bar in it?
<azeem> progress bars are patented in Europe
<seb128> mdz: really easy to do
<mdz> seb128: is there some example code I could steal?
<opi> seb128: I'll attach /var/log in regards of #5147 bug
<mdz> preferably in python if that's possible
<opi> mdz: seen it somewhere in Pythong/GTK related examples
<seb128> yeah
<seb128> a sec
<seb128> opi: /var/log/XFree86.0.log
<opi> seb128: ok, I need to leave office first ;)
<seb128> mdz: /usr/lib/python2.3/site-packages/gtk-2.0/gnome/applet.py
<seb128> hum nop
<seb128> mdz: /usr/share/doc/python2.3-gnome2-extras/examples/applet/applet.py
<mdz> in which package?
<seb128> mdz: you have just a label here, but changing it for a progress bar would be easy
<mdz> oh, python2.x-gnome2-extras
<seb128> yep
<seb128> the instructions are in the README in the dir
<pitti> daniels: ping
<mdz> whoa, that is easy
<seb128> yep
<seb128> pygtk rocks :)
<two-face> hi
<seb128> hey two-face 
<two-face> hello seb128 
<mdz> what is the 3rd argument to bonobo_factory?
<mdz> ("hello")
<two-face> i guess i'll find people using tla in here :)
<mdz> what I want to do is create an applet which will poll a file containing some numbers, and display them as a progress bar
<mdz> so it needs to refresh periodically
<seb128> the description
<pitti> two-face: close, baz :-) But I still know tla
<mdz> do I need to run a thread?
<seb128> mdz: perhaps you can read that http://www.pygtk.org/articles/applets_arturogf/
<mdz> ok, thanks
<seb128> http://www.pygtk.org/articles/applets_arturogf/x134.html 
<seb128> 5.3. Optional timeout callback method
<seb128> for the update
<seb128> with a timeout
<seb128> no need to thread
<two-face> pitti: with what key do you sing your archive?
<two-face> pitti: sign :)
<pitti> two-face: ? my normal GPG key?
<pitti> two-face: however, usually I don't sign my own archives
<pitti> I should probably, though
<two-face> pitti: i'm pondering generating a dedicated key signed by my main gpg key
<two-face> pitti: i don't know if it's worth it
<pitti> two-face: what should be the benefit of this?
<two-face> pitti: for instance, avoiding having one main key on one's laptop
<pitti> two-face: I already have three subkeys for my different roles (Debian, Ubuntu, private), I don't need any more
<pitti> two-face: however, it might be worth having some project-specific keys
<two-face> pitti: ha, subeys
<two-face> subkeys
<two-face> pitti: it might be what i need
<pitti> two-face: I don't have any GPG key on my laptop
<pitti> two-face: if I need it, I ssh on my server
<two-face> pitti: ok, I guess I can easily find docs on subkeys in the web
<pitti> two-face: well, I don't know whether subkeys is right
<pitti> two-face: in fact I think it's wrong
<pitti> two-face: I have different IDs
<pitti> but it's actually the same key
<two-face> ah?
<two-face> Ho different is it?
<two-face> How
<pitti> no idea
<two-face> hmm
<lamont> dbus. postinst. must. change.
<two-face> pitti: but how did you generate them, then?
<pitti> two-face: the different IDs?
<two-face> pitti: yep
<pitti> two-face: gpg --edit <key>
<pitti> adduid
<two-face> ah, ok, I see
<pitti> tehre is also "addkey", this might be the one for subkeys
<two-face> pew
<two-face> I need to spend some time reading docs
<two-face> in the meantine I won't sign at all
<two-face> pitti: thanks
<pitti> no problem
<two-face> still maintaing postgresql?
<pitti> yes
<pitti> I spend 95% of my Debian time on it... :-/
<two-face> heh
<two-face> i think it is worth it
<pitti> after every upload (that ususally closes 10 bugs) I think "yes, that's the Sarge version"
<pitti> and after this I get 5 new bugs...
<pitti> yes, me too
<pitti> it is fun
<two-face> :-P
<pitti> most of the time
<two-face> it is fun because it is an interesting piece of soft
<pitti> two-face: indeed
<pitti> two-face: the only problem is that the original packaging was totally screwed up
<two-face> oh, does it feature redundancy?
<pitti> two-face: what do you mean by that?
<two-face> database redundancy between servers
* lamont adds a workaround for dbus's brain damage for the moment
<pitti> two-face: ah, replication?
<pitti> two-face: not right now
<two-face> pitti: yep
<lamont> must run to get kids. back about 1630 MST
<pitti> somebody should find the time to package slony-1
<two-face> pitti: which is?
<pitti> two-face: this is the replication system of choice currently
<two-face> ah
<two-face> nifty
<pitti> two-face: however, I spent my current time in stabilizing postgresql proper
<pitti> so I did not find any time for it
<two-face> two-face: i see
<pitti> two-face: I also have to work on the complete repackaging of PostgreSQL 8
<two-face> pitti: good
<pitti> two-face: brb, I test my new -hardened kernel :-)
<two-face> with oliver?
<pitti> off to reboot
<pitti> two-face: yes
<two-face> ok
<jinty> Is there someone who can go and kick debpartial-mirror?
<jinty> It is currently uninstallable because of a dependency on python 2.3
<gsuveg> re
<jinty> whcih a simple re-build without changes should fix.
<mvo__> jinty: I can take a look
<jinty> In fact I have done so and tested on my local machine.
<pitti> two-face: back
<jinty> Thanks muchly
<two-face> pitti: are you hardened? :)
<pitti> two-face: I am hardened all the time :-), but this was a new build
<two-face> pitti: heh
* lamont talked his wife into fetching kids
<mdz> lamont: how goes the build adventure?
<lamont> somewhere in the course of things, invoke-rc.d seems to get overwritten with the real version, which is most annoying.
<lamont> dbus-1 directly invokes /etc/init.d/dbus-1, so I'm temporarily diverting that too...
<lamont> because once you have tac-nukes, everything starts to look like a small city
<lamont> the bitch is that the test cycle is now up to several minutes
<lamont> 623 packages installed by apt-get install ubuntu-desktop linux-386
<mdz> lamont: I think the dbus thing is deserving of a patch + bug report
<lamont> mkinitrd was fun to divert.  /bin/true didn't cut it.
* lamont hugs python-minimal
<lamont> yes
<lamont> will file that when I'm done
<lamont> doh
<mako> mdz: yo!
<mdz> mako: what is up my brother
<mdz> mako: what is happening in your hood?
<mako> mdz: so your suggestion about the HEADER.html for the releases page.. what happened to it?
<mdz> mako: I think nobody got around to putting the files in the right place
<mako> mdz: lets do it..
<mdz> mako: yes, let's
<mako> thom: but us, i mean you
<mdz> mako: and by let's, I mean you do it :-)
<mako> hah
<mako> right i'll do it
<mako> and by i, i mean thom
<lamont> mdz: dbus bug is ubuntu-specific
<mako> mdz: i'll send mail to admins and then follow up on it
<mako> mdz: i get mail every few days from people who are confused, and i liked the idea
<mdz> lamont: because we patched it that way, or because we're behind on merges?
<mdz> I'm guessing the latter
<lamont> mdz: my bad.  debian has the bug, and I can't read.
<lamont> mdz: debian has 0.22-4, we have 0.22+cvs.200412122010-0ubuntu4
<mako> i think we should futher clarify the amd64 thing.. people think *allthetime* that they need amd64 for their athlon xp, etc
<mdz> mako: yes
* lamont will file a bug against debian, and fix our version - code is way diff
<lamont> actually, not all that diff... we migrated it from 20 -> 12.
<mjt> anyone know how to build certain file in glibc?
<mjt> i want to experiment with that grep slowness with utf-8, to find the real cause of the problem.. but glibc build stuff is quite.. complex... ;)
<pitti> mjt: what do you want to do?
<pitti> mjt: I also touched glibc a while ago, but the build system is relatively easy
<pitti> mjt: it just takes a while :-/
<mjt> heh.. i tought i explained that a line above... ;)
<pitti> mjt: what is "a certain file"?
<mjt> i want to get some files (modified( off it and build either a static or shared (to pre-load) lib
<mjt> so i will not need to reinstall glibc while doing some expiriments
<azeem> messing with the glibc build system is not for the faint of the heart, AFAIK
<mjt> nod
<pitti> azeem: it's dpatch, nothing fancy
<pitti> mjt: it has several build-tree directories
<azeem> pitti: upstream build system
<pitti> mjt: just build it once, then you can go into the build-tree, make your changes
<pitti> mjt: ah
<mjt> that's what i do now (it's compiling right now)
<pitti> mjt: I thought you wanted to deal with the Ubunut/Debian source pacakge
<mjt> in particular i want mbrtowc.c
<pitti> mjt: believe me, that's much easier
<mjt> it's irrelevant really
<mjt> in fact i grabbed glibc-2.3.2.ds1-20
<pitti> mjt: debuild -us -uc once to build everything
<pitti> mjt: then you can go into one build-tree, make your changes, type make
<pitti> mjt: and can LD_PRELOAD the resulting library in the build-tree
<pitti> for experiments
<pitti> mjt: above worked fine for me
<mjt> ughrrrr...
<mjt> /stage/build/glibc/glibc-2.3.2.ds1/build-tree/i386-libc/wcsmbs/mbrtowc.op(.text+0x109): In function `__mbrtowc':
<mjt> /stage/build/glibc/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/wcsmbs/mbrtowc.c:92: undefined reference to `__mbsinit'
<mjt> /stage/build/glibc/glibc-2.3.2.ds1/build-tree/i386-libc/wcsmbs/mbrtowc.op(.text+0x1a2): In function `__mbrtowc':
<mjt> /stage/build/glibc/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/wcsmbs/wcsmbsload.h:74: undefined reference to `_nl_C_LC_CTYPE'
<mjt> etc
<mjt> ;)
<pitti> mmm, that's your problem
<crimsun> mdz: question regarding libflac4 -> libflac6 if you have a moment
<mjt> (i just tried to build my program with one of the resulting .o files from glibc... ;)
<pitti> crimsun: btw, -686 packages with fixed XFS are up :-)
<mdz> crimsun: it's broken, and there is nothing I can do to fix it until elmo comes around again, I'm sorry
<crimsun> mdz: np, thanks.
<mdz> elmo: are you around?
<crimsun> pitti: awesome. I'll try 'em when I get home tonight (in a few hours).
<elmo> mdz: yeah?
<Keybuk> gah; whatever happened to mono-assemblies-base 1.0.4 ?
<mdz> elmo: I need flac 1.1.1-2 and evms 2.5.0-1 from queue/new to get into hoary
<mdz> elmo: and then upstream version freeze needs to happen
<elmo> gar, your as bad as jeff
<elmo> "fix MY packages, then let them eat FROZEN CAKE"
<elmo> ;P
<mdz> elmo: dude, I completely broke flac
<mdz> and we would have been fine, except that someone didn't do the freeze on the day it was scheduled :-P
<mdz> so the broken version came into hoary
<mjt> pitti: thanks for the suggestion.. i think i can go from there (a bit.. slow but that's something anyway)
<lamont> elmo: is there any easy way to pass a passphrase to gpg from a program?
<mdz> elmo: evms, well, as long as you're there...:-)
<lamont> Keybuk: see the bug
<Keybuk> lamont: #?
<mvo__> lamont: I think there is  "--passphrase-fd n"
<lamont> it's busted, they know it, and they'll upload working sources to debian when they have it built everywhere.  _then_ we can bootstrap it.
<lamont> Keybuk: looking
<elmo> what mvo said
<lamont> Keybuk: 5052
<elmo> mdz: done, but it won't hit debian till tomorrow now - shall I freeze now and let flac through when it hits Debian?
<mdz> lamont: what's "it"?
<lamont> short answer is that it's ftbfs, and when someone gives me a working source patch, I'll fix it.
<lamont> mono
<elmo> anyone got any experience with ipmi ?
<mdz> elmo: both debian and ubuntu users are harrassing me about flac; if it's not too much extra work, it would be nice to fix it at least for the Ubuntu users
<mdz> elmo: (yes, I know, my fuckup and all)
<crimsun> mdz: / elmo: many thanks.
<mako> mdz, anyone: http://mako.yukidoke.org/outgoing/test-dir/
#ubuntu-devel 2005-01-18
<mako> comments before i send this to thombot?
<mdz> mako: why are the install CDs bold, but not the live CD?
<mako> because you made them that way?
<mako> i think it's a plone stylsheet thing
<mako> because the tope ones are <dt> and the bottom one i just a link
<mako> i can bold the bottom one too
<crimsun> it might also be useful to succinctly note if the live cd differs from the installation cd
<mako> mdz: ok.. fixed
<mako> i think that looks quite nice actually :)
<mdz> mako: looks TOTALLY FRICKIN AWESOME
<pitti> mako: why is there only a link to the amd64 cd?
<mdz> mako: fwiw, I think you might be able to hand it to Kamion, if he comes around before thom
<mako> pitti: because that's not hte archive.. that's just a file i touched to make sure the directory index showed up and looked ok
<elmo> mdz: do you happen to have flac somewhere that has a Sources.gz ?
<pitti> mako: ah, ok
<elmo> if not, don't worry
<ogra> mako: nice page :)
<mako> ogra: most credit goes to mdz
<ogra> pitti: click it, its quite a small iso ;)
<mdz> elmo: I don't, but I could do it trivially
<mdz> mako,ogra: my design skills suck; all the credit goes to the plone CSS
<mako> mdz: seriously :)
<mako> mdz: that is a wonderful little tools i've used a few times
* mako coughs *shipit*
<ogra> heh
<elmo> mdz: doesn't matter - done
<ogra> mako: the jigdo link has two backslashes too much
<elmo> I've also disabled syncing for now - I'll fix it to still update MOM tomorrow
<mako> ogra: thanks
<mako> ogra: i was just about to send that off
<pitti> night everybody
<mdz> elmo: perfect, thanks
<mdz> pitti: night
<ogra> pitti:  night
<mdz> ogra: was your network interface detected on the live CD?
<ogra> yup, both :-D
<ogra> prism2 11mbit and a e100 onboard 
<amu> mdz: ethernet yes, ipw2200 no 
<mdz> ok, so this is a problem with the non-monolithic build
<mdz> it looks like busybox depmod is broken
<mjt> in what way it is broken?
<mjt> it does not look at /lib/modules/../modules.alias, and it does not handle *?[]  wildcards in aliases
<mjt> and it does not check if a module is already loaded... and it does not transform - into _ as module-init-tools depmod does.
<mjt> Anything else? ;)
<mjt> er
<mjt> s/depmod/modprobe/.  stupid /me ;)
<mjt> (i don't expect depmod in busybox to work at all)
<mdz> mjt: depmod
<mjt> yeah -- that's why i said i'm stupid ;)
<mdz> it doesn't seem to update the map files
<mjt> it does not know about them 
<mdz> at least not completely
<mjt> just avoid using it, use real depmod from m.i.t.
<mjt> ;)
<elmo> oh, that's cool, I don't need to do anything for the MOM stuff - it's already separate
<mdz> is it already part of the udeb?
<mjt> depmod?  Should it?
<mjt> i mean, there's no real need to use depmod "from" d-i, is it?
<mdz> how does it work presently?
<mdz> is depmod run ahead of time and placed in one of the udebs?
<mdz> (its output)
<mjt> no idea ;)
<mdz> in d-i, the modules are split up into many udebs
<mdz> I'm not sure where the modules.dep and friends come from
<mdz> gah, just discovered that the version of alsa-base on the image is missing the unmuting code
<mdz> particularly annoying for the live CD
<mdz> lamont: how are things on your front?
<chrisa> dato: heard from julian yet?
* chrisa feels silly
<mjt> mdz: i really dunno how it works now. but i think it's pretty simple to either get real depmod (there should be udeb for mit, as busybox module stuff is quite.. problematic on 2.6 kernel anyway), OR by providing partial modules.*map files in kernel udebs
<mdz> yes, there is a udeb
<mdz> I don't think it makes sense to try to provide partial ones and merge them
<mdz> I'm just wondering how this ever worked
<mjt> using discover to determine which modules to load?
<mjt> (instead of those .*map files)
<mdz> I mean now
<mdz> in hoary
<mdz> this has worked for me
<mdz> but on this test image, my ethernet driver isn't even listed in pcimap
<mjt> btw, now modules.*map files may be declared obsolete it seems, because of modules.alias which holds everything in *map files
<mjt> (and more)
<mdz> it does not hold everything in pcimap
<mdz> at least not in 2.6.10
<mjt> too bad i never ever installed debian or ubuntu (but use debian for several years now)
<jdub> elmo: ping
<jdub> hi all
<mjt> what's "everything" ?
<karim> where does dpkg stores wich file are on hold ?
<azeem> karim: that's a question for #ubuntu
<mdz> mjt: what's ambiguous about "everything"?
<mdz> there is information in pcimap which is not in modules.alias
<karim> azeem: that will not be answered there
<mjt> mdz: the last column you mean -- driver data?
<karim> unless you answer there :)
<elmo> jdub: ?
<jdub> elmo: anything in NEW atm?
<azeem> win25
<azeem> bah
<elmo> jdub: nope
<jdub> elmo: did you see ubuntu-calendar come through?
<mdz> the masks
<elmo> jdub: no, I pre-added all the months?
<jdub> for some reason, u-c didn't come through; u-c-j did though
<elmo> oh
<mjt> mdz: the masks ARE in modules.alias
<elmo> I'm spethial
<lifeless> elmo: hey there
* azeem looks up spethial
<elmo> jdub: sorry, I only did u-c-j; the "masssage into w-s from w-u" is stil lBYHAND
<mjt> mdz: "transformed" into *?[] -style wildcards
<elmo> lifeless: hey
<jdub> elmo: upload again?
<lifeless> you know that the admins address is bustified ?
<elmo> jdub: no, i'm doing the B YAND now
<jdub> elmo: ok, thanks :-)
<elmo> lifeless: it's kind of busted ;) but  yeah
<jdub> that'll make people happy
<lifeless> did you get my mail about davis ?
<lifeless> cause I'm gonna nag you about davis.
<jdub> changelog date for that package is like, 22nd or something ;)
<mdz> the class mask seems to be broken up into three fields
<mdz> this is so much less readable
<jdub> mdz: permission to upload new version of gamin? two fixes only
<mdz> and less parseable
<mdz> jdub: new upstream, you mean?
<jdub> mdz: yeah
<mdz> jdub: you read the diff?
<mdz> as long as you know what's going in, yeah, sure
<elmo> lifeless: yeah, I'm at the DC atm tho, and have to go in 15 mins - I'll look at it tomorrow tho
<elmo> spethial hotel I'm at wants something like 4UKP an hour for wireless too. freaks.
<lifeless> elmo: thanks! then I can resume ppc builds.
<mdz> daniels: I am still looking for you
<mjt> mdz: it's baseclass, subclass, interface (all 1-byte)
<mjt> mdz: for fnmatch() (which is used in modprobe), it's trivially parseable ;)  And trivially "expandable" from fields in /sys too.
* mvo__ is going to bed now
<ogra> n8
* lamont grabs debootstrap by the head and beats it against the wall repeatedly
<opi> :)
<opi> man, exchanging servers is a nice party ;)
<mjt> hell.  grep is spending 88% of time in mbrtowc(), inside scary auto-generated routine named __gconv_transform_utf8_internal() ...  Ugh.
<mjt> ...and ony 8% time in bmexec() -- which is the main re-execute loop
<jdub> mdz: the installability report for the cd - can we generate a report like that for any set of packages without a huge chunk of work?
<elmo> mjt: there's been a bunch of patches upstream to fix utf-8 and re speed regressions btw - I dunno what you're working off, but I thought I'd mention it
<mjt> upstream = glibc?
<mjt> mbrtowc() is glibc code
<mjt> (multi-byte to wide char it is)
<elmo> yeah
<elmo> the posts were probably from paolo bozinni (sp?, the sed guy)
<mjt> yeah, sed suffers badly from that prob too
<mjt> where's the glibc-devel (?) list?
<elmo> List-Archive: <http://sources.redhat.com/ml/libc-alpha/>
<mjt> aargs... i was afraid it's there... :(
<mjt> they've blocked access from our network to their server about half a year ago, and i *still* can't find anyone there who can explain what happened.
<mjt> Paolo Bonzini
<mjt> (going via an open proxy in .br ;(
<elmo> gotta go get a tube.. night all
<lamont> hrm.. 5410 inodes in the root that are not root:root.  so much for genext2fs, at least without mods.
<mjt> elmo: well.. yeah, there's quite some optimizations in regex stuff in glibc.  Too bad grep does not use that (or, rather, it performs its own optimizations).. and mbrtowc() implementation for utf8 hasn't changed (except of small bugfixes) in a long time...  Anyway, thanks for the pointer.
<mdz> jdub: yeah, should be simple to apply it to a given set of packages
<mdz> lamont: yeah, I thought I mentioned before, you're really going to need root
<lamont> mdz: yeah - trying to avoid requiring loopfs on the buildd machine
<mdz> I think it's unavoidable
<lamont> sparse files OK?
<mjt> why it's needed?  
<mdz> yeah
<mdz> sparse files are fine for loop
<mdz> you're just going to throw it away anyway, after compressing it
<mjt> "`genext2fs' is meant to generate an ext2 filesystem as a normal (non-root) user. It doesn't require you to mount the image file to copy files on it. It doesn't even require you to be the superuser to make device nodes."
<mdz> mjt: been there already
<mjt> heh
<lamont> ide drive performance sucks
<mjt> maybe fakeroot can help here?
<mdz> lamont: you're not doing this at the DC?
<lamont> atm I'm doing the script development at my house.
<lamont> because development is not done on the DC machines.
<lamont> root     26721 86.5 83.1 2001472 970020 pts/10 R+   17:20   5:28 genext2fs
* lamont giggles
<lamont> pitti?
<amu>  pitti moved to /dev/bed 
<lamont> mdz: did you want to know that flac_1.1.1-2 is ftbfs some places?
<mdz> lamont: yes
<lamont> bad assembly on ppc
<lamont> mdz: do you even want to try a genext2fs image?
<mdz> lamont: no
<mdz> I've been down this road
<lamont> ok..
<mdz> Keybuk: around?
<Keybuk> nope, asquare
<mdz> Keybuk: is bugzilla up to date as far as MOM is concerned?
<mdz> Keybuk: if so, it's time to turn off the bug filing bit
<Keybuk> uh, no; it crashed today (slight typo) ... want me to run it now?
<mdz> sure
<Keybuk> gah, elmo's broken lorraine *shocker*
<Keybuk> shall we just declare it up to date? :p
<Keybuk> whatever he did to turn off syncs, also broke the list of needing-merge packages
<mdz> odd, he said something about it before he left which sounded hopeful
<mdz> Jan 06 15:29:46 <elmo>  oh, that's cool, I don't need to do anything for the MOM stuff - it's already separate
<mdz> Keybuk: anyway, yeah, just draw a line in the sand
<Keybuk> when shall we draw the line?
<mdz> 'now' sounds about good
<lamont> mdz: on the + side, this doesn't build the entire FS in core.
<Keybuk> mdz: ok, no more bugs
<mdz> lamont: doing so isn't a half bad idea, for the DC machines ;-)
<mdz> Keybuk: thanks
<lamont> yeah - I only have 1.12GB in my machine.
<lamont> mdz: but _you_ can explain the lofs to elmo...
<mdz> lofs?
<lamont> loop
<lamont> lo fs.
<lamont> sorry
<lamont> you want the script, or the compressed image?
<mdz> right now? or for the ongoing process?
<mdz> I could use a compressed image right now
<mdz> going forward, it should go someplace where Kamion can get at it to do daily CD builds
<mdz> either way, the script can be your dirty little secret
<jdub> one of many
<mdz> jdub: dude, we are going to have a DVD with all of main + a live image for hoary
<mdz> for every arch
<lamont> mdz: and it defaults to live, or install?
<jdub> mdz: and massive torrent love ;-)
<lamont> right.  I still need to wrap a debian package around the beast, etc, etc
<mdz> lamont: the eternal question
<lamont> I'll get you the compressed image once I run the script in the DC>
<jdub> mdz: hrm, wonder how much dvds would cost to ship...
<lamont> overall 33%
<mdz> jdub: I have a feeling we'd come out ahead, compared to 2xCD
<mdz> less packaging, less weight
<mdz> more expensive media
<lamont> -rw-r--r--  1 root root 519336845 2005-01-06 18:00 livecd.cloop
<lamont> that gonna fit???
<mdz> wow, that's smaller than the one I have here
<mdz> but yeah, no problem at all
<mdz> I'd be grateful if you could give it some sanity checks before I download the beast
<mdz> chroot into it, make sure everything looks OK
<lamont> hrm.. wonder if this'll run in a chroot...
<jdub> ooh, i could actually run a livedvd
<jdub> mdz: could you install packages from the dvd when running the livedvd portion? that'd be rad ;)
<Kamion> mdz: um, depmod works just fine on the install CD
<Kamion> mdz: hw-detect calls it each time it's run, it's great
<Kamion> mdz: we already include both busybox-cvs and module-init-tools on the install CD's initrd ...
<Kamion> mdz: this is why I want you guys using the same initrd as the install CD :)
<mdz> jdub: absolutely
<mdz> Kamion: grep e1000 /lib/modules/`uname -r`/modules.pcimap turned up nothing
<Kamion> unfortunately I'm only here for about one more minute because I'm being harassed to go to bed :)
<mdz> though e1000.ko was in the module tree
<Kamion> check that module-init-tools-udeb is being unpacked after busybox-cvs-udeb
<mdz> how do I check that?
<Kamion> initrd build log, you can watch it
<mdz> oh
<Kamion> and the normal d-i initrd build process furthermore calls depmod itself
<mdz> I'm using the initrd that came on the CD
<mdz> and hacking it up
<mdz> not building one at all
<Kamion> that's more trouble than it's worth in the long run, in my experience
<Kamion> too error-prone
<mdz> Kamion: sure, but it needs to be called after new modules are unpacked
<Kamion> it is
<Kamion> 01:03 < Kamion> mdz: hw-detect calls it each time it's run, it's great
<mdz> but it isn't doing the right thing
<mdz> I called it by hand
<mdz> and the pcimap was still not up to date
<mdz> where does the m-i-t depmod end up?
<Kamion> if this were happening on the install CD, installs would not be working correctly
<mdz> I only see /sbin/depmod which points to busybox
<Kamion> it just overwrites the busybox one
<mdz> ok, then it's not in the initrd
<mdz> ohhh
<mdz> I unpacked a new busybox-cvs over it
<mdz> because I needed the new version
<mdz> that explains it
<Kamion> that would be it :)
<Kamion> right, build initrds the normal way and you won't have a problem. :)
<mdz> how long before my changes propagate into a d-i build?
<Kamion> daily-installer builds happen nightly, each one waits for byhand processing
<Kamion> elmo's usually pretty prompt with them
<Kamion> I've just changed the cdimage config to use daily-installer, it had temporarily been using the uploaded one
<Kamion> anyway, I really have to go now, back c. 9:30 UTC
<Kamion> I'll be doing a new proper build for 2.6.10 and rescue-check soonish anyway
<Kamion> tomorrow if all the required stuff is in main
* lamont screams
<lamont>   linux-386: Depends: linux-restricted-modules-386 but it is not going to be installed
<lamont> hoary ain't happy in the DC atm.
<mdz> generating a proper initrd will require a useful /dev and /proc in the chroot
<mdz> (assuming that's the issue)
<lamont> mkinitrd == bin/true
<lamont> this is purely dependency issues
<lamont>  linux-restricted-modules-2.6.10-1-386 doesn't exist in the archive, but linux-meta points there.
<mdz> oh, oops
* lamont wonders if it's a case of needing NEW love.
<mdz> no, I think it truly doesn't exist yet
<mdz> daniels was working on it, as I recall
<mdz> Jan 03 16:53:11 <daniels>       mdz: l-r-m is my first priority after xorg, so should be tomorrow by the time I've run it around all the buildds
<mdz> Jan 03 16:53:53 <daniels>       mdz: (i also have an engagement tonight, so losing a couple of hours off today, making it up tomorrow, so probably won't quite get to a new upstream l-r-m, especially as it needs patches for nvidia)
<mdz> jdub: it's a reasonable hour over there, right?  could you ring daniels for me?
* lamont builds locally, after killing/disabling the inflight gonna-break-things mirror
<lamont> worst case, I'll buz the neighbor's driveway to upload bits for you mdz
<mdz> lamont: as a workaround, you can install linux-{image,restricted-modules}-2.6.9-1-386 for now
<mdz> instead of linux-386
<lamont> linux-image-2.6.9-1-386 should depend restricted-modules?  or I need to install both?
<lamont> running with both
<mdz> you need to install both
<mdz> the linux-386 metapackage is there to tie image and restricted-modules together
<lamont> ah, ok
<mxpxpod> is there a reason after using a certain theme for a long time and trying to switch it, gnome-settings-daemon needs to be restarted to switch?
<lamont> mdz: scp chinstrap:~lamont/livecd.sh for giggles/gagging
<lamont> mdz: there's still a little cruft left in it, and a lot of commenting needed
<lamont> and yes, 99% of the steps require root, so the whole script does. :-()
* lamont fixes dbus
<lamont> Keybuk: about?
<jdub> mdz: ok
<jdub> mdz: moby's off
<azeem> lamont: I'm not sure what it meant, but he 'bounced upstairs' three hours ago
<mdz> jdub: pardon?
<jdub> mdz: his mobile is off
<mdz> hmm
<mdz> any other number to try?
<jdub> nup
<lamont> any udevd literate folks here?
<mdz> yes
<lamont> why does it start in the DC when I debootstrap it, but not on my home machine, even in a chroot?
<lamont> it's not running outside the chroot in the DC either, if that means anything
<mdz> I wouldn't expect it to start in either case
<lamont> I _suppose_ I could see if it was running before I start, and then kill it if it wasn't...  But that's just plain _UGLY_
<mdz> assuming you're disabling init scripts
<lamont> yeah - well, it did.
<lamont> debootstrap
<lamont> what does /sbin/udevstart do?
<mdz> starts udevd and processes events
<mdz> creates initial device nodes
<lamont> it seems to be invoked directly from the udev postinst
<Keybuk> lamont: yeah
<mdz> ick
<mdz> probably want to divert that, then
<lamont> Keybuk: I need to make udev's postinst not start udevd... is that easy?
<lamont> divert --> remove from debootstrap, add to the apt-get. blech
<Keybuk> it doesn't, does it?
<mdz> it didn't used to, but now it does
<mdz> maybe_run_udevstart() {
<mdz>   [ -e /dev/run-udevstart ]  || return 0
<mdz> lamont: touch /dev/run-udevstart?
<Keybuk> udevstart != udevd
<mdz> er
<mdz> rm -f
<lamont> machine without udevd running (running warty, custom kernel, dc machine...), chroot'ed, debootstrapping a chroot inside that.
<mdz> Keybuk: doesn't running udevstart cause udevd to be started?
<Keybuk> mdz: no, udevstart runs udev directly
<lamont> udevd winds up owning chroot/chroot/dev, and things get sicker from there
<Keybuk> udevd gets started on the first event that doesn't happen through udevstart
<Keybuk> (at least that's how it was a couple of weeks ago)
<lamont> I can't imagine any events for udevd in the DC machine...
<lamont> Keybuk: I need to wind up with udev installed, but not actually _doing_ anything until the _NEXT_ reboot... is painful?
<lamont> mdz: I think the 'see if it's running and kill it afterwards if it wasn't' trick is starting to sound more sane...
<mdz> Keybuk: nothing should be triggering events within the chroot, surely
<mdz> lamont: anything a good fuser -mk wouldn't cure?
<Keybuk> only udevsend will start udevd
<Keybuk> are you sure it's not just running from before?
<Keybuk> UDEV_NO_UDEVD=1  ... does that help?
<zul> i know i probably asked this already at one point but for the merge bugs in bugzilla what do you need to be attached to the bug for it to be accepted?
<lamont> mdz: sounds like it could./
<lamont> mdz: we'll see how fuser -mk does in just a couple of minutes
<daniels> fabbione: still haven't got my phone back :\
<lamont> daniels: they still found you, eh?
<daniels> mdz: consider me found.  connection has been utterly shitty, so I went to uni to attempt to find connectivity there, but I can't SSH out any more.
<daniels> yeah, I've got l-r-m 2.6.10
<daniels> it's here and I think it's good to go, just needs another quick build test across all architectures
<daniels> 2.6.10 broke a few things :\
* lamont ponders the sudden disappearance of the DC machine where he was building...
<daniels> fabbione: any news on xorg/sparc?
<daniels> fabbione: oh, GO.  thanks.
* daniels respins with the ia64 fix.
<lamont> mdz: so, once this finishes here, I'll run the image down the street and upload it for you...
<lamont> I'm disinclined to see if I can crash a second machine in the DC...
<lamont> mind you, I don't _KNOW_ that's it...
<daniels> FUCK ME
<daniels> MJG59
<daniels>         - DRI suspend/resume support
<daniels>         - Detection of monitor changes on VT switches
<daniels>         - Support custom video modes if available in the Video BIOS
* lamont wonders if highlighting is case sensitive...
<daniels> mjg59: tungsten just made i810 LOVE
<lamont> mdz: on the end system, do the cdrom's fs size and numinodes matter?
<lamont> -rw-r--r--  1 root   root    519336845 2005-01-06 18:00 livecd.cloop
<lamont> bbiab
<daniels> lamont: you didn't notice that xorg was ftbfs on ia64?  surely this is the lamont of legend?
<lamont> daniels: don't even go there.
<mdz> daniels: does this batch of Xorg stuff also have what I need for the live CD?
<lamont> daniels: I didn't get any email, you see...
<mdz> lamont: end system?
<lamont> liveCD as it finally shows up for the user
<lamont> that is, livecd.cloop is the start of that filesystem, do we care what it's size/numinodes is?
<lamont> are, even
<mdz> it should be as small as possible while still containing everything we want
<mdz> the absolute upper bound is about 620M or so
<mdz> but that would leave no room for the opencd stuff at all
<mdz> doesn't matter how many inodes it has
<mdz> er
<lamont> it's currently a 1500000*1024 byte file, with default numinodes.
<mdz> are you talking about the compressed size or the uncompressed size?
<mdz> ah, uncompressed
<lamont> uncompressed
<mdz> the entire desktop system fit in 1.5 gigs?
<lamont> compressed is 519MB
<lamont> 1.43Gb
<mdz> that's odd
<mdz> last I checked, it was more like 1.8
<lamont> ls -ls livecd.fsimg 
<lamont> 1463952 -rw-r--r--  1 lamont lamont 1536001024 2005-01-06 17:45 livecd.fsimg
<mdz> how much free space on it?
<lamont> /dev/loop0             1476384   1438916         0 100% /home/lamont/chroots/a/livecd.mnt
<mdz> ok
<mdz> bump it up to an even 2G to leave some space to breathe
<lamont> having it full kinda hurts towards the ends.
<daniels> mdz: not quite.
<lamont> yeah, will do that as I pretty things up
<lamont> but I'm gonna go upload this image now.
<daniels> mdz: i've been doing the sync from debian + outstanding patch sweep for xorg plus a couple of other fixes, and l-r-m after that
<daniels> mdz: but i'm wandering one day into the weekend, so i still have time to check it out this week
<lamont> daniels: let me know when you upload l-r-m, eh?
<mdz> I'm not sure that image will even boot
<daniels> mdz: i'm expecting to do an upload next week with all the i8xx love, so we can finally support widescreen laptops properly
<lamont> mdz: ah, so no point in uploading?  it's cold outside, you see...
<mdz> lamont: no point
<lamont> ok
<mdz> lamont: I would like an updated image, but can't you build it at the DC?
<daniels> mdz: if you export XORGFORCEPROBE (or whatever it is) and run dpkg-reconfigure -pcritical xserver-xorg, you should get a decent approximation of what you want
<mdz> or does that need admin hands?
<mdz> daniels: I don't
<daniels> mdz: arse
<daniels> mdz: i'll take a look at tonight/tomorrow
<daniels> mdz: could I also please get an exemption from UVF for lrm?
<daniels> mdz: i'm sitting on a beta of fglrx now with xorg, amd64, and proper pcie support
<daniels> as well as a hojillion bugfixes
<crimsun> mdz: out of curiosity, the flac 1.1.1-2 packages in incoming requires all packages to be rebuilt against the new libflac-dev, correct?
<mdz> daniels: l-r-m is a breakage that needs to be fixed
<mdz> crimsun: requires in what way?
<crimsun> mdz: I have a libFLAC++.so.4 and a libFLAC.so.6 (and their corresponding dev symlinks). Thus the packages that rely on the existence of libFLAC.so.4 need to be recompiled?
<crimsun> (e.g., the soname bump for the C++ wrapper makes sense; I'm just trying to ensure I'm not missing any strange symlinks)
<mdz> oh, I see what you mean
<mdz> normally, this wouldn't be a problem, except for the mistake
<mdz> so there is no valid libflac4 package anymore
<mdz> so yes, everything needs to be recompiled
<crimsun> gotcha, thanks muchly.
<daniels> mdz: yes.  i have 2.6.10-1 now pretty much ready to go and will upload that very soon, but after that there's a new fglrx (i.e. 2.6.10.1-1)
<daniels> mdz: so we'll have lrm 2.6.10 today, but i can't release new fglrx until next week or such
<mdz> daniels: what bugs does the new fglrx fix?
<daniels> mdz: a) lack of amd64 support, b) lack of xorg support (i.e. complete no-go for hoary), c) many rendering issues (i.e. random polygons, crashes, and random misshapen textures) in a fair few games, e) adds support for pci express cards
<stub> I need to get postgresql-contrib moved to main for hoary. We are using it internally in launchpad for full text indexing.
<daniels> mdz: unfortunately, being binary, i don't have total visibility into the driver, but from what I've seen of the feedback on the list so far, it seems to be quite solid and far more reliable than the old
<lamont> mdz: of course, the image would be bigger if I didn't 'apt-get clean' before building it... :-)
<mdz> daniels: lack of l-r-m 2.6.10 is blocking lamont's work on building live cd stuff, so be sure to get it in today
<usual> hi
<daniels> mdz: understood
* zenrox streaks acroos the network
<lamont> mdz: btw, places I see with hardcoded hostname: /etc/hostname, /etc/mailname, /etc/postfix/main.cf
<lamont> and resolv.conf is kinda custom
<mdz> lamont: hostname will be taken care of by d-i
<mdz> mailname and main.cf, ick
<mdz> resolv.conf gets fixed up for us too
<lamont> base-installer does a dpkg-reconfigure of postfix, iirc.
<mdz> we want this image to be as vanilla/unconfigured as possible
<lamont> but Kamion knows for sure
<mdz> we don't use base-installer in the live cd
<mdz> so probably I need to emulate that
<lamont> I know - meant for the logic
<mdz> Kamion: ^^^ when you're back
* lamont codes things up so the filesystem is created 1.2x the output from 'du'
<lamont> for meta data and such
<mdz> lamont: how much free space does that leave?
<mdz> should be at least a few hundred meg
<lamont> that was the question I had earlier - they do inherit what we gave them, then?
<lamont> so leaving them with 20 inodes or so would be unreasonable, I expect...
<lamont> should we go with 10000 inodes, 700MB (free, in both cases)?
<lamont> or closer to 400MB?
* daniels feels his DSL line creaking.
<daniels> new lrm orig tarballs are nasty.
<lamont> mdz: livecd also has to force a paper selection based on locale, I expect.
<mdz> lamont: leave the default inodes, say 400MB free
<mdz> I don't think many folks have enough RAM to make use of more
<mdz> I wouldn't mess with the inodes
<lamont> it used 77000 of the 180000 inodes that the default gave it... I'm inclined to shrink it just to see how much we save - that build is just about to the point of compressing the fs
<lamont> inum calc was easier than the size calc anyway...
<lamont> SZ=$(python -c "print int($(du -sk $ROOT|sed 's/[^0-9] .*$//')*1.1+$USZ)")
<lamont> INUM=$(python -c "print $(find ${ROOT} | wc -l)+$UINUM")
<lamont> hrm.. then again, 10000 inodes and 400MB is 40KB/inode
<lamont> -rw-r--r--   1 root   lamont  524056539 2005-01-06 22:04 livecd.cloop
<lamont> that's with 10000 inodes and 400MB
* lamont runs it again with no change in inum
<daniels> shit
<daniels> elmo_away: can I please have linux-headers-2.6.10-* in concordia/davis chroots as a matter of urgency?
<lamont> daniels: I guess that means I can get some sleep, eh?
<lamont> daniels: fwiw, I'm not blocked on what I'm doing, but I am blocked on building usable images for mdz.
<lamont> and I almost have the script packaged
<lamont> then I _will_ be blocked on lrm
<daniels> lamont: yeah, lrm's just blocked on getting l-h-* installed
<daniels> lamont: and will be until elmo wakes up, so go get some sleep
<lamont> yeah
<lamont> gonna finish this measurement first
<daniels> measurement?
<lamont> effect of playing with numinodes on the root fs
<lamont> for the livecd
<lamont> [ 9]  Block#  6163 size  65536 ->     84 [compression ratio   0%, overall:  24%] 
<lamont> I love those
<lamont> daniels: if you run out of other things to work on... mpeg2dec dies with -lXt not found.
<fabbione> morning
<daniels> lamont: blegh, will check it out
<daniels> fabbione: hey dude
<fabbione> daniels: hey
<lamont> morning fabbione
<fabbione> sup?
<fabbione> hey lamont 
<sivang> fabbione: morning
<fabbione> morning sivang 
<lamont> daniels: europe's waking up.  clearly bedtime. :-)
<fabbione> lamont: did you talk with ggg?
<daniels> lamont: heh :) night dude, cheers
<sivang> lamont: I just didn't go to sleep.. :) bedtime for me also :)
<lamont> fabbione: willy was going to look at it - never heard back, but didn't poke either.
<fabbione> ok thanks
<lamont> quite possibly either ggg or willy is awake now
<lamont> willy last seen 15 ago, pestering him
<fabbione> The changelog says we are creating 2.6.10, but I thought the version is 2.6.10-1-32
<fabbione> lamont: i think i need also kernel-package from ubuntu
* lamont scratches his head.  starting fs is 20MB bigger, but the compressed one is 500kb smaller.
<lamont> obviously noise.
<lamont> mdz: they can have all their inodes
<lamont> Free blocks:              487299
<lamont> Free inodes:              247797
<lamont> sounds about right. :-)
<lamont> and ~525 MB total size
<lamont> fabbione: in the chroot, yes?
<fabbione> ogra: i think i understand the bug noe
<daniels> agh, once again the house is devoid of food
<fabbione> lamont: yes
* lamont installs wget as well
<fabbione> that error message is something coming from it
<fabbione> daniels: did you read my message yesteday?
<daniels> fabbione: xorg is go on sparc?
<daniels> fabbione: i just caught an important message about horizsync/vertrefresh options being busted when we did choose to write them out
<daniels> fabbione: so i'm running around again
<lamont> fabbione: hoary kernel-package installed
<fabbione> daniels: yes. it is GO on sparc
<fabbione> lamont: thanks
<fabbione> lamont: testing now
<daniels> fabbione: btw, look up -- alanh/keithw just committed sweet i8xx stuff to cvs, so we don't need 855wrap/855resolution and all that crap now :D
<lamont> fabbione: well, the dpkg is _almost_ done. :-()
<fabbione> daniels: i am way behind on xorg mailing lists
<lamont> done
<fabbione> lamont: thanks..
<fabbione> no they didn't fix the I/O problem i
<fabbione> it will take at least a couple of hours to get there again
<daniels> fabbione: xorg-commit, alanh, today
<daniels> fabbione: ignore xorg@, it's crap
<fabbione> daniels: ENOTIME
<daniels> fabbione: yeah
<daniels> fair enough
<fabbione> lkml is now my bitching ml
<fabbione> over 300 mss/day
<fabbione> it's insane
<daniels> sheez
<daniels> sounds dire
<fabbione> [PATCH]  ALPS touchpad detection fix
<fabbione> uhuh
<fabbione> it's a one liner :-)
<daniels> could you please bounce it to me?
<daniels> anything that touches psmouse needs SERIOUS testing
<daniels> triply so if it's alps
<daniels> which, last I checked, grabbed a few IBM TrackPoints and random PS/2 mice as being ALPS :\
<daniels> as well as most every Synaptics device, ALPS or not
<fabbione> on the way
<daniels> cheers
<daniels> back in a few, grabbing the bus to the supermarket to acquire food (not eaten yet today)
<jdub> http://blogs.sun.com/roller/resources/eschrock/halcyon.png
<jdub> worst time to be sick -> summer in sydney :|
<sivang> jdub: you poor thing..go get some timtams and tea! :)
<jdub> oof
* sivang is _crazy_ about timtams
<sivang> jdub: is it ever winter in sydney ?
<jdub> yeah
<jdub> our seasons are very different
<sivang> jdub: I see, does it switch nicely comparing to our seasons?
<sivang> I mean, when it's winter for me, summer for you and the other way around?
<jdub> yes
<sivang> jdub: cool :-)
<daniels> mmm, food
<daniels> jdub: xsun is very quick.  we can get the X server starting blindingly quickly on proper hardware (e.g. Radeons, nVidias -- most everything except i8xx).
<sladen> daniels: I'm wondering if to a certain point that can be disguised.  How much of the setup delay is detection before any of the registers are actually changed?
<daniels> sladen: not much -- that part is pretty quick, except we're now slamming /proc with about 15,000 opens
<daniels> that's a bit of a cpu load, so i'm looking to optimise that
<sladen> errrrrm  ?
<sladen> why's it hitting /proc, is X not content with holding /dev/mem open?
<daniels> sladen: probing /proc/pci
<daniels> but instead of using readdir(), it attempts to open every possible combination of bus/device/subdevice
<sladen> duuuuude...
<daniels> yes, I know
<daniels> it's in 6.8 branch
<daniels> it fixes a problem with pci domains, to be fair
<daniels> but yeah, I have plans to fix it
<daniels> but not right now
<jdub> thom: hrm, think i have libgecko-cil love with firefox
<abelli> pitti: ding
<pitti> Morning abelli
<pitti> morning all
<abelli> ciao
<abelli> pax wont let xorg live: is it normal?
<daniels> abelli: yes
<abelli> ok..
<abelli> thank you
<Treenaks> abelli: send some money to daniels, I'm sure it'll get fixed
<daniels> heh
<daniels> unfortunately fixing that and using the nvidia/ati binary drivers are mutually exclusive
<Treenaks> let's send a million threatening letters to nvidia and ati!
<abelli> daniels: dont even mention nvidia please.
<daniels> yeah, because that's worked in the past to get us open-source drivers :P
<daniels> abelli: it's the main blocker with moving to a libdl-based loader (that and fglrx)
<Treenaks> daniels: no, but it makes us feel better.. venting frustrations etc. ;)
<daniels> heh
<Treenaks> daniels: btw, have you seen your "transmgr" picture?
<daniels> Treenaks: heh yes
<Treenaks> daniels: ok, I forgot :)
<pitti> ping daniels 
<daniels> someone saw it and asked if I'd put on weight
<daniels> it's not very flattering :P
<daniels> pitti: sure, give me a URL
<abelli> seb128: ciao
<daniels> seb128: yo
<daniels> seb128: do you still have the widescreen laptop?
<seb128> morning
<seb128> daniels: yep
<daniels> cool
<seb128> need some testing ?
<daniels> yep
<daniels> have a patch from CVS that should do away with the need for 855resolution or whatever
<daniels> so they should all work out of the box :)
<seb128> cool
<abelli> daniels: what do you think about some testing with _my_ laptop, and *my* nvidia? :)
<daniels> abelli: er?
<abelli> i think that just because i use nvidia, having a screen that looks like leerdammer, is not so fair
<daniels> 'leerdammer'?
<daniels> what's the exact problem you're having?
<Treenaks> abelli: it looks like cheese with lots of holes?
<Treenaks> abelli: or like a human from the small town of Leerdam? :P
<abelli> the first one
<abelli> :)
<daniels> abelli: ok ...
<abelli> abelli: what does it mean sorry?
<abelli> 1) ok ... no way i'll fix it
<abelli> 2) ok ... please shut up
<abelli> ?
<daniels> abelli: i don't know what you're describing, i would need a full bug report in order to fix it
<Treenaks> abelli: he probably wants more details :)
<abelli> Treenaks: he has seen it in mataro...
<seb128> abelli: I think that you need to describe the bug if you want a chance to get it fixed
<abelli> Treenaks: ...he said: <<No idea sorry>>... :)
<abelli> mine was just a try :)
<seb128> abelli: is it in bugzilla ? So many guys ping with bug, not easy to remember every single bug ...
<abelli> i don't know, i think that kinnison spotted it while using my laptop..
<abelli> ciao
<abelli> im off
<daniels> abelli: oh, you had *that* laptop
<abelli> in fact...
<daniels> i vaguely remember it
<daniels> i think it's a timing issue
<abelli> i said "_my_" laptop ;)
<daniels> well, yeah
<daniels> i got shown a lot of laptops with a lpt of problems at matar
<abelli> ahh..
<Treenaks> daniels: does your client mis-transcode, or mine?
<cartman> hmm xorg update still didn't make it to a.u.c
<cartman> Treenaks: using a unicode charset?
<fabbione> cartman: give the buildd the times to build it?
<cartman> fabbione: oh I thought prebuilt packages are sent by developers
<cartman> my bad
<fabbione> nope
<fabbione> it's not debian :-)
<cartman> sorry then
<Treenaks> cartman: I'm using UTF-8, but daniels' "" looks like he types UTF-8, that got converted to latin1, and THAT mis-converts back to UTF-8 and over the wire
<cartman> Treenaks: daniels I don't think daniels sent last msg as unicode
<Treenaks> cartman: I see ""
<cartman> right
<Treenaks> no.. 
<cartman> funny A+sup-2
<Treenaks> anyway, UTF-8 looks like that if you treat it as Latin1
<Treenaks> so if you then convert your "latin1" (which is actually utf-8) to UTF-8, it breaks :)
<cartman> U+C383 U+C2B3
<cartman> says my hex editor ;)
<daniels> Treenaks: mine, screen is broken
<daniels> matar
<daniels> much better
<cartman> yeah
<Treenaks> daniels: yay :)
<seb128> jdub: http://mail.gnome.org/archives/nautilus-list/2005-January/msg00012.html <- cool
<daniels> elmo: just the man I was looking for
<daniels> elmo: can I please get linux-headers-2.6.10-1-* on concordia and davis (hoary chroot), and libqt3-mt-dev, libxxf86misc-dev, libxxf86vm-dev, libxtst-dev, and libxinerama-dev on concordia's hoary chroot?
<elmo> didn't I do that already?
<lifeless> elmo: while you're doing chroot stuff...
<daniels> elmo: nope
<seb128> elmo: hey. Have you seen my sync requests 2 days ago ?
<daniels> elmo: i did get rman on halley and /dev/null unbroken though -- thanks
<elmo> seb128: err, possibly not sorry; I managed to kill my irc client at home - can you repeat?
<seb128> elmo: libbonobo gnome-gv gnome-pilot gnome-pilot-conduits ghfaxviewer
<seb128> thanks :)
<seb128> elmo: and easytag 1.99.2 from experimental too
<Treenaks> seb128: do you have any clue on the "panel stays empty"/"nautilus doesn't start" bugs yet?
<seb128> Treenaks: nop, gnomevfs guys are still in VAC
<seb128> elmo: and add glib2.0 and pango1.0 from experimental too and that should be enough for now :)
<seb128> thanks
<cartman> and fix flac package please
<elmo> seb128: done
<seb128> thank you :)
<elmo> cartman: they should be on archive.u.c by now
<lifeless> elmo: morning :)
<cartman> elmo hmm just updated not there. guess will take some more time.
<elmo> lifeless: I saw you
<lifeless> elmo: hehhe, I'll get outta your hair then.
<ogra> fabbione: great news !
<ogra> fabbione: anything i should do for you before rushing to the office ?
<fabbione> ogra: try to understand why the module is loaded -> unloaded and reloaded?
<fabbione> is there any point in the module being unloaded the first time?
<ogra> fabbione: not to my knowing.....
<fabbione> ok
<fabbione> i will need to add more debugging stuff
<ogra> fabbione: it should stay loaded...
<fabbione> because at the first load
<fabbione> the module automatically unloads
<elmo> daniels: done
<ogra> fabbione: probably its the load order
<fabbione> it shouldn't
<elmo> daniels: and I did do it, last time you didn't ask for linux-header-* is all, so I only installed the top level package
<daniels> elmo: thanks dude
<ogra> fabbione: i can experiment with that tonight and trace the module dependencys with modinfo
<fabbione> DEBUG: AVM Fritz: pnp_unregister_driver(&fcpnp_driver);
<fabbione> DEBUG: AVM Fritz: pci_unregister_driver(&fcpci_driver);
<daniels> elmo: ah ok, sorry
<fabbione> ogra: see.. it loads but later it unloads again
<ogra> fabbione: yup...
<fabbione> the error mostlikely is that the module does not de-register itself from mISDN core
<fabbione> and at the second load you can see the oops when it walks the device/module lists
<daniels> ARGH
<fabbione> meaning that the last entry hasn't been freed properly
<daniels> i'll be quite unhappy if the thing causing GL on original iMacs to lock up is the fix to prevent GL lockups on PC r128s
<lifeless> daniels: hahhah
<Treenaks> that'd suck
<ogra> fabbione: hmm...... buggy crap, i wish we could go with i4l
<fabbione> yeah
<Kamion> mdz: see netcfg's base-installer script
<fabbione> so let's build this bunch of other fixes for the kernel
<fabbione> at lesat.. let see if they actually build
* fabbione runs a buildd orgy or almost
<ogra> fabbione: i will dig the web a bit today to see if it is a workaround to run i4l instead until this really works
* ogra races to work.....
<sabdfl> daniels: do we have an ATI xorg driver nowadays?
<fabbione> sabdfl: do you mean the fglrx?
<cartman> libflac4 is still foobared
<cartman> trying to install /usr/lib/libFLAC.so.6.0.1
<elmo> cartman: what version of the package?
<daniels> sabdfl: yeah, it's in beta
<cartman> elmo libflac4_1.1.1-1_i386.deb
<elmo> cartman: install libflac6?
<elmo> that's the fixed version AIUI
<cartman> hmm
<cartman> dpkg: error processing /var/cache/apt/archives/libflac6_1.1.1-2_i386.deb (--unpack):
<cartman>  trying to overwrite `/usr/lib/libFLAC.so.6.0.1', which is also in package libflac4
<cartman> still buggy
<cartman> and still no libFLAC.so.4 installed needed by ogg123
<elmo> ogg123 will need rebuilt with the new lib
<cartman> what about the above error?
<elmo> that's a bug, you can work around it for now with --force-overwrite to dpkg
<cartman> ok
<elmo> cartman: can you file the overwrite thing in bugzilla, by the way, please?
<cartman> its more than that I guess
<elmo> hmm?  no, it really is just a file overwrite for the libflac4 thing, the rebuilds are a separate issue
<cartman> well ok
<sabdfl> daniels: is it easy to test with the current hoary xorg?
<daniels> sabdfl: i'm going to be doing some testing on my machine tonight -- unfortunately they're unredistributable while in beta
<cartman> daniels: nvidia drivers?
<cartman> or ati?
<daniels> cartman: ati
<cartman> okies
<cartman> elmo https://bugzilla.ubuntu.com/show_bug.cgi?id=5276
<elmo> cartman: thanks
<cartman> hope it gets fixed soon. no ogg123 no sound here :/
<cartman> daniels: when compiling kde/mplayer I got this
<cartman> /usr/X11R6/lib/libGL.a(glxcmds.o)(.text+0x2eea): In function `glXGetMscRateOML':
<cartman> : undefined reference to `XF86VidModeQueryVersion'
<cartman> rm /usr/X11R6/lib/libGL.a solves it but I think somehow nvidia-glx package is responsible for this mess
<Kamion> cartman: do you have libxxf86vm-dev installed?
<cartman> let me check
<cartman> nope
<cartman> some package is missing "depends" I guess?
<Kamion> no idea
<daniels> cartman: you need to link with -lXxf86vm
<daniels> nvidia-glx has a weap dep on libXxf86vm, it seems
<daniels> which totally sucks.
<Kamion> if kde/mplayer use XF86VidModeQueryVersion themselves, then they need to build-depend on libxxf86vm-dev
<cartman> problem on my side then
<daniels> Kamion: it's from libGL.a tho
<daniels> Kamion: which would be bizzare.  because Xxf86vm was static for the longest time, and still is by default.
<daniels> Kamion: so how it works is beyond me
<cartman> well nvidia-glx package has far more bugs with symlinks
<cartman> I should report them all
<cartman> is "restricted" supported?
<elmo> as far as possible, taking the license and lack of source into account
<cartman> well symlink bugs can be fixed without source ;)
<Kamion> restricted is supported, yes
<Kamion> (oh, elmo already answered that)
<daniels> cartman: what sort of symlink bugs?
<cartman> daniels: you end up with /usr/lib/libGL.so being a dangling symlink after installing nvidia-glx
<cartman> also /usr/X11R6/lib/modules/extensions/libglx.a needs to be manually symlinked to /usr/X11R6/lib/modules/extensions/libglx.so
<cartman> well looks like you already know those issues ( http://ubuntuforums.org/showthread.php?t=7906&highlight=nvidia+glx )
<trulux> pitti: i'm available now
<pitti> Hi trulux
<trulux> pitti: it would be great to have mostof things done today
<trulux> as the next Monday school starts for me and i will have really limited time
<pitti> sure, that'd be fine
<trulux> pitti: the TPE engine is now finished
<pitti> trulux: do you think you can prepare the ssp packages today?
<trulux> pitti: i don't like what i do at school, but before i leave this for do better things i will get the secondary school graduate
<pitti> trulux: hey, school is important
<trulux> and move outside Spain for continue my studies in place where i can really enjoy them
<pitti> trulux: more important than this stuff in any case
<trulux> yes, and that's what i mean when saying limited time ;)
<trulux> but Spain for example is not a good place for kernel hackers, here the situation is the worst of Europe, and i think i'm really enjoying low level development
<trulux> i haven't developed any GUI application since i use computers
<trulux> never known Glade, gtk, etc
<trulux> last two months i've started developing with C and the kernel, and i'm learning quickly, that's the thing that matters
<trulux> ok, back to our work
<trulux> first
<trulux> how's the situation of SELinux in ubuntu?
<pitti> you asked me this already two times :-)
<trulux> and, what about the SSP packages? we need to make a final decision on them
<trulux> pitti: maybe :(
<pitti> trulux: selinux: kernel support is there, no userspace support (userspace == sid)
<pitti> trulux: ssp: we already have a decision
<pitti> trulux: competely separate source pacakge for universe, gcc-3.4-ssp
<elmo> pitti: hey, don't forget my question about a way to detect SSP compiled binaries, at some point pls
<pitti> trulux: and it would be nice if it ships a binary gcc-3.4-ssp which already enables all necessary things
<trulux> pitti: i have set a sid development chroot, if i prepare packages for it, would you prepare them for Ubuntu?
<pitti> elmo: that's easy
<pitti> elmo: ldd | grep -ssp
<trulux> pitti: :)
<pitti> elmo: second, we only make source uploads to Ubuntu, so this should not be a problem anyway, right?
<trulux> pitti: better to call it gcc-hardened
<elmo> pitti: every binary gets linked to a SSP lib?
<pitti> trulux: -hardened is fine for me too
<pitti> elmo: yes
<mdz> morning
<trulux> pitti: ok then
<trulux> hey mdz
<pitti> Hi mdz!
<elmo> err, please don't call it hardened
<pitti> trulux: TIA! I look forward to see the packages
<elmo> the propaganda campaign doesn't need to extend to package names
<trulux> mdz: i have your doc: http://wiki.debian-hardened.org/Development_layout_organization
<elmo> please call it what it actually is
<pitti> -ssp says what it is probabl
<pitti> y
<trulux> pitti: ok, today i'm a bit sleepy, i just slept 3 hours, i was testing the TPE all the night
<pitti> mdz: we now have upstream freeze, right?
<mdz> pitti: yes
<trulux> elmo, what propaganda?
<pitti> mdz: today a new hal bugfix version 0.4.4 was released which fixes some segfaults and a regression in 0.4.3
<mdz> trulux: I don't know what that document is about
<pitti> mdz: the changelog is relatively small
<pitti> mdz: I can backport the patches or shall I just package the new upstream version (after auditign the diff)?
<mdz> pitti: http://www.ubuntulinux.org/wiki/UpstreamVersionFreeze
<mdz> Exceptions requiring confirmation:
<mdz>  Minor fixes, if the upstream change is a micro-increment (or equivalent)
<Kamion> trulux: "hardened" is essentially an advertising term, not a description of what it actually is :)
<trulux> mdz: is about the development layout i commented, the infrasctructure that needs to be done
<trulux> Kamion: hardened means a hardened toolchain, even hardened gentoo uses it and so on
<trulux> ;)
<pitti> mdz: exactly, point 2 seems to fit
<pitti> mdz: so I hereby ask for permission
<mdz> pitti: go for it
<pitti> okay, thanks
<trulux> pitti: so, what's your final decision? -ssp or -hardened?
<pitti> trulux: does it contain anything else apart from ssp by now?
<trulux> ssp would distract users of know about PIE and so on
<trulux> PIE
<trulux> comes by default in 3.4 but not in 3.3
<pitti> I thought PIE was just a consequence (or arequirement) of ssp
<trulux> it's not
<trulux> PIE is for PaX ASLR
<trulux> not for ssp
<pitti> pie itself is not a security feature IIRC
<pitti> oh right
<pitti> but still, it is a means to support a feature, not a sec feature itself
<trulux> PIE is used as a security feature
<trulux> developed as it
<pitti> trulux: since this is meant to be an experimental package only, -ssp is fine for me
<trulux> let me try to bring here psm
<mdz> trulux: what I asked for was a document describing what resources you needed in order to do a proof-of-concept derivative of Ubuntu using SSP, and what you are showing me is a document which describes the CVS repository layout for debian-hardened
<mdz> I don't understand
<mjg59> daniels: Oh, rock
<mjg59> Can you get that into Hoary?
<trulux> mdz: ok, let me write a section about it
<pitti> trulux: just write a plain ASCII file, which only contains the necessary resources
<trulux> mdz: i just have a server specs doc for a sponsorship that is going to start (with Tek, they sponsor Gentoo)
<trulux> pitti: ok
<pitti> trulux: i. e. separate archive, buildd support, modified toolchain in the buildd (-ssp), etc.
<mdz> pitti is on the right track
<pitti> trulux: also, team structure
<pitti> trulux: who is responsible for what, future plans (eventual merge into Hoary+1 if successful, etc.)
<psm> hello all, what are the questions about pie?
<pitti> psm: PIE itself is no security feature right?
<pitti> psm: as far as I understood it supports PaX memory randomization and stuff
<psm> PIE is like a shared lib, loadable to any address
<pitti> right
<mdz> Kamion: did you receive my email with casper?
<psm> if the addresses are randomized, you'll get it loaded each time at diff addresses
<pitti> psm: this is PaX ASLR
<psm> for ex
<pitti> Morning carlos!
<Kamion> mdz: no
<mvo_> hi carlos 
<psm> the randomization can be done in kernel (PAX does it), or ld.so could be used prob for that
<carlos> morning
<zul> morning pitti
<pitti> Hi zul
<mdz> Kamion: wtf
<mdz> you didn't get the last one either
<mdz> sending you a test mail
<Kamion> mdz: where was it sent to?
<mdz> Kamion: cjwatson@canonical
<Kamion> bleh, it got spam-trapped?!
<pitti> carlos: right now we agreed to the ZIP structure <LANG>/<DOMAIN>.mo, right?
<Kamion> hold on, I have it
<pitti> carlos: would it be any more difficult for you to change that to <LANG>/LC_MESSAGES/<DOMAIN>.mo ?
<pitti> carlos: then it would already have the final structure
<Kamion> opening that mail folder is a bit of a challenge, that's all ...
<mdz> Kamion: anything else from me in there? :-P
<Kamion> -rw-------    1 cjwatson cjwatson 1196359985 Jan  7 11:55 mail/spam
<Kamion> I'll tell you in a bit :P
<carlos> pitti: will do it that way
<pitti> carlos: if it does not make the job harder for rosetta?
<mdz> -rw-rw----  1 mdz mdz 45930357 2005-01-07 03:37 /home/mdz/mail/incoming/spam
<mdz> you win
<mdz> that goes back to Dec 17
<carlos> pitti: for me it's the same one directory than two or three
<pitti> carlos: okay, thanks
<carlos> np
<pitti> carlos: with this new structure I don't need to rearrange the files at all
<trulux> mdz: done, can i dcc it to you?
<fabbione> mdz: already awake?
<pitti> fabbione: I'd rather call it 'still' :-)
<Kamion> mdz: four mails from you in that folder, going back a while
<fabbione> ehhe
<mdz> fabbione: I'm not sure whether I'm awake already or if I haven't slept yet
<mdz> trulux: please put it in the Ubuntu wiki
<Kamion> to which I say, wtf?
<fabbione> mdz: pick one :-)
<mdz> Kamion: hmm, I have some vague recollection of you not receiving a mail from me in the past few months
<trulux> mdz: ok
<Kamion> Subject: ubuntu-meta
<Kamion> mdz: apparently caused by overenthusiastic filtering of certain types of binary attachments
<mdz> Kamion: you're not using spamassassin, are you?
<Kamion> I am, but the binary attachment thing was manual to try to avoid being buried under Klez
<Kamion> sorry about that
<fabbione> daniels: still around?
* Kamion barfs all over anaconda
<Kamion> the kickstart stuff is vile
<Treenaks> bile as well now 8)
<trulux> mdz: https://www.ubuntulinux.org/wiki/HardeningNeededResources
<trulux> btw
<trulux> if someone wants to fall back to 2.4 for SELinux, now you have SELinux for 2.4
<trulux> ;)
<Treenaks> *shudder*
<daniels> fabbione: wassup
<daniels> mjg59: yes, it will be in hoary
<fabbione> daniels: there is a big bunch of drm updates for 2.6.11
<fabbione> should we pull them in?
<daniels> fabbione: yep!
<daniels> and i have some more drm stuff for i915
<daniels> i'll forward it to you
<fabbione> daniels: no need to..
<fabbione> i will grab what is in bk
<fabbione> if it is not upstream is no no :-)
<thom> mdz: hrrm. there are other cases where the filesystems are unconditionally not checked
<mdz> thom: really?
<thom> mdz: yes
<thom> if you have /fastboot
<thom> as a file, then no checks are run
<mdz> ah, right
<mdz> thom: did you get with mako about the directory index stuff?
<mdz> +AC_CHECK_PROGS(GAS, gas)
<mdz> [...] 
<mdz> +# funniest. macro. ever.
<mdz> +AC_DEFINE(FLAC__HAS_GAS)
<thom> mdz: um?
<Treenaks> 8)
<mdz> thom: for the CD image downloads
<mdz> back about 8 hours or so
<Kamion> mdz: wow, that's an *amazing* hack :)
<mdz> thom: he sent you an email too
<mdz> two of them
<mvo_> ping doko_ 
<thom> mdz: you can take that as a no - i have no mail from mako today
<elmo> joii why is he sending it to thom?
<mjg59> daniels: Rock
<mdz> thom: hmmmm
<Kamion> mdz: while there are obviously improvements I can think of, I'm satisfied it won't break regular d-i as it stands, so if that's all I can upload it as-is
<mdz> never mind
<mdz> he sent it to admins@admins
<mdz> and mentioned it to thom on irc
<mdz> so it's sitting in the vacuum of admins@ somewhere :-P
<Kamion> he sent directory index stuff to me
<mdz> CCed
<Kamion> for releases
<Kamion> I'm the right person to do that anyway, probably, I'll take care of it
<mdz> yeah, I wasn't sure if you could do that without admin intervention, so I recommended he ping you as well
<Kamion> think I can, we'll see
<mdz> Kamion: since I'm awake anyway, shall I go ahead and seed+upload casper?
<Kamion> go for it
* mdz wonders in what strange and wonderful ways the seed repository will break today
<mdz> it's a bit annoying that gnupg hassles me to update-trustdb when all I've imported are new signatures on my own key
<mdz> I'm fairly certain that no exciting new trust paths are established by those
<fabbione> daniels: in any case.. -5 stuff
<thom> mdz: the case you suggest for fsck would require each individual fsck to learn how to check for being on ac, i think
<Kamion> elmo: if I could have rescue-{check,mode}, casper-{check,udeb}, and the 2.6.10 udebs in main, I can do new d-i with all of this stuff ...
<thom> or the fsck wrapper, certainly
<mdz> thom: I was thinking that the fsck wrapper would pass a flag to them saying "don't do anything stupid"
<daniels> fabbione: yeah, that's cool
<kent> seb128, are you there?
<daniels> fabbione: btw, the stuff in xorg is newer than bk
<mdz> thom: I say post something to ubuntu-devel and see what folk think about the way it works now
<mdz> thom: maybe I'm just paranoid
<mdz> thom: on_ac_power is guaranteed not to do anything stupid on a server, right?
<seb128> kent: yes
<Kamion> mdz: netcfg's the only useful thing in base-installer.d AFAIK; maybe we could invent a casper.d which casper-udeb runs?
<mdz> Kamion: the notion of having gobs of other udebs knowing about casper isn't very appealing
<Kamion> I like that notion, actually
<Kamion> it's a lot better than casper knowing about the internals of gobs of other udebs, which is what we have now
<mdz> Kamion: I was thinking that prebaseconfig.d could be broken up
<thom> mdz: yes.
<Kamion> nah, that's casper.d :)
<mdz> into bits which do crazy things, and bits which don't do crazy things
<kent> seb128, well.. i was just going to ask if it was gnome-applets i should report the bug against the weather applet, but i saw that it must be that.. :) 
<Kamion> that affects the install CD in much more invasive ways
<Kamion> and is scary because prebaseconfig.d is dealt with by lots of udebs
<Kamion> and it's by no means guaranteed that more stuff won't be added to prebaseconfig.d
<seb128> kent: yep
<mdz> Kamion: who expands the Kernel-Version in the installer seed, germinate?
<Kamion> yep
<Kamion> I got bored of having to substitute 2.6.8.1 with 2.6.9 a thousand times
<mdz> Kamion: anything you noticed which ought to work differently and wasn't already marked with a scary comment?
<kent> seb128, https://bugzilla.ubuntu.com/show_bug.cgi?id=5281   :)
<fabbione> mdz:   [PATCH]  convert Linux to 4-level page tables
<fabbione> interested?
<mdz> fabbione: we're still pre-feature-freeze, if you think it's supportable
<fabbione> no s*!t
<Kamion> mdz: I wondered about using /dev/ram0; doesn't the installer already use that for its own ramdisk?
<fabbione> i have not even idea of what it is after reading a few tons of documentation stuff
<fabbione> it reorders all the VM in more layer
<mdz> Kamion: apparently not; I didn't think the installer used a ramdisk apart from the initrd
<mjg59> daniels: So the custom video mode stuff means we don't need 855resolution?
<fabbione> no way i will understand that in 20 years from now ;)
<Kamion> that's what I meant, the initrd
<mdz> fabbione: ok, let's not backport major new features that we don't understand, ok? ;-)
<Kamion> "newer kernels use /dev/ram0 for the initrd" <- Documentation/devices.txt
<mdz> fascinating
<mdz> gah, nightly backup is running
<mdz> Kamion: I think d-i actually copies itself into a tmpfs
<Kamion> mdz: the /dev/vc stuff is a bit nightmarish, hopefully that'll go away when we eventually switch the installer to non-devfs paths
<Kamion> mdz: oh, so it does, good point
<Kamion> yes, and it umounts the initrd afterwards, so you're ok
<mdz> Kamion: we still need to find a clever way to let us unmount the d-i tmpfs
<Kamion> mdz: other than that I think you had a sufficiency of scary comments to cover my concerns :)
<pitti> daniels: still here?
<Kamion> mdz: what's still open on it?
<jdub> seb128: that sounds pretty rad :-)
<mdz> Kamion: the new root filesystem is a device-mapper device, one of whose components is a cloop device which is attached to a file on the cdrom, which is mounted under the tmpfs :-)
<mjg59> fabbione: The only big advantage from an end-user point of view is that 64 bit architectures get more addressible physical RAM
<Kamion> mount --move the cdrom?
<mdz> ooh, didn't know about that
<mjg59> So I wouldn't worry too much
<mdz> sounds like exactly what I need
<fabbione> mjg59: i am not ... reallyt
<Kamion> assuming that busybox mount implements --move
<Kamion> doesn't look like it, but should be a small addition
<mdz> doesn't have to
<mdz> we have real mount by that time
<Kamion> true
<mdz> Kamion: what were you saying about base-installer.d?
<daniels> pitti: yo, sup
<daniels> mjg59: afaict, yes
<mjg59> daniels: That makes life unbelievably easier.
<daniels> mjg59: shit yes
<Kamion> mdz: netcfg is the only thing that uses it, and it could easily just declare that it needs to be used by casper too
<mdz> Kamion: will you add casper-check to your next d-i upload?
<Kamion> yes, once it's in main
<mjg59> daniels: How long until packages with that are available?
<daniels> mjg59: will do it this weekend, so probably packages this weekend, hoary next week
<mjg59> 1337
<Kamion> http://releases.ubuntu.com/warty/ updated
<Kamion> looks much nicer
<crimsun> pitti: 2.6.10-hardened-1-686-smp works great :)
<daniels> mjg59: it's because i am shit hot
<mdz> Kamion: looks good, thanks
<daniels> Kamion: nice :)
<pitti> crimsun: cool
<pitti> crimsun: did you use the linux-hardened-support package?
<pitti> crimsun: I uploaded version 2 this morning which fixes chpax'ing
<crimsun> pitti: and chpax, too.
<pitti> crimsun: does framebuffer work for you?
<crimsun> pitti: haven't tested; using X Windows atm
<pitti> crimsun: you saw boot messages? do you boot with text console or fb?
<elmo> Error trying to open /dev/hda exclusively (Device or resource busy)... retrying in 1 second.
<elmo> duh
<crimsun> pitti: text
<pitti> elmo: is that cdrecord?
<elmo> yeah
<mdz> Kamion: we may want to make the ramdisks larger, too
<elmo> nautlius isn't burning valid CDs for me :(
<fabbione> elmo: get ready for another travel to the dc :-)))
<elmo> fabbione: I'm AT the DC
<elmo> (look at my IP)
<fabbione> ok :-)
* Kamion hugs the existence of shlex
<elmo> pitti: how do I get this stupid thing (cdrecord) to not try and gain control of the drive with my root partition on?
<pitti> elmo: it doesn't, because it cannot exclusively open it anyway
<pitti> elmo: but why do you try burning to /dev/hda in the first place?
<elmo> I'm not, I'm trying to run -scanbus
<elmo> I'm not quite that stupid; but I'm touched by your confidence in me
<pitti> elmo: sorry
<pitti> elmo: however, I think this -scanbus bug was fixed in Hoary
<mdz> don't run -scanbus, then
<pitti> elmo: it's only a cosmetic issue, though
<pitti> elmo: older versions also touched hda during scanning, so your version is actually better
<elmo> mdz: and figure out the archaic rune for my cdrom, how? :P
<mdz> elmo: archaic rune?
<mdz> elmo: dev=/dev/cdrom
<pitti> elmo: the hda scanning should time out after 10 seconds, and hda will not be touched
<elmo> I thought it had to be ATA:2034,3224,3841 or something
<mdz> elmo: they fixed that in like 1990
<mdz> it prints this obnoxious pedantic shitbag complaint about it, but then it does what you ask
<mjg59> daniels: Does Hoary do the right thing with loading AGP and DRM modules?
<elmo> does nautlius' burning stuff log anywhere btw?
<daniels> mdz: UNINTENTIONAL, BE THANKFUL THIS WORKS YOU FOOL, ALL HAIL JRG
<daniels> hmm, weird
<daniels> JRG
<daniels> i hate screen
<Treenaks> daniels: Schilling?
<daniels> mjg59: yah
<pitti> daniels: the umlaut works fine if you meant that
<daniels> Treenaks: who else
<mjg59> daniels: Rocking
<daniels> pitti: really?  it renders weird here
<mdz> elmo: it has a debug flag in gconf which logs all the output from cdrecord/growisofs/mkisofs/whatnot
<pitti> daniels: I have /charset UTF-8, looks fine
<jdub> so you know that trash .desktop file i posted to u-d?
<jdub> it's sitting on my desktop
<pitti> daniels: something more:    
<Treenaks> daniels: well, there are 2 other Jrgs on planet debian at least
<jdub> and i loaded up the january calendar
<jdub> and it's IN HIS HAND
<mjg59> Haha
<daniels> ahr, much better.  but mine is still rendering like crap.
<daniels> 
<daniels> gah.
<lifeless> 
<Treenaks> daniels: looks fine here
* daniels kicks screen really hard.
<daniels> it renders fine in the status line, but then renders horribly in the main window
<Treenaks> daniels: I have it the other way around
<Treenaks> daniels: when I type it it looks f*cked, when I press ENTER it's OK
<Kamion> urgh, badly written documentation
<Kamion> "When posix is not true (default), the shlex instance will operate in compatibility mode."
<mvo_> mdz: what's our policy with merges that only require a sync from debian (because debian took the changes from us)? #3518 is such a case. do we sync them? or ignore the because of upstream-version-freeze
<Kamion> is that "not (true (default))" or "(not true) (default)"?
<elmo> kamion the latter
<mdz> mvo_: if the debian version doesn't contain other things that we don't want, a sync is fine
<elmo> Kamion: I guess
<Kamion> turns out it's the latter, but then they should say "false (default)"
<daniels> Kamion: i'd say the latter
<daniels> yeah
<mvo_> mdz: it's a new upstream version that was not synced automatically
<mdz> Kamion: where do you think I should move the CD to?
<daniels> mdz: l-r-m 2.6.10-1 uploading now
<mdz> Kamion: I was thinking /media/cdrom0, but there's no particular guarantee that it's cdrom0, or even a cdrom
<daniels> well, l-r-m-2.6.10 2.6.10-1
<mdz> daniels: thanks
<mvo_> elmo: can you please sync "scim"? all our changes are now in the debian package (merge bug #3518)
<mdz> lamont: ^^^
<elmo> [NOT Updating - Modified]  scim_0.9.7-1ubuntu1 (vs 1.0.1-4)
<elmo> mvo: ^-- that?
<Kamion> mdz: /media/live or something?
<mvo_> elmo: yes, all our changes are in the debian package now (only a missing build-depends)
<daniels> mdz: i live to give
<elmo> mvo: yeah, but look at the version numbers?
<mdz> mvo_: that's a universe package anyway
<mvo_> mdz: so we ignore it and leave it at 0.9.7-1ubuntu1?
<mdz> mvo_: yes, until the MOTU decide otherwise
<daniels> woh are the motu?
<lifeless> masters of..
<mvo_> mdz: what to do with the merge bug? just change it to "universe"?
* fabbione will bbl
<mdz> mvo_: it should already be severity: enhancement
<mvo_> yes. I'll just leave it alone then
<mdz> there was a time when MOM filed bugs about universe packages, but keybuk fixed it shortly thereafter
<mdz> the MOTU will need to get a complete list of pending universe merges
* daniels cheers his uplink on as it struggles with l-r-m.
<mvo_> how many MOTU do we have right now?
<daniels> lifeless: yeah, but who specifically ... like, the people
<daniels> i know what the concept of motu is :P
<mdz> Kamion: will you take care of adding an option to isolinux which sets casper/enable=true?
<Kamion> fabbione: in your next kernel upload, could you create an rtc-modules udeb that includes drivers/char/rtc.o?
<Kamion> I need it for the timezone question in the first stage
<elmo> fuck.  even burning with cdrecord didn't work.  what kind of freaks don't provide md5sums of iso's anyways
<kent> btw, i got a broken pipe when upgrading my Hoary recently.   /usr/lib/libFLAC.so.6.0.1 from libflac6 is also in libflac4 according to synaptic.
<jdub> http://www.livejournal.com/users/zabilcm/3490.html
<daniels> elmo: what are you trying to burn?
<Kamion> mdz: that would be on the live CD only, wouldn't it?
<elmo> daniels: latest Update Xpress CD
<elmo> IBM's "all in one" firmware/driver etc. update CD
<mdz> Kamion: the live CD should default to it; the live+install DVD should have an option :-)
<Kamion> the latter doesn't exist yet though ;)
<Kamion> I'll add it commented out for the moment
<mdz> kent: it's a bug, it's reported already
<Kamion> and eventually make it DVD-only
<Kamion> fabbione: (or should I file a bug?)
<mdz> Kamion: I need something to use for testing, is all
<mdz> easiest would be if I only had to drop /casper/ onto an install CD
<Kamion> mdz: you can just type 'linux casper/enable=true ...
<Kamion> '
<mdz> Kamion: yeah, but I have to type that in qwerty :-P
<Kamion> ah :)
<mdz> it sucks
<Kamion> ok, I'll add it for now
<Kamion> won't stay for release, though
<mdz> well, I suppose you and lamont will have automated builds going soon, no?
<Kamion> fabbione: should I switch sparc to 2.6.10 as well?
<mdz> if so, don't worry with it
<Kamion> yeah, but not for the install CD, is my point :)
<Kamion> fabbione: (d-i)
<mdz> daniels: that's one of the topics for the next CC meeting
<daniels> mdz: schwoit
<mdz> daniels: motu
<daniels> mdz: it's 'dude, where's my car?' all over again
<daniels> mdz: (schwoit -> sweet)
<Kamion> mdz: have you thought about doing casper over nbd or similar, incidentally?
<mdz> Kamion: yes, in fact I was just thinking about it last night
<mdz> er
<mdz> tonight
<mdz> "some hours ago"
<jdub> casper/
<jdub> ?
<mdz> jdub: the new live cd/dvd/usb/whatnot system
<jdub> oh
<mdz> (the one I wrote on wednesday)
<jdub> great name
<mdz> I looked hard and couldn't find another project with that name
<jdub> surprising
<Kamion> mdz: right, I'm including casper-check in pkg-lists/base then, we'll just have it on all initrds
<daniels> cartman: i'm aware of the libglx.a thing, but libGL.so shouldn't be a dangling symlink with a halfway recent version of nvidia-glx
<mdz> Kamion: even (hypothetical) floppies?
<cartman> daniels: I am always using latest packs
<Kamion> yeah
<Kamion> there are plenty of machines that have CD drives but can't boot from them
<Kamion> booting from floppy is a common workaround
<Kamion> of course whether any of them will run casper is a different question :)
<mdz> I intend to make casper fairly clever about that sort of thing
<daniels> cartman: weird.  where was it pointing?
<cartman> libGL.so.1.2
<mdz> it should be able to find filesystem images and COW overlays on hard disks, USB devices, etc.
<mdz> probably do something a bit like os-prober
<Kamion> I was thinking more about desktop memory requirements
<daniels> cartman: bonnnnnng
<Kamion> mdz: might want to look at iso-scan too
<cartman> daniels: doing
<mdz> Kamion: oh, PC that can't boot from CD -> old PC -> low memory?
<Kamion> right
<Kamion> might not be universally true though, c.f. laptops with pcmcia cd drives
<Kamion> mdz: hm, need to add casper-check to the seed too, I'll do that
<mdz> Kamion: oh, oops
<Kamion> fixed
<mdz> Kamion: or even USB CD drives
<mdz> Kamion: such as loonies who buy X40s
<Kamion> :-)
<jdub> or the more powerful and beautiful x300 ;)
<mdz> Kamion: how would you feel about changing the title of "loading components of the Ubuntu installer"?
<mdz> it's rather weird-looking on a live CD :-)
<mdz> (not nearly as weird-looking as when it says "The system is going down NOW!" and kills all the processes, but one thing at a time...)
<stockholm> mdz: ?
<stockholm> ah
<daniels> mdz: if you do it through the dock, I don't think it comes up as USB
<mdz> daniels: oh, is the dock standard equipment?
<stockholm> mdz: do you know if there is interest in having python bindings for kerberos? there is a project started on alioth, but it needs some work and love to be usefull
<mdz> I assume X40s can boot from USB anyway (my T42 can)
<daniels> mdz: nope, it's $$
<mdz> I even booted it from a CF card in a USB card reader
<daniels> mdz: yeah, it can boot from USB in any case
<Kamion> mdz: awkward to achieve, unfortunately. I was thinking about having a legend at the top-left corner of the screen to say that you're in rescue mode or in live CD mode or whatever ...
<mdz> stockholm: yeah, I imagine there is, kerberos being a windows interoperability thing now
<Kamion> mdz: unless you can think of a title for that progress bar that makes sense in all modes
<stockholm> mdz: but there are no working python bindings yet.
<mdz> Kamion: "loading components"
<Kamion> bit *too* generic perhaps
<mdz> stockholm: I imagine there is [interest] 
<daniels> AGH VIM
<mdz> loading runtime components? too techy
<mdz> "loading things to do stuff"
* robtaylor loves his vim :P
<mdz> I don't think "loading components" is bad
<daniels> if there's a vim modeline at the bottom of a file, you seemingly can't change it
<Kamion> "loading extra components"?
<Kamion> daniels: uh?
<Kamion> "loading additional components"
<daniels> Kamion: debian/local/dexconf has et ts=2
<daniels> Kamion: and despite all my efforts, the tabs are always expanded to 2 spaces
<daniels> Kamion: having set noet, and ts=8
<Kamion> try setting ts sts and sw
<stockholm> mdz: and do you imagine canonical with its quest to promote python would push this?
<Kamion> daniels: oh, if et is set there won't be any tab characters in the file
<Kamion> daniels: you have to retab in order to change that
<daniels> Kamion: ahr, that was it -- thanks
<daniels> Kamion: no, this was me putting in new tabs :)
<daniels> Kamion: what's the difference between ts and sts?
<Kamion> softtabstop is what gets inserted when you press tab
<daniels> elmo: please NEW l-r-m-2.6.10 as a matter of priority -- lamont and mdz's livecd is blocking on it
<Kamion> so you can have ts=8 to make tabs in the file be eight spaces wide, but sts=4 to use four-space indent
<elmo> daniels: I already did you talentless gypsy
* Kamion laughs
<daniels> elmo: thankyou, dear
<jdub> catalonians are french gypsies
<azeem> this is better than soap operas on TV
* daniels stares at jdub.
<Kamion> hm, hw-detect/module_params is not very useful for preseeding
<elmo> like, seriously, it'd been in NEW less than 5 minutes.. stop invoking the 'b' word with insane gratuity
<mdz> stockholm: by "push", do you mean "fund"?
<stockholm> mdz: not sure, i guess so.
<daniels> elmo: BULGARIA
<mdz> stockholm: who is developing the bindings?
<lamont> ts should never be other than 8.  sts is a good thing.
<stockholm> mdz: no one at the moment, they are orphaned
* lamont just uses ctl-t
* Kamion ^5s lamont
<stockholm> mdz: rb@d.o started on them but he started studying now and has no time 
<mdz> stockholm: what is rb@d.o's full name?
<stockholm> Roland Bauerschmidt
<stockholm> mark approached him, too
<lamont> if we could get people to quit using ts!=8, then maybe we could get SteveA to let us have tabs back..
<daniels> mdz: if only there was some kind of web-based utility to find information on Debian developers
<mdz> stockholm: if you're looking for someone to continue the development, we don't have developer resources for such projects, but if you find someone who is interested in working on it, have them contact me
<mdz> daniels: the next thing that you say to me should be "here's the command you need to run to generate a working X config for the live CD"
<stockholm> cool!
<daniels> mdz: i'm on it
<mdz> BZZT
<amu> mdz: *eg* 
<elmo> btw, we are going to drop 2.6.9 and 2.6.8.1 eventually  right, and not let them linger on indefinitely in universe?
<amu> elmo: imho better wait till 2.6.10 is kind of "stable"  
<mdz> elmo: 2.6.8.1 I think we can drop today
<elmo> yeah, sure, I do mean eventually
<mdz> fabbione, Kamion: confirm?
<elmo> it's just that, because we name them differently from Debian, they won't get purged, even when Debian drops support for them
<elmo> (in 2014)
<ogra_> mvo ?
<mdz> elmo: please kill any kernel-*-2.6.8 stuff
<mdz> since debian has moved onto 2.6.9
<mdz> I don't see any reason to keep more than the most recent Debian kernel on each branch
<Kamion> sarge hasn't moved, and 2.6.8 is still getting significant development work
<Kamion> probably more attention than 2.6.9 at the moment
<Kamion> I would say that 2.6.8 is still interesting for merges
<mdz> Kamion: interesting for hoary users?
<Kamion> developers
<Kamion> if that doesn't matter, then TBH we might as well just kill kernel-image-* :)
<mvo_> ogra: ?
<mdz> we really don't need 8 versions of the kernel; we're getting Debian disease
<ogra_> mvo: what do you think about using the original avm drivers ?
<mvo_> ogra_: if we can distribute them we should have them 
<ogra_> mvo: and leaving mISDN for the next release....
<Kamion> mdz: ok, fair enough then
<mdz> I think we can at least shed linux-source-2.6.8.1
<mdz> probably kernel-source-2.2.25
<mvo_> ogra_: I think doko asked for permission from avm to distribute the avm drivers
<mdz> and hopefully one of kernel-source-2.6.x
<pitti> ugh, we have 2.2 still?
<mdz> pitti: in universe
<pitti> mdz: right, but still
<ogra_> mvo: i think it eats a reasonable amount of time from fabio and doesnt look as if it gets solved to soon
<mdz> pitti: 2.4.27 in universe as well
<ogra_> mvo: ah, great news
<pitti> mdz: we should drop 2.4.27 IMHO, it has a hell of a lot of security holes
<pitti> mdz: 2.4.28 fixed most of them
<mvo_> ogra_: agreed
<mdz> pitti: I don't know to what extent Debian is still patching 2.4.27
<mdz> pitti: but if they aren't keeping it up to date with fixes, I agree, we should drop it
<pitti> mdz: I just went though the recent vulns with elmo
<pitti> mdz: it seems that even the recent 2.4.28 package still has issues...
<elmo> lunch, bbiab
<mdz> pitti: if you feel that kernel-source-2.4.27 and kernel-source-2.2.25 should be removed, I am in favour of it
<ogra_> mvo: do you know of any probs with i4l and 2.6.10 ? anything we should test in a more detailled way ?
<pitti> mdz: I don't know about hte security status of 2.2.25
<pitti> mdz: but 2.6 should run fine on all of our Ubuntu arches, right?
<mdz> pitti: 2.6?
<mvo_> ogra_: I haven't tested i4l and 2.6.10 yet
<pitti> mdz: I meant, that Debian still needs 2.4 and 2.2 for some architectures
<mdz> right
<pitti> mdz: but I guess Ubuntu doesn't
<ogra_> mvo: ok, i will do some basic testing on the weekend then :) if i encounter probs i'll shout
<pitti> mdz: if we have 2.4.28 in universe, I doubt that we should offer 2.4.27 still
<mdz> the debian kernels are nice to have since they sometimes offer different features/fixes/etc., but if they are not secure, we should not include them
<pitti> mdz: okay, it's universe, but it's so utterly useless
<mdz> pitti: we don't have .28
<pitti> ugh
<mdz> pitti: Debian doesn't have .28 either
<mvo_> ogra_: thanks
<pitti> mdz: oh, I thought, because elmo just compiles 2.4.28 for the Debian servers
<ogra_> :)
<pitti> indeed, no 2.4.28 package; darn
<pitti> mdz: I check the changelog
<pitti> of 2.4.27
<pitti> hmm, what's wrong with packages.d.o?
<pitti> mdz: okay, it seems that they backported much to 2.4.27
<mdz> pitti: right now, or in general? :-)
<pitti> mdz: right now
<pitti> mdz: I looked at the last two changelog entries
<Kamion> pitti: judging from my cron mail, gluck was brought down, I'm guessing for a kernel upgrade or something
<mdz> Kamion: I'd like to add a progress bar to casper; what's a good example to work from?
<mdz> pitti: I meant with regard to packages.d.o ;-)
<pitti> mdz: ah; no, right now; worked fine yesterday
<pitti> mdz: true, that will be a consequence of elmo's kernel updates
<Kamion> mdz: it's very easy, try yaboot-installer or something if it's just stepping through a known list of tasks
<pitti> mdz: luckily we have mvo's changelogs at people.u.c :-)
<mdz> Kamion: the only bit I'm uncertain about is where it runs the prebaseconfig hooks
<mdz> Kamion: I suppose it should count them at the start and incorporate that count into the progress bar?
<Kamion> mdz: yes, you could look at how the prebaseconfig progress bar itself works
<Kamion> it would be best not to use run-parts then, so that you can step the progress bar properly
<mdz> since it runs locale-gen and stuff, that is actually the longest bit I think
<Kamion> or at least not to use the one from /target
<mdz> that, and waiting for udev to create device nodes
<mdz> we really should find out why that sucks so much
<Kamion> hm, it's a shame 'apt-get -s build-dep' requires root
<lamont> daniels: you around?
<mdz> Kamion: there are many shameful things about apt-get build-dep
<mdz> lamont: daniels uploaded l-r-m-2.6.10, so you should be able to use the metapackagaes again now
<mdz> lamont: also, it would be really handy to be notified of failures in your daily desktop builds; can you arrange for those to go someplace useful?
<Xof> ah, lamont
<Xof> I've been told it's you I should speak to about sbcl build failures?
<lamont> Xof: patches welcome
<mdz> whoa, #5271 seems to trigger some bug in debzilla
<mdz> Kamion: is it possible that some comments in debbugs have no message-ids?
<Kamion> wouldn't surprise me
<Xof> lamont: that attitude doesn't impress me very much
<Kamion> mdz: which comments?
<mdz> Kamion: https://bugzilla.ubuntu.com/show_bug.cgi?id=5271
<mdz> Kamion: guess which :-)
<Kamion> Xof: remember that sbcl is an unsupported package; to some extent we depend on community contributions for those
<Xof> of course
<Xof> and I spend my day making patches to it
<lamont> Xof: I'm hip deep in a bunch of must-do stuff.  sbcl is ftbfs, I believe, yes?
<Xof> and I kind of wanted to know about the environment of the buildds
<Xof> but now I don't really care any more
<lamont> Xof: if you have patches for it, I'd love to get them.
<mdz> Kamion: hmm, doesn't look like a message-id problem now that I look in debbugs
<lamont> Xof: it's sbuild in a chroot with hoary
<mdz> Kamion: it looks like maybe the log parser is inadvertently splitting a message into two?
<lamont> Xof: is sbcl one of those that will need to be bootstrapped from other than the binaries that are currently in hoary?
<Xof> it shouldn't do
<lamont> good.  those make my brain hurt./
<lamont> what more did you need to know about the buildd environment?
<Xof> at least, I don't know what binaries you have in hoary; it does depend on itself, I'm afraid, so for the new amd64 support you may need one bootstrap
<Xof> but it doesn't depend on the exact same version of itself
<Xof> lamont: the fact that it seems to be failing non-deterministically (or deterministically failing but not always in the same place) makes me suspicious
<lamont> should be good.  http://archive.ubuntu.com/ubuntu/pool/universe/s/sbcl has the sbcl binaries for {hoary,warty}
<Xof> is there anything like stack-guard or randomized mmap() or a movable malloc heap in your environments?
<Kamion> mdz: looks like it's splitting at the . on a line by itself, but why would it do that?
<Xof> any non-unlimited ulimits?
<fabbione> mdz: sorry.. i had to run away.. what do you want me to confirm?
<Xof> (also, knowing the difference between your buildds and debian's would be useful, because the builds seem to succeed more often over there)
<mdz> Kamion: isn't that the delimiter you use?
<mdz> fabbione: that we can remove linux-source-2.6.8.1
<mdz> and corresponding l-r-m
<fabbione> mdz: from hoary.. yes
<Kamion> mdz: not in debbugs, but it *is* the delimiter used for communication between debbugs-log.pl and debbugs.py
<mdz> elmo: removal of linux-source-2.6.8.1 and linux-restricted-modules-2.6.8.1 is agreed
<mdz> Kamion: right
<Kamion> mdz: all that code seems to dot-escape and -unescape correctly though ...
<mdz> yeah, I thought so too
<lamont> Xof: no ulimits that I know of 
<Xof> lamont: having the output of /proc/`pidof emacs`/maps (when there's an emacs started) on the machines would be useful
<Kamion> mdz: the bug's in debbugs-log.pl; I'll have a look after I get back from lunch
<Xof> lamont: there's no terribly urgent rush from my point of view, so if you have more urgent things, go do them :-)
<lamont> Xof: the ubuntu buildd's use ccache and a small gcc-shim (which should be having no effect on sbcl), but are otherwise currently no different from debian in any practical way
<mdz> Kamion: meanwhile, I should probably find a workaround, since it's adding a new comment every 15 minutes...
<fabbione> lamont: i did ping willy.. he doesn't know what is the I/O problem either
<mdz> oh, it's been downgraded, I can just remove it
<Xof> (fwiw, I committed amd64 support to the sbcl development tree yesterday, and it's working fine on my ubuntu desktop... so it's just the rest of the world which needs this investigation ;-)
<fabbione> lamont: in anycase.. the kernel compiles now.. we need to allign the configurations
<lamont> fabbione: ggg was mumbling about it last night.
<fabbione> lamont: ok. i need to check the pa6 patch now and see if it still applies with the fixes i am backporting from bk
<fabbione> lamont: after that i will handle you the packages to prepare the configs
<fabbione> lamont: because i dunno some of the stuff it asks for
<lamont> ok
<fabbione> lamont: that are pretty specific to hppa hardware
<lamont> right
<Xof> lamont: I'll tell you up front that the nondeterminism in the failure point tends to lead me to suspect hardware problems (at least on x86 and powerpc); sbcl compilation is a very good way of finding those.  On the other hand, your buildds are presumably surviving the rest of the load, so...
<Kamion> mdz: aha, this is an amusing bug :)
<Kamion> -        $text =~ s/^\./../m;                    # escape dots
<Kamion> +        $text =~ s/^\./../gm;                   # escape dots
<Kamion> mdz: try that
<Kamion> it only escaped the first dot :)
<Kamion> (I've tested it, seems to do the right thing here)
<lamont> buildd's are nice fat IBM boxes that have been doing quite well for some time.  The one of 10 or so that had memory issues has been repaired lo these 6 months or so.
<lamont> Xof: and memtest was quite happy at that point.
<Kamion> lamont: do we run exec-shield kernels on the buildds?
<elmo> mdz: removed
<elmo> Kamion: no
<Kamion> ok
<elmo> we don't run exec-shield anywhere anymore
<mdz> Kamion: I put that in place; we'll see what happens with #5271
* Xof drums his fingers
<Xof> to be honest, I'm not entirely sure what to suggest
<lamont> Kamion: so, livecd-rootfs...
<lamont> wanna discuss it here, or take it off-channel, since it's almost entirely administrivia
<lamont> ?
<Xof> the same source builds fine on debian and elsewhere.  It's _possible_ that you'd see this kind of thing if the previous binaries (which you're using to build from) are bad, of course
<Kamion> lamont: off-channel's probably better
<Kamion> unless mdz's interested
<Kamion> or amu
<elmo> lamont: have you tried building without the wrapper?
<lamont> elmo: not yet.
<mdz> lamont: here is fine, unless there's a reason to keep it a secret
<mdz> I would like to have a record to refer to
<lamont> mdz: OK.
<lamont> mdz: or ubuntu-meeting?
<fabbione> daniels: ROCKING xserver-xorg_6.8.1-1ubuntu9_sparc.deb!
<mdz> lamont: wherever
<lamont> fabbione: about time, slacker. :-)
<fabbione> lamont: i had to build twice man :-)
<Kamion> lamont: where's easiest for you to get the blobs to, then?
<fabbione> before to test and to do the real build
<fabbione> ;)
<lamont> heh
<lamont> and on sparc.  ok.
<fabbione> no.. on ONE sparc...
<fabbione> you have N * 4 
<fabbione> or * 3
<fabbione> still...
<fabbione> ;)
<Kamion> mdz: d-i with 2.6.10, rescue-check, casper-check uploaded
<lamont> Kamion: so the livecd script (a) can run in a chroot, so it will, and (b) generates ~525MB of cloopimage on i386 - prolly about the same on the others,
<fabbione> Kamion: rocking hard!
<lamont> since elmo doesn't want it going near the archive, and it'd be by-hand anyway, we get to figure out some other way to get the bits where they need to go.
* Kamion tends to agree with elmo there
<mdz> Kamion: way cool
<lamont> Kamion: me too.
<Kamion> can I just wget it from the relevant buildd or something?
<mdz> lamont: powerpc will end up bigger, but of course we don't need to worry about opencd stuff on powerpc I suppose
<lamont> Kamion: certainly
<mdz> lamont: unless we start shipping macos ports :-)
<Kamion> lamont: assuming, of course, that it's always going to be the same one ...
<Kamion> mdz: fink! :)
<lamont> Kamion: so I'll get you a list of the buildd's in question, and then it's just wget http://.../~buildd/...
<lamont> Kamion: always the same one
<lamont> barring events
<sivang> anybody seen pitti ?
<Kamion> then, as I read casper-udeb, I stick that in casper/filesystem.cloop on the image
<pitti> sivang: I think I have seen him recently :-)
<lamont> brb
<Kamion> now, the rest of the image should have dists/ and pool/ with d-i udebs, but no debs; correct?
<Treenaks> pitti: prove it! ;)
<thom> pitti: lots of mirrors in your house?
<mdz> Kamion: what's the least ugly shell idiom for "run all this bit in a subshell, and if it fails, do this bit instead" ?
<daniels> fabbione: :)
<Kamion> mdz: (...) || ...?
<mdz> ("all this bit" is many lines)
<pitti> Treenaks: I think, therefore I am mad
<pitti> Treenaks: or so... :-)
<Treenaks> pitti: 8)
<mdz> (...many many lines...) || ... seems a bit ick
<Kamion> mdz: use a shell function for the first bit
<Kamion> then (function) || ...
<sivang> pitti: hehe, I tried to autocomplete you name to message you but couldnt :)
<sivang> pitti: eh, multi network clients..
<Kamion> mdz: do you want me to attempt to trim the list of udebs included on the live CD?
<mdz> Kamion: yes
<Kamion> mkay
<fabbione> ChangeSet@1.1938.463.14, 2005-01-03 20:14:55-08:00, slpratt@austin.ibm.com
<fabbione>   [PATCH]  Simplified readahead
<fabbione> thoM ^
<Kamion> ideally that would be a seed or something
<mdz> Kamion: yeah, casper needed functionalizing anyway
<mdz> Kamion: happy for you to create a seed out of it
<fabbione> check it from bk9 changelog
<Kamion> casper.seed?
<Kamion> casper-first-stage.seed?
<Kamion> then I'd get to figure out where the hell it lives in germinate :)
<thom> fabbione: i don't think i care that much that it's worth backporting
<Kamion> fabbione: you forgot to say "the first one's free"
<Kamion> mdz: how about we call the first-stage seed 'casper' and the live-filesystem seed 'live'?
<fabbione> thom: oh yes.. you do.. if you check the performance improvements :-)
<fabbione> Kamion: uh?
<thom> fabbione: that much?
<fabbione> thom: quite a lot yes
<Kamion> fabbione: I was reminded of a dealer passing out crack in the form of tasty kernel patches :)
<elmo> s/one/hit/
* lamont is back
<mdz> Kamion: hmm, tough one
<thom> fabbione: cool, thanks :-)
<Kamion> elmo: do you care about the names of individual seeds, or do you just look at 'all'?
<mdz> Kamion: whatever works for you
<Kamion> mdz: kinda makes sense to me since you could boot into the live filesystem in ways other than casper
<elmo> I care for generating Task: desktop entries, but other than that, no
<fabbione> Kamion: ahahha
<Kamion> elmo: ok, so a new seed that germinate treats as part of 'all' will automatically feed into main?
<lamont> Kamion: things I know need to get tweaked on the livecd:  netconf (duh), /etc/postfix/main.cf, /etc/mailname (both done with the reconfig of postfix in base-installer, iirc), and /etc/papersize based on locale.  I can make the file not be there, if you can run the postinst...
<fabbione> Kamion: that's why he will pay for the readhaed-congestion-control :-)
<Kamion> base-config not base-installer
<Kamion> lamont: guess that gets to be part of the weird hacks casper does :)
<elmo> Kamion: err, mm, lemme check, but I think so
* Kamion tries to remember if di-utils-mapdevfs is needed
<lamont> Kamion: yeah.  just wanted to make sure they were on the table.
<elmo> Kamion: yes
<Kamion> hm, I'll include that one, it's cheap
<Kamion> elmo: ok, thanks
<sabdfl> Kamion: can the installer framebuffer support a mouse pointer?
<thom> holy crap! 25-100% performance improvements?
<thom> dude, what are you waiting for
<daniels> baaaaackport :)
<daniels> sabdfl: not a pointer as such ... more a sort of floating block
<sabdfl> i've seen mouse pointers of fb-text before...
<Kamion> directfb does mouse pointers, doubt the plain fb does
<Kamion> although I could be wrong
<ogra_> gpm with a special charset ?
<Kamion> (we don't have mouse drivers in the installer at the moment, so nobody's ever tried afaik :))
<fabbione> pitti:
<fabbione> ChangeSet@1.1938.463.17, 2005-01-03 20:15:37-08:00, Andries.Brouwer@cwi.nl
<fabbione>   [PATCH]  mm: overcommit updates
<fabbione> this patch is cool
<fabbione> but really cool
<Treenaks> fabbione: what's so cool about it?
<fabbione> thom: i did already.. only for you :-)
<fabbione> Treenaks: the memory allocation for root
<thom> aw, you knew what i wanted for christmas
<fabbione> reserver for root
<pitti> fabbione: "mm overcommit" rings a bell
<fabbione> Treenaks: basically a user with no ulimits cannot allocate all the RAM on the machine but only up to 97%
<pitti> fabbione: we already have this, right?
<fabbione> pitti: adding it now.
<Treenaks> fabbione: coolness
<fabbione> Treenaks: basically that ensures a 3% left for the user
<fabbione> hem root
<fabbione> to kill the user
<fabbione> without having to reboot the machine
<lamont> fabbione: what'll the hppa meta packages be?  linux-hppa32 and linux-hppa64?
<fabbione> lamont: no idea.. 
<lamont> what are sparc's?
<thom> big expensive things
<fabbione> linux-sparc64
<thom> made by fujitsu-siemens
<fabbione> so i guess it would be linux-hppa32 and hppa64
<lamont>   # and the bastard stepchildren
<lamont>   hppa)         KERNEL="linux-hppa32 linux-hppa64";;
<lamont>   sparc)        KERNEL="linux-sparc64";;
<elmo> thom: badoom-tisch
<fabbione> pitti: people/~fabbione/stolen-from-head_mm-overcommit-updates.dpatch
* thom gives up trying to read the readahead optimisation paper
<thom> it was making steam rise from my brain, and the windows were misting up
<daniels> thom: more!
* fabbione hands over more crack to thom
<mako> jdub: around?
<mako> Josephus: probably not
<mako> ergh
<mako> jdub: probaby not
<mako> Josephus: sorry.. borked completions
<mako> jdub: traffic -> planet.ul.o
<fabbione> thom: i am going to give you another 50% performance increase in the next patch:
<fabbione> ChangeSet@1.1938.463.20, 2005-01-03 20:16:19-08:00, miquels@cistron.nl
<fabbione>   [PATCH]  mark_page_accessed() for read()s on non-page boundaries
<fabbione> this rocks for databases
<fabbione> elmo: ^^you really want that on emperor
<elmo> is anyone else seeing bizarre scrolling problems with xterm recently?
<elmo> where the screen will like hang for a bit when you throw lots of really fast data at it, but recover 5-10 seconds later
<thom> yay, we have infected fabio with the desire for SPEEEEEEEEEEEEEEEEEEEEEEEEEED
<elmo> fabbione: get you and your pull-random-patches-from-bk crack behind me and my production machines ;-P
<mdz> hmm
<Keybuk> OSError: [Errno 2]  No such file or directory: 'sources/elilo-installer_1.3/elilo-installer_1.3/debian/changelog'
<mdz> if a shell script is set -e, does an unsuccessful command in a function terminate the entire shell?
<Keybuk> meh
<mdz> or only the function?
<mdz> eek, the whole script it seems
<Kamion> if it's in a subshell it terminates just the subshell
<Kamion> Keybuk: 1.3? where'd that come from? current is 0.3
<Kamion> no it's not
<Kamion> hah, elilo-installer_1.3.tar.gz contains the directory elilo-installer-1.3/
<Kamion> hah, elilo-installer_1.3.tar.gz contains the directory elilo-installer-0.3/
<Kamion> slap dannf :)
<fabbione> elmo: tsk!
<fabbione> ;)
<Keybuk> it does?  heh
<mdz> Kamion: yeah, so I need a subshell inside a function to get what I want, bleah
<Kamion> elmo: what did you think of my gpgv-udeb patch?
<mdz> Kamion: hmm, so my progress bar comes up, but all the text is missing
<seb128> Keybuk: any idea on #4785 ?
<mdz> Kamion: the templates are present in the udeb, but I don't see them in /var/cache/debconf/templates.dat
<Kamion> there is no /var/cache/debconf/templates.dat in d-i, it's /var/lib/cdebconf/templates.dat
<elmo> Kamion: err
<mdz> there is on my initrd; I wonder where it came from
<mdz> anyway I thought I did everything right, but I get no text
<mdz> not even the text for the progress bar title
<Kamion> mdz: it came from your mad udpkg --unpack onto initrd thing
<mdz> is /var/lib/cdebconf/templates.dat where I should look?
<Kamion> mdz: if you do that, udpkg calls debconf-loadtemplate, but it will call the version in the development system rather than the one in the initrd
<Kamion> yeah
<Kamion> but after booting
<Kamion> the initrd should have the text in /var/lib/dpkg/info/*.templates
<Keybuk> seb128: hmm... Libtool doesn't strip a /usr/lib rpath on AMD64 ... I can believe that; does "gcc -print-search-dirs" include /usr/lib on AMD64?
<fabbione> ChangeSet@1.1938.463.31, 2005-01-03 20:18:48-08:00, rusty@rustcorp.com.au
<fabbione>   [PATCH]  netfilter: Remove IPCHAINS and IPFWADM compatibility
<fabbione> mdz: ?
<mdz> Kamion: the initrd?
<mdz> fabbione: yay
<fabbione> or is it too scary?
<mdz> sounds great to me
<ogra_> no, do it !
<fabbione> ok
<mdz> less code -> less bugs
<seb128> Keybuk: dunno ... anybody with an amd64 box around ? thom ?
<mdz> er, less code -> fewer bugs :-P
<thom> Keybuk: /usr/lib/, yes
<Kamion> mdz: yes ...?
<Keybuk> seb128: unless they made the stupid mistake of building epiphany on Fedora
<mdz> Kamion: this is in casper-udeb
<ogra_> seb128: next week, its ordered ;)
<Kamion> mdz: oh
<Keybuk> can you: grep "^    sys_lib_dl" *.m4  -- (4 spaces) in the epiphany source directory?
<seb128> Keybuk: what's specific about fedora ?
<Kamion> mdz: udpkg should call debconf-loadtemplate when unpacking it then, so /var/lib/cdebconf/templates.dat
<seb128> $ grep "^    sys_lib_dl" *.m4
<seb128>     sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
<seb128>     sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff} $lt_ld_extra"
<Keybuk> muahahaha
<Keybuk> yeah, that's the fuck-arsed broken Fedora version of Libtool
<Keybuk> SUFFER AND DIE!
<seb128> chpe use fedora yep
<seb128> so we just have to relibtoolize it ?
<Keybuk> libtoolize, aclocal, autoconf, share and enjoy
<seb128> thanks Keybuk 
<mdz> Kamion: templates are present in cdebconf/templates.dat
<mdz> Kamion: my god it is huge
<Kamion> yep
<mdz> what's the next suspect?
<Kamion> incorrect use of the progress API probably
<mdz> mailed you a copy of the code
<elmo> Kamion: looks fine
<elmo> Kamion: did you need it soonish?
<Kamion> elmo: need it for apt authentication support in the installer, which I'd like to finish by feature freeze
<mdz> oh
<mdz> Kamion: I think I need to call STEP before INFO, rather than after
<Kamion> so soonish would be nice if you could, yeah
<Kamion> mdz: should work either way round
<mdz> it looks correct to me, then
<Kamion> I'm fairly sure I've written both
<fabbione> mdz: fabbione@gordian:/usr/src/bk$ ./dpatchify 1.1938.463.31 ipchains_and_ipfwadm__must_die
<fabbione> there you go...
<mdz> Kamion: your debbugs-log.pl fix seems to have worked
<Kamion> good
<Kamion> mdz: looks ok to me too, I'd triple-check that the template names are right ...
<mdz> Kamion: I generated the .templates file using grep|awk on the script, so I'm extremely certain that they match
<Kamion> hm, ok
<Kamion> can I see the templates file?
<Kamion> wondering about po-debconf weirdness
<mdz> sure
<mdz> sent
<mdz> ahhh
<mdz> I bet that's it
<mdz> I don't have a debian/compat file
<mdz> hmm, maybe not
<mdz> I thought that made a difference, but it doesn't seem to
<mdz> mizar:[...canonical/casper/casper-0.2]  diff -u debian/casper-udeb.templates debian/casper-udeb/DEBIAN/templates
<mdz> mizar:[...canonical/casper/casper-0.2] 
<Kamion> that's not normal, there's usually debian/po/ and '2 utf8' in debian/po/output, which changes the format
<mdz> I didn't create debian/po
<mdz> should I?
<Kamion> yes
<mdz> ok, done
<mdz> doesn't seem to make a difference, though
<mdz> oh, yes it does
<mdz> guh
<Kamion> you'll need to do the full po-debconf gettextising routine
<mdz> well, just creating debian/po fixed the output templates file
<Kamion> Description: lines (at least) in .templates need to be _Description:
<mdz> -_Description: Starting up
<mdz> +Description: Starting up
<Kamion> ah
<Kamion> yes, if they were already _Description: then you'd have had a problem
<Kamion> try debconf-updatepo as well
<Kamion> to create templates.pot
<mdz> File debian/po/POTFILES.in does not exist... exiting
<Kamion> [type: gettext/rfc822deb]  casper-udeb.templates
<mdz> did that, re-ran, works
<mdz> doing a new test CD build now, thanks
<elmo> mdz: dude, flac needs relibtoolized
<fabbione> Kamion:   [PATCH]  ppc32: add uImage to default targets
<fabbione> do we need this?
<lamont>   ubuntu-desktop: Depends: rhythmbox but it is not going to be installed
<lamont> GAH!
<Kamion> fabbione: not worth backporting, it's for Amiga hardware IIRC
* lamont needs to run an errand for his wife real quick, back in a bit.
<lamont> who knows, maybe rhythmbox will be installable then
<Kamion> mdz: I've added a casper seed; you probably want to eyeball it
<lamont> After installing, the following source dependencies are still unsatisfied:
<lamont> python-dev(inst 2.4-0ubuntu4 ! << wanted 2.4)
* lamont laughs and points at swig1.3
<lamont> must flee
<fabbione> Kamion: ok
<Keybuk> mdz: there were a handful of stuck merges, I've fixed the bug that caused them and they've been released; so there's probably a few more bugs been filed.  otherwise, that's a line drawn now
<mdz> elmo: hmm, yeah, keybuk said the same thing, but I forgot to do it in -3
<mdz> Keybuk: ok, thanks
<mdz> Keybuk: can we generate a list for universe as well?
<mdz> s/list/output/
<elmo> SWEET
<elmo> sensors-detect kills our dells
<thom> kick ass
<Keybuk> what kind of output do you want?
<thom> elmo: i assume it was maitri you just special'ed, then
<elmo> thom: yeah
<elmo> I thought it be a bit harsh to trash James' arch box, even if it his devel server ;)
<thom> heh
<sabdfl> special'ed? that with arm effects?
<thom> sabdfl: the arm effects are optional
<elmo> is lm-sensors going in main for hoary?
<Keybuk> are there many machines where lm-sensors is useful anymore?
<Keybuk> I thought most of it was covered through ACPI and I2O in the kernel nowadays
<mdz> Keybuk: the kernel bits are all in the kernel now
<mdz> the userland bits are in main for hoary already, I thought
<elmo> none of the servers in the DC have ACPI which can do what lm-sensors does
<elmo> neither does my home machine
<mdz> there was a discussion and agreement on it anyway
<mdz> hmm
<mdz> scratch that
<mdz> anyway, I fixed it so that it doesn't build the kernel bits, and it's ready to be seeded
<mdz> I'll seed it now
* elmo looks for a DL380 to test-kill
<mdz> lamont: do you have a new image for me?
<mdz> elmo: done
<elmo> what about the seed proposals we discussed at mataro, are they getting done for hoary?
<mdz> thom: ?
<thom> ahr, i knew there was something
<thom> shall i update the seeds direct, or the wiki and someone else will do the seeds?
<daniels> elmo: sensors-detect kills a LOT of things
<Kamion> thom: the wiki is totally obsolete
<elmo> daniels: I don't see why, it's the same bloody mb as the IBM and it didn't kill that :PO
<Kamion> if whoever's relevant (probably mdz/jdub) okays it, just update the seeds in arch
<daniels> elmo: it takes out all my boards here
<mdz> thom: there are no more seed lists in the wiki
<Kamion> unless you mean the proposals pages
<mdz> thom: the ones in baz are the one, true and authoritative seeds
<thom> seed proposals, rather
<thom> ok
<mdz> this is stuff which was already discussed and approved at the conference, right?
<trulux> mdz: did you read the doc?
<thom> yes
<mdz> trulux: no, not yet.  please send me an email so that I don't forget about it
<cartman> elmo new flac packages fixed libflac6 problems but now some packs are un-installable because they depend on now removed libflac4
<trulux> mdz: ok
<cartman> gstreamer0.8-flac libtunepimp2 libtunepimp2-dev vorbis-tools
<mdz> cartman: once flac is built on all architectures, we'll upload new versions of those packages
<cartman> mdz: so I shouldn't update bugreport?
<cartman> with the new info
<mdz> cartman: no need; there is a list of uninstallable packages which is automatically generated
<cartman> mdz: cool, thanks for info
<cartman> you guys are fast bugfixers. appreciated
<thom> what did we end up deciding for oo.o-evo/gnomevfs? that we're doing so only for x86/ppc
<mdz> thom: dunno, but it seems a bit broken at the moment
<thom> shall i hold off seeding them for the time being
<thom> elmo: doesn't look good for the HP, then?
<elmo> well.. I can helpfully see the banks of memory via lm-sensors... but for anything useful? no.. meh
* mako can think of like 10 funny ways to reply to this mascot thread
<kent> not that it matters, but how long until flac is build on the other platforms?
<elmo> bizarrely, the IPMI stuff doesn't even work, but does with the much lower-end DL140's
<Treenaks> mako: post 10 funny replies then :P
<mdz> kent: it's done already
<mako> Treenaks: i posted one funny reply :)
<mako> Treenaks: that's my quota
<mdz> and I just uploaded three packages
<mdz> kent: for future reference, you can check both things for yourself at http://people.ubuntulinux.org/~lamont/buildLogs/ and http://lists.ubuntu.com/mailman/listinfo/hoary-changes
<Treenaks> I justed picked up a copy of "Mind Hacks" (by Stafford & Webb)
<Treenaks> great book :)
<kent> mdz, thanks :)
<mdz> mako: we need an equivalent of www.d.o/devel/ which points to all this stuff
<mako> mdz: here.. lets make a wiki page for right now and then move it into the website once it's stablized
<mdz> mako: sounds good
<mdz> mako: once it exists, add it to the topic, and I'll add anything else to it that I think of
<mako> http://www.ubuntulinux.org/wiki/MaintainerDocumentation
<mako> i just found it
<mdz> that needs to be named DeveloperResources or something instead
<mako> i'll rename
<mdz> lots of people who aren't maintainers can benefit from it
<mako> chris halls did it :)
<robtaylor> mako: hey.. out of intrest will you be going to the CDD devcamp?
<mako> http://www.ubuntulinux.org/wiki/DeveloperResources
<mako> robtaylor: yes.. i didn't reply onlist but i did reply
<robtaylor> mako: groovey :)
* ..[topic/#ubuntu-devel:mako] : Ubuntu development -- ARE WE NEARLY THERE YET? -- general discussion and support on #ubuntu | http://www.ubuntulinux.org/wiki/DeveloperResources | Want to help Hoary? see https://www.ubuntulinux.org/wiki/HoaryGoals
<robtaylor> mako: it'll be a busy summer :) FISL, CDD, then debconf.. hope i can get all the time off work :)
<mako> robtaylor: debconf is very long this year.. i suspect many people will come for just a part
<mako> robtaylor: i will probably take 4-5 days off to go to LSM, which happens during the middle of debconf
* mako takes off time from his time off
<robtaylor> mako: LSM?
<azeem> mako: are you going to hit LinuxTag as well?
<mako> libre software meeting.. french free software meeting. one of my personal favorites
<mako> azeem: yes, it's on the list
<mako> azeem: is there a CFP yet? i put lt and lsm on the list of confs that i thought canonical should send people to
<azeem> dunno, Joey would know about LT
<azeem> I believe LSM is pretty unorganized
<mako> this year seems better
<mako> they have dates and a location and speakers already (!)
<mako> that's like 6 months better than last time :)
<azeem> whoa, you got an URL?
<mako> i've been emailing with one of hte organizers
<azeem> mako: Joey just said the deadline for LinuxTag is today
<mako> damnit
<cartman> mdz: ping
<elmo> when is debconf?
<azeem> mako: nah, it appears to be 15th Jan for LinuxTag
<mako> woot!
<robtaylor> mako: so why's LSM your fave? ;)
<robtaylor> elmo: 1st two weeks of july i believe..
<mako> robtaylor: it's basically just talks, TONS of them (8-10 tracks) and nothing else for 4 days
<cartman> mdz: nm see my comments @ https://bugzilla.ubuntu.com/show_bug.cgi?id=4680
<mako> robtaylor: lots of really great people saying lots of great things.. the facilities aren't that great, etc.. the emphasis is completely on the content and on sharing information with each other
<mako> robtaylor: i have always learned a ton
<robtaylor> mako: nice :)
<thom> cartman: i know already, fix coming shortwith
<mako> robtaylor: it helps a lot if you understand french
<cartman> thom: alright
<mdz> cartman: please file a separate bug about that; it is a bug in its own right
<mdz> cartman: or, don't bother, because thom already knows
<cartman> right
<mdz> not used to thom being awake ;-)
<thom> oi!
<cartman> hehe
<elmo> LOL
* robtaylor wonders wether to learn portugese or french by the summer ;)
<mdz> due to time zone differences, of course
<bob2> haha
<thom> cartman: your analysis is way off, by the way :-)
<bob2> robtaylor: finnish
<cartman> thom: speculation always works :P
<robtaylor> bob2: i think i'd need a decade for that ;)
<mdz> mako: oh god it's in restructuredtext
<cartman> thom: whats the real problem?
<bob2> haha
<bob2> itym reStruCtuREDTeXt
<robtaylor> bob2: oh, a freind of man was asking the other day.. has australia got anything good on its human rights records?
<thom> cartman: on_ac_power helpfully returns 255 if it can't work out whether you're on ac power or not
<robtaylor> s/man/mine
<cartman> thom: I see :)
<bob2> robtaylor: we used to not suck
<mdz> ReST makes me want to die
<robtaylor> bob2: heh
<cartman> thom: I thought since it will do fsck it won't mount filesystem ;)
<thom> that's why i check for the existence of on_ac_power before trying to use it ;-)
<cartman> my bad
<lamont_r> mdz:?
<bob2> robtaylor: we used to be pretty good about pressuring other countries to shape up, but now all we do is lock up refugees and oppress indigenous people.
<mdz> lamont?
<lamont_r> can we pretty please have cloop-utils in main?  we're supporting it after all...
<mdz> thom: isn't cloop-utils on your list?
<mdz> if not, I'll add it right now
<mdz> I thought it had already been done
<lamont_r> then I don't have to bounce sources.list around in the chroot - it really doesn't like building a livecd rootfs with universe in there.  That or rhythmbox really was broken.
<thom> mdz: no
<mjg59> thom: So, how are we going to write these ACPI scripts?
<elmo> someone needs to fix cloop not to use modules-assistant
<elmo> then it can go into main
<elmo> there's a bug in bugzilla
<robtaylor> bob2: heh, thanks. I seemed to remeber it being something like that :/
<lamont_r> elmo: ok.
<mdz>  * cloop-utils # for LiveCD
<mdz> lamont: it's already there
<lamont_r> interesting... 
<mdz> hmm
<mdz> amu?
* elmo considers making snide analogies between bugzilla and a void as revengeh on mdz
<mdz> amu: I assigned that bug to you some time ago
<amu> mdz: ?
<mdz> amu: https://bugzilla.ubuntu.com/show_bug.cgi?id=4535
<lamont_r> mdz: interestingly, http://archive.ubuntu.com/ubuntu/pool/main/c/cloop is 404...
<mdz> lamont: what elmo said
<lamont_r> mdz: so it's really just blocked on the bug
<Kamion> lamont_r: rhythmbox really was broken, per britney
* amu *ducks* 
<lamont_r> Kamion: kewl.
<Kamion> somebody with a spare minute oughta fix that
<lamont_r> Kamion: no ia64 love for you today - glibc still b0rked there
<lamont_r> other 3 are chunking away now
<mdz> Kamion: already did
<mdz> it depends on vorbis-tools, which was broken due to flac
<lamont_r> Kamion: it installs now...
<mdz> I uploaded fixes for all the flac stuff in main a short while ago
<amu> mdz: in process now 
<Kamion> lamont_r: I'm buried in kickstart anyway :-/
<lamont_r> Kamion: actually meant no livecd-rootfs, but the other is true to.
<robtaylor> mdz, amu: can you point me to the current livecd work? 
<mdz> robtaylor: www.ubuntulinux.org/wiki/LiveCD or such
<sabdfl> lamont: is there any way to force postfix to relay through a host and use SSL?
<sabdfl> erm, worse
* elmo eyes start flopping around wildly
<sabdfl> use SSL *if it's offered*
<sabdfl> sorry elmo
<Kamion> elmo: funky
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals
<lamont_r> sabdfl: you can use a transport map to force it, force it.  relayhost generally does a good enough job though.
<lamont_r> as for the TLS stuff, it's done opportunistically
<sabdfl> so if it sees it, it uses it?
* lamont_r really needs to pester sabdfl/whoever about cert generation for postfix-tls, so that we can do tls by default.
<lamont_r> if it's configured...
<lamont_r> we don't currently configure it
<sabdfl> configured?
<elmo> did we make a decision about MTA for hoary yet btw?
<sabdfl> hmm... let's switch to #ubuntu
<robtaylor> mdz: umm, i mean your d-i code. or can i just apt-get the hoary source for d-i + debian-cd?
<mdz> robtaylor: the magic is spread around in many packages, but probably the most interesting one is casper
<mdz> lamont: do you have something for me to download?
<mdz> lamont_r: ^^^
<fabbione> not too bad
<fabbione> i am not even at 40
<fabbione> 40% of bk9 changelog
<fabbione> and we have already like 80 patches
<fabbione> and there is bk10 out already..
<mdz> why?
<fabbione> mdz: all small bug fixes
<fabbione> plenty of them
<Kamion> hm, translating kickstart 'partition' will be interesting
<Kamion> I think I'm going to have to write out a partman-auto recipe on the fly, or something
<lamont_r> mdz: people.ubuntu.com/~lamont/mdz/livecd.cloop , iirc
<lamont_r> yep.  that's it.
<lamont_r> Kamion: setting up http for you after lunch
* fabbione needs a break
<sivang> mdz: [curiosity]  what is casper?
<mdz> sivang: the new infrastructure for the live CD
<sivang> mdz: k, thanks, is it downloadable from anywhere yet?
<tseng> sivang: it was accepted into hoary
<mdz> sivang: it is a package in the Ubuntu archive
<sivang> mdz: coooool :)
* sivang has localized live cds in mind when time comes.
<mdz> it will be trivial with casper
<sivang> mdz: that's what I thought, Kamion and you are the people to thank to? :)
<mdz> and the live DVD should support all locales
<sivang> mdz: eh! now that's rad
<Kamion> mostly mdz, I just checked a few things and gave advice
<sivang> mdz: seems that localized ones are bit redundent, given the live dvd will be also distributed free by canonical? 
<mdz> it depends on what will fit
<Kamion> plenty of machines don't have DVD readers
<mdz> which reminds me
<mdz> Kamion: how are we going to work the magic to install language packs?
<sivang> Kamion: most of the machines around my region and many people I know have been shipped with dvd reader since about 2 years ago :)
<Kamion> mdz: for the install CD?
<mdz> Kamion: yes
<Kamion> mdz: hack up base-config/lib/menu/pkgsel, I figure
<mdz> and maybe for the live CD also if we get tricky
<ogra> sivang: i my company we have 900 PCs ... guess how many DVD readers 
<sivang> ogra: 900? :)
<ogra> 3
<mdz> Kamion: e.g., ship with top N languages in the filesystem image, but if you select something else, download the language pack on the fly and install it
<ogra> and the machines are about 2 years old
<Kamion> mdz: (hell, just unconditionally aptitude install ...)
<Kamion> mdz: by pkgsel I've got the language, so it's a SMOP
<mdz> Kamion: casper doesn't talk to base-config yet, but it ought to
<Kamion> mdz: note that kickstart has a langsupport command that lets you install multiple languages; it would be interesting to figure out how to integrate that
<mdz> the last time I tried something like this, it didn't DTRT for noninteractive mode
<Kamion> in fact kickstart has one command for the installation language and a totally separate command for the installed language(s)
<sivang> Kamion: that would make preseeding a d-i question redundent? if kickstart would take care of it setting the default local/input lang per loccalized install cd.
<Kamion> sivang: uh, don't understand
<Kamion> sivang: the way we support kickstart is going to be by translating it into preseed files
<thom> seed updates are now done
<sivang> Kamion: oh ok.
<daniels> Kamion: btw, your -devel suggestion for l-r-m is totally sick
<daniels> Kamion: it should totally parse Packages files instead :P
<daniels> or subscribe to hoary-changes or something
<lamont_r> lunch time
<Kamion> daniels: ha :)
<lamont_r> bbiab
<daniels> actually
<daniels> it could parse the pipermail output
<daniels> not too difficult
* Kamion preemptively kills daniels
<bob2> daniels: dude. 5am.
<ogra> Kamion: please not before 6.8 is in and fully functional ;)
<daniels> bob2: yeah ...
<daniels> ogra: it's already in, dude :)
<ogra> daniels: working ? bugfree ? 
<bob2> daniels: you'll be happy to know I missed krust and die.
* ogra ducks
<daniels> ogra: i wouldn't say bug-free ...
<daniels> bob2: WHAT
<daniels> ogra: i know how to fix your imac bug, btw
<daniels> bob2: how?!?
<ogra> daniels: i already tried to give V/Hsync values....
<daniels> ogra: if you did Option "HorizSync" "12-34", don't
<daniels> you need HorizSync 12-34
<daniels> and VertRefresh 12-34
<daniels> but if that fails, i really have no idea
<ogra> mako: "Point me to the bars full of ubuntu users!" -> should have a wiki page with preferred bars ;)
<ogra> daniels: i'll have to reinstall hoary first..... i'll answer you during the night if it works :)
<Kamion> ogra: I think you mean 6.8.2?
<ogra> Kamion: the hoary version..... yep.... wasnt sure about the minor num.... :)
<mako> ogra: well.if your in nyc, it's going to be the belgian beer bar tonight :)
<mako> ogra: we should have at least half a dozen of them
<ogra> mako: unfortunately i have to drive about 20km to the next bar here...... but if i'm in nyc i'll ask you before ;)
* Kamion goes for dinner
<fabbione> lamont: did pitti fix that ftbfs?
<thom> new sysvinit uploaded, i'm net.dead for the weekend in all probably
<thom> ciao
<fabbione> ciao thom
<fabbione> have fun
<thom> and you
<fabbione> thanks mate
<fabbione> i am going to work in the living room this time :-)
<fabbione> sandpapering walls.. 
<fabbione> sandpapering more walls..
<fabbione> put up glue and glassfiber
* fabbione sighs
<fabbione> it's an endless job
<elmo> is there anyway with ACPI to get a description of what a thermal zone actually relates to/
<elmo> I've got one here that claims to be 8C, which seems, err, dubious, unless it's like a thermal monitor on the right side of a fan or something
<mdz> Kamion: I have seen that bug where udev never seems to get going in d-i
<mdz> Kamion: it's happened to me about 3 times, in qemu and on real hardware, during live cd testing
<mdz> running udevstart clears it up
<mdz> lamont: /etc/apt/sources.list ends up with lines beginning with "echo" in it
<mdz> lamont: in your cloop image
<smurfix> mdz: a few bits in universe still want libflac4. Are you going to fix these too, or should I?
<mdz> smurfix: I don't plan to fix them, no, feel free
<mdz> mjg59: around?
<mjg59> Yup
* lamont_r does some cleanup work.
<lamont_r> mdz: changing the sources.list to match the default install, comments, etc.  (although uncommenting hoary.. - it'll want to include hoary-security once that exists...)
<mdz> mjg59: what data ought we collect in order to have some chance at predicting whether suspend will work properly on a given laptop?
<mjg59> Currently, there's no good way other than doing it on a machine by machine basis
<mjg59> But DMI information ought to be enough
<mdz> mjg59: so we're building a hardware database, and I'd like to know what we should be sure to have in it for the sake of the laptop team
<mjg59> Ah, ok
<mjg59> PCI output and dmi contents ought to be fine
<lamont_r> mdz: wondering if the image build process should remove resolv.conf and hostname, etc, or not...
<mdz> ok, PCI is a done deal, I'll be sure to have DMI in the spec
<mdz> what about non-x86?
<mjg59> The only non-x86 we can deal with is Apple hardware, and that's fairly well understood
<elmo> ITANIUM LAPTOPS!
<lamont_r> elmo: for those who never want to have children!
* Keybuk can think of people who will be getting them for christmas presents
<mxpxpod> has ffmpeg been approved by ubuntu since debian approved it?
<cartman> mxpxpod: debian approved it?
<lamont_r> mdz: alpha2 is what I'm looking for, yes?
<mdz> lamont_r: yes, but it's a bit disappointing
<lamont_r> I see.
<mdz> lamont: it uses 2.6.9 to boot, so you get no modules
<mdz> I didn't realize that until after we takled
<mdz> talked
<lamont_r> I could give you a 2.6.9 kernel on the image, too.
<mdz> I'd rather just get a 2.6.10 initrd from Kamion
<lamont_r> 'a
<lamont_r> 'k, even
<mdz> it looks like today's is already 2.6.10
<mdz> but it doesn't have casper-check :-/
<lamont_r> hrmpf.  /me wanted to download something now though. :-)
<mxpxpod> cartman: that's what I heard on planet.debian.org... go there and search for ffmpeg
<cartman> hmm
<cartman> then mplayer can be accepted too
* lamont_r grumbles at cupsys
<cartman> http://packages.qa.debian.org/f/ffmpeg.html
<cartman> wow they even accepted cvs version
<lamont_r> mdz: wonder if I can get away with stubbing out ps...
<mxpxpod> cartman: also, gst-ffmpeg will get in as well
<cartman> mxpxpod: no need for marillat then
<lamont_r> mdz: cupsys has issues installing in a chroot on a machine where cupsys is running.  feh
<cartman> cool
<lamont_r> mdz: actually, changing cupsys to just use stop-start-daemon like a good boy would do the trick, eh?
<mdz> lamont_r: yeah, and would make it policy-compliant to boot
<lamont_r> this is in _POSTINST_.
<lamont_r> sheesh
<Keybuk> gah, I forgot to cast the correct magic runes to make nautilus build
* Keybuk tries again
<amu> cloop_2.01.5-2ubuntu1_source.changes ACCEPTED
* amu cross fingers
<lamont_r> amu: no crossing fingers until at least ubuntu4
<lamont_r> :-)
<lamont_r> sheesh.  new gnome, xorg, and kernel.  mirror's gonna take a while
* lamont_r hugs pitti
<amu> lamont_r: about 200mb :) 
<lamont_r> ouch
<amu> lamont_r: already tested with your script and got the image 
* sivang chocked to the sight of this: http://webshop.ffii.org/
<amu> lamont_r: cloop_2.01.5-2ubuntu1_20050107-2038-i386-successful ... sometimes it realy help if you're crossing fingers ;) 
<lamont_r> yeah
<smurfix> sivang: exactly. Nothing new unfortunately.
<amu> lamont_r: I try the script now on ppc 
* sivang is not sure if this is relavent here, let me know if it's not.
<sivang> smurfix: but I though the polish one just stopped such from happening no?
<sivang> smurfix: polish vote
<smurfix> "delayed" is more correct. The fight's not over yet. Besides, most of these refer to US patents.
<sivang> smurfix: true, I've spotted acouple of a adobeies there :)
<sivang> smurfix: now that's not a surprise..
* cartman reports another xkb bug with a patch
<smurfix> Hmm. "Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hoary/restricted/binary-i386/Packages.gz  MD5Sum mismatch". Does anybody else see this, or do I need to dropkick my squid?
<lamont_r> I'd vote for dropkickking
* lamont_r needs to run away again for a bit.
<lamont_r> bbiab
<mdz> elmo: if there's anything you can do to kick flac_1.1.1-1 out of the archive prematurely, that'd be swell. the fewer people upgrade to it, the better
<Kamion> mdz: hm? today's initrd should have casper-check ...
<Kamion> mdz: c.f. network --bootproto=static --ip=10.0.2.15 --netmask=255.255.255.0 \
<Kamion> d'oh
<mdz> Kamion: daily-installer-i386/current/images/cdrom/initrd.list doesn't have it
<Kamion> mdz: c.f. http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-i386/20041227ubuntu2/images/cdrom/initrd.list
<Kamion> mdz: use installer-i386
<mdz> oh
<mdz> what is daily- then?
<Kamion> I only uploaded the changes today, the subsequent daily run hasn't happened yet
<mdz> ah
<mdz> so sometimes daily is newer, and sometimes not
<Kamion> mdz: installer-* = when somebody uploads the debian-installer source package; daily-installer-* = nightly based on the last debian-installer source package
<Kamion> exactly; I have a convenient switch on cdimage which I can flip to make it use one or the other
<mdz> Kamion: is there anything else you need in order to add live CDs to the daily CD build process?
<Kamion> time? :-) no, I don't think so
<Kamion> I'm having a look at what's needed now, may be Sunday before it works though
<Kamion> the first cut will be crude and won't use the casper seed
<Kamion> (because it turns out that the current install CD stuff doesn't actually use the installer seed to decide what udebs to include *ahem*)
<Kamion> (at least, not directly)
<mdz> crude would be great
<mdz> a crude autobuilt daily CD is a huge step forward from my crude handbuilt CDs
<Kamion> indeed :)
<mdz> I expect lamont will have the filesystem images available for the big three architectures this evening
<mdz> Kamion: is linux-kernel-restricted-di-2.6 still used?
<elmo> uh
<elmo> what in god's name happened to the seeds
<elmo> mono?
<mdz> elmo: what, just today?
<Kamion> mdz: no
<elmo> yeah, after thom's update
<mdz> Kamion: can it be removed from the archive?
<Kamion> mdz: for hoary, yes
<Kamion> obviously still needed for warty
<mdz> elmo: please remove  linux-kernel-restricted-di-2.6 from hoary
<elmo> is it superseded by something or just obsolete?
<mdz> it's superseded by linux-source
<Kamion> no, it's superseded by linux-restricted-modules-*
<mdz> or linux-restricted-modules
<elmo> done
<elmo> mdz: am I insane or was the verdict on mono that the stuff wasn't ready for supported?
<mdz> elmo: the last verdict was that we would accept and deal with it given an application that we actually wanted (which needed mono)
* Kamion giggles at the "RESPECT MY SECURITAH" comments
<Kamion> wow, overreaction from baz
<mdz> elmo: if it's incredibly fucked or something, we can reconsider...is it actually buildable and installable and stuff?
<Kamion> if you ask for a delta against a patch that doesn't exist, it says "corrupt archive"
<elmo> mdz: I've no idea, I've not looked at it.. I guess I'm just having false memory syndrome
<mvo_> mdz: what's your feeling about the synaptic-dpkg-progress bar stuff I send a mail about to ubuntu-devel some days go? is there a chance to get the needed (small) patches into apt and dpkg? 
<elmo> mdz: the apps they've put in are tomboy and muine
<elmo> anyway, fuck this for a laugh, I'm sending you the list so you can take some of the blame
<elmo> mdz: people.ubuntu.com/~james/to_sync.txt
<seb128> elmo: gstreamer0.8 0.8.8 sync please
<elmo> seb128: do you get super screw-the-freeze powahs for gnome stuff?
<seb128> not afaik, I need that ?
<seb128> elmo: BTW are the package from experimental autosynced ? ie: we have pango 1.6.0-1 from exp, 1.6.0-2 is auto-updated or I need to ask a sync ?
<elmo> oh, we're only in Upstream Version freeze, aren't we
<seb128> that doesn't affect GNOME
<elmo> seb128: nope, not auto-synced, my syncing isn't clever enough to keep track of where packages came from, unfortunately
<elmo> seb128: ah, okay --> supah powahs
<seb128> elmo: ok, so we need pango1.0 1.6.0-2 from exp :)
<seb128> elmo: yeah, gimme the supah powaaaahs :)
<seb128> elmo: the new versions are blocked by a technical way, or we just count on people to not upload a new version ?
<elmo> seb128: we rely on the iron fist of mdz
<seb128> ah ah
<elmo> dude, he can walk up walls; I wouldn't mess with him
<seb128> :)
<seb128> bah, I don't care, I've a special GNOME card which is a joker :p
<elmo> that's a harsh, yet fair way to describe jdub
<elmo> you mean pango 1.8.0-2, btw, right?
<seb128> oups, yes
<elmo> ok, both syncs done
<seb128> thanks
<Keybuk> seb128: I guess you know that the panel's Places menu notify-me-it-changed-fu is pooched, ya?
<Kamion> sheesh, the CDs were still booting with devfs=mount,dall
* Kamion nukes that
<seb128> Keybuk: iz inotify bug
<seb128> or gamin
<seb128> Keybuk: #5176
<Keybuk> *chuckle*  Jeff's "perfect solution" in "not actually finished yet" shocker
<Keybuk> is there an easy/quick way to turn off inotify, that you know of?
* Kamion wonders why exactly the CDs boot with init=/linuxrc
<mvo_> I'm going to bed now
<mdz> Kamion: I wondered that as well
<smurfix> Kamion: Looks like a "we have a problem we don't quite understand, and this fixes the symptom" hack.
<sivang> mvo_: night
<mvo_> night sivang, night all
<Kamion> mdz: I've removed it, fairly certain it's bogus
<Kamion> smurfix: I think it's actually "this was needed somewhere in the dawn of time and nobody remembered to remove it when things changed"
<smurfix> Kamion: Yeah -- the boundaries between these two tend to be somewhat fluid, so we may well both be right.
<Kamion> :-)
<mako> whiprush: you around?
<whiprush> yeah
<Kamion> mdz,lamont: OK, I think I've got most of the bits together to build CDs now; all I need is the exact URL.
<mako> whiprush: cool.. i've got #16 done. do you have time to read through it? fix errors/etc?
<whiprush> sure, just getting home, gimme 10 to settle in.
<mdz> Kamion: http://people.ubuntu.com/~lamont/mdz/livecd.cloop is the one that he gave me
<Kamion> lamont: (as in, the tail of the URL, I know everything up to .../~buildd/)
<mdz> that has 2.6.10 modules on it and seems to work with my test CD
<Kamion> mdz: yeah, that's not the per-arch buildd thing I had earlier though
<mako> whiprush: i'm gonna run off for an hour or so.. so i'll just let you have it :)
<Kamion> though I s'pose I can kick off a test build with that
<mako> whiprush: email me tonight and i'll just merge back in and post when i'm done :)
<mako> whiprush: also, add something in the intro about how you're helping out now :)
<whiprush> k
<Kamion> also I've only done the bootloader bits for amd64 and i386 so far
<mdz> Kamion: I hacked up a test CD with kernel module udebs from the archive + initrd/vmlinuz from your d-i upload + lamont's filesystem image, and it worked
<mako> whiprush: cool.. the new traffic is in my baz archive on the mirror
<Kamion> eek, it's confused the hell out of diff-tasks
<mako> whiprush: send me an email or an irc msg when you think it's good to go. and thanks!
<whiprush> k
<mdz> what's diff-tasks?
<mako> i have a debian+ubuntu party i need get ready for for (it's at my house!)
<Kamion> mdz: the thing that runs each cdimage cron.daily to mail me about differences in base/desktop/ship/supported since the last cron.daily
<Kamion> hm, jigdo not such a good idea on the live image :)
<mdz> no...it would be sweet to make rsync work, though
<mdz> I wonder how much work it would be to graft the gzip --rsyncable bits onto create_compressed_fs
<seb128> Keybuk: oups, better to highlight me to be sure I read a reply :p Rebuilding gamin with --disable-inotify should do it I guess
<mdz> Kamion: while you're there, it would be nice to have a much larger ramdisk
<Kamion> where's that set?
<crimsun> do we know about http://isec.pl/vulnerabilities/isec-0021-uselib.txt ? (I only did a rudimentary /lastlog -regexp "isec.pl", sorry if it's a repeat)
<mdz> Kamion: ramdisk_size on the kernel command line usually
<Kamion> mdz: doesn't that only govern the initrd?
<mdz> when the live CD runs out of ramdisk, everything falls apart
<mdz> Kamion: I'm pretty sure it sets the size of all /dev/ramN
<mdz> the current one seems to be not much more than enough to get the system going
<mdz> we'll bring that requirement down through tuning, but for now...
<Kamion> crimsun: pitti's aware, yeah, should be fixed soon
<crimsun> Kamion: all right, thanks.
<Kamion> mdz: does setting it to $HUGE impose memory requirements?
<mdz> Kamion: it shouldn't
<Kamion> i.e. if you set it to 64MB will it break a 32MB system?
<Kamion> ok
<mdz> should be virtual memory
<mdz> I certainly don't think it allocates 20M or whatever now
<sivang> seb128: GNOME is exempt from UFV as I heared :)
<seb128> sivang: yep, that would be a non-sense to freeze 2.9.3 ...
<mdz> The RAM disk dynamically grows as more space is required. It does this by using
<mdz> RAM from the buffer cache. The driver marks the buffers it is using as dirty
<mdz> so that the VM subsystem does not try to reclaim them later.
<sivang> seb128: yes, if we did, we would loose all the wonderful magic of network-admin :)
<seb128> sivang: there is something new planned ?
<sivang> seb128: garnacho has been working hard on applet integration 
<seb128> cool
<sivang> seb128: for monitoring the isdn connection and others..
<Kamion> bleh, it included all the .debs too
<Kamion> confused
<mdz> that'll be a big image
<Kamion> yeah :)
<Kamion> >1GB
<Kamion> oh, I know
* Kamion rebuilds
<gsuveg> re
<mdz> jdub: ping?
#ubuntu-devel 2005-01-19
<Kamion> hm, that looks slightly more reasonable now
<amu> mdz: successfully builded images for powerpc,amd64 and i386 
<lamont> Kamion: you want urls, eh>
<mdz> amu: by hand?
<Kamion> mdz: give http://cdimage.ubuntu.com/daily-live/20050107/hoary-live-i386.iso a try
<amu> mdz: by script 
<mdz> Kamion: can you make rsync:// work?
<Kamion> it does
<mdz> @ERROR: Unknown module 'daily-live'
<Kamion> put /cdimage/ first
<Kamion> but there's a maxconn limit :(
<mdz> @ERROR: max connections (15) reached - try again later
<mdz> gah
<Kamion> you have an account on little, rsync over ssh :)
<mdz> what's the local path?
<Kamion> mdz: /srv/cdimage.no-name-yet.com/www/full/daily-live/20050107
<lamont> ew.  something bloated.
<lamont> 637MB
<lamont> Kamion: i386 is there
<amu> lamont: amd64?
<lamont> amu: building
<Kamion> lamont: ok, but won't be able to do anything with it until tomorrow
<amu> lamont: the amd64 image is 100mb bigger compared to i386
<amu> *** Error -5 compressing block 0! (compressed=0x7fbffff830, len=548682070016, uncompressed=0x526010, blocksize=65536)
<amu> ./livecd.sh: line 130:  1630 Segmentation fault      create_compressed_fs $IMG 65536 >livecd.cloop
<Kamion> ok, I'm off for the night now ...
<amu> Kamion: n8
<mdz> total size is 547250176  speedup is 81.06
<mdz> not bad
<mdz> Kamion: night
<mdz> amu: I have a quest for you
<mdz> amu: we need to find out what is doing so much writing during startup on the live CD
<mdz> eek
<mdz> Kamion: it's broke
<amu> mdz: i#ll look to it 
<mdz> amu: it uses like 15M of snapshot space just to boot
<mdz> Kamion: could not find kernel image: linux
<amu> mdz: means memoryuseage is d-i + 15M ? 
<Kamion> mdz: did you explicitly type 'linux' at the boot prompt?
<mdz> amu: dmsetup status /dev/mapper/casper-snapshot
<mdz> Kamion: I tried both pressing enter and typing 'linux'
<Kamion> bleh, ok, maybe isolinux defaults to linux or something
<lamont> aum: note that the script has probably changed since you grabbed a copy...
<mdz> what should the name be?
<Kamion> it's probably broken, let me attempt to fix/rebuild
<amu> mdz: which version we talking? Kamion's? your's? mine? 
<mdz> amu: they should all have the same characteristics
<amu> lamont: ok, still same place? 
<mdz> amu: run dmsetup status /dev/mapper/casper-snapshot
<lamont> amu: not quite yet...
<Kamion> AARGH, MY CAPS LOCK OR SHIFT KEY OR SOMETHING IS STUCK
<mdz> Kamion: if it's not trivial to fix, it can wait, don't lose sleep over it
<Kamion> mdz: try 20050107.1, see how it goes
<mdz> Kamion: same result
<Kamion> erk, I was doing repeated >isolinux.cfg rather than >>isolinux.cfg
<Kamion> 20050107.2 will happen in a moment and should fix that problem; in the meantime bed :)
<Kamion> try that when it appears in a few minutes
<Kamion> it's up
<elmo> oh! mirnyy has space now; I can round-robin cdimage too
<elmo> [<de-randomizing>that'll help with the rsync limits</>] 
<mdz> rsyncing
<mdz> elmo: oh, the limit is for the sake of server resources (rather than bandwidth)?
<mdz> Kamion: booting now
<elmo> mdz: totally resources - 25 was hitting the box so hard, colin couldn't sync a sounder image
<mdz> my word
<mdz> somebody needs to fix rsync
<lamont> + create_compressed_fs livecd.fsimg 65536
<lamont> Opening input: File too large
<lamont> Hrmpf.
<lamont> mdz: so how do you feel about just making the file system an even maxint in size?
<mdz> lamont: that's fine, but we ought to fix create_compressed_fs
<mdz> should be trivial
<lamont> yeah
<lamont> elmo about?
<mdz> Kamion: it's gotten as far as starting sysvinit; looks good, thanks
<elmo> yeah
<lamont> mdz: this pass, I'll just hardcode the size, then I'll fix cloop
<mdz> lamont: can we quash that scary postfix inode warning?
<lamont> mdz: paste it to me
<mdz> can't paste from qemu, bu tit goes like this:
<mdz> QUEUE FILES WERE RENAMED TO MATCH INODE NUMBERS OH MY GOD
<mdz> THE GODDAMN SKY IS FALLING
<lamont> this on livecd?
<mdz> something like that
<mdz> yes
<lamont> there _shouldn't_ be any queue files...
* lamont goes to look
<mdz> probably got some from debconf or whatever
<sladen> daniels: on the X40 does s4_bios need a special partition creating?
<mdz> also
<mdz> lamont: sources.list still says 'echo'
<mdz> oh, nm
<mdz> this is the same image
<lamont> 3 messages sent during the install.  I'll make em go away
<mdz> hmm, what would be the best way to stop cron.daily from running on the live CD, I wonder
<mdz> as nice as it is to have an up-to-date locate db, it's not very convenient to have it start up soon after boot...
<mdz> I suppose I should just not let it start up
<mdz> lamont: hmm, /etc/init.d/dbus-1 is missing
<mdz> lamont: are you keeping a list?
<lamont> and mkinitrd?
<lamont> and sbin/udevd
<lamont> udevd is OK
<lamont> is this in the latest image, or the one from lunch?
<lamont> verified OK in the current image
<lamont> diverts were kinda borked at lunch, like I said
<lamont> DIVERTS="usr/sbin/mkinitrd usr/sbin/invoke-rc.d etc/init.d/dbus-1 sbin/udevd"
<lamont> but udevd came in later, and invoke-rc.d apparently got better somehow...
<lamont> any changes to /etc/kernel-img.conf?
<mdz> lamont: in both
<mdz> colin used the same fs image from lunch to build the test CD
<lamont> if you want etc/cron.daily/man-db to go away, that can be arranged...
<lamont> does it get ran at isntall time?
<mdz> nah, if I just don't start anacron, it fixes all that
* lamont throws another round of builds into the fire, with postfix queues flushed, but cron.daily/man-db intact
<mdz> cron suppresses the daily stuff when it sees anacron is installed
<mdz> lamont: you know what would be nice
<mdz> lamont: if at the end of the build, you ran cron.daily/man-db and cron.daily/slocate
<mdz> brb, reboot
<elmo> night all
<lamont> night elmo
<sivang> night elmo
<ogra> night
<lamont> pitti around?
<mdz> gah, my panel is fucked
<mdz> I have Blank Panel Syndrome
<robertj> mdz: BPS
<robertj> it's kinda refreshing though
<robertj> minimalism is in
<mdz> does anyone know the workaround for the panel-bug-o-day?
<robertj> dunno, about to find out ;)
<robertj> 1m40s remaining on my download
<sladen> mdz: I found a reliable   sudo pkill -u mdz
<Keybuk> seb128: awake?
<sladen> mdz: and log back in
<sladen> mdz: there's a race in there somewhere, but I couldn't find it
<seb128> Keybuk: yep
<Keybuk> seb128: http://people.ubuntu.com/~scott/nautilus-2.9.1_keybuk-places-bookmarks.patch
<mdz> thanks
<seb128> Keybuk: cool, thanks
<mdz> seb128: my mixer applet is showing the red crossed-out icon even when it is unmuted
<seb128> Keybuk: that's a bit late to read it now, but I'll try it tomorrow and let you know
<seb128> mdz: do you have a way to reproduce it ? 
<mdz> seb128: it is happening right now; I have never seen it before
<mdz> seb128: I lowered the volume to zero and brought it back up, and now the icon is normal
<lamont> mdz: etc/cron.daily/man-db is _scary_
<mdz> seb128: but when I mute, it still doesn't change
<seb128> how do you mute ? keybinding ?
<mdz> context menu
<seb128> right, same bug here
<mdz> seb128: the panel startup problem, is it #4794?
<mdz> it just happened to me on the first login after a reboot, so no processes running
<lamont> mdz: man-db starts background processes (why???), and that causes a race condition that I'm not going near.
<seb128> startup problem ?
<seb128> freeze you mean ? nautilus and blank panels ?
<mdz> seb128: I logged in, and got empty panels
<mdz> right
<seb128> yeah
<seb128> that's it
<mdz> lamont: background processes? where?
<seb128> seems to be a deadlock in gnome-vfs-daemon
<lamont> cat /etc/cron.daily/man-db
<seb128> I've not had it since mataro
<mdz> lamont: I did
<lamont> start-stop-daemon --startas mandb
<lamont> etc
<mdz> start-stop-daemon doesn't fork unless you give it -b
<seb128> I thought it was fixed with the hal support off in gnome-vfs, but apparently not :/
<lamont> oh. that's better then.
<mdz> seb128: are you able to reproduce it?
<seb128> no
<mdz> is there anything I can do?
<seb128> I've not had it since mataro
<mdz> (if I see it again)
<sladen> while we're on the subject;  gnome-battery-applet blinking whilst charging is annoying and distracting
<mirak> seb128: yes after a reboot
<mirak> seb128: I just rebooted and it's happened
<mirak> however it didn't happened5 days ago when I booted the computer
<seb128> rebuilt a non-stripped libgnomevfs2-common (yeah, the package split is borked, I wonder why a -common has a server part)
<seb128> and get a backtrace with symboles of the lock
<seb128> to compare with the previous one in #4794
<seb128> which was with the hal support
<mdz> are you planning to upload gnomevfs sometime soon?
<mdz> if not, I will build it for debug now
<seb128> no, not in the next days
<mdz> you could upload an unstripped version to the archive so that everyone can debug it :-)
<seb128> yeah, I want to fix that stupid "-common contains the server" stuff
<seb128> -common should be an arch all, and the server should be in a -bin or with the lib
<mdz> not with the lib
<mdz> unless it's versioned with it?
<seb128> no
<seb128> it should be in a -bin in fact
<seb128> with the gnomevfs-ls/cat/info/copy/...
<lamont> seb?
<seb128> lamont: include the full nickcname to highlight :p
<lamont> yeah, sorry
<seb128> mdz: you disagree with the place menu not working as a target to fix for Hoary ?
<seb128> (#5123)
<amu> mdz: /usr/lib/prebaseconfig.d writes a lot and takes the long time .... 
<jdub> mdz: pong
<seb128> jdub: gpdf will probably get type3 fonts support in the next days (that works with evince and will be backported to gpdf), I think we should set it as the default pdf viewer for hoary :)
<jdub> seb128: agree.
<mdz> seb128: I assumed the submitter had set it
<mdz> seb128: since it was also BLOCKER
<mdz> jdub: status of adding upgrade-notifier to the default session?
<mdz> amu: which bit?
<seb128> mdz: I've set both. Blocker is not a "has to be fixed" ?
<seb128> mdz: imho this one has to be fixed for hoary, having place not working sucks
<mdz> seb128: blocker is WAIT DON'T RELEASE YET
<mdz> seb128: I agree, it ought to be fixed
<mdz> but I don't see much point in setting blocker severity on bugs when we are still far from release
<seb128> is blocker appropriate or not ? just to know for the next time :)
<jdub> mdz: that's one for seb
<mdz> seb128: does it make it easier for you to track your bugs?
<seb128> yep
<mdz> if so, go ahead
<seb128> ok, thanks
<mdz> often people file random bugs with severity=blocker, and they show up in my global reports
<seb128> yeah, I know :)
<mdz> seb128: can you add upgrade-notifier to the default session?
<seb128> I should have added a comment, I've thinked about that after clicking on the button :p
<seb128> mdz: ok
<mdz> seb128: do you add a dependency when you do that, or should I change the seed?
<mdz> (for upgrade-notifier)
<mdz> er
<mdz> update-notifier
<mdz> we have both in the archive right now, ick
<seb128> change the seed
<mdz> and update-notifier is in universe, blecch
<seb128> session start it if available
<seb128> I don't need to add a depends
<mdz> jdub: update-manager ready for desktop as well?
<mdz> seb128: ok, thanks
<seb128> np
<seb128> time to sleep, 'night guys
<jdub> mdz: no, mvo and i have to talk about those before they're added to the seed
<mdz> ok
<mdz> GAH
<mdz> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<mdz> this is getting so old
<amu> mdz: didnt found it out, i've also some problems after using some programs, the snaphot becomes invalid, stauts is 0 3965184 snapshot 16904/20480 
<amu> mdz: 16904 grows up to 20480, after it reaches 20480, i cannot run other programs
* amu moves to bed 
<azeem> amu: sleep well
<mdz> amu: invalid means you filled it up
<mdz> after which it won't work anymore
<amu> did't catched it, if it goes near to 20480   
<amu> azeem: hi
<mdz> amu: you can boot with ramdisk_size=65536 to get more space
<amu> sure 
<mdz> but I think we can get it down to a more reasonable level with some tweaks
<lamont> mdz/Kamion: i386: 526249079; powerpc: 567143169; amd64: waiting for kernel love on the buildd machine;  ia64: broken depends
<mdz> lamont: kernel love?
<lamont> lacks loopback support
<mdz> lamont: did elmo not compile the loop module or something? :-P
<mdz> haha
<lamont> modules, what modules.  this is an elmo kernel
<mdz> CONFIG_ELMO=y
<lamont> will have loopback support tomorrow london time
<amu> lamont: could you run updatedb before clooping the chroot 
<lamont> amu: we run /etc/cron.daily/{man-db,slocate}
<mdz> amu: aha
<mdz> amu: for some reason the noatime is not taking effect
<mdz> or it is being removed by the mount --move
<mdz> that will cause a huge number of writes
<mdz> or maybe busybox mount doesn't even support -o properly?
<lamont> mdz: hppa: ubuntu-desktop not installable (well, has no depends); sparc: unknown
<amu> mdz: it's better, i run just a tty, guess i've to setup X :) 
<mdz> hmm, no, busybox mount seems ok
<mdz> amu: mount -o remount,noatime /dev/mapper/casper-snapshot /
<mdz> should save a lot
<lamont> mdz: as in the friendly ghost?
<mdz> lamont: yes
<mdz> or the dopest ghost in town
<lamont> I thought he turned back into a dead little boy. :-)
<amu> mdz: yeah it save a lot, .... still trying to configure X 
<stub> I've got a crippled hedgehog. My background and my panels have not loaded (the panels are there, but blank). Is there a fix for this?
<mdz> I don't know where it loses noatime though
<mdz> I tested a mount --move on my desktop, and it preserved noatime
<mdz> maybe it has to do with mtab
<salgado> I've build evolution with debugging symbols (as file /usr/bin/evolution confirms me that), but when I run it in gdb, I can't get those symbols.
<salgado> I've built evolution according to http://www.ubuntulinux.org/wiki/DebuggingProgramCrash. is there something I may be missing?
<mdz> nope, tested with mount -n
<mdz> wtf
<mdz> maybe the pivot changes it?
<lamont> mdz: did you want those cloop's where you could fetch them?
<mdz> lamont: what's responsible for writing the entry for root into mtab?
<mdz> lamont: sure, I'll download them so I can rsync the full images faster tomorrow
<lamont> I think mount does it, but have'nt had to look before..
<mdz> it's one of the early init scripts
<mdz> checkroot.sh
<mdz> salgado: those instructions should do it
<mdz> salgado: if file /usr/bin/evolution says it's not stripped, then you did the right thing
<mdz> salgado: can you paste the gdb output to me in /msg ?
<salgado> mdz: sure
<lamont> mdz: http://people.ubuntu.com/~lamont/livecd/livecd-20050108-{i386,powerpc}.cloop
<lamont> mdz: how often do you want them built, btw?
<mdz> lamont: daily is fine
<mdz> lamont: daily, in time for the daily CD run
<lamont> 0615 is when the d-i build runs, sounds like about a good time.
<amu> mdz: i'll play little more tomorrow with it, too late now
<mdz> amu: ok, good night
<mdz> amu: tomorrow, see if you can find out where the noatime goes away
<mdz> so we can fix that
<amu> mdz: last suggestion, what's about a swapfile on the cd, i've a lot ram, probalby other user have not too much ... 
<amu> mdz: where do you put your last d-i? i'll try to build also homeeditions iso's ;) 
<amu> mdz: k
<mdz> amu: on the cd?
<mdz> a swap file on read-only media is hard to use :-)
<mdz> I do think we should detect and use swap on the hard disk
<lamont> mdz: certainly
<sivang> mdz: fallback to RAM drive if there's not enough space?
<amu> n8 -R * 
<mdz> sivang: very funny
<mdz> amu: I am using the daily d-i build
<mdz> no need to build it here anymore
<lamont> mdz: so daily install cd, with a bit of hackification?
<mdz> lamont: what I'm using right now is the CD Colin built, in fact
<mdz> unmodified
* lamont needs a 'so you want to build a home-edition livecd' cookbook
<mdz> it's way easy
<mdz> all you need to do is put the cloop image in /casper/filesystem.cloop
<mdz> and pass casper/enable=true on the kernel command line
<mdz> boom
<mdz> (assuming you have a full complement of udebs, including casper-udeb, on the CD)
<mdz> so you could start from an install CD, remove all the .debs, drop in a filesyste image, tweak isolinux, and you're done
<lamont>  /casper/filesystem.cloop on the CD, yes?
<lamont> or I could fetch hoary-live-i386.iso and use that, eh?
<mdz> lamont: oh, we're going to want pcmcia-cs in the cloop image
<lamont> if I tweak filesystem.cloop in the iso, are there any checksum files to fix?
<mdz> lamont: nope
* lamont sighs, adds pcmcia-cs.  anything else?
<mdz> if you're starting from a live CD, you can swap in any filesystem you want
<mdz> lamont: actually, hmm
* lamont contemplates putting nethack on the system...
<mdz> the reason we don't install pcmcia-cs by default is that it breaks some machines
<lamont> and frozen-bubble/kobodl, of course.
<mdz> we can arrange for it to be installed if needed, of course...
<mdz> but that wastes valuable COW space
<lamont> I guess the udeb isn't enough?
<mdz> don't worry about it just yet
<mdz> I need to consult with colin on the pcmcia-cs situation
<daniels> sladen: i don't know, sorry
<mdz> daniels: hey, your magic xkb dvorak recipe stopped working
<mdz> daniels: your xkb hero status is in jeopardy
<daniels> mdz: so us(pc104)+dvorak(basic) as the symbol set is no longer any good?  what happened?
<mdz> daniels: dunno, did anything change xkb-wise in that last X upload?
<mdz> (correct, it no longer does what I want)
<daniels> mdz: yeah, a little, but nothing I would think would be relevant
<mdz> (i.e., give me an Alt_R)
<mdz> daniels: it should be setxkbmap -keymap 'us(pc104)+dvorak(basic)', right?
<mdz> I thought it was just setxkbmap 'us...dvorak...'
<mdz> but that doesn't work, so I assumed I had done it differently before
<daniels> er, -symbols 'us(pc104)+dvorak(basic)', i think
<mdz> mizar:[~/data/src/canonical/casper]  setxkbmap  'us(pc104)+dvorak(basic)'
<mdz> Error loading new keyboard description
<mdz> hmm
<mdz> ahh, ok, maybe that was it
<mdz> daniels: what do I put in xorg.conf?
<daniels> rtw c br, e.ucbcyc.nf dak. ekrpat
<daniels> mdz: just put us(pc104)+dvorak(basic) in xorg.conf for XkbSymbols
<daniels> mdz: and if you're going to keep breaking dvorak, you need to teach it to me
<mdz> daniels: switch your keycaps around
<mdz> you probably don't need to look at the keycaps for qwerty anyway
<daniels> mdz: well, good point
<daniels> (btw, the above random garbled text was something like, 'yeah, switching into dvorak works')
<mdz> daniels: when I was learning, I would leave an image viewer on sticky with an image of the layout
<daniels> mdz: heh :)
<daniels> mdz: that would work nicely on my crt (21", 1600x1200), but maybe not so much on the laptop
<mdz> daniels: should I delete my XkbModel/XkbLayout when I add XkbSymbols?
<daniels> mdz: think it should be fine as is; what is it now?
<mdz>         Option          "XkbRules"      "xorg"
<mdz>         Option          "XkbModel"      "pc104"
<mdz>         Option          "XkbLayout"     "dvorak"
<daniels> ah, I see
<daniels> so change XkbLayout to "us(pc104)+dvorak(basic)"
<daniels> and leave model and rules alone
<daniels> i'm not entirely sure it's the most elegant, but it should work
<sivang> mdz: ;)
<srbaker> uh.  if i'm going to write a gnome bittorrent gui, as listed on the Ubuntu Bounties page, where do i find out the person to contact?
<azeem> I heard the latest bittorenr GUI is a much improved GTK one, so you might want to check that first (I don't use bittorent)
<mdz> daniels: but setxkbmap -layout 'us(pc104)+dvorak(basic)' doesn't work
<mdz> but XkbLayout will?
<mdz> srbaker: that would be me
<srbaker> mdz, ah.  is there a list of requirements?
<srbaker> mdz, i'm curious what the requirements are, and what the value is.
<mdz> srbaker: yes, there was a discussion on the mailing list where we worked out the requirements
<srbaker> mdz, i'm trying to schedule it in.
<srbaker> oh, okay.  ML archives then.
<daniels> mdz: must be XkbSymbols, then
<mdz> srbaker: though, someone mentioned on the wiki that bittorrent upstream seems to be developing a pygtk gui
<mdz> so there may be a starting point there
<daniels> mdz: try XkbLayout "us" XkbSymbols "dvorak(basic)"
<mdz> daniels: and leave everything else in place?
<srbaker> yeah.
<srbaker> mdz, well, my plan was something like azureus, only not so heft.
<srbaker> hefty
<srbaker> mdz, i'm trying to schedule as many of these bounties as i can in between client obligations
<mdz> daniels: "setxkbmap us; setxkbmap -symbols 'dvorak(basic)'" breaks my alt keys
<mdz> srbaker: what other projects are you interested in working on?
<mdz> srbaker: feel free to email me proposals
<daniels> mdz: ok, so try setting (in the config -- you want to start another X server) XkbLayout "dvorak(basic)", and XkbSymbols "us"
<daniels> mdz: (if you leave XkbLayout as "dvorak" and have XkbSymbols as "us(pc104)+dvorak(basic)", it should work, but I'm looking for something slightly more elegant
<mdz> I'll play with it later
<daniels> cool
<daniels> sorry I couldn't be of more help; my grasp of XKB is kind of handwavey
<daniels> i am still neither of the people in the world that understand it properly
<lamont> mdz: If I'm remembering my last foggy conversation with doko, gcc-3.4/glibc/libunwind on ia64 need some bootstrapping love.  but I'm not 100% sure - will chat with doko and figure out the right path
* lamont wanders off for the evening.  night all
<daniels> night dude
<KeyserSoze> anyone know this other KeyserSoze chap?
<Rez> no, but you should use recover and release
<KeyserSoze> he keeps taking my nick, it's a PITA to have to have the nickserv kick him
<KeyserSoze> Rez, is recover and release any better than ghost?
<Rez> yes.  when the broken client rejoins the nick will still be taken so it can't repeat the cycle
<KeyserSoze> does either step of recover/release actually change my nick?  or do i still need to do /nick?
* KeyserSoze read the /msg nickserv help recover and help release
<KeyserSoze> anyway, thanks for the advice
<daniels> gnuh, ndiswrapper really is broken :\
<daniels> fabbione: for -4 or whatever, could you please put in a new kernelside patch?
<daniels> i swear someone is trying to fuck with me
<daniels> neither of my optical drives on my desktop would eject via the button -- i had to use the eject program, which would eject the drive and then return EINVAL
<daniels> so then I rebooted it, and it wouldn't power on with the optical drives connected
<daniels> then it stopped powering on at all
<daniels> the latter being due to the fact my power switch was disconnected.
<daniels> ho ho ho
<daniels> acx100 is broken, because that wasn't enough
<fabbione> daniels: there is a new ndis for -4
<fabbione> i think
<fabbione> no
<fabbione> it's already 0.12
<fabbione> daniels: there are no newer releases of ndis
<daniels> fabbione: ndiswrapper-utils is 1.0rc2
<fabbione> GRRRR
<daniels> Jan  8 16:27:06 nanasawa loadndisdriver: loadndisdriver: main(462): version 1.0rc1 started
<fabbione> that's user space crap
<daniels> Jan  8 16:27:06 nanasawa loadndisdriver: loadndisdriver: main(488): version 1.0rc1 doesn't match driver version 0.12
<daniels> sorry, 1.0rc1
<fabbione> yeah i know...
<fabbione> ok i will have to update it again to 1.0rc2
<daniels> if it's already 1.0rc1, don't worry
<daniels> i might just have an outdated l-i-2.6.10
<fabbione> no.. in 2.6.10 there is 0.12
<fabbione> there are no updates from zcx100
<fabbione> acx100 even
<daniels> i have a bug to file on acx100, anyway
<fabbione> yeah go ahead
<fabbione> what is broken anyway?
<daniels> firmware loading; doesn't find it
<daniels> Jan  8 11:08:14 nanasawa kernel: Firmware: '/lib/hotplug/firmware/TIACX111.BIN' not found. Trying alternative firmware.
<daniels> needs to be trying TIACX111.BIN-version
<fabbione> that's not a driver bug
<daniels> #5329
<daniels> mmm?
<fabbione> hotplug loads the firmwares
<fabbione> etc/hotplug/firmware.agent
<daniels> so hotplug should be appending the version?
<fabbione> yes and it does
<fabbione> we can check if it is hardcoded for a mistake in the driver
<fabbione> but do this:
<fabbione> http://people.ubuntulinux.org/~fabbione/firmware.agent
<fabbione> grab this firmware.agent
<fabbione> it has a bunch of debugging stuff
<fabbione> use it in place of the hotplug one
<daniels> ok
<daniels> brb
<fabbione> and send me the output when trying to load the driver
<fabbione> maj?
<fabbione> are you in somekind of crack dude?
<fabbione> -> normal
<daniels> don't think it's getting called
<daniels> there's nothing in syslog
<fabbione> hmmm
<fabbione> -char default_firmware_dir[]  = "/usr/share/acx";
<fabbione> +char default_firmware_dir[]  = "/lib/hotplug/firmware";
<fabbione>         if (firmware_dir) sprintf(filename,"%s/ACX100_USB.bin",firmware_dir);
<fabbione> -       else sprintf(filename,"/usr/share/acx/ACX100_USB.bin");
<fabbione> +       else sprintf(filename,"/lib/hotplug/firmware/ACX100_USB.bin");
<daniels> +       if (priv->chip_type == CHIPTYPE_ACX111) {
<daniels> +               sprintf(filename,"%s/TIACX111.BIN", firmware_dir); /* combined firmware */
<daniels> +               if (OK != acx_check_file(filename)) {
<daniels> +                       acxlog(L_INIT, "Firmware: '%s' not found. Trying alternative firmware.\n", filename);
<daniels> er, yeah
<daniels> great minds, and all that
<zenrox> lol
<fabbione> yeah i see
<fabbione> damn shit
<daniels> yeah, needs to be hacked to use hotplug
<daniels> in the meantime, we could just do a small sed :)
<fabbione> daniels: i will try to get it fixed for -4
<daniels> fabbione: thanks mate, much appreciated
* daniels purges ndiswrapper.
<fabbione> i have the security thing pending a shit load of bug fixes
<fabbione> so i am not sure i can manage for -4
<daniels> that's fine -- it wfm now ;)
<fabbione> http://people.ubuntulinux.org/~fabbione/bla
<fabbione> this is the partial changelog
<fabbione> and the "stolen from upstream" is only 40% of bk9 
<fabbione> i need to process the other 60% of bk9 + bkX on monday
<daniels> good god, that's insane
<fabbione> and that i have scripts that do a lot for me :-)
<fabbione>  /proc/sys/kernel/bootloader_type:
<fabbione>       . Add patch stolen-from-head_bootloader-type.dpatch.
<daniels> heh :)
<fabbione> this one is cool
<daniels> oh
<fabbione> it writes the boot loader name in proc
<daniels> so that tells you ... lilo? grub?
<daniels> nice!
<fabbione> no need to understand if it was lilo or grub
<fabbione> a postinst can just check that to see what to do
<fabbione> there is some stuff that is really really nice
<fabbione> like the readahead patch
<fabbione> with 25% to 100% gain in speed
<fabbione> - mm: overcommit updates:
<fabbione>       . Add patch stolen-from-head_mm-overcommit-updates.dpatch.
<daniels> wow, that's awesome
<fabbione> this one for shared users...
<fabbione>  - mark_page_accessed() for read()s on non-page boundaries:
<fabbione>       . Add patch stolen-from-head_mark_page_accessed.dpatch.
<daniels> and next week (hopefully) we get new fglrx too
<fabbione> this ons is for DB
<daniels> cool time :)
<fabbione> approx 50% faster
<fabbione> ah nice
<daniels> finally with xorg + amd64 + pcie
<fabbione> eheh
<fabbione> ati sucks anyway
<fabbione> as much as nvidia
<fabbione> i want my CGA card back
<crimsun> my hercules monochrome with integrated printer port rocks your cga card
<fabbione> right...
<fabbione> :(
<daniels> holy crap man, 1904FPS with fglrx in xorg
<daniels> THIS DRIVER IS OFF THE HOOK
<fabbione> ahahha
<fabbione> cr4ck
<daniels> fabbione: do we have a working installer for sparc?
<fabbione> not 100%
<fabbione> Kamion was mumbling something about silo-installer
<fabbione> and you need the binaries in the archive to isntall
<fabbione> otherwise you can just upgrade sarge -> hoary
<daniels> ahr
<fabbione> that's doable
<fabbione> and either i build or i test the install :(
<daniels> heh
<daniels> just been thinking about getting the u5 up
<fabbione> yeah that would be leet
<fabbione> but just so a minimal sarge install
<fabbione> and switch to hoary
<fabbione> you need 2 deb sources
<fabbione> one for the sparc binaries
<fabbione> and one for _all.deb
<fabbione> in anycase the binaries are on people/~fabbione/sparc
<fabbione> for the _all you need a trick with i386 pool
<fabbione> it was something like:
<fabbione> deb http://a.u.c/ubuntu hoary/main/binary-i386 ./
<daniels> heh :)
<fabbione> well ... time to go for wedding cake hunting
<fabbione> hmm i need to update the Packages file on people...
<fabbione> bah later
<bob2> mjg59: do you ever see netapplet either crash and give the "restart/inform developers/close" box or just silently disappear after a resume?
<cartman> hmm now that ffmpeg is in debian will it be in hoary too?
<seb128> yes
<seb128> universe
<cartman> damned :/
<cartman> won't be in supported part?
<Kamion> lamont: man-db's cron.daily uses start-stop-daemon as a cheap way to switch users that doesn't generate noise entries and therefore cause confused users to file bugs ...
<Kamion> er, "noisy syslog entries"
<seb128> cartman: no, patents issues
<cartman> well its in debian...
<cartman> also those patents doesn't exist in EU
<seb128> and ?
<seb128> and ?
<cartman> put it in multiverse? :)
<seb128> I said universe
<Kamion> cartman: don't see how that would help you, neither universe nor multiverse is supported
<seb128> what's the problem with it
<cartman> Kamion: argh
<cartman> seb128: unsupported
<seb128> yeah, multiverse will not help
<Kamion> multiverse is, if anything, *less* supported
<Kamion> because it's a cesspit
<Kamion> mdz: for the moment, daily-live builds are kicked off manually by me because I haven't quite fixed the publisher yet; let me know when you need new builds
<two-face> hi
<elmo> webserver (www.ubuntulinux.org, etc.) is going down for reboot in 4 minutes; if you're editing a page or something, please save your changes now 
<jdub> seb128: evince 0.1.0 tarball release :)
<seb128> jdub: yep, I was considering to package it
<seb128> jdub: but I don't want to steal all the GNOME stuff, perhaps some NM would be happy to maintain it :)
<two-face> jdub: you noticed something strage about emacs in menus, didn't you?
<seb128> bah, I'll probably upload it this afternoon, if somebody want take over it later that's fine :)
<seb128> but bbl lunch for now
<two-face> jdub: (hi BTW)
<Kamion> elmo: FYI, cdimage is now auto-purging old images, which should keep disk usage on the mirrors down a bit
<elmo> Kamion: woo, thanks dude
<Kamion> I've set it at 7 days for dailies at the moment, I might drop that to 4 or so actually
<Kamion> yeah, dropped
<elmo> root     28999 21.6  0.0  2676 1272 ?        R    Jan01 2324:17  \_ /bin/sh /usr/sbin/tzconfig
<elmo> root     30950  0.0  0.0  2684 1280 ?        R    12:56   0:00      \_ /bin/sh /usr/sbin/tzconfig
<elmo> cute
<Kamion> whoa?
<elmo> it's the bastard spawn of some automated chroot updating cron job lamont has - I think it got awfully confused by interactivity
<elmo> not sure why it'd drop into tzonfig
<Kamion> dpkg --configure libc6 probably
<Kamion>     frontend=`echo "$DEBIAN_FRONTEND" | tr '[:upper:] ' '[:lower:] '`
<Kamion>     if [ "$frontend" = noninteractive ] ; then
<Kamion> [...] 
<Kamion>     else
<Kamion>         echo "Running 'tzconfig' to set this system's timezone."
<Kamion>         /usr/sbin/tzconfig
<Kamion>     fi
<Kamion> maybe he forgot to set DEBIAN_FRONTEND properly
<elmo> could be
<elmo> boggle
<elmo> or doesn't have debconf installed
<Kamion> !
<elmo> neither the warty nor hoary buildd chroots have debconf installed on this machine, it seems
<Kamion> debconf isn't in hoary.buildd
<Kamion> the debootstrap script
<Kamion> evidently lamont doesn't consider it essential enough :)
<elmo> well, it isn't, except that it needs to be forced to non-interactivity
<Kamion> certainly not Essential: yes, no
* Kamion updates the front page of http://releases.ubuntu.com/ to be marginally more descriptive
<Kamion> I should apply mako-style love to that
<elmo> ok, entire DC network's going down for a couple of minutes.. last reboot of the day (at least that anyone'll notice :)
<Kamion> having fun?
<seb128> grrrr
<mjg59> bob2: Very occasionally, but I can't reproduce it reliably
<seb128> people start bug reporting to say than new glib is out for 10 hours and not yet packaged
<maswan> elmo__: btw, I saw your reference to rsync giving lots of load, are you running bittorrent on the same fs? in our experience, that is a much worse disk-performance-killer.
<seb128> they are never happy
<Kamion> seb128: by the same reasoning, never pay taxes, or they'll just expect you to pay more taxes next month ... :)
<seb128> ah ah
<azeem> seb128: they just do it so you can increase your bug-closing karma
<elmo__> maswan: oh, err, yeah, we are .. thanks for the info, didn't realise that.. we already planned to move bittorrent to a dedicated machine anyway
<seb128> azeem: that's kind :p
<elmo__> maswan: but I have to say, since we dropped the rsync's to 15, the box hasn't seen the load jump to 30 again like it use to
<maswan> elmo__: It just queues up lots and lots of small reads in random order
* maswan nods
<elmo__> maswan: haha, ouch, yeah, I can see why that'd suck
<elmo__> latency?  wassat?
<maswan> elmo__: The bittorrent stuff is like a constant background that makes other applications go slower and wait longer, increase load etc
<maswan> elmo__: We cut the time of generating the weekly isos on cdimage.d.o from about 24 hours to about 8 hours by not running bittorrent on it anymore.
<maswan> (well, just the tracker, but that's not disk intensive)
<maswan> Now, we have a dedicated front-end on ftp.acc.umu.se that handles the bittorrent seeding
<trukulo> what about new kernel bug?
<trukulo> jdub: i was thinking... about theme in gtk using sudo
<lupus_> fabbione, is the scanner module missing in the kernel 2.6.10 hoary
<lupus_> my usb scanner is not working
<seb128> elmo: we can get a sync from incoming or we need to wait a day to get the packages on the mirrrors ?
<seb128> elmo: if I upload the debian version in ubuntu too, is that the same as a sync from you ?
<elmo> I can sync it from incoming, if necessary
<elmo> I'd rather not start doing 'by hand syncs' in the form of uploads, 'cos sooner or later someone will make a mistake and we'll end up with same file, different contents stuff
<seb128> ok
<seb128> there is no hurry, the sync needed are easytag 1.99.2-2 and glib2.0 2.6.1-1
<seb128> targetted for experimental and in incoming
<seb128> so sync them whenever you want, thanks :)
<Josephus> anyone got that userlib exploit working? All i got is FAIL and Segmentation fault with a bounch of kernels. So maybe the problem is not that general?
<elmo> Josephus: the isec.pl guys do not fuck around - the exploit posted may not work for you without tweaking, but I wouldn't make any assumptions based on that
<Josephus> probably they do not fuck around, but it does not even compile at first, i'm just talking about the "tweaking" you mentioned.
<elmo> why on earth do you need it to work?  just patch your kernels.  if you're  looking for help to exploit a box, you've come to the wrong place.
<Josephus> elmo: never mind, while it's a proof of concept, i just wanted to see it working on _my_ pc
<elmo> running exploit code you don't fully understand in anything other than a _very_ tightly controlled sandbox is a really Bad Idea.. there's been  a whole bunch of "dummy" exploits that do stuff varying from "rm -fr ~/" to sending "/etc/shadow" out etc.
<mjt> what exploit is that? something new?
<Josephus> i'm aware of that, but you just said that isec.pl does not fuck around :)
<Josephus> http://www.isec.pl/vulnerabilities/isec-0021-uselib.txt
<pitti> Hi guys
<lupus_> seb128, can you check if it is normal that scanner module is not present
<lupus_> in hoary
<seb128> ?
<seb128> what are you talking about ?
<lupus_> modprobe scanner
<lupus_> does nothing
<lamont> elmo: yeah, I need to force it non interactive
<lamont> figured out how to do that building the livecd chroot, just need to apply it in build-chroot now, and retrofit all the existing chroots.
<elmo> without installing debconf?
<lamont> yeah.
<lamont> ugly bastard script preseeding
<doko> lamont: I now have an ia64 machine at home. fixing the ia64 stuff. did you already merge the glibc -20 changes?
<lamont> not merged yet
<lamont> fabbione: you around?
<lamont> fabbione: daniels: thoughts on 5341, if you would be so kind
* lamont becomes more convinced on his own.
<tseng> pitti: http://bugs.gentoo.org/show_bug.cgi?id=77094 < multiple kernel vulns
<tseng> pitti: someone is working on breaking them out
<tseng> -ac already picked them up.
<pitti> tseng: thanks for that hint
<tseng> nps
<pitti> tseng: I have to go now, but I will deal with that at Monday
<tseng> great, have a nice weekened
<pitti> tseng: nice to see that grsec is released for 2.6.10 now
<tseng> indeed.
<pitti> tseng: you too :_)
<lamont> bbiab
<mjg59> Christ, scrollkeeper-update has taken 7 minutes so far
<lamont> mjg59: it likes to take its time
<Kamion> mdz: let's say that we were asked to produce an updated CD of warty with security updates for a certain European Linux magazine. Should we attempt to rebuild the kernel udebs and debian-installer for the kernel security fixes and the module ABI change, or just leave that well alone?
<cartman> does "Matthias Klose" hangs here?
<Kamion> cartman: what do you need?
<Kamion> (yes, he does)
<cartman> Kamion: need to ask what he thinks about a bug. He is the bug assignee
<Kamion> why not just ask the bug? :)
<cartman> Kamion: irc is usually faster ;)
<smurfix> cartman: he's "doko".
<cartman> smurfix: ok thanks
<cartman> but I better ask in bugzilla to be polite :/
<doko> cartman: here
<cartman> doko: cool :) let me find the bug#. I wonder if you will fix it or WONTFIX it
<doko> lamont: the gcc-3.3 build failed to fetch the debhelper package ...
<cartman> doko: https://bugzilla.ubuntu.com/show_bug.cgi?id=5251 thats the bug
* lamont grumbles
<cartman> doko: I ask because a similar bug on debian bugzilla closed as WONTFIX though I think the bug is valid
<Kamion> (debian doesn't use bugzilla, thank God)
<doko> cartman: wontfix. gcc-3.3 and gcc-3.4 have ABI incompatibilities, changing the symlink will result in linking the wrong libstdc++, etc ... it's not an alternative. we will have to recompile many more things for a proper GCC transition from gcc-3.3 to gcc-3.4
<cartman> debian's bug system is worst thing ever
<Kamion> cartman: you're talking to its maintainer :-P
<cartman> doko: hmm I don't ask for changing default.
<cartman> doko: I just want a way to shoot myself in feet if I want to
<Kamion> if gcc-3.3/gcc-3.4 were alternatives we'd run into serious buildd problems all the time
<cartman> I mix libstdc++ 5,6 fine here
<cartman> Kamion: hmm why?
<lamont> doko: the gcc-3.3 build you're looking for is the one currently running on hooker.
<Kamion> because update-alternatives is seriously fragile sometimes
<Kamion> cartman: why not use dpkg-divert?
<cartman> Kamion: hmmm
<doko> cartman: use dpkg-divert for self-shooting you
<cartman> doko: well please paste your comment to the bug then. Someone else is looking at it.
<lamont> doko: dpkg-divert is for customizing-with-a-crowbar. :)
<Kamion> the other traditional way to make gcc-3.4 the default is to export CC=gcc-3.4, which works with autoconf-generated configure scripts at least and many others
<doko> and CXX=g++-3.4 ... (or just put symlinks in /usr/local/bin)
<smurfix> Did somebody rename the MaintainerDocumentation page on the Wiki?
<smurfix> It's linked from the Wiki front page, but that link is dead
<Kamion> smurfix: yes, it became DeveloperSomething, forget exactly; rationale was that it wasn't just for maintainers (in the community process sense)
<Kamion> DeveloperResources
<smurfix> Kamion: OK, I'll update the front page
<Kamion> thanks
<Kamion> does zwiki do the auto-renaming thing for referring pages? guess not
<Kamion> maybe that's why it got missed
<smurfix> Not in RestructuredText pages
<lamont> {standard input}: Assembler messages:
<lamont> {standard input}:214: Error: suffix or operands invalid for `xchg'
* lamont grumbles at gcc
<Kamion> smurfix: yay for ReST! :-/
<lamont> seb128: around?
<Kamion> sigh, in order to build updated warty CDs I have to mirror universe
<Kamion> I'd forgotten about that "feature" of universe->main moves
<lamont> Kamion: or at least a couple files from it
<Kamion> sorry, main->universe moves
<Kamion> lamont: yeah. way less effort to mirror the lot, though ...
<lamont> on the real mirror, just find pool -type l
<seb128> lamont: pong
<lamont> and mirror the targets
<lamont> seb128: is there a trivial way to restart metacity, short of logging out and back in?
<Kamion> true, that would work, maybe I can kludge that in somewhere
<lamont> Kamion: rsync -L is your friend.
<lamont> (follows symlinks)
<Kamion> will that work even with --exclude **/universe/**?
<lamont> ye.
<seb128> lamont: killall metacity
<Kamion> bonus
<lamont> it gives you pool/main/f/foo/foo_1.2-1_i386.deb as a file instead of a link
<lamont> Kamion: whether good or bad is left as an exercise.. :-)
<lamont> that was how i solved the issue in my partial mirror scripting
* lamont grumbles about de-iconfication of all  his windows, but is otherwise happy.
<lamont> seb128: and yeah, I know there's nothing you could do there
<Kamion> lamont: that's perfect, thanks!
<lamont> Kamion: it took me a minute to remember "oh.  that".
* Kamion is up to patch-102 in the cdimage source tree now, which is kinda scary.
<lamont> but does that say '2004' in the archive name???
<Kamion> yes :)
<Kamion> haven't rotated it because there are no junk branches to forget about, so there seems little point ...
<lamont> yeah, that's the one.
<lamont> and cached revs take care of the play-forward pain
<smurfix> Hmm. If I want to Ubuntu-ize Debian version 0.99.76-0.2, what should I use?
<lamont> 0.99.76-0.2ubuntu1
<smurfix> Thanks
<lamont> seb128: is there anything that can be done about the fact that killing metacity causes all the windows to move down header-height pixels?
<lamont> window-top-border pixels down, window-left-border pixels right, actually.
<mxpxpod> why hasn't ubuntu switched to using n-c-b 2.9.0?
* Kamion doesn't see an n-c-b 2.9.0 tarball in http://ftp.gnome.org/pub/GNOME/sources/nautilus-cd-burner/
<mxpxpod> Kamion: ah
<lamont> seb128: if I send you an 83 lines unidiff that implements META_FOCUS_MODE_STRICT, would you take it???
* lamont ducks
* lamont grumbles.  what was the name of the amd64 porting box?
<lamont> Kamion: to add ubuntu-desktop to ia64, do I just need to put the seeds, or germinate output, into {base,desktop}-ia64?
<lamont> hrm... debian/rules would tend to indicate 'seed'
<lamont> :q
* lamont needs META_FOCUS_MODE_EYES
<mjg59> Haha
<smurfix> lamont: No problem. Just install an eye tracker.
<mjg59> I've seen that in action
<lamont> mdz around?
<smurfix> lamont: not since a few hours
<smurfix> he said he has to deal with Real World Problems
* lamont understands those... I have to decide if it's warm enough, or my need great enough, for me to go out and work on the starter on my car.
* smurfix grumbles at galeon. Its non-left mouse buttons stopped working today.
<usual> lamont, bang it with something heh
<lamont> usual: that's plan B
<lamont> smurfix: one word: firefox
<lamont> :-)
<lamont> Kamion: germinte output doesn't format correctly in the presence of wide characters. :-)
<smurfix> lamont: If it would restore my collection of open tabs after I crash the machine again, gladly. Right now: ENOWAY.
<mjg59> daniels: Around?
<lamont> smurfix: yeah - I miss that
<smurfix> Epiphany can do it, but it segfaults importing my Galeon bookmarks. :-(
<seb128> lamont: sure (if the patch is correct :p) :)
<seb128> lamont: what do you want to do to metacity exactly this time ?
<lamont> the heart of the patch is in window_takes_focus_on_map:
<lamont>   if (meta_prefs_get_focus_mode () == META_FOCUS_MODE_STRICT)
<lamont>     return FALSE;
<lamont> the rest of the patch is: accepting 'strict', and making it behave like 'mouse'
<mdz> lamont: yes
<lamont> mdz: gotta go fetch a daughter, but ubuntu-meta questions for you when I get back in about 25 min, if you're still here.
<lamont> seb128: I'll email you the patch too. really gotta run -was supposed to pick her up 15 min ago...
<seb128> lamont: ok
<seb128> Keybuk: here ?
<mdz> thom: PING
<mdz> mako: around?
<mako> mdz: yeah
<mako> mdz: whats up?
<mako> i'm doing baz evangelism on oftc/#debian-devel :)
<mdz> mako: mailed you
<mdz> mako: about publishing traffic
<mako> had dinner/drinks/etc with clint yesterday
<mako> ok
<mako> what about?
<mdz> mako: oh, also, I think in many paces in traffic you wrote 'lead' but meant 'led'
<mako> my mail is.. er.. not very accessible at the moment
<mako> "scheduled downtime"
<mako> hopefully better by tonight
<mdz> mako: mailed you about whether it's feasible to publish traffic at www.u.c/news/traffic or something
<mdz> mako: rather than /~mako/
<mako> that would be great
<mako> it was discussed briefly before
<mako> but there issues with integration into the rest of the site
<mdz> mako: since you are both traffic master and website master, I think you are in an ideal position to make it happen :-)
<mako> which was prohibitively difficult to do
<mdz> hmm, I see
<mdz> even if it were just a URL change, and not integrated with plone, I think it would be an improvement
<mako> the scripts generate an arbitrary number of pages
<mako> one for each person, etc
<mako> i can kind of make it looks like plone, maybe
<mako> although i'm not sure it will be a net gain
<mako> yeah.. we can do the url change for sure.. i agree that current home is not ideal
<mako> i was kind of hoping to put this on the list of things for the New Web Person
<mako> i also need the ability to just rsync the files into it.. which is not something i could easily do on www site
<mdz> Kamion: a new live CD build with the latest casper and lamont-output would be great
<lamont> mdz: for generating ia64 ubuntu ubuntu-meta, all I need to do is add 'ia64' to the list of architectures and run update?  And do we want to do that yet?
<lamont> Kamion: and if you build it say after at least 20 minutes have elapsed from now, that'd be even better.
<lamont> &*%)*^)& damn script
<lamont> either that, or don't use the -current links, since they're broken.
<Nafallo> anyone from Canonical working on the powernowd bug with AMD64 Mobile CPUs?
<Nafallo> bug assigned to debzilla@ubuntu.com, but bugs.debian.org/powernowd doesn't seem to have the bug. is it supposed to be like that?
<mdz> lamont: yeah, that should basically work
<mdz> lamont: and you can do that whenever you're ready
<mdz> lamont: maybe we should use Architecture: i386 powerpc amd64 etc. rather than Arch: any, and have update get the list from there
<mdz> lamont: would that make more sense?
<sivang> does anybody know if there's a sync policy or something like that into rosetta from the debian po archives/gnome ones?
<sivang> suppose a country team wanted to start transalting, and there has already been much transaltion going on gnome and debian archives, will it be apparent there?
<mdz> sivang: #rosetta would be the place to ask
<sivang> mdz: ok, asked there. awaiting response.
#ubuntu-devel 2005-01-20
<nakeee> I want to translate things to hebrew using rosetta, I thought I would start with xchat
<nakeee> I know xchat is partly translated
<nakeee> how can I see what version of the hebrew po file is being used?
<nakeee> so I won't retranslate things which were translated by the gnome team already
<mdz> nakeee: /join #rosetta
<nakeee> mdz: where there are even less people?:)
<mdz> nakeee: there may be fewer, but they are the ones who can answer your question (I can't)
<mdz> you can also mail the rosetta-users mailing list
<Nafallo> there is no way in current hoary to empty an CD-RW?
<mdz> Nafallo: only from the command line, afaik
<mdz> I usually don't bother blanking them; that's one less write cycle that could be used for real data
<Nafallo> mdz: hmm, need to write an ISO to it. I HAVE to blank it before?
<Nafallo> can't get cdrecord to show me what dev= to use :-P
<Nafallo> /dev/hdc should be ATA:something?
<nakeee> 2
<nakeee> no?
<crimsun> Nafallo: -dev=/dev/hdc
<Nafallo> nakeee: 0,2,0 worked. crimsun: ah, THAT easy :-)
<Nafallo> -dev=/dev/hdc worked best :-)
<mdz> Nafallo: right-click on the ISO in nautilus, click "write to CD"
<mdz> Nafallo: it will automatically blank it if necessary
<Nafallo> mdz: DOOH! to easy ;-)
<mdz> there is no way to tell it "just blank the CD and don't write anything to it", though, which is what I thought you were asking
<Nafallo> mdz: well, I was. but with the goal to write an ISO-image ;-).
* Nafallo blanks on a console atm *
<jdub> daniels: ping
<elmo> how do I see what's making outgoing DNS calls?
<elmo> as, in what process
<Nafallo> while I see alive ubs, what does debzilla@ubuntu.com as assigned to do in bugzilla?
<mdz> elmo: hmm...you can match on pid in netfilter, but I don't think you can convince it to log it afaik
<elmo> damn.. something cached my old resolv.conf from when I was in the data centre
<mdz> elmo: filter outbound DNS so that it has to timeout, then use netstat to see what has the socket open?
<elmo> AHA
<elmo> it's spamassassin
<elmo> POS
<mdz> you knew it was a POS already, no sympathy
<elmo> mdz: meh, I'll subscribe you to ftpmaster, admin and some of the inanely-widely-publicized-since-the-dawn-of-time debian addresses and then see who needs the sympathy
<Keybuk> SA3 is more POS than SA2
<elmo> is there anything else that's as good and most importantly doesn't require training?
<Treenaks> elmo: echo "elmo:|cat>/dev/null" >> /etc/aliases ; newaliases
<elmo> Treenaks: thanks dude, you're a star
<Treenaks> elmo: it gets rid of all spam and doesn't require training
* Treenaks blames it on the alcohol
<mdz> elmo: I already get a huge amount of spam
<mdz> elmo: my addresses are, er, widely publicized :-P
<mdz> bogofilter does very well for me
<elmo> isn't bogofilter the one that uses libdb and constantly needs upgrades every second week?
<elmo> and does it work without training, a la.. err, crm114?
<Clint> yes, and no.
<bob2> so, yeah, python2.4 doesn't like this whole installing thing
<bob2> Setting up python2.4 (2.4-2ubuntu5) ...
<bob2> Compiling python modules in /usr/lib/python2.4 ...
<bob2> /usr/bin/python2.4: can't open file '/usr/lib/python2.4/compileall.py': [Errno 2]  No such file or directory
<jdub> elmo: bogofilter is the one that changes command line parameter semantics -> to their polar opposites ;-)
<Clint> that only happened once
<jdub> i only pulled the trigger of the nailgun once
<Clint> next fun breakage might be to store database words in UTF-8
<Clint> is everyone excited?
<Keybuk> . o O { if only zsh supported utf-8 }
<Clint> . o O {if only people wouldn't discuss zsh and utf-8 every day without submitting patches}
<Keybuk> I looked once, I got scared
<Clint> it's scary
<Keybuk> there did seem to be a Tom Lord "reimplement the world" going on inside zsh
<Clint> well, a lot of that predates the world
<Clint> like all the funky memory management stuff predates mmap
<Keybuk> then again, I can't talk about packages not supporting utf-8
<Keybuk> ho-hum
<doko> bob2: from which python2.4 version do you upgrade?
<Clint> at some point, someone will get frustrated enough to write some really hacky patches to make it look like it does utf-8, a la readline
<bob2> doko: 2.4-2ubuntu1 -> ubuntu5
<sladen> Keybuk:   bash  Provides: zsh
<doko> bob2: and python2.4-minimal is already installed?
<Keybuk> sladen: except it doesn't
<bob2> doko: hrm, yes, at ubuntu1
<Keybuk> bash doesn't do anywhere near as much of the weird (but infinitely useful) shit zsh dose
<bob2> doko: maybe aptitude is being stupid and put it on hold
<Keybuk> mv ^Sources(@) ..
<Keybuk> "move all symlinks, except Sources to the parent directory"
<Clint> bash is only about 5 years behind zsh in terms of usability
<doko> bob2: ok, I see, please update -minimal as well. the dependency is still unversioned. will fix it.
<bob2> doko: ahh
<bob2> doko: cool, thanks!
<sladen> find -type l | xargs mv --target-directory=..     # nothing could be simpler
<Keybuk> sladen: you forgot -not -name Sources
<sladen> yeah, still might fit on one line with a 132 column display
<sladen> and to cope with spaces, you'd need  -print0 | xargs -0  too
<Keybuk> sorry, remind me, are you defending bash or not? :)
<bob2> doko: ah, perfect, thanks
<Keybuk> foreach FILE (*) mv $FILE ${FILE/^\([^.] \)\./\1\/}
<Keybuk> and friends too :p
<davyd> is the gnome-panel package maintainer around?
<bob2> davyd: it's probably a gtk bug
<davyd> (who appears to be seb)
<davyd> bob2: hmm? I don't want to chat about bugs
<Keybuk> wrong timezone for seb really
<davyd> yeah
* davyd does the maths, about 2.30am over there?
<davyd> I really want a CVS gnome-panel package
<sivang> jdub: you have that streaming video you took of me and some others over the crystal room? :)
<davyd> I was going to roll myself one
<davyd> but you gents have much patchage crack in there
<Keybuk> davyd: hmm?  you should just be able to copy the debian/ directory in
<mjg59> I so desperately need more RAM
<sivang> mjg59: how much do you have?
<davyd> Keybuk: that's what I would have thought
<Keybuk> you might get bitten by debian/patches/01_layout
<davyd> Keybuk: indeed... what is that?
<Keybuk> changes Application/System to Application/Places/System
<Keybuk> just nuke the patches that don't work
<davyd> Keybuk: aah
<mjg59> sivang: 256MB
<sivang> davyd: well, for me it's 3:42, so for seb around 2:42...:)
<davyd> sivang: yeah, they're on +1 at the moment?
<davyd> WEST?
<sivang> davyd: I think so, due to non daylight savings, when they are using daylight savings it's the same time as here..
<sivang> mjg59: oh, I bet your system chokes when running OOo together with moz ..:-/
<sivang> mjg59: I have 0.5G ram, and still machine gets slow when using OOo/Web together with evo|moz|thunderbird
<zenrox> sivang,  have you tried prelinking
<zenrox> sivang,  try this http://ubuntuforums.org/showpost.php?p=9864&postcount=80
<sivang> zenrox: no, can't say I have. You have a link for how to make it work?
<zenrox> does help reduce load time on firefox and OOo
<zenrox> i have bonic running and my dvds dont slow down
<sivang> zenrox: this is documented somehwere other then the uf.o ?
<zenrox> works for me
<zenrox> and suse uses it
<zenrox> at install of every program
<sivang> zenrox: nice
<zenrox> does that help
<sivang> zenrox: I will install beofre I go to sleep, currently working on something can't afford to let the system become less responsive
<zenrox> wont slow it down too much
<davyd> hmm, I am going to have to build every gorram module under the Sun I think
<davyd> this is annoying
<jdub> pants off davyd 
<davyd> PANTS!
<jdub> having a fun pre-freeze hack weekend?
<davyd> also hi
<davyd> jdub: yeah, except I realized the one problem in my new, no work dev environment
<davyd> I need CVS gnome-panel, and I can't pull the same hack with gnome-panel as I can with applets
<davyd> this makes me sad :(
<jdub> :-)
<jdub> hrm, you can use the funny bonobo env vars to do the same thing
<davyd> jdub: panel is not started by bonobo though
<davyd> so my bonobo magic is no good
<jdub> you can start panel on its own
<jdub> hold on, on phone
<davyd> jdub: yeah, that's worth a try
<davyd> I was going to just roll a package, but it's proving to be a bitch
<mdz> Keybuk: how do you think we should handle it if we were to switch to udevsend as default?  have init.d/udev set kernel.hotplug, and then init.d/hotplug set it iff it's not set to udevsend, or something like that?
<Keybuk> yeah, that's how I was handling it
<Keybuk> udev's first init script sets it
<Keybuk> and hotplug won't spam over the top if it sees udevsend in there
<mdz> Keybuk: what's this ipw/firmware thing about?  ipw2200 seems happy enough with udevsend
<Keybuk> which version of udev?
<mdz> ii  udev           0.050-3ubuntu1 /dev/ management daemon
<Keybuk> the problem is that the kernel issues a firmware hotplug event to get the firmware loaded
<Keybuk> and the driver only waits 10s
<mdz> I don't have an ipw2100 to test, though
<Keybuk> so if udev doesn't (for whatever reason) handle the event straight away, you get no firmware
<Keybuk> and the driver sulks
<mdz> daniels: X autoconfiguration for the live CD
<daniels> mdz: hoary chroot building now
<daniels> mdz: i've literally walked in the door 15 minutes ago
<bob2> mdz: I can test it
<mdz> bob2: would you?
<mdz> bob2: brief instructions are above
<daniels> GNAR
* daniels watches his attempt to rsync i386/powerpc/source Ubuntu go into its second week.
<davyd> hey daniels !
<bob2> hrm, is there a 'test' flag to check the contents of a file?
<mdz> daniels: hoary chroot wha?
<daniels> mdz: when I do sudo dpkg-reconfigure -plow xserver-xorg, predictably it works :P
<daniels> mdz: working on the whole 'testing' thing
<daniels> davyd: hey dude :)
<davyd> daniels: you never mailed me your address ;)
<daniels> davyd: heh
<davyd> and my psychic powers are lacking
<daniels> davyd@maddley.id.au?
<davyd> madeley
<daniels> sent
<davyd> daniels: my spidey sense tells me it was your birthday on Thursday, is that vaguely true, or am I smoking expensive crack?
* tseng checks it
<daniels> davyd: it's true, in a vague and more concrete sense
<mdz> Keybuk: do you happen to have tracked down why udev is quite so abhorrently slow under d-i?
<davyd> daniels: happy birthday ;)
<davyd> 19 or 20?
<davyd> "By the definitions I use,  and  seem strictly equivalent to me. Would be it fair to say that   " haha
<Keybuk> mdz: I didn't know it was
<mdz> Keybuk: it takes about 5 seconds before /dev/fb/0 appears after the module is loaded, most of the time
<mdz> and sometimes it never appears at all, but I expect that'll be fixed by udevsend
<Keybuk> odd, can't say I've looked at it
<mdz> daniels: I was under the distinct impression that 'Driver "radeon"' was nonsense and there was no reason ever to do that
<mdz> daniels: but someone just stated in the wiki that it got things working for them
<Keybuk> mdz: could certainly be an issue with hotplug trying to do the event too early, and then backing off too long
<daniels> mdz: it is not nonsense, and sometimes the ati driver is so staggeringly shit that it fails to hand over to the right submodule
<daniels> mdz: my personal opinion is that we should use atimisc/r128/radeon in preference to tai
<mdz> Keybuk: does udev have some magic to prevent it from having itself called again via its own hotplug hook?
<mdz> Keybuk: or does it just deal with that when it comes?
<davyd> daniels: I opted not to go to Melbourne next month
<Keybuk> I thought there was, but I can't see the magic now
<davyd> since I'm going to be doing a lot of travelling otherwise
<Keybuk> I think udevd sets an environment variable, and udevsend bails out if it finds that
<davyd> so it'll obviously be April then
* davyd wonders if he can get someone to witness his passport renewal so he can submit it tomorrow
<daniels> davyd: ahr, bugger
<davyd> daniels: also, you didn't answer, did you turn 19 or 20?
<daniels> davyd: oh, sorry, missed that one -- 19
<davyd> cool
<sivang> davyd: g_warning is great in debugging. thanks :)
<sivang> davyd: it appears there nothing wrong iwht the model , as expected :) I'll have to check the xml creation functions then....:-/
<daniels> 'The V3200 is a 16Mb Banshee board, which means it can support some rather impressive 2D resolutions. It can manage a 75Hz refresh rate at 1792 by 1344 with 32 bit colour. This is probably enough to stretch a startlingly expensive 30 inch monitor to its limits, and much higher than you should bother using on smaller screens like the 17 and 19 inch monitors many people use.'
<bob2> mdz: doesn't work
<bob2> mdz: afaict from dmesg it is that it's not loading the firmware in time
<mdz> bob2: thanks
<mdz> daniels: you have an ipw2100, right?
<bob2> he has atheros
<mdz> oh
<daniels> mdz: ath
<bob2> thombot has ipw2100
<bob2> lifeless has ipw2200
<mdz> I have 2200 as well
<mdz> I guess thom can fix it when it breaks
<mdz> Keybuk: unless you already know exactly what needs to be done
<mdz> Keybuk: I'm thinking about doing the udevsend switch tonight
<Keybuk> no, I don't -- just kill it anyway :p
<davyd> daniels: ooh ooh, where do I buy one?
<daniels> davyd: i have one on my desk; if it wasn't the only tdfx I had, I'd give it to you
* bob2 does a list upgrade before putting hotplug and udev on hold
<davyd> I remember back in the day
<bob2> er, last
<davyd> when I got a 2MB Cirrus Logic
<davyd> I could play Wolfenstein 3D
<davyd> and it was quick too
<bob2> daniels: mjg59 says you have a fix for the gl-is-fucked-after-resume i855 thing?
<daniels> i miss my rendition verite (3d blaster pci)
<daniels> that was totally ahead of its time
<daniels> bob2: yep
<jdub> so
<daniels> bob2: but if you value your job, don't ask me to do it before xorg autoconfiguration for livecd is done :P
<bob2> haha, alrighty :)
<mdz> Keybuk: is there even any point in having hotplug check if udev is kernel.hotplug, and if not, putting itself there?
<mdz> Keybuk: it is the default and all
<bob2> I was just having udev overwrite sys.kern.hotplug always
<Keybuk> mdz: not really :p
<jdub> ok
<jdub> so
<mjg59> daniels: 1792x1344? 30 inch?
<bob2> jdub: put your pants on and finish a sentence!
<jdub> i'm getting "can't write to /dev/null" (and /dev/console) errors during initrd when booting software raid1
<mdz> I wonder if it still makes sense for init.d/hotplug stop to set the helper to /bin/true
<daniels> mjg59: FEAR THE AWESOME VOODOO POWAH
<jdub> it occurs to me that /dev on the target is entirely empty
<jdub> because there is no udev
<jdub> so i'm trying a reboot with /dev/null and /dev/console on there
<jdub> (i'm assuming it's target disk stuff here)
<jdub> this is a bit of a problem
<jdub> if it works with those nodes created, then i'll be worried
<mdz> jdub: how did you end up in this mess?
<mdz> jdub: initrds generated by mkinitrd have /dev/console and /dev/null on them (statically) for exactly this reason
<jdub> yes, they are there
<jdub> i've done mkinitrd -r /dev/md0 -o pants
<jdub> pia says the machine successfully booted
<jdub> so it needed null and console on the *target*
<jdub> which means that it would be very hard for someone to convert a fresh ubuntu install to software raid1 easily
<jdub> (also, i really dislike the hardcoded mdadm call after redoing the mkinitrd)
<jdub> i'm sure we can come up with a better way of making robust initrds
<jdub> that can handle configuration changes like this
<jdub> hrm
<jdub> unless our /dev already has those
<jdub> i did a cp -vax
<jdub> though that should've copied them if they were there
<mdz> Keybuk: hmm...should init.d/hotplug run udevstart rather than run_rcs if udevsend is the helper?
<mdz> I don't suppose it matters
<mdz> probably best to leave it alone
<Keybuk> mdz: that's what most of my work in Mataro was trying to do -- then you end up racing X to load your mouse driver
<bob2> you should start gdm out of a udev event script
<Keybuk> bob2: which one?
<bob2> hah, touche'
<bob2> silly english keyboard
<daniels> le sigh
<daniels> mdz: we don't use radeonfb, do we?
<mdz> daniels: we deliberately pretend that it doesn't exist
<mdz> daniels: https://bugzilla.ubuntu.com/show_bug.cgi?id=3993
<mdz> jdub: the best way to do it is to use EVMS
<mdz> jdub: and forget about mdadm and all that other cruft
<mdz> jdub: if you set up fstab so that it uses a /dev/evms/foo volume as root, it will magically set up the initrd for you
<daniels> mdz	sweet
<daniels> mdz: thoughts on this for lrm? http://www.heby.de/ltmodem
<Keybuk> You know what tla's killer feature is?  How it doesn't get affected by a change of umask
<Keybuk> OH WAIT
<Keybuk> descent dpkg-1.13% tla changes | wc -l
<Keybuk> 2369
<bob2> Keybuk: "don't do that"
<bob2> (and/or file a bug)
<Keybuk> bob2: I have different umasks on different machines
<Keybuk> tla cannot cope
<bob2> changing it causes tla to do a massive permission change changeset?
<Keybuk> apparently
<Keybuk> all the patch logs have different permissions on this machine
<bob2> erm
<Keybuk> 644 vs. 664
<daniels> bbiaw
<jdub> mdz: mmm, i wasn't bold enough to go evms this time around
<jdub> mdz: should we regard evms as our one true raid/volume-management system; no md?
<lamont> mdz: we could just fetch the architecture list from the archive...
<lamont> that is, if there's a ubuntu/dists/hoary/main/binary-foo, then foo needs to be done.
<mdz> jdub: no mdadm, right
<lamont> mdz: what do you think of fetching the list of main/binary-* and using that?
<lifeless> bob2: theres a bug open on keybuk...'sproblem
<lamont> mdz: for ubuntu-meta
<bob2> be nice.
<lifeless> how ?
<lifeless> :}
* lamont does not feel qualified to make a good decision on 3442, looks to mdz/keybuk/etc for fontconfig thoughts
* lamont falls over, heads to bed.
* daniels abdicates from 3442.
<daniels> keybuk touched it last
<crimsun> by default ~/.fonts.conf overrides everything
<mdz> lamont: I don't think that we add new architectures frequently enough to justify the complexity, to be honest
<jdub> mdz: but we wouldn't recommend md.ko usage either?
<mdz> jdub: why wouldn't we?
<mdz> EVMS uses md for raid5
<mdz> until such time as device-mapper gets equivalent functionality, anyway
<jdub> oh right
<jdub> sorry, thought dm already did that
<mdz> it does mirroring only, afaik
<jdub> lamont: we should kill all our local.conf changes
<mdz> but the nice thing about EVMS is that you don't have to give a damn
<mdz> you tell EVMS you want a raid-1 volume and a raid-5 volume, and it does what needs to be done
<mdz> including figuring out how to configure the kernel for it this week
<jdub> so is there a simple path from md raid1 to evms, or will i need to fail one drive and re set stuff up?
<mdz> I believe EVMS will read md metadata, so it will recognize and activate your volume
<mdz> I'm not sure whether it uses raid1 or dm-mirror in that case
<mdz> jdub: fire up evmsgui and see what it shows you
<jdub> hmm
<jdub> ok :)
<sivang> mdz: can I install evms on an already running lvm system?
<mdz> of course
<sivang> mdz: coool :) apt-get instal evms? ;-)
<jdub> mdz: is there a non-gtk evms interface?
<jdub> oof
<mdz> sivang: it's in base
<mdz> jdub: evmsn is an ncurses interface
<jdub> particularly a non-gtk1 ui
<mdz> evms-cli has a CLI, but I don't recommend it
<mdz> I use evmsn and evmsgui
<jdub> whoa
<jdub> /dev/evms/md/md0
<mdz> sivang: evms understands both lvm1 and lvm2 metadata
<jdub> so i can set my / to that and go?
<sivang> mdz: cooooooooooool
<sivang> :)
<mdz> jdub: yeah, or you can create an EVMS volume on top of it and use that
<mdz> EVMS sees md volumes as a lower level storage object out of which it can build things
<mdz> but you can use them directly as well
<jdub> makes sense
<jdub> i might just stick with that for now
<sivang> mdz: is colin going to integrate it into d-i ?
<mdz> not likely
<mdz> but it could become a bounty
<mdz> integrating EVMS in the installer would be a much bigger project than the existing LVM support though
<mdz> there's just a lot more you can do
* jdub makes a new initrd
<mdz> there is an evms udeb which should in theory let you use evmsn from the installer
<jdub> on this system i seem to have to modprobe loop
<mdz> jdub: haven't upgraded in a while?
<mdz> jdub: grep loop /etc/udev/links.conf
<jdub> it's a warty server
<jdub> not listed
<jdub> hrm
<jdub> script in the initrd still has mdadm
<jdub> hrm, it doesn't have any evms related binaries in it
<jdub> # update-grub
<jdub> Searching for GRUB installation directory ... found: /boot/grub .
<jdub> /dev/evms/md/md0 does not have any corresponding BIOS drive.
<jdub> 
<jdub> d'oh ;)
<sivang> jdub: grub doesn't play well with it?
<jdub> i'm pissing aroudn in the dark atm dude :)
<sivang> jdub: hehe 
* jdub googles for evms grub
<sivang> jdub: does it boot at all? :)
<jdub> haven't tried
<jdub> erm
<jdub> hrm
<jdub> "This means your /boot volume must be based on a single partition."
<jdub> bong!
<sivang> jdub: /boot is adviced to not reside on a non evms/lvm volume, if to sum up to not so much I've read about it on the web :)
<sivang> jdub: correction, not on _a_ evms/lvm
<mdz> jdub: ah, that was fixed post-warty
<jdub> mdz: which bit?
<mdz> jdub: both, actually
<mdz> jdub: the loop device thing, and the initrd thing
<mdz> the initrd fix should be a one-liner
<jdub> oh right
<mdz> the logic just doesn't get triggered on /dev/evms/md/foo, only on /dev/evms/foo
<mdz> /usr/share/initrd-tools/probe.d/evms
<fabbione> morning
<mdz> fabbione: morinng
<jdub> mdz: change to /dev/evms/*/*, or /dev/evms/* /dev/evms/*/* ?
<mdz> jdub:     for vol in /dev/evms/* /dev/evms/md/* /dev/evms/lvm/*; do
<mdz> is what I have in current hoary
<jdub> oh, ok
<fabbione> AHAHAH
<fabbione> oh god
<mdz> you'll be way happier if you update to the hoary version of evms if you're doing this kind of stuff
<fabbione> "All hail fabbione,
<fabbione> Grandmaster of the all omnipotent and omniprescient ubuntu linux kernel.
<fabbione> I offer up my sacrifice of some signed and encrypted gpg keys in the
<fabbione> hope that they satisfy.
<fabbione> I only pray that my acpi may work in the next version.
<fabbione> "
<jdub> ok, initrd fixed - thanks :)
<mdz> jdub: one thing to watch out for
<mdz> jdub: the evms initrd magic in warty doesn't know how to figure out which disks make up your raid array
<jdub> only now update-grub is completely spewing
<jdub> mdz: ... ugh
<mdz> jdub: so you need to ensure that the modules it needs are loaded in the initrd, yourself
<mdz> jdub: it can detect the array fine, you just need to make sure that it can see your disks before it gets to that point
<jdub> so, 'raid1'
<mdz> no, stuff like your SCSI driver
<mdz> will need to get added to /etc/mkinitrd/modules
<mdz> the hoary version has more magic
<sivang> fabbione: LOL
<jdub> oh, i see, yeah
<sivang> fabbione: morning
<jdub> it missed sata_sil and friends
<fabbione> eheh hi sivang
<mdz> making evms-udeb a reality would be a pretty cool bounty project, actually
<jdub> ok,
<jdub> sata_sil
<jdub> sd_mod
* jdub makes another initd
<jdub> mdz: recommendations wrt grub, lilo, etc.? give up and have a separate /boot?
<mdz> jdub: I would use grub
<sivang> hehe, someone promoted my news flash about the arstechnica awards to a (!) mark on main page :)
<jdub> grr, bong, using the same config (fstab, menu.lst) as before, update-grub isn't working
* jdub goes to dinner for the moment
<sivang> ok, enough g-s-t hacking for now, sleep 4 hours, then fininsh the backends hopefully :)
<sivang> night all!
<crimsun> night.
<sivang> crimsun: night Zzzz
<bob2> so, after suspend-to-disk, ipw2100 says "ipw2100: eth1: Failed to start the card." every second until I reboot
<mdz> er
<mdz> when did xfsprogs get added to base?
<fabbione> bob2: buy serious hardware...
<fabbione> if it works for me.. everything else is buggy hardware
* bob2 assigns the bug to fabbione 
<jdub> http://alan.aspuru.com/archives/2005/01/08/ubuntu-linux-on-a-middle-school-computer-lab-a-linux-enthusiasts-adventure/
<jdub> mako: ^
<^_^> i am a devel
<^_^> ?
<^_^> ok why can't ubuntu put a bounty for a gui installer?
<^_^> i am willing to do it for $750USD
<^_^> i might even do it for $500 but
<^_^> if you paying for a hack in firefox to show some html pages $500 then your standards are diffrent to what i thought they might be
<cartman> ^_^: start with getting a real nick
<^_^> why is ubuntu paying $500 for a $10 job
<^_^> cartman: i change it at a rate of 1 per 4hrs
<^_^> brb
<^_^> back
<^_^> BOOOOOOOOOOOOOOOOO
<^_^> ooops
<^_^> wrong tab
<Kamion> lamont: http://terranova.warthogs.hbd.com/~buildd/livecd/livecd-current.cloop gives a 403; would appreciate a permissions fix
<^_^> Kamion: lag?
<pitti> elmo: ping
<^_^> pitti: pong
<pitti> ^_^: you are certain that you are elmo? :-)
<^_^> pitti: pong
<pitti> elmo: I'm releasing the Warty kernel update now (16.8)
<^_^> don't
<^_^> you will brake some systems
<^_^> just black mail ati and nvidia
<daniels> ^_^: please take it somewhere else, ok?  if this channel gets cluttered with crap, we cannot do development.
<Kamion> ^_^: huh?
<^_^> daniels: umm all i see is parts and joins and ping requests
<^_^> OMG
<pitti> hey, it's Sunday after all
<^_^> Kamion: you have way too much lag
<Kamion> ^_^: there's a lot of interesting stuff from before you joined
<cartman> sigh
<Kamion> ^_^: dude, some of us do not pay attention to IRC 24/7
<^_^> Kamion: you had to stop the intresting stuff :(
<daniels> ^_^: there's every chance Kamion was actually doing interesting work instead of listening to this
<^_^> ok here is my wishlist
<daniels> ^_^: you are not here for development, and you are actively hindering it.  please be quiet, or leave.
<^_^> 1) ignore me
<^_^> 2) tell me to leave
<^_^> thanks
<azeem> hmm, and I was half-convinced ^_^ was daniels in disguise
<azeem> 2004-08-#gnome-hackers.log:11:25 -!- daniels is now known as ^_^
<azeem> there, evidence
<cartman> hmmm
<daniels> azeem: heh
<^_^> LOL
<^_^> wtf
<azeem> 2004-08-#gnome-hackers.log:18:28 -!- ^_^ was kicked from #gnome-hackers by ^-^ [get your own damned name] 
<azeem> ^_^: beware
<^_^> oh ow
<Kamion> hm, diffing loop-mounted ISOs takes a while
<^_^> ok here is my wish list
<^_^> ubuntu should start selling computer with ubuntu pre installed
<Kamion> I doubt Canonical will be in that business in the near future, but we'd be happy to support other people doing that, and indeed there's some installer stuff in planning stages to help with OEM installations
<^_^> yes and please GET THOSE NAKED PICTURES OFF UBUNTU
<^_^> not all of us like the female body
<^_^> or let alone the male
<^_^> that one thing m$ did right no pictures of people on the desktop
<Kamion> they're not the default, plus the artwork argument is *so* September
<^_^> yes they should even be part of ubuntu
<^_^> that is a reason why some of my friends didn't install the os because they saw they cd cover
<daniels> we've already had that argument, please read the mailing list archives.
<^_^> link
<^_^> btw a lot of people like how not all apps look the same grey...
<Kamion> look in the ubuntu-users archives for September and October and I find it hard to imagine that you could miss it
<tuo2> gah
<Kamion> the current situation was decided following a community meeting
<^_^> look most media players are umm whats the word
<martink> "ugly"? "in-consistent with your desktop"? "fruit salad"?
<daniels> ^_^: this is not appropriate for #ubuntu-devel.  if you insist on continuing, please take it to #ubuntu.
<^_^> daniels: ahh the people who would do anything would be in here 
<^_^> and as you said you are not at irc 24x7
* cartman is glad he ignored ^_^ 
<^_^> you'll miss of it
<Kamion> no, that just means we have to read it in scrollback
<^_^> you are telling me you are going to read 10k lines of stuff just to find 1 line that you need to read
<Treenaks> ^_^: /help lastlog
<daniels> i read scrollback of #ubuntu-devel, because it's not filled with morons trying to hijack it
<daniels> right now, i'm trying to watch discussion of the live cd development, which is now very, very difficult.
<^_^> ohh one question
<Kamion> I read scrollback of #ubuntu-devel because I do this stuff for a living and I feel slightly obliged to pay attention to scrollbacck
<pitti> nice Sunday everybody
<^_^> why not let gnoppix be the live cd for ubuntu
<^_^> it uses the ubuntu packages....
<^_^> it is far better than the current cd
<Kamion> Gnoppix *is* the Warty live CD
<^_^> and it has an installer on the cd
<Kamion> they're bit-for-bit identical
<^_^> Kamion: not the one i got
<^_^> the one i got doesn't have a installer on the cd
<Kamion> perhaps you should look at http://www.gnoppix.org/ and read the stuff on the front page
<daniels> ^_^: look, there is only one cd, and it's gnoppix.  and i still fail to see the relevance to ubuntu development.
<^_^> well the screeny on that site show an insatller
<Kamion> this is something we're working on for the next release, by means of making the live CD bootstrap process use the installer code
<^_^> hey the gnoppix cd is 0.8warty
<^_^> and in a screeny of 0.7
<^_^> there is already a installer
<^_^> as shown in this screeny
<^_^> http://www.gnoppix.org/pages/screenshots/gnoppix07beta/gnoppix_installer.png
<daniels> take it to #gnoppix
<^_^> what happened to it
<Kamion> no, we aren't going to use the gnoppix installer, we already have an installer and we don't want to have to support two installation systems
<^_^> Kamion: ah ha so the gnoppix project is now your live cd project and you guy desided to dump the installer then
<^_^> now it makes sence
<^_^> btw #gnoppix has one person in there
<Kamion> just because other places don't have enough targets for rants doesn't mean this is the right place
<^_^> ok ok
<^_^> one thing where do i rant about gnoppix's site saying its based on debian woody and not ubuntu? there is no one in #gnoppix to rant to, and as ubuntu took over the project i'll guess this would be the place
<Kamion> perhaps you should try finding e-mail addresses or bug tracking systems rather than irc channels; bug reporting on irc is generally not so useful
<^_^> ok
<daniels> don't know what he's on, the gnoppix site has ubuntu all over it
<Kamion> wow, my security-updated warty CD actually seems to be vaguely correct
<daniels> heh, nice :)
<Kamion> and I can basically build it with DEBUG=1 DIST=warty ARCHES=i386 cron.daily
<daniels> rad
<daniels> Kamion: what's the default debconf priority in casper; high?
<Kamion> should be, yeah, everything defaults to high now
<daniels> phat
<daniels> we should be able to do live cd autoconfiguration when I fix this stupid stupid stupid bug
<daniels> note to self: dpkg --print-architecture works without dpkg-dev; dpkg-architecture doesn't
<Kamion> heh, yeah, dpkg-architecture's only intended for stuff in package builds IIRC
<daniels> well, I thought, 'what gets the value of the architecture?', and I was in a debian/ dir at the time :P
<daniels> mdz: ok, listen up, yo
<daniels> export XORGFORCEPROBE=yes
<daniels> md5sum /etc/X11/xorg.conf > /var/lib/xfree86/xorg.conf.md5sum
<daniels> dpkg-reconfigure -phigh xserver-xorg
<daniels> mdz: for the meantime, you'll need to have dpkg-dev installed, but I have the fix for that locally
<daniels> mdz: that *should* do autodetection fine; the only real problem is prompting for the keyboard layout atm, and also lack of a fallback (probably 640x480?) if we can't pick the default resolution.  i'll do 640, but how do you want to handle the keyboard layout?
<daniels> mdz: (by '*should*', I mean 'does on my freshly-installed hoary chroot, with dpkg-dev, laptop-detect and xresprobe installed')
<daniels> daniels@nanasawa:/etc/X11% export XORGFORCEPROBE="yes"
<daniels> daniels@nanasawa:/etc/X11% sudo sh -c 'echo > xorg.conf'
<daniels> daniels@nanasawa:/etc/X11% sudo sh -c 'md5sum /etc/X11/xorg.conf > /var/lib/xfree86/xorg.conf.md5sum'
<daniels> daniels@nanasawa:/etc/X11% sudo dpkg-reconfigure -phigh xserver-xorg
<daniels> daniels@nanasawa:/etc/X11% wc -l xorg.conf
<daniels> 126 xorg.conf
<daniels> Kamion: what state does casper come in?  i assume unpacked and configured?
<daniels> Kamion: or does it do this on the fly?
<mjg59> daniels: Still around?
<azeem> he's like flooding this chan currently
<daniels> mjg59: represent
<mjg59> daniels: VIA again
<daniels> mjg59: ...
<mjg59> On the craptop
<mjg59> It doesn't switch the LCD off now, but it doesn't actually seem to start X
<daniels> still arse with Xorg?
<daniels> oh, hooray
<mjg59> Hang on, I'll just try with vesafb disabled
<daniels> want to bounce me Xorg.1.log from sudo Xorg :1 -logverbose 9999 -notvtswitch?
<daniels> yeah, fb is generally badness
<daniels> the via driver is probably flakey enough to not deal with coming from !text
<mjg59> daniels: It just stops with Using VT number 8
<mjg59> Ok, it's better without -novtswitch
<mjg59> www.codon.org.uk/~mjg59/tmp/Xorg.1.log
<mjg59> (II) VIA(0): Not using mode 1024x768 (no mode of this name)
<mjg59> Hmm.
<daniels> looks like it's failing in VIAGetBIOSTable
<daniels> VGA BIOS image is wrong!! CheckSum = 5e403a
<daniels> you'd probably need to poke libv about that one
<mjg59> libv?
<daniels> oh, arse.
<daniels> luc varhaegen, one of the via guys
<daniels> it looks like we can't get any sensible output without rebuilding the via driver
<mjg59> Hahaha
<daniels> http://amnesiac.heapspace.net/~daniel/via-drv.o
<daniels> er, via_drv
<daniels> that should have way more debugging funk
<daniels> well, in a sec
<mjg59> The one I just grabbed?
<daniels> the incomplete one, yes :P
<daniels> my link is flogged atm
<daniels> ok, grab it now
<daniels> if you run with -logverbose 9999, you should get some sweet debug love
<mjg59> Ah, yes, that's bigger
<daniels> a bit, yeah
<mjg59> daniels: Ok, www.codon.org.uk/~mjg59/tmp/Xorg.1.log again
<daniels> and it just hangs there?
<daniels> or is the mode stuff broken?
<mjg59> It just stops there
<daniels> oh, haha
<daniels> (II) VIA(0): Generic Monitor: Using default hsync range of 28.00-33.00 kHz
<mjg59> Nothing on screen
<daniels> (II) VIA(0): Generic Monitor: Using default vrefresh range of 43.00-72.00 Hz
<mjg59> Ah. Yes, it's not going to get 1024x768 out of that, is it?
<mjg59> 33kHz?
<mjg59> Christ
<daniels> try setting HorizSync 28-49, VertRefresh 43-72
<daniels> via seems to be one of the drivers which will happily do everything for the modes except set up sensible sync ranges so the only modes it sets up and will accept can validate
<mjg59>         Option          HorizSync     28-49
<mjg59>         Option          VertRefresh   43-72
<mjg59> In the monitor section?
<daniels> (II) VIA(0): VIABIOS_GetVideoMemSize
<daniels> (II) VIA(0): Return Value Is: -1073544704
<daniels> very encouraging, that is
<daniels> nope, just HorizSync\t28-49\nVertRefresh\t43-72
<mjg59> Hm. It's still setting the default
<daniels> in the Monitor section
<mjg59> Oh, right
<daniels> (i made the same mistake)
<mjg59> Some day I'll understand the semantics of this
<mjg59> Hrm. Still nothing. Hang on.
<mjg59> www.codon.org.uk/~mjg59/tmp/Xorg.1.log
<mjg59> Interesting. I can't find a single machine here that doesn't have a bad video BIOS checksum.
<Treenaks> mjg59: try using Option          "NoDDCValue"    "on"
<Treenaks> mjg59: the via driver kept choosing the lowest res. when I didn't have that.. somehow the (incorrectly read/parsed) values override the X config
<mjg59> Treenaks: Is that in the monitor section?
<Treenaks> mjg59: no, Device
<daniels> hold on, what mode *is* it using?
<daniels> i'm beginning to suspect I'll never have a hope of correctly configuring the via driver
<daniels> via and apple need their hardware licences revoked
<mjg59> Treenaks: Nope, stops in the same place
<mjg59> I'm almost at the point of wondering whether there's a newer BIOS available for this thing
<mjg59> The one in it is a Dixons special
<ericf> why is it that a symlink like '/dev/dvd -> /dev/hdd' is gone after reboot? Maybe it's offtopic here, but in #ubuntu no-one could tell me...
<Treenaks> ericf: because udev manages /dev in ubunti
<Treenaks> ericf: and if you want that symlink, add it to /etc/udev/links.conf
<ericf> Treenaks: Great! Thanks :)
<daniels> mjg59: with a capital SPECIAL
<kagou> hi
<kagou> i'v found a bug on hoary 64 with openoffice 1.1.3
<kagou> first launch -> crash ... i had to manually edit ~/.sversionrc and change 1.1.2 by 1.1.3. After openoffice is ok
<kagou> hi seb128 
<Nafallo> kagou: could you find it on bugzilla.ubuntulinux.org?
<kagou> mmmm let'"s go
<kagou> no Nafallo 
<Nafallo> kagou: then you should file a bug against the package.
<kagou> okay
<mjg59> Damnit. I need to get DOS on here.
<mjg59> ...and, of course, it has no floppy drive
<Nafallo> mjg59: you might want one of those; ubcd.sf.net
<Nafallo> :-)
<mjg59>  14:30:24 up 376 days, 21:21,  4 users,  load average: 0.29, 0.08, 0.02
<mjg59> Nafallo: Nah, I'll just netboot it
<mjg59> Pff. That'd be 450 days if my housemate hadn't switched it off last christmas.
<daniels> haggai: see kagou's comment above
<mjg59> Best. Laptop. Ever.
<daniels> mjg59: the craptop, or another laptop?
<Nafallo> mjg59: hehe, nice one :-).
<mjg59> Haha. No. That's an ancient P75 Toshiba
<daniels> nice
<daniels> mjg59: do you know anything about GTK's craptasmic input method, BTW?
<mjg59> In what way?
<daniels> well, I've been trying to hack it to generate a unicode heart on compose-<-3
<daniels> took me 3 seconds with the X mappings, but adding it to gtk_compose_map in GTK didn't do any good
<daniels> so it works with the X input method, but not with the default one
<mjg59> Ah. No idea, I'm afraid.
<daniels> ditto compose-i-j for the ij ligature
<daniels> ah well
<daniels> christ, the original imac advertises 640x480@112Hz
<daniels> that's psychopathic
<mjg59> I love the feeling of flashing hardware with (theoretically) unsupported BIOSes
<daniels> even if it doesn't work, it's an improvement
<mjg59> Haha
<mjg59> memdisk is the best thing ever
<daniels> then again, setting it on fire, or using it to beat an old woman to death on the street, would be an improvement
<elmo> seb128: ?
<elmo> or any mono guys?
<seb128> elmo: I'm not a mono guy
<mjg59>                 UUID: 22222222-2222-2222-2222-222222222222
<daniels> elmo: is this about mcs/m-a-b?
<mjg59> Best. UUID. Ever.
<daniels> mjg59: word
<seb128> elmo: but since you are here, sync for python-gtk2-tutorial python-gtk2-doc please :)
<mjg59> Oh, WOW
<mjg59> The new BIOS makes the fan EVEN LOUDER
<mjg59> When it's idling
<elmo> seb128: no, but you might know if there's any reason gtk-sharp would be using an old copy of gtkhtml, gal and soup?
<mjg59> daniels: Ok, X is still just as fucked
<elmo> why the heck is python-gtk2-doc in multiverse?
<daniels> mjg59: awesome
<daniels> mjg59: i think this might be a courier-it-to-the-via-hackers thing
<daniels> mjg59: (he's in belgium, iirc, so maybe you could just ride your bike over)
<mjg59> daniels: It's weird, though. At least one of the via hackers had dealt with the G320.
<daniels> mjg59: i'm not entirely sure libv had dealt with one, as much as heard a report from someone using one once
<mjg59> And it used to work better than this (as in, it started X fully and then turned the LCD off...)
<daniels> heh
<mjg59> Haha
<daniels> i dunno, i assume the horizsync/vertrefresh lines are the same as from xfree86
<daniels> if not, you might want to steal the xfree86 ones
<mjg59> Oh, it never worked at all with XFree
<daniels> oh, sweet
<mjg59> Remember? It hung the machine
<mjg59> This was an earlier Xorg package
<daniels> oh yeah
<daniels> looks like the unichrome merge broke it then, maybe
<daniels> you'll have to poke libv, I'm afraid (he hangs out in #freedesktop)
<daniels> my downstream's hammered, so I'm going downstairs to get some more food now
<seb128> elmo: I've no idea, python-gtk2-doc should be in main
<seb128> elmo: and dunno for gtk-sharp
<elmo> seb128: well it's not seeded - could you get it seeded?  in the meantime, I'll move it to universe
<seb128> elmo: ok, thanks
<elmo> and both syncs' done
<mjg59> Bah. Upgrading the BIOS hasn't fixed ACPI.
<seb128> thanks :)
<Kamion> daniels: casper's just the piece that finds the live filesystem, munges it a bit, and pivots into it; you mean the live filesystem?
<Kamion> daniels: AFAIK it comes configured
<lamont> Kamion: grumble the non-symlinks are fine...
<lamont> fixing
<fabbione> huffff
<fabbione> another room has been sand papered :-)
<daniels> Kamion: ok, that's alright.
<daniels> mdz: so if you ship an /etc/X11/xorg.conf with its md5sum already in /var/lib/xfree86/xorg.conf.md5sum, then all you need to do is call dpkg-reconfigure -phigh xserver-xorg, with XORGFORCEPROBE=yes
<daniels> mdz: (with dpkg-deb installed)
<daniels> er, dpkg-dev
* fabbione makes some space on the cd/dvd mirrors to add live and dvd
<Kamion> lamont: thanks, rebuilding now
<Nafallo> is there anyway to but a cd from a grub-shell?
<Nafallo> (i.e. ubuntu livecd)
<lamont> Kamion: still dealing with it - not very apache2 literate.
<lamont> thom around?
<lamont> or anyone else wanna give me the snippet?
<daniels> lamont: it's probably on AllowSymlinksIfOwnerMatch, which does what it says on the box
<fabbione> lamont: what are you searching for?
<daniels> lamont: if you want to unconditionally walk symlinks, add Option FollowSymlinks to the Directory or Location stanza
<lamont> ah, that could be it...
<daniels> (if you don't have a Location stanza, make one)
<daniels> (i think it's SymlinksIfOwnerMatch, rather than Allow..., but meh)
<Kamion> lamont: oh, ok, I'm off for a bit now so let me know when it's done
<gsuveg> thom: are you here ?
<lamont> yeah - is fixed on terranova now.
<daniels> gsuveg: it's Sunday afternoon in the UK
* lamont adds chowning the files to his script. :-(
<gsuveg> daniels: like here. thanks
<gsuveg> daniels: np. email sent
<gsuveg> i've problem with NM on warty
<daniels> networkmanager is known to be rather broken
<daniels> the suggested thing to do is to use netapplet, which is far more likely to actually work
<gsuveg> i see
<lamont> Kamion: is better now.
<lamont> back in 4-5 hours or more
<daniels> woah, they've done the i830 lvds stuff *right*.
<Treenaks> daniels: who have?
<fabbione> God, Jesus and the Holy spirit
<fabbione> nobody else could have done it otherwise
<daniels> Treenaks: tungsten graphics
<daniels> they're setting sensible sync ranges per default
<daniels>    /* With panels, we're always assuming a refresh of 60Hz */
<daniels>    pScrn->monitor->nHsync = 1;
<daniels>    pScrn->monitor->nVrefresh = 1;
<daniels>    /* With panels, we're always assuming a refresh of 60Hz */
<daniels>    pScrn->monitor->nHsync = 1;
<daniels>    pScrn->monitor->nVrefresh = 1;
<daniels> erk, stupid mouse -- sorry
<fabbione> hey
<fabbione> they have copied our setup!
<fabbione> 60Hz was OUR idea!
<Treenaks> fabbione: sue them!
<daniels> heh :)
<daniels> i'd rather buy them a beer than sue them
<Treenaks> "60Hz should be enough for everyone"
<daniels> this gets rid fo the need for 855resolution/865patch and all that crap, as far as I can tell
<fabbione> we can buy many beers :-)
<crimsun> gah, missed Martin. I need to ask him if he's going to provide linux-headers-2.6.10-hardened*
<daniels> Kamion: ping
<fabbione> crimsun: i am pretty sure he will once the packages will ake shape
<fabbione> take
<mako> jdub: that's awesome
<mjg59> daniels: So, dude, are we getting i830 love today?
<daniels> mjg59: it's 3:40am
<crimsun> fabbione: yeah, I'm hoping so. I'm attempting to test a newer ALSA [alsa-driver 1.0.8rc2, with fixes for a nasty OOPS in snd-pcm-oss] 
<daniels> mjg59: by the time I do test builds around all three architectures (i386 is frigging *slow), I'll want to be asleep
<mjg59> You suck
<mjg59> GIVE ME THE LOVE
<Keybuk> I'll give you more loving than you can handle, bitch! :p
* daniels grumbles and goes to fetch another bottle of Red Eye from his bar fridge.
<fabbione> crimsun: you can do that in the normal kernel :-)
* fabbione hits mjg59 with a lot of love
<crimsun> fabbione: I'm trying to stay with -hardened :-)
<daniels> mjg59: 
<daniels> daniels@catsby:~/x/xorg/bleh/xc% wc -l yay-tungsten.diff
<daniels> 6219 yay-tungsten.diff
<mjg59> Yay tungsten
<Keybuk> +# Copyright (C) 2002, 2003, 2005  Free Software Foundation, Inc.
<Keybuk> +#
<Keybuk> +# This file is free software; the Free Software Foundation
<Keybuk> +# gives unlimited permission to copy and/or distribute it,
<Keybuk> +# with or without modifications, as long as this notice is preserved.
<Keybuk> fear.  RMS approved too
<mjt> Keybuk: pls excuse me for a silly question... what's the reason for grepmap? ;)  I mean, why another piece of software is "better" than 3-line patch for modprobe (in m.i.t.)?
<Keybuk> mjt: modprobe doesn't do the same thing
<fabbione> fabbione@gordian:~$ glxgears 
<fabbione> 37840 frames in 5.0 seconds = 7568.000 FPS
<fabbione> 46718 frames in 5.0 seconds = 9343.600 FPS
<fabbione> THIS IS SO RAAAAD!!!!
<fabbione> daniels: ubuntu9 + 2.6.10 + l-r-m
<mjt> Keybuk: think /lib/modules/$version/modules.alias 
<fabbione> see above :-)
<crimsun> gordian, eh? an allusion to gordian knot, praps?
<Keybuk> mjt: as far as I remember, those don't work with device drivers that just say "anything with this set of flags"
<fabbione> crimsun: all my boxes are named after jap's robot
<Keybuk> grepmap is basically just an implementation of the hotplug shell code in C
<Keybuk> so it's drop-in compatible
<fabbione> like gundam, trider, vultus5
<crimsun> fabbione: ah, ok. I mistook that for the prog metal-jazz band, Gordian Knot
<mjt> Keybuk: "anything with this set of flags" -- such as?
<fabbione> crimsun: nope.. you are not the first one :-)
<daniels> fabbione: GLXGEARS IS NOT A BENCHMARK
<fabbione> daniels: AHAHHAHA
<daniels> key	nice
<daniels> Keybuk: ^ that's you
<fabbione> daniels: anyway.. it GLX works only on one of the 2 heads.. but that's nothing new
<Keybuk> mjt: things like the mousedev driver need to be loaded for anything with a given USB class, etc.
<daniels> fabbione: yeah
<daniels> fabbione: get a Radeon, they have MergedFB support :)
<daniels> fabbione: overlays on both heads
<fabbione> daniels: that's why i get 9K FPS on it... and 300 FPS on the other ;)
<fabbione> daniels: nah.. i don't care until xv works on both
<mjt> Keybuk: that mousedev example works just fine with modules.alias
<daniels> fabbione: doesn't TwinView do that?  IIRC that was the main revision for TV over Xinerama
<fabbione> i can watch 8 differnt pron movies full screen...
<mjg59> daniels: Make the Tungsten people do mergedfb support
<fabbione> that's enogh
<daniels> fabbione: Xv works on both with Radeon -- all overlays do
<daniels> mjg59: for i8xx?
<mjg59> Yes
<daniels> mmm, that would be cool
<fabbione> daniels: dunno... i think it does.. but hounetly i don't really care
<fabbione> daniels: i only need headS
<Keybuk> mjt: hotplug upstream didn't seem to think it was sufficient (otherwise hotplug would use it itself)
<fabbione> time to prepare some dinner.....
<fabbione> later folks
<Keybuk> in theory it's just a temporary solution, and will go away eventually
<Keybuk> descent 2.6.8.1-4-686% grep mousedev modules.alias
<Keybuk> zsh: exit 1     grep mousedev modules.alias
<mjt> hmm... hotplug code evolved since 2.4 at least
<daniels> fabbione: seeya
<mjt> Keybuk: do you really have that module? ;) Isn't it hiddev?
<Keybuk> mjt: yes, everyone really has that module
<Keybuk> descent 2.6.8.1-4-686% grep tsdev modules.alias
<Keybuk> zsh: exit 1     grep tsdev modules.alias
<Keybuk> descent 2.6.8.1-4-686% grep joydev modules.alias
<Keybuk> zsh: exit 1     grep joydev modules.alias
<Keybuk> modules.alias is missing quite a few things
<mjt> it's from inputmap, right? 
<Keybuk> yes
<mjt> i mean, all those modules are listed in modules.inputmap
<mjt> oh
<mjt> that's the only map which isn't in modules.alias ;)
<Keybuk> it was easier to clone the hotplug code than futz around with stuff that's not yet finished :)
<mjt> but grepmap is so large tarball!.. ;)
<Keybuk> it's not that big ?
<mjt> 280Kb for 0.1.0 ;)
<Keybuk> heh, that's not big :p
<mjt> the whole module-init-tools is 122Kb ;)
<mjg59> mjt: Most of that will be build infrastructure...
<Keybuk> 104     po
<Keybuk> 108     tests
<Keybuk> 176     m4
<Keybuk> 368     configure
<Keybuk> 480     intl
<mjt> well.. just kidding, really
<Keybuk> mjt: (digs out his e-mail) and modules.alias doesn't yet correctly do usb versions
<Keybuk> given a version in usbmap, you have to match that or later within certain bounds
<Keybuk> mit only does an exact match at the moment
<Keybuk> it also only does precise pci class matches, rather than free ones (but I don't think there's a driver that relies on that yet)
<mjt> i'm trying to "get in touch" with someone who "can get the end to all this nonsense" ;) for quite some time -- there's hotplug and udev, m.i.t, kernel module stuff (file2alias etc, the same is repeated in mit), everyone complains hotplug is too slow, and every distro solves the problem it's own way
<Keybuk> the end theory is that you'd have udev handling kobject events from the kernel, preparing the device node if necessary and running a set of handlers when they're ready to be dispatched.  One of these handlers would be to check the output of m-i-t and load any appropriate module (current hotplug), others would include hal and so on.
<mjt> i just wanted a small tool to do module loading in initrd, somehing akin a tiny scan_pci tool used with ltsp (i think) - which had its own pci->module file.  And after digging into that stuff, i see there's only very small stuff needs to be done to solve it all (it seems -- your comments above makes me think again).. before it's too late and everyone does it their own incompatible way... ;)
<Keybuk> on boot, you still need to coldplug the modules (scan the bus and load them)
<mjt> yes sure
<Keybuk> udevstart seems a reasonably logical place to do that
<mjt> i wrote a small shell script to do that -- based on /sys/bus/pci/devices and modules.alias (aliases works faster in shell than *.*map files)
<mjt> but that's yet another way to do it ;)
<Keybuk> that's basically /etc/hotplug/pci.rc ? :)
<mjt> yes but that works in initrd (small etc)
<Keybuk> it depends on the discretion of the problem you want to solve
<Keybuk> 1) dynamic /dev, or static /dev
<Keybuk> 2) built-in modules, or dynamic modules
<Keybuk> 3) no hardware reporting, hardware reporting
<mjt> and i just changed my pci.rc to call that same my script too (it completes in 3 sec instead of almost 20 sec in sid)
<Keybuk> your script, for example, wouldn't be able to inform hal of the new hardware -- so hal would have to do /yet another/ cold plugging scan when it starts
<mjt> yes sure
<Keybuk> an ideal goal is to reduce the number of hardware scans on boot to just one
<mjt> isn't it impossible when using initrd?
<Keybuk> not necessarily, you just start udevd and hald earlier
<Keybuk> before init :p
<mjt> so initrd becomes persistent?
<Keybuk> (which actually makes some sense, having hardware managing code running before any userland)
<Keybuk> well, you're already mounting /proc and /sys in initrd at that point
<Keybuk> it's a bit blue-sky at the moment, when kobject ide drivers come along, it'll be a very sexy thing to have
<Keybuk> so rather than the 100-odd lines of modprobe that's statically generated, you'd just start the hardware in the system] 
<mjt> "it'll be .." what's "it" ?'
<Keybuk> udev/hotplug-in-initrd
<Keybuk> right now there's no reason to do it
<Keybuk> but if things normally loaded in initrd are kobjected, then there becomes a very compelling reason to do it
<mjt> hmm
<Keybuk> if you can "hotplug" your 
<Keybuk> ide/scsi drivers and filesystem drivers, then it makes sense to do that before you try and mount the root partition
<Keybuk> at that point, you may as well hotplug everything else as well
<mjt> udevD isn't really needed (not even in real root), i think -- provided one does not insert/remove hardware 1000 times a sec (as /dev is in tmpfs and not in udevd memory)
<Keybuk> udevd is very needed
<Keybuk> e.g. usb storage remove events take about a tenth of the time of an insert event
<Keybuk> so you can plug in and out a device reasonably quickly (within a second or two) and have the remove event finish before the start event has even finished
<Keybuk> it's job is to correctly serialise events
<mjt> well yes
<mjt> just too much stuff for initrd... ;)
<Keybuk> yup
<mjt> i liked the days when a single floppy with kernel+initrd image was sufficient to boot any of 500+ our different machines... ;)
<Keybuk> if you hotplug in initrd, you're going to be mounting every storage device on the system at the same time as the root
<Keybuk> I've often wondered how MS deal with scsi drives
<Keybuk> one idea is that you do away with initrd almost entirely; and in userland do hotplugging and detect things like scsi drives and filesystem types
<Keybuk> this writes a configuration onto the minimal initrd to just load those modules
<Keybuk> though this doesn't work if you swap hardware
<mjt> heh.  grub comes to mind, with its ext2fs etc implementation... ;)
<Keybuk> indeed, if grub could actually prepare an initrd for the kernel ...
<mjt> in solaris there's 2nd stage bootloader which loads 16-bit drivers for hardware
<Keybuk> so the kernel would load the right single ide/scsi and filesystem module it needed
<Keybuk> and then the first thing you do in userspace is hotplug the rest of the hardware
<Keybuk> (ignoring, for now, strange people who want separate or even nfs-mounted /usr)
<mjt> oh well.
<Keybuk> that's a fun one
<Keybuk> if you want hotplug to use stuff in /usr, you need to do it after remote filesystems are mounted
<Keybuk> but you can't access remote filesystems until you've hotplugged the network device
<Keybuk> and the network device might depend on firmware in /usr
<Keybuk> *hello!*
<sivang> Keybuk: hehe
<Keybuk> as time goes on, I'm more and more heading towards a "well, don't configure your machine like that" stance on some things :)
<mjt> in that case the initrd (pxe, whatever) should contain the firmware
<mjt> mkinitrd job -- yet another piece of software that um.. does "offline hot^Wcouldplug"
<mjt> i already got some probs with tg3 and network (pxe) booting. but for now it works, ie the firmware, while good to have, is optional
<Keybuk> my tg3 seems ok, I've not yet dropped the firmware into place
<sivang> does anybody know what happens privilege wise, if I have one prog that is executed using sudo, which forks/executes another program ? Does the "child" program  also get the sudo'd privileges?
<Keybuk> sivang: yes
<Keybuk> (this is not generally true of setuid programs though)
<sivang> Keybuk: so sudo makes an excepction and assigns explicitly the child's as root privs?
<Keybuk> no
<sivang> Keybuk: k, thanks
<Keybuk> do you know the difference between real, effective and saved user/group id?
<sivang> Keybuk: hmmm, /me goes on googeling :)
<mjt> heh. that's quite a story...
<Keybuk> ok, well, simply put
<Keybuk> processes have both a real and effective user id
<Keybuk> generally they are the same
<mjt> (all that different uids, that is -- historic mess)
* sivang listens
<Keybuk> processes are entitled to swap them as well
<Keybuk> or make them both the same
<mjt> fsvp 
<mjt> er. fsvo "both" ;)
<Keybuk> mjt: shush, I'm simplifying :p
<sivang> mjt: what's fsvp if I may ask? ;)
<Keybuk> now, when you fork a child process, that child process is created under your real user id
<Keybuk> so if your real user id is 1000, your child will be also 1000 for both real and effective
<sivang> Keybuk: but I can reser it?
<mjt> sivang: a typo: fsvo it should be, or "for some value of"
<Keybuk> your effective user id is used whenever you do anything on disk
<Keybuk> so if your effective user id is 0, you can roughly behave as root
<Keybuk> a setuid program (o+s) is run with its real user id unchanged, but it's effective user id changed to 0
<mjt> s/o+s/u+s/
<Keybuk> so if you run a setuid program as you (1000), it's real user id is still 1000 and it's effective user id is 0
<Keybuk> mjt: gah, typo, thanks
<Keybuk> if that setuid program was to fork a child, the child process would run as you
<Keybuk> so setuid programs that don't know any better can't fork root children
<sivang> Keybuk: ok, that explains alot! Thank you!
<Keybuk> sudo knows better, it knows it's setuid so one of the things it does after it's checked your credentials is sets its real user id to its effective user id (so both become 0)
<sivang> Keybuk: uh ha. got it now.
<Keybuk> setuid gives you a helping hand to root, you still need to pull yourself up
<sivang> Keybuk: as in having the child process set effetive uid to 0
<Keybuk> it also means (for example) that a setuid program can do something quickly as root, and then drop its root privileges and run as just the user again
<sivang> Keybuk: ok, but it has to be setuid prior to runnig right? it can't ask to change it i runtime?
<Keybuk> yup
<Keybuk> you can only set your real, effective or saved user id to the value of one of the others
<Keybuk> you can't stick anything arbitrary in there
<mjt> unles you're God^Wroot ;)
<Keybuk> and once you've dropped root, (so real, effective and saved are 1000) you can no longer switch back to it
<Keybuk> or if you never had root in the first place, you can't stick 0 in there
<daniels> Keybuk: so how come you can only drop your uids to 1000? that sounds like a poor limitation to me
<daniels> unix sucks
<Keybuk> daniels: well, if you're root, you can change your uid to whatever you like <g>
<Keybuk> but you could have a "setuid daniels" process, which when I run I can flip between being daniels or scott until I make a decision
<sivang> Keybuk: so a nont setuid proc could never gain root privs, unless executed by root, right?
<daniels> Keybuk: yhbt yhl hth hand kthxbye
<Keybuk> children would be mine by default, unless I became you in which case they'd be yours
<crimsun> sounds like a handy avoid-blame resolution
<Keybuk> sivang: kernel bugs not withstanding, yes
<sivang> crimsun: hehe
<mjt> nah, it's like "don't let everyone do evil things with the system"
<Nafallo> then sudo -u other_user will gain root to become other_user, right?
<mjt> sudo is setuid *root*
<Keybuk> Nafallo: yup.  sudo is setuid root, checks creds, becomes root, becomes over user, runs process
<Nafallo> good to have that one confirmed :-).
<crimsun> mdz: looks like more soname fun with liboggflac* ? [from Flac-dev] 
<fabbione> elmo: i think that apt-ftparchive is confused about update-notifier
<fabbione> elmo: there are sources in both main and universe
<fabbione> elmo: and binaries only in universe
<fabbione> while the packages file for main reports the binary there
<doko> elmo: please sync graphviz and drdsl from non-free to multiverse
<seb128> elmo: have you synced glib2.0 2.6.1-1 and easytag 1.99.2-2 ?
<mdz> gah, my mail is bouncing
<mdz> daniels: we need a better interface to tell it "just clobber the config" than writing the md5sum to that file
<Kamion> daniels: pong?
<daniels> mdz: what, such as CLOBBERXORGCONFIG=yes?
<mdz> fabbione: main should have update-notifier, universe upgrade-notifier
<mdz> fabbione: upgrade-notifier can be removed
<daniels> Kamion: could you please clag me your Option"Xkb(...)" settings?
<daniels> Kamion: (from the powerbook)
<mdz> daniels: something like that, perhaps
<mdz> daniels: or
<mdz> daniels: if the config is missing entirely, always create a new one
<fabbione> mdz: well something is wrong
<Kamion>         Option          "XkbRules"      "xfree86"
<Kamion>         Option          "XkbModel"      "macintosh"
<Kamion>         Option          "XkbLayout"     "gb"
<fabbione> update-notifier is in both universe and main
<mdz> I don't see it in universe, only main
<Kamion> mdz: new daily-live build up now
<Kamion> publishing actually worked automatically \o/
<mdz> Kamion: how many architectures?
<Kamion> just i386 for now, amd64 and ia64 didn't have fs builds last time I checked and I haven't fixed the powerpc yaboot.conf yet
<fabbione> mdz: it's in both...
<fabbione> http://archive.ubuntu.com/ubuntu/pool/universe/u/
<daniels> Kamion: thanks
<fabbione> either my mirror was mirroring during the sync
<daniels> mdz: mmm.  presumably branden had a reason for his paranoia and I'd like not to differ too much from Debian in that regard if possible, since it's already obtuse and a complete shit to deal with as it stands.
<Kamion> (powerpc is relatively straightforward to fix, but I'm concentrating on this updated warty CD for Linux+ at the moment)
<mdz> daniels: that is not necessarily a safe assumption
<daniels> mdz: point
<daniels> Keybuk: what does dpkg do in this case?
<daniels> it respects removed conffiles, no?
<mdz> yes
<daniels> right ...
<mdz> which is insane and nothing deals with it properly and users get horribly confused
<daniels> let me have a think about it later (i'd rather just do grunt work right now); itmt, that recipe should do it
<mdz> Kamion: what do you think about udevsend
<mdz> Kamion: if you mailed me, please hang onto it for a bit until my mail stops permanently bouncing
<Keybuk> mdz: for the Debian definition of config file, it makes sense
* sivang just read the backlog about ^_^, phew why can't he get a name?
<mdz> daniels: just tried your method; it gives me the video modes question
<mdz> daniels: standard Ubuntu install on the same machine asks no questions
<Kamion> mdz: sounds sane but I have to reserve judgement until I've tried it out :-)
<daniels> mdz: please run with DEBUG_XFREE86_PACKAGE=yes DEBUG_XRESPROBE=yes
<mdz> daniels: believe it or not, I tried this already
<Kamion> which I'll do
<daniels> mdz: (are you sure you have xresprobe and laptop-detect installed?)
<daniels> mdz: i got the same until I installed those two
<mdz> lamont: ?
<mdz> fabbione: http://archive.ubuntu.com/ubuntu/pool/universe/u/update-notifier/
<mdz> fabbione: it is an empty directory
<mdz> Kamion: does it also include the increased ramdisk_size?
<fabbione> mdz: i think my mirror was mirroring during a sync...
<fabbione> and got everything mixed
<fabbione> Kamion: i started mirroring the weekly-dvd locally...
<fabbione> i will let you know how it goes :-)
<mdz> daniels: laptop-detect is present, but xresprobe is missing
<Kamion> mdz: oh, no, not yet, sorry, this has been a very busy weekend for me and I've only just been keeping up with you lot :-)
<mdz> Kamion: no worries
<Kamion> mdz: remind me what you wanted it bumped up to?
<Kamion> 65536 or something?
<mdz> Kamion: 65536 would be good for starters
<daniels> mdz: righto
<mdz> something which runs during dpkg-reconfigure xserver-xorg is calling dpkg-architecture
<mdz> when it wants to be calling dpkg --print-architecture
<Kamion> mdz: done for the next build
<Kamion> hm, let's kick off another build now
<daniels> mdz: yeah, already fixed
<mdz> ok
<daniels> mdz: hence the note about needing dpkg-dev installed
<mdz> Kamion: are lamont's blobs showing up daily now? or will this be the one from friday?
<Kamion> mdz: they seem to be daily
<Kamion> [   ]  livecd-current.cloop    09-Jan-2005 06:38  501M
<Kamion> new image up
<mdz> cool
<Kamion> Purging daily-live images older than 4 days ...
<Kamion> this is just LOVE
<mdz> :-)
<fabbione> mdz: would it be possible to ship a non compressed .iso for the live? together with a tool that will compress?
<fabbione> that might increase of a few N the rsyncability of it
<mdz> daniels: dpkg-dev is installed, in fact (though I'm not sure why), but of course gcc isn't
<mdz> ah, for alien, via lsb
<mdz> fabbione: we could distribute an uncompressed filesystem image, I suppose
<mdz> fabbione: I was thinking we could make the compressed image rsyncable if we really wanted to
<fabbione> mdz: something that we can just toolfoo /path/to/uncompressed | cdrecord or something
<fabbione> mdz: how?
<mdz> fabbione: gzip --rsyncable
<fabbione> is there any negative impact on that?
<mdz> slightly less compression
<mdz> a few %
<mdz> we would turn it off for the final, presumably
<fabbione> that can be quite a lot...
<mdz> fabbione: 1% ~= 5M
<daniels> great, more lib64 braindamage
<daniels> that means bedtime
<mdz> fabbione: in exchange for rsyncability, it is a good tradeoff
<mdz> daniels: No devices detected
<daniels> mdz: xorg.conf and Xorg.0.log please
<mdz> RADEON: No matching Device section for instance (BusID PCI:1:0:0) found
<mdz> sent
<daniels> thanks
<mdz> don't bother replying to the mail; my mail is fucked
<daniels> if you could clag me lspci in /msg, that would be handy also
<mdz> daniels: it looks like the PCI busID of the old config remained
<mdz> I desperately need for it to _ignore_ everything that came before
<mdz> and create a completely new config based only on probes
<mdz> users need this too
<daniels> yeah
<Kamion> guh, please stop changing evms soname, kthxbye
<mdz> Kamion: it changed once in September, and once in January
<Kamion>   * [hoary]  libevms-2.4 -> libevms-2.5.
<Kamion>  -- Colin Watson <cjwatson@canonical.com>  Sun,  9 Jan 2005 19:10:08 +0000
<Kamion>   * [hoary]  Add libelfg0; libevms-2.3 -> libevms-2.4; libgcrypt7 ->
<Kamion>  -- Colin Watson <cjwatson@canonical.com>  Tue,  2 Nov 2004 23:47:39 +0000
<mdz> evms (2.4.0-1) unstable; urgency=low
<mdz>   * New upstream release
<mdz>  -- Matt Zimmerman <mdz@debian.org>  Fri, 17 Sep 2004 17:55:21 -0700
<mdz> oh, that was the warty->hoary dealy
<mdz> delay
<Kamion> although admittedly the latter was the first relevant debootstrap change after the great hoary merge
<daniels> fwiw, debootstrapping hoary seems broken, unless my laptop is out of date
<mdz> daniels: see above
<daniels> doesn't have ubuntu-keyring and ethtool
<Kamion> your laptop's out of date
<daniels> phat
<daniels> alright, important appointment with a pillow
<Kamion> you must have debootstrap << 0.2.45ubuntu16; current is 0.2.45ubuntu19
<Kamion> (well, counting the upload of two minutes ago)
<mdz> Kamion: is there any straightforward way to convince a CD-booted installer to act like a netboot one, and download udebs from the archive?
<mdz> Kamion: that'd be incredibly handy for live CD testing
<Kamion> not that I can think of
<Kamion> well, not since we mutilated the installer in the name of fewer questions :-P
<Kamion> hm, you need net-retriever on the CD for that
<Kamion> but you also need to include download-installer in the initrd rather than load-cdrom, and I suspect that that would break things
<Kamion> mdz: just use the netboot initrd, which also has casper-check in it
<Kamion> there's a netboot/mini.iso somewhere if actual netbooting is inconvenient for you
<Kamion> http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-i386/current/images/netboot/mini.iso
<Kamion> try booting that with casper/enable=true and see what happens
<mdz> actual netbooting could be made to be convenient for me
<mdz> I have PXE stuff set up already
<mdz> hm, no I don't
<mdz> but I have tftpd/bootp stuff set up
<Kamion> since you depend on cdrom-detect, /cdrom should be available despite netbooting by the time casper-udeb.postinst runs
<mdz> yay for depends
* Kamion notes the existence of http://cdimage.ubuntu.com/daily-live/20050109.2/hoary-live-powerpc.iso
<Kamion> ... and starts downloading
<Kamion> ETA three hours or so, so off to relax
<fabbione> ehhe
<fabbione> this new live methods are nice :-)
<Kamion> (bootstrapping off other people's porting work)++
* mdz does a dance and starts downloading too
<mdz> ETA 38 minutes
<mdz> Kamion: we need to find a reasonable way to enable DMA on the CD-ROM
<mdz> it's fairly essential if you're using an IDE CD-ROM drive
<mdz> and the installer would benefit as well
<mdz> we could add a simple "nodma" option for the command line, and start enabling it by default again
<mdz> nocdromdma or so
<mdz> Kamion: current i386 hoary-live seems to work great
<mdz> Kamion: and thanks to the hotplug/udev changes I made yesterday, no more problem with /dev/input/mice missing
* mdz updates the wiki
<fabbione> mdz: i am not too happy to enable DMA by default
<sivang> mdz: we should start a "derivation howto" on the wiki :)
<sivang> mdz: for the livecd at least, if your infra is already mature.
<fabbione> it tends to do much more mess if either the cdrom or the ide controller or a combinantion of all the chain is faulty
<mdz> sivang: brian sutherland was interested in this as well
<mdz> fabbione: that may be, but it is worse to have a live CD without DMA enabled
<fabbione> mdz: i will check something on the kernel cofig
<fabbione> config
<fabbione> afaik we enable DMA by default only on harddisk
<fabbione> we could remove that option
<sivang> mdz: you have his email?
<fabbione> and iirc at the first sign of crappiness the kernel disable the DMA on cdroms
<sivang> mdz: hmmm , come to think, I can look for him on the mailing list. don't bother.
<doko> hmm, is /proc mounted in the buildd chroots by default? gcc-3.4 builds are failing :-(
<fabbione> doko: yes...
<robtaylor_> mdz: sivang: i'll
<robtaylor_> bah
<fabbione> also /dev/pts
<robtaylor_> bi intereseted in helping out
<sivang> Kamion: Is there anything ready for derivation of ubuntu itself? that is, the installer cd. (not pushing or anything, curious)
<robtaylor_> also. take care enabling dma on cdroms
<robtaylor_> a lot of older drives just fail to work#
<fabbione> doko: ppc: make[6] : stage2/xgcc: Command not found
<mdz> robtaylor: however, it seems to work in a majority of cases, and the tradeoff when it's disabled is _huge_ for the live CD
<mdz> for an install, it just takes longer during a noninteractive period
<mdz> on the live CD, it's constantly slowing user interaction
<doko> fabbione: IIRC this only happens without /proc being mounted.
* robtaylor_ remembers getting ver confused one when our manufacturing came to him and said they could install the software on any recent hardware. turned out suppluiers had just started sendinga slightly different model of cdrom ...
<fabbione> doko: it failed much much later on ia64
<robtaylor_> mdz: i dont suppose it's dynamically settable?
<mdz> it is
<robtaylor_> mdz: ideal would be to have dma if it works..
<mdz> the trick is figuring out whether it works
<mdz> it's a combination of chipset, drive, etc.
<mdz> afaik
<robtaylor_> cant switch it on, attemt to read a file, if failiure occurs, run without it?
<doko> fabbione: the build succeeded on my machine. almost the same build succeeded on the debian buildd
<robtaylor_> it'd be a shame if, after these changes that give us a live cd that should run on every system that ubuntu will install cleanly on, we then lose that with this :)P
<robtaylor_> wish i still had access to asystem where i new dma on cdrom failed :/
<Nafallo> my girl's machine fails
<Nafallo> faulty hardware
<robtaylor_> Nafallo:so it works fina normally and fails if you hdparm -d1 /dev/hdc?
<Nafallo> robtaylor_: she installed warty today. I had to guide her to ALT+F2, hdparm -d0 /dev/cdroms/cdrom0 cause it hanged.
<robtaylor_> Nafallo: righty, cool stuff
<robtaylor_> Nafallo: dont uppose you have access to the machine atm? ;)
<Nafallo> robtaylor_: it's on my left side :-).
<robtaylor_> (didn't know warty set DMA by stanbdard on install =) .. it doesnt after install, it seems =))
<lamont> E: Couldn't download libevms-2.4
* lamont grumbles
<lamont> mdz/kamion: non-i386 is not currently debootstrapable...
<robtaylor_> Nafallo: ok, could you try a script that say, hdparm -d1 /dev/cdroms/cdrom0;  ls /media/cdrom/ ; echo $?; hdparm -d0 /dev/cdroms/cdrom0 ...
<robtaylor_> i cant remember quite what goes wrong =)
<Nafallo> robtaylor_: from wartyinstall?
<robtaylor_> Nafallo: just on the box as is will do fine
<Nafallo> oki
<robtaylor_> (with a cdrom in, of course ;) )
<Nafallo> *booting*
<robtaylor_> (and mounted)
<Nafallo> damn cdrom won't open with the ejectbutton :-P
<robtaylor_> Nafallo: /usr/bin/eject? ;)
<Nafallo> on my way, just have to create myself an account ;-)
<robtaylor_> Nafallo: heh
<robtaylor_> mdz: i'm thinking it may well be possible to sanely detect the problem with an ls {some file on cdrom} && dmesg |grep 'DriveReady' or somesuch might suffice for detection
* robtaylor_ rereads that sentence and realsies he forgot what he was writing halfway through =)
<Nafallo> hehe, doesn't like mount /media/cdrom ;-)
<Nafallo> hdc: Timeout waiting for DMA
<Nafallo> hdc: drive not ready for command
<Nafallo> Buffer I/O error on device hdc, logical block xx
<robtaylor_> Nafallo: how long did it take to fail?
<Nafallo> like, *enter, BOOM!* ;-)
<robtaylor_> ah thats ok then :)
<robtaylor_> can you paste me the output of dmesg?
<robtaylor_> Nafallo: does something like d if=/dev/cdrom count=1 of=/dev/null give you the same result?
<robtaylor_> s/d/dd
<Nafallo> http://www.magicalforest.se/~nafallo/dmesg
<Nafallo> last command succedded
<Nafallo> LOL, forgot how dmesg worked :-P
<Nafallo> fixed
<Nafallo> same url :-)
<robtaylor_> Nafallo: hmm, what about with bigger values for count?
<Nafallo> robtaylor_: 9,99,999,9999 succedded
<Nafallo> trying 99999 now ;-)
<Nafallo> worked to
<Nafallo> how large counts should I try?
<Nafallo> s/count/block/
<robtaylor_> Nafallo: mmm
<robtaylor_> maybe bigger block sizes..
<Nafallo> trying six 9's now ;-)
<robtaylor_> try bs=655536, count=1
<robtaylor_> or 2
<robtaylor_> oops one less 5's ther ;)
<jdub> lifeless: http://www.kerneltraffic.org/kernel-traffic/kt20050109_293.html#3
<robtaylor_> Nafallo: or bs=512K, count=1 something like that..
<Nafallo> bs=65536 count=[1,2]  succeded
<Nafallo> testing bs=65536 count=99999 now
<robtaylor_> no, try larger values of bs
<robtaylor_> Nafallo: and small values of count
<Nafallo> oki
<robtaylor_> Nafallo: you can use K and M in specifying bs..
<Nafallo> dooh! bs=99999999 ;-)
<Nafallo> 100M would have been better :-P
<Nafallo> transferred. and I believe I know why it isn't failing ;-)
<robtaylor_> Nafallo: oh?
<Nafallo> hdparm /dev/cdrom shows DMA as off ;-)
<Nafallo> the kernel does that automagically
<robtaylor_> doh!
<robtaylor_> double doh!
<Nafallo> I turned it on again ;-)
<Nafallo> and runs bs=100M count=1 :-)
<robtaylor_> Nafallo: well starting small is probably the sane option ;)
<Nafallo> same errors and then kernel dropped DMA. test succedded :-P
<Nafallo> 10M gives error
<robtaylor_> ok dma back on, start with bs=512 count=1, keep doubling till failure
<Nafallo> oki
<robtaylor_> Nafallo: thanks :)
<Nafallo> 8M worked, so I tried 10M again. worked this time. 16M fails :-P.
<Nafallo> using warty pressed livecd for info.
<Nafallo> turned dma on and tried 10M again, and it fails :-P
<Kamion> lamont: I beat you to spotting that one; upgrade debootstrap :)
<robtaylor_> Nafallo: hmm
<Kamion> sivang: not my department, sorry, dunno
<sivang> Kamion: k, np
<Nafallo> robtaylor_: dd starts from the beginning of the CD every time?
<robtaylor_> Nafallo: yep, unless you use skip=bla
<Nafallo> robtaylor_: even more odd then ;-)
<Nafallo> 10M fail, succedd, fail :-P
<lamont> Kamion: yeah - done.
<lamont> I need to update ubuntu-meta too.
<lamont> ia64 is pretty booooring otherwise
<robtaylor_> Nafallo: ah well, guess we can conlcude that dding is a bad way to cause the failure :)
<Nafallo> robtaylor_: agreed ;-)
<jdub> mdz, Kamion: http://www.advogato.org/person/mbrubeck/diary.html?start=90
<Nafallo> robtaylor_: mounting is much more effective :-P
<lamont> *** Error -5 compressing block 0! (compressed=0x7fbffff950, len=548682070304, uncompressed=0x526010, blocksize=65536)
<lamont> /usr/sbin/livecd.sh: line 170:  9566 Segmentation fault      create_compressed_fs $IMG 65536 >livecd.cloop
<lamont> ew!
* lamont isn't sure about that .5 TB length...
<Kamion> lamont: didn't think ubuntu-base directly depended on libevms-2.5?
<Kamion> it's not in the seed list itself, it's just a dependency ...
<robtaylor_> mdz, Kamion: where can i find casper?
<mdz> robtaylor: apt-get source casper
<robtaylor_> hmm
* robtaylor_ apt-get updates ;) 
<robtaylor_> mdz: thx :)
<Nafallo> robtaylor_: you need silverfairy anymore? :-)
<lamont> Kamion: another round of builds with latest debootstrap and ubuntu-meta will run at 22:06 london time.  should take about 25-30 minutes to complete.
<Kamion> lamont: let me know when amd64/ia64 are available; it'll be easier to finish automating the builds if they have the same set of architectures
<Kamion> otherwise, sure, I can kick off another build then
<mdz> Kamion: powerpc live CD didn't work
<mdz> it's missing some modules we need
<Kamion> really? I haven't trimmed udebs yet
<Kamion> what was missing?
<mdz> dm-snapshot
<mdz> looks like i386 uses common/md-modules
<Kamion> huh
<mdz> while powerpc has a separate one for some reason
* Kamion blames fabbione
<lamont> btw, livecd-current.manifest
<mdz> fabbione: ping
<mdz> Kamion: the udeb stuff in linux-source could probably use some review, to clean up inconsistencies like this
<Kamion> yes
<mdz> likewise for the configs, really, but that's harder
<Kamion> it was probably because the same set of modules weren't built for powerpc at the time I created that file
<Kamion> the udeb review has to go hand in hand with the config review to some extent
<jdub> mdz: how's casper going?
<mdz> jdub: rad
<lamont> Kamion: question for you... if the build fails, should livecd-current.* go away, or remain so that at least you get something?
<lamont> currently they do the latter
<Kamion> lamont: hm, think I'd prefer it to remain
<jdub> mdz: is this dc-build related discussion?
<mdz> jdub: that, and "damn, powerpc doesn't work because of something silly"
<jdub> sucks being a second class citizen
* Kamion goes to fix that bug in Debian
<lamont> Kamion: was thinking you would./
<Kamion> dm-snapshot was only added to common/md-modules in September
<jdub> house got robbed this morning :|
<lamont> tomorrow I'll go leach bandwidth and download the then-current CD
<Kamion> jdub: erk
<lamont> jdub:???
<mdz> Kamion: just confirmed that i386 and powerpc build identical modules, so it should be safe to fix that
<jdub> couple of laptops stolen, wish they'd taken one or all of the three tvs we don't want
<mdz> amd64 looks to be OK
<Kamion> mdz: yes, I was checking it in Debian as well
<mdz> ia64 and sparc are also OK, seems like only powerpc was weird in this respect
<Kamion> shall I file a bug on our kernel?
<mdz> I'd prefer to just fix it, but fabbione has a kernel upload pending I think
<mdz> so yeah, I guess a bug
<lamont> mdz: does ubuntu-meta_0.16 have ia64 as well?
<mdz> lamont: no
<lamont> grumble.
<mdz> lamont: I thought you were going to do it
<lamont> wanna roll 0.17, or shall I?
<lamont> yeah - I tried, we stepped on each other.
<mdz> Jan 08 13:50:00 <mdz>   lamont: and you can do that whenever you're ready
<lamont> I'll roll it now.
<mdz> go for it
<lamont> again. :-(
<Kamion> #5372
<Kamion> I wonder why dm-snapshot was added to kernel-wedge in the first place? Nothing in mainline d-i uses it.
<mdz> Kamion: maybe it went in with the rest of dm-*
<Kamion> no, it was added explicitly and individually
<Kamion>   * Martin Michlmayr
<Kamion>     - Add dm-snapshot.o to md-modules if it's available.
<gsuveg> can i use gimp22 under warty ?
<lamont> 0.17 uploaded
<kent> gsuveg, ask those kind of questions in #ubuntu
<mdz> Kamion: I wonder what tbm was up to
<mdz> it would not be at all common to configure a snapshot during installation
<Kamion> I think he was working on RAID stuff at the time, but I don't remember the details
<lamont> sigh. local mirror is 852 files out-of-date. :-(
<lamont> Kamion: ia64 requeued to run at 22:36, this time with dependencies.. :-)
<gsuveg> kent: ok. sorry
<Kamion> lamont: is amd64 long-term screwed, or will it start working with the current build?
<mdz> lamont: is the issue corrected which was preventing amd64 live fs builds from being possible?
<Nafallo> it's only the livecd that's broken on amd64?
<lamont> 8458 Segmentation fault      create_compressed_fs $IMG 65536 >livecd.cloop
<lamont> you mean that bug?
<lamont> *** Error -5 compressing block 0! (compressed=0x7fbffff950, len=548682070304, uncompressed=0x526010, blocksize=65536)
<lamont> still there, cause unknown
<Mithrandir> that's amd64?
<lamont> yep
<Mithrandir> ugh :/
<Mithrandir> it used to work?
<lamont> Mithrandir: unknown
<lamont> it used to die because there was no loopback support in the kernel.
<Mithrandir> ok
<lamont> OTOH, amu built home-edition OK, iirc
<Mithrandir> he has an amd64
<Mithrandir> ?
<mdz> lamont: no, I was talking about the lack of loop modules and what not on the build system
<mdz> lamont: this is the first I think I've heard about it segfaulting
<mdz> lamont: that 'len' value looks quite wrong
<mdz> I have this bad feeling that nobody has really used cloop on anything but i386
<mdz> powerpc should be fun
<lamont> mdz: kernel was fixed yesterday.
<lamont> and then it was failing because of evms-2.4
<lamont> we're finally up to the segv failure.
<lamont> note that if you want to test a live-dvd, the uncompressed fsimg can be made available now... :(
<mdz> lamont: try advfs?
<mdz> never mind; they're the same now
<mdz>  * * Sun Okt 26 01:05:29 CEST 2003 Klaus Knopper
<mdz>  * - Changed format of index pointers to network byte order
<mdz> thanks, Klaus
<mdz> so there's hope
<mdz> jdub: I need some mbox love from mailman
<Kamion> combo install/live DVDs need a bit more work at the cdimage end
<mdz> jdub: my mail was fucked this morning and I missed a bunch of list mail
<mdz> lamont: reproduced the amd64 crash
<Kamion> at the moment I just have a LIVE flag; I need to invent another flag called INSTALL or something to allow for combinations
<Kamion> shouldn't take too long, because I can find all the places where it's needed by grepping for LIVE :)
<mdz> hmm
<mdz> that weird 'len' value comes from it printing the value of a pointer as an integer
<lamont> that would do it.
<mdz> doesn't explain the crash, though
<lamont> did mono move into main?
<mdz> #define Z_BUF_ERROR    (-5)
<mdz>      compress2 returns Z_OK if success, Z_MEM_ERROR if there was not enough
<mdz>    memory, Z_BUF_ERROR if there was not enough room in the output buffer,
<mdz>    Z_STREAM_ERROR if the level parameter is invalid.
<mdz> lamont: should have
<mdz> so it thought there was not enough room in the output buffer
<lamont> muine (in main) Build-depends a bunch of mono stuff...
<robtaylor_> Nafallo: umm, hope you took my lack of reply as a 'no' ;)
<Nafallo> robtaylor_: indeed ;-)
<lamont> Kamion: i386 and ppc are there.
<lamont> ia64 is, um, borked
<lamont> amd64 has the segv issue
* lamont works on ubuntu-meta_0.18
<lamont> mdz: or is shipping openoffice.org on ia64 a requirement?
<lamont> and what's the best way to strip the OO.o stuff from the desktop list for just one arch?
<jdub> mdz: ok
<Mithrandir> lamont: I don't think that's advisable if we want elmo to retain his sanity.
<mdz> lamont: ia64 seems pretty fucked overall as far as hoary is concerned
* lamont doesn't want to ship it either
<lamont> mdz: if we get oo.o gone from the u-d deps, then we should have a livecd.
<lamont> then again, anna doesn't seem to like it very much
<mdz> I'm not inclined to bother
<lamont> to bother with?  ia64/hoary
<lamont> ?
<mdz> ia64 live cd
<lamont> ah, yes.
<mdz> and, if things don't change, ia64 hoary
<lamont> it has a glibc now...
<magnon> ia64 does seem pretty screwed overall
<mdz> the community people who said they would look after it have disappeared, as far as I can tell
<lamont> I've heard from t-bone, but only that he was hip deep until january started...
<lifeless> jdub: thanks!
<lifeless> fabbione: http://www.kerneltraffic.org/kernel-traffic/kt20050109_293.html#3 <--- can we get this, please please please
<jdub> heh
<mxpxpod> lamont: when I go to upgrade libmono0 on powerpc, every mono app wants to uninstall... is that being fixed?
<lamont> so back to the mono question....
<lamont> mdpxpod: it's ftbfs, and known broken upstream.
<mxpxpod> ftbfs?
<lamont> the last I've heard, they planned to upload what was needed once debian had built all the architectures they cared about.
<lamont> fails to build from source.
<mxpxpod> ah, ok
<mxpxpod> thanks
<lamont> see people.ubuntu.com/~lamont/buidlLogs/m/mcs/1.0.4-1
<lamont> mdz/jdub: so does muine belong in universe, or did mono enter main while it was ftbfs
<lamont> ?
<Mithrandir> I should set up a local mirror, I think.
<jdub> lamont: mono shouldn't be in main...
<lamont> Mithrandir: of at least main/restricted for at least amd64...
<jdub> (it's not here atm)
<mdz> lamont: is t-bone back in the game and not going off on a ship somewhere?
<lamont> jdub: the muine needs some love.
<lamont> mdz: nfc
<jdub> lamont: what's up with it?
<Mithrandir> what's the current recommended mirror script?  Debmirror?
* lamont will pester some more ia64 community folks
<jdub> (turns out muine 0.8.0 just came out, so my quick rebuild upload was pretty pointless)
<lamont> Checking for already installed source dependencies...
<lamont> debhelper: missing
<lamont> mono-jit: missing
<lamont> mono-mcs: missing
<lamont> c-sharp-compiler: missing
<lamont> that's from the build of muine_0.6.3-4ubuntu1
<jdub> i thought all the mono foo was fixed up now?
<lamont> jdub: see 5052
<lamont> it's understood... it's ftbfs.
<lamont> built upstream, but not buildable in our archive.
#ubuntu-devel 2005-01-21
<sivang> mdz: any info on the lanchpad integration into the menu panel bounty? is there a wiki page for that or bugzilla entry?
<mdz> lamont: looks like sizeof(unsigned int) != sizeof(unsigned long) problems
<lamont> GAH!
<lamont> simple, or systemic?
<Kamion> meh, why does 'reboot' in d-i suddenly not work?
* Kamion blames udev because he can
<mdz> lamont: systemic
<Kamion> or maybe I should be blaming busybox ... hmm
<mdz> reboot is hard to screw up
<robtaylor_> Kamion: umm, i was wondering before.. why deos d-i still use busybox-cvs?
<mdz> kill -INT 1
<mdz> robtaylor: yes
<Kamion> robtaylor_: what else would make any sense?
<robtaylor_> Kamion: umm, hasn;t busybox 1.0 been released for some time?
<lamont> mdz: that's another mark for ia64, hten.
<Kamion> robtaylor_: the busybox package in Debian is ancient
<Kamion> robtaylor_: in Ubuntu, we need some stuff newer than 1.0
<Kamion> so *shrug* it's not worth the size of the diff it would take to change
<robtaylor_> Kamion: ah, righty :)
<Nafallo> noone is working on #5256, right?
<Nafallo> ((except me then ;-) ))
<Kamion> robtaylor_: and the diff from busybox-cvs to 1.0 doesn't seem to be too important, AFAIK
<mdz> lamont: I can fix it trivially if I disable a bunch of stupid shit
<mdz> this thing is such crap
<robtaylor_> Kamion: heh. i was just about to say, actually you're using cvs lower than the 1.00 release..
<robtaylor_> s/lower/older
<mdz> if you give it the --best option, it tries zlib compression levels 1-9 and chooses the one with the smallest size
<mdz> which ends up being 9
<mdz> always
<Kamion> mdz: actually I suspect I screwed up by typing '/sbin/init' rather than 'exec /sbin/init'. whoops
<lamont> mdz: go figure...
<Kamion> mdz: is there any reason that we couldn't lose /sbin/hotplug.real entirely in d-i?
<mdz> lamont: emailed you a patch which will get you going
<mdz> Kamion: if you switch to udevsend, none
<mdz> it breaks the stupid shit in favour of fixing the bit we actually use
<mdz> I'll work up a more correct patch later
<Kamion> goodie, though I'll need a small fix to debian-installer/build/Makefile before removing it
<lamont> mdz: meaning I should upload the patch, or just install it in the chroot?
<mdz> lamont: that patch should probably not go into the archive
<Kamion> mdz: you were talking to lamont and not me there?
<mdz> Kamion: correct (regarding the cloop-utils patch)
<Kamion> ok
<lamont> mdz: OK.  getting taken away for some family stuff now, if that's ok...
<Nafallo> YES! Fixed my first Ubuntu-bug :-P
<sivang> Nafallo: # ?
<Nafallo> 5256
<Nafallo> just have to make the changes look more nice, generate the patch and add it on bugzilla :-)
<Nafallo> when to mark a bug fixed?
<Kamion> when the fix is in the archive
<Kamion> not just when a patch has been suggested, if that's what you're thinking
<Nafallo> oki
<mdz> jdub: which bit of that advogato diary did you mean for me to see?
* mdz processes queued firefox tabs
<jdub> mdz: the ssh-add on first ssh invocation bit
<chrisa> ssh-add on ssh invocation sounds useful
<Mithrandir> jdub: url?
<jdub> http://www.advogato.org/person/mbrubeck/diary.html?start=90
<jdub> just a shell script
<Mithrandir> it's neat, though
<mdz> I think we talked about that sometime last year
<jdub> mmm, thus my interest ;0
<jdub> ;)
* tseng uses keychain
<mdz> trulux: ping?
<mxpxpod> have the hotplug patches worked on in mataro been put into hotplug for powerpc?
<Keybuk> mxpxpod: which ones?
<Keybuk> if you mean the asynchronous stuff, no.  we've deferred that to hoary+1 as it involves fairly large changes and we'd rather have more time to work on them
<Mithrandir> people who use implicit sizes and think that sizeof(long) == sizeof(int) should be shot.
<mdz> Mithrandir: looking at cloop?
<Mithrandir> yeah
<mdz> Mithrandir: unless you enjoy it, there's no need; I asked Charles to look at it tomorrow
<mdz> he doesn't seem to have a bugzilla account yet, but I mailed him
<Mithrandir> ok; I'll see if this tiny little change fixes it, if so, I have a fix.  Not a real fix, since that means getting rid of loads of cruft, but a fix.
<mdz> I already gave lamont the quick fix
<mdz> (changing len to unsigned long and deleting the code which uses compress.cc)
<mdz> that code is only used when --best is passed, which is a silly thing to do anyway
<Mithrandir> ah, ok.
<mdz> Kamion: is daily-live daily now, or still manual?
<Safari_Al> jdub, yo?
<Safari_Al> jdub, just wanting to check about those docs :)  Have to head off now but I'll be back later this arvo.
<mdz> whee, just got powerpc live CD going
<mxpxpod> Keybuk: ah, ok
<mxpxpod> Keybuk: thanks for the update :)
<stub> Weird - Can someone try and repeat this?
<stub> Fire up the volume control, and play some music. Now switch back and forth between the OSS and Alsa mixers (File -> Change Device)
<stub> I'm noticing quite distinct changes in sound
<stub> Like some of the hidden controls are being randomly reset
<jdub> stub: they're not synced
<jdub> stub: so when you change them around, they're flipping back and so on
<stub> Yeah - but if I switch to one, and switch back *it sounds different* to what I started with
<stub> Hmm... seems to be only if I have the 3d controls turned up on the Alsa mixer.
<stub> mmm... yes... jack up the 3d controls and every time you switch back to the Alsa mixer you get a different mix ;)
<jdub> :-)
<`anthony> stub: That's because ALSA mixer was designed by crackheads.
<zenrox> and oss by potheads
<zenrox> witch one works better
<zenrox> lol
<`anthony> zenrox: I'll take the OSS mixer over the 22 separate mixer controls that ALSA gives my onboard sound.
<`anthony> (no, that's not a joke. _22_ controls.)
<zenrox> `anthony,  ya same here but alsa imho is better casue of the 22 controles it gives me
<zenrox> oss only has a few
<`anthony> zenrox: riiiight. sure. tell me, quick: for correct behaviour of the microphone, what settings should Mic, Mic Select and Capture devices have (settings == mute/no mute, capture/no capture, volume/no volume) ?
<`anthony> If you answered Mic: Muted, Capture, Capture: Not Muted, not Capture, Mix: no volume, no muted -- then you win a cookie.
<jamesh> `anthony: in part, that is a problem with the user interface
<`anthony> jamesh: Well, the UI is just reflecting the underlying settings of the "devices". 
<`anthony> But in any case, there needs to be a higher-level UI - shtoom's growing one when running under ALSA. It will fix the settings up for you (after prompting).
<jamesh> `anthony: yep, and most of them shouldn't be visible by default (many are only useful to audio geeks)
<`anthony> jamesh: more importantly, the standard "audio mixer" program should check for sane settings each time it's run, and prompt "Your audio device settings are all fucked up. Should I fix them? Yes/No"
<jamesh> `anthony: btw, some sound cards provide even more mixer settings in alsa: http://people.redhat.com/~alexl/files/why-alsa-sucks.png
<jamesh> `anthony: yep.  ALSA's policy of setting all levels to zero by default is a problem
<jamesh> it is basically a cop-out on picking sensible defaults
<`anthony> I've seen people run alsamixer, not realize it's doing anything, and smack on keys and end up with muted master, or capturing on the mono output, or whatever.
<jamesh> sure.
<`anthony> hence the shtoom 'fix-the-audio-settings-for-you' mode.
<`anthony> trying to debug this stuff remotely is more than a pain.
<jamesh> the Windows mixer only shows a few standard channels by default
<jamesh> and has a prefs dialog where you can show/hide all the weird ones.
<bob2> you shtoom-hippy
<`anthony> the one for linux should, too. in addition, the 'Capture' flag should be set intelligently, and the basic UI should _not_ let you change it.
<pasc> `anthony: you broke me
<jamesh> `anthony: have you looked at the gnome-2.8 volume control app?
<pasc> `anthony: I bought a mouse exactly like yours when I went through HK
<jamesh> it looks a lot better than the screenshot above ;)
<bob2> also because everytime I see 'shtoom' I think 'shroom'
<`anthony> jamesh: It says "Sorry, no mixer elements and/or devices found", and then exits. You're right, that looks much better than alsamixer ;)
<fabbione> morning
<`anthony> pasc: ziplinq.com
<jamesh> `anthony: okay then.  Have you tried it on a working system? :)
<`anthony> jamesh: I think it's expecting the OSS-compat devices, but I killed those.
<jamesh> `anthony: it should do ALSA too.
<`anthony> The only thing that was still using them was #&*($(#$& flash, and I wanted it to stop with the noise-making banner ads.
<`anthony> jamesh: looks like it relies on esd or gstreamer.
<jamesh> ah.  the volume control does let you turn off channels now
<jamesh> although it has everything turned on by default.
<mdz> fabbione: morning
<sivang> mdz,fabbione : morning.
<fabbione> mdz: hey.. i might be a bit late tomorrow for the CC meeting, but hopefully not.
<fabbione> mdz: do you want me to prepare a draft for the kernel team?
<fabbione> or do you want to lead it directly?
<mdz> fabbione: just make sure that the kernel team item is low on the agenda, so that you're there when we start to discuss it
<mdz> fabbione: a draft what?
<Keybuk> I'm sure what I'm doing here is wrong
<Keybuk> but it feels so right
<Keybuk> I have two checkouts, one I've been fucking around with, and another that's clean
<Keybuk> and I'm gradually committing my fucking about my copying stuff from the dirty to the clean one
<Keybuk> and then sync-tree'ing the dirty one to catch up
<Keybuk> THIS IS WHAT HAPPENS WHEN YOU CAN'T DO PARTIAL COMMITS
<jdub> tla commit -s "blah" -- file file file <- ?
<Keybuk> jdub: doesn't work if you add, remove, move, copy, etc.
<fabbione> mdz: it is already the last one.. a draft on how to organize the kernel team...
<jdub> Keybuk: mmm
<fabbione> mdz: do you have any particular interest in getting all the UML stuff from 2.6.11 into hoary?
<mdz> fabbione: no
* fabbione skips a few tons of patches
<jdub> My name is Nceba Botha working at Tshwane University of Technology in
<jdub> Pretoria, South Africa.  We have just installed Ubuntu Linux as a print
<jdub> server but we are struggling with the root password.  Is there a default
<jdub> root password in Ubuntu?  If not how do we configure it?
<jdub> 
<jdub> ;-)
<fabbione> hehe
<sivang> heheh
<sivang> jdub: we need to add this on the disk stored wlecome page.
<sivang> jdub: (maybe, thinking out loud)
<sivang> jdub: that is , instructions how to enable / use sudo
<jdub> sivang: thing is, normal users don't care
<Treenaks> jdub: hm.. when I started reading I thought it was some 419 spam you pasted...
<Treenaks> jdub: it could at least link to the wiki more prominently
<Treenaks> jdub: ("if you have more questions, look on the wiki")
* Treenaks off
<jdub> yep
<sivang> Treenaks: heheh, really sounded like this - I got a couple asking me to take their 40$G for them , until they can take it back...
<sivang> jdub: I'll ad this to the wishlist.
<mdz> sivang: that's more or less implicit in what's already there
<mdz> I added an item requesting that there be more effective links to existing documentation
<fabbione> mdz: there are some rumors that they might release a 2.6.10.1 or 2.6.11 pretty soon to include the security fixes....
<sivang> mdz: I saw those, but maybe a specific link to that notion of sudo for people coming from other os's ? I mean, that's a central aspect of the system's managemtn
<mdz> fabbione: will you be uploading the kernel today?
<fabbione> mdz: yes for 2.6.10
<mdz> sivang: my instinct is that there is very little overlap between the people who will read the "about ubuntu" page and people who wonder about things like root passwords
<mdz> fabbione: ok, good.  I need that dm-snapshot/powerpc fix
<bob2> it's in the FAQ and people still refuse to read it
<fabbione> mdz: hmmm i still didn't see it in the bk changelog i am parsing.. 
<fabbione> mdz: i will make it so :-)
<mdz> fabbione: the one I filed a bug about in ubuntu bugzilla
<mdz> it is not upstream
<fabbione> ah ok
<fabbione> i didn't check bugzilla yet
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=5372
<mdz> trivial
<mdz> for some reason, powerpc has a separate md-modules list for the udeb
<mdz> but it should be the same as the others
<mdz> fabbione: with that fix, we can have powerpc live CDs today
<fabbione> sure no problem
<mdz> thanks
<mdz> daniels: what's the status of the live cd X configuration issue?
<sivang> mdz: right, not about root passwords, but how you use sudo for system managment tasks, which are not available from the gui yet, but maybe there are none anymore, however I may be wrong so this is a mere suggestion.
<mdz> sivang: we can only lead the user to documentation; we cannot make them read it
<zenrox> mdz tho we should
<zenrox> lol
<sivang> mdz: ok
<fabbione> mdz: 5372 pending upload
<trulux> mdz: pong, just near to go to school
<trulux> mdz: howya?
<mdz> trulux: ping me when you have time to discuss the requirements doc you wrote in the wiki
<trulux> mdz: ok, now i must go to school
<mdz> yes, I heard
<trulux> mdz: have a nice day!
<mdz> goodbye
<doko> good morning all
<sivang> doko: morning
<doko> lamont: what are you doing with the buildds? gcc-3.4 did build some hours later on powerpc and ia64 ...
<mdz> fabbione: how much smaller do the linux-image .debs get if you use bzip2 compression?
<mdz> lamont is likely to be asleep
<fabbione> mdz: dunno...
<fabbione> let me check
<fabbione> the source approx 10Mb
<fabbione> i will need to run a test build to see the .deb
<mdz> yes, the next time you run a build, please measure
<mdz> I thought it might be useful to bzip2 the 686{,-smp} and k7{,-smp} kernels if they would be significantly smaller
<mdz> because they are very frequently downloaded
<mdz> ok, good night
<fabbione> night :-)
<doko> mdz: lrm: yes, each module increases to 4.5mb size
<doko> fabbione: how to rename the lrm package, if I need to add new tarballs (binary files)
<d3vic3> morning 
<fabbione> doko: hmmmm i need to check... gimme a sec
<d3vic3> fabbione, help 
<fabbione> linux-restricted-modules-2.6.10 -> linux-restricted-modules-2.6.10.0 perhpas?
<fabbione> d3vic3: ?
<d3vic3> fabbione, how do I assing a bug to myself ?
<fabbione> d3vic3: on bugzilla?
<d3vic3> s/assing/assign/
<d3vic3> yes
<fabbione> open the bug
<doko> fabbione: ok, will do.
<fabbione> there is a thumb: Reassing to:
<fabbione> put your email address in there and push on commit
<fabbione> d3vic3: you need to use your bugzilla account email address
<d3vic3> ok
<fabbione> doko: that's just an idea..
<fabbione> you will have to check that it doesn't break anything
<fabbione> doko: also at packages that come out of it
<fabbione> since ubuntu-meta uses them somehow
<fabbione> doko: otherwise uuencode and add it as real binary in the next release
<daniels> mdz: looking at it now, I think I know how to do it
<Mithrandir> daniels: why did you wonder about whether I'm using an ATI card?
<doko> fabbione: hmm, yes, uuencoding should be safer approach
<fabbione> doko: remember to bump the nvidia and fglrx versions in debian/rules
<fabbione> Keybuk: ping
<Keybuk> fabbione: yo
<fabbione> Keybuk: sorry that i need to bother you
<fabbione> dpkg --build calls dpkg-deb right?
<fabbione> so if i need to tell dpkg to use bzip...
<fabbione> dpkg --build -Zbzip2 ?
<fabbione> unfortunatly the kernel package is so complicated that i can't just swith to use dh_buildeb
<fabbione> as in the example
<Keybuk> I think that'll work
<crimsun> is it -Z or -z?
<Keybuk> dpkg --build ... => dpkg-deb --build ...
<Keybuk> -Zbzip2
<crimsun> k, thanks
<fabbione> Keybuk: can i just export an ENV var to automatically switch to bzip instead of having to modify the scripts?
<Keybuk> no, you have to modify the scripts as it's a per-package decision
<Keybuk> otherwise you could accidentally build things the wrong way
<fabbione> Keybuk: ok
<Keybuk> I would be surprised if the kernel benefits
<fabbione> ok
<fabbione> it might...
<fabbione> we need to give it a shot
<Keybuk> bzip2 is generally better for mostly-text packages
<fabbione> but to do that i need to modify kernel-package first
<fabbione> that's why i was hoping for an ENV var that i can export in the main kernel package
<fabbione> and propagates down to all the mess
<fabbione> thanks mucho dude
<Keybuk> no worries
<Mithrandir> why is python-gtk2-doc in universe and not main?
<crimsun> My guess is that no one has stepped up to maintain it. It doesn't seem to be a licensing issue regarding the documentation.
<d3vic3> mdz, ping
<fabbione> he is asleep
<d3vic3> cloop won't build 
<d3vic3> fabbione, help
<d3vic3> ./debian/rules build <-- just gives me errors 
<Mithrandir> d3vic3: use dpkg-buildpackage
<fabbione> d3vic3: cloop kernel module or utils?
<fabbione> there is no need to build the kernel module since we already have it
<d3vic3> utils I think 
<fabbione> in the main kernel
<fabbione> hey pitti
<d3vic3> I'm trying to fix a bug 
<pitti> Hi guys
<d3vic3> but i can't build it to begin with 
<fabbione> pitti: you got mail
<d3vic3> dpkg-buildpackage give same error 
<fabbione> pitti: i have some other pending stuff from debian
<fabbione> d3vic3: be more specific
<fabbione> show us the error at least
<Treenaks> d3vic3: did you install the build-depends?
<pitti> fabbione: you mean the enhanced do_brk patch?
<d3vic3> yes
<fabbione> pitti: yes
<d3vic3> /home/knopper/advancecomp-1.9_create_compressed_fs/missing: No such file or directory
<fabbione> i have others security stuff from debian
<pitti> fabbione: what about all the other occurrences of do_brk? They are not fixed by this patch AFAICS
<fabbione> pitti: that one fix them all
<fabbione> linus did that commit
<fabbione> and there is nothing in bk
<fabbione> other than that
<pitti> hmm, ok
<d3vic3> fabbione, gives the error above 
<fabbione> d3vic3: apt-get source cloop-utils (or whatever they are called)
<fabbione> apt-get build-dep cloop-utils
<fabbione> go in the source
<fabbione> do your changes
<fabbione> dpkg-buildpackage
<d3vic3> did all that 
<d3vic3> still give me error when i try to build 
<fabbione> d3vic3: bug number?
<d3vic3> #5376
<fabbione> d3vic3: works fine here
<fabbione> you need to check your environment...
<d3vic3> ok 
<d3vic3> that is ? 
<fabbione> it depends what you are doing....
<d3vic3> jut trying to build the package 
<fabbione> what modifications you did to the package
<fabbione> and so on
<d3vic3> so far 
<d3vic3> nothing 
<d3vic3> becouse i can't even build it 
<fabbione> d3vic3: ayou you runnig hoary?
<d3vic3> no
<d3vic3> warty
<Mithrandir> d3vic3: there's something funky on your system, check that you have enough free space.
<fabbione> d3vic3: if you need to do development for hoary
<fabbione> you need to either run hoary or have a hoary chroot
<amu> moins 
<d3vic3> hmm 
<fabbione> you are probably trying to fix something on an old version of the package
<fabbione> hey amu
<d3vic3> oh right 
<d3vic3> we don't have enough bandwidth for me to update to hoary here 
<jdub> anyone got an nforce3-based amd64 machine?
<d3vic3> I think
<daniels> jdub: i'll have an nf4-based amd64 soon
<fabbione> you all suck
* Mithrandir hits daniels with a hammer.
<fabbione> i want an amd64 too
<jdub> daniels: nf4... yeek
<jdub> fabbione: i don't have on e;)
<jdub> fabbione: just checking if nf3 doesn't suck for my housemate
<Mithrandir> jdub: seems I have one, why?
<Kamion> mdz: still manual, will fully automate RSN
<jdub> Mithrandir: how's the sata/lan/audio/etc hadware suport?
<amu> fabbione: buon giorno ;) 
<Mithrandir> jdub: working, I think.  We haven't checked th audio, but apart from that, it works.
<Kamion> morning all
<Mithrandir> hi Kamion
<jdub> Mithrandir: cool, thanks
<Mithrandir> jdub: it's running sarge just fine at least.
<daniels> jdub: heh, should be fun
<amu> daniels: matt told me, i should test your Xconfigurator :)   
<daniels> amu: sure
<daniels> amu: export XORGFORCEPROBE=yes && sudo dpkg-reconfigure -phigh xserver-xorg
<daniels> amu: make sure you have dpkg-dev installed
<Kamion> fabbione: oh, you haven't finalised this kernel upload yet have you?
<Kamion> fabbione: I'd like the rtc module to be available in a udeb
<fabbione> Kamion: not yet..
<fabbione> just tell me what and where and it will be in :-)
<Kamion> is there any other udeb where it would fit neatly? I couldn't think of one
<fabbione> no idea...
<fabbione> do we have a misc module udeb?
<Kamion> if not, rtc-modules would be great; amd64 and i386 should have it, and on sparc you'll want to add rtc-modules to the kernel-image Provides in debian/d-i/sparc/package-list
<Kamion> having it separate would probably work well for dependencies, since it's only the timezone question that needs it
<Kamion> shall I add it to kernel-wedge?
<fabbione> hmmm
<Kamion> yeah, I should, I think
<fabbione> only i386 and amd64 has it has module
<Kamion> yep
<fabbione> i think we should just inline it
<fabbione> hppa/sparc/ia64 is compiled in
<fabbione> and ppc too
<fabbione> instead of adding another module...
<Kamion> however you'll need to provide the package description etc. yourself if it's not in kernel-wedge
<Treenaks> Kamion: I have some GPS-detecting python code (for yet another way to determine location/timezone/exact time).... but that'd make the installer depend on python-serial :P
<fabbione> s/module/udeb
<Kamion> ia64 and powerpc don't have it at all; CONFIG_RTC is not set
<fabbione> Kamion: they have CONFIG_GEN_RTC
<Kamion> hm, ok
<Kamion> so you mean you think it should just be compiled into all kernels?
<fabbione> i think so yes
<fabbione> that would save us another udeb
<Kamion> it's 21K
<Kamion> udebs are relatively cheap, but it's up to you :)
* Kamion <- happy either way
<fabbione> Kamion: ok.. let's make it a udeb
<fabbione> i would suggest to create a misc-modules
<fabbione> a bit more generic to fit all these "strange" categories
<Kamion> seems a bit misleading since it isn't drivers/misc/
<fabbione> hmmm ok
<fabbione> just tell me what to add to debian/d-i/
<fabbione> and i will do
<Kamion> rtc-modules is more useful to me that misc-modules, because with the latter I have to depend on something weird and generic rather than on something specific that describes exactly what I want
<Kamion> hm, is genrtc.ko useful on systems that have rtc.ko?
<Kamion> s/that misc-modules/than misc-modules/
<Kamion> config GEN_RTC
<Kamion>         tristate "Generic /dev/rtc emulation"
<Kamion>         depends on RTC!=y && !IA64 && !ARM
<fabbione> genrtc conflitcs with rtc
<fabbione> is either one or the other
<fabbione> according to the arch
<Kamion> I wonder why we have both as modules on amd64
<fabbione> imho because it is possible
<Kamion> heh
* Kamion tweaks kernel-wedge
* fabbione will wait the new kernel-wedge
<Kamion> fabbione: ok, build-dep on kernel-wedge (>= 1.25.1ubuntu3), 'echo common/rtc-modules > debian/d-i/i386/modules/i386/rtc-modules.lnk; echo common/rtc-modules > debian/d-i/amd64/modules/amd64/rtc-modules.lnk', and add ", rtc-modules" to the end of the two Provides_* lines in debian/d-i/sparc/package-list, please?
* fabbione does
<Kamion> hm, should probably do the Provides in ia64 and powerpc too, but only if you can be bothered :)
<fabbione> of course i can
<Kamion> ia64 is easy, for powerpc you'll need to add a Package: kernel-image block to the top
<Kamion> dependency correctness there isn't vital, it'll just suppress a few whines in /var/log/debian-installer/syslog
<fabbione> Provides_sparc64: ext2-modules rtc-modules
<fabbione> something like this...
<Kamion> Provides_sparc64: ext2-modules, rtc-modules
<fabbione> right
<Kamion> thanks dude, $beer{fabbione}++
<fabbione> eheh no problem man
<fabbione> Package: kernel-image
<fabbione> Provides: rtc-modules
<fabbione> this is for ppc
<Kamion> at some point I may ask for a mouse-modules udeb, but that's in the future since I haven't got gpm working smoothly with fb yet ...
<Kamion> fabbione: that's cool
<daniels> noooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
<fabbione> Kamion: well we are at it.. let's do it
<fabbione> all this stuff needs to go via NEW
<Kamion> fabbione: I'm not quite sure what needs to be added yet
<Kamion> and it's all bluesky yet ...
<fabbione> Kamion: ok
<Kamion> besides I have the feeling that daniels wants to kill me
<daniels> Kamion: whatever gave you that impression? :)
<fabbione> the latter is irrelevant imho :-)
<daniels> i just, er, dropped something very heavy on my toe
<daniels> (or heard that the second of my dogs will get put down after having one put down three months ago)
<daniels> s/one/the first/
<daniels> but, in all seriousness, gpm is probably a very bad idea
<fabbione> Kamion: we might have to update kernel-wedge later on for hppa support.. but don't bother now
<fabbione> it has probably one extra rtc-module
<Kamion> daniels: any other suggestions for mouse support on fb?
<Kamion> fabbione: hm, ok
<fabbione> Kamion: -4 has preliminary hppa support, but i need the new configs from lamony
<fabbione> lamont
<daniels> Kamion: why?
<fabbione> i really don't know what to answer to some of the stuff over there
<Kamion> daniels: sabdfl suggested the ability to point-and-click at buttons in the newt frontend
<Kamion> daniels: which newt does support
<daniels> Kamion: in d-i?
<Kamion> yeah
<Kamion> it's a graphical-installer stopgap :)
<Kamion> I like the idea if it can be pretty
<daniels> i honestly don't think we gain anything from the ability to click on buttons, but not the ability to do the proper layout we've been discussing
<Kamion> because the "tab to get to buttons, in more or less random order" thing does suck
<fabbione> Kamion: mind to give me the contents of rtc-modules?
<daniels> i suppose it's not so bad, as long as it never, ever, ever propagates to the installed system
<fabbione> otherwise i will need to wait up to 2 hours before i can testbuild
<Kamion> -drivers/char/genrtc.o
<Kamion> -drivers/char/rtc.o
<fabbione> danke
<Kamion> daniels: it won't; there's a worry of how to autodetect the mouse type though
<Kamion> of course we have to solve that for the graphical installer anyway
* fabbione updates ndiswrapper to 1.0rc2
<Kamion> I have a feeling that gpm's framebuffer support is, um, lacking; it just scribbles black squares over the screen when you move the mouse around
<daniels> Kamion: hm
<Kamion> at least on powerpc
<pitti> Kamion: this worked fine on kernel 2.6.9
<pitti> Kamion: it's broken for me on 2.6.10 too
<pitti> Kamion: so I don't think that this is a gpm problem
<Kamion> I'm running 2.6.9 here
<pitti> hmm, odd
<pitti> worked fine for me on 2.6.9
<Kamion> you don't get a pretty mouse pointer anyway though, you just get a block
<Kamion> so it may not be a usability win anyway
<pitti> but at least the block worked as it should and did not delete the contents of my screen...
<Kamion> powerpc too, or something else?
<pitti> yes, ppc I think
* pitti installs gpm on his i386
<fabbione> you are all dreaming
<fabbione> the kernel is NOT broken
<fabbione> it's your crappy hardware
<fabbione> Kamion: since you are at it
<pitti> Kamion: works fine on i386 on standard Ubuntu kernel (2.6.10) and VESA driver
<pitti> Kamion: maybe this is a problem with the radeon driver then?
<fabbione> i need you to test the emu10k1 build on ppc
* pitti does not have an emu10k1 soundcard
<fabbione> pitti: it's enough you can get it to build
<fabbione> i don't need you to test it.. because there is none at the moment
<pitti> fabbione: you can test building on davis
<pitti> it's very fast and nice to work on :-)
<fabbione> pitti: ok.. short version of the story
<fabbione> davis doesn't build it
<fabbione> i have no root access on the chroot
<fabbione> perhaps it builds with another gcc
<pitti> fabbione: you need root to build it?
<fabbione> or something that i have no way to test on davis
<pitti> fabbione: I can try it here if you want
<fabbione> i need root to install another gcc
<pitti> ah
<fabbione> like 3.4?
<fabbione> the error is pretty much a weird gcc message
<fabbione> that happens only on pcc
<pitti> fabbione: give me the package, I compile it with gcc-3.4 and send you the log
<pitti> fabbione: but uh, it's not a complete kernel image?
<pitti> fabbione: this lasts about 5 hours on my iBook :-)
<fabbione> pitti: just grab 2.6.0 from hoary, change the EMU10K in debian/config/powerpc to build as module
<fabbione> and build...
<fabbione> it's enough on one of them
<fabbione> i don't need you to build the world
<pitti> 2.6.10 that is? :-)
<pitti> okay, I'll do that
<fabbione> but i need you to figure out why it fails
<fabbione> yes 2.6.10
<pitti> does the linux Makefile respect CC=gcc-3.4?
<fabbione> pitti: yes afaik
<fabbione> otherwise it's one line change in the makefile
<crimsun> yes, set HOSTCC and CC
<fabbione> just search for gcc ;)
* pitti gives his iBook something to bite on :-)
* Kamion sees pitti paying more attention to IRC than him and therefore getting work ... ;)
<pitti> right, actually I should continue with my security updates...
<Kamion> pitti: could be, not entirely sure I can follow where selection.c goes
<pitti> ?
<pitti> Kamion: what about selection.c?
<doko> fabbione: hint ... unpack cpp-3.4 and gcc-3.4 into your home directory, add the <unpack dir>/usr/bin to your path, and compile.
<Kamion> it's what TIOCLINUX(TIOCL_SETSEL) calls, which is basically what gpm does to set the mouse pointer position
<fabbione> doko: no way i am going to do stuff like that .. KTHXBYW
<fabbione> ;)
<fabbione> doko: i don't like these kind of things when it goes to get stuff done properly
<fabbione> i prefer to have the things tested properly
<pitti> world: please stop finding holes in the kernel! We _just_ released an update yesterday and how I know about 5 to 10 new issues
* pitti cries a little
* fabbione cries together with pitti
<fabbione> pitti: is there anything i need to push in hoary today?
<doko> fabbione: ok, just an intermediate solutions until our admins wake up ...
<fabbione> doko: point is that we are not supposed to build with gcc3.4
<fabbione> so if this is something special it needs to be discussed
<fabbione> specially because we are going to build an entire kernel set on gcc3.4
<fabbione> that might introduce a bunch of regressions
<cartman> are there any plans to do a gcc 3.3->3.4 migration in the future?
<fabbione> since kernel tends to be affected by different gcc
<Treenaks> cartman: well, when it's released etc, probably
<cartman> Treenaks: released what?
<daniels> pitti: christ
<Treenaks> cartman: both gcc 3.4 and hoary probably
<cartman> Treenaks: ah I see but when hoary is release gcc 4.0 will be out possibly
<cartman> :)
<cartman> released*
<fabbione> daniels: the acx100 thingy will have to wait. the code is messy and fuckign stupid
<fabbione> daniels: i need to rewrite most of it
<pitti> fabbione: I sent you a mail with a disclosed patch
<pitti> fabbione: all other issues are not yet public
<fabbione> pitti: thanks
<pitti> fabbione: are the Debian patches basically fixes for Brad Spengler's issues?
<fabbione> pitti: yes afaict
<pitti> cool
<fabbione> but i have seen no info from other sources
<fabbione> only these few patches
<pitti> fabbione: I sort them to the advisories later today
<pitti> fabbione: but all of them are public, so having them in Hoary is good
<fabbione> pitti: ok...
<fabbione> ah yeah
<fabbione> i saw the thread this morning
<pitti> Mithrandir: any news regarding mailman?
<daniels> fabbione: not just sed -i foo -e "s/^ACX100ISSHITHOUSE^/$KVERS/;"?
<fabbione> daniels: no. that will break other stuff
<fabbione> pitti: gmm debian has only 3/4 patches
<fabbione> i need to check the rlimit stuff
<daniels> fabbione: ?
<fabbione> daniels: because somebody might actually have the firmware with the proper name
<fabbione> and we can't break it
<fabbione> plus there is a cascade of checks that needs to be done to load the correct one
<fabbione> and each one has it's own filename
<fabbione> so it doubles the check all over to find what is available
<fabbione> and which one is the correct one
<trukulo> ogra: u there? new version of graveman avalaible
<trukulo> hi fabbio :)
<fabbione> hey trukulo 
<trukulo> i'm here learning how to make _good_ debs
<Treenaks> trukulo: read Debian Policy :) it explains how :P
<azeem> and use dpatch
* azeem hides
* fabbione inflicts true pain to azeem 
* Treenaks hands fabbione the Vat of Boiling Acid
<trukulo> Treenaks: i know, i'm doing
<ogra> trukulo: lintian is your friend ;)
<fabbione> trukulo: stay away from dpatch.
<trukulo> ogra: and linda :)
<fabbione> that's all you need
<trukulo> fabbione: i'll show your way, my master
<trukulo> ups
<trukulo> s/follow/show
<fabbione> pitti: the missing patch is just a ddos
<fabbione> pitti: but there is no linus-blessing on it yet
<pitti> fabbione: Herbert created this patch and sent it upstream
<fabbione> pitti: http://seclists.org/lists/fulldisclosure/2005/Jan/0270.html
<pitti> fabbione: you can defer it if you want
<fabbione> pitti: just grab the rlimit.diff from the tgz included in that url
<fabbione> pitti: yes i saw that..
<fabbione> i am not sure if it is in bk tho
<fabbione> i can just apply and rename later...
<daniels> fabbione: yeah, fair enough; want me to make the patch for you?
<fabbione> daniels: that would be nice.. 
<fabbione> if you have time...
<fabbione> basically what needs to be rewritten is all the crap that tries to load the different firmwares
<fabbione> in such a way that will test for <firmwarename>-EXTRAVERSION before the firmwarename
<fabbione> remeber that we define EXTRAVERSION
<fabbione> and that's the same that is used to name the firmware
<daniels> fabbione: yeah, when I've finished up with the xorg config stuff
<fabbione> yeah
<seb128> elmo: here ?
<Mithrandir> nautilus should _so_ be able to resume transfers which have gotten stuck.
<seb128> Mithrandir: any news of the gaim upload ?
<Mithrandir> it passed NEW in Debian the same evening
<pitti> Hi Mithrandir 
<pitti> Mithrandir: any news about mailman?
<Mithrandir> pitti: hiya; yes, I've decided on how to go about with the 55_thingy; we can't just remove it, since it fixes a real problem.  I need to actually test it though.  
<Mithrandir> so, expect a patch today.
<pitti> cool
<pitti> Mithrandir: will you upload a new sid version?
<Mithrandir> yes
<pitti> Mithrandir: with the new password algorithm?
<pitti> nice
<trukulo> ogra: olivier? new graveman package dude
<Mithrandir> that's my intention, yes, but I don't see the need for that to go into a USN if you want one for warty.
<seb128> Mithrandir: I know for Debian, but about hoary ? :)
<pitti> Mithrandir: I won't fix the password generation for Warty right now
<seb128> Mithrandir: we don't sync from experimental automatically, and as you said you were going to handle the new version ...
<pitti> Mithrandir: by now I only want to fix the XSS and the 55_thingy
<Mithrandir> seb128: ah, it's experimental, I forgot. :/
<Mithrandir> pitti: yup, I agree.
<Mithrandir> seb128: I'll do it once I finish breakfast and get to uni, then. :)
<seb128> ok, thanks!
<pitti> Mithrandir: I agreed with mdz to leave the new password thingy in sid/hoary for a while before we update warty
<Mithrandir> do you want a hoary upload instead of just syncing from Debian?
<pitti> Mithrandir: we need a hoary upload since hoary diverted from Sid (python2.4)
<pitti> Mithrandir: so we need a merge
<Mithrandir> nope
<pitti> (according to the changelog)
<Mithrandir> mailman doesn't follow that (silly) part of Debian's policy.
<Mithrandir> at least, it shouldn't.  If it does, it's a bug.
<pitti> Mithrandir: you mean it depends on "python" instead of e. g. "python2.3"? So we don't need to divert?
<Mithrandir> pitti: correct.
<Mithrandir> pitti: it depends on python (>= 2.1), iirc
<pitti> Mithrandir: nice, then we should indeed just sync it
<fabbione> rsync warning: some files vanished before they could be transferred (code 24) at main.c(1146)
<fabbione> DOH!
<fabbione> that was trying to rsync the daily iso
<fabbione> ..
<Kamion> odd
<Kamion> I haven't been messing about at that level very recently
<fabbione> hmmmmm
<fabbione> i think my server is a bit... hmmm unreliable
<fabbione> it refused to delete files in ubuntu/spool due to an IO error
<fabbione> but the fs is clean
<fabbione> Package: rtc-modules-2.6.10-1-386-di
<fabbione> Kamion: do you like it? ;)
* fabbione fires up more Metallica... FULL THROTTLE
<fabbione> and a bit of After Burner
<Kamion> fabbione: sounds good to me
<fabbione> i am building on i386
<fabbione> i can't test the others because of the chroot not being updated
<fabbione> that should be good enough
<Kamion> "Need to get 0B/397MB of archives. After unpacking 1218MB will be used." <- updated warty CD
<mvo_> Kamion: uhh, that's a lot of updates
<trukulo> only bug fixes?
<Kamion> those aren't updates, that's the desktop installation step
<Kamion> I'm pleased about the fact that it doesn't have to get anything from the network
<Kamion> trukulo: warty+warty-security
<mvo_> ahhh
<trukulo> Kamion: ok
<fabbione> elmo: can you update kernel-wedge on concordia hoary chroot please?
<fabbione> to ubuntu3
<trukulo> fabbione: we're preparing videos of badopi talkings :)
<fabbione> trukulo: nice :-)
<trukulo> when we have it, we'll tell you
<fabbione> thanks
<trukulo> we have technical problems with a f***ng ba***rd
* sivang wonders where jdub put the Mataro video he took ;-)
<jdub> sivang: it was a stream, not recorded
<sivang> jdub: eh....
<sid77> hi
<sivang> hi ogra_ !
<ogra_> hi sivang :)
<Treenaks> hey you both :)
<pitti> Did anybody try a recent daily Hoary cd?
<pitti> I just do, and now my computer is painfully slow
<ogra_> mdz wrote about it on the ML
<pitti> it takes about 5 seconds to execute a trivial command
<pitti> and switching VTs lasts about 3
<ogra_> dma was off when he tested it
<fabbione> is that the live cd?
<ogra_> whoah
<pitti> ogra_: I checked, DMA was on. I disabled it for testing, but no change
<ogra_> hmm
<pitti> ogra_: no, that's a hoary install cd
<sivang> Treenaks: hi!
<sivang> pitti: hi :)
<pitti> Hi sivang 
<fabbione> pitti: is it .9 or .10 based?
<pitti> fabbione: .10
<pitti> fabbione: standard i386 kernel
<fabbione> yup
<fabbione> my machine seems a bit slower on I/O with 2.6.10
<pitti> this has got nothing to do with "a bit slower"
<ogra_> 3 sec for switching VTs ?
<pitti> I could not even install the desktop system, because it already took 5 minutes to linstall libdv4
<pitti> now I canceled this 
<pitti> brb
<crimsun> it takes my machine approximately 3 seconds to switch vts as well
<fabbione> pitti: are you sure you are not on your m68k in i386 emulation?
<fabbione> here is immediate
<ogra_> lol
<sivang> crimsun: this is a laptop?
<fabbione> are you all running frambuffer?
<crimsun> (hoary, 2.6.10-1-686-smp _and_ 2.6.10-hardened-1-686-smp)
<fabbione> is there any message in the log?
<fabbione> like dmesg
<crimsun> no fb, strictly "nv" X.Org driver and normal vga console
<fabbione> same here
<fabbione> except i use the nvidia drivers
<crimsun> I have a despairing hunch that this has something to do with my reenabling ACPI :/
<pitti> I rebooted my desktop, now it runs fast again
<pitti> however, this is a weeeird problem
<fabbione> pitti: hold on..
<fabbione> you said you were installing right?
<pitti> fabbione: I did
<pitti> I did not supervise it
<fabbione> so.. you installed = ok.. reboot = slow .. reboot = ok?
<pitti> but I have the strong feeling that some postinst script triggered this
<pitti> fabbione: right
<pitti> fabbione: well, even more:
<pitti> fabbione: install after reboot = ok
<fabbione> where reboot = slow was the second stage installed?
<fabbione> installer even
<pitti> fabbione: then I left for a while, returned, then it was slow
<pitti> fabbione: yes, reboot after 1st stage
<fabbione> HMMMMM
* fabbione smells of crap in the fb direction
<pitti> fabbione: I had to manually install the desktop system since CD packages could not be authenticated
<pitti> so I did apt-get install ubuntu-desktop
<fabbione> pitti if you modprobe the fb modules...
<fabbione> does it become slow again?
<pitti> are they modprobed in the middle of pacakge installation?
<fabbione> no.. during base-config
<pitti> no, it worked fine after b-c
<fabbione> or better.. at base-config init
<fabbione> ok
<fabbione> than i dunno...
<pitti> pacakge installation already started
<pitti> while it ran, I worked at another shell (some ssh)
<pitti> then I left, and when I returned, it was slow
<pitti> hmm, I have to try this again at some time
<pitti> fabbione: btw, I tried the kernel emu10k1 problem in the meantime, I /msg you
<fabbione> i didn't see the /msg
<fabbione> yeah
<fabbione> the same i saw on davis
<trukulo> fabbione: news for you
<trukulo> http://linuxbcn.homeip.net:6969/
<fabbione> did i win 200 Million dollars?
<trukulo> torrents of videos
<trukulo> more less
<fabbione> ah ok...
<fabbione> thanks :-)
<trukulo> you win a bride for february :)
<fabbione> is she rich or something? ;)
<fabbione> hell... people are already downloading it..
<fabbione> my reputation is totally trashed now
<fabbione> :)
<trukulo> sure :)
<trukulo> don't know
<trukulo> perhaps she is virgin
<trukulo> (think about it)
<fabbione> ehehe
<sivang> fabbione: I am also :)
<fabbione> sivang: virgin? or getting a bride?
<sivang> fabbione: oops, not a virgin, downloading that is :)
<trukulo> lol
<fabbione> ahhaha
<sivang> fabbione: hmmm bride? scary....;-)
<ogra_> hehe
* sivang prefers bribe
<trukulo> jeff video published too
<fabbione> trukulo: why the fabio_big seeds is down to 0?
<fabbione> it killed the download...
<trukulo> don't know
<trukulo> it's the same for me, wait a moment
<fabbione> sure..
<lamont> doko: I think I gave it back again, dunno
<trukulo> back again now
<lamont> Kamion: you have email re anna/ia64 - please correct my iso-steps as needed.
<fabbione> hey lamont 
<fabbione> lamont: -4 is up with hppa support
<fabbione> you will have to do the configurations and send them back to me for -5 inclusion
<pitti> amu: I release the KDE libs security update now if you don't have any objections
<fabbione> it will fail on the buildd so it is better that you just take it manually before wanna-build
<fabbione> trukulo: thanks :-)
<amu> pitti: ok 
<pitti> amu: thanks for preparing them
<amu> pitti: np
<trukulo> fabbione: wanna your ass
<fabbione> ehehe
<amu> pitti: it would be nice if i get a build.log of it .... 
<pitti> amu: you have to ask lamont for that, I don't have them
<Kamion> lamont: (yes, you have to fix the Release file)
<amu> lamont: ? 
<lamont> amu: build log of?
<amu> lamont: kdelib+base from warty 
* lamont goes looking
<lamont> amu@canonical.com?
<amu> yeah 
<lamont> both succeeded, you know...
* lamont emails
<trukulo> fabbione: can you put the notice about the videos on ubuntu web?
<amu> lamont: hehe, nethertheless, i'll check it ;) 
<fabbione> trukulo: just slam them in the wiki
<lamont> amu: kdelibs sent, kdebase is going to have to wait about an hour - must take kids to school
<amu> lamont: .... in hoary there was a problem :)  
<trukulo> fabbione: put it on planet
<fabbione> i don't have that access level to do so
<fabbione> otherwise i would
<amu> lamont: no prob .... i#ll ask you again till i get them 
<Mithrandir> fabbione: just blog about them?
<seb128> lamont: new metacity with your patch in the archive
<lamont> seb128: round 1 or round 2?
<elmo> seb128: you were looking for me?
<seb128> 2
* lamont runs
<elmo> fabbione: concordia's updating now
<fabbione> Mithrandir: i didn't add my blog anywhere yet...
<fabbione> elmo: thanks
<seb128> elmo: yep, did you do the glib2.0 and easytag sync ?
<seb128> elmo: they are in the archive
<elmo> doko: ?
<trukulo> fabbione: tell mako
<fabbione> Mithrandir: you can blog it too :-)
<seb128> lamont: BTW do you have a short description for it ? To add to the gconf schema 
<Mithrandir> fabbione: yeah, I know
<seb128> elmo: s/are/are not/
<elmo> seb128: gar, sorry.  done now 
<seb128> elmo: np, thanks
<pitti> mvo_: right now installation from daily hoary seems to be utterly broken
<pitti> mvo_: I suspect it fails to isntall ubuntu-desktop because it cannot authenticate the packages on CD-ROM
<Kamion> dailies are for debugging :-)
<pitti> mvo_: is this possible/known?
<mvo_> yes
<Kamion> um; base-config turns off authentication
<Kamion> for precisely this reason
<pitti> Kamion: that's why I'm doing :-)
<pitti> Kamion: (testing for debugging)
<mvo_> Kamion: will it help when you have the ubuntu-keyring udeb?
<Kamion> unless somebody changed the configuration variable name
<Kamion> mvo_: kinda waiting for gpgv-udeb first to make sure the name doesn't change
<mvo_> all right
<Kamion> mvo_: that won't make any difference to base-config, though; what I need for *that* is to have the keyring automatically registered with apt-key
<Kamion> mvo_: at the moment apt's postinst registers a key in the apt package rather than from ubuntu-keyring
<mvo_> Kamion: so what you need is apt-key update in postinst of ubuntu-keyring? 
<Kamion> mvo_: right
<Mithrandir> trukulo: your uplink seems a bit slow?
<trukulo> Mithrandir: it's slow
<trukulo> it doesn't seem, it is
<trukulo> it's a home connection in spain
<trukulo> it's what we can afford
<Mithrandir> if you want me to run the tracker here, I can do that; it'll save you some traffic at least.
<trukulo> of course
<trukulo> just tell me what do you need
<sivang> Mithrandir: wow that would be cool
<trukulo> (if you need something)
<Mithrandir> trukulo: I need some stuff, just wait a second while I set this up
<trukulo> ok
<Kamion> urgh. in python, how do I get a tuple containing all the elements of a given list?
<Kamion> so I have foo = [a, b, c]  and want (a, b, c)
<Kamion> oops, never mind, tuple() does what I need
<sivang> tuples are cool
<Mithrandir> trukulo: you need to make new metafiles using for f in *.avi; do ./btmakemetafile.py $f http://tracker.err.no:6969/announce; done and then put the torrents online somewhere (I can host them fine)
<trukulo> wait a sec
<trukulo> think ppl hosting torrents is eating now, shit
<trukulo> umm, perhaps i can do it...
<Mithrandir> I can't make the meta-files as I don't have the complete files. :)
<trukulo> ok, ok
<trukulo> wait a sec
<thom> sladen: ping?
<Mithrandir> trukulo: arghle, of course the wired network here _had_ to go down right now :/
<trukulo> :( of course
<trukulo> don't worry
<trukulo> we'll do in two or three hours, ok?
<Mithrandir> I guess it'll be back in a couple of minutes.
<fabbione> trukulo: i have stopped my downloads so you can get a bit of bw back
<trukulo> don't worry
<trukulo> have to go home now
<fabbione> i have done already
<trukulo> i'll continue
<fabbione> i will wait Mithrandir to set the stuff up
<trukulo> so you can resume :)
<trukulo> ok, hope this afernoon
<Mithrandir> trukulo: ok, no worries, if this isn't up in a couple of minutes, I'll use the box I'm running IRC off.
<trukulo> ok
<trukulo> but now, i have to go home to lunch :)
* lamont_r wonders if it was something he said... :-)
<mako> your presence is enough :)
<Treenaks> lamont_r: just on-join triggers ;)
<lamont_r> mako: feh!
<lamont_r> :-)
<Mithrandir> elmo: can you sync stuff from experimental, or would you then prefer that we upload an ubuntu version?
<elmo> Mithrandir: I can sync stuff from anywhere with a Sources
<Mithrandir> elmo: ok, please sync gaim from experimental, then.
<elmo> Mithrandir: err, wouldn't that need an exception fromthe UpstreamVersionFreeze?
<elmo> oh, no, we already have 1.1.1
<Mithrandir> elmo: yeah, I thought we had, so that should be fine.
<elmo> done
<Mithrandir> thanks a lot.
<pitti> elmo: can you please sync imlib+png2 and imlib2 from sid?
<elmo> pitti: done
<pitti> thanks
<lamont_r> no mdz yet, is there..
<lamont_r> amu: kdebase sent
<Mithrandir> doko?
<lamont_r> amu: sorry for the delay - that one had been archived.
<gsuveg> thom: echo request
<amu> lamont_r: thx again ... as i thought there's a problem with it :) 
<lamont_r> amu: I see.
<lamont_r> things with problems really should fail, you know...
<amu> lamont_r: hehe
* lamont_r considers beating on daniels with all the 67MB xorg packages, but decides that could hurt too much...
* Nafallo just read through the kernel announcement on changes-hoary *
<pitti> Kamion: do you know how to automatically map a language code (pt_BR or de_DE) to a language name (like "Brazilian Portugese" or "German")?
<seb128> hum
<lamont_r> pitti: /usr/share/misc/languages
<lamont_r> .gz
<seb128> Address   Kbytes     RSS    Anon  Locked Mode   Mapping
<lamont_r> (in miscfiles)
<seb128> b5c9f000    7592       -       -       - r----  kochi-gothic-subst.ttf
<seb128> what's that ?
<seb128> why a .ttf is listed in the memory table and eat that memory ?
<lamont_r> pitti: and /usr/share/misc/countries.gz for the _BR _DE, etc
<lamont_r> seb128: probably mmaped
<smurfix> seb128: because it's mmap'd ?
<smurfix> lamont: you win ;-)
<pitti> lamont_r: cool, thanks
<lamont_r> pitti: miscfiles is full of really cool stuff..
<seb128> hum
<lamont_r> and really useless stuff.
<seb128> I'll just remove it, I don't care about this stuff :p
<lamont_r> smurfix: less keystrokes..
<seb128> lamont_r: BTW have you read my request for a small description of your focus mode ? :)
<seb128> and thanks lamont_r and smurfix 
<fabbione> lamont_r: mind to kick back the 2.6.10-4 on ia64?
<lamont_r> seb128: yeah - although I'm still not 100% sure I'm happy with it....
<lamont_r> fabbione: ok
<fabbione> lamont_r: i doubt that's a package problem
<lamont_r> will do, that is.
<fabbione> make[1] : Entering directory `/build/buildd/linux-source-2.6.10-2.6.10/debian/build/linux-source-2.6.10'
<fabbione>   HOSTCC  scripts/basic/fixdep
<fabbione> Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
<fabbione> make[2] : *** [scripts/basic/fixdep]  Error 127
<thom> gsuveg: um, ack
<seb128> lamont_r: out of you nobody use it atm so feel free to send a new patch to change the behaviour if you want :)
<thom> focus_follows_lamont?
<lamont_r> seb128: it's 'strict pointer mode' that is, new windows never take focus, although they may be mapped on top.  (issue is, if the new window maps on top and lands on the mouse, it still doesn't get focus - not sure which way I'd rather that went, and can argue both sides of that... must ponder.)
<lamont_r> thom: upgrade metacity, and then use gconf-editor to change focus to 'strict'....
<seb128> the key to change is in the changelog
<lamont_r> seb128: the argument for why I want it (passwords, conversations, etc) kinda leads directly to the current behavior of the mode.  so I may just leave it that way...
<seb128> the new metacity focus prevention should avoid to lost focus while typing a password or so
<seb128> it works pretty fine here
<lamont_r> thom: it behaves exactly like 'mouse', except that newly mapped windows _NEVER_ take focus.  ever.
<lamont_r> seb128: right - that's only one corner case of the thing...
<lamont_r> the other is popping up new windows, and wanting to do several before going to the new ones.
<seb128> the focus in metacity now is: don't give the focus unless something ask for it
<lamont_r> it's really a 'don't make retrain the muscle memory' thing...
<seb128> it: you ask when you click on "save" icon in an app
<seb128> that's stupid to not give the focus to the file selection which ask for the filename
<lamont_r> or there's a shell prompt in an xterm/gnome-terminal
<lamont_r> seb128: like I said - muscle memory.
<lamont_r> the other side of the argument to calling it 'strict' would be that the focus would always be on the window where the mouse is sitting. current behavior violates that argument when the new window lands on the mouse...
<seb128> http://mail.gnome.org/archives/desktop-devel-list/2004-December/msg00306.html
<lamont_r> seb128: does that give you enough for the schema description, or do you want me to actually craft the entry?
<seb128> the details of the current metacity behaviour
<seb128> lamont_r: that's enough informations, but the "get the focus if pop under the mouse cursor" seems to be a bug for me :)
<lamont_r> nice. note that (a) I sometimes interact with windows using only my eyes, and (b) there is still a brief window between the prompt in a window and when I start typing that could result in keystrokes going to the wrong window.  admittedly, it's a short window, but...
<lamont_r> and sadly, neither of those can really be solved with the information available to the system./
<gsuveg> thom: now works the apps, but in live i cant test now
<seb128> yep
<seb128> but opening a fileselector for example is really fast
<seb128> you should be patient enough to wait for the dialog :)
<lamont_r> seb128: so you think that my mode should give focus to the new window that maps on top of the cursor?
<seb128> no
<lamont_r> good - because it doesn't right now.
<seb128> no if you don't move the mouse at least
<lamont_r> right now, mouse must enter the new window (which could mean 'leaving' it first...)
<seb128> no
<lamont_r> ??
<seb128> ie: I open gedit, type something in it, do alt-F2 with the cursor in the middle of the screen
<thom> gsuveg: ..
<seb128> the dialog takes the focus from gedit
<gsuveg> thom: ?
<lamont_r> seb128: with the current patch, mode==strict will never give the dialog focus until the mouse moves.
<seb128> lamont_r: I've just tried again here before saying so on IRC
<seb128> or the mouse move alone :)
<lamont_r> for me - I have to either move the mouse out of the dialog box and back in, or click to take focus.
<seb128> I don't touch the mouse
<thom> gsuveg: i have no idea whether you're asking something, telling me something, or what
<seb128> just open gedit in the middle of the screen, place the mouse cursor in the place where the alt-F2 dialog pop up
<seb128> enter some text
<seb128> alt-F2
<seb128> and now input doesn't go in gedit
<lamont_r> seb128: ah - it's not that the new window gets focus, it's that the old window loses focus.
<lamont_r> got it.
<lamont_r> that'd be a bug
<seb128> yep :)
<lamont_r> I'll investigate that today and send you a new patch
<seb128> thanks
<lamont_r> you want it relative to the current archive, I assume.
<lamont_r> (duh)
<seb128> if possible. Be careful, there is already a 000_raise-on-click.patch changing the code a bit
<lamont_r> dpatch?
<seb128> no, cdbs with diff files
<seb128> but your patch apply ok on the current version and doesn't conflict with 000_raise-on-click.patch
<seb128> hum, maybe there was 1 rej in fact due to some upstream changes
<Mithrandir> seb128: gaim with -dev is now synced.
<seb128> cool
<seb128> perhaps the new version will fix some of the bugs open too :p
* seb128 hates to use the sf bug tracker
<Mithrandir> at least, elmo has synced it, but it's not in the archive yet, it seems?
<elmo>       gaim |  1:1.1.1-2 |         hoary | source
<elmo> it's not built is all
<seb128> nop, not in the archive yet
<lamont_r> ok.  with cdbs (never used it), how do I get to the state where patch foo is not applied yet, but everything before it is?
<azeem> lamont_r: man patch :P
<Mithrandir> seb: blah, failed due to libebook-dev
<azeem> is there a better way? (I'm seriously interested)
<lamont_r> azeem: heh
<lamont_r> azeem: with dpatch, I just say 'dpatch-edit-patch <patchname>' and get to that state
<azeem> yeah
<lamont_r> well, actually, <patchname> is applied, etc.
<azeem> lamont_r: note that cdbs is patch-agnostic (you can use it with dpatch and quilt), it's just the simple-patchsys it also provides which sucks
<azeem> simple-patchsys is not really suited for editing patches around and stuff I think (but I haven't poked at the code)
<azeem> ask Jeff once he's around to fix cdbs :P
<Mithrandir> seb128: I'm handling it
<seb128> ok
<seb128> azeem,lamont_r: simple-patchsys just apply all the diff files from debian/patches
<seb128> that's nice when you get patch or diff from the CVS, you just have to drop them in debian/patches/
<azeem> it adds stamp-files though
<seb128> yes
<seb128> but that's not optimal when you want to edit a patch
<azeem> so could you do 'debian/rules debian/stamp-patch-foo'?
<azeem> where 'foo' is the patch prior to the one you want to edit?
<azeem> hmm, should try that out one time
<lamont_r> doko??!!?
<lamont_r> Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
<lamont_r> fabbione: it'll be a while on that give-back
<fabbione> lamont_r: it did it again?
<fabbione> or gcc screw up?
<lamont_r> it's systemic
<fabbione> ok
* lamont_r gives it back anyway, just to be certain
<fabbione> roger
<fabbione> perhaps it's only one chroot that is b0rk3d
<lamont_r> nope.  all 3, and all 3 are current wrt/archive
<fabbione> ah
<fabbione> ok
<lamont_r> but we just finally got the toolchain in... hence the doko-summoning
<fabbione> ehehhe
<fabbione> ok i am off.. more sandpapering
<Nafallo> I can see a new powernowd just entered, did bug #5256 get fixed within that one?
<azeem> Nafallo: check the changelog
<Nafallo> azeem: rsyncing and on my way to evening-course :-).
<Nafallo> but it seemed only Sempron was added, a shame when there's a patch for Mobile AMD64 on bugzilla :-P.
<thom> i thought we'd fixed 5256
<thom> ho-hum
<thom> uploads are cheap *shrug*
<Nafallo> thom: hehe, uploading again? :-)
* Nafallo is off for evening course in french *
<Nafallo> later all
<lamont_r> Kamion: amd64 images available to you.
<lamont_r> 541MB of cloop
<lamont_r> well, 542.
<lamont_r> mdz: hack fix worked, btw
<trukulo> hi
<trukulo> Mithrandir: i'm finishing torrents for yo
<trukulo> you
<Mithrandir> trukulo: just biking to my gf's now, but I'll be back online in 30 minutes or so.
<trukulo> ok
<Kamion> lamont_r: hooray
<trukulo> i'll finish them
<trukulo> i'll put it on http://mercurio.homeip.net/debian/
* Kamion is waiting for linux-source-2.6.10 2.6.10-4 first, to get the powerpc fix
<mdz> lamont_r: great
<lamont_r> mdz: in other news, the new toolchain now in ia64 seems to be b0rked.
<mdz> lamont_r: T Simonnet seems to have resurfaced
<thom> mdz: i assume the reason you pinged was umask?
<lamont_r> Kamion: does that mean you'll want me to rebuild rootfs's for all the architectures again later today?
<mdz> lamont_r: can you communicate to him what needs to be fixed and ask him to coordinate?
<mdz> thom: yeah, elmo fixed it for me
<lamont_r> mdz: yeah - was going to ping doko about why it's what it is, since he can probably answer off the top of his head/trivial fix/etc.
<lamont_r> mdz: already replied to T with how to debug the install cd
<mdz> lamont_r: sure...we need for someone to start acting as go-to person for ia64, though
<mdz> and T Simonnet said he would be that
<lamont_r> well, how to produce a modified one, actually
<lamont_r> right - specifically, not me. :-)
<lamont_r> I'll send him mail in a short while.
* lamont_r must go run an errand for a bit (and move his car, etc)
<Kamion> lamont_r: it's only the udebs that matter here; it was the dm-snapshot thing
<lamont_r> Kamion: ah, ok
<Kamion> since md-modules isn't in the initrd, it doesn't even need a daily-installer build
<thom> mdz: yeah, i guessed
<thom> sorry.
<lamont_r> Kamion: i386/ppc are the daily build images from 06:15 your time, amd64 was a manual run just before I told you about it
<Kamion> ok, thanks
<mdz> thom: could you file a bug against baz if there isn't one already, to have it prevent us from shooting ourselves in the foot this way?
<lamont_r> anything else before I run off for about an hour?
<lamont_r> mdz: so mono is in main now?
<Kamion> daniels: kickstart documents a (kickstart-specific) 'xconfig --noprobe' command, described as "do not probe the monitor". do you happen to know if I can translate that into some number of debconf answers that will have the same effect?
<mdz> lamont_r: the source package iis, yes
<mdz> I have to run to an appointment, back in a few hours
<thom> we still need to fix mcs' FTBFS :/
<lamont_r> mdz: ok.  that adjusts the priority for fixing it, if nothing else... ;_(
<lamont_r> thom: see the bug
<trukulo> Mithrandir: you have all the torrent files located on my website (http://mercurio.homeip.net/debian/)
<lamont_r> 5052? maybe
* lamont_r runs an errand - bbiah
<mdz> Kamion: are there updated CD images for me to download?
<mdz> if so, I'll start them before I leave
<mdz> hmm, don't seem to be
<mdz> Kamion: could you do a new set of live CDs based on lamont's latest images and Fabio's new kernel that he planned to upload today (haven't checked if it's up yet)
<mdz> really going now
<Kamion> mdz: I'm waiting for the new kernel images to arrive
<Kamion> the source is up but powerpc isn't there yet
<Kamion> daniels: xserver-xorg/autodetect_monitor appears to be what I want, but as far as I can tell the code that calls xresprobe doesn't honour it. Could you fix that?
<elmo> powerpc just went in
<elmo> next sync is 30 mins; can force earlier, if needed
<Kamion> elmo: thanks, that's great; universe->main for rtc-modules would be good too, but not needed for the live CD
<elmo> oh, actually, no, it should already be on archive.u.c
<Kamion> yeah, it is
<Mithrandir> trukulo: ok, if you now, with a client that already has the downloaded files, process the new .torrents, it'd be good
<Kamion> mdz: it's up; amd64, i386, powerpc all built
<trukulo> no one has downloaded the files yet
<trukulo> i've made them with the original videos
<trukulo> same as old torrents, in that machine
<trukulo> (not mine)
<trukulo> if you have instructions for it, send to my email
<trukulo> now i have to go, to buy more ram to my laptop (am, am)
<elmo> hmm, nice 2.6.10 is up to 3:25 to build on i386
<Mithrandir> trukulo: yes, but you need to seed the new torrents.
<trukulo> i know
<trukulo> but now, i can't
<Mithrandir> ok. :/
<Mithrandir> please do when you can, then?
<trukulo> perhaps tomorrow, don't know, now i've to go
<trukulo> of course
<trukulo> but i need full videos download isn't it?
<trukulo> so perhaps tomorrow on my work
<trukulo> today, with spanish connections, is impossible
<Mithrandir> you need the files you used when running btmakemeta (or what the command is called)
<Mithrandir> are they anywhere else on the web?
<trukulo> i made them in the original machine where actual torrents are hosted
<Mithrandir> ok
<trukulo> well, see you later
<Mithrandir> see you around
<thom> hrm, can i do a query in bugzilla and negate the product - "I want to find all  bugs assigned to me that aren't on mozilla-firefox"
<pitti> thom: got 'nuff of those ffox bugs? :-)
<thom> a few too many
<thom> :-)
<pitti> thom: advanced search, summary "does not match regexp" comes close...
<pitti> thom: or you select all components and manually deselect firefox et al
<pitti> ^but this is going to be a biiiig HTTP request, I think :-)
<thom> i was trying to avoid doing the latter ;-)
<thom> the boolean stuff doesn't seem to work
<elmo> if I want to test IMAP am I safe to use evolution?  it's not going to start mucking around with my local ~/mail/ is it?
<thom> elmo: it shouldn't do, but i'd've thought mutt -f imaps://foo/bar was a safer bet
<elmo> ok, I'll try that
<HostingGeek> just some game ideas for ubuntu
<HostingGeek> PPRacer
<HostingGeek> it cont. from where tuxracer left off 
<HostingGeek> And SupertuxKart
<HostingGeek> as its way better than tuxkart
<HostingGeek> PPRacer: http://projects.planetpenguin.de/racer/index.php
<HostingGeek> SuperTuxKart: http://supertuxkart.berlios.de/index.html
<cartman> PPRacer looks nice
<HostingGeek> cartman: yes
<HostingGeek> cartman: will it make hoary
<cartman> <-- not an official dev.
<thom> HostingGeek: no, we've already frozen our upstream selections, and it's unlikely we'll want to support games in the main distro
<HostingGeek> no it doesn't have to come on the default install 
<HostingGeek> but as long as its in the main rep
<HostingGeek> as non of them are in universe to begin with
<Mithrandir> mdz: do I have an implicit approval for new upstream version of mozilla-thunderbird?
<elmo> Mithrandir: if you have to ask, then clearly not ;-P
<Mithrandir> elmo: bah. ;P
<HostingGeek> elmo: thunderbird 1
<HostingGeek> OMG this is a brake through
<HostingGeek> please click the ads on the PPRacer site
<azeem> HostingGeek: are you taht ^_^ dude?
<azeem> that, even
<HostingGeek> i would like to see the team making enough money that he doesn't stop the project
<HostingGeek> and if anything puts more time into it
<HostingGeek> wait
<HostingGeek> not all at the same time
<HostingGeek> google will not pay them
<HostingGeek> i clicked now
<HostingGeek> we will do 1 per 30min
<HostingGeek> azeem: LOL why?
<azeem> just wondering. Are you?
<HostingGeek> maybe yes or yes
<cartman> hmm buildd is busy?
<cartman> swig update still didn't make it to a.u.o
<elmo> cartman: what version do you mean?
<cartman> elmo swig1.3 1.3.22-5ubuntu2
<elmo> it's in dep-wait on a package in universe
<cartman> ah ok
<elmo> doko: ?
<pitti> carlos: here?
<carlos> pitti: hi
<pitti> carlos: is it possible to get the current (date-based) timestamp from Rosetta?
<pitti> carlos: i. e. if I create a language pack with version 20050110, can I get this number from Rosetta?
<pitti> carlos: this avoids time zone and wrong clock troubles when building the package
<pitti> carlos: like http://rosetta.ubuntu.com/timestamp
<pitti> carlos: ^ this would return an ASCII text just containing the time stamp
<pitti> carlos: alternatively (or even better):
<pitti> carlos: can the timestamp be delivered as a txt file within the ZIP file?
<carlos> pitti: hmmm
<rjek> Hello.
<rjek> I think I have a bug to report with Hoary.
<pitti> Hello rjek 
<rjek> Good evening pitti.
<carlos> pitti: so we use; http://launchpad.ubuntu.com/rosetta/language-pack
<pitti> rjek: the bug is not yet filed in bugzilla.ubuntu.com?
<carlos> and you get a file like: timestamp.zip?
<carlos> pitti: will that work for you?
<rjek> pitti: Who knows?  I routinely avoid it because of its awfulness.  Anyway, I thought I'd discuss it here first incase somebody could justify the behavior.
<pitti> carlos: I meant something else
<rjek> Ubuntu/Gnome/Whatever locks the CD-ROM drive's tray when an audio CD is inserted.
<pitti> carlos: if I request http://rosetta/updates/20041231
<pitti> carlos: I get a ZIP with all translations changed since 20041231
<carlos> pitti: no
<carlos> hmmm
<carlos> yes
<carlos> :-
<rjek> Eject from the icon on the desktop for the audio disc doesn't work (it silently fails), and neither does "eject /cdrom" unless run with root privileges.
<carlos> :-P
<carlos> sorry
<pitti> carlos: and within this ZIP is the translation data and also a file "timestamp" which contaisn 20051001
<pitti> carlos: or, 20050110 even :-)
<pitti> carlos: so that I can update my recorded timestamp and use that the next time I request an update
* thom reboots to see if his dev.d hdparm script works
<rjek> thom
<rjek>     !
<carlos> pitti: ok, I see your point
<thom> hullo rjek
<carlos> yes, it's doable
* rjek wiggles thom by his toe.
<pitti> carlos: Of course Ican also take the time of the build host, but this might lead to errors
<pitti> carlos: with my proposal we have a central global reference
<carlos> pitti: I think I will use always 23:59 UTC from the day before the request
<pitti> rjek: this works fine for me here
<rjek> What aspect of the issue?
<pitti> rjek: I insert an audio CD, it automatically starts playing, then I type "eject" and it comes out again
<carlos> that way you will not get some translations from that day but will work always the same way and you don't need the time timestamp just the date
<rjek> pitti: I close the CD player application when it pops up.
<rjek> Pressing the hardware eject button then does nothing.
<rjek> Only way I can get the tray to open again is "sudo eject /cdrom"
<rjek> It's clearly locking the tray, I'm just interested in *why* it's locking the tray.
<pitti> carlos: it basically boils down to date +%Y%m%d > timestamp
<rjek> I can see it's advantagous to lock the tray when you've mounted a file system on it.
<pitti> rjek: audio CDs are not mounted
<rjek> I know this.
<rjek> Which is why I'm complaining about it locking the tray. :)
<carlos> pitti: right
<pitti> rjek: after I stop the CD player, the tray gets unlocked again for me
<rjek> "stop" ?
<rjek> Do you mean pressing the stop button on the cd player application, or quiting the CD player?
<rjek> Why is it getting locked in any case anyway?
<pitti> rjek: can you please write a detailled explanation in a bug report and include /proc/sys/dev/cdrom/info?
<pitti> rjek: that's a good question; proably the CD player should be adapted not to do this
<rjek> pitti: If that involves touching Bugzilla, then no :)  Ubuntu's Bugzilla appears to hate me.
<pitti> rjek: hmm, then please write it to ubuntu-devel@lists.ubuntu.com
<rjek> It doesn't actually appear to want to let me sign up for an account with it, for example.
<pitti> rjek: why bz hates you? it works fine for anybody else
<elmo> rjek: if you used your pepperfish mail, that's because of your fascist policies; it should work now, we have stuff like reverse DNS
<rjek> pitti: Perhaps for the same reason that this weekend I found 5 bugs in my new DVD player's firmware that are baffling the author of its firmware? :)
<elmo> if it's not worked for you recently, I'd like to try and find out why...
<rjek> elmo: I tried with and without.
<rjek> AFAIK, ppf's mail is quite happy to accept mail from places without rDNS.
<rjek> We don't run SAUCE. :)
<elmo> rjek: kinni was whining at me about not having reverse, he said he had to special case our mail server, but maybe I'm misremembering
<rjek> (Our home ADSL for some time didn't have rDNS.)
<rjek> elmo: Perhaps.
<rjek> I routinely deal with ppf customers who don't have rDNS, though.
<rjek> Anyway, I've got to go.  I'll try sending a mail to ubuntu-dev, and I'll try to go near Bugzilla again.
<rjek> ... later this evening.
<mjt> i'm seeing the same behaviour with my cdrom drive and kernel 2.6.10 - it locks the door (mplayer (it's dvd really), xmms, ..)
<mjt> 2.6.9 was ok with that - no door locking
<pitti> carlos: so the timestamp file in the zip is doable?
<carlos> pitti: yes
<pitti> carlos: nice
<carlos> pitti: could you open a bug at https://launchpad.ubuntu.com/malone to track all this things?
<pitti> carlos: this URL loads forever...
<sivang> carlos: what's with the rosetta mailing list? so quite...:) did you get my emails regarding the imported files versions?
<carlos> sivang: too much pending mails. I was fixing important bugs today, will try to answer all mails tomorrow (sorry)
<pitti> carlos: timeout
<carlos> pitti: ok
<sivang> carlos: ok, good to know :) thanks!
<sivang> carlos: I also got someone to tell you about the plurar froms in arabic :) , he told me it's bit complex, although the rules are quite clear - I hope rosetta could support it.
<carlos> sivang: if gettext support it, Rosetta will do it also
<sivang> carlos: ok, cool
<lamont_r> moof
<Treenaks> lamont_r: you.. you.. APPLE person!
<lamont_r> Treenaks: heh.  finally broke down and bought a G3 in november
<lamont_r> it's installed, and looking for power and a home in the house somewhere.
* Treenaks needs to teach gpg to NOT update the trustdb EVERY time a new key is imported...
<Treenaks> *fires up vim*
<lamont_r> mdz: is 2.6.8.1 supposed to drop from hoary/main?
<lamont_r> Treenaks: heh
<lamont_r> no-auto-check-trustdb
<Treenaks> thanks
<Treenaks> seems to work :)
* Treenaks needs to cross-sign a bit more..
<Kamion> lamont_r: I think we agreed 2.6.8.1, yes
<lamont_r> Kamion: fwiw, amd64 was built using cloop_...-1ubuntu1buildd1_amd64.deb
* Kamion will download powerpc/amd64 overnight when his housemates won't object
<lamont_r> i386 should pick that up tonight, and ppc/ia64 if/when I get around to compiling it for them.
* lamont_r is tanking bandwidth at the coffeeshop today
<lamont_r> (hence the grumble about 2.6.8.1
<lamont_r> (grabbing i386 live, merge stuff, and missing mirror-files)
<lamont_r> dunno what everyone else here is doing, but I'm getting about 100KB/s agregate
<lamont_r> here == coffeeshop, that is.
* lamont_r beats swig1.3 against the wall, goes to find who uploaded it;
<lamont_r> seb128: you probably care about evoultion-webcal_2.1.3-0ubuntu1
<seb128> lamont_r: yes, ftbfs ?
<lamont_r> yeag
<seb128> ok, thanks
<lamont_r> doko?  awake?
<lamont_r> mdz/jdub about?
<elmo> lamont: what's wrong?
<elmo> I moved pike7.6 into main
<lamont_r> ah, ok
<lamont_r> that was my grumblage-source
<thom> seb128: hey, nautilus sucks
<seb128> thom: ... 
<thom> seb128: this is what's happening: i have a webdav share. i cna mount it in cadaver, i can view it in firefox, gnomevfs-ls lists the dir
<thom> nautilus says: "Couldn't find "http://10.9.8.12/mp3/"."
<thom> gnomevfs-info http://10.9.8.12/mp3/|grep MIME
<thom> MIME type         : x-directory/webdav
<seb128> thom: how do you try to browser it ?
<thom> Ctrl+L
<seb128> thom: with the "connecteur server" stuff ?
<seb128> na
<thom> or connect to server
<seb128> or user webdav://...
<thom> both do the same
<seb128> s/user/use/
<seb128> hum
<Kamion> aargh, kickstart files can %include files generated by preinstallation scripts in the kickstart file, which are run in the initrd
<Kamion> that's painful
<seb128> thom; is there any way to have an account to play with it ?
<thom> seb128: wait one
<Mithrandir> lamont_r: can you track down where my gaim upload went?
<lamont_r> Mithrandir: ok
<Mithrandir> lamont_r: I uploaded it some hours ago and no trace of the build logs
<lamont_r> Mithrandir: anything to do with libebook-dev?
<Mithrandir> lamont_r: that was what I fixed in the upload, yes
<lamont_r> anytime you fix a missing build-dep by removing it, I have to kick the buildd's...
<lamont_r> so once you see the source in the archive, you can poke me...
<fabbione> hmmm
<Mithrandir> ah, ok.  I didn't remove it, I just changed it, though.
<Mithrandir> stuff get auto-depwaited?
<fabbione> lamont_r: it looks like that only ia64 is screwed
<lamont_r> kicked
<lamont_r> fabbione: yeah - all 3 ia64 machines, only.
<lamont_r> Mithrandir: stuff gets auto-depwaited, and clearing the depwait is manual
<Mithrandir> lamont_r: ok, noted.  Thanks.
<lamont_r> should save a little frustration the next time around.
<fabbione> lamont_r: ok :-)
<lamont_r> fabbione: that was what I meant earlier by 'all' - sorry about the miscommunication
<fabbione> lamont_r: yeah gotcha.. don't worry...
<fabbione> atleast it's not sparc ;)
<fabbione> like we would say between real friends
<fabbione> when shit happens
<fabbione> better to you than me!
<fabbione> :P
<lamont_r> "there you sit all spic-n-span.  where were you when it hit the fan?"
<fabbione> ehehe
<lamont_r> fabbione: meanwhile hppa (which has more personal mindshare than ia64...) is at 734/5/17/20 of 777 inst/fail/d-w/build (==failed)
<lamont_r> kernel threads seem to be a bit unhappy on hppa.
<fabbione> nice
<thom> lamont_r: are you looking at mcs? if not, i might play around tonight and see what i can find
<fabbione> lamont_r: try to build the kernel.. and give it a spin
<fabbione> it's up to this morning cvs
<Mithrandir> lamont_r: that's not bad at all.
<lamont_r> thom: not currently looking at it - the bug talks about known b0rkage that hasn't been uploaded yet - that'd be a starting point
<fabbione> anyway
<fabbione> i am off
* fabbione &
<thom> lamont_r: that's way out of date
<lamont_r> Mithrandir: once one understands that the building==failed list includes gcc-3.[34] , db4.3, kenrel, synaptic, etc, it looks a bit uglier...
<lamont_r> thom: glad I didn't head down that rat hole then.
<lamont_r> thom: if you would please look at it, I'd be happier
<thom> lamont_r: sure
<lamont_r> feel free to hijack the bug too
<thom> righto
* lamont_r dups out the 2nd mono bug against 5052
<thom> lamont_r: also, it doesn't appear to have built anywhere in debian, so i dunno wtf that's about
<doko> lamont_r: the ia64 archive doesn't seem to be get updated
<lamont_r> doko: with what?
<doko> gcc-3.4
* lamont_r looks
<doko> the second time it did build sucessfully
<thom> yeah, debian has the exact same error, so i think it's a case of the missing build deps
<lamont_r> doko: libgcc1_3.4.3-7ubuntu1 is installed
<lamont_r> doko: so I think the toolchain is completely current.  I'd love to be shown otherwise, because that makes the fix trivial.
<doko> oops, wrong chroot. you are right. preparing the final libunwind upload.
<lamont_r> doko: thanks.  pls tell me when to give everything back....
<lamont_r> or even when the upload happens and I'll babysit it.
<Mithrandir> doko: why did you upload a mailman to hoary with tightened build-deps?
<elmo> doko: dude, can you fix python-nevow? it's been promoted from universe and needs transitioned
<elmo> can file a bug if you want
<doko> Mithrandir: don't remember. maybe the python-defaults package was delayed? don't know anymore.
<doko> elmo: ok, please file a report. there are more packages...
<Mithrandir> doko: ok; it doesn't need any, that's just why
<elmo> doko: not in main, I hope?
<doko> elmo: syncs from Debian only. and I have to look at abiword.
<doko> elmo: please could you sync drdsl and graphviz from Debian?
<doko> lamont_r: can you compile _anything_ on ia64 with the new libgcc1?
<lamont_r> nope
<elmo> doko: both would need an exception from the UpstreamVersionFreeze - please mail mdz/jdub, cc me, to get their approval
<lamont_r> so do I just need to rollback libgcc1 on something to the prior rev to get libunwind to build?
<doko> elmo: same with pike7.6. the last Debian upload was in November. just saw it when fixing swig
<doko> lamont_r: I've put the libgcc1 from my testbuild on chinstrap. could you verify, if this works for you?
<lamont_r> doko: in place of what's currently in the chroot, in order to build libunwind?
<lamont_r> or just generally?
<doko> just see, if you can compile things with it.
<doko> (and the compiled binaries run ...)
<elmo> doko: I promoted pike7.6 under the 'obvious' rule.. FWIW
<robtaylor_> carlos: ping-a-ling?
<seb128> <LiMpKiN> Generating locales...
<seb128> <LiMpKiN>   fr.ISO-8859-1...cannot open locale definition file `fr': No such file or directory
<seb128> somebody has an idea on what could break the locales installation in this way on warty ?
<mjt> isn't it fr_FR.... ?
<seb128> yeah, it should
<seb128> I'm wondering how he can get fr here
<elmo> seb128: I suspect the user hand-edited /etc/locales.conf and got it wrong?
<elmo> err locales.gen
<doko> elmo: thanks
<seb128> locales.gen was wrong yes
<seb128> but removing it doesn't help according to him
<seb128> is the value stored in debconf or something ?
<mjt> removing what?  A file, or the line?
<mjt> all debconf answers (or almost, anyway) are stored in debconf db
<seb128> /etc/locales.gen
<seb128> the fr line in it
<seb128> locales is still broken (apt-get -f install)
<mjt> still the same message about missing `fr' ?
<seb128> yes
<lamont_r> doko: Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
<elmo> seb128: try dpkg-reconfigure locales first?
<elmo> it shouldn't fix it, but..
<seb128> already tried
<seb128> <LiMpKiN> /usr/sbin/dpkg-reconfigure: locales is broken or not fully installed
<seb128> the state is "iF"
<mjt> the script is at /var/lib/dpkg/info/locales.postinst
<seb128> I know that :)
<mjt> dunno what's wrong, but as the last resort it's possible to add "|| :" at the end of locale-gen line
<mjt> the script -- seems to be -- tries to restore values in locale.gen
<seb128> I think so :/
<mjt> (in which case i think it is wrong, btw)
<mjt> hmm crap.
<mjt>                 sed -e "s,#$locale *\$,$locale," $LG > $LG.tmp || true
<mjt>                 mv -f $LG.tmp $LG
<mjt> that '|| true' part is WRONG, imho.
<lamont_r> mjt: actually, I bet it wants to be: sed ... && mv .. || true
<lamont_r> or just tell perl to do it in place.
<mjt> (or sed for that matter ;)
<lamont_r> istr sed will exit 1 if it didn't do anything...
<lamont_r> sed does things in place now?
<mjt> yeah
<Mithrandir> lamont_r: with -i, it does.
<lamont_r> kewl
<Mithrandir> it's a _really nice_ feature.
* lamont_r has some postinsts he can update now.
<elmo> yeah but this is glibc
<elmo> you don't want  to update _it's_ postinst in a hurry :P
<lamont_r> elmo: I meant _my_ postinsts... :-)
<mjt> sed exits with 0 even if it didn't do anything.  at least here
<lamont_r> and yeah, it's a function of when was -i introduced, and was that effectively the dawn of time (and then you can change it..)
<lamont_r> mjt: my bad
<mjt> i think that "|| true" thing comes from days when grep was used at this place
<mjt> still, what's a "common consensus" about debconf variables and actual configuration files?  Which takes precedence?
<Mithrandir> mjt: config files.
<Mithrandir> mjt: config files seed debconf which is then used for building the config files
<Mithrandir> at least, that's the way I do it.
<mjt> well ok... that's how i do it too ;)
<lamont_r> ditto
<Mithrandir> anything else is very much broken
<lamont_r> with the added caveat that changing the configfile outside of things, and then running debconf and changing something else, needs to not overwrite the hand edits...
<lamont_r> that bit gets a little more ugly
* lamont_r has 75% of a hoary-live-i386.iso...
<mjt> i asked to confirm.. a few months ago i filed a grave bugreport about mdadm as after i changed config in /etc and upgraded mdadm, my machine becomes unbootable
<Mithrandir> you need to parse the config file somehow.
* amu tested ppc-live ....   
<lamont_r> Mithrandir: actually, I just added a changed flag to debconf :-)
<lamont_r> then again, sometimes early adoption can be painful...
<amu> lamont_r: ppc is still not working  
<lamont_r> amu: grumble.  not-working how?
<amu> caspar runs amok ...  
<amu> ... on a pb4 
<doko> lamont_r: ld.so doesn't seem happy with libunwind changing between /lib and /usr/lib. I put the new libunwind on chinstrap. at least this makes things working again
<amu> lamont_r: i'll continue now with i386 ... 
<lamont_r> doko: will there be a new upload of libunwind that makes thigns happy?
<doko> yes, if that works for you. this is my test build of the new upload.
<lamont_r> doko: ah, ok. so test your .debs by building the source, eh?
<lamont_r> doko: much happier.  if you upload, I'll help the binaries through, and we can make ia64 happy again
<doko> lamont_r: ehh, they do build ...
<doko> ok
<doko> elmo: any chance to setup a chroot on davis for powerpc64 work?
<doko> lamont_r: signed binaries on chinstrap:libunwind/
<lamont_r> doko: yeah, I know
<lamont_r> but policy says that the binaries have to be built in our buildd-chroots
<lamont_r> but if you upload the source, then I can help the binaries along, since I have to diddle the chroot a bit to get it to work...
<amu> lamont_r: i386 has the same problem 
<doko> lamont_r: the source is included
<lamont_r> amu: great.  consistancy is wonderful.
<amu> lamont_r: i'll tryy to find it 
<lamont_r> doko:  do you want me to do the dput of the source, or are you going to?
<doko> lamont_r: will do.
<lamont_r> please tell me when you get the accepted message
<amu> lamont_r: got it, problem in cloop
<doko> lamont_r: done
<amu> cloop: disagrees about version of symbol struct_module
<lamont_r> amu: that sounds pretty fatal
<amu> lamont_r: should i try also amd64? 
<amu> guess it's the same 
<lamont_r> amu: I expect that you're right
<lamont_r> it better not require that the system where we compress the filesystem match the kernel on the CD...
<lamont_r> because that would be wrong in oh so many ways.
<du2br> how should I contribute potfiles revision to ubuntu patched packages (eg. gnome-panel)? patch to bugzilla?
<lamont_r> 95% of an iso that's borked.  sheesh
<lamont_r> amu: I guess I can kill my download, eh?
<amu> nope, try to rsync next time ;) 
<lamont_r> hrm.... I wonder if we could run something over the fsimage that changed the timestamps on everything to something specific...  and if that would be a good idea or not...
<lamont_r> I expect it would help with rsync-ability
<lamont_r> how bad are the incremental rsync's?
<mdz> lamont: here
<mdz> lamont: yes, 2.6.8.1 is supposed to disappear entirely
<amu> got the i386 in about 15sec. 
<lamont_r> mdz: did I give you any context?
<Mithrandir> mdz: mozilla-thunderbird 1.0 is already ok-ed, right?
<lamont_r> amu: way cool
<mdz> Mithrandir: the exception cases are listed in the wiki; does it meet one of them?
<mdz> Kamion: thanks
<doko> lamont_r: libunwind accepted
<lamont_r> doko: thanks
<doko> mdz: regarding the size of the l-r-m packages, should we build separate packages? these modules seem to be of interest for a relative local audience.
<Mithrandir> mdz: it was discussed on the Hoary status meeting about a week ago, but no, it doesn't really fit apart from that. :/
<mdz> doko: cf. the discussion on ubuntu-devel about why we have only one l-r-m
<mdz> doko: it's better to only need to rebuild one package when updating the kernel
<mdz> amu: which image has this cloop problem?
<doko> mdz: sure, but that's not an argument to put them in a separate _binary_ package.
<Mithrandir> mdz: you did actually say it needed a new upstream version. :P
<amu> mdz: 20040110
<amu> mdz: tested intel&ppc, i've also a amd64 here, guess it's the same, if you want me to test it also letme know, therefore i've reboot mail mail/webserver
<lamont_r> ETIME
* lamont_r must go get kids... will finish making ia64 build again after that.
* Kamion gets back from a particularly painful training session. zonk.
* lamont_r feels for Kamion 
<Kamion> lamont_r: sed -i was introduced relatively recently, in sed 3.95
<Kamion> lamont_r: woody doesn't have it ...
<lamont_r> back on somewhere around 16:45 -0700
<Kamion> and it took a while before it worked properly, e.g. didn't chmod /dev/null when run as root with </dev/null :P
<lamont_r> lol
<lamont_r> anyway,
<mdz> amu: all there are broken?
<mdz> amu: all 3?
<mdz> amu: did you talk to fabbione about it?
<amu> mdz: yeah it looks like, i'm burning now amd64   
<mdz> amu: what is the exact error?
<amu> mdz: not now, looks like fabbione is away
<amu> cloop: disagrees about version of symbol struct_module
<smurfix> amu: kernel updated and not rebooted?
<amu> smurfix: .. the dc live edition
<Mithrandir> mvo_: mdz and I got an excellent, and/or crackful idea last night.
<Mithrandir> mvo_: do you have a little time?
<mdz> oh, yes, I meant to send a mail to mvo about that but haven' tyet
<mvo_> Mithrandir: I'm pretty tired, but tell me
<mvo_> I'm always curious for crazy stuff :)
<Mithrandir> mvo_: have you looked at the UTFEightMigrationTool thingy?
<Mithrandir> that's something which should really be run by all users after the system is hoarified.
<mvo_> yes 
<Mithrandir> and U8MT might not be the only tool which would want that, so if packages could ask, through upgrade-notifier or something to have a command run when the user asks for it, that'd be nice.
<mvo_> Mithrandir: so what we need is some kind of "post-dist-upgrade-hook"?
<Mithrandir> mvo_: post-dist-upgrade-per-user-hook, yes.
<Mithrandir> and it should not just be some wizard which pops up when the user first logs in, it should probably be a notification icon of some sort.
<mvo_> Mithrandir: sounds like a very interessting idea. let me sleep over it to think how it could be representated in the GUI
<Mithrandir> mvo_: ok, sleep tight.
<Mithrandir> mvo_: please prod me tomorrow or so.
<mvo_> Mithrandir: will do, thanks :)
* mvo_ goes to bed now
<mdz> doko: if we make it a separate binary package, we would need to have an existing package depend on it anyway
<mdz> doko: the idea is to have the drivers present that the user may need in order to get connected to the Internet
<mdz> doko: as for the details of the packaging, I'll defer to fabbione; whatever the two of you agree on should be fine
<doko> mdz: just, didn't want to penalize other users by the size of the package.
<elmo> doko: sure
<doko> elmo: powerpc64? thanks
<amu> mdz: amd64 same problem  
<mdz> amu: the module is just broken in the kernel package; it has nothing to do with the live CD
<trukulo> hi ppl
<trukulo> Mithrandir: u there?
<Mithrandir> trukulo: yes
<trukulo> Mithrandir: now, we need entire files to put torrents online, isn't it?
#ubuntu-devel 2005-01-22
<Mithrandir> you just need to point torrent clients, which have the full files, to my tracker.
<trukulo> i did
<trukulo> i did with the script you gave me
<trukulo> well done :)
<Mithrandir> are you sure you used the correct set of torrents?  I can't see anything coming from you in the logs.
<trukulo> umm, i think i did
<trukulo> i run:
<sivang> Mithrandir: do you know hot to allow bittorrent under iptables?
<trukulo> for f in *.avi; do btmakemetafile $f http://yours ; done
<Mithrandir> trukulo: the torrents are fine, but are you sure that your client is using those .torrent files?
<trukulo> that's the problem
<trukulo> there aren't on a client
<trukulo> because it's not my machine
<sivang> Mithrandir: I need to configure my sarge firewall to allow this, when you have time , I'd appriciate if you pinged me :)
<trukulo> tell me how to do remotely and i'll do
<Mithrandir> sivang: http://btfaq.com/serve/cache/25.html
<sivang> Mithrandir: THANKS
<sivang> Mithrandir: oops the caps
<sivang> Mithrandir: un intentional
<Mithrandir> trukulo: hmm, and you can't access them with NFS or something either?
<trukulo> no, sorry
<Mithrandir> trukulo: what did you use to seed the old tracker with, then?
<trukulo> azureus
<trukulo> but not me
<trukulo> one of badopi members
<Mithrandir> ah, ok.
<Mithrandir> can you put the files somewhere I can just download them and use them to seed, then?
<trukulo> umm, it's difficult
<trukulo> because the only site is where torrents are downloading
<jdub> oh, are there videos of the badopi talks?
<trukulo> i haven't seen those files yet :(
<trukulo> yes jdub
<Mithrandir> trukulo: ok, but I either need access to the files (so I can seed), or somebody else with access to the files need to seed. :)
<trukulo> i know, i know
<trukulo> that's the problem
<trukulo> i'm trying to find a solution
<Mithrandir> ok, I wasn't sure if you understood the problem or not, which was why I was spoon-feeding you.  (:
<trukulo> sure, it's always better if you explain it
<mdz> amu: filed https://bugzilla.ubuntu.com/show_bug.cgi?id=5410
<trukulo> but we have a phisical problem :)
<Mithrandir> yeah, I understand that.
<trukulo> i'll see what can i do
<trukulo> i hope tomorrow i've downloaded this on my company
<Mithrandir> are the files online anywhere?
<trukulo> nop
<lamont_r> moof
<trukulo> well... on torrent, i think
<trukulo> http://linuxbcn.homeip.net:6969/
<amu> mdz: ok
<trukulo> but not very well, i think
<Mithrandir> ok, those seemed dead when I looked at them a little time ago
<trukulo> could be
<trukulo> wait a moment
<trukulo> no, until tomorrow i can't do anything more
<Mithrandir> ok, we'll take a look then
<trukulo> wait a sec
<trukulo> can you give me an ftp account to upload the files?
<trukulo> or sftp
<trukulo> i think i can do it now
<Mithrandir> ok
<trukulo> i'll upload *.avi and *.torrent
<trukulo> ok?
<Mithrandir> sounds good
<lupus_> on boot I get pciehp.ko missing error
<lupus_> is this a known issue?
<Mithrandir> it complains about the hardware missing?
<Mithrandir> or the kernel driver missing?
<mdz> lupus_, Mithrandir: https://bugzilla.ubuntu.com/show_bug.cgi?id=1869
<mdz> lupus_: please ask support questions on #ubuntu
* lamont_r does a whole bunch of ia64 give-backs
<Mithrandir> mdz: it should be easy enough for fabio to fix?
<mdz> Mithrandir: fix how?
<Mithrandir> make the modules not complain about being unable to load?
<mjt> is bugzilla.ubuntu really that slow?  That bugreport took about 5 minutes to load here...
<Kamion> it has to download the enormous component list for the drop-down box
<Mithrandir> mjt: looks fast from here.
<Kamion> remember that Mithrandir has godlike bandwidth
<Mithrandir> bah, only 100Mbit here.
<mdz> Mithrandir: I think the only way to do that would be to make them succeed in loading
<mdz> really, they should never be loaded in the first place
<mjt> strange. and i don't see large dropboxes there
<mdz> (on hardware that doesn't support PCI hotplug)
<Mithrandir> mdz: any idea why they are, then?  Buggy pci map?
<mdz> Mithrandir: possibly; not sure
<Mithrandir> Kamion: that page (https://bugzilla.ubuntu.com/show_bug.cgi?id=1869) is 54k.  it shouldn't take much bandwidth to load it :P
<opi> hi there
<Kamion> mjt: look closely at the Package: field; if you try to delete a bit and type stuff into it, you'll see a javascript drop-down appear
<mjt> gah
<Mithrandir> Kamion: that should be cached, though
<Mithrandir> the component cache is 163k.
<mjt> looks like i have to get some [A] DSL/WaveLan @home, finally... ;)  (I'm on 28kbps dialup now)
<Mithrandir> mjt: ah, that explains it. :)
<sivang> Mithrandir: have you got the tracker running already?
<Mithrandir> sivang: yes, but I don't have a full seed, so it's not too useful yet.
<sivang> Mithrandir: trulux's site is not responding for me...it says I can't connect to the tracker
<Mithrandir> sivang: I'm getting the videos uploaded now so I can seed them tomorrow.  I can give you the .torrents just fine, but they won't be particularly useful for a couple of hours.
<sivang> Mithrandir: I'll let them downlaod - that way I won't have to be here when you finish the uploads
<Mithrandir> sivang: http://tracker.err.no/
<Mithrandir> gromit looks shiny -- http://www.home.unix-ag.org/simon/gromit/
<mdz> Kamion: still here?
<Kamion> mdz: yes
<Kamion> http://people.debian.org/~markos/console_x_map.txt
<mdz> Kamion: I'm doing a kernel build to try to fix this module breakage
<mdz> Kamion: if it works, I'll want a new set of live CD builds
<mdz> Kamion: going to be up for a bit?
<Kamion> mdz: was planning to crash soon, karate training was tough and I'm not really so awake right now
<Kamion> how long are we talking about?
<Kamion> I could just cron it now ...
<mdz> time to finish this build + quick test + upload + autobuilds
<mdz> it's on sound/pci at the moment
<mdz> so fairly close to being finished
<mdz> no idea how long the autobuilds will take
<mdz> depends on whether they hit the same buildd and get ccache love
<Kamion> what kind of time of day would be good for live CD autobuilds?
<mdz> Kamion: hmm, didn't we set things up so that I could trigger CD builds?
<mdz> Kamion: can that apply to the live CD process as well?
<Kamion> yes, you should be able to; run "ARCHES='amd64 i386 powerpc' cron.daily-live" with umask 002 in effect
<mdz> Kamion: best time of day for me would be about 0800 UTC
<mdz> that would give me the freshest crack for overnight download :-)
<mdz> but it doesn't much matter, really
<mdz> Kamion: I'll just kick off a build when I'm ready (if this works), then
<mdz> no need for cron
<mdz> well
<lifeless> so, this warning is crap:
<Kamion> let's do it anyway
<lifeless> Preparing to replace linux-image-686 2.6.9-4 (using .../linux-image-686_2.6.10-1_i386.deb) ...
<mdz> I do still want daily builds
<lifeless> Unpacking replacement linux-image-686 ...
<mdz> I think we're ready
<lifeless> ...
<lifeless> (Reading database ... 164343 files and directories currently installed.)
<lifeless>    I repeat, this is very dangerous. If at all in doubt, answer
<lifeless>     no. If you know exactly what you are doing, and are prepared to
<lifeless> Removing linux-image-2.6.9-1-686 ...
<lifeless>     hose your system, then answer Yes.
<lifeless> Remove the running kernel image (not recommended) [No] ?
<Kamion> what's removing linux-image-2.6.9-1-686?
<mdz> lifeless: aptitude?
<Kamion> is that aptitude's autoremove?
<Kamion> if so, the warning is correct
<lifeless> mdz: aptitude autoremoving the kernel.
<Kamion> and aptitude needs a special case or something to stop it trying to remove the running kernel
<lifeless> Kamion: yes, its *correct*, like tla is *corect* when it asserts.
<mdz> yeah, that's a known problem with aptitude+kernel metapackages
<lifeless> whichi is why I thought you'd like to know :)
<mdz> not entirely sure what the correct solution is yet
<lifeless> ok, already known, cool.
<mdz> file a bug and assign to mvo
<mdz> component: UNKNOWN
<lifeless> done
<Kamion> mdz: cronned for 0801 UTC (I have a built-in aversion to cronning things to run exactly on the hour); you can run it by hand too if you like, though let me know if anything ends up group-unwritable
<mdz> Kamion: great, thanks
<mdz> lamont: please arrange your live-fs builds to be complete by the time Kamion's daily build runs ^^^
<Kamion> lifeless: ok, didn't know whether you meant crap => wrong or crap => unhelpful
<Kamion> also somebody tell me when ia64 works so I can remove the hacky special case :-)
<mdz> Kamion: what's broken?  filesystem.cloop builds?
<mdz> eek
<mdz> seb128: gaim upgrade just failed
<seb128> Mithrandir did the gaim update
<mdz> oh
<Kamion> mdz: nothing interesting in http://weddell.ubuntu.com/~buildd/livecd/, so yeah
<mdz> Mithrandir: bug coming your way
<Kamion> mdz: hm, you can't really do CD builds at the moment actually
<mdz> oh?
<Kamion> mdz: the gnupg secret keyring for dists/hoary/Release.gpg on the CD had to be group-unwritable
<mdz> gah
<mdz> anna doesn't even check that, does it?
<Kamion> this would all be so much easier if we had userv
<mdz> can i get a little || true action?
<Kamion> not yet, but I want to make it check that
<Kamion> I'm kind of averse to having different results based on who kicks off the build
<Kamion> there must be better ways to fix it ...
<jdub> mdz: far away from the landslide?
<jdub> mdz: it's been rainy there?
<mdz> Kamion: DISABLE_RELEASE_GPG=yes ?
<mdz> jdub: things are falling apart here
<mdz> my living room is a swamp
<Kamion> actually, does gpg care about group-readability?
<opi> mdz: you don't have a roof?
<jdub> mdz: ugh, badness :|
<mdz> and I had to dodge rock slides, mud slides, flooded roads, non-functional traffic signals and wrecked cars on my drive this morning
<opi> mdz: sounds bad
<mdz> opi: I do have a roof, but I also have a leaking patio door
<daniels> Kamion: will do
<sivang> mdz: on the weather report you sent me it it said that a flood warning is still on...
<mdz> LA county is one massive flood zone
<opi> I guess, even if our politicans sucks and we have high level of unemployment, there is still a plus in living in Central Europe
<sivang> mdz: but it's probably nice in your city when it's summer and no floods, it is home for some studios right?
<mdz> opi: let's just say that this kind of weather is "unusual" for this area
<mdz> http://weather.yahoo.com/climo/USCA1107_c.html
<Kamion> hey, it works fine when group-writable; gnupg is much less whiny than ssh about this sort of thing, yay gnupg
<opi> mdz: that makes most of people unprepared, right?
<mdz> normally 9cm of rain for the entire month of January
<Kamion> mdz: fixed
<mdz> we've had more than that in the past few days I think
<mdz> Kamion: s/writable/readable/ ?
<Kamion> mdz: either/both :)
<elmo> Kamion: it doesn't whine about secring?
<Kamion> I did chmod g+rw * in cdimage/secret/dot-gnupg/
<Kamion> elmo: nope
<elmo> huh
<mdz> I know it bitches about ~/.gnupg
<Kamion> elmo: not with --no-options --batch --no-tty --armour anyway
<jdub> when i first saw the shot of the landslide, i thought the foliage was weird for south-east asia :|
<mdz> jdub: yeah, not much for us to whine about given what just happened over there
<Kamion> are you at risk of being flooded out of the house or anything?
<elmo> mdz: hasn't stopped some of the newspapers in the UK
<elmo> OH MY GOD, THOUSANDS OF PEOPLE ARE WITHOUT ELECTRICTY.. uh, yeah, wow, sucks to be us.  everyone else has it so easy.
<mdz> Kamion: nah, it's only one room
<sivang> opi: where are you in europe?
<mdz> I just wring out the towels every hour or so
<mdz> it's supposed to rain one more day, and then we get a respite
<sivang> mdz: no draining holes , emergency pumps?
<jdub> socal... scorchio!
<mdz> sivang: they don't build such things in southern california
<mdz> because it doesn't rain :-P
<opi> sivang: Poland
<opi> sivang: we have a lovely spring this winter
<mdz> all hell breaks loose if it rains heavily for any period of time, which isn't very often
<Kamion> elmo: although the substantial increases in flooding here aren't a very good sign for the world in general, extrapolating
<mdz> pretty much everyone has some water problems at this point; it's saturated
<sivang> mdz: ah right. I recall california as a very warm , dry and beach rich place from movies/tv/other media.
<sivang> mdz: you live by the sea shore?
* Kamion wonders if the portrayals of California are any more accurate than the portrayals of England
<Kamion> everyone here either has a butler and a drawing room or lives in a hovel in London's East End, apparently
<mdz> sivang: that's accurate for southern california; northern california is quite different
<mdz> sivang: I live ~10 miles from the ocean, I guess
<mdz> Kamion: you mean it isn't true??//
<Kamion> mdz: I'll call the butler and ask him; maybe he knows
<jdub> i thought everyone in london had multiple massive plasma tvs
<mdz> Kamion: did I mention that I surf and audition for feature films?
<sivang> mdz: I live about ~Km from the medi, I should also look out from floods if they become global...;)
<Nafallo> yay! I should move to London at some time :-P.
<sivang> mdz: hehehe
<Kamion> mdz: your postcode's 90210, right?
<sivang> Kamion: so not to judge enligsh people by the "Eastendres" ? :)
<mdz> sivang: no, you must incorporate "The Young Ones" as well
<jdub> sivang: 'the bill' and 'the young ones' are closer
<jdub> aww
<jdub> man
* Kamion drives around arresting THE WORLD
<seb128> grumpf
<sivang> mdz,jdub : ah shame, on BBC prime I only get ee, "two packs of lager and a bag of crisps", "Doctors" etc..
<seb128> Version 0.9.5:
<seb128> - Removed sudo backend; there's just no way to support it without
<seb128>   crippling the feature set, or modifying sudo.
<mdz> err
<mdz> seb128: gksu?
<seb128> libgnomesu has dropped its sudo support
<mdz> that is, er, bad
<seb128> mdz: no, libgnomesu ... proposed for GNOME 2.10
<seb128> and used in the new gnome-system-monitor
<elmo> GO GNOME
<jdub> no, that's not so bad
<seb128> jdub: do something !
<mdz> seb128: either crippling the feature set or modifying sudo is better for us :-)
<Kamion> it's your birthday
<mdz> jdub: that is so bad
<jdub> all our changes use gksudo
<jdub> not libgnomesu
<jdub> libgnomesu should die
<elmo> I'm sure people have scripted that
<seb128> jdub: ah ah
<sivang> jdub: hehe
<seb128> jdub: but that's proposed upstream
<jdub> and hopefully it will (discussion on d-d-l)
<mdz> doesn't g-s-t use libgnomesu?
<seb128> jdub: that's an extra argument to get it kicked, no sudo support
<jdub> mdz: no
<mdz> ah, ok then
<jdub> mdz: we make it use gksudo
<jdub> seb128: we should comment on the thread
<seb128> gnome-system-monitor uses libgnomesu BTW
<jdub> seb128: but we have patches for it to use sudo
<seb128> yeah, I need to update the patch :/
<seb128> and the evil guy has broken the ABI again in the new libgtop
<jdub> oh man
<jdub> dude, you uploaded it!
<jdub> to gnome ftp!
<seb128> jdub: he changed the soname and that's not a devel platform
<jdub> which is ok
<seb128> yep, that's why I uploaded
<seb128> that's just annoying to have to rebuild a bunch of stuff
<jdub> but i'm looking at my ftp-release-list archive and feeling less sympathetic to you ;)
<jdub>    N   11/01 | Sebastien Bacher   | 0.8K | gnome-system-monitor 2.9.4
<jdub> -> N   11/01 | Sebastien Bacher   | 0.8K | libgtop 2.9.4
<jdub> ^ heh
<seb128> ah ah
<seb128> need to do a control-center release tomorrow :)
<jdub> awesome :)
<jdub> great to have an active maintainer ;)P
<seb128> :)
<kent> sorry for disturbing now, but does gnome even have a control-center?
<jdub> yes
<jdub> that's the preference dialogues
<sivang> jdub: btw, we now have default privileges groups support in g-s-t's user profiles, now if only I could understand the backend code while my perl-fu is not high lately.....it would also store this profiles to disk...:-)
<sivang> *profiles(s)
<jdub> sivang: rocking :)
<seb128> jdub: mail desktop-devel about libgnomesu/sudo please :)
<jdub> sivang: wish they were python...
<sivang> jdub: I am thinking of taking garnacho there.....he hesitent somewhat with the amount of code there is there..
<jdub> seb128: buffer being filled atm ;)
<seb128> cool
<lamont_r> mdz/kamion: live-fs builds runs at 0615 london, takes ~25-30 min
* jdub uses figlet "NO!"
<lamont_r> that should hit 0801 easily
<mdz> lamont_r: sounds good
<mdz> I'll set my cron job to download at 0900 or so
<lamont_r> mdz: and he has it set up to fetch the most recent successful build...
<mdz> and I will have FRESH HOT COMMITS EVERY MORNING
<lamont_r> meaning you'll be making them, or testing them, I wonder...
<daniels> Kamion: your Bill impersonation is for shit; you forgot some long melodrama involving someone who just discovered he was gay
<mdz> brute-force kernel fix is a success
<mdz> uploading
<lamont_r> mdz: you want 2 builds a day, then? :-)
<mdz> lamont_r: how long to build linux-source-2.6.10 on all live CD architectures?
<mdz> lamont_r: I'll want to kick off a live CD build when they're done
* lamont_r checks
<daniels> Kamion: (amusingly, the outdoor scenes of Neighbours are filmed about a 15min drive north of me)
<Kamion> that's when good neighbours become an infuriatingly catchy theme tune
<lamont_r> ppc is 4:30, i386 3:30, and amd64 2:00
<daniels> Kamion: becooooooooooome ... good ... frieeeeends
* daniels heads back to bed.
<elmo> 4:30, that's SO WRONG
<lamont_r> mdz: you uploaded another kernel??? dammit
<mdz> lamont_r: er, yes?  2.6.10-4 was broken
<lamont_r> elmo: yeah, adare did 2:53, sigma 2:23, and royal managed it in 3:45
<lamont_r> mdz: sigh.
<lamont_r> before or after 1700 your time?
<mdz> -rw-rw----  1 mdz mdz 336 2005-01-10 17:03 ../../../linux-source-2.6.10_2.6.10-5_source.upload
* lamont_r wonders if elmo wants to whack cron.daily once.
* lamont_r wants to mirror at least the sources before he heads back home, you see..
<elmo> the diff between -4 and -5 can't be that big?
<elmo> at least in source form
<mdz> the entire .diff.gz is only ~3.5M
<mdz> but the binaries are rather large
<elmo> yeah, but they won't build for like 4 hours
<elmo> so whacking cron.daily isn't going to help anyone
<mdz> ...unless they get lucky and hit the right buildd to get a ccache win?
<mdz> wanna-build-ng ought to prefer the same buildd as the previous build
<elmo> ccache isn't that much of a win for kernels 'cos of the CPU changes
<mdz> don't they have a couple gigs of ccache? should be plenty
<elmo> yes but it doesn't seem to cope with the difference gracefully
<lamont_r> elmo: it'll let me mirror source now though ,instead of in 30 minutes
<mdz> a full i386 build tree is ~500M
<elmo> lamont: it's 3.5Mb?
<lamont_r> elmo: point
<lamont_r> nm
<mdz> it will just cache each -march separately
<elmo> mdz: doesn't IME
<mdz> it does for me
<lamont_r> IME?
<elmo> every time I compile kernels for Debian as soon as I switch architectures, it goes back to "normal" speed
<elmo> (err, CPU architectures)
<mdz> it does a hash of all the flags which affect compilation
<lamont_r> we have 3GB of cache, or was it 8?
<mdz> lamont_r: what's the hit rate like?
<elmo> lamont: who knows, but it should be 10x the latter of those :P
<elmo> half a fricking terabyte and you won't even use 5% for ccache :P
<mdz> elmo: that should be plenty for freeze time
<lamont_r> wGB
<lamont_r> 2GB
<mdz> gah, that's nothing
<mdz> that's not even a linux-source build on i386
<opi> yawn
* lamont_r bumps it to 10GB everywhere
<opi> time to catch some Zzz
<elmo> dude.  half a terabyte.
<elmo> seriously, what's the problem with giving it 50 or even a hundred?
<mdz> elmo: he needs some space for pr0n
<elmo> oh, yeah, fair point
<lamont_r> 30GB except for ia64, which gets 4G
<lamont_r> * 3 chroots - that barely leaves room for oo.o to build.
<lamont_r> speaking of oo.o...
<elmo> hmm, I hope ccache has sensible expiriation policies ;0
<lamont_r> elmo: LRU, iirc
<seb128> ok, time to sleep, 'night
<lamont_r> mdz: ubuntu-meta... how do I tell it to not bother with oo.o on ia64?
<lamont_r> they're arch: all, and depend on things that aren't there on ia64...
<jdub> mdz: so we taslked about using a sudo group a while back
<jdub> mdz: is it far too late to do that for hoary?
<elmo> what's unix_chkpwd?
<lamont_r> elmo: tell me that's not a kernel module...
<elmo> no, it's some suid binary, with an unhelpful manpage
<elmo> ah, nm, found 155583
<lamont_r> 170MB of kernel images. and that's just i386/ia64
<elmo> I suppose "just break NIS and let them suffer" is an option for us?
<elmo> err, I DONT suppose
<Kamion> jdub: it's relatively straightforward to do it on installs; what about upgrades?
<mdz> lamont_r: you don't...they use the seeds
<mdz> lamont_r: it's smart enough not to depend on things that don't exist on a particular arch, but it doesn't track dependencies
<mdz> elmo: didn't I propose in that bug that the NIS package override its permissions or something?
<jdub> Kamion: yeah, that's my owrry too - but we could just add the group line to sudoers and leave the existing configuration
<mdz> elmo: anyway, that's how I think it should work
<jdub> Kamion: perhaps add the first user to that group, too (would be safer to do that too)
<mdz> lamont_r: if you want to make it that smart, feel free
<elmo> mdz: yeah, like, two years ago
<Kamion> jdub: on upgrades, you have to check that the first user still has unrestricted sudo privileges
<Kamion> it's not trivial
<mdz> lamont_r: why don't you share the cache between chroots?
<lamont_r> mdz: how?
<mdz> Kamion: yeah, this would only be for new installs
<jdub> Kamion: add all the users that have ALL/ALL to the group?
<elmo> su - user -c 'sudo -l' ? \o/
<mdz> lamont_r: mount --bind
<lamont_r> ??
<lamont_r> nfs?
<Kamion> jdub: means you have to parse sudoers in the maintainer scripts, which is a bit sucky
<jdub> mdz: wouldn't want to do it on upgrades at all?
<elmo> lamont: no, bind mount /home/buildd/.ccache
<lamont_r> oh. chroots on the same machine
<lamont_r> sigh
<lamont_r> EBRAIN
<Kamion> and arguably crackful - would be better to use sudo code to do that parsing
<mdz> or put it in some directory that you already share; surely you share something already
<lamont_r> nothing shared currently
<mdz> jdub: no, I don't think so.  as Kamion says, it's tricky to get right
<Kamion> elmo: su> freak
<mdz> and since the semantics don't change anyway, what's the point
<lamont_r> mdz: why should they have anything shared?
<mdz> lamont_r: I suppose not in the buildd chroots
<lamont_r> elmo: any policy objections to me creating ~buildd/ccache and bindmounting that into all the chroots as ~buildd/.ccache?
<mdz> lamont_r: other than /dev at least
<lamont_r> well, proc and devpts are mounted everywhere...
<elmo> lamont: no
<mdz> you use a static /dev?
<lamont_r> mdz: uh, I guess...
<mdz> how 1995
<lamont_r> mdz: debootstrap hoary chroot-hoary http:....
<lamont_r> simple, spartan, workable
<elmo> mdz: considering the udev package just recently trashed several of our chroots...
<lamont_r> and yes, very 1995
<elmo> lamont: tho, I'm not sure I see the point
<mdz> elmo: it what?
* Kamion finds it considerably easier to use static /dev in chroots too
<Kamion> saves me trying to figure out how to start udev at the right time, and how to get hotplug events to all the udev instances in all the chroots
<lamont_r> elmo: bind mounting one 150GB ccache across all the chroots?
<Kamion> (or bind-mounting)
<elmo> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287146
<elmo> mdz: ^-- variant on that
<lamont_r> won't help much until hoary release, and then hoary-security and hoary-updates and bendy will all benefit some
<mdz> elmo: your fault for using 2.4?
<elmo> I wasn't, you lamer
<lamont_r> of course, with any luck, we'll have buildd-ng by then, and definitely want a shared ccache..
<mdz> hippie
<jdub> mdz: did you disable *all* patches, or just the stolen from head ones?
<mdz> I bet you didn't compile in support for tmpfs, or sockets or something
<elmo> mdz: no, it was a genunine package bug
<elmo> it ALWAYS tried to start udev and do the bind mount of a tmpdir crap
<mdz> jdub: I disabled all the new patches from -4 except the security-related ones
<elmo> which doesn't work too well in a chroot where daemons don't start
<mdz> jdub: (some of the security-related ones were stolen from head ones)
<elmo> and more to the point it bind mounted an empty dir over the real /dev
<jdub> ah, ok
<lamont_r> elmo: the livecd fs build diverts sbin/udevd to avoid that issue... :-(
<mdz> jdub: fabbione can sort out the rest tomorrow
<mdz> or more likely, just upload a 2.6.10-2 version 2.6.10-6
<mdz> we need a better naming scheme for the kernel ABI version
<mdz> 2.6.10+2 or something
<mdz> something which doesn't look like a Debian version number
<elmo> yes please
<elmo> typing those in byhand breaks my brain
<mdz> I'll add it to the hoary+1 list, no desire to mess with it at this stage
<jdub> mdz: still unhppy with bendy? :)
<mdz> jdub: I fucking hate bendy
<jdub> CKK-CHHK COMING THROUGH LOUD AND CLEAR
<elmo> mdz: let's just go on strike
<mdz> warthogs are warty in a punnish sort of way, and some hedgehogs could certainly be hoary, but a bendy badger is a stretch in the wrong direction
<jdub> haha
<jdub> bend and stretch
<jdub> reach for the badger
<Nafallo> huh? the *hogs are already used? :-P
<mdz> if anyone from the press asks me about the names, I will respond unhesitatingly "I hate those goddamn names"
<elmo> hey, what happened to bugzilla?  did someone tighten up the perms?
<stub> We can truncate it to bent badger (too much crack)
<lamont_r> so how do I get the mixer to give me > 100% volume?
<elmo> yeah, and while you're at, how do I get time to go backwards?
<elmo> [i.e. huh?
<mdz> lamont_r: you want it to go to eleven?
<lamont_r> I just want more volume...
<lamont_r> mencoder to rip a dvd, and now I can barely hear the volume...
<azeem> lamont_r: you need a GHETTO BLASTER
<azeem> ask daniels for details
<lamont_r> ah, bumping up PCM seems to maybe have helped.
<lamont_r> or maybe it was one of all those others I moved from 70->100%
<lamont_r> :-)
<azeem> "energize"
<stub> I assume /usr/share/sounds/gaim disappearing is not good?
<jdub> might be a gaim upgrade issue
<jdub> there were some funny package problems before
<stub> Hmm... looks like a load of packages decided to not install before, including gaim-data
<jdub> hrm, sounds is in the latest package i have
<stub> Although they downloaded fine
<jdub> ah, i don't ahve the latest
<jdub> do you have gaim-data installed?
<Nafallo> lamont_r: put a good reciever between computer and speakers :-).
<stub> Got it now - no idea what happened unless Synaptic saved its old logs
<jdub> gaim definitely depends on gaim-data, mmm
<Nafallo> yikes! my clock must be screwed. it says it's 3:02 over here :-P
<azeem> yeah, my clock pretends it's just 3:00
<Nafallo> 3:04 with ntpdate. time for me and lappy to continue in bed then ;-).
<jdub> stub: gaim-data doesn't replace gaim
<stub> All I know is I did a reload, full update and ignored the output. gaim-data was then missing. Just doing another full-apply (no reload) installed a load more packages and it was fine.
<jdub> yeah
<sivang> how do people get du2br.user addresses? is this somekind of a new TLD/proxy through which they connect? intersting..
<Kamion> sivang: no, it's a cloak, basically an illusion created by the IRC server
<Kamion> see http://freenode.net/faq.shtml#projectcloak
<du2br> sivang, http://freenode.net/faq.shtml#cloaks
<Kamion> (or that)
<sivang> Kamion: tnx for the link.
<sivang> du2br: you too
* lamont_r heads home
<sivang> daniels: did you ever get to kylie minouge when she acted for neighbors? :)
<zeratha> I've been getting some help in the #ubuntu channel, but this problem has yet to be resolved. I installed Ubuntu and sound worked great. Then I updated the system, and now I am getting the no mixer element error. I tried gst-register-0.8 and that didn't help. I get errors from both XMMS and totem. Any ideas?
<lamont> zeratha: #ubuntu is the right place for that question...  There are lots of developers there.
<lamont> this would be the channel to discuss your proposed code change to fix it...
<zeratha> lamont, well, there are so many people ther and so much chatter, I was hoping someone here might have a quick work-around or fix. I'd rather not reload the system with Fedora, just because I'm more familar with it :-(
<lamont> you running hoary or warty?
<zeratha> warty
* lamont has little clue wrt sound
<zeratha> ok thanks anyhow.
<HostingGeek> <mjt> i'm seeing the same behaviour with my cdrom drive and kernel 2.6.10 - it locks the door (mplayer (it's dvd really), xmms, ..)
<HostingGeek> <mjt> 2.6.9 was ok with that - no door locking
<HostingGeek> Why did you ignore HIM!!!!!
<lamont> HostingGeek: who are you talking to?
<HostingGeek> you guy didn't answer him for an hour and talk about other stuff
<lamont> dunno - first I've seen of the discussion.
<lamont> I have noticed that 2.6 doesn't like to let you eject mounted drives.
<lamont> s/drives/cds, etc/
<lamont> was that in #ubuntu, or here?
<mdz> lamont: what's happening with that kernel build?
<lamont> i386 and ppc chunking along, amd64 done
<lamont> start time was ~0135 london for all 4
<lamont> well, ia64 was 0225 start time
<lamont> but I know you don't care about that. :)
<lamont> it's only 0431 there now
<mdz> ok, thanks
* lamont wonders what the latest on shtoop is
<lamont> shtoom?
<fabbione> morning guys
<lamont> morning fabbione 
<fabbione> hmmmm
<fabbione> i guess i will need to do some bootstrapping dance for mono on sparc...
<lamont> fabbione: thom was working on figuring out the steps to that dance
<fabbione> ah ok
<fabbione> humpf a lot of stupid FTBFS
<fabbione> lqtplay.c:32:31: X11/extensions/Xv.h: No such file or directory
<fabbione> lqtplay.c:33:34: X11/extensions/Xvlib.h: No such file or directory
<lamont> heh
<lamont> we know what caused those... :)
<fabbione> blame GTK!
<mdz> fabbione: I had to abuse the kernel, I'm afraid
<fabbione> mdz: ?
<mdz> fabbione: #5410
<fabbione> checking...
<fabbione> it hasn't been assigned to me...
<mdz> I closed it
<mdz> it was assigned to you, but you were asleep
<fabbione> hmmm
<fabbione> no
<fabbione> i don't think that is the correct solution
<mdz> you really think so? :-P
<mdz> however, it was the simplest way to un-break it
<fabbione> yes because all these modules are shipped with the kernel
<fabbione> so even if the abi changes they should be able to load
<mdz> no
<fabbione> the abi is only for external kernels
<mdz> there is a good reason why we change the package name when the ABI changes
<fabbione> external-modules
<mdz> users upgrade to the new kernel, and then they can't load any modules
<mdz> until they reboot
<mdz> and in this case, no modules would load at all on the live CD
<fabbione> mdz: that's why there is a warning that when you upgrade the kernel you need to reboot the machine
<mdz> fabbione: it is not OK to change the module ABI without changing the package name
<fabbione> mdz: if i knew that there was an ABI change i would have change the package name
<lamont> mdz: looking at 4148, I'm inclined to upload 1.4.3-20ubuntu2 == debian/1.4.3-20.  thoughts?
<mdz> lamont: agreed
<lamont> since there isn't a -21 to sync,and all that.
<mdz> lamont: all yours
<fabbione> mdz: did you kept an interdiff between -4 and -5?
<mdz> fabbione: I can generate one if you need it
<fabbione> mdz: that would be nice.. thanks
<mdz> but all I did was create a 00list-5 which did not apply those patches
<fabbione> yeah but which patches?
<fabbione> all the stolen from head?
<fabbione> because some of them were applied before this release too
<mdz> I knew what I was doing
<fabbione> i need to wake up my gf
<fabbione> brb
<fabbione> i know you know :-)
<mdz> I started from -3 and added the security patches from -4
* lamont makes a note to file ftbfs bugs on all of the main failures tomorrow
<mdz> diff mailed
<fabbione> thanks
* HostingGeek jumps
* fabbione sighs
<fabbione> mdz: you lost a couple of security patches on the way :(
<mdz> fabbione: if so, they were not marked [SECURITY] 
<mdz> I applied those
<fabbione> sorry but they are
<mdz> which?
<fabbione>   * [SECURITY]  http://seclists.org/lists/fulldisclosure/2005/Jan/0270.html:
<fabbione>     - Add patch 031-sg_scsi_ioctl_int_overflows.dpatch.
<mdz> hmm
<mdz> I remember pasting that one
<fabbione> no worries
<fabbione> it's nothing easy to exploit
<fabbione> the second one was in that pool of patches, but it was not marked sa SECURITY.. that's right
<fabbione> it is a proactive patch in that direction
<thully_> so, what's the status of suspend userland being merged into hoary?
<thully_> suspend - as in suspend-to-RAM, suspend-to-disk, etc etc
<fabbione> mdz: how long ago did you upload -5?
<fabbione> ppc is not even around yet....
<fabbione> ehhe
<mdz> fabbione: a few hours
<fabbione> ok
<fabbione> plan is to upload -6 to readd the security patch
<mdz> 1703 local time
<fabbione> and jump the abi with all the stuff from -7
<mdz> sounds good
<fabbione> hey Keyser
<fabbione> KeyserSoze: back to ubuntu after gentoo?
<mdz> I just saw that film for the first time yesterday
<fabbione> which film?
<fabbione> the Usual Suspects?
<mdz> yes
<fabbione> eheh
<jdub> mdz: whoa!
<fabbione> mdz: you should see Secretary
<fabbione> that's a weird movie
<mdz> I saw it
<fabbione> did you?
<fabbione> ehe
<mdz> it came around on mythtv
<Keybuk> I've never properly seen it
<fabbione> i think to really appreciate some details you need to know a bit about BDSM and watch it a couple of times
<Keybuk> Usual Suspects, that is
<Keybuk> fabbione: you know a bit about BSDM? :p
<fabbione> ahhh
<fabbione> i tought Secretary
* fabbione inflicts pain to Keybuk 
<fabbione> :P
<thully_> Hi - I've got a suggestion for Hoary's live CD
* lamont admits to having NFC what he should really do with #3442
<Keybuk> stars Daniel Jackson 1 and Donnie Darko's sister
<Keybuk> *interesting*
<lamont> fabbione: is linux-meta happy with ia64?
<fabbione> lamont: afaik it should..
<fabbione> lamont: we did the same day we did sparc...
<lamont> fabbione: right.  closing the bug
<thully_> Could the kernel headers be added to it?  I feel that these would be useful if there was a dire situation when a network card/modem without native drivers needs to be used from the live CD - the drivers could be built w/linux-headers
<fabbione> lamont.
<fabbione> lamont: sure that the bug is 3442?
<lamont> 3442 is fontconfig
<lamont> 4142 was linux-meta
<lamont> and closed
<lamont> 3442 is still hanging in the wind
* lamont defers to mdz on what packages should go on livecd..
<fabbione> lamont: checking.. just a sec. i recall doing that change in fontconfig
<lamont> although I'm tempted to sneak netehack onto it.:-)
<lamont> fabbione: if you know what to do, feel free to hijack it...
<mdz> thully_: they wouldn't be useful without a C compiler
<thully_> then add the C compiler also - that may be useful also if something used for diagnostic purposes needed to be compiled
<mdz> thully_: space is limited
<fabbione> lamont: i will give you the solution.. use laptop-detect
<fabbione> lamont: as we do in Xorg
<fabbione> lamont: that portion of the code has been introduce in Debian for a better x <-> fontconfig interaction
<mdz> thully_: linux-headers + build-essential is over 100M
<fabbione> lamont: so that one of the 2 questions can go away if the other has been answered already
<thully_> I see - I thought they were less than that
<fabbione> lamont: we don't ask any of them because we have a common source of info in laptop-detect
<mdz> the kernel headers have become enormous
<fabbione> lamont: so basically you can just keep what we have
<thully_> I knew that there was no space crunch on the install CD - didn't know about the live CD though
<lamont> thully_: there's always space crunch
<thully_> BTW - can you install debs when booted off the liveCD?
<lamont> once you start shipping something, it's hard to stop
<fabbione> lamont: and don't listen to all these people that rants about one method or another.. 
<lamont> thully_: certainly
<fabbione> lamont: tell them to buy better hardware and reassign the problem to gtk
<lamont> fabbione: you want to go ahead and do that merge, then?
* fabbione needs help to maintain the kernel
<fabbione> lamont: i need to fix the kernel
<thully_> lamont: warty's install CD could have had about 150MB more on it
* lamont might be talked into helping fabbione...
<thully_> that doesn't seem like space crunch
<thully_> but I see that the live CD is a different story
<fabbione> lamont: i am afraid that as porter you will be involved :)
<lamont> thully_: that's because we agressively approached things as though there were a space crunch
<lamont> fabbione: np
<fabbione> mdz: the kernel -> bzip thingy is a pain to test
<lamont> thully_: once it's gone, it's pretty much gone.
<fabbione> mdz: i will do as soon as i can trash a build for it
<fabbione> mdz: it needs some changes in kernel-package
<mdz> fabbione: really?  it should just be dh_builddeb -- -Zbzip2
<thully_> when will the acpi userland support packages be merged into hoary, anyway?
<mdz> ah, ok
<mdz> thully_: which ones?
<mdz> I saw mjg59 upload at least some
<thully_> yes - his - the ones that allow suspend-to-RAM as well as suspend-to-disk
<fabbione> mdz: no.. it uses manually dpkg --build in several points
<fabbione> mdz:
<fabbione> so i need to do some manual love...
<fabbione> but i was thinking that i can flaggify it ;)
<fabbione> somehow...
<fabbione> so we can switch anytime
<lamont> Mithrandir: you awake yet?
<lamont> Mithrandir: any chance you could look at the current libsdl1.2 on amd64 and tell me what's borked?
* fabbione sends a not to lamont that fabbione is the only one waking up at 6 am
<fabbione> s/not/note
<lamont> fabbione: feh.  I'm online somewhere between 5:30 and 6:15 each school day morning
<lamont> didn't realize you were in that camp too.
<fabbione> lamont: well that i am not the only one :-)
<lamont> heh
<fabbione> lamont: i need to wake up my gf every morning
<fabbione> she can't wake up by herself
<fabbione> OH GREAT!
<fabbione> only 430 message on LKML in the last 12 HOURS!
<lamont> LOL
<fabbione> and approx 25000 lines of diff between bk9 and bk13
* fabbione cries desperatly
<fabbione> oh diff.. in the changelog!
<fabbione> not in the code
<lamont> linux-source-2.6.10_2.6.10-5_20050111-0135-i386-successful
<fabbione> ehe there will be -6 and 7 up today
<smurfix> fabbione: seems like a fulltime job just to keep track of LKML these days
<fabbione> smurfix: it is
<lamont> mdz: ppc continues
<fabbione> i have been doing nothing else since i agreed with mdz that i was going to do 2.6.8.1 -> 2.6.9 :P
* fabbione hides from mdz
<lamont> sigh... ia64 build time for linux-source-2.6.10 is pretty solidly 7:30
<mdz> fabbione: if I recall correctly (and I do), what you said was that you would "look after the kernel"
<mdz> not 2.6.8.1, not 2.6.9, not 2.6.10..."the kernel" :-)
<fabbione> mdz: right.. you trapped me in somekind of obscure way of english talking...
<fabbione> :P
<lamont> fabbione: why -6 _and_ -7?
<fabbione> lamont: did you unfuck ia64?
<fabbione> lamont: -6 to readd the security patch that slept out
<lamont> ia64 is building stuff again.  doko and I got it happy
<fabbione> -7 to bump the ABI
<fabbione> and readd all the stuff that were in -4
<lamont> happy happy joy joy
<fabbione> that means renaming all the packages
<mdz> we need to wait for -5 or -6 to build before uploading -7
<fabbione> and waiting for elmo to bless NEW binaries again
<lamont> it's just that my poor mirror is struggling to keep up and failing... :-)
<fabbione> mdz: yup...
<fabbione> well.. i can upload -6 pretty soon
<lamont> mdz: rather, need to wait until the daily cd build finishes before uploading
<fabbione> so that it will be done for today
<mdz> that would be nice, too
<fabbione> and -7 tomorrow
<lamont> fabbione: -6 will not be done for today's cd build run
<fabbione> lamont: no big deal
<fabbione> it's only a security patch on scsi that is missing
<lamont> as long as it doesn't land in a way that breaks the cd builds...
<fabbione> it's not like you can gain root farting on the console...
<mdz> I'm not sure that we need another upload of 2.6.10-1
<mdz> once -5 builds, we can roll a live CD and then go to 2.6.10-2
<fabbione> mdz: well somebody might have -1 and not upgrade to -2
<fabbione> that's why i would be more happy to have -1 completely fixed
<fabbione> ohhh i knew it
<mdz> fabbione: they could also be back on 2.6.9 :-)
<fabbione> mdz: now you convinced me
<mdz> another vulnerability?
<fabbione> DIE USERS DIE UNDER THE POWER OF SCSI IOCTL INT OVERFLOW!
<fabbione> no
<fabbione> let's go for -2 directly
<mdz> ok
<fabbione> lamont: can you give me the green light for the cd to build?
<mdz> fabbione: we were discussing earlier that we should use a different scheme for the ABI version
<fabbione> or should i wait for -5 to be on all arches?
<fabbione> mdz: such as?
<mdz> fabbione: because it is confusing to have 2.6.10-1, 2.6.10-2, etc. (they look like package version numbers)
<fabbione> i agree... 
<mdz> dunno, anything really...2.6.10-a, 2.6.10-b
<mdz> 2.6.10+1
<fabbione> what's the solution?
<mdz> 2.6.10-blue, 2.6.10-yellow
<fabbione> 2.6.10.abi1
<fabbione> 2.6.10.abi2
<fabbione> 2.6.10.abi3
<fabbione> etc...
<fabbione> that would be even more clear....
<lamont> fabbione: livecd fs build is at 0615 (as is the d-i daily build).  cdrom construction runs at 0801 london time.  Not sure how long it runs, but I expect that it's done by 0900 london time.
<mdz> hmm
<lamont> Kamion would be the one to ask for a 'go-for-kernel-upload' signal once the cd's are built
<fabbione> that means a few hours from now...
<mdz> lamont: aren't we already too late?
<fabbione> lamont: ok..
<mdz> or doomed to miss it, at least?
<lamont> mdz: new upload will not make todays run
<lamont> but might just manage to break at least amd64
<fabbione> i can wait
<lamont> (amd64 is only 2 hours to build the kernel)
<fabbione> i need to test 2/3 things before uploading anyway
<mdz> fabbione: please ask Kamion to run a new build when he wakes up (once -5 is built)
<mdz> (live CD build)
* fabbione will do
<lamont> we should turn on snapshotting so that kamion can have the same image as the rootfs builds.. :-)
<fabbione> mdz: do we have any reliable way to know when the ABI in the kernel changes?
<fabbione> other than for me trying to understand some really obscure patches?
<mdz> nope
<mdz> they can change it at any time in bk
<mdz> herbert or dilinger should be able to tell you what to look for
<fabbione> mdz: you also forgot to copy 00list-4.hppa to 00list-5.hppa
<fabbione> ok. i can ask them
<lamont> woot.  ppc may actually make this cron.dailky
* fabbione hugs mdz for his love on the kernel
* fabbione and feels less lonely in his crusade against aBI changes
<mdz> fabbione: honestly I do not like the 00list method very much
<lamont> it seemed like the abi changed every upload before...
<mdz> it seems error-prone
<lamont> that's certainly the most conservative approach, but not very nice..
<mdz> lamont: before when?
<lamont> from what I saw of the 2.4 and 2.6 herbert kernels in debian.
<mdz> fabbione: I think I would rather have it apply every patch in debian/patches, so that it is obvious what is active and what is not
<lamont> but that's just my deluded memory speaking...
<mdz> nah, he only changed it when necessary
* lamont believes that
<lamont> quite likely that I only noticed it when it had needed to change
<fabbione> mdz: i did never spend much time on the packaging...
<fabbione> mdz: i just used the same packages that Herbert did...
<mdz> fabbione: yes, I know
<mdz> I had the same concern with it originally, I just did not have much motivation to change it
<fabbione> but if you want to give me a couple of days and i can make that package a bit more shiny
<fabbione> ;)
<mdz> since you are working on it, it is your decision
<fabbione> mdz: it is very time consuming...
<fabbione> to change it i mean
<mdz> I am concerned about having hppa present if it makes it easier to make this kind of mistake
<mdz> I assume it could not break the build on other arches, though
<lamont> fabbione: btw, I would be happy to be on the kernel team with you.
<fabbione> lamont: that would rock!
<mdz> what time is the CC meeting?
<fabbione> mdz: 16:00 UTC
<mdz> gah
<fabbione> and i will be there on time
<mdz> good night, then
<fabbione> night :-)
<lamont> me too, I fear.
<fabbione> mdz: we don't want big fat patches for one arch to be applied to all of them
<fabbione> night lamont ;)
<mdz> fabbione: yes, this is why it is a problem to support architectures which are not in mainline
<fabbione> mdz: last question: linux-headers-2.6.10-abi2-
<fabbione> ?
<mdz> fabbione: let's not change it yet, and wait until post-hoary
<fabbione> mdz: oh ok.. fine for me
<mdz> no hurry, just something to think about
<mdz> good night
<fabbione> night
<fabbione> KLINE on the way
<wasabi> Howdy. So, who do I speak with about getting a package into Hoary? It's a pretty big package: Eclipse 3.0.
<wasabi> It's heading to Debian, but it'll probably be hung up in experimental until the end of time (when Sarge is released).
<aj> why would you say that?
<wasabi> Say what? That sarge will never be released? Because I have my doubts. ;)
<aj> no, that it'll have to stay in experimental forever?
<aj> KDE and Gnome didn't, after all
<wasabi> True.
<aj> what's the package name?
<wasabi> eclipse. It's not there yet. I'm doing the final build of it. I'll probably get somebody to upload it tomorrow.
<wasabi> Just wanted to know who to talk to about Hoary.
<wasabi> I use Ubuntu, so it's more important to me that it's there vs Debian... but I will probably end up maintaining it in Debian anyways.
<fabbione> wasabi: proposal for packages go to ubuntu-devel mailing list
<aj> getting it fixed in experimental over a few weeks, then putting it in unstable, whether or not sarge is released; and having it appear in multiverse automagically would've been the first preference i would've thought; experimental->unstable seems likeit ought to be fairly easy at first glance
<ajmitch_> does the current debian maintainer not have enough time for it?
<wasabi> The current debian maintainer has orphaned it, and it's about a year and a half behind.
<aj> tbh, i can't see much need for it to even spend more than a week in experimental
<aj> nothing seems to depend on eclipse, anyway?
<wasabi> eclipse provides libswt-java
<wasabi> I am guessing a few things depend on it, all in contrib non-free
<aj> nothing packaged
<aj> ...that i can see anyway, don't think i missed anything though
<wasabi> heh. my apt-cache rdepends: mmap ran out of room
<aj> oh, actually eclipse isn't even in sarge, so uploading a new version has no effect on the release
<aj> does the new package (libswt2.1-motif-jni or it's replacement in particular) depend on libmotif still? or is that gone completely?
<wasabi> I'm killing it.
<wasabi> It doesn't serve a useful purpose.
<aj> i'd say just upload it straight to unstable, personally; then it should go straight to multiverse whenver that next gets updated too (disc: i have no idea how multiverse actually gets updated)
<jblack> daniel: ping
<fabbione> i think he is not around
<fabbione> go ahead jblack
<fabbione> what video card is in that lappy?
<jblack> radeon mobility 7500
<fabbione> ok..
<fabbione> can you put the config somewhere?
<jblack> sure.
<fabbione> i need to grab cigarettes.... brb
<d3vic3> mdz: ping 
<jblack> http://mercury.linuxguru.net/~jblack/XF86Config-4
<fabbione> re
<fabbione> d3vic3: he is asleep
<jblack> go smoke. :) 
<d3vic3> mdz sleeps by day ? 
<fabbione> i am...
<fabbione> sometimes i allow myself for one or two cigarettes in the office
<fabbione> d3vic3: he lives in the US. it's night there
<jblack> its essentially a copy of the XF86Config-4 from my other laptop, for which this works
<d3vic3> hmmm, I thought he was in UK 
<crimsun> d3vic3: it's 2:24 AM in his timezone.
<jblack> the idea is to get this other laptop doing dual-head, and then that xdcmp or whatever thing, to give me 4 monitors
<d3vic3> that expalains it 
<fabbione> jblack: ahhhh ok.. XDMX sucks btw..
<fabbione> jblack: what is the error on in the logs?
<jblack> oh, it does? 
<fabbione> jblack: yeah.. it's way slow...
<fabbione> and it tends to break the graphic on gnome...
<fabbione> like missing icons
<fabbione> horiz bars during refresh
<fabbione> and i am on 100Mb FD
<fabbione> so there is no real network limitation
<fabbione> it can be because one machine is xorg and the other xfree
<fabbione> but i didn't bother to test too much
<fabbione> jblack: anyway let's make this thing work
<fabbione> put /var/log/Xfree86.0.log somewhere i can look at it
<jblack> oh boy. maybe I shoudln't bother, since I'm using wireless
<fabbione> well.. let's get the dual head working anyway
<fabbione> perhps with xorg <-> xorg it works...
<fabbione> the mouse movement on a clean X run was ok
<fabbione> gnome was slow.. but that's not really measurable in my environment
<fabbione> it was way too mixed
<jblack> http://mercury.linuxguru.net/~jblack/Xorg.0.log
<fabbione> hmmmm
<fabbione> jblack: than you modified the wrong config....
<fabbione> Xorg uses xorg.conf
<fabbione> not XF86Config-4
<jblack> is it as simple as copying the one onto the other? 
<fabbione> yes
<jblack> oh, wait, the info is already there.
<jblack> diff XF86Config-4 and xorg.conf shows no diffs
<fabbione> jblack: if you look at the beginning of the log you can see that the ATI-2 hasn't been checked at all
<fabbione> the Section "ServerLayout" is missing the second head part
<fabbione> Section "ServerLayout"
<fabbione>         Identifier      "Default Layout"
<fabbione>         Screen          "ATI-1"
<fabbione> ah no
<fabbione> sorry
<fabbione> there are a few things wrong
<fabbione> let's start from the top
<fabbione> Section "Screen"
<fabbione>  Identifier"Default Screen"
<fabbione> Device"ATI-1"
<fabbione> change "Default Screen" to "Default Screen 1"
<fabbione> and for ATI-2 do a similar thing
<fabbione> to "Default Screen 2"
<jblack> WHoops. /me forgot the serverlayout screen
<fabbione> then.. down to the ServerLayout
<jblack> and now it works great
<fabbione> ehehe
<jblack> you're like a genious or something
<fabbione> nahh....
<fabbione> that was easy...
<jblack> so the question is, fix kde, or try xdmx
<fabbione> for xdmx you need to do a lot of magic...
<fabbione> but i can help you there
<jblack> from the way you describe it, its not even worth it
<fabbione> well you can still try and decide yourseld
<fabbione> yourself
<jblack> ok
<fabbione> let me dig the configs
<jblack> then lets do this
<fabbione> install xdmx on one of the machine.. the one is going to be the "input" box
<jblack> input box as in the extra display machine? 
<fabbione> you have 2 machines...
<fabbione> one is where you use the keyboard and mouse
<fabbione> the other one is a slave
<jblack> ok. which one is the input box? the master or the slave? 
<fabbione> the master
<fabbione> on the master install xdmx
<fabbione> there is no need of xdmx on both of them
<jblack> Ok. its installed
<fabbione> ok
<fabbione> now...
<fabbione> go on the slave.. quit gdm or X
<fabbione> and stay on console...
* fabbione digs the commands
<jblack> ok
<fabbione> from the console as root run:
<fabbione> damn.. i can't find it...
<fabbione> hold on :-)
<Treenaks> damn..: command not found
<fabbione> jblack: just a sec.. i need to find the proper command to start X
<fabbione> otherwise you will get crazy
<fabbione> there:
<fabbione> X -ac :1
<fabbione> the -ac flag is to disable access control via DISPLAY=
<fabbione> otherwise you can play with xauth
<fabbione> but i leave that as an exercise to the user ;)
<jblack> Ok. that started the slave up with the standard X checkerboard.
<fabbione> and put that process in bg ones it starts properly
<fabbione> correct
<fabbione> now.. remember that command because you will need it on the master too
<jblack> ok. its backgrounded. 
<fabbione> good...
<fabbione> let's write down the Xdmx config now
<fabbione> in which basically you create the virtual desktop on top of the 2 real ones
<fabbione> virtual test 4800x1200 {
<fabbione>     display trider-g7.int.fabbione.net:1.0 1600x1200;
<fabbione>     display gordian.int.fabbione.net:1.0 3200x1200 @1600x0;
<fabbione> }
<fabbione> the file contains something like that
<jblack> into what file does that go? 
<fabbione> it doesn't matter
<fabbione> you will have to specify the config file to xdmx anyway
<fabbione> so how does it work:
<fabbione> virtual test 4800x1200
<fabbione> is the global resolution you want
<fabbione> that's up to your local resolutions
<fabbione> (remember it needs to be a square)
<jblack> One of them isn't.
<fabbione> they need to have either the same width or the same height
<fabbione> at least for simplicity
<fabbione> it is possible to make more complex screen configs
<fabbione> but i didn't dig too much into it
<fabbione> and i am not sure the protocol is really really smart yet
<fabbione>     display trider-g7.int.fabbione.net:1.0 1600x1200;
<fabbione>     display gordian.int.fabbione.net:1.0 3200x1200 @1600x0;
<fabbione> these 2 lines define the slaves
<fabbione> note:
<fabbione> you cannot use an IP address there
<jblack> Lets hope it is, because on my primary, its 1920x1200 + 1200x1024
<fabbione> for a test reduce the primary to 1920x1024 or something like that
<fabbione> so that it will become 3120x1024
<fabbione> just for testing is fine...
<fabbione>     display trider-g7.int.fabbione.net:1.0 1600x1200;
<fabbione> this is my master head... in my case
<jblack> This isn't going to work.
<fabbione> why not?
<jblack> different screen sizes, no hostnames
<fabbione> you can use /etc/hosts for that
<fabbione> and you can set the screen to share at least one dimension
<jblack> Not with the equipment I have. ;) 
<fabbione> ehhe
<jblack> not on this display. I don't have a monitor that matches the lcd
<fabbione> ah o
<fabbione> k
<fabbione> well
<fabbione> grab the config anyway
<fabbione> so you know how to do it
<jblack> I'm trying something else. 
<fabbione> ok
<jblack> on the slave machine, in my .xinitrc I put "ssh -X otherlaptop startkde" 
<fabbione> that won't help much
<jblack> Well, its not the same screen, so I can't move windows across or anything...
<jblack> but I have my home dir
<fabbione> jblack: if the point is only /home just use nfs to share it between them
<fabbione> that's what i do here
<doko> fabbione: any preference to but the avm isdn modules in separate binary packages, or bloat the existing packages? (size increase from 1.5mb to 4.5mb)
<fabbione> doko: i have no preferences.. that's up to mdz.. the policy is pretty clear.. no extra kernel modules (that needs support) outside kernel and l-r-m
<jblack> I really appreciate the help
<fabbione> jblack: anytime
<doko> fabbione: mdz wanted to decide us on that. I think the argument is no extra kernel modules built from other sources. I just do not want to bloat each binary driver package with 3mb stuff nobody really needs outside of .de (maybe .no, hi Mithrandir).
<fabbione> doko: what about one -firmware package out of l-r-m ?
<fabbione> firmwares are not compiled so there is no need for them to be versioned
<Treenaks> fabbione: some kernels only work with some firmware versions
<doko> linux-restricted-firmware for all kind of firmware? I think kamion won't be happy with that for the firmware he needs for the udeb's.
<fabbione> Treenaks: some drivers require specific firmware versions, but in this case.. since they come from the same source a versioned dep would do
<fabbione> doko: until you create the proper udebs i don't see the problem.. perhaps let's wait for Kamion to wake up?
<fabbione> doko: actually...
<fabbione> no
<fabbione> this doesn't work
<fabbione> Treenaks is partially right
<fabbione> what if i have 3 kernels installed?
<fabbione> that would create weird conflicts installing l-r-f
<fabbione> i need a network cable... brb
<doko> hmm, ok I'll have to ask if the avm firmware is dependent on the driver
<pitti> Morning
<fabbione> hey pitti
<pitti> fabbione: needless to say - more kernel security work is coming today...
<fabbione> oh i hate you
<fabbione> well send me the stuff now
<fabbione> since i am going to upload another kernel today
<pitti> fabbione: nothing disclosable for today, sorry
<fabbione> I HATE YOU
<pitti> D'uh, today's dist-upgrade fails
<pitti> fabbione: Thanks, I'm feeling much better now
<fabbione> pitti: :-)
<pitti> gaim depends on gaim-data, but g-d is in universe and file-conflicts with gaim
<pitti> so no icq today...
<HostingGeek> I LOVE YOU fabbione 
<fabbione> HostingGeek ?
<HostingGeek> gaim-data is stuffed
<d3vic3> heh
<HostingGeek> <fabbione> I HATE YOU
<HostingGeek> wtf is up with gaim-data
<HostingGeek> why a new package?
<fabbione> eheh
<pitti> fabbione: ugh, now all feature patches are disabled in -5?
<HostingGeek> wtf is up with gaim-data
<pitti> fabbione: (#5410)
<fabbione> pitti: yes.. i am working -6 now that will bump the abo
<fabbione> abi
<pitti> fabbione: why didn't mdz do that in the first place?
<fabbione> pitti: because 2.6.10 is the default kernel and needs to be working?
<HostingGeek> just rename -3
<fabbione> i didn't notice the abi change
<HostingGeek> -3 was wonderful
<fabbione> otherwise i would have done that myself
<HostingGeek> it wasn't b0rken
<HostingGeek> now rename -3 as -6
<HostingGeek> so people don't have a b0rken system
<fabbione> HostingGeek: dude.. -5 is like -3
<HostingGeek> but
<HostingGeek> <pitti> fabbione: ugh, now all feature patches are disabled in -5?
<fabbione> HostingGeek: please.. read the changelogs before commenting
<fabbione> you are completely out of topic
<HostingGeek> wtf is up with all the b0rken packages?
<pitti> HostingGeek: calm down, there is a reason that Hoary is a "development version"
<Mithrandir> lamont: ack.
<pitti> HostingGeek: if you want something reliable, use Warty
<HostingGeek> pitti: yes but 90% of #ubuntu is using it
<HostingGeek> pitti: now i just don't reboot....
<fabbione> HostingGeek: than you live with what you choose...
<HostingGeek> 8no
<HostingGeek> arghhh
<HostingGeek> *no
<pitti> Hi mvo_ , hi carlos!
<d3vic3> fabbione, ping
<fabbione> pong
<d3vic3> fabbione, I got that cloop-utils thing to work 
<carlos> morning
<HostingGeek> ok why are there NO nvu packages in debian or ubuntu
<HostingGeek> there is a few in apt-get.org
<fabbione> d3vic3: nice
<d3vic3> but now, its broken for amd64, which means i can't test it properly 
<fabbione> HostingGeek: -> #ubuntu please. this is a developer chan
<HostingGeek> i hate it when some loser take the job of being a package maniger and does nothing for 130+ days
<d3vic3> the bug is in amd64 
<d3vic3> I kinda fixed it according to what mdz said, how do I go about testing it ? 
<HostingGeek> fabbione: but this is where the package maniger would hang out and accully read the crap i say
<d3vic3> and how do I upload the fix ? 
<Mithrandir> d3vic3: it was broken in the beginning for amd64, due to sizeof(int) != sizeof(long)
<fabbione> HostingGeek: wrong. we all are in #ubuntu and this is offtopic for this chan.
<HostingGeek> fabbione: do all you read the ALL the stuff said in 
<fabbione> d3vic3: you need to test it first... 
<d3vic3> Mithrandir, yeah I know that
<HostingGeek> #ubuntu
<d3vic3> fabbione, build and install it ? 
<d3vic3> on i386 it works 
<fabbione> d3vic3: on amd64
<Mithrandir> HostingGeek: no, but if people abuse #ubuntu-devel, we will have to ignore you, which means we lose anything you say which is not crap.  (To use your own words)
<HostingGeek> i say stuff not crap
<Treenaks> HostingGeek: your stuff maybe other people's crap, in some contexts
<Mithrandir> 09:57 < HostingGeek> fabbione: but this is where the package maniger would hang out and accully read the crap i say
<HostingGeek> then join #ubuntu-ontopic where i can say the "stuff" and you guys will still see
<Treenaks> HostingGeek: that's #ubuntu
<HostingGeek> Treenaks: no but #ubuntu-ontopic can be for stuff that you guy must read and this is #ubuntu-offtopic talk here
<smurfix> HostingGeek: Besides, among ubuntu developers, "crap" is a technical term with well-defined meaning. Ask anybody who's been in Mataro. ;-)
<Treenaks> smurfix: just like "crack" :P
<HostingGeek> what does it mean?
<Treenaks> HostingGeek: http://www.catb.org/~esr/jargon/
<mvo_> hi pitti 
<Mithrandir> hi mvo
<mvo_> hi Mithrandir 
<mvo_> I saw that there was some discussion about the hook-idea while I was sleeping :)
<Mithrandir> yeah
* mvo_ reads
* HostingGeek read it too
<HostingGeek> wtf is http://www.catb.org/~esr/jargon/
<Treenaks> HostingGeek: it's a link. paste it in your web browser.
<Mithrandir> HostingGeek: the jargon file, a collection of terms and their meanings.
<HostingGeek> yes how to use it
<HostingGeek> the search page look like crap
<HostingGeek> ohh wait now i know what crap means
<HostingGeek> Treenaks: funny meaning i alway thought it was a nicer word for poo
<d3vic3> fabbione, I modified one file to fix the bug 
<d3vic3> i used diff -u to get the changes 
<fabbione> d3vic3: yes.. i understand that.. you still need to get it properly tested on amd64
<d3vic3> now I can just pipe that to a file and attach it to the bug ? 
<d3vic3> I know 
<d3vic3> I sent e-mail to mdz 
<fabbione> d3vic3: yes you can do that too
<fabbione> or ask Mithrandir to test it for you?
<fabbione> or somebody with an amd64?
<d3vic3> and waiting to see if we have a test machine lying around 
<fabbione> i have none.. so i can't help there
<d3vic3> hmmm 
<d3vic3> ok 
* fabbione installs another test box in his datacenter
<d3vic3> thanx, you are helpfull, jblack was right 
<d3vic3> he he he 
<Mithrandir> d3vic3: I can test the patch, sure.
<fabbione> see :-)
<fabbione> d3vic3: generally i suggest you to ask everybody around and not just me
<fabbione> that will speed up stuff. trust me
<d3vic3> lol 
<fabbione> specially when i go in deep insane kernel mode
<d3vic3> yeah 
<fabbione> ;)
<d3vic3> ok 
<d3vic3> :-/
<d3vic3> i don't know most ppl here 
<d3vic3> especially who does what 
<d3vic3> :-| 
<fabbione> d3vic3: that's why... keep it generic
<Treenaks> d3vic3: stay for a while and read, you'll figure it out :)
<fabbione> and people will answer if they can help
<d3vic3> true 
<Treenaks> d3vic3: also read the -devel mailing list
<fabbione> d3vic3: otherwise a fast turn around...
* d3vic3 takes notes 
<Mithrandir> d3vic3: then don't address anybody in particular and say interesting things and you'll get a response. ;P
<fabbione> d3vic3: Treenaks and daniels are our bitches... :P
* d3vic3 takes more notes 
<d3vic3> bitches? 
<fabbione> Mithrandir is our amd64 god
<fabbione> d3vic3: just kidding ;)
<d3vic3> he he 
<fabbione> daniels is our Xorg bitch^Wkid
<Mithrandir> fabbione: amd64 czar :)
<fabbione> i am the kernel boy.. but if the kernel doesn't work for some reasons you can either blame GTK (Seb128) or your broken hardware
* Mithrandir chuckles at fabio
<fabbione> seb128 is our gnome guru
<Treenaks> fabbione: guru^Wscapegoat
<fabbione> thom 'i love to slice my fingers' bot: *mozilla*
<fabbione> elmo is our ftp-master and main sysadmin
<fabbione> meaning that if he dies we are fucked
<fabbione> rason why he lives closed in a bunker 200 meters deep in the ground under a glass bell
<fabbione> and nobody have ever seen him
<fabbione> rumors says he has like 6 heads and 12 arms...
<fabbione> (just for the amount of works he does)
<Treenaks> fabbione: hm, I thought that was lamont 
<fabbione> oh lamont.. he handles the buildd
<d3vic3> ok 
<fabbione> without him no binary packages
<Treenaks> "build daemon wrangler"?
<fabbione> same story as elmo
<d3vic3> can anyone help me make a patch tar gz ? 
<d3vic3> to send to someone 
<Mithrandir> d3vic3: no need to tar it up, just diff -Nru old-tree new-tree > patchfile
<Mithrandir> then read through the patch and make sure it's what you expect
<fabbione> d3vic3
<fabbione> and pitti is our 'derootificator' security guy
<fabbione> did i miss anybody?
<HostingGeek> i am our lame guru
* d3vic3 the newbie guru 
<Treenaks> fabbione: jdub and mako?
<Mithrandir> fabbione: mjg59, haggai at least?
<fabbione> and mdz
<fabbione> ok ok.. this is radio ubuntu-devel live from DK
<Mithrandir> and Kamion
<fabbione> dj fabbione on the console mixing for you the UD tasks
<Treenaks> kamion is the installer guru
<fabbione> *rriiiiing*
<fabbione> *rriiiiing*
<fabbione> hey we have aphone call for our first interactive show on UD's
* Mithrandir thinks fabbione should podcast this. :)
<fabbione> and let's give voice to Treenaks 
<fabbione> Treenaks: hey dude...
<Treenaks> fabbione: hm?
<fabbione> Treenaks: so we have a few missing description in our pitcure...
<fabbione> Treenaks: complete the picture to win your fabolous new kernel version 2.6.10-6!
<Treenaks> Oh wow!
<fabbione> Treenaks: soooo....
<fabbione> Treenaks: come on... don't be shy..
<Mithrandir> I think we forgot amu and mvo_ as well, didn't we?  And Keybuk, though he's not distro team, he does maintain some important packages.
<d3vic3> does diff take note of new files ? 
<fabbione> d3vic3: yes
<Treenaks> fabbione: hmm?
<fabbione> ok we have lost Treenaks 
<fabbione> Treenaks: sorry you lose
<Treenaks> fabbione: I want 2.6.10-6!
<Mithrandir> d3vic3: with -N, it does.
<fabbione> Treenaks: keep going with the descriptions for d3vic3 :-)
<Treenaks> d3vic3 is our resident noob for today :P
<fabbione> d3vic3: diff -Narud old-tree new-tree > patch
<Keybuk> Mithrandir: I'm semi-distro team
<Keybuk> "I'm complicated" :p
<fabbione> Treenaks: kinda :-)
<d3vic3> Treenaks, eish
<Treenaks> d3vic3: you just said so yourself :P
* fabbione will brb
<Treenaks> 10:25  * d3vic3 the newbie guru 
* Mithrandir pats Keybuk on the head.
<d3vic3> Mithrandir, can I send you diff's output then ? 
<Mithrandir> d3vic3: put it online somewhere and I'll download it.
<d3vic3> Treenaks, i know 
<d3vic3> erm 
<d3vic3> don't have anyware to put it 
<Mithrandir> I don't run any email client at home atm.  (And I'm not at home, but that's kinda besides the point.)
<Mithrandir> sure you do, you have an account on rookery, don't you?
<d3vic3> nope
<Mithrandir> huh, why not?
<d3vic3> rookery ? 
<Mithrandir> aka people.ubuntu.com
<Keybuk> you have an account on chinstrap?
<d3vic3> nope 
<mjt> is it "just me", or is there really no mention of pam_limits in pam.d/login ??
<HostingGeek> *riiiiiiiing*
<HostingGeek> *riiiiiiiing*
<mjt> (or, rather, it's commented out)
* HostingGeek sets mode +lol Treenaks 
* HostingGeek sets mode +typo HostingGeek 
<HostingGeek> Green [ ok ]  messages? why not apply this patch by default like all other distros have?
<HostingGeek> http://ubuntuforums.org/showthread.php?t=8556
<fabbione> HostingGeek: offtopic here
<fabbione> it has been discussed on the mailing list iirc
<HostingGeek> how is it offtopic
<HostingGeek> its offtopic in #ubuntu-offtopic 
<fabbione> because it is a communityu decision done by all users
<fabbione> therefor discussed between all of them
<fabbione> and the verdic was something like: no thanks
<fabbione> for different reasons
<mjt> "quiet" graphical boot, green/red messages.. and a cup of coffee every morning pls. ugh.
<HostingGeek> link
<HostingGeek> i need to join more mailing lists
<Keybuk> fundamantally, colour should only be used to highlight problems
<Keybuk> in particular, that's a very silly patch -- the green and red are of the same intensity, so a colour blind person wouldn't see any difference
<Keybuk> by using red for fail, they stand out in the otherwise black/white boot sequence
<Treenaks> make it BLINK
<Treenaks> that's stand out for sure!
* Keybuk shakes his head
<Keybuk> it'll be colour prompts next
<Treenaks> Keybuk: Ubuntu needs more gentoo influence :P
<Keybuk> we had gentoo influence for warty
* Mithrandir whacks Treenaks 
<bob2> next you'll all be madly trying to get the boot time down to < 30 seconds
<HostingGeek> Treenaks: no make it explode
<HostingGeek> bob2: 0_0
<Keybuk> bob2: except that's actually quite a useful thing to do
<fabbione> given that the patch to delay mount of root of 10 secs will not go kernel upstream
<mjt> delay mount??
<fabbione> yes
<fabbione> for some cases that will be required
<Keybuk> scsi cards to settle?
<HostingGeek> why the hell will you want to do that
<fabbione> basically the kernel will sleep 10 secs
<mjt> there's a patch for 2.4 (taken from Owl) 
<HostingGeek> because there is no sprate root partion by default
<mjt> but it does not sleeps, but retries mounting root
<mjt> to allow eg usb cd-rom to initialize
<fabbione> Keybuk: because of some booting methods that are not "syncable" like from usb
<fabbione> Keybuk: during boot the usb stick is seen as a floppy
<HostingGeek> haha my friend says his win xp takes 10min to boot
<fabbione> while it changes is status after it gets probed correctly
<mjt> while(mount() != 0) { sleep(); } it is, sort of
<Keybuk> that's a hell of a penalty for normal people though
<fabbione> Keybuk: well that's why they are still discussing it
<Keybuk> given how many times the average kernel developer reboots, I can't quite see that one making it in :p
<Treenaks> how about a "sleep 10&& exit".ko
<fabbione> Keybuk: you will be surprised how often they do NOT reboor
<fabbione> reboot
<Keybuk> isn't the initrd the right place to do that though?
<bob2> 'it compiles, ship it'
<fabbione> Keybuk: not necessarely.. not all kernels boot with initrd
<fabbione> it's a feature.. it is not mandatory
<Keybuk> too much stuff is a feature these days :)
<Keybuk> more mandatory, damnit
<HostingGeek> Keybuk: lol
<Mithrandir> uhm, did the ftp server which handles uploads just die?
<mjt> so, is it intentional pam.d/login does not include pam_limits?
<Keybuk> mjt: should it?
<mjt> at least it isn't consistent with all other ways to login
<Keybuk> hmm?
<Keybuk> only gdm has it
<mjt> ssh, xdm, ... -- all "calls" to pam_limits
<Keybuk> it could/should be in common-session if it's common
<mjt> well.. yes and no
<mjt> more for "yes" than for 'no' ;)
<mjt> cron also does not list it -- the only real reason cron was "pamified"
<Keybuk> it's probably that people bugged the wrong people, and made the Debian ssh/gdm maintainers add it -- rather than bugging the pam maintainer
<mjt> and now there's another question: pam_limits, if no limit is given, set it to unlimited.
<mjt> i think this isn't right
<mjt> at least `unlimited' should not be the default for everyhing
<mjt> (so, loging on my system (without pam_limit) behaves "better" than ssh with pam_limit0
<mjt> s/0/)/
<mjt> s/loging/login/ bah
<Keybuk> no idea, it's not something I know much about
<Keybuk> pam scares me
<mjt> i was trying to debug why the hell i have eg max_locked_memory=unlimited while limits.conf does not mention the limit, and kernel sets it to 32k..  pam_limits was the problem
<Mithrandir> Keybuk: pam is good for you
<pitti> seb128: Hi!
<pitti> seb128: do you know what messed up gaim?
<seb128> hello
<seb128> how messed ?
<seb128> the file conflict ?
<pitti> seb128: gaim depends on gaim-data
<pitti> seb128: g-d is in universe and file-conflicts with aim
<pitti> s/aim/gaim/
<seb128> ?
<Mithrandir> pitti: yes, I'm handling that bug.
<pitti> Mithrandir: oh, thanks
<seb128> $ dpkg -l gaim\* | grep ^ii
<seb128> ii  gaim           1.1.1-2ubuntu1 multi-protocol instant messaging client
<seb128> ii  gaim-data      1.1.1-2ubuntu1 multi-protocol instant messaging client - da
<HostingGeek> but it insatlled for me
<HostingGeek> its working for me
<HostingGeek> 'i do not lie
<Mithrandir> HostingGeek: depends on install order.  gaim, gaim-data works, gaim-data, gaim doesn't
<pitti> Package: gaim-data
<pitti> Priority: optional
<pitti> Section: universe/net
<pitti>         ^^^^^^
<seb128> pitti: yeah, it has not been seeded probably
<Mithrandir> pittit: it's an instance of the "universe by default" thing; I'll ask elmo to change that.
<HostingGeek> Mithrandir: but apt-get -f install fixes it
<Mithrandir> HostingGeek: it's still a bug.
<Mithrandir> actually, since gaim depends on gaim-data, shouldn't that be fixed automatically?
<HostingGeek> Its Not A Bug Its A Feature(tm)
<pitti> Mithrandir: no, this requires a manual step
<pitti> Mithrandir: germinate will mark it as "needs to be in main"
<pitti> Mithrandir: but AFAIK somebody has to actually put it there
<HostingGeek> gaim installed with out gaim-data for me
<Mithrandir> pitti: ok.
<HostingGeek> and gaim gave me errors of file x not found....
<bob2> HostingGeek: please dude
<fabbione> HostingGeek: this is a developer channel (again)
<fabbione> please move this stuff to #ubuntu
<Kamion> HostingGeek: Mithrandir is the person who uploaded the current version of gaim to Ubuntu. It's he who gets to say that something is a feature not a bug.
<fabbione> hey Kamion
<fabbione> Kamion: lamont/mdz were asking to get the live cd rebuilt today with linux-source 2.6.10-5
<fabbione> (or atleast be sure that it is)
<fabbione> -4 was BAD
<fabbione> and if you can ping me when you have done so i can upload -6
<Kamion> fabbione: well, it was cronned
<Kamion> let me see what the current version built with
<fabbione> Kamion: yes, but mdz uploaded -5 and we are not sure it made it on all arches
<Kamion> powerpc didn't build at all
<fabbione> mostlikely it didn't
<Kamion> amd64 built with udebs from -5 and debs in the live filesystem from -4
<Kamion> i386 built with udebs from -5 and debs in the live filesystem from -3
<Mithrandir> hi Simira 
<Simira> mornin
<elmo> ftp daemon's back
<Kamion> the current live fs build on amd64 failed because ubuntu-desktop was uninstallable
<Kamion> ditto i386 (gaim, totem-gstreamer)
<fabbione> Kamion: i am not sure what the live fs is. but i don't think it is related to the kernel... right?
<trukulo> hi
<trukulo> Mithrandir: r u awake?
<fabbione> hi trukulo 
<Kamion> fabbione: it has the kernel and modules unpacked inside it
<trukulo> hi fabbio
<Treenaks> trukulo: I think he's sleep-ircing :P
<fabbione> Kamion: hmm true...
<trukulo> coming to talk about videos
<Mithrandir> trukulo: yes, I'm here.
<fabbione> Kamion: -4 is bad...
<HostingGeek> Treenaks: no he is not
<trukulo> Treenaks: ups, seems he is awake :)
<fabbione> Kamion: is there anything we can do to either bump it to -5 or back to -3 ?
<trukulo> Mithrandir: how about uploading of the files?
<Kamion> the powerpc build failed because I suck
<Mithrandir> the only one who knows if I'm sleep-irc-ing would be Simira, since she's in the same room as me. :P
<fabbione> Kamion: come on.. you don't suck as much as i do :P
<HostingGeek> -Mithrandir- TIME Tue Jan 11 11:35:56 2005 <<< now who will be sleep ircing at this hour?
<Kamion> fabbione: well, i386 is fine, and the amd64 live CD is very very new; let's leave it and just fix powerpc
<Mithrandir> trukulo:yay, one of the files is complete now.
<fabbione> Kamion: ok.
<trukulo> ok, so we can publish the file on web, isn't it?
<trukulo> if you tell me link, i'll made a web in badopi for this
<Mithrandir> trukulo: just a sec.
<trukulo> ok
<Mithrandir> trukulo: the mako_small is live! :)
<Mithrandir> http://tracker.err.no/mako_small.avi.torrent
<bob2> so waryt's multiverse contains a ton of dodgy stuff.  but no mplayer?
<Kamion> fabbione: lamont is the person who builds the live filesystems, and he's probably asleep
<Kamion> bob2: IIRC that got fixed very shortly after warty
<trukulo> ok
<Mithrandir> Kamion: I have the build-live-cd script if you want me to test anything.
<bob2> Kamion: so it'll be in hoary or it should be there for warty on archive.u.c?
<trukulo> error on connect
<Kamion> mplayer-custom is there on i386, but nothing else
<Kamion> bob2: hoary
<trukulo> sorry
<Kamion> mplayer-386 | 1:1.0-pre5-0.6ubuntu3 | hoary/multiverse | i386
<trukulo> my fault
<Kamion> Mithrandir: nah, it's more new official builds that cdimage will pick up
<Treenaks> Mithrandir: and the other torrents? :)
<trukulo> ok, downloading
<Mithrandir> trukulo: I can see that.. ~210Kbyte/sec uploading now.
<Treenaks> Mithrandir: that's me :)
<Mithrandir> Treenaks: I'm getting them.  Sloooowly.
<Mithrandir> Treenaks: ok :)
<Treenaks> | dl speed: 208.3 KB/s                                                         |
<HostingGeek> OMG is that a ubuntu cd in today vedio clip of Bill Gates speaking at CES
<bob2> Kamion: yeah, all the weird hanging Suggests were confusing me, thanks
<trukulo> Mithrandir: as fast as we can here
<Mithrandir> trukulo: yeah, but it's still slow. :P
<HostingGeek> i am sure that says ubuntu
<HostingGeek> OOOPS
<HostingGeek> wrong channel
<fabbione> Kamion: ok.. we can live with it for today i guess
<fabbione> Kamion: lamont will build the new livefs with -6
<fabbione> Mithrandir: are the torrents up?
<fabbione> oh yeah i see :-)
<Mithrandir> fabbione: yes, but I don't have seeds for any other than mako_small yet. :/
<fabbione> ah ok
<Treenaks> Mithrandir: can't you just get the .torrent from trukulo and make him seed?
<fabbione> i will wait than
<Treenaks> Mithrandir: then wait until the downloaders become seeds
* fabbione tests a warty -> hoary update
<Mithrandir> Treenaks: that's basically what we're doing, except that he's uploading to me first.
<Kamion> fabbione: I'm building new CDs to get powerpc
<fabbione> Kamion: sure.. take your time
<fabbione> i am not in a hurry to upload
<Treenaks> Mithrandir: Now with an IPv6-enabled peer! :P
<trukulo> Treenaks: i don't have the files
<Mithrandir> Treenaks: bah, I should have beaten you to that. :P  the tracker isn't ipv6 enabled, but I have boxes here with ipv6 native.
<Treenaks> Mithrandir: hm, I'm using a tunnel.. but behind the tunnel endpoint is a native IPv6 wifi net :)
<trukulo> http://www.badopi.org/videos
<Mithrandir> trukulo: I have native, routed IPv6 on the box where I'm irc-ing off.
<trukulo> you mean Treenaks 
<Mithrandir> yes, I did
<Mithrandir> trukulo: nice with that page -- probably add a comment that we'll be adding more as fast as they become available?
<fabbione> WOW
<fabbione> i am impressed.
<fabbione> warty (fresh install) -> hoary 
<fabbione> there is only 1 package that is not upgraded
<trukulo> ups, i said on spanish, but not in english
<trukulo> editing
<Kamion> mdz: ok, daily-live/20050111.1 now has udeb/livefs kernel versions of: amd64 -5/-4, i386 -5/-3, powerpc -5/-3; so that should give you working i386 and powerpc at least
<Mithrandir> trukulo: my spanish is _really_ bad, so I wouldn't notice. :)
<trukulo> fixed
* fabbione sets up a distcc farm
<trukulo> correct my HORRIBLE english
<Kamion> fabbione: go ahead with -6
<fabbione> Kamion: thanks. i will when i am ready :-)
<fabbione> told you that there was no rush :-)
<robtaylor> carlos: alive?
<carlos> robtaylor: hey!
<carlos> morning
<robtaylor> carlos: morning :)
<robtaylor> carlos: did you get chance to check out the accessd code yet?
<carlos> robtaylor: not yet :-(
<robtaylor> carlos: !
<robtaylor> carlos: i think i'm going to do some glib binding examples, check over the consistency of method naming, do some basic documentation and put to gether a 0.1 release 
<carlos> robtaylor: I need to setup for you an sftp account
<carlos> the webdav method is not working atm for me
<carlos> please if I don't give you it before this weekend, poke me
<robtaylor> carlos: ok :)
<robtaylor> it'll take a little while to update the documentation, but just to let you know i want to make a move on this, as its starting to look needed..
<robtaylor> :)
<carlos> robtaylor: I suppose you are following the libgnomesudo discussion, right?
<robtaylor> carlos: nope! where?
<robtaylor> gnome-devel?
<carlos> Desktop Devel <desktop-devel-list@gnome.org>
<carlos> "GNOME System Monitor will use libgnomesu"
* robtaylor looks
<robtaylor> hmm, i guess one of us should post :)
<robtaylor> carlos: one thing i've been thinking about is what namespace to use for the capability request string..
<robtaylor> I think in the examples I'll use  dbus namespace style and then see if people follow my lead. But i was also thinking maybe about using RDF
<carlos> robtaylor: why do we need namespaces?
<carlos> system.config
<carlos> system.burn
<carlos> system.open
<carlos> etc..
<carlos> robtaylor: /join #accessd
<carlos> this is offtopic here
<robtaylor> sjoerd: if your interested, you know where we'll be :)
<pitti> carlos: sudo dpkg -i language-pack-de_20050111_all.deb
<pitti> carlos: ^ this works now :-)
<pitti> carlos: I can now generate base language pack debs fully automatically
<carlos> cool
<pitti> carlos: now I'm working on the -update debs
<pitti> carlos: what's the status of rosetta?
<carlos> pitti: seems to be working again
<pitti> carlos: no, I mean the Hoary import
<carlos> pitti: today we are going to do an import of about 100 packages
<pitti> cool
<pitti> carlos: I still need some time anyway; the update debs are much trickier
<pitti> elmo: here?
<elmo> yes
<carlos> pitti: we have today a Rosetta meeting about our future goals so I think we could give you an schedule for your needs
<pitti> elmo: I'm currently thinking about how to package the language pack update debs
<pitti> elmo: would it be possible/wise to accept binary deb uploads for these?
<elmo> no?
<pitti> elmo: if only source package uploads are accepted, then I have to generate a souce package for each supported locale
<pitti> elmo: if we only upload debs, then one source package (which spits out several debs) would be enough and much easier
<pitti> elmo: ^ because only a few languages will need updating every day, not all
<elmo> hang on, what was the eventual resolution of the BOF?  
<elmo> because it sounds like we've de-evolved back to square one
<pitti> elmo: we provide language-pack-$LOCALE packages at the release time (and every now and then)
<pitti> elmo: and provide language-pack-$LOCALE-update every day
<elmo> WHAT?
<pitti> elmo: the latter packages are going to be tiny
<pitti> elmo: that was the resolution of the BOF
<pitti> elmo: that's why I want to avoid uploading new debs daily if their language did not change at that day
<Kamion> huh, I have to implement accept_types and reject_types in cdebconf and make sure the stack driver works before I can move the password questions to the first stage
<elmo> then split the source package?
* Kamion rolls up sleeves
<pitti> elmo: okay, then I don't generate the debs in the source package on the fly, but I generate the source packages itself automatically
<elmo> because, I'm not going to start randomly rewriting the debian packaging rule book to override such basics as "each binary must have an associated source package" and "when you rebuild the source package you get this (and possibly other) binary/ies"
<pitti> okay
<azeem> elmo: so just write a new one
<Mithrandir> elmo: would you care to update the override file for hoary and add gaim-data to main (it's a dependency of gaim)?
<Mithrandir> if you're getting reminders about such stuff automatically, please tell me and I'll shut up :)
<elmo> pitti: hang on, what happens to these -update packages?  are they cumulative?
<pitti> elmo: yes, relative to the latest -base package
<pitti> elmo: otherwise you would accumulate lots and lots of -update packages
<pitti> elmo: so you will only ever have the base and one -update package installed
<pitti> elmo: as soon as the -update packages get too big, we can release a new base at any time
<pitti> elmo: however, in the BOF it was believed that the updates are very small
<sabdfl> elmo, kamion: do you think we need to handle byhand uploads?
<Keybuk> is there anything byhand left?
<sabdfl> some html files we can see
<elmo> debian-installer uploads are BYHAND
<elmo> so, err, yeah, I do
<thom> lamont: ping? (in massive hope)
<sabdfl> which bits are byhand?
<elmo> sabdfl: everything that goes under installer-$ARCH?  
<sabdfl> if we will be building the cd images centrally, surely those can just be tracked directly and published by lucille?
<sabdfl> kinnison is saying that the only byhand files he sees are html files
<elmo> kinnison isn't looking very hard then
<sabdfl> ok
<elmo> BYHAND isn't used by very much, certainly, the only non-d-i thing these days is probably doc-debian ("the html files"), but the d-i case definitely needsw to be handled.. and if you want to special case it, sure
<elmo> it's not just cd image stuff, it's netboot stuff and some other stuff 
<elmo> usb stick image media etc.
<sabdfl> ok, kamion and kinnison will discuss further thursday
<Kamion> elmo: what do you think of calling it byhand-installer or something, to allow the automation to work on something other than "oh, er, yeah, this looks a bit like a d-i tarball"
<elmo> yeah, that'd be a good idea
<sabdfl> do the byhand files go into predictable places?
<elmo> sabdfl: for d-i, yes
<Kamion> depends on the byhand
<elmo> the whole point of byhand tho, is to allow people to do arbitrary things
<Kamion> basically each byhand is "ftpmaster, please do something you think might be sensible with this"; but each *instance* of byhand has its own fairly predictable rules
<sabdfl> i'm just trying to establish the set of typical rules
<Keybuk> can we have dpkg.tar.gz again? :p *ducks*
<Kamion> there aren't really any typical rules
<sabdfl> run away...
<elmo> Keybuk: I actually think we should :P, esp. if it were automated
<elmo> it was nicer than trying to explain to people about ar and tar to extract debs
<Kamion> elmo: what would happen at the moment if I did 'dpkg-distaddfile $(TARNAME) installer -' rather than 'byhand -'? I assume it'd get rejected?
* Kinnison is with Kamion on this. We should classify instances of byhand-type operations and work with those
<Kamion> at which point they aren't byhand any more so the byhand- should be removed :)
<elmo> Kamion: dunno.. feel free to try it, if they get rejected, I'll sort katie out to handle them
<sabdfl> ok, i think that's a consensus
<sabdfl> if we find an example of stuff that needs special processing, we'll figure out to handle it then
<elmo> err, well, if you're going to do that, I wouldn't call it byhand
<sabdfl> precisely ;-)
<Kamion> hm, dpkg-distaddfile documents its second argument as the section
<Kamion> so I presume there are just magic section special-cases
<elmo> yes
<Kamion> ok, I'll dive back into cdebconf then :)
<sabdfl> thanks
<Mithrandir> possibly make the section special/installer or something?
<Mithrandir> so it's actually shown that it's special and not just magic.
<sabdfl> good idea
<elmo> special's a slightly loaded term tho ;P
<elmo> non-deb/installer?  anyway, whatever, let me know what you use and i'll update katie to cope
<Keybuk> bling, crack, special ... we need a bigger dictionary
<Kamion> might as well agree it now
<sabdfl> thpecial...
<HostingGeek> anyplans on having something like gdeb in hoary that will auto download all dependces
<Mithrandir> Keybuk: pwgen? ;P
<Kamion> HostingGeek: welcome to apt
<HostingGeek> lol
<HostingGeek> Kamion: no there are some apps that people download that are in deb format that are not inside a apt rep.
<Kamion> HostingGeek: the people providing those should simply create an apt repository; it's not hard
<Kamion> failing that you can create one yourself with apt-ftparchive
<HostingGeek> yes
<HostingGeek> but n00bs that download a program like amsn from the site are going to say why the hell am i getting these errors
<Keybuk> that kind of thing scares me
<elmo> well amsn is in universe for a start
<HostingGeek> its a needed feature
<Kamion> the code to retrieve dependencies is in apt; that's where it belongs. if you want to write something that creates a small apt repository and feeds it to apt to install a given package, feel free
<Keybuk> "click here to download something and run it as root" ... "no, don't check it first"
<Kamion> no, it's really not a needed feature, that's why we have universe/multiverse :)
<Kamion> and a billion random apt repositories all over the planet
<HostingGeek> there are sites that do make debs for a program that are not in the rep
<Kamion> elmo: how about raw/installer?
<elmo> Kamion: sure
<HostingGeek> i know when i was a n00b and started learning howto program some IDIOT refered me to gambas and there was a deb on the siteand there was none in the rep till like version 0.9x
<HostingGeek> my brain is still herting from what that idiot refered me to
<Kamion> elmo: ok, I'll make the next non-urgent installer upload use that, then
<elmo> oh, wait
<elmo> that'll be broken down to component: raw, section: installer
<Kamion> raw-installer then?
<elmo> yes, please
<Kamion> would be nice to document the precise upload format expected for all known raw subtypes
<elmo> document where?
<Kamion> no idea :)
<HostingGeek> Kamion: look it will be a nice feature to have
<HostingGeek> it will make life easier
<HostingGeek> maybe the app should use apt-ftparchive to do this
<Kamion> if you're on #ubuntu-devel you are implicitly signalling a willingness to do development, so well volunteered ;)
<HostingGeek> and as a lot of people are not use to the idea of package maniger and still use to the idea that redhat and winbloze put in there head installers
<HostingGeek> this will make the deb format into a basic installer as well as be a package maniger format
<HostingGeek> Kamion: hmm maybe i will
<Kamion> it's just wrong to encourage people to download and install unsigned stuff as root, though; there's a reason we're doing signed apt repositories for hoary
<HostingGeek> dah
<HostingGeek> thats why it should use apt-ftparchive
<Kamion> errr, no, you've already downloaded an unsigned deb
<HostingGeek> no no one said that deb is unsigned
<Kamion> it is
<Kamion> signatures live at a higher layer, not in each individual package
<HostingGeek> Kamion: well the deb on amsn site and in the rep are the same deb
<Kamion> I rather doubt that, we rebuild all packages from source
<HostingGeek> Kamion: why not in each package
<Kamion> it cannot possibly be bitwise-identical unless they took the deb from us (which seems unlikely)
<HostingGeek> i see i misunderstood this apt 0.6 feature
* Kamion doesn't really feel like rehashing the 2000-message discussion about package signing
<HostingGeek> so who will the end user install a app from somewhere like... mallarat
<HostingGeek> *typo*
<Kamion> third-party repository administrators should just sign their repositories. it's not hard.
<mvo_> not hard at all :)
<HostingGeek> Kamion: btw can we include more apps in universe
<Kamion> (then you have trust path issues etc., but at least it's *possible*)
* pitti discovers http://www.eta.immi.gov.au/
<HostingGeek> Kamion: well they don't as debian isn't using apt 0.6 yet
<thom> pitti: yeah, ETA is goodness
<Kamion> universe> that's sort of what universe is for
<Kamion> HostingGeek: you can verify repository signatures without apt 0.6; apt 0.6 just makes it more convenient
<HostingGeek> Kamion: there is about 50 apps or so all of us want that are in unoffical reps like nvu
<pitti> thom: I still need to get a passport, but good to know that at least the visa is a near non-issue
* Kamion disbelieves "all of us"
<HostingGeek> Kamion: intresting
<Kamion> in any case this still doesn't belong on #ubuntu-devel without code to back it up :)
<HostingGeek> while(HostingGeek talk() Kamion answer == 1)
<HostingGeek> is that good enough?
<HostingGeek> if i find a deb for nvu can you guys test it out and include it in universe?
<amu> moins 
<fabbione> Kamion: does udeb support bzip2?
<fabbione> the format i mean...
<Mithrandir> fabbione: no
<fabbione> ok
<Mithrandir> at least, it didn't some time ago, and I'm not sure we want it to.
<Kamion> hasn't been added AFAIK
<elmo> yeah, I thought bzip2 support was meant to be limited to things like doc packages  where it's an obvious win?
<fabbione> it's ok... i am testing the kernel build using bzip2, but udebs are created in a separate target
<Kamion> well ... a lot of the bloat in .udebs does come from stonking templates files
<fabbione> elmo: i am just doing a test on mdz request
<Kamion> most of that's outside the initrd though, which is where it really matters; the bulk of the initrd is modules
<fabbione> all header files should be a gain
<Kamion>         snprintf(buf, sizeof(buf), "ar -p %s data.tar.gz|tar -xzf -", pkg->file);
<Kamion> that's hardwired
<elmo> mdz needs to be forced to use less than fast-as-heck computers for a while
<Mithrandir> elmo: heh :)
<fabbione> elmo: it's not like i disagree with you :-)
<Keybuk> oh, man; shouldn't read people's quote files and get ideas
<Keybuk> doogie piping apt output through chef ... ROSETTA HERE I COME!
<Mithrandir> d3vic3: I asked you to read through the patch before sending it to me -- I'm not interested in your .arch-ids and such. :P
<fabbione> daniels: you around?
<d3vic3> erm 
<d3vic3> I did 
<d3vic3> read it 
<d3vic3> Mithrandir, sorry I missed the .arch-ids 
<Mithrandir> d3vic3: why are you build-depending on module-assistant?
<Keybuk> Kamion: clearly, !arch should be #!/usr/bin/dpkg
<d3vic3> I'm not 
<fabbione> Mithrandir: that's for the kernel module i think
<Mithrandir> d3vic3: you patch shows me that it has changed in the diff you sent me.
<fabbione> the cloop-stuff is kinda.. hmmm intersting..
<d3vic3> I just fixed a bug on that package 
<Mithrandir> d3vic3: http://err.no/~tfheen/cloop.diff is the cleaned-up patch I got.
<Mithrandir> part of that sillyness (patching config.log and makefile) isn't your fault.
<d3vic3> theres a lesson to be learned here issin't there 
<sabdfl> HostingGeek: yes
<Mithrandir> d3vic3: yes, make readable patches, so you don't get questions like "why did you do $foo" and you think you didn't, but the patch shows you did. :)
<Mithrandir> d3vic3: no worries, I'll just remove that part of the patch before testing.
<d3vic3> erm 
<d3vic3> ok 
<sabdfl> HostingGeek: please work with elmo to get it into universe, and if you'd like to maintain it so much the better
<HostingGeek> sabdfl: haha this is easy so i guess nvu will be in universe in a few days
<sabdfl> cool
<HostingGeek> i got one for 0.60
<HostingGeek> i found using google
<HostingGeek> but 0.70 is out.....
<Kamion> Keybuk: heh
<bob2> probably best to coordinate with whoever ITP'd it for Debian, too
<Treenaks> HostingGeek: rebuilding a package for a new version is easy
<HostingGeek> why can't debian fire the nvu package maniger if he can't do it in 183+ days then he shouldn't take the jobs lots of other have been abled to
<Keybuk> HostingGeek: an ITP isn't a lock
<bob2> HostingGeek: erm, maybe you should email him/her and ask if you can help?
<Keybuk> it's just an announcement that they're working on one
<HostingGeek> bob2: i have emailed him to ask what taking so long but no answer
<bob2> HostingGeek: did you CC the ITP bug?
<Treenaks> Keybuk: it's an advisory lock :)
<Keybuk> HostingGeek: then I'd reassign the ITP to yourself and package it
<HostingGeek> bob2: cc?
<thom> on the email to the maintainer
<HostingGeek> # nvu
<HostingGeek> deb http://www.linuxbh.org/naarea/ pacotes/
<HostingGeek> that rep apparently has nvu
<HostingGeek> i have not tested it
<HostingGeek> and i get a 403 from http://www.linuxbh.org/naarea/
<Keybuk> it only has binary .debs on it though, at a glance
<Keybuk> obviously anything in universe is built on our autobuilder network, so it's the source package we'd need
<HostingGeek> Keybuk: nvu is GPL
<HostingGeek> we can force the code from him
<Keybuk> I wouldn't be surprised if he threw it away
<azeem> HostingGeek: did you ever package a .deb?
<Keybuk> he has a "written offer" from linspire, so can just point you at their website if he's not changed anything
<HostingGeek> azeem: yes and ask bob2 about it
<bob2> you made a package? of what?
<HostingGeek> bob2: you remeber my port of gaim 1 to warty and xchat 2.4
<Kamion> since you keep changing nicks I'd imagine it's hard for anyone to remember
<bob2> you didn't make packages
<bob2> you ran 'apt-get source -b xchat' on warty against hoary's source repository
<HostingGeek> bob2: no i didn't
<HostingGeek> hoary wasn't open yet
<bob2> that's what you told me at the time
<bob2> or sid then
<Keybuk> to clarify, what we need for ubuntu is the .orig.tar.gz (probably just a renamed upstream tarball), a .diff.gz containing the debian/ directory with all the control files in and any patches to make nvu comply with Debian policy and the .dsc file that goes along with both
<bob2> HostingGeek: assuming you're GMAIL aka GNU-DEBIAN aka shimun aka shimon
<HostingGeek> you said it will be 2 week till hoary merges
<HostingGeek> i was never shimun
<HostingGeek> and you forgot Ubuntu-linux
<bob2> it'd be really great if you could stop changing nicks, too
<azeem> or have a real name
<elmo> azeem: yeah, Ben
<azeem> shuddup
<HostingGeek> shimon is my real name
<Keybuk> what's worse is I have to think to remember azeem's real name
<HostingGeek> but now someone called jamse has the nick
<Keybuk> while Ben is foremost in my mind
* azeem glares at elmo
<sivang> HostingGeek: where are you from?
<HostingGeek> australia
<HostingGeek> now is this ontopic
<sivang> HostingGeek: you have a rather, hebrew sounding name :) (much like mines:)
<plovs> jdub which of these is current: http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule and http://www.ubuntulinux.org/wiki/HoaryHedgehogReleaseSchedule
<HostingGeek> sivang: of couse i do
<HostingGeek> because it is
<sivang> HostingGeek: :)
<HostingGeek> now well do people say what i say is offtopic?
<HostingGeek> *why
<bob2> because you tend to ramble and paste odd things while people are having technical discussions
<tseng> HostingGeek: because the channel is mostly about the developers working while we politely watch or try to help out where we can
<bob2> and make assertions, insist they are true, and then go silent when proven false
<ogra_> plovs: i think its the second one....iirc they postponed the schedule a week
<sivang> bob2: hehe, mostly :)
<smurfix> Seems HoaryReleaseSchedule is the outdated one
<ogra_> hmm, but the editing date suggests something else, strange
<smurfix> Bah, the other way round, sorry
<plovs> ogra_: ok, i'll delete the first one and blame you :-) thanks!
<ogra_> plovs....wait :)
<Mithrandir> d3vic3: ta, seems to work.
* smurfix hides in a corner
<plovs> ogra_: don't worry, i haven't done anything yet
<HostingGeek> bob2: do not get unwired! i am getting 5kb/s sence there new stupid policy that reseller only get a connection rate of 25:1  that is no where enough with such a leet isp
<ogra_> plovs i'm not quite sure about that, i just remember there was a discussion to postpone (which would match the second one), but the editing date of the first one is more current
<bob2> HostingGeek: I have no idea what you're talking about, it seems unrelated to every one of the 5 conversations we've had tonight
<HostingGeek> okok i guess your not up to date with 1 year old news in sydney
<plovs> ogra_: yes, i noticed ... weird, i'll wait until jdub wakes up
<ogra_> plovs: yep, probably the best to do here :)
<d3vic3> Mithrandir, thanx 
<d3vic3> can I have that file back ? 
<Mithrandir> http://err.no/~tfheen/cloop.diff ; you just want to apply the first patch; the rest are there because you diffed against an unclean tree.
<d3vic3> ok
<Mithrandir> and then you add a changelog entry to debian/changelog (use dch -i), build using debuild -S and upload.
<Mithrandir> (you're in the keyring, aren't you?)
<HostingGeek> i got nvu 0.50 debs here
<Nafallo> thom: there?
<HostingGeek> plus 0.41
<d3vic3> keyring ? 
<d3vic3> i have my key signed 
<Mithrandir> d3vic3: the ubuntu keyring, so you can upload.
<d3vic3> and uploaded to subkey server
<Kamion> I don't remember the community council approving Charles, so I don't think he is
<d3vic3> yes 
<Mithrandir> Kamion: ok.
<Mithrandir> d3vic3: I can upload the fix for you, then, if you want.
<Kamion> (yet)
<d3vic3> Mithrandir, yes, but can you tell me how ? 
<HostingGeek> and i also have gambas 1 gtk (OMG GTK+) debs
<Mithrandir> d3vic3: make sure you start from pristine source, then apply the patch.  Write an appropriate changelog entry (where you make sure to note the bug# of the bug you have fixed) and build the package using debuild -S.  Since you don't have anywhere to put it online, just mail me the .dsc and the .diff.gz
<Mithrandir> and please, please, please read through the diff to make sure you don't have anything there which you shouldn't and the other way around.
<thom> Nafallo: yes
<HostingGeek> and source packages
<HostingGeek> we have biuness
<Nafallo> thom: exactly what is done to the latest powernowd (Version: 0.90-1ubuntu7). I can't get my patch to work anymore :-P.
<HostingGeek> ok nvu 0.5
<thom> Nafallo: what patch?
<HostingGeek> gambas using GTK+
<HostingGeek> ...
<HostingGeek> lots of cool stuff
<Nafallo> thom: the one on #5256 :-)
<thom> Nafallo: uh, the latest upload is -5, anyway
<thom> oh, i used the latest cpufreq-detect script, so your patch will need to be applied manually and rediffed *shrug*
<Nafallo> thom: ops, my bad. I should learn that dpkg -l is better than apt-cache show ;-)
<HostingGeek> elmo: are you here?
<elmo> HostingGeek: yes
<HostingGeek> i am working with you right? to get them in universe and maybe into main?
<elmo> HostingGeek: did you read what keybuk wrote about what we need?
<HostingGeek> yes
<HostingGeek> and we have them
<HostingGeek> this is the rep http://www.linex.org/sources/linex/debian/
<HostingGeek> deb http://www.linex.org/sources/linex/debian/ sarge linex
<HostingGeek> *deb-src
<Nafallo> thom: I need to make more changes than add "[Mm] obile\ AMD\ Athlon*\ 64\ Processor*)" in there?
<Treenaks> Athlonnnnn and athlo and processo and procesorrr are valid?
<Keybuk> those are 0.50 ?
<Treenaks> uh all capitalized, of course
<fabbione> Keybuk: dpkg --build -Zbzip2 debian/tmp-headers ..
<thom> Treenaks: it's more Processor 2800+ v Processor 3200+
<fabbione> dpkg: unknown option -Z
<HostingGeek> elmo: so what better a binary 0.6 nvu deb or a source of 0.5
<elmo> HostingGeek: binaries are not an option
<Treenaks> thom: oh it's not regex..
<Nafallo> Treenaks: and Athlon vs Athlon(tm)
<Keybuk> fabbione: use dpkg-deb :)
<HostingGeek> elmo: but can't you get some of the stuff you need out of them?
* Treenaks has been regexing too much
<Keybuk> HostingGeek: nope, there's nothing useful in a binary
<fabbione> Keybuk: i love you...
<HostingGeek> Treenaks: want a laugh? look at my /proc/cpuinfo on my server? answer yes if you want to see
<Treenaks> Keybuk: and you maintain libtool?
<thom> Treenaks: which is shell...
<HostingGeek> Keybuk: but can't you decode the 0101's into source slowly?
<Treenaks> thom: yeah I noticed
<Keybuk> Treenaks: yeah, your point? :p
<Keybuk> fabbione: should be as easy as replacing "dpkg --build" with "dpkg-deb --build"
<Keybuk> except dpkg-deb actually has useful options
<fabbione> Keybuk: btw -Z is not documented in dpkg-deb man page...
<Keybuk> fabbione: I don't want people to use it (in Debian) yet
<Nafallo> thom: do I need to do something more than edit and run that cpufreq-detect.sh?
<thom> no
<Keybuk> +++ nvu-0.50/nvu
<Keybuk> @@ -0,0 +1,6 @@
<Keybuk> +#!/bin/sh
<Keybuk> +nvuviejo=`grep -r 0.5 $HOME/.nvu/*|grep useragent`
<Keybuk> +if [  -z "$nvuviejo" ] ; then
<Keybuk> +	rm -Rf $HOME/.nvu
<Keybuk> +fi
<Keybuk> +/usr/lib/nvu/nvu
<Nafallo> thom: then I can't see why it doesn't work :-/.
<Keybuk> *gulp*
<thom> aiiiie
<thom> Nafallo: do you get any error output?
<Nafallo> thom: just the NONE info :-/.
<thom> sladen: PING!
<fabbione> ok
<fabbione> Keybuk: ok
<HostingGeek> elmo: so this rep is any good? or more looking for one with source?
<HostingGeek> btw its a big upgrade from 0.6 to 0.7 as they swap to firefox at the core
<Keybuk> HostingGeek: are you content with 0.5 ?
<HostingGeek> ?
<Keybuk> the linex repository has nvu 0.50 in it
<HostingGeek> what contant?
<HostingGeek> yes thats what i said
<Keybuk> so are you happy with that?
<HostingGeek> it has the source packages too
<Kamion> HostingGeek: source is a *requirement*, not at all optional
<Keybuk> yes, of 0.50
<HostingGeek> Kamion: yes and it has them
<Keybuk> you speak English, right? :)
<Kamion> 13:47 < HostingGeek> elmo: so this rep is any good? or more looking for one with source?
<Kamion> replying to that
<HostingGeek> arghh let me reword that
<HostingGeek> elmo: so is this rep any good (as in is its source package crap or not)? or should i look for another rep with source packages
<HostingGeek> btw thank google
<elmo> HostingGeek: dude, how about you have a look at the source packages, and you tell me if you think they're any good or not?
<HostingGeek> elmo: hey i am not good at this stuff i an a n00b to it accully
<Keybuk> HostingGeek: are you aware that 0.50 looks nothing like the screenshots on their site?
<HostingGeek> yes
<HostingGeek> OMG my system crashing 
<HostingGeek> my cpu is too hot i might shutdown any second
<Keybuk> to me, the source package looks crack
<Keybuk> it contains the entire moz codebase, rather than just build-depping on it
<thom> Keybuk: that's probably right
<HostingGeek> well 0.7 contain all of firefox
<Keybuk> clearly this is a job for our firefox maintainer ... :p
<Keybuk> dpkg-source: error: file nvu_0.50.orig.tar.gz has size 4325376 instead of expected 11480572
<Keybuk> heh
<Keybuk> the tarball doesn't match the dsc
<thom> fuck. right. off
<elmo> tsk, I think thom needs to go back to those anger management classes
<thom> :-)
<Keybuk> "DEALING WITH THE CYLONE.  12 Steps."
<thom> Keybuk: Step 1, be on board the battlestar galactica when they attack?
* Kamion groans
<thom> it's not my fault you typoed Cyclone :-)
<Keybuk> haven't been able to type all day today
<carlos> pitti: dude, you should use autoconf/automake with pmount :-P
<pitti> carlos: what for?
<pitti> carlos: I hate this stuff
<carlos> pitti: why?
<pitti> carlos: it is big, various autoconf/automake versions are incompatible, it blows up the build system and makes it non-obvious
<pitti> carlos: also it uses recursive makefiles (which is a bad habit)
<Hosting-Geek_> OMG
<azeem> pitti: you can depend on one version
<pitti> carlos: and it is much too heavy for such a small package like pmount
<Hosting-Geek_> it chant be happening my system crashed
<Hosting-Geek_> someone send me logs
<carlos> pitti: in theory it's more portable
<pitti> azeem, carlos: why _should_ I use autofoo for compiling 4 c files?
<Keybuk> logs
<azeem> pitti: dunno whether there are any porting issues with pmount. If there are none, it might not be worthwhile, *shrug*
<pitti> what is not portable with
<pitti> pmount: $(pmount_OBJ)
<pitti>         $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
<Keybuk> pitti: what's amusing is that everything you just said there is wrong <g>
<azeem> I was talking about the code, not the Makefile
<pitti> Keybuk: what is wrong?
<Keybuk> <pitti> carlos: it is big, various autoconf/automake versions are incompatible, it blows up the build system and makes it non-obvious
<Keybuk> <pitti> carlos: also it uses recursive makefiles (which is a bad habit)
<pitti> Keybuk: did you never ever have the problem of wanting to autoreconf and failed?
<Kamion> it clearly is much bigger than not using it
<pitti> Keybuk: this has happened so often to me that I learned to hate it
<Keybuk> pitti: sometimes, I fixed the bugs
<pitti> Keybuk: and it _is_ big, compared to an 2K makefile, you can't say that I'm wrong about that
<Keybuk> well, true
<Keybuk> I can't fault you there
<Keybuk> the generated Makefile is bigger than 2k, but also rather more useful
<Keybuk> the source (that you edit) is rather smaller though
<pitti> Keybuk: recursive Makefiles can trash your build if you are not careful
<pitti> Keybuk: of course that is not a problem with a project the size of pmount
<Keybuk> pitti: what's automake got to do with recursive Makefiles ?
<Kamion> if you don't need a wheel, there's no point borrowing a spare one just because it's circular :)
* pitti always saw recursive Makefiles with autofoo
<Treenaks> sivang: you have weird hostmasks :)
<sivang> Treenaks: I know :-)
<pitti> Keybuk: is there any way to avoid it with autofoo?
<Keybuk> pitti: so?  I've always seen recursive Makefiles for every single project, even those that don't use automake
<Keybuk> pitti: yeah.  Don't put a Makefile.am in every directory
<Kamion> ("do people want fire that can be inserted nasally?")
<lamont> thom: ack
<thom> ahah
<pitti> Keybuk: but don't you loose all the magic if you don't?
<Keybuk> pitti: what magic?
<Keybuk> automake's just a script that adds pre-defined rules based on Makefile variables you put in a source file
<azeem> Keybuk: black magic
<thom> lamont: i take it your recommended way of mixing forwards and mailboxes in postfix virtual hosting is multiple domains?
<pitti> Keybuk: okay, if that's possible and does not make the job harder, then I withdraw that argument
<Keybuk> bin_PROGRAMS = pmount
<Keybuk> pmount_SOURCES = src/pmount.c src/policy.c
<pitti> Keybuk: it's just that I never saw a single makefile with a multi-dir project
<Keybuk> pmount_LDADD = lib/libmount.a
<Keybuk> or whatever
<pitti> Keybuk: (using autofoo)
<lamont> thom: that's probably the cleanest way
<Keybuk> pitti: I've seen about as many as I've seen without automake
<lamont> it can be done the other way, but it's not as pretty
<Keybuk> maybe 3 or 4
<HostingGeek> Keybuk: elmo: are the source packages any good?
<Keybuk> HostingGeek: no.
<HostingGeek> Keybuk: why?
<lamont> Kamion: so I gather that another rootfs is in order?
<pitti> Keybuk: so again, is there any reason why the current Makefile is worse than an automake'd one?
<HostingGeek> its better than the current way of installing nvu
<Keybuk> HostingGeek: for a start, the tarball on that URL doesn't match the md5sum or size specified in the .dsc
<pitti> Keybuk: if there is, then I'm willing to learn
<lamont> Kamion: fabbione: looks like 2.6.10-5 is the most recent kernel?
<Keybuk> pitti: not especially
<pitti> Keybuk: it's just that the current one does what it should, is small and don't cause problems
<HostingGeek> Keybuk: well it can be fixed
<fabbione> lamont: it is. i have -6 on the way soon.
<fabbione> lamont: but -5 is lacking the hppa patch (mdz missed it this night)
<HostingGeek> and Keybuk its better than a 0.41
* lamont plans to disappear for about another hour.
<Keybuk> HostingGeek: dude, that's a total problem.  That.  Source.  Package.  Is.  Unsafe.
<Nafallo> thom: shouldn't powernow-k8.ko be in /lib/modules/2.6.10-1-amd64-k8/kernel/drivers/cpufreq?
<Keybuk> pitti: it was carlos suggesting you autofoo it, not me :p
* sivang away food
<pitti> carlos: again, so why did you propose to use autofoo?
<pitti> carlos: does it make Rosetta imports easier? :-)
* carlos in meting
<Keybuk> about the only advantage would be that you'd get "make dist", but I'm sure you don't care about that given the size of package
<HostingGeek> Keybuk: ok we will remove the rm -rf /* code but the rest is safe
<Keybuk> HostingGeek: you're not listening to a single word I say, clearly
<lamont> thom: the two solutions are (1) complete virtual map (has naked domain on LHS) that maps everything to some other domain(s), one or more of which are delivered to some vda/imap/whatever, and (2) partial virtual map (no naked domain on LHS) with a transport map that delivers said domain (if not rewritten) to some vda/imap/whatever
<Nafallo> thom: find gives me kernel/arch/x86_64/kernel/cpufreq/powernow-k8.ko
<HostingGeek> Keybuk: but its easier to make the package safe than making our own
<fabbione> Nafallo: and what is the problem with that?
<Keybuk> HostingGeek: Read What I Said.
<Kamion> lamont: yeah
<HostingGeek>  That.  Source.  Package.  Is.  Unsafe.
<Nafallo> fabbione: probably just chasing ghosts while trying to make powernowd load the right stuff.
<Keybuk> HostingGeek: and why did I say it was unsafe?
<HostingGeek> yes now just remove the un and it will become safe
<Nafallo> fabbione: I was expecting to find all cpufreq-stuff in one place :-)
<HostingGeek> its possible to make something unsafe, safe
<lamont> Kamion: now, or after -6?
<fabbione> Nafallo: a call to modprobe doesn't imply a path, so that it is bogus and the kernel is allowed to put stuff around. it doesn't matter at the end where it is
<Keybuk> HostingGeek: ok, now listen carefully
<Keybuk> A Debian source package consists of three files.
<Keybuk> 1) A tarball containing the source code
<HostingGeek> i know
<Keybuk> 2) A patch adding Debian-specific magic
<Kamion> lamont: don't really mind personally, depends whether mdz wants amd64
<Keybuk> 3) A file describing it, and (here's the clever bit), the size and a checksum for the other two
<Kamion> lamont: if amd64's wanted now then we need a new build now; if it's not urgent then we can wait
<lamont> Kamion: I can run one now, or just before the meeting at 1600Z
<Nafallo> fabbione: oki. loading it didn't help the damn script either :-P.
<Kamion> lamont: go for it now, I guess, it's cheap right? :)
<Keybuk> the size and checksum listed in the description file for the tarball with the source in _does_not_match_ the size and checksum of the tarball alongside it on that site
* Nafallo goes back to dig through the damn script *
<Keybuk> from this you can infer a great many things
<fabbione> lamont, Kamion: -6 will push new packages with an ABI change and mostlikely to break other stuff like linux-meta and l-r-m. THat's probably why mdz wants everything done before my upload
<Keybuk> I choose to infer that somebody has compromised that FTP site and replaced the tarball with one that exploits some new problem in tar, and will wipe my system if I unpack it
<thom> lamont: nod, thanks
<fabbione> and i have no rush to upload -6
* Mithrandir kicks self.
<Mithrandir> I suck.
<Keybuk> this may, or may not be true
<Keybuk> either way, that is not the tarball that was originally uploaded
<HostingGeek> email linex about it
<Keybuk> I have no reason to
<Kamion> HostingGeek: you're the one pushing for it, you should take responsibility
<Keybuk> feel free to do so yourself
<Nafallo> Mithrandir: what's the status of those torrents? seems I got only one down while sleeping.
<HostingGeek> Kamion: i do not speak spanish
<Mithrandir> Nafallo: right, I don't have the sources for the rest of them, yet. :/
<HostingGeek> anyone here speak spanish?
<fabbione> mdz: you awake yet?
<Keybuk> I'm sure the Linex guys are perfectly capable of understanding English
<Nafallo> Mithrandir: yikes, I thought you had them coming with ftp?
<Keybuk> probably better than you
<Mithrandir> Nafallo: yes, and that sftp I'm getting them over is sloooooow.
<Nafallo> Mithrandir: hehe, oki. I thought my line was slow ;-).
<Mithrandir> Nafallo: it's not my line which is slow, it's the other's
<lamont> Kamion: new livecd fs builds on all 4 architectures, although ia64 is known to gonna-die
<HostingGeek> Keybuk: why would they know spanish?
<Keybuk> you don't live in Canberra by any chance, do you?
<HostingGeek> no hell no i want to stay as far away from a 5 city state
<Keybuk> really?  you surprise me
<HostingGeek> sydney mate
<HostingGeek> ok whats the linex email
<lamont> Mithrandir: any clue on what's borked in libsdl1.2?
<lamont> (on amd64 only...)
<Mithrandir> lamont: ew.
<Mithrandir> that one just looks mean
<Mithrandir> looks like a gcc bug at first sight.
<Keybuk> damn, bubulle woke up and mirrored the missing patch
<Keybuk> I have no excuse not to release 1.10.26 now
<lamont>   ubuntu-desktop: Depends: gaim but it is not going to be installed
<lamont>                   Depends: totem-gstreamer but it is not going to be installed
<lamont> E: Broken packages
<lamont> Kamion: bummer
<Mithrandir> lamont: I've broken gaim, mea culpa.
<lamont> Mithrandir: can you fix it quick?
<Mithrandir> yeah, working on it right now.
<Treenaks> Mithrandir: but basically you only have one file to seed right now?
<Mithrandir> Treenaks: correct.
<Mithrandir> Treenaks: I have about a third of mshuttleworth_small.avi as well
<lamont> Kamion: fabbione: I'll try another livecd in a bit, then.
<lamont> although I wonder what's up with gstreamer as well..
<Treenaks> Mithrandir: OK.. can I start using the torrents and wait for you to start seeding?
<Mithrandir> Treenaks: sure
<Treenaks> OK :)
<HostingGeek> Mithrandir: nice one so i shouldn't do an upgrade just yet as i was about to?
<lamont> doko: could it be that we need a new something? locale: error while loading shared libraries: libunwind.so.7: cannot open shared object file: No such file or directory
<Mithrandir> HostingGeek: it won't let you, I imagine
<lamont> ah, gstreamer: totem-gstreamer: Depends: libnautilus-burn0 (>= 2.8.3) but it is not installable
<HostingGeek> Mithrandir: couldn't you delete a file out of the rep if it only been there for a few min and then renumber the old verion up one
<lamont> seb128: does a simple rebuild of totem-gstreamer work?
<Mithrandir> HostingGeek: no, that's not how it's done.
<seb128> should
<seb128> lamont: but 0.100 is in the archive, which one is failing ?
<Kamion> HostingGeek: (a) no, he can't, (b) even if he could, he wouldn't, because it leads to more confusion in the long run if people had downloaded the package in that interval
<lamont> 0.100-0ubuntu1 was built against old nautilus
<Nafallo> Mithrandir: you are 200x faster than me both up and down, so that wasn't pointed at you ;-).
<seb128> hum ok
<lamont> bumped the build-dep to libnautilus-burn-dev (>= 2.9.4), uploading -ubunut2
<seb128> nooo
<lamont> seb128: ok.  no upload
<seb128> PKG_CHECK_MODULES(NAUTILUS_BURN, libnautilus-burn < 2.9.0,,
<seb128>                 AC_MSG_ERROR(libnautilus-burn < 2.9.0 is needed))
<seb128> in totem
<seb128> it was meant to build with 2.8.6
<lamont> seb128: could you fix it so it's installable again?
<seb128> not atm
<lamont> libnautilus-burn0 is no longer in the archive
<seb128> need some upstream work to be compatible with the new libnautilus-burn1
<Mithrandir> lamont: ok, new gaim uploaded.
<seb128> that's on my todo list, but I've still 9 tarballs from 2.9.4 to package ... it'll take some time
<Mithrandir> now I need to fix cloop-utils for d3vic3 
<lamont> Mithrandir: and me...
<seb128> lamont: don't bother with GNOME ftbfs for today and yesterday, there is bunch of problem, I'll solve them when all the 2.9.4 tarballs are packaged
<Mithrandir> lamont: yeah, but Charles is the one who produced a patch
<lamont> seb128: the other option is that I manually drop it from the Depends: in ubuntu-desktop, so that we can have a livecd to test...
<Kamion> ugh
<seb128> lamont: let me 15min to try to fix it first
<seb128> just pinging upstream side
<lamont> seb128: OK.  I'll go ahead and disappear for a bit, then check with you and do one or the other.
<seb128> ok
<lamont> ideally, an upload within the next 15 minutes would be great.
<lamont> (before :00)
<seb128> will try, but that's probably a bit short to find a fix, patch, try and upload
<lamont> np.
<Nafallo> thom: is it just me or those this have some significant effect on those amd CPUs ;-); case "$VENDOR_ID" in<br>GenuineIntel*)
<Mithrandir> d3vic3: you _really_ need to be on hoary -- the patch I got is against the previous version of cloop.
<lamont> seb128: yeah, I expect so.
* lamont wanders off for a bit.
<d3vic3> Mithrandir, ok, but the bandwidth here is a bit slow 
<Mithrandir> d3vic3: I'll just handle it now, but at least point your deb-src lines to hoary
<d3vic3> ok
* mode/#ubuntu-devel [+o thom]  by ChanServ
* mode/#ubuntu-devel [-o thom]  by thom
* mode/#ubuntu-devel [+o thom]  by ChanServ
* mode/#ubuntu-devel [+o Keybuk]  by thom
<crimsun> seb128: / lamont: thanks for the excellent 'strict' mode for metacity :)
* mode/#ubuntu-devel [+b *!*HostingGe@*.exetel.com.au]  by Keybuk
<thom> Nafallo: heh
<seb128> that's lamont's work, I've only included the patch :)
<crimsun> seb128: aye
* HostingGeek was kicked off #ubuntu-devel by Keybuk (Please ask questions on #ubuntu, where more people are able to help.)
<Mithrandir> d3vic3: also, usually make sure your uploads are pointed to hoary, not unstable.
<Mithrandir> d3vic3: uploaded now.
<Mithrandir> d3vic3: so you can then close the bug.
<fabbione> hmmmm i have a problem with distcc....
<fabbione> distcc[10739]  Warning: failed to distribute /usr/src/.ccache/earlyquirk.tmp.gordian.10681.i to gundam.int.fabbione.net, running locally instead
<Mithrandir> lamont: what's the missing magic which needs to happen for mono to work?
<fabbione> and there is a distccd running on gundam with the proper ALLOWEDNETS stuff...
<fabbione> distcc[10739]  (dcc_pump_sendfile) ERROR: sendfile failed: Connection reset by peer
<fabbione> any idea of what could be the problem?
<Mithrandir> thom: what do you use for generating the list for readahead?
<thom> Mithrandir: strace and ldd
* mode/#ubuntu-devel [-b+q *!*HostingGe@*.exetel.com.au *!*HostingGe@*.exetel.com.au]  by Keybuk
<Mithrandir> thom: ok.  That sucks, really.  IMHO, at least.  Can't one ask the kernel to start collecting a list of files it's opening and then later collect said list?
<thom> there is a patch that get the kernel to punt everything it opens to klog
<Mithrandir> do you have a reference for that?
<thom> Mithrandir: the patch is in the kernel source rpms in fedora
<thom> http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01374.html for a bit of info
<seb128> lamont: totem cvs snapshot in upload, build with libnautilus-... > 2.9
* mode/#ubuntu-devel [-o Keybuk]  by Keybuk
<Nafallo> thom: I should sign a bug with the new patch and assign it to you?
<thom> no, i've fixed it already
<Nafallo> thom: *s* New upload? It's rather grave to screw all AMDs out there ;-).
<thom> my P-M works alright, so who cares? ;-)
<Nafallo> thom: don't forget to add [Mm] Mobile AMD Athlon* 64 in that case :-)
<thom> it's already there
<Nafallo> :-)
<thom> Nafallo: can you grab http://people.ubuntu.com/~thom/cpufreq-detect.sh and run it
<Nafallo> thom: powernow-k8 :-)
<thom> sounds reasonable to me
<Nafallo> thom: why do we have * after VENDOR_ID?
<thom> to allow for the possibility of spaces and so on
<Nafallo> thom: oki, agreed. but (tm) should be * :-)
<carlos> pitti: it was just a curiosity, I just downloaded the source to see how the .pot file is named, that's all
<pitti> carlos: ah, ok
<thom> Nafallo: no.
<Nafallo> thom: if you say so...
<lamont> Mithrandir: dunno --> thom
<Kamion> $ ../debconf test.config
<Kamion> Trace/breakpoint trap
<Kamion> aargh
<lamont> seb128: thanks
<Kamion> I will personally worship anyone who ports valgrind to powerpc
<thom> Mithrandir: looking at that now
<seb128> np
<mdz> fabbione: here
<mdz> Kamion: I would very much like amd64; what's wrong with it?
<Mithrandir> Kamion: use qemu and run it in i386 mode?
<lamont> mdz: ubuntu-desktop uninstallable, should be fixed at :03
<seb128> Kamion: there is a patch for valgrind/powerpc IIRC
<mdz> Kamion: ah, udeb/livefs mismatch
<Kamion> mdz: built with -5 kernel udebs and -4 in the livefs
<fabbione> mdz: building the kernel with bzip2 we save almost nothing
<Kamion> seb128: really?
<mdz> fabbione: really?  I'm surprised, but thanks for testing
<seb128> yeah, some GNOME dude use valgrind on ppc
<Kamion> Mithrandir: I'd have to rebuild the binary I'm valgrinding anyway, so that wouldn't really save much
<fabbione> mdz: approx 9MB for all the i386 of which an average of 1.6/1.8 on the images and we lose on doc and other stuff
<Kamion> awesome
<mdz> fabbione: _lose_ on documentation?
<fabbione> mdz: yesyes
<fabbione> ehm yes
<Kamion> sigh, all the sites with the valgrind/powerpc tarball are down
<fabbione> approx 400K
<cartman> there is always a source tarball on http://valgrind.kde.org
<lamont> seb128: new totem built and uploaded on all 4
<lamont> thank you
<seb128> np
<Kamion> cartman: not for powerpc, as far as I can see; would like to be corrected if I'm wrong
<lamont> Kamion: I assume you just want to know when all 3 fs's are ready, yes?
<Kamion> lamont: yes
<cartman> Kamion: source tarball should compile everywhere afaik. if not its a bug
<Kamion> cartman: er, not in the slightest
<Kamion> cartman: porting valgrind is not even a little bit trivial
<cartman> Kamion: ah its not ported?
<cartman> I thought it was ported hence it should compile
<Kamion> cartman: it emulates an i386 processor; to make it useful on powerpc, you have to make it emulate a powerpc processor
<Kamion> cartman: this is not exactly a "just works" thing
<cartman> Kamion: yes I know but didn't know it wasn't working on powerpc
<Kamion> it is not
<cartman> I know Solaris is not supported
<Kamion> most systems are not supported
<mjt> valgrind is especially for i386
<mjt> NAME
<mjt>        valgrind - a memory debugger for x86-linux
<Kamion> it only supports i386/Linux right now
<mjt> there's alot of stuff in it that's x86-linux-specific
<Kamion> yes, there's an experimental port to powerpc which seb128 alerted me to though, and I was trying to get the tarball for that
<lamont> meeting in 2
<stratus> Is gaim 1.1.1-2ubuntu3 w/o documentation or what? Please, look at /usr/share/doc/gaim :)
<Simira> ah, that's right... thanks for reminding me, lamont.
<stratus> Anyone eat my gaim changelog :(
<cartman> Kamion: ok, sorry for confusion
<mdz> lamont: can you confirm cloop-utils 2.01.5-2ubuntu2 on amd64
<Mithrandir> mdz: it worked on my amd64 test box.
<lamont> is in the archive, will freshen the chroot
<sivang> garnacho: erghh.. I have some kind /join #ubuntu-meeting
<sivang> oooooooooops
<lamont> mdz: hack fix now gone
<mdz> Mithrandir: oh, he asked you to test it?
<Mithrandir> mdz: no, but I sponsored Charles' upload.
<mdz> Mithrandir: I see, thanks
<mdz> Mithrandir: the fix wasn't exactly what I expected...did you review it?
<mdz> it casts an unsigned long to an unsigned int
<Mithrandir> that should be safe.
<Mithrandir> AIUI
<mdz> which, while the values we're dealing with tend to be only about 2^16, loses precision
<Mithrandir> that's true.
<Mithrandir> what is the procedure for unreproducible bugs where the submitter doesn't answer?
<Mithrandir> (for about four weeks, at least)
<thom> resolve/invalid with a note
<Mithrandir> ok
<seb128> dpkg-shlibdeps: warning: format of libplds4.so not recognized
<seb128> dpkg-shlibdeps: warning: format of libplc4.so not recognized
<seb128> dpkg-shlibdeps: warning: format of libnspr4.so not recognized
<seb128> somebody knows what is causing this ?
<cartman> corrupted libraries?
<thom> seb128: where are you seeing that?
<sabdfl> daf: big call for ubuntu installer (d-i) in rosetta, can you arrange that today please?
<seb128> thom: evolution-data-server build
<thom> seb128: hrm, i've seen other things bitch about libnspr4
<seb128> that causes issues like #5135
<Kamion> sabdfl: daf isn't here
<Keybuk> ugh @ yaclc ... a useful tool, but a clear example of bad ui as I have to figure it out again every time I use the thing :-/
<Mithrandir> doesn't dcut work with our archive?
* Kamion finds yaclc really easy to use ...
<Keybuk> Kamion: dpkg-parsechangelog | yaclc ... but WHY does it not do that bit for you? :)
<Kamion> hm, I just yaclc foo.changes
<thom> elmo: is our morgue available anywhere?
<elmo> morgue.ubuntu.com
<thom> oh, how about that
* mode/#ubuntu-devel [-o thom]  by thom
<elmo> oh, well, except it doesn't work
<elmo> but details
<thom> minor issue
<Keybuk> Kamion: I tend to want to know if bug#s are wrong before I build the package
<mdz> lamont: do we have a good amd64 livefs now?
<lamont>   ubuntu-desktop: Depends: gnome-applets but it is not going to be installed
<lamont> that'd be 'no'
<lamont> we have a new i386 though
<lamont> ppc/amd64 have uninstallable ubuntu-desktop
<lamont> seb128: gnome-applets ftbfs on i386: uudecode:
<lamont> +debian/gnome-applets-data/usr/share/pixmaps/wireless-applet/broken-0.png: No such file or directory
* lamont hands seb128 the critical-path baton
<seb128> ok, will fix it
<Kokey> Hi! where can i find info about how to make a live cd with the 855patch?
<mroth> hmm.. all the kernel images and headers were updated to 2.6.10-4, but all the restricted-modules seems to have not been pushed and are still at 2.6.10-3?
<Kamion> mroth: those two pieces don't need to be the same version
<fabbione> that's not an issue.. and please upgrade the kernel to -4
<fabbione> hem
<fabbione> -5
<fabbione> -4 is borked in some aspects
<mroth> Kamion: well, the nvidia module in -3 appears to be incompat. with the -4 kernel
<fabbione> mroth: read above.. go to -5
<Kamion> yes, that's a bug in -4
<Kamion> module ABI broke
<mroth> Will do, has it been pushed to archive yet?
<fabbione> mroth: yup
<fabbione> it's there since a few hours
<mroth> ah yeah, i see it now
<mroth> I'll reboot on lunch break, thanks. ;-)
<lamont> seb128: holler when it's uploaded and give me back the baton...
<fabbione> mdz: are you happy with the images around or do you want me to wait with -6? (that i plan for tomorrow afternoon my time)
<mdz> fabbione: we need more time
<mdz> fabbione: lamont was unable to build new images due to dependency breakage
<fabbione> mdz: sure no prolem
<fabbione> i will have more time to grab more fixes from bk
<fabbione> and flush a bit the queue
<trukulo> fabbione: can you put my lion wallpaper by default in hoary? lol
<trukulo> don't tell anyone, just do it ;)
<fabbione> trukulo: ehhehe
<lamont> fabbione: we'll have Kamion hand you the baton once I give it to him hand he builds cd images.
<fabbione> lamont: i am not in a hurry really....
<fabbione> i just want to be able to schedule some work in progress
<fabbione> specially now that i have my distcc cluster up and running i can test way faster
<seb128> lamont: uploaded
* thom sighs at mono
<thom> azeem: (re, suicide mission) you can just run around screaming "Ben Affleck!" (this joke only works if youve seen Team America World Police)
<azeem> damn, I wanted to actually see the movie
* lamont needs to see that movie
<lamont> seb128: and before :00.  awesome.
<seb128> :)
<Keybuk> thom: that's not out here yet, is it?
<fabbione> Keybuk: that's why they invented torrent.. you know, don't you?
<Keybuk> bah, 320x240 is not a good way to see movies
<fabbione> Keybuk: now you can get DVD's directly....
<fabbione> it's kinda impressive tbh
<Keybuk> fabbione: given my usual success with bittorrent, that would take a few weeks
<fabbione> Keybuk: it looks like.. after you go over the 30% it tends to speed up a lot
<fabbione> i am down to 4 days/dvd
<Mithrandir> that's fairly slow
<fabbione> Mithrandir: i don't have 100Mb at home.. you know...
<fabbione> and the ratio is way dependent on how fast you upload
<fabbione> and there i am castrated
<Mithrandir> true enough
<thom> fabbione: does your girfriend know?
<fabbione> thom: i don't ALWAYs get pr0n
<fabbione> ;)
<trukulo> fabbione: he means that you are castrated
<trukulo> heh
<fabbione> ahaha
<fabbione> even if she did... it's not like anything... (golden rule of getting married.. if you were getting a bit of sex before.. you will get always less approaching the wedding and nothing after)
<thom> heh
<fabbione> "it's not like I GET anything"
<Keybuk> fabbione: I think that's probably the problem; upload on UK ADSL is 256Kb
<fabbione> was missing a bit ;)
<OddAbe19> fabbione, why do you think my g/f and I don't have sex... so we can have more after the wedding
<OddAbe19> :-P{
<fabbione> Keybuk: i am on 512k but downloading N things, i cap the upload bw to 40K/N
<fabbione> OddAbe19: yeah .. dream about it ;)
<OddAbe19> lol
<fabbione> after the wedding is much worst than before...
<OddAbe19> so if it's nothing now... she's gonna chop my balls off after the wedding?
<OddAbe19> got it
<OddAbe19> lol
<OddAbe19> ;-P
<fabbione> eheh
<OddAbe19> speaking of chopping balls off... i have to remember to make an appointment to have my cat neutered
<mjg59> thom: Ping?
<thom> mjg59: yo.
<OddAbe19> thanks for bringing up the subject, i forgot
<OddAbe19> lol
<mjg59> thom: We need to do acpi-support
<thom> yes, we do
<trukulo> we need suspend support :P
<mjg59> trukulo: It's there
<thom> trukulo: hush in the cheap seats
<mjg59> It just needs acpi-support to be dealt with
<mjg59> thom: We also need to decide what to do about loading hotkey modules
<trukulo> i'm in warty, don't listen me ;)
<mjg59> thom: I think the scripts in my package ought to be a decent starting point, except for a couple of things:
<mjg59> 1) We don't want to do video restore stuff on resume from disk
<thom> ok
<mjg59> 2) Most of the dodgy hardware stuff ought to be wrapped in config checks (enabled by default)
<mjg59> Oh, and we ought to have a list of modules to remove/reload on suspend/resume (empty by default)
<mjg59> And then we just need the scripts to check whether suspend is enabled or not
<pitti> elmo: can you please sync tiff?
<thom> right
<mjg59> Then we can hand script names off to seb and get them in the logout dialogue
<mjg59> Oh, argh. Except suspend to RAM shouldn't appear there if it's disabled in the config file. Oh well.
<thom> yeah, that might be a tricky one
<mjg59> Never mind. That's seb's problem :)
<thom> is it possible to have conditional entries in the logout dialog? guess probably not
<elmo> pitti: done
<mjg59> I'm sure it's a simple matter of coding...
<mjg59> And then I just need to go through the hotkey modules and work out all the possible events sleep and hibernate buttons may generate...
<mjg59> thom: Is it worth looking into having the power button generate a logout dialogue rather than hibernating by default?
<pitti> thanks
<thom> i think that's the best option; current behaviour seems to surprise people a bit
<mjg59> Last time I tried this, I had to write a small hacky client that connected to the session manager and generated a logout event
<mjg59> I can't remember if there's a proper way to do it
<Mithrandir> dbusify gdm and have something throw ACPI events onto the system dbus?
<mjg59> Well, yeah
<mjg59> thom: At the moment, most ACPI drivers don't actually get loaded. We should probably change that.
<mdz> seb128, lamont: do we have an installable desktop yet?
<mxpxpod> since the gtkmm api is frozen, do you think we could get gtkmm 2.5.5 and glibmm 2.5.4 packages into hoary?
<thom> i'm not sure how we do that better, unless we try detecting what we have in the same way that we're doing so for powernowd
<mjg59> That'd be one way. Alternatively, we just try loading all of them.
<thom> yeah, we used to do that
<thom> one of the hotkey modules spits it's dummy
<lamont> mdz: should in 3 minutes
<thom> and spews errors all over the shop
<mjg59> thom: Eww. Can't we just remove its irritating printks?
<thom> yeah
<thom> i wasn't sure if it was anything more harmful
<lamont> mdz: I think we do need to augment ubuntu-meta with a list of excluded-by-arch packages...
<mjg59> thom: I'd say go with it, and then we can work out if there's anything broken afterwards
<thom> agreed
<Mithrandir> rock! zsh now has baz completions.
<fabbione> ping?
<fabbione> did i ping off?
<thom> what do we do about suspend to disk initial setup? use laptop detect in d-i, setup the suspend partition to be big enough, ...
<seb128> mdz: we need an installable desktop today ?
<thom> hrm, last i saw was 17:31 < mjg59> thom: I'd say go with it, and then we can work out if there's anything broken afterwards
<mdz> seb128: yes, in order to build live CDs
<mdz> seb128: we need it ASAP
<Kamion> we always need an installable desktop :-)
<mdz> in fact, it needs to stay installable as much as possible for the remainder of the release cycle, in order to enable live CD development and installation testing
<seb128> kind of the middle of GNOME 2.9.4 releases which has a lot of changes pushed before GNOME feature/API freeze
<thom> mjg59: what do we do about suspend to disk initial setup? use laptop detect in d-i, setup the suspend partition to be big enough, set up grub-install with the correct params
<Kamion> oof. somebody better be prepared to hack partman lots
<mjt> is there a simple way (except of removing debian/config/$arch/* and working around some build probs as a result) to build just the source package from linux-source-2.6.10, without building all the kernels ?
<mjg59> thom: mdz was keen on making the initrd stuff work without grub parameters
<thom> ok, is that doable?
<mdz> there's a bug open about it somewhere
<mjg59> But yeah, make sure the suspend partition is big enough
<mjg59> thom: Sure, pick the biggest swap partition
<mjg59> The problem is that this needs to be done without fstab support...
<OddAbe19> did we ever fix the K3b and .ICEauthority problem?
<OddAbe19> it just occured to me
<Kamion> mdz: can I get a new cdebconf into hoary, once I upload it to Debian? I've just made the stack driver work properly (I think), and I need that for moving the password question to the first stage
<mdz> Kamion: yes
<Kamion> that's basically the only set of changes barring translations and typo fixes; I seem to be the only one touching cdebconf lately
<Kamion> (lately = since July, now that I look at it, sheesh)
<Mithrandir> Kamion: perhaps I should stomp a bit on it and break some day, then.
<Kamion> Mithrandir: you're welcome, it'd be nice to have all its miscellaneous drivers actually working
<lamont> Kamion: the baton is yours....  cd images if you please
<Mithrandir> Kamion: I have been playing with the idea of writing a test suite for it.
<lamont> mdz: once Kamion gets cd images built, any reason to make fabbione wait on -6?
<mdz> lamont: none
<Kamion> if it's ever to replace perl debconf it needs some serious love
<Kamion> Mithrandir: there's a src/test/ directory, it's not a real test suite but it's useful
* Kamion kicks off live CD builds
<Mithrandir> Kamion: I'd rather say it's not completely useless rather than saying it's useful. :P
<Kamion> mdz: I've put the manifest in /casper/ in the CD image; publishing it next to the image is a bit fiddly but I'll get to that eventually
<Kamion> Mithrandir: heh, yeah
<mdz> Kamion: sounds good
<cartman> OddAbe19: any bug #?
<Kamion> Mithrandir: still, making the gtk frontend not crash / look crap on the stuff in src/test/ was cause for quite a few improvements there
<Mithrandir> Kamion: I have no problems believing that.
<OddAbe19> cartman, i can't dig one off the top of my head, but it was a pretty common bug preventing Gnome login discussed on ubuntuforums.org
<OddAbe19> resetting of .ICEAuthority to root
<mjg59> thom: http://www.codon.org.uk/~mjg59/tmp/hotkeys.list
<cartman> OddAbe19: hmm is k3b running as root?
<OddAbe19> that was the only way to fix it was by running it in root terminal, not sudo
<OddAbe19> i never experienced it myself
<cartman> OddAbe19: well it explains. why run it through sudo?
<cartman> 2.6.9+ can burn cd without root
<OddAbe19> running it through sudo or as user would reset it
<OddAbe19> this was a warty problem
<OddAbe19> 2.6.8-1
<thully> hi - does anyone know which build of the hoary live CD works best at this point?
<cartman> OddAbe19: yes kdeinit will change perms of .ICEAuthority when running as root
<OddAbe19> cartman, i was just wondering if it was fixed in warty yet, because i've been working on a deb for k3b for warty users
<OddAbe19> to try to prevent that
<cartman> OddAbe19: you could hack kdeinit but I don't think it would be good
<OddAbe19> cartman, i don't think you get where i'm coming from, i dont have the problem, i'm trying to find a solution for the problem for warty users
<OddAbe19> lol
<Kamion> live CDs built, let me check them over
<cartman> so I say solution is to hack kdeinit
<OddAbe19> so they can log in after using k3b
<thully> the latest build doesn't work
<OddAbe19> cartman, i didn't think of that
<Kamion> all live CDs built with 2.6.10-5 across the board
<OddAbe19> i shall try that next deb i build and test
<Kamion> thully: try the latest build that *just* appeared :-)
<cartman> OddAbe19: void init_kdeinit_socket() is your guy
<Kamion> sorry for the big downloads - live CD's in a lot of flux right now so you might want to talk to one of us before wasting time downloading
<Kamion> fabbione: baton is yours
<OddAbe19> thanks, i'll work on it in a few hours, i have to get to class soon
<cartman> OddAbe19: kdelibs/kinit/kinit.cpp btw
<OddAbe19> yeah, i got it
<OddAbe19> thanks
<cartman> np
<thully> Kamion: I downloaded one about2 hrs ago - is there a newer one?
<Kamion> thully: 18:21 < Kamion> live CDs built, let me check them over
<azeem> OddAbe19: is your nick your gnupg id?
<Kamion> i.e. yes
<OddAbe19> i don't have a gnupg id
<azeem> oh :)
<Kamion> this one actually has consistent kernel versions so might stand a chance
<Riddell> OddAbe19: make sure you comment on the buzilla entry if you fix it
<OddAbe19> i do my builds as a hobby
<OddAbe19> and distribute them if people are interested
<OddAbe19> thats it
<OddAbe19> Riddell, i will
<cartman> Riddell: its not a fix I guess
<OddAbe19> not really
<thully> OK - looks newer than what I have
<thully> thanks a lot
<cartman> Riddell: kinit supposed to change perms. on .ICEAuthority
<cartman> security purposes
<OddAbe19> it's just an kinit error on k3b and gnome in warty
<OddAbe19> yeppers
<OddAbe19> lots of complaints from warty users on ubuntuforums about it
<Riddell> cartman: it does have the nasty side effect of sometimes breaking KDE for all the other users though
<Riddell> well, more than KDE I guess
<cartman> Riddell: don't think it would be accepted in upstream though
<Riddell> cartman: I'll commit it, nobody monitors kdelibs anyway :)
* Riddell still has to unbreak konqueror's tabs
<cartman> Riddell: lol you wish
<OddAbe19> probably not, it is a security problem after hacking the library
<cartman> dirk I'm sure watching kdelibs
<cartman> :)
<lamont> Kamion: the truely sick can mount the compressed fs and dpkg -l in that...
<sladen> who knows about  update-initrd  ?  It's not 2.6 compilant (fails because modules are named \.ko not \.o), and also seems to be part of discover1 ?
<Kamion> what's still using that, if anything?
<pitti> elmo: can we have a new mail address language-packs@ubuntu.com which is directed to me?
<pitti> elmo: I would like to set the new gpg key (for autobuilds) to this email address
<metalikop> thx for fixing gaim :)
<Mithrandir> np
<metalikop> You guys have a plan to add gnome-bluetooth support (or multisync-evolution)?
<crimsun> ugh, not that again.
<metalikop> heh
<OddAbe19> lol
<metalikop> uh oh
<azeem> metalikop: what's the problem with multisync-evolution?
<metalikop> libmultisync-plugin-evolution: Depends: libedata-book1.2-0 (>=1.1.1) but it is not installable Depends: libedata-cal1.2-0 (>=1.1.1) but it is not installable
<mjg59> metalikop: That sounds like it's the old Evolution plugin
<mjg59> Hoary ought to have one for Evolution 2
<metalikop> unfortunately I can't find one
<azeem> nah 1.2 are the hoary e-d-s libs
<azeem> or so I thought
<seb128> perhaps the soname have changed
<azeem> ah, yeah
<seb128> and I'm uploading a new version with some new soname changes in a few min ...
<azeem> it's 1.2-1 now
<metalikop> very nice ;)
<metalikop> so why the "not that again" regarding gnome-bluetooth
<seb128> ?
<azeem> metalikop: it was about that guy parting all the time
<metalikop> oh oh
<azeem> not about gnome-bluetooth (or so I think)
<metalikop> acceptable.
<Kamion> elmo: is there any value in my asking you to sync cdebconf from incoming only to immediately branch it into cdebconf 0.74ubuntu1? I guess having it in the morgue might help with future merges?
<elmo> that'd be the only value I can think of, yeah
<lamont> Kamion: iso's done, I assume?
<Kamion> lamont: yes
* lamont back in 2-3 hours
<mdz> lamont: when you get back, please do an experiment to see how much larger the image gets if you compress with 1k blocks rather than 64k
<mdz> I imagine it's a lot, but that should make it much more rsyncable
<trukulo> Mithrandir, new video uploaded
<trukulo> can you tell me the link?
<Kamion> elmo: ok, please sync cdebconf_0.74 from incoming then, please
<Mithrandir> trukulo: http://tracker.err.no/mshuttleworth_small.avi.torrent
<sivang> Mithrandir: torrents are up already?
<Mithrandir> sivang: two are
<trukulo> updated
<Mithrandir> mako_small and mshuttleworth_small
<mako> who are you calling small?
<trukulo> you have small one
* Mithrandir pats mako on te head.
<Mithrandir> s/te/the/
<sivang> Mithrandir: ok, going to download.
* mako is watching himself on video now
* Mithrandir wonders if you aren't going to stress my link a little bit at least.
<Mithrandir> it's idling at 2% usage.
<sivang> Mithrandir: downlaoding
<sivang> 94kbs
<sivang> wow
<trukulo> mako, what about quality? is it good?
<Mithrandir> ok, I'm up to 2.5% usage now :P
<fabbione> Mithrandir: did you finish to get all the stuff for the torrents?
<sivang> so nice to have those, just to get reminded of the fun that was in mataro :)
<sivang> Mithrandir: you have some nice upstream there, 100Kbs ?
<Mithrandir> fabbione: I have two of them, so still missing a large bunch.
<trukulo> no fabbione 
<trukulo> it's VERY SLOW
<fabbione> oh ok
<trukulo> only two videos, low quality, atm
<Mithrandir> sivang: yeah, academic 100Mbit to my machine.  Would like to have gbit, but I don't.
* fabbione will wait...
<sivang> Mithrandir: cool
<Mithrandir> trukulo: you saw my mail about the big mako dropping after 18M?
<trukulo> Mithrandir, yes
<trukulo> i answered it, i think
<sivang> Mithrandir: it's stressing my 1.5Mbit /128kb upstream :)
* Kamion doesn't want to think about mako droppings, if you please
<trukulo> i said i'll resume when others finished
<sivang> mako: you client must be rining you with colors :)
<trukulo> fabbio is very ugly
<sivang> *rining, even
<sivang> erghgh
<sivang> ringing
<Mithrandir> trukulo: ok, that's fine.
<Treenaks> GREAT
<Treenaks> wireless link monitor is gone
<smurfix> Treenaks: isn't it in another package now?
<Treenaks> smurfix: it's not in the default set of gnome applets antmore
<mako> Mithrandir: yeah.. i got to that point too.. i was trying to get bigmako too
<Mithrandir> mako: trukulo's uplink is slow, so it takes me half a day to get each of those.  I'm putting them online when they're complete.
<smurfix> Treenaks: right. From the gnome-applets changelog.Debian:    - remove wireless applet (replaced by gnome-netstatus)
<Treenaks> smurfix: yes, the applet got replaced on my bar
<Treenaks> smurfix: but I don't see the link quality part...
<Treenaks> oh wait.. it does... in some weird non-obvious way
<mako> Mithrandir: nice :)
<mako> this is actually pretty educational for me
<mako> to watch myself give a talk
<trukulo> it's not my uplink :) god thanks
<trukulo> it's a friend's one
<Treenaks> Mithrandir: any new ones online? :)
<trukulo> mark's one is online
<Treenaks> hm..
<Treenaks> oh wait
<Treenaks> I have the _big ones
<Treenaks> those will probably take some more time
<trukulo> you have the ENTIRE big ones?
<Treenaks> trukulo: no, just the .torrents
<trukulo> they are broken now
<trukulo> look this
<Treenaks> trukulo: if I had the entire _big ones I'd seed them at 100mbit :)
<trukulo> www.badopi.org/videos
<trukulo> here are the new (valid) ones
<trukulo> only two atm
<Treenaks> trukulo: I got my torrents direct from mithrandir's site
<Mithrandir> Treenaks: the mshuttleworth_small
<trukulo> Treenaks, he only has 2
<Mithrandir> Treenaks: it's the same torrens.
<Mithrandir> +t
<trukulo> i'm remotely uploading the .avi
<Treenaks> this seems to work..
<Treenaks> I'll be seeding in ~14 minutes
<Treenaks> trukulo: wow, what's the codec?
<trukulo> avc divx
<trukulo> i think
<elmo> oh!
<elmo> graphviz got CPLed
<azeem> \o/
<Kamion> CPL?
<mako> trukulo: once these are all being seeded quickly, i'll announce them on ubuntu-news
<trukulo> mako, perfect :)
<mako> Mithrandir, trukulo: let me know
<trukulo> ok
<trukulo> i'll tell you when we have all of them
<trukulo> but i think that would take 3 o 4 days
<mako> that's cool
<trukulo> small ones perhaps tomorrow
<mako> the small ones look fine
<mako> i just watched babymako
<trukulo> :)
<trukulo> i didn't see big ones
<trukulo> but small one are: 400x320
<trukulo> and big ones: 720x576
<Treenaks> trukulo: another seed for mshuttleworth_small has arrived:)
<trukulo> :) cool
* sabdfl read "quality" as an indicator of the talk itself
<trukulo> sabdfl, you have your video online :)
<sabdfl> <blush>
<mdz> GAH
<mdz> lamont: amd64 live image is b0rked
<mdz> lamont: it has no /var
<trukulo> :)
<trukulo> sabdfl,  http://tracker.err.no/mshuttleworth_small.avi.torrent
<trukulo> we have only two videos, uploading the others with a VERY slow uplink
<mdz> trukulo: where are these from?
* Kamion ctrl-cs the hoary-live-amd64.iso download
<mdz> from Mataro?
<trukulo> yes
<trukulo> from barcelona, badopi talks
<mdz> lamont: please find out how this happened and add a sanity check of some sort
<mdz> oh, the LUG
<Kamion> elmo: should I just upload that gpgv-udeb patch to Ubuntu?
<trukulo> yes
<mdz> I suppose I don't need to download the video, since I was there :-)
<trukulo> :) yes
<trukulo> i was there too, presenting the talkers
<trukulo> but no one let me listen the talks
<trukulo> so i have to download and see them
<Mithrandir> mdz: you could do my uni a favor and download it to generate traffic. :P
<mdz> Kamion: are you downloading powerpc, then?
* ChrisH takes a bow to the community :)
<ChrisH> Unfortunately I missed today's CC meeting. The backlog dealt with MOTU coordination. Does anyone have more information at hand?
<Kamion> mdz: just started
<azeem> ChrisH: congrats
<mdz> Kamion: we'll need a new one with casper 0.6 for amd64 anyway
<ChrisH> azeem: Thanks. :) I assume you read debian-project...
<sivang> ChrisH: here you are again
<sivang> !
<Kamion> mdz: yay :-/ whenabouts?
<sivang> finally
<mdz> ChrisH: the complete log for the meeting should be available from mako shortly, if not already
<mdz> Kamion: uploaded already
<ChrisH> sivang: Yes, sorry. It's my wife's anniversary today and I promised to stay offline.
<mdz> Kamion: modprobe ext2 || true
<sivang> ChrisH: ah sorry :-/
<zul> ChrisH: shesh where are your priorities ;)
<ChrisH> mdz: Yes, already read them. Just wondered what the MOTU team lead job's supposed to be.
<ogra> heh
<elmo> Kamion: yes
<ChrisH> zul: Uh... I better don't tell that to my wife. ;)
<elmo> kamion: CPL == same license as postfix
<mdz> ChrisH: should be clear from the meeting, but at this point, primarily approving new people for upload privileges to universe
<mdz> Kamion: /var/log/debian-installer is huge
<ChrisH> mdz: So you are thinking of the coordination of "AMs" (if I may use that Debian term)?
<Mithrandir> elmo: yay! :)
<mdz> Kamion: but some bits of it are useful for the live CD
<mdz> Kamion: can we arrange something so that we get, say, only hardware-summary.gz and syslog.gz ?
<sivang> ChrisH: since you have experience with debian mentors, this seems fit :)
<mdz> Kamion: (they probably ought to be compressed in all cases anyway)
<mdz> elmo: will there be a proper release with the new license in time for hoary?
<mdz> elmo: graphviz->main would be excellent
<ChrisH> sivang: Sounded very interesting so far. I wish I could have placed my dumb questions during the -meeting.
<Kamion> mdz: that's prebaseconfig/prebaseconfig.d/93save-install-log
<mdz> Kamion: yes, I know
<mdz> Kamion: should I hack it up to check some environment variable or something?
<Kamion> for what?
<magnon> mdz, aren't you doing security stuff on ubuntu?
<mdz> Kamion: it wastes a huge amount of space on the live CD snapshot
<Kamion> you could just rm the bits you don't want after it's done ...
<mdz> Kamion: where things like templates.dat are not very interesting
<mdz> Kamion: it's too late once they've been written
<elmo> mdz: it'd be a big version hike, so we'd have to bend the rules, but 2.0 is available from the website
<Kamion> mdz: hm, ok, file a bug and let me think about it ...
<mdz> magnon: some, but Martin Pitt (pitti) has primary responsibility for security
<Mithrandir> elmo, mdz: I could take a look at the new graphviz now if you'd like me to.
<sivang> ChrisH: you might also want to coordinate with haggai as he is also considered for this lead role of MOTU.
<sivang> (summing up what I saw during the CC meeting :)
<ChrisH> sivang: yes, that's right
<mdz> Mithrandir: sure
<Kamion> mdz: shall I kick off a live CD build now, then?
<mdz> Kamion: no point until lamont fixes the cloop image
<mdz> and he said he was disappearing for 2-3 hours(?)
<Kamion> oh, and casper 0.6 binaries aren't up yet
* mdz calls
<elmo> mdz was being a muppet with the distro line ;)
<elmo> so casper only just got in source-wise
<mdz> elmo: distro line?
<elmo> Distribution: unstable
<Kamion> mdz: TBH I'm really thinking that duplicating the small bits of prebaseconfig that you actually need would be better than removing the large bits of prebaseconfig that you don't need in the current very fragile way; rebooting into base-config and pivoting into a live CD are totally different use cases and I think they deserve different code
<mdz> Kamion: I want locale config, I want keyboard config, I want timezone config, I want network config
<mdz> I do not want to duplicate all that code
<Kamion> that is why casper.d should exist
<Kamion> but the stuff in prebaseconfig is just not appropriate
<Kamion> and I don't like casper running around rming stuff whose name is not guaranteed, and I don't think it makes logical sense to split prebaseconfig
<mdz> I agree that the current approach of rming is far from ideal
<mdz> so you think that things like 05localeconfig should be duplicated in casper.d by whichever module creates them?
<Mithrandir> how about just keeping what you want and removing everything else?
<mdz> Mithrandir: that has the same problems
<Kamion> yes, unless the assumptions inherent in any split are very carefully documented
<Kamion> both ordering and forward/reverse dependencies
<mdz> I don't even know which udebs create those files
<Kamion> localechooser, kbd-chooser, (tzsetup-udeb sort of assuming it works in that environment which it may not), netcfg
<Kamion> tzsetup-udeb doesn't have a prebaseconfig script though
<mdz> are those generally created at runtime, or shipped in the udeb?
<Kamion> shipped in the udeb; there used to be a couple of things that created a prebaseconfig script at runtime, but netcfg got fixed to not do that any more
<Kamion> hw-detect still fiddles with its prebaseconfig at runtime I think
<Kamion> yeah, it does, for de4x5 blacklisting and pcmcia
<mdz> ok, so hopefully just a handful of symlinks in the udebs, and modify hw-detect
<Kamion> a symlink likewise
<mdz> but to be created at runtime
<Kamion> the file is shipped in the udeb, it gets appended to at run-time
<mdz> oh
<Kamion> sorry, unclear
<mdz> what was the magic recipe to eject the CD during boot on powerpc again?
<mdz> I thought it was holding down the left mouse button, but that doesn't work for me
<Kamion> didn't know there was one, unless I ran across it by accident and forgot about it
<Kamion> mdz: try cmd-opt-o-f and then 'eject cd'
<mdz> Sep 28 17:31:45 <Kamion>        mdz: one rumour claims holding down the left mouse button during boot also ejects the CD ...
<mdz> Sep 28 18:19:10 <Kamion>        mdz: incidentally that hold-down-left-mouse-button-during-boot-to-eject-CD trick worked for me too
<Kamion> hm, ok
<mdz> Kamion: what are cmd and opt on a us layout keyboard?
<Kamion> obviously I forgot about it :)
<amu> pressing mouse after warm-start is one  
<Kamion> do you have an apple key?
<mdz> no
<Kamion> uh
<mdz> I have a 104-key keyboard
<Kamion> command is normally apple, option is alt
<mdz> maybe windows = apple
<Mithrandir> yeah
<Kamion> I don't know what to do if you don't have an apple key
<Mithrandir> at least windows = apple
<Mithrandir> uhm, apple = winows.
<Kamion> mdz: that trick probably only works with an ADB mouse
<Mithrandir> use a paperclip to eject the cd, then?
* Kamion thinks the open firmware trick is easier
<Kamion> I haven't disassembled OF's mac-boot command yet, though
<Kamion> mdz: why's it urgent to eject it during boot?
<mdz> Kamion: because I'm tired of waiting for the entire system to boot so that I can type 'eject' and reboot it
<mdz> I keep it turned off, generally
<Kamion> heh, ok
<mdz> Mithrandir: they cleverly block the eject button and hole with a bracket
<mdz> Kamion: anyway, powerpc is not entirely a success, but worthwhile for you to download I think
<mdz> dpkg-reconfigure xserver-xorg hangs
<Kamion> mdz: ok, 25% through
<mdz> I think it might be pissed at being already running under debconf?
<Kamion> ETA a couple of hours, so I'm off for the evening
<mdz> (cdebconf, anyway)
<Kamion> very possible; don't you disconnect from cdebconf?
<mdz> can the debconf confmodule talk to cdebconf?
<mdz> Kamion: this happens while the progress bar is still displayed
<Kamion> yes, theoretically
<Kamion> sort of
<Kamion> they speak the same protocol (modulo extensions) over stdio
<mdz> you'll probably want to comment out the dpkg-reconfigure for your test
<Kamion> but the xserver-xorg templates will not be registered with cdebconf
<Mithrandir> use the trick which is used when calling debootstrap and redirect stdout/stdin?
<mdz> the hostname prompt turns out to be a convenient spot to switch over and fix stuff
<mdz> so we shouldn't suppress that quite yet :-)
<Kamion> Mithrandir: not if you *want* the question to be asked :)
<Kamion> mdz: for xserver-xorg, I'd recommend disconnecting from cdebconf instead
<Kamion> hm, maybe not
<mdz> Kamion: will that break the progress bar?
<Kamion> tough problem
<Kamion> if debconf actually asks the question, then it will probably break because it doesn't understand TERM=bterm
<Kamion> you could register the xserver-xorg templates with cdebconf?
<mdz> why doesn't it?
<Kamion> because it doesn't need to ...
<Kamion> also the UI looks slightly different
<mdz> would -fnoninteractive help, or no?
<mdz> presumably wouldn't fix the template situation
<Kamion> noninteractive still talks to the database
<Kamion> it would probably help providing that you disconnected
<mdz> db_stop?
<Kamion> no, db_stop can't fix up fds
<Kamion> see rescue-mode.postinst
<Kamion> disconnect_run and the stuff down near the bottom that sets OLD_*
<Kamion> grotty but it works :)
<mdz> where do $OLD_STDOUT etc. come from?
<mdz> oh, set below
<Kamion> yep
<Kamion> the env -i is needed to unset various debconf-specific environment variables
<Kamion> it might also be possible to unset them individually; baseconfig-udeb takes that approach
<mdz> registering the templates with cdebconf starts to sound appealing
<Kamion> I'd rather that cdebconf exported some way to do this, but I haven't been able to see how
<mdz> is it permissible to ask a question in the middle of a progress bar anyway?
<Kamion> depends; do you want to support people running dpkg-reconfigure xserver-xorg in the live filesystem?
<mdz> yes
<Kamion> you'd have to mess about with debconf-copydb to make that work then, if you had the questions asked by cdebconf
<Kamion> yes, questions can be asked (by cdebconf) in the middle of a progress bar
<Kamion> hw-detect does that
<Kamion> and prebaseconfig
<mdz> it's less important that dpkg-reconfigure xserver-xorg have the probed values
<Kamion> debconf-copydb is *relatively* straightforward, if runic
<mdz> sounds like it needs for the databases to be defined in the config file
<Kamion> if you run into any missing features in cdebconf, let me know
<Kamion> nah, you can do that on the command line like base-config does
<mdz> ah
<Kamion> it's fairly important to get cdebconf up to feature-parity with debconf, because long-term it would be good to be able to replace debconf with cdebconf
<mdz> I suppose I should just disable the dpkg-reconfigure for now
<Kamion> at least, maybe :)
<mdz> to get back to a working (console-mode) live CD
<Kamion>         debconf-copydb d-i configdb -c Name:d-i -c Driver:File \
<Kamion>                 -c Filename:$DI_DB \
<Kamion>                 --pattern='^(mirror/http/proxy|mirror/suite|debian-installer/keymap|debian-installer/country|debian-installer/language|debian-installer/only-os)$'
<mdz> uploaded casper 0.7 with that change
<mdz> (disabling)
<mdz> I'll give copydb a try later
<Kamion> debconf-loadtemplate /target/var/lib/dpkg/info/xserver-xorg.templates; chroot /target dpkg-reconfigure xserver-xorg; debconf-copydb configdb target -c Name:target -c Driver:File -c Filename:/target/var/cache/debconf/config.dat --pattern='^xserver-xorg/.*'
<Kamion> something like that ought to work
<Kamion> although you might have to chroot to run debconf-copydb; I can't remember if cdebconf's version can safely write to debconf's files
<Kamion> probably can
<Kamion> oh, debconf-loadtemplate xserver-xorg /target/var/lib/dpkg/info/xserver-xorg.templates, but anyway
<mdz> Kamion: we're already pivoted into /target by the time this runs
<Kamion> uh, and cdebconf survived that?
<mdz> yeah, works great
<Kamion> surprising; it won't be able to save
<mdz> it doesn't get a chance :-)
<Mithrandir> Kamion: why shouldn't it work?
<Kamion> Mithrandir: no /var/lib/cdebconf
<mdz> we increment the progress bar, and then it gets killed by init
<Kamion> no /usr/lib/cdebconf/*/*.so, come to that
<Mithrandir> so?  They're already in memory by then.
<mdz> I guess that makes debconf-copydb, er, awkward
<Kamion> mdz: yes ...
<mdz> so we're back to disconnect_run
<Kamion> can you dpkg-reconfigure xserver-xorg before pivoting?
<mdz> I suppose it could be done
<mdz> via chroot
<Kamion> disconnect_run still leaves you with the "what does the UI look like if xserver-xorg really *has* to ask a question?" problem
<Kamion> and unfortunately I fear the answer is "dreadful"
<mdz> is it that hard to provide a terminfo file for bterm?
<Kamion> probably not, but it's still using totally different UI code and therefore looks rather different
<mdz> I could write a precasper.d script to do the chroot/dpkg-reconfigure before pivoting
<Kamion> it's probably better than it used to be because a UTF-8 locale will exist in the live filesystem; that wasn't the case when I last tried baseconfig-udeb (before warty)
<thully> is there any plans for more array CDs?  The schedule calls for about 1 every 2 weeks, yet only 2 have been made the entire development schedule.
<sladen> thully: pester Kamion
<Kamion> there are, but it kind of requires the archive to work :-)
<Kamion> the windows of installability have been quite narrow at times
<Kamion> for warty, we only started doing sounder CDs around the time of the upstream version freeze, so I'm not too worried
<thully> yes - just learned that - I tried installing hoary from the daily build and I had to do lots of funky things to get a working install
<Kamion> I'm not sure that I have a copy of Sounder CD 1 any more, but Sounder CD 2 was 29 June
<Kamion> today's daily?
<thully> yes - it bombed out to a command prompt without installing anything but base, and then after I did an "apt-get install ubuntu-desktop" something funky w/udev and hal happened and the instalslowed to a crawl until I killed those things
<Kamion> oh, ubuntu-desktop was broken today (do you mean a command prompt, or aptitude?)
<lamont_r> mdz: amd64 fsimg has a 43MB /var
<Kamion> I didn't know about the udev problem
<Kamion> thully: oh, did the move of the timezone question to the first stage fix that long-standing timezone bug of yours?
<thully> Haven't checked - my PC is currently in a state of chaos as I've been testing many OSes on it - I haven't even set my clock correctly in a while :)
<lamont_r> Kamion: are the livecd links still pointing to yesterday???
<Kamion> lamont_r: which ones?
<lamont_r> Kamion: nm.  fat finger
<lamont_r> s
<lamont_r> mdz about?
<sivang> anybody know pitti's canonical address and can answer me in private so not to get his email harvested by bot log readers?
<Kamion> the addresses are of the form firstname.lastname@
<thully> I don't know if I'm quite up to this "unstable" thing - I just don't have the time for testing at the moment
<azeem> bot log readers?
<thully> One question - regarding Thunderbird 1.0, is Ubuntu taking the same stance as Debian regarding the whole trademark issue?
<thully> since that's the only thing holding up 1.0 being in unstable
<mdz> lamont_r: yes
<Mithrandir> thully: what trademark issue?  That we're not shipping the trademarked icons and stuff?
<mdz> potpal:[~/live]  sudo mount -o loop hoary-live-amd64.iso /mnt
<mdz> Password:
<mdz> potpal:[~/live]  sudo losetup /dev/cloop0 /mnt/casper/filesystem.cloop
<mdz> potpal:[~/live]  sudo mount /dev/cloop0 /mnt
<mdz> mount: block device /dev/cloop0 is write-protected, mounting read-only
<mdz> potpal:[~/live]  ls /mnt
<mdz> bin   dev  home    initrd.img  lib32  lost+found  mnt  proc  sbin  sys  usr
<mdz> boot  etc  initrd  lib         lib64  media       opt  root  srv   tmp
<mdz> lamont: ^^^
<thully> that they can't use the name "Mozilla Thunderbird"
<Mithrandir> thully: hm, can you give me any references on that?
<azeem> Mithrandir: lwn
<azeem> has a feature on it
<Kamion> is that really a Debian stance or something that one person said on a Debian list?
<thully> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284560
<thully> Well, it's keeping 1.0 out of debian at the moment - but there are unofficial packages and the unofficial Ubuntu backports for Warty have Thunderbird 1.0 included
<lamont_r> bin   etc     initrd.img  lib64       mnt   root  sys  var
<lamont_r> boot  home    lib         lost+found  opt   sbin  tmp  vmlinuz
<lamont_r> dev   initrd  lib32       media       proc  srv   usr
<Mithrandir> well, I don't see why this is an issue for 1.0 vs 0.9
<mdz> c5fd3f7995bb2479095200f951654c17  hoary-live-amd64.iso
<mdz> 9ae025da3e122ec6ef8942e4e24c946e  /mnt/casper/filesystem.cloop
<lamont_r> 9ae025da3e122ec6ef8942e4e24c946e  livecd-current.cloop
<mdz> lamont_r: are you looking through cloop?
<lamont_r> mdz: so either cloop trashed things, or something is deleting /var... :-(
<lamont_r> no - loopback on fsimg
<mdz> look through cloop
<lamont_r> no cloop module on that system
<mdz> ELMO
<lamont_r> well, I think not... how do I tell it to?
<thully> well - maybe Ubuntu should make a 1.0 package separately from debian - based off one of the unofficial builds
<lamont_r> that is, is it just losetup, or does it need something more?
<Kamion> we already have a 1.0 package
<mdz> lamont: scroll back about 30 lines
<Kamion> I don't see how deliberate separation helps us in the least
* lamont_r tries
<thully> So - it's held up for the same reasons it's held up in debian?
<Kamion>    mozilla-thunderbird_1.0-0ubuntu1_i386.deb
<Mithrandir> Kamion: I uploaded that earlier today.
<Kamion> doesn't look held up to me
<mdz> it's not "held up"
<mdz> it's in hoary
<mdz> so this entire discussion is pointless
<thully> it is - well, that's new
<lamont_r>  /dev/cloop0 - no such file
<mdz> lamont: sudo modprobe cloop
<lamont_r> mdz: this is an elmo kernel. what modules?
<Kamion> thully: yes, as Mithrandir said. :)
<mdz> E L M O 
<lamont_r>  modprobe cloop
<lamont_r> FATAL: Could not load /lib/modules/2.6.8.1/modules.dep: No such file or directory
<thully> I see - things happen fast
<mdz> lamont: if anything, create_compressed_fs is fucking up
<Kamion> thully: we had nobody looking after m-t for a while; at the last hoary goals meeting, Mithrandir volunteered to give it some love
<mdz> I'm doing my test using cloop on i386, which is known to not be horribly broken
<lamont_r> mdz: let me rebuild it with the hack job instead and see what that does for us.
<Mithrandir> thully: I think we can ignore it, it shouldn't be any bigger problem with 0.9 rather than 1.0.
<lamont_r> failing that, maybe compressing on i386 will be better
<mdz> lamont: I doubt it will differ in the slightest
<Kamion> AFAICS the only reason that's keeping 1.0 out of Debian is that the maintainer wants to deal with both problems at the same time
<sivang> mdz,Kamion : all this test talk relates for the live cd and the gui installer? :)
<Kamion> and I guess 1.0 is a good point at which to do so
<mdz> sivang: what gui installer?
<Kamion> sivang: not the GUI installer
<Kamion> keep up :-)
<mdz> sivang: I thought you were going to write the gui installer :-)
<sivang> mdz: heheh :)
<sivang> mdz: dreams dreams, it's amazing how one can be stupid with what he claims when he has not a clue of it :-/
<Mithrandir> Kamion: yeah; tackling both problems at the same time might be fine, but I think we can do that later.
<Kamion> mdz: hm, would you like to have a background title on the live CD's cdebconf screens saying "Ubuntu Live CD", or something like that?
<sivang> mdz:  :)
<mdz> Kamion: sure
<mdz> Kamion: that reminds me, I should also fix its menu item
<Kamion> I'd like that for rescue mode, so I think I'll try to come up with a general interface for that in cdebconf
<pasc> ~..
<mdz> Kamion: currently I have Description: Run a "live" preinstalled system from read-only media
<lamont_r> mdz: was amd64 the only borked cloop?
<mdz> Kamion: which makes a reasonable description, but not a menu item
<mdz> Kamion: how do I override it?
<mdz> lamont_r: not sure
<Kamion> mdz: create a debian-installer/casper-udeb/title template, type text, with the description you want as the menu item
<Kamion> (it should really be main-menu/title/casper-udeb or something, but that won't be changing just yet)
<mdz> Kamion: what would be a good menu item name?
<Kamion> describe the action, so "Enter live filesystem" maybe?
<mdz> s/filesystem/something else/
<mdz> 'session' maybe
<Kamion> Enter live preinstalled system
<mdz> Kamion: I just put this in my templates file?
<Kamion> yes
<lamont_r> mdz: I'd bet on it.
<Kamion> at the top is conventional
<mdz> lamont_r: oh, you found a problem?
<lamont_r> no - it's just that it's not any diff from the other machines, other than being 64 bit
<Mithrandir> lamont_r, mdz: what's the problem?  cloop-utils still broken on amd64?
<mdz> Kamion: oh, btw, I get a ton of garbage output overwriting the cdebconf dialog when casper-udeb is unpacked
<mdz> seems to have to do twith the po file that amu gave m e
<mdz> me
<lamont_r> Mithrandir: the fsimg looks good, but cloop is kinda missing /var
<mdz> Mithrandir: it succeeds, but the result is apparently not optimal
<Mithrandir> lamont_r: what do you mean, missing /var?
<lamont_r> see scrollback
<lamont_r> ls in / does not show /var
<Mithrandir> that's fairly crackful.
<lamont_r> at least according to mdz - and he has the same .cloop file that I do
<mdz> er
<mdz> lamont_r: i386 is fucked in exactly the same way
<lamont_r> Mithrandir: s/fairly//
<lamont_r> WTF
<Mithrandir> is http://cdimage.ubuntu.com/daily-live/current/hoary-live-amd64.iso the right one?
<lamont_r> yep
* Mithrandir grumbles at his 2.4Mbit.
<mdz> lamont_r: EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
<mdz> lamont_r: might have something to do with it
<mdz> lamont_r: in both cases
<mdz> lamont_r: did you remember to unmount it before creating the cloop file?
<lamont_r> mdz: gah - wonder what didn't get unmounted.. :-(
<lamont_r> uh.  heh.
<mdz> Kamion: I'm thinking I should just convert most of the shell functions in casper-udeb.postinst into casper.d scripts
<Kamion> tend to agree
<mdz> Kamion: will I run into problems driving the progress bar from within a subprocess?
<Kamion> no
<mdz> ok, so basically cut and paste then
<Kamion> not that I can think of, anyway
<Kamion> just source the confmodule in each, they all talk to the same frontend
<lamont_r> so, um, Kamion...
<lamont_r> new livecd rootfs files for you in about 30 minutes
<lamont_r> mdz: for the record, I was unmounting it...
<Kamion> ok
<lamont_r> right after I compressed it.
<lamont_r> :-(
<Kamion> unfortunately I basically can't download an image in time for it to be usefully testable at the moment
<Kamion> so I'll give up for a while and use the bandwidth for something more productive
<mdz> Kamion: what's the intended difference between base-installer.d and prebaseconfig.d?
<mdz> lamont_r: tried blocksize=1k?
<mdz> we could also do blocksize=4k and use 4k blocks in the ext2 fs
<mdz> the latter should be much more efficient
<mdz> space-wise
<lamont_r> actually running one with blocksizes from 1 to 32 kb
<lamont_r> ah, because most of our files are > 2KB?
<Kamion> mdz: base-installer.d runs before the base system is installed, i.e. before debootstrap
<Kamion> mdz: the reason netcfg runs there is that some packages installed by debootstrap expect the networking information already to be set up
<mdz> ah
<Kamion> so prebaseconfig.d would be too late
<mdz> so for casper the distinction is irrelevant
<mdz> (which is good, because I treated them exactly the same)
<lamont_r> 4k is 655MB, 2k is 741
<lamont_r> 8k is 603
<mdz> Kamion: hmm
<Kamion> yes
<mdz> Kamion: we're going to run into some major sequence number problems if I go this route
<Kamion> why?
<mdz> because casper has >5 things which need to be run in order before 05archive-copier
<Kamion> 05archive-copier doesn't have to stay as 05 in casper.d
* mdz whimpers
<Kamion> uh, in any case you don't want to run archive-copier in casper!
<Kamion> sure
<Kamion> surely
<lamont_r> heh
<mdz> s/archive-copier/05localechooser/
<mdz> they both run at 05
<mdz> the prebaseconfig bit of archive-copier only runs apt-cdrom
* lamont_r notes that 0400xxx through 0499xxx land between 04a and 05b
<Kamion> I didn't put archive-copier in the casper seed :)
<mdz> Kamion: you didn't implement usage of the casper seed, either, iirc ;-)
<Kamion> lucky for you ;)
<Kamion> mdz: I guess it's useful; shall I put it back?
<Kamion> oh, do you have any preseeding entries that you want me to set for casper? it's not hard to do so
<lamont_r> what locale does the livecd boot with by default?
<Kamion> C.UTF-8 and runs localechooser first
<lamont_r> ok.  gonna have to stomp on libpaper1 a little, I think
<Kamion> I could add one that defaults to en_US or whatever and skips the localechooser question, if you like
<Kamion> s/one/a bootloader entry/
<lamont_r> unless we want A4 to be the default paper on the livecd regardless of locale...
<mdz> Kamion: the only thing which I would like to change is the hostname logic
<mdz> Kamion: but preseeding won't exactly do what I want
<Kamion> hm, I thought I gave preseeding entries which would?
* lamont_r wonders if he can get away with running off for an hour...
<mdz> Kamion: what's the right way to display those nice error dialogs?
<mdz> Kamion: you did?
<mdz> Kamion: oh, preseeding is scripts, not simply setting values?
<mdz> because I need to twiddle the seen flag or whatever
<Kamion> mdz: search for netcfg/dhcp_options in those logs of yours
<Kamion> mdz: no, preseeding is setting values, but the seen flag automatically gets set
<mdz> Kamion: but I don't want to set the value
<Kamion> otherwise it'd be somewhat useless :)
<mdz> I want it to use the dhcp one, or 'ubuntu' if it doesn't get one
<Kamion> yes, you can do that by preseeding the control flow
<mdz> Kamion: example?
<Kamion> d-i netcfg/dhcp_options select Configure network manually
<lamont_r> mdz: need to go fetch kids and head back home
<lamont_r> amd64 is compressing now, others still installing
<Kamion> d-i netcfg/get_hostname string ubuntu
<Kamion> if DHCP succeeds it'll overwrite netcfg/get_hostname
<lamont_r> back about 15:30 mdz time
<Kamion> mdz: error dialogs, you mean the ones d-i throws up?
<Kamion> mdz: db_input a question whose template has type 'error', then db_go
<Kamion> if you've turned on the backup capability then db_go will return 30 on backup, and exit 10 from a postinst to backup to the main menu
<Kamion> the priority of any error question is forced to critical
<Kamion> that's about it
<mdz> Kamion: yes, those, thanks
#ubuntu-devel 2005-01-23
<lamont> niif
<lamont> hrm..  off by one
* Kamion finishes cdebconf patch for background titles
<lamont> lqtplay.c:32:31: X11/extensions/Xv.h: No such file or directory
<lamont> lqtplay.c:33:34: X11/extensions/Xvlib.h: No such file or directory
* lamont grumbles, looks around for daniels
<daniels> libxv-dev
<lamont> yeah - libquicktime's bad, it appears.
<lamont> then again, it's not an ubuntu version.
<daniels> heh
<lamont> btw, do these get forwarded to debian, or are they ubuntu specific bugs?
<daniels> ubuntu-specific
<lamont> ok
<mdz> lamont: new cloop builds?
<lamont> should have finished a while back - checknig
<lamont> Kamion: your turn
<Kamion> building
<jdub> http://www.apple.com/macmini/
<jdub> hmm
<doko> lamont: pong. unable to reproduce the libunwind load error.
<mjg59> jdub: Yeah, it's quite cute
<Mithrandir> jdub: that one's _cute_---
<Mithrandir> s,---,,
<mjg59> It'll be interesting to see how the x86 manufacturers respond
<jdub> definitely a leap ahead of the shuttle
<jdub> i wonder if they'll start doing laptop cd drive ports
<__daniel> hai mxpxpod :-)
<mxpxpod> __daniel: ?
<__daniel> mxpxpod: wally@irc.gnome.org - you're right... i should try to stick to ONE nick :-)
<mxpxpod> __daniel: heh
<lamont> mdz around?
<lamont> doko: trying to remember what failure it was...sigh
<mdz> lamont: yes
<lamont> been thinking about ubuntu-meta
<lamont> one option that would help non-dc architectures would be to have the seeds in the package, and let the arch-specific build do the rest of update
<lamont> and we probably wind up needing a per-arch exclusion list, for things like oo.o (where making things currently arch-all into specific really doesn't make sense...()
<lamont> thoughts?
<lamont> the alternative is to teach update the canonical location of each non-dc arch build.
<Kamion> hm, makes it a bit hard to tell history from the source package
<Kamion> I think I prefer your latter option
<lamont> that's the downside to the first option
<lamont> as a hybrid, the build process could be enhanced to build the list from the local cache Packages files in the case where {base,desktop}-$arch don't exist in the source.
<lamont> that gives us our history for dc builds, and flexibility for non-dc builds, with the downside on history
<Kamion> update just calls germinate, right? all that needs is a mirror ...
<lamont> on the exclusion list, that's the current borkage of the livecd build for ia64.
<lamont> update doesn't call germinate - it fetches the seeds
<Kamion> gar, yeah, true
<lamont> and parses that, then removes anything not in the Packages lisdty
<lamont> so it fetches seeds and Packages files for main,restricted for each arch
<lamont> so if the source package had the seeds (think it does...) and the component list for each dc-architecture, and logic to just use the cache Packages file to generate things if the arch isn't present in the source, I think that would fit both sets of needs
<lamont> since there may not be _one_ canonical repository for an archive, sometimes
<Kamion> the sparc and architecture: all case ...
<lamont> daniels: are these in anything specific?
<lamont>  /usr/X11R6/lib/libICE.so /usr/X11R6/lib/libX11.so
<daniels> libice-dev libx11-dev
<daniels> which are both in xlibs-dev, which should make Kamion happy ;)
<Kamion> I've been splitting my packages' build-deps up, dude :P
<daniels> lamont: more ftbfs fun?
<lamont> the same - it had warnings at the end.  libice is a missing dep, the other isn't
<lamont> at first blush, anyway
<lamont> mind you, libice-dev is a dep of a build-dep, but still.
<daniels> which package?
<lamont> it's directly ref'ed by the package, it should be a build-dep
<lamont> libquicktime
<daniels> yeah
<daniels> ahr, heh
<lamont> uploading
<lupus_> daniels, how is xcb going?
<lamont> mdz: did we decide on a ubuntu-desktop mta change?
<lamont> or jdub
<Kamion> mdz: oh, live CDs built like an hour ago, sorry, forgot to check back
<mdz> no, we haven't
<mdz> Kamion: no problem, I'm hacking away on casper
<lamont> mdz: neither have we decided to not change it?
<mdz> Kamion: if I unpack a new version of a udeb in a running d-i, how do I get the templates merged into cdebconf?
<mdz> lamont: correct
<lamont> ok.  eta end of month? or what?
<Kamion> mdz: debconf-loadtemplate d-i <templates file>
<Kamion> mdz: but udpkg -i does that automatically
<lamont> not that it makes a big diff, of course.
<mdz> Kamion: and also udpkg --unpack?
<mdz> if so, perfect
<Kamion> it's at unpack time, yes
<Kamion> the templates file gets removed before the end of unpacking, in fact
<mdz> hmm
<mdz> odd
<mdz> I unpacked a new casper-udeb in a booted d-i to test it, and it won't run the postinst
<Kamion> which won't?
<mdz> it claims that it exited nonzero, but I added an echo at the very top and it clearly isn't running it
<mdz> the main menu won't
<Kamion> selecting it from the menu?
<Kamion> perhaps a dependency?
<mdz> I haven't added any dependencies in this version, no
<Kamion> check /var/log/syslog ...
<mdz> oh, there's the output
<mdz> I thought stdout ended up on vc3
<Kamion> only of some bits
<Kamion> debootstrap, e.g.
<Kamion> mostly it's vc4
<mdz> Kamion: "succeeded but requested to be left unconfigured?" eh?
<mdz> how did I manage to break it in that particular way
<Kamion> that means you returned the back-up code
<Kamion> i.e. 10
<mdz> I only db_input once and it has || true
<mdz> db_progress can't return backup, can it?
<mdz> oh, maybe one of the subprocesses did
<Kamion> no, you probably didn't intend to return backup
<Kamion> I suspect you forgot to check the exit code on a debconf command which happens to have 10 as one of its exit codes
<mdz> hm, no, I emit a debug message before running each one
<mdz> and none of them came out
<Kamion> 10 is CMDSTATUS_BADQUESTION
<mdz> hmm
<Kamion> generally meaning a template wasn't registered properly
<daniels> lupus_: good, I think
<mdz> Kamion: it is annoying that the debug/error output from casper is normally scrolled off the screen by the main-menu DEBUG
<mdz> Kamion: is there a way to turn that off?
<lifeless> does this matter:
<lifeless> Setting up nautilus (2.9.2-0ubuntu1) ...
<lifeless> ** (process:27059): CRITICAL **: egg_desktop_entries_add_group: assertion `egg_desktop_entries_lookup_group (entries, group_name) == NULL' failed
<lifeless> ** (process:27059): CRITICAL **: egg_desktop_entries_add_group: assertion `egg_desktop_entries_lookup_group (entries, group_name) == NULL' failed
<lifeless> ** (process:27059): CRITICAL **: egg_desktop_entries_add_group: assertion `egg_desktop_entries_lookup_group (entries, group_name) == NULL' failed
<lifeless> Setting up gnome-applets-data (2.9.4-0ubuntu2) ...
<Kamion> mdz: I usually do 'tail -n <whatever> /var/log/syslog' on the shell on tty2 rather than relying on tty4; then I have scrollback
<Kamion> mdz: I don't think busybox syslogd is configurable enough to suppress debug-priority messages
<mdz> ok, I'm at a point where I need an un-broken live fs to play with
<lamont> what was the command that dumps X events to stdout?
<crimsun> xev?
<daniels> xev
<daniels> either that, or snooping on /tmp/.X11-unix/X0 :)
<lamont> yeah
* lamont has 20 new buttons to play with...
<lamont> daniels: so can I tell X to launch an app when a key is pressed?
<lamont> 129 key wireless keyboard/mouse.
<daniels> lamont: apt-get install hotkeys
<daniels> or i think gnome has a hotkey daemon that isn't as ghetto
<daniels> ditto kde
<lamont> keyboard shortcuts?
<lamont> yep
* lamont goes to fire training
<tseng> sucks about the wifi applet being replaced by netstatus
<lamont> hrm...  wvstreams appears to have dropped wvstreams-gtk package.
<lamont> wonder if I care...
<mdz> Kamion: what are you doing awake?
<mdz> Kamion: I've uploaded a casper 0.8 with the changes we discussed; it contains symlinks to the prebaseconfig.d and base-installer.d stuff for now, but it's easy enough to transition to having those symlinks in the other udebs
<mdz> once it's built, I intend to fire off live CD builds and test them later tonight
<Kamion> mdz: I have absolutely no idea, about to go to bed :)
<Kamion> ok, cool, let me know if anything goes wrong with you running the build
<mdz> lamont: builds should show up at :15 or so, yes?
<Kamion> I've been buried deep in cdebconf all day, only just emerging
<mdz> I need to tackle the dpkg-reconfigure problem next
<mdz> Kamion: this redesign reduced the XXX count in casper by a large margin
<lamont> mdz: cron.daily runs at :03 (and:33), however there is time involved in getting from the master to the archive servers
<mdz> only 7 remain
<lamont> so yeah, by :15 :45 they're there
<mdz> was neary double that before
<mdz> -rw-rw----  1 mdz mdz 299 2005-01-11 19:44 ../casper_0.8_source.upload
<Kamion> mostly I am grappling with twalk() being SHIT
<mdz> I think that's a side effect of C being shit
* lamont giggles...
<lamont> wvstreams is ftbfs: build-deps universe.... sigh
<lamont>   libxplc0.3.10 libxplc0.3.10-dev
<lamont> mdz: do I drop that, or do we promote it?
<mdz> wvdial, how I hate thee
<mdz> lamont: can we make it optional?
<lamont> dunno -will look
<mdz> that would be the preferred option
<Kamion> mdz: no, there are much better approaches to such APIs in C, twalk() just doesn't use them 'cos it's stupid
<Kamion> private data arguments are perfectly standard in C, but ...
<lamont> mdz: looks to be easy to drop - you want it gone then?
<mdz> lamont: yes
* lamont has no clue what xplc is, of course...
<mdz> lamont: we use very little of what's in wvstreams
<mdz> only enough for wvdial
<mdz> Kamion: is there any delay between when things show up on ftp://archive.ubuntu.com and when they're usable by a cdimage build?
<Kamion> no
<Kamion> cdimage syncs from archive.ubuntu.com directly
<lamont> Kamion: does the cdimage build pull from archive.ubuntu, or j.w.h.c?
<Kamion> err, actually mirnyy but don't tell anyone
<Kamion> lamont: m.u.c
<lamont> Kamion's gonna get in trouble.... :-)
<Kamion> hey, that was authorised
<lamont> lol
<mdz> lamont: it's past :15, where are my builds :-P
<mdz> I need to go buy food, and want to start this download before I go
<lamont> you uploaded at :44, source appeared at :03, builds started within 5 of that.  binaries (assuing < 20 minute build...) will be there at :33, visible in the archive shortly thereafter.
<mdz> GAH
<lamont> remember, it takes 2 days...
<lamont> hrmpf.
<mdz> can you give me a reasonable guaranteed time so I can queue this build?
<lamont> configure: WARNING: Valgrind is missing.
<lamont> configure: error: Required dependencies missing: XPLC
<lamont> make: *** [config.status]  Error 1
<lamont> maybe we don't get to just drop xplc.
<mdz> :40?
<mdz> :45?
<lamont> 40 almost certainly, 45 for sure.
<mdz> the build for casper takes about 5 seconds
<lamont> all 3 architectures?
<mdz> yes
<lamont> casper is arch: all, so it's sitting there uploaded, waiting for cron.daily to run at :03
<lamont> er, :33
<lamont> with gigabit, I'd say 40 is almost certain to be good.  45 is a good safe hedge bet
<lamont> so about xplc...
* lamont puts wvstreams back on the shelf to let mdz go get food
<lamont> mdz: a fair number of those universe ones are from the tiff crap... should we just sync those in?
<lamont> if that was the change, that is...
<sivang> don't we have "PENDING" in bugzilla anymore?
* sivang wants to set a bug "resolved", and "PENDING" cause it's pending a new released upstream version.
<fabbione> morning
<sivang> fabbione: morning, you kenrel sacrafice maker :)
<fabbione> eheh
<sivang> fabbione: I really liked your goddish text - I thouhg of adopting it to use for my own needs :)
<fabbione> aahha
<sivang> fabbione: anything good tunred out from last night
<sivang> fabbione: kenrnel meeting ?
<fabbione> well yeah
<fabbione> we manage to define some bits of the team
<sivang> fabbione: ah nice, so you would get some load off eventually.
<fabbione> hopefully
<crimsun> at least you'll have a nice 2-wk break in Feb :)
<sivang> fabbione: so you could go and visit those huge turtles :)
<fabbione> crimsun: i am really looking forward to it
<fabbione> i am very very tired
<crimsun> I can imagine
<fabbione> sivang: + sealions and galapagos penguins
<fabbione> i read somewhere that there are 2 kind of birds called the "Blue tits" and "Red tits"
<fabbione> when i read it i imagine half woman brest running around on 2 blue little tiny feet
<fabbione> and the other half with red feet
<fabbione> it took me a hour to stop laughing
<sivang> hehehe
<sivang> fabbione: you need some time off the kernle...
<fabbione> s/kernel//
<fabbione> i need time off. <- full stop
<sivang> hehe right
* fabbione gives a spin to distcc
<mdz> lamont: yes
<sivang> haggai: thanks for kubuntu, I can now use konqeuror for (80%) the israeli non standards conforming websites :-)
<fabbione> mdz: what's the situation with livecd and co?
<fabbione> do i have greenlight for -6?
<mdz> fabbione: I reworked casper a lot today
<mdz> just built new images
<mdz> downloading them now to test
<fabbione> mdz: ok
<fabbione> ah cool! i got a bunch of merging bugs....
<mdz> I just bought a new pack of DVD+RW
<mdz> so I can have live + install CDs for every arch
<mdz> lamont: if you're around, these images could use an extra download+test
<mdz> fabbione: do you have good bandwidth at your new house?
<fabbione> mdz: a couple of megabit
<sivang> mdz: casper can also be used to create install cd layouts for image creation?
<mdz> sivang: no, casper only deals with setting things up
<mdz> you provide your own filesystem image
<fabbione> mdz: what would you like me to do?
<sivang> mdz: ah ok, so what is it's main functionality?
<mdz> ROCK
<mdz> i386 and amd64 live CDs are good
<mdz> except for this network detection bug
<mdz> fabbione: if you could test the live CDs, that would be great
<fabbione> mdz: i have them mirrored locally.. when did you do the last build?
<fabbione> (i can test i386 only)
<mdz> fabbione: 30 minutes ago
<mdz> if you mirrored earlier today, then it should be fast (same filesystem image, different udebs)
<fabbione> syncing the mirror now...
<fabbione> yup
<fabbione> ubuntu mirror run every 4 or 6 hours...
<fabbione> and the last was at 6:30
<fabbione> so one hour ago more or less
<mdz> powerpc worked for me
<mdz> there is this problem with network detection
<mdz> but that seems like a d-i problem
<mdz> live CD stuff is working great
<fabbione> mdz: burning now...
<fabbione> elmo: please sync ispell-lt-1.1 from unstable
<daniels> fabbione: sup?
<fabbione> daniels: not much.. doing some merge-o-matic stuff
<fabbione> BAHHHH
<fabbione> i fucked up this upload....
<daniels> fabbione: heh :)
<daniels> fabbione: you were looking for me earlier?
<fabbione> daniels: only for the Horiz Vert bug.. but i saw it is still open.. so not really...
<daniels> ahr
<daniels> which one?
<fabbione> for the nv driver
<daniels> which one?
<daniels> oh, cool
<fabbione> i can't remember the number now.. but you wrote that it will be fixed in ubuntu10
<daniels> yeah, i'm on it :)
<daniels> yeah, I typoed it
<fabbione> so i didn't really worry about it
<daniels> or thinkoed, rather
<daniels> Option "HS" "xx-yy" instead of HS xx-yy
* fabbione waits for katie to tell him that he is an ass
<fabbione> ah great!
<fabbione> now.. even my most stupid debian package got a security bug
<fabbione> JEEEEEEEEEEEEEE
<fabbione> wow... katie accepted the upload....
<fabbione> this is soooo wrong...
<fabbione> whevet...
<fabbione> whatever...
<Riddell> when I upload packages how do I specify which repository the are for (main, universe etc)
<mdz> daniels: how are you feeling?
<fabbione> bah... this DVD burner is taking ages to write the cd
<daniels> mdz: shit
<daniels> mdz: but I am working on Debconf stuff
<mdz> daniels: you have bandwidth now, right?
<daniels> mdz: yeah
<daniels> i'm actually capable of coherent trains of thought today
<mdz> daniels: you can download the current daily live CD and use it to test in the real environment
<mdz> though there is this debconf issue we need to sort out
<fabbione> something is really wrong on the machine
<mdz> probably the best way to do it would be to add a script at /usr/lib/casper/pre.d/80xconfig or so
<fabbione> KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1348)
<fabbione> KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1284)
<fabbione> recvmsg bug: copied 99770FBC seq 99771550
<mdz> which chroots into /target and does its business
<mdz> hmm, no, that won't work
<mdz> daniels: the problem is, we're running under cdebconf in the initrd at the time, and want to invoke dpkg-reconfigure in the target system
<mdz> normal debconf in the target may not even run
<mdz> and cdebconf doesn't know about the xserver-xorg templates
<mdz> easiest to just let it boot all the way, and then use dpkg-reconfigure, I suppose
<daniels> tried to so the clearing stuff yesterday, ended up with 'for i in $(cat debian/xserver-xorg.templates.in); do db_reset 3816; done'
<mdz> that'll avoid that issue
<daniels> a) we don't have templates.in on the install sstem b) even if we did, that didn't work, c) resettign a bug number is difficult
<daniels> mdz: yeah, I'm modifying the semantics to just clear everything if we're running with XORG_FORCE_PROBE
<mdz> sounds good
<daniels> mdz: since the system is seemingly useless with XORG_FORCE_PROBE (note the renaming) but previously-set templates
<fabbione> mdz: the alsa-utils merge-o-matic has done a mess....
<fabbione> mdz: i need keybuck to rerun it properly with the versions that are currently in the archive
<randabis> howdy
<fabbione> mdz: booting now the live CD
<fabbione> mdz: no network here... i think it is the same bug you mentioned before
<randabis> I was just wondering if any of the developers were here, and if they were aware of the problem with installing themes using the themes applet using the latest updates in hoary
<mdz> fabbione: yes, I'm not sure what happened; that worked before
<mdz> Kamion will probably have an idea when he wakes
<mdz> I mailed him already
<fabbione> mdz: did you do a debdiff on the .udebs?
<mdz> fabbione: which, all of them?
<fabbione> the nic-* stuff?
<fabbione> perhaps the modules are missing...
<mdz> no, they're there
<mdz> if I modprobe the right module, it works
<fabbione> mdz: i am sorry.. i don't remember all the names...
<fabbione> ah ok
<fabbione> mdz: well it boots.. no X
<mdz> ddetect has barely changed
<mdz> fabbione: yes, we need to resolve this debconf issue, and also daniels needs to finish his work
<mdz> then we should be able to do X
<fabbione> cool
<fabbione> i need to fix the e100 driver and so some tests
<mdz> fabbione: if you copy in a working config, you can do /etc/init.d/gdm start
<fabbione> ok
<fabbione> it works....
<calc> are there any plans to remove libfam, it seems that some things don't like using libgamin, or perhaps its just dselect being a pita
<fabbione> but we need to change some of the d-i entries..
<fabbione> it looks scary with "Ubuntu Install will take over your machine"
<calc> er don't like using libgamin as the provides for libfam i meant to say
<calc> eg i tried to install kde dev libs and it tried to remove all of gnome on ubuntu :\
<mdz> fabbione: yes, I mentioned this to Kamion
<mdz> fabbione: suggestions for a better title are welcome
<mdz> calc: they don't work, or the dependencies just don't resolve?
<fabbione> mdz: we could hide them in somekind of "Preparing to boot the Live CD"
<mdz> fam is already moved out to universe
<calc> it appears dselect wants to remove them since the packages want libfam instead of accepting the fact that libgamin provides libfam
<bob2> yay
<mdz> fabbione: I would prefer to just make it generic, and say "loading components" or something
<bob2> aspell-de is arch:any!
<mdz> calc: do they have versioned deps or something?
<calc> mdz: i added universe to grap some of the kde stuff for dev which is when it started causing issues
<calc> no, i forced it to stop using libfam by manually selecting libgamin and all of gnome again and it worked
<calc> so perhaps its just dselect being braindead
<fabbione> mdz: that too...
<mdz> fabbione: that is less scary than when it says "Sending all processes the KILL signal" :-)
<fabbione> yeah i saw that too :-))))
<calc> KILL ALL HUMANS :)
<mdz> ah, I see the bug in hw-detect
<calc> i wonder if the issue is since libgamin provides a package that really exists (non virtual package) that dselect decides to use the real one instead (higher priority) even when the package providing it is already installed
<mdz> fix is on the way
<jdub> calc: hrm, what's the problem?
<mvo_> what's the consensus with python? will python2.{1,2} go away? should I remove the building of python2.{1,2} packages in the merge I'm just doing (python-musicbrainz)?
<mdz> mvo_: yes, we intend to remove python2.1 and python2.2
<calc> jdub: if universe is added to sources.list and you try to install kde in dselect the fact that libgamin provides libfam doesn't matter dselect tries to remove libgamin and all of gnome along with it
<calc> if you manually go back and select libgamin and all of gnome it works ok
<mdz> calc: does it work if you use aptitude or apt-get?
<calc> perhaps i should mention to kubuntu people to have it build with libgamin instead
<calc> mdz: not sure didn't try that
<mdz> would be good to narrow it down
<jdub> calc: i thought they already did that
<calc> i'll try to see what was attempting to pull in libfam
<calc> i installed kde-core kde-devel and something in that did it
<mvo_> mdz: thanks
<calc> appears libfam0c102 is in all kde deps
<mdz> mvo_: however, I don't think anyone is currently working on fixing the packages to make that possible
<mdz> mvo_: (hint, hint)
<mdz> 4 versions of python is too much, I think :-)
<mvo_> mdz: :) I totally agree
<calc> or a very large amount of them
<mdz> fabbione: ddetect fix confirmed and uploaded
<mdz> too late for this morning's live CD build, though
<calc> kdeedu, kdevelop3, kdetoys, koffice and perhaps others, just from looking at rdeps list that is some i can see needing to be recompiled with it
<mdz> if I am still awake when it builds, i will kick off a new live CD build
<calc> it appears that kdelibs itself is compiled against gamin already
<fabbione> mdz: cool
<jdub> calc: ah
<Riddell> calc: none of those pages have been updated to 3.3.2 ubuntu versions
<calc> ok
<calc> then thats another good reason to update them ;)
<mvo_> mdz: it looks like we have ~200 packages (including universe) depending on python-2.{1,2}
<mdz> mvo_: how many in main?
<mvo_> mdz: around ~10  it seems
* calc tests his script
<calc> only 4
<calc> bluez-utils
<calc> pychecker
<mvo_> looking closer it seems: pychecker, python-docutils, python-epydoc (build with python2.{1,2} support
<calc> python-defaults
<calc> python-numeric
<calc> the rest are built into python2.1 and python2.2 source (afaict)
<mdz> mvo_: oh, that is not very many at all
<mdz> mvo_: would you take care of those 10?
<mvo_> calc: bluez-utils only suggest python2.2
<mvo_> mdz: sure
<calc> ah hmm my script needs more work then :)
<mdz> thanks
<mvo_> calc: what kind of script is it (/me curious :)
<calc> ugly one
<calc> apt-cache showpkg $1 | grep ,$1 | cut -f 1 -d "," | cut -f 3- -d " " | sort | uniq | xargs apt-cache showsrc | grep ^Package | sort | uniq | cut -f 2- -d " "
<mvo_> mdz: zope (in universe) depends on python2.2 :/
<mdz> mvo_: but zope2.7 depends on python2.3
<calc> it spits out source packages for anything that shows up as a rdep
<mdz> and according to SteveA we should only ship zope2.7 and not zope
<mvo_> mdz: ah, cool!
<calc> which was why it caught a suggests
<calc> ah several things rdep on 2.3
<mvo_> calc: I'll use it to cross-check my results, thanks!
<calc> the 4 i posted were just for 2.1/2.2
<calc> abiword dictdlib epydoc libglade2 nevow pychecker python-defaults python-numeric python2.3 swig1.3 twisted
<calc> that is what 2.3 shows up
<calc> mvo_: came in very handy in the past when i would break libraries in debian ;)
<calc> so i would know what i had to nmu afterwards ;)
<mvo_> calc: hehe :)
<mvo_> hi pitti 
<pitti> sivang: morning!
<pitti> sivang: just read that the new gst upstream is out now. Congrats!
<pitti> Hi everybody!
<fabbione> hey pitti
<pitti> Hi my dear fabbione! :-)
<pitti> Hi mvo_ 
<doko> morning all
<fabbione> ok
<mdz> pitti, doko: morning
<pitti> Hi mdz!
<mdz> pitti: please follow the status of that rosetta import thread, so that we know what to do about language packs
<pitti> mdz: regarding the PHP4 merge
* calc bbl
<pitti> mdz: oh, I do :-)
<pitti> mdz: I did not forget about merging php4, but you said that 4.3.10 was somehow broken, so we should not merge it for now
<mdz> pitti: is that still not fixed?
<pitti> mdz: I will evaluate that today again
<mdz> pitti: #288672 is the bug I think
<doko> mvo_, mdz: I'll take care of dropping 2.1 and 2.2 for python-{crypto,docutils,sqlite,unit,xml} today
<mdz> doko: ok
<mdz> thanks
<pitti> mdz: I will install the Debian version on my machine today and will try that out
<pitti> mdz: btw, can we still (manually) sync Debian revisions (no new upstream) if they contain fixes?
<pitti> mdz: i. e. I fix a security bug in Warty, but just sync the fix to Hoary?
<mdz> pitti: yes
<mdz> pitti: are there really packages which are identical in warty and hoary?
<pitti> mdz: no, I mean if the same vuln is fixed in sid, I would just sync it to Hoary
<mdz> pitti: oh, s/warty/sid/
<pitti> mdz: not necessarily in the same version
<pitti> mdz: ?
<mdz> pitti: <pitti> mdz: i. e. I fix a security bug in Warty, but just sync the fix to Hoary?
<fabbione> pitti: the last cupsys upload you did in hoary is FTBFS
<pitti> mdz: where to apply this substitution?
<pitti> fabbione: uh thanks, I look at it
<mdz> pitti: the last message I pasted
<pitti> mdz: I do a warty-security upload and fix hoary by syncing a fixed sid version
<mdz> pitti: that would require that the warty-security version be newer than the hoary version
<pitti> mdz: sorry, now I'm completely confused
<pitti> mdz: warty has 1.0ubuntu1, I fix it by warty-security 1.0ubuntu1.1
<pitti> mdz: hoary has 1.5-1, sid fixes this in 1.5-2
<mdz> pitti: then you can't sync that into hoary unless hoary has 1.0ubuntu1 as well
<pitti> mdz: so I sync 1.5.2 to hoary to fix hoary
<mdz> pitti: ok, yes
<mdz> pitti: it sounded like you were saying you would sync from warty->hoary
<mdz> pitti: but you are saying upload to warty, and then sync sid->hoary
<mdz> syncs from sid are OK as long as they are justified
<mdz> upstreamversionfreeze means that we don't blindly sync :-)
<pitti> mdz: right, that's what I meant
<fabbione> mdz: i asked the ispell-lt sync it merges our changes.. and it was queued before UVF. it would be silly to upload it manually...
<seb128> jdub: around ?
<seb128> mdz: do you have the admin rights on bugzilla ? Could you add a product for update-manager/update-notifier ?
<mdz> seb128: yes
<seb128> thanks
<mdz> who should the default assignee be for update-manager?
<seb128> mvo_ ?
<mvo_> mdz: me
<mdz> ok
<seb128> mvo_: I've a crasher with it
<mvo_> seb128: again? crap :/
<seb128> mvo_: backtrace in its way :p
<mdz> done
<mvo_> seb128: thanks
<seb128> thanks mdz 
<mdz> I have a script somewhere to create components for al lpackages in main
<mdz> I need to run it
<seb128> would be nice yeah
<seb128> and is there any way to create the team/list stuff
<seb128> or to assign all the GNOME stuff to me by default ? You reassign quite a number of bugs (and sometime some are forgotten), that should not be necessary
<mdz> seb128: I think I have most of them set to you now
<seb128> (I've found some bug assigned to debzilla for weeks on GNOME stuff while searching on the list)
<mdz> if you notice one that does not go to you by default, which should, let me know
<seb128> ok
<mdz> it is just a pain to do it with the bugzilla UI
<mdz> there is no easy way to do it for 50 packages
<seb128> mdz:  gedit gtksourceview devhelp glade-2 gconf-editor gnome-terminal gnome-gv gnome-utils gnome-keyring
<seb128> some examples
<seb128> gnome-nettool
<mdz> seb128: each one that I change requires about 1 minute of loading 300k bugzilla pages :-)
<mdz> I was sure I did gnome-terminal already
<seb128> so that didn't work :p
<seb128> I've just tried in the "New bug" page
<mdz> fixed now
<fabbione> hmmmm 2.6.11-rc1 is out
<mdz> also gedit
<seb128> didn't work neither so :)
<seb128> mvo_: bug sent
<mdz> bah, I can't stay up waiting for this build
<mvo_> seb128: thanks
<seb128> np
<mdz> fabbione: please ask Kamion to do a new live CD build with ddetect  1.11ubuntu3 when he wakes up
<mdz> good night
<seb128> let me know if you get it, quite easy to get here, just click on check box in the list
<fabbione> mdz: i will. good night
<seb128> 'night mdz 
<mvo_> seb128: any crashes with the new update-notifier yet :) ?
<mvo_> night mdz
<seb128> mvo_: not yet, neither with the old one since I rebuilt a debug version :p
<pitti> night mdt
<pitti> night mdz
<seb128> hey pitti 
<pitti> Hi seb128!
<pitti> seb128: btw, did you hear any news about gnomevfs + HAL?
<mvo_> seb128: I rewrote some code that _may_ have caused the problem. so with a bit of good fortune, the problem is gnoe :)
<mvo_> seb128: and it's much more responsive now
<seb128> pitti: no, some people have had the panel lock issue with the non-hal version of gnome-vfs (ie: mdz)
<seb128> so I'm not even sure that's due to hal ...
<seb128> mvo_: cool, you keep rewritting it or what ? most of the bugs I've filled should be "fixed with luck in the rewritten code" :p
<mvo_> seb128: I keep improving it ;)
<mvo_> apt is not very helpfull when it comes to "when is a apt-get update" finished (or even started)
<seb128> BTW do you get this crash with 0
<seb128> 0.35
<mvo_> it's a bit tricky to catch that
<mvo_> seb128: yes, I reproduced it here
<seb128> ok, cool
<mvo_> seb128: the update-manager crash looks like a python-gtk problem ... the same code works on my warty system
<seb128> that's possible yep
<seb128> I was thinking that it may come back when I opened it :p
<seb128> if you have a test case please reassign :)
<mvo_> seb128: I'll build a (small) testcase and give it back to you :)
<seb128> thanks
<pitti> mvo_: now I dist-upgraded to get the new update-notifier
<pitti> mvo_: but now I can't test it any more since no new upgrades are available any more :-)
<mvo_> pitti: if it's not showing now, that's a good sign :)
<mvo_> keep apt-get updating and see if it comes back :)
<pitti> mvo_: which part automatically does apt-get update?
<mvo_> pitti: no part of update-notifier. it just installs a apt config file that will trigger a daily apt-get update
<seb128> bah, synaptic does some weird stuff
<mvo_> but it will detect if you call apt-get update by hand (or aptitude update or synaptic)
<mvo_> seb128: how so?
<pitti> mvo_: this is already done now?
<pitti> mvo_: in cron.daily?
<seb128> whe you" update package list" ... it displays first "download 1/1", then "1/2", then "1/10"
<seb128> why 3 differents numbers ?
<mvo_> pitti: in /etc/apt/apt.conf.d/99update-notifier
<seb128> you are thinking "cool, it's updated" and it starts with a new set
<mvo_> pitti: apt has a job in cron.daily (it can do other things like cleaning the list too)
<mvo_> seb128: it's actually a apt problem. when you look at how apt-get update displays, it's the same. but I agree that it sucks :)
<seb128> ok :p
<fabbione> elmo: you alive?
<pitti> Hi carlos!
<carlos> morning
<mjg59> thom: Ping?
<thom> mjg59: ack with great justice
<mjg59> thom: Did you get the list of ACPI hotkey events?
<thom> i saw it
<thom> only just got dsl at home, so will grab in a second
<mjg59> Ok, cool
<Mithrandir> seb128: can I make nautilus understand that volumes on the desktop should appear on the right hand side, somehow?
<rburton> Mithrandir: no
<seb128> I don't think so
<Treenaks> that's Bad
<Treenaks> Mithrandir: use a RTL locale?
<Mithrandir> seb128: any chance og getting it implemented, or should I rather just grumble and search for the icon each time I put in a cd?
<seb128> the todo list is long for nautilus but I guess that could be done yep
<kent> Bug 5443 Submitted
<seb128> not sure on how to do an UI for this BTW
<trukulo> Mithrandir: man, you have jeff-have-a-small-dick.avi uploaded
<seb128> kent: you count the bug arriving in bugzilla ? :p
<kent> seb128, i have nothing better to do ;)
<Mithrandir> seb128: no idea -- I would be happy with it just being in gconf, but that's me.
<fabbione> trukulo: ahahha
<trukulo> lol
<fabbione> trukulo: how did you know he has?
<trukulo> it's recorded in video
<trukulo> heheheh
<seb128> Mithrandir: yep, I'll ping upstreams to know what they think
<Treenaks> seb128: I guess the same is true for "text besides icons" on the desktop?
<Treenaks> instead of text-under-icons
<Mithrandir> seb128: ok, coolie.
<Mithrandir> trukulo: ok, seeded.
<trukulo> :) thanks
<seb128> Treenaks: ??
<fabbione> how many are missing?
<seb128> oh
<trukulo> 5
<seb128> dunno abouyt this
<trukulo> fabbio-small-arsehole.avi
<trukulo> hehehhee
<trukulo> and big ones
<fabbione> true.. my arsehole is small
<fabbione> :-)
<trukulo> fabbio-big-goatse.avi and the other ones
<trukulo> i'm very bad today, i need my pill
<fabbione> trukulo: damn! you got me!
<fabbione> ehhehe
<trukulo> fabbione: if you understand spanish, i would show you what i wrote today on a friend's blog
<trukulo> and he doesn't know it
<trukulo> hehehe
<trukulo> perhaps you can understand something, or try to translate the web
<trukulo> http://www.tomedo.net/node/608
<fabbione> i can try
<fabbione> ahahah it's very difficult to translate it
<Mithrandir> mvo_: any ideas around what the interface for update-notifier should look like?  The "please make the user run this app"-interface.
<trukulo> umm, very near with babel
<sivang> pitti: thanks martin! How are you today? :)
<sivang> pitti: did it get packaged already?
<pitti> sivang: fine, just made cupsys work again
<trukulo> fabbione: http://translate.google.com/translate?u=http%3A%2F%2Fwww.tomedo.net%2Fnode%2F608&langpair=es%7Cen&hl=es&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools
<pitti> sivang: not yet, but seb128 knows about it and will certainly do it soon
<trukulo> more less :(
<trukulo> perhaps with italian you understand it well
<mvo_> Mithrandir: kind of, I'm thinking about just showing a different icon with a information symbol. I wonder how we should design the general conecpt though. 
<seb128> people are never happy, aren't they ?
<sivang> pitti: ok , great ! 
<Mithrandir> mvo_: I was more concerned about the interface I (as a package maintainer) will be using.
<pitti> seb128: no worries; but the next g-s-t upstream release is supposed to fulfill a critical hoary goal :-)
<Mithrandir> putting a file in /var/lib/upgrade-notifier/user.d which is a shell script or some kind might be an idea?
<pitti> seb128: sivang put lots of effort into it, so he is natually a bit eager to see it
<sivang> seb128: sorry, didn't mean to make you upset...
<seb128> pitti: I've packaged like 40 tarballs since monday, I get some hours of sleep and people keep speaking about a tarball released during the night
<seb128> pitti: dude, that's not even release for 10 hours
<seb128> released
<seb128> and I already got a bug pinging me and now IRC, calm down people :)
* Mithrandir gives seb128 a beer
<fabbione> seb128: so? where is the new gnome?
<seb128> sivang: np but be patient please, I don't think I'm slow to package new versions
<pitti> seb128: hey, I don't want to urge you
<fabbione> 10 hours? for that looong and no packageS?
<seb128> thanks Mithrandir 
<fabbione> omg
<fabbione> :(
* seb128 slaps fabbione 
<pitti> seb128: I was just explaining why sivang bugs you
* fabbione hugs seb128 
* trukulo gives seb128 a blade
<pitti> seb128: adduser works fine for me :-)
* sivang hugs seb128 too
* trukulo and salt
<mvo_> Mithrandir: yes, it's certainly a idea. and then we can keep track about what was already seen on a per user-basis. it needs to have a description encoded somewhere as well
<sivang> seb128: ofcourse I will, and garnacho is alwasy amazed how fast you package stuff from gnome :)
<fabbione> time to cook some food
* mvo_ cheers seb128
<Mithrandir> mvo_: yeah, so possibly a simple key=value file might be better.
<seb128> thanks guys :)
<Mithrandir> with keys being name, description, command, at least.
* seb128 packages the new gst now :p
<pitti> seb128: pleeease, that was no offence; no hurry
<seb128> pitti: don't worry, that was the next on my list, I've just uploaded wnck 2.9.4 :)
<mvo_> Mithrandir: we have to think about i18n as well :)
<Mithrandir> mvo_: name[langcode]  and such, for those, then.
* pitti is still amazed about seb128's processing speed
<mvo_> Mithrandir: yes, that sounds good!
<seb128> bah, stop guys, that's too much :p
<seb128> mvo_: ok, pygtk bug fixed upstream
<seb128> mvo_: updating the package soon :)
<Mithrandir> mvo_: you spec it on the wiki or should I?
<mvo_> seb128: man, that was quick!
<mvo_> Mithrandir: I can do it
<Mithrandir> mvo_: ok, thanks
<mvo_> Mithrandir: thanks for your input :)
<Mithrandir> mvo_: please tell me when you have support for it in u-n, I need it for U8MT.
<mvo_> Mithrandir: ok
<d3vic3> does anyone know wat package is nsgmls in ? 
<Mithrandir> sp, iirc
<d3vic3> universe ? maltiverse ?
<d3vic3> nm
<d3vic3> got it
<mvo_> Mithrandir: https://www.ubuntulinux.org/wiki/InteractiveUpgradeHooks, please check if I forgot something
<Mithrandir> mvo_: is there any reason the file should be called .hook and not just $packagename or something?
<trukulo> jdub: jeff, your video is up :P
<Mithrandir> mvo_: I don't think the scripts themselves should be stored in that directory.
<Treenaks> I'm already seeding jeff_small :)
<mvo_> Mithrandir: that was my reasoning. if you don't think the scripts belong there, we can omit the .hook
<Mithrandir> mvo_: and why would the command be optional?  It doesn't really make sense to have something without a command, does it?
<Mithrandir> mvo_: I don't see any reason why they should go to /var rather than /usr/lib/$packagename/foo or something.
<mvo_> Mithrandir: it does IMO. after a kernel upgrade it makes sense to tell the user that he will have to reboot 
<Mithrandir> mvo_: then the command will be something which offers to reboot, wouldn't that make sense?
<trukulo> :)
<mvo_> Mithrandir: yes. it may be easier to just tell the user what to do (my two use-cases for this are: gnome upgrade that needs a relogin and kernel upgrades). in both cases it's IMO not really needed to present a actuall script
<Mithrandir> mvo_: notification icons should do something when clicked, shouldn't they?
<mvo_> Mithrandir: yes, they will show a dialog with the description in the hook file
<mvo_> and a optinoal "do this now" button :)
<Mithrandir> mvo_: hm, ok.
<Mithrandir> mvo_: we need another way to handle description then, if so.
<Mithrandir> I was thinking description = tooltip.
<Mithrandir> since it can potentially be multiple paragraphs.
<mvo_> what about adding a tooltip parameter?
<mvo_> if no tooltip key is given, it just uses the descripiton?
<mvo_> I don't mind if it's /var or /usr, /var looked more "natural" to me (and you suggested it in the first place :) 
<Mithrandir> yeah, for the hook files, but not for the scripts.
<mvo_> Mithrandir: ok, that was a misunderstanding. I agree that the scripts should not go into /var
<Mithrandir> how do you think we should handle long descriptions?
<Mithrandir> we could use rfc822 rather than key=value
<Mithrandir> mvo_: ^^
<mvo_> Mithrandir: yes :) I had hoped to use the xdg parser
<mvo_> so that I get the key[locale]  stuff for free
<mvo_> but for multiline rfc822 is better
<Mithrandir> the alternative is letting it be a filename where the text is stored.
<Mithrandir> one file per language.
<mvo_> it means we needs something like "Description.LOCALE:"
<Mithrandir> smells of debconf
<mvo_> Mithrandir: one file per language is not optimal either
<mvo_> Mithrandir: yes :)
<Mithrandir> mvo_: I don't know if you can lift code off debconf for it, possibly?
<mvo_> Mithrandir: staying close to debconf may be a good idea because we may be able use reuse their tools (debonf2pot) for example
<mvo_> Mithrandir: cdebconf most likely. I should talk to Kamion about it 
<Treenaks> Mithrandir: how's the next .avi coming? (after jeff_small :))
<Mithrandir> the rfc822 parser in cdebconf is fairly trivial.  I think it's about five lines of C.
<Mithrandir> (plus the i18n stuff)
<mvo_> Mithrandir: cool!
<Mithrandir> Treenaks: it dropped after 54M, so the small fabio started -- about 6.5MB done on that.
<Mithrandir> mvo_: rfc822 is _simple_ to parse.
<Mithrandir> not just fairly easy, but _really_ simple. :)
<Mithrandir> mvo_: what's u-n written in?
<Treenaks> Mithrandir: uh.. I seem to have everything of jeff_small
<mvo_> Mithrandir: C
<Mithrandir> Treenaks: yes, but you don't have all of mshuttleworth_big. :)
<Treenaks> Mithrandir: true :)
<Mithrandir> mvo_: ok, lifting the code should be fairly easy, then.
<mvo_> Mithrandir: yeah
<mvo_> I change the spec accordingly
<seb128> pitti: gnome-system-tools 1.1.4 packaged but there is some issues to fix before uploading (ie: an add user is only in its group by default and the services build is done even if turned to off in the configure)
<pitti> seb128, sivang: I thought the former was exactly the problem sivang worked on?
<seb128> I thought so
<seb128> but it doesn't work here
<pitti> oops, sivan is not here
<seb128> I've pinged him on the #gst chan, waiting for reply
<fabbione> Kamion: ping?
<seb128> hum, he timeouted
<Kamion> fabbione: pong
<fabbione> Kamion: mdz asked this morning if you can rebuild the liveCD with the latest ddetect to fix the network problem
<Mithrandir> mvo_: 
<Mithrandir> mvo_: maybe you should put an example in the Wiki as well?
<mvo_> Mithrandir: yes, will do. I wonder if the tooltip is actually needed. there may be more than one new hook. it may be better to display something like "3 new post-update information availabe" 
<sivang> seb128: ping
<Kamion> fabbione: hm, will need a new initrd build for that
<Mithrandir> mvo_: hm, possibly.
<fabbione> Kamion: is it doable?
<Kamion> fabbione: /me != lamont
<fabbione> Kamion: until all this is not sorted i am stocked with the kernel
* fabbione sighs......
<Kamion> I guess I can do a null d-i upload
<fabbione> Kamion: mdz pointed at you.. lamont was around i think...
<seb128> sivang: did you read what I said on #gst ?
<sivang> seb128: lemme check
<Kamion> yeah, mdz was wrong though :)
<sivang> seb128: got disconnected, the server I was connecting through went down...:(
<Kamion> I'll see what I can do, but it also requires byhand attention from elmo
<sivang> seb128: so no.
<mvo_> Mithrandir: can you possibly add the UT8M as example? That would be nice and real-world :)
<Mithrandir> mvo_: ok :)
<fabbione> Kamion: thanks
<Kamion> fabbione: ok, uploading, we'll wait a bit for the wheels to grind ...
<fabbione> Kamion: fine for me
<fabbione> i think this is the last change mdz is waiting for before giving me the green light for the kernel
<fabbione> also because i have a bunch of security fixes to upload :-))))
<fabbione> Kamion: ah you will have to upload d-i after me.. due to the ABI change :(
<fabbione> sorry about that, but i can't avoid it
<Kamion> yes, I know, that's fine and expected :)
<fabbione> elmo: dunno if you read the scroll back.. can you sync ispell-lt from sid please
<fabbione> ?
<elmo> fabbione: it's a new upstream version?
<fabbione> yes, but it merges all our changes and the merge-omatic bug was before UVF
<fabbione> at least...
<fabbione> and mdz didn't object this morning
<elmo> did you ask him explicitly, or do you mean he didn't object when I asked for the sync?
<elmo> :)
<fabbione> i explained the reason for asking the sync and he didn't object
<fabbione> so either he has me in his ignore list
<fabbione> or i think it was ok
<fabbione> otherwise blame GTK!
<elmo> shrug, k.  I think we need to stop using irc for sync requests tho, then I don't have to keep doing this "but it's a new upstream version!" dance
<fabbione> elmo: i also added the note in the bug...
<fabbione> let me see if he added something..
<elmo> it's done, don't worry about it now
<fabbione> well.. if i am wrong i will take my responsabilities
<fabbione> thanks dude :-)
<fabbione> actually it also fixed another bug
<fabbione> so that's even more cool
<thom> elmo: please sync mozilla-firefox-locale-tr (bug #4781)
<elmo> done
<pitti> thom: sure?
<pitti> thom: what about the language packs modifications?
<thom> pitti: doesn't have any
<pitti> thom: okay, then it's probably a new language
<pitti> thom: I will modify it soon
<thom> it's been in since prewarty, but, whatever :-)
<thom> elmo: grazi
<pitti> thom: oh, then it was a too old version
<pitti> thom: anyway, on my todo list now
<mjg59> thom: Oh, yeah, the sleep scripts need to be transitioned over to using vbetool, too
<Kamion> bleh, I wonder what happened to my pbbuttonsd_0.6.6-2ubuntu1 upload of ages ago
<elmo> Rejected: pbbuttonsd_0.6.6-2ubuntu1.dsc refers to pbbuttonsd_0.6.6.orig.tar.gz, but I can't find it in the queue or in the pool
<elmo> the diff's still in queue/reject if you want it
<Kamion> elmo: yeah, I'd just got round to working out that that must've been the problem - don't worry, I've got the diff here, I'll just re-merge the last Debian change by hand
<Kamion> I must've deleted the REJECT mail though, special
<elmo> pitti: ?
<pitti> elmo: here
<elmo> pitti: got a patch for isec-0022?
<pitti> elmo: which is? 
<elmo> http://isec.pl/vulnerabilities/isec-0022-pagefault.txt
<pitti> elmo: sorry, my server with all my mails is currently down
<pitti> elmo: the failed raid, remmeber?
<pitti> elmo: I'm just at reconstructing it
<pitti> elmo: should be back in about 30 minutes
<Kamion> hooray, merges done
<pitti> elmo: yes, this was disclosed 2 minutes ago
<elmo> pitti: ok, no prob
<pitti> elmo: the next warty update will contain this
* thom is not looking forward to his firefox merge
<pitti> elmo: fabbione has the patch, too
<daniels> Kamion: my DSL is just chocking on the glibc .orig.tar.gz
<daniels> Kamion: (ubuntu archive rsync is at 50%; been going for a bit over a week now)
<pitti> elmo: I asked Herbert to upload ASAP, but he did not yet do
<elmo> ok
<daniels> OH FUCK ME
<Kamion> daniels: fun!
<Kamion> no
<zul> ditto
<lamont> moo
<daniels> i seriously need an alias on fd.o for 'disable all ssh access except mine'
<daniels> pitti: where's the patch for 0022?
<elmo> daniels: disable userdir-ldap via /etc/nsswitch.conf
<lamont> Kamion: do we need a new daily di build?
<pitti> daniels: give me half an hour to reconstruct my server
<elmo> we just had a d-i build
<daniels> elmo: doesn't cover people already logged in
<daniels> elmo: it's allow everything from my IP, drop everything on port 22
<elmo> daniels: ps auxfw | grep -v root | awk '{print $2}' | xargs kill -9 :-P
<Kamion> lamont: I just uploaded it manually, was easier
<daniels> elmo: and wipe out my own SSH access, awesome :P
<thom> rofl
<thom> the elmo school of gunboat diplomacy
<daniels> 'zsh? who the fuck needs that?'
<Kamion> oh, rock
<Treenaks> it doesn't even do utf-8 right  :P
<Kamion> ELMO, FASTEST BYHAND IN THE WEST
<lamont> daniels: fuser -mk / is much faster.
<lamont> seb128: how come autohide doesn't hide the panel anymore?
<daniels> dpkg-buildpackage: source package is glibc
<daniels> dpkg-buildpackage: source version is 2.3.2.ds1-20ubuntu1
<daniels> dpkg-buildpackage: source maintainer is Scott James Remnant <scott@canonical.com>
<daniels> KEYBUK TOUCHED IT LAST
<Kamion> Keybuk touched everything last
<Kamion> isn't that right, thom, lamont?
<thom> it's looking that way
<thom> although sadly i may have to do some work on firefox
<Kamion> make sure you leave that changelog as Scott, too
<daniels> i wonder if I can 'gift' X to him
<thom> oh, definitely. how could i blame him otherwise
<daniels> unfortunately mom doesn't touch xorg
* thom breaks his new DSL in with firefox orig
<Mithrandir> thom: how's the new house?
<daniels> Mithrandir: it has walls
<daniels> (plural)
<thom> Mithrandir: and a ceiling, most notably
<thom> it's good
<lamont> Kamion: damn near
<Mithrandir> thom: that's a good start. :)
<thom> yup :-)
<daniels> i almost owned glibc at one point
<thom> by way of a revolutionary concept for london, we have a frickin' garden too
<lamont> thom: furniture is still left as an exercise?
<Kamion> owned with a 0?
<daniels> when i was doing 4.3.0-0dsX, there were a whole slew of 'oh my god, I'm putting glibc on hold' posts
<daniels> (i don't blame them: i'd put glibc on hold if i maintained it)
<daniels> thom: you mean ... pot plants?
<thom> no, an actually garden, with a bbq
<daniels> sweet
<daniels> so you can stand around the bbq and drink cold beer in summer
<thom> lamont: fortunately, left as an exercise to the owner ;-)
<thom> daniels: it seems unlikely
<rburton> thom: a real garden?
<rburton> wow
<thom> rburton: yeah :-)
<daniels> rburton: dulwich had a fair few rad gardens
<daniels> and parks!  what's up with that?
<rburton> i know
<rburton> thom: where is the new house?
<Kamion> hm, I suppose I should test cdebconf 0.74ubuntu1 a bit before just radically changing how d-i's debconf infrastructure works
<thom> rburton: still ealing
<mjt> several major russian ISPs have blocked swip.net - some more than a year ago - due to all this, and especially due to the lack of ANY responses to abuse@.  I dunno how "important" russia for you is, really, and dunno about other countries either
<mjt> er
<mjt> mischan
* pitti pets is reconstructed server
<pitti> daniels, elmo: my server is back, shall I forward you the patch?
<pitti> daniels, elmo: as I said, the Warty update comes soon
<pitti> and fabio will upload a new Hoary kernel soon, too
<lamont> why is cyrus-sasl still showing up in main for me...
<daniels> pitti: that would be great, thanks
<lamont> (it's build-deps aren't there...)
<elmo> pitti: could you forward, and 2.4 if you have it too, please?
<pitti> elmo: I have, sure
<elmo> lamont: because it's build-deps on libtool1.4 and thatm akes keybuk cry
<elmo> I need to file a bug about it and a bunch of other stuff like that
<lamont> elmo: I said why _is_ it still in main...
<lamont> it needs to die. :-)
<elmo> lamont: I promoted it TO main
<lamont> oh
<lamont> so it needs to be fixed then\
<elmo> because tourguide promoted it
<elmo> lamont: weren't you at the BOF seed syncage hell?  it was proposed then
<lamont> but hasn't built yet, so the dep doesn't show in apt-cache. got it.
<pitti> daniels, elmo: sent
<lamont> elmo: think I was...
<thom> lamont: mono is not looking fun
<lamont> maybe I'll fix it...
<lamont> thom: I'll buy you a beer.
<elmo> pitti: obrigado
<pitti> elmo: por favore (?)
<sivang> pitti: it's thank you and brazillina port
<daniels> pitti: cheers
<sivang> pitti: in brazillian portugueese.
<pitti> ah
<sivang> elmo: you speak some of it? :)
<sid77> hi
<azeem> sivang: it's also thank you in regular portuguese, AFAIK
<thom> lamont: i'll talk to you about it in a bit, it's bootstrap time though
<sivang> azeem: yeah, but brazillian say it a bit differently
<sivang> azeem: by accent that is
<azeem> I guess :)
<elmo> sivang: no, it's the only word I learnt at debconf4 in .br is all
<thom> sivang: we tried to teach him english too
<thom> ...
<lamont> fire cal
<elmo> Rejected: ubuntu-keyring-udeb_2005.01.12_i386.udeb: architecture part of filename (i386) does not match package architecture in the udeb (all).
<elmo> mvo: ^--
<sivang> thom: who elmo? he knows english alrady no? :)
<thom> sivang: nah, that's just a tape recording 
<sivang> thom: hehe
<Kamion> mvo_: oops. get rid of all the DEB_HOST_ARCH stuff and replace $(DEB_HOST_ARCH) with all ...
<Kamion> elmo: can I upload gpgv-udeb?
<elmo> Kamion: I said yes yesterday...
<daniels> OH CHRIST WHY DO PEOPLE STILL USE SERVER-SIDE FONTS
<Kamion> oh, I missed that
<Kamion> ok, thanks
<elmo> granted with a 3 hour lag ;)
<sivang> -rw-r--r--   1 pooh  pooh  2.5M 2005-01-12 16:28 file5.txt
<sivang> ops
<sivang> sorry
<Kamion> oh, fixed live CD is up, btw
<mvo_> Kamion: ok
<Kamion> fabbione: you can go ahead and do the kernel changes now, I think
<sladen> daniels: sudo pkill -9 -v -u $USER
<daniels> sladen: ... for 270 users
<daniels> seriously, it's just easier this way :)
<fabbione> Kamion: thanks. i will wait the green light from mdz
<daniels> holy shit, acpi video which can retreive edid
<daniels> and i'm pretty sure radeons support it
<daniels> that's so phat
<kent> daniels, server side fonts?
<sladen> daniels: -9 KILL, -v NOT, -u $ME
<Kamion> -u root,$ME indeed
<daniels> kent: yes, they are an abomination to mankind
<sladen> Kamion: good point, killing init liable to cause bad stuff(tm)
<daniels> i fail to see how this is easier than the same two iptables commands i type every other day :P
<Kamion> although that probably kills a lot of daemons
<Kamion> so you'd need to init 1; init 2 afterwards probably
<Kamion> and whether you can do that remotely ... :)
<mjt> in debian the network is up in runlevel1
<daniels> Kamion: yeah, because I  need to kill fd.o for my credibility, that'd be great :P
<daniels> i already get enough shit when I drag it down, build a  new kernel, and update, and always bring it up reliably
<Kamion> I thought you did that already
<daniels> no, I kill fooishbar a lot
<daniels> i've never managed to kill fd.o
<daniels> just hand out root to everyone on the face of the planet, seemingly
<Kamion> mjt: yes, but /etc/rc1.d/S20single sends all processes SIGTERM and SIGKILL so I'm unconvinced that your login would survive
<mjt> well, sshd (whatever) will be shut down anyway
<Kamion> although it does use killall5, which ought not to kill its own session
<Kamion> shutting down sshd does not kill ssh sessions
<mjt> i mean it's quite unsafe thing to do remotely
<Kamion> yeah, I think it's possible though
<fabbione> hey Keybuk 
<Kamion> Keybuk: yay for dselect complaints on debian-devel :-)
<Keybuk> heyhi
<Keybuk> Kamion: you just like upsetting people, don't you :p
<fabbione> Keybuk: #4600 <-
<Kamion> Keybuk: absolutely
<Keybuk> fabbione: yeah, I commented on that one
<fabbione> i think merge-o-matic did some odd stuff with the diffs
<fabbione> Keybuk: the diffs are based on 1.0.6-4
<fabbione> shouldn't they be based on 1.0.7-1ubuntu1?
<mjg59> daniels: Depends on the acpi
<mjg59> It's not always implemented
<Keybuk> fabbione: no, that's not a base version common to both packages
<Keybuk> they *could* be based on 1.0.7-1
<Keybuk> but that package can't be found
<Keybuk> (-2 came out too fast afterwards)
<daniels> 'he hacker knew about Secret Service subpoenas relating to government computer crime investigations, and even knew the agency was monitoring his own Microsoft ICQ chat account.'
<daniels> microsoft bought aol, did they?
<fabbione> Keybuk: *srughs*
<fabbione> the merge is messy...
<Keybuk> to do a three-way diff, you need three versions
<Keybuk> left (debian), right (ubuntu) and base; base has to be a version common to the ancestry of both left and right
<daniels> man, zinf is QUALITY
<daniels> segfaults if you give it a non-existant filename
<Keybuk> 1.0.7-1ubuntu1 isn't in the ancestry of left, so it's not a valid base
<fabbione> Keybuk: yes.. i get the idea behind it...
<Keybuk> I'd be surprised if it was "messy"
<fabbione> Keybuk: check the rejects :-)
<Keybuk> it's probably just got some common bits in both diffs
<Keybuk> I did, the rejects looked small to me
<fabbione> ok let's make it simply. do we have 1.0.7-1 somewhere?
<Keybuk> it looked like postrm was rewritten
<Keybuk> fabbione: not that it could find
<fabbione> yes and there are things that are differnt...
<Keybuk> it's not even on snapshot.d.n
<Keybuk> Depends and the description changed on both sides
<Keybuk> and the dpatch 00list
<Keybuk> that's a *tiny* dropped :p
<Kamion> Keybuk: dpkg changelog> who's "Captain Tight-Pants"? :)
<fabbione> that's a pain in the ass
<Keybuk> dude, that's an easy merge :p
<fabbione> bah i guess i will have to understadn all the changes that have been done before
<Keybuk> Kamion: borrow my Firefly DVDs off Kinnison :p
<Kamion> ah
<daniels> lamont: know of any hppas or ia64s in .au? :)
<Kamion> Keybuk: how hard would it be to use gzip --rsyncable for Ubuntu's .debs?
<Kamion> I'm wondering if it would help out with rsyncing ISO images
<Kamion> (can you tell I'm waiting for an image to rsync at the moment?)
<Keybuk> quite hard.
<Kamion> it's not just a matter of adding --rsyncable to the compress_cat?
<Keybuk> dpkg uses zlib
<Kamion> oh, arse, ok
* daniels giggles.
* aj wonders why someone's searching for "ubuntu bush babes"
<Keybuk> it statically links to zlib, rather than invokes gzip
<Keybuk> (though I could just omit --with-zlib from the configure line to make it invoke gzip)
<Keybuk> but then you get ... issues with upgrades :p
<Keybuk> doesn't look line anyone's ported the rsyncable code from gzip/deflate.c into zlib either
<mjg59> Keybuk: Haha. You think *you* have it bad.
<mjg59> (In terms of 3-way diffs)
* mjg59 is currently looking at a 12-way diff
<Kamion> !
<mjg59> DNA rather than code, but still
<mjg59> It makes even less sense...
<Kamion> I hate to ask, but *why*?
<Keybuk> mjg59: +GTTGGAGGT -TATGAGGA +GATCCA -CCAGTG ? :p
<mjg59> Kamion: 12 species of fruit flies with fairly complete genomes
<mjg59> ...and me trying to find the important bits in the junk
<Kamion> Keybuk: http://lists.debian.org/debian-devel/2003/07/msg00462.html refers to it
<Nafallo> something have happened with the battery monitor :-P
<Keybuk> Kamion: useful, bug the debian zlib maintainer and I'll add support for it
<Keybuk> broonie isn't it?
<Kamion> Keybuk: yep, done
<Nafallo> is it me or is update-manager broken?
<mvo_> Nafallo: it's GTKs fault ;)
<randabis> so is theme manager
<Keybuk> itym "iz gtk bug"
<Nafallo> mvo_: hehe, should I sign a bug or are you aware of it? ;-)
<mvo_> Nafallo: it's filed as #5441 
<Keybuk> mjg59: why it is *always* fruit flies?
<Kamion> Keybuk: extraordinary genetic diversity due to the evolution of generations of geneticists naturally selected for their expertise in playing with fruit-fly genomes
<Keybuk> one day I'm going to wake up, the the world will be being terrorised by a 120ft-high fruit fly, and I'm going to blame Matthew
<Nafallo> mvo_: fixed to :-)
<randabis> is there a fix for the broken theme manager yet? no rush, just wondering
<trukulo> hi
* fabbione goes to sandpaper some more....
<fabbione> lamont: -6 is ready.. do you want the diff and the dsc now?
<fabbione> lamont: i need to wait mdz green light before upload
<crimsun> < m00se> crimsun: who should i bother about updating galeon? bug #288875 is really anoying
<crimsun> 'galeon' is in universe, so I'm not sure where to direct him
<mjg59> thom: I have some sweet scripts for you
<thom> sweeeeeeet
<thom> mjg59: whatya got?
<pitti> sivang, seb128: were you able to sort out the g-s-t problem?
<mjg59> thom: I'll throw them over in a second
<seb128> pitti: sivang is working on it, some changes are not included in the release or something like that
<seb128> pitti: but the gst devel is working atm, so it'll probably wait tonight
<pitti> ah, ok
<pitti> thanks
<pitti> sure, just curious :-)
<lamont> fabbione: either way - more interested for when to restart my mirror script...
<lamont> Rejected: ubuntu-keyring-udeb_2005.01.12_i386.udeb: architecture part of filename (i386) does not match package architecture in the udeb (all).
<lamont> anyone care?
<Kamion> lamont: mvo fixed that
<lamont> kewl
<Kamion> 2005.01.12.1
<mjg59> thom: http://www.srcf.ucam.org/~mjg59/tmp/acpi-support*
<mjg59> thom: Support for Thinkpads and default events. Needs other hardware specific events added. Need to hook in the power button stuff from acpid. Other than that, it ought to do.
<mjg59> (Note that I'm at work and thus haven't tested this in the slightest)
<thom> righto
<thom> GRAR
<mjg59> Mm?
<thom> hopefully this time my laptop won't become unusable when i tab complete a Makefile target
<rburton> try tab-completing a java class
<mjg59> Haha
<thom> make cle<tab>
<thom> and off we go so far into swap i can't move the mouse until i reboot
<thom> this is, imho, not ideal behaviour
<thom> well, i think swap
<thom> i have no way to tell bar the disk light not turning off at all
<mjg59> zsh or bash?
<thom> zsh
<mjg59> It's the crack
<mjg59> It's come for you
<thom> heh
<thom> i blame Fabio
<mjg59> I think you should admire the elegance of my wireless on/off script
<trukulo> i don't know why, but i blame fabio too
<mjg59> Yeah. Down with fabio.
<Keybuk> mjg59: what's your wireless on/off script do?
<mjg59> Keybuk: Walks through /sys/class/net looking for stuff supporting the wireless extensions, and then changes their power state
<Keybuk> cool
<mjg59> sysfs = teh 31337
<mjg59> It ought to check whether it's on an asus or not, and if so toggle the LED as well
<Keybuk> what I don't understand is why we have /sys *and* /dev
<Keybuk> there's no reason the major:minor "dev" file can't just be a device
<rburton> Keybuk: to stop RSI when you are trying to mount a device by hand
<cartman> cupsys pack is buggy
<cartman> it must depend on cupsys-client
<cartman> it tries chown /usr/sbin/lppasswd
<Nafallo> damn server! bad vga-card :-(.
<Keybuk> rburton: /sy<tab>/c<tab>/s<tab>d<tab>... :p
<cartman> also see https://bugzilla.ubuntu.com/show_bug.cgi?id=5397
<kferdous> Hey all
<Keybuk> it's no worse than devfs anyway :p
<mjg59> thom: If you're happy with the paths, then I can hand that over to seb
<thom> looking currently
<Kamion> damnit, I broke the powerpc CDs
* Kamion fix0rs
<Kamion> *ahem* sorry, a brief leet moment there
<thom> the wireless script is very nice
<amu> Kamion: live or install ? 
<Kamion> install
<Kamion> the install CD was using the live yaboot.conf by mistake
<Nafallo> does voodoo2 have a bios? :-P
<mjg59> Nafallo: Not really, no
<Nafallo> hmm, it smells like something is burning *pulls the plugs for the server*
<thom> mjg59: where do i get vbetool 0.2?
<mjg59> thom: Argh. http://www.srcf.ucam.org/~mjg59/vbetool
<mjg59> Sorry, it's still waiting in NEW
<thom> ahr
* Nafallo heads for the REALLY old server, bbl *
<lamont> mdz about yet?
<lupus_> it seems that wget is missing in the wget package
<lupus_> can someone verify this
<Kamion> lupus_: warty or hoary?
<Mithrandir> lupus_: what architecture?
<Kamion> lupus_: but anyway, all the .debs in the archive have /usr/bin/wget
<Kamion> so anti-confirm
<lupus_> hoary
<cartman> anyone knows where the post-removal scripts located in a package?
* azeem waves from his shiny new warty installation
<lupus_> weird I have no /usr/bin/wget
<Mithrandir> cartman: /var/lib/dpkg/info/$package.postrm
<thom> mjg59: paths look good
<lupus_> and the package is installed
<cartman> Mithrandir: thanks
<thom> lupus_: dpkg -L wget
<Mithrandir> lupus_: dpkg -L wget | grep bin/ ; what does that return?
<amu> azeem: a hurd-warty? 
<azeem> nah
<azeem> warty is pretty good to download and burn the latest sarge snapshot
<azeem> ;)
<azeem> didn't have any other CDs handy
<rburton> daniels: would you appreciate bugs against x for the crap man pages?
<amu> azeem: *g*
<lupus_> lupus@lupus ~ $ dpkg -L wget | grep bin
<lupus_> /usr/bin
<srbaker> is the first login of ubuntu supposed to be super-duper-slow?
<srbaker> it's been 5 minutes.
<mjg59> thom: Cool. Any sign of it actually working? :)
<srbaker> and it's sitting there with a pointer
<srbaker> did the same thing on my laptop
<srbaker> thougths?
<azeem> srbaker: check whether the loopback device is configured correctly and /etc/hosts is alright, I'd say
<azeem> but on a new install?
<srbaker> azeem, yeah
<srbaker> installed over wifi
<srbaker> well, installed from cd.  it used wifi for the security updates, i guess
<azeem> warty or hoary?
<Mithrandir> srbaker: I've never seen that, but seen some reports about it.
<srbaker> Mithrandir, thoughts on a fix?
<srbaker> happened on both my Toshiba Tecra 8100, and IBM TP T22
<lupus_> Mithrandir, ii  wget                                        1.9.1-10   
<lupus_> is this the latest version?
<pitti> elmo: still here?
<Kamion> lupus_: yea
<Mithrandir> lupus_: same version as I have, at least.
<Kamion> yeah
<Mithrandir> srbaker: since I don't know what the reason is, not really, no.
<lupus_> and you got wget?
<Mithrandir> srbaker: some people mumbled about IDE DMA issues.
<mjg59> thom: Are you ok with the /etc/default/ stuff?
<srbaker> oh.
<srbaker> anyone else see this?
<Mithrandir> srbaker: if you're able to track down what's it hanging on, then please tell us and we can fix it. :)
<srbaker> Mithrandir, that was probably me about idee dma.  that was a coincidental problem
<Mithrandir> ok
<Mithrandir> srbaker: try logging in on a text console and play around with top and strace?
<mdz> lamont: here
<lamont> so wvstreams.... it wants xplc or whatever it was...thoughts?
<elmo> pitti: yeah
<thom> mjg59: yes, happy with the /etc/default stuff
<srbaker> Mithrandir, i'll try that next
<mjg59> thom: Rock
<mdz> Kamion: I didn't need a new initrd when I tested it
<thom> mjg59: playing with the scripts now
<mjg59> thom: So all it really needs now is for all the other events from that list I wrote up adding...
<mdz> Kamion: I just dropped in the udebs and it fixed the problem for me
<thom> yeah, which i can thrash through once firefox is happy
<srbaker> where does options "SWCursor" go?  i forget which section
<mjg59> mdz: What were your feelings on dealing with the initrd-tools/swsusp issue?
<srbaker> Mithrandir, i removed all of the .g* files, and rebooted.  after reboot, worked fine
<pitti> Hi mdz
<srbaker> Mithrandir, i tested on another machine with same problem, rebooting witha n empty homedir fixes it
<mdz> mjg59: bug#?
<mdz> Mithrandir: why would you want to use grub?
<mjg59> mdz: 5230
<Mithrandir> mdz: because it's much nicer both to look at and than syslinux, imho.
<Mithrandir> more flexible too
<pitti> mdz: I finished my language-pack generator packages so far
<mdz> mjg59: what's the default if I don't have resume= and don't echo anything to /sys/power/resume?
<Mithrandir> mdz: if grub works well with cds on amd64 systems (as I think), any prolems with grub and cds on i386 systems can be ignored. :)
<pitti> mdz: I'm currently creating a quick-and-dirty script which would allow me to extract all mo files from the hoary archive
<mjg59> mdz: Good question. My recollection of the code is that it might suspend, but shouldn't resume.
<mdz> Mithrandir: but it seems to have the disadvantage of not being as widely bootable, at least the version used for the Warty live CD
<pitti> mdz: I can go with this if you want
<Mithrandir> mdz: we never released a live amd64 cd for warty.
<mjg59> thom: One thing that's lacking there is doing something sensible on low battery
<mdz> mjg59: I definitely think it makes more sense for the initrd to do the work, since it is simpler to hook there than to modify the boot loader config
<mdz> mjg59: but it's not clear to me how it should determine which device to use
<mjg59> mdz: Ok. Yes, that's the problem.
<mjg59> The kernel doesn't appear to expose partition types
<mdz> mjg59: the 99% case is that the system has one swap device, and that's what should be used, right?
<mdz> so the initrd process could read fstab or /proc for that, and save it in the initrd
<mjg59> mdz: We can't read fstab
<mdz> mjg59: the initrd-building process I mean
<mjg59> Oh, right. Yes, that works.
<mjg59> Is the first initrd built after swap has been enabled?
<mdz> Kamion: ?
<mdz> not sure
<mjg59> mdz: The 99.99% case is that we take the biggest swap partition
<Mithrandir> afaik, yes.
<mjg59> initrd-tools also needs 5231 dealing with
<Mithrandir> since the initrd is built when the kernel is installed, while partman activates swap.
<Mithrandir> iirc
<mdz> there is an enable_swap function in partman/definitions.sh
<mdz> but I don't know where it gets called from
<Mithrandir> probably when committing changes.
<mdz> ok, so that should work nicely, then
<mdz> as long as the initrd script is part of base
<mdz> mjg59: would you put it in acpi-support?
<mdz> or someplace else?
<mdz> acpi-support is currently in desktop
<mjg59> mdz: re 5231?
<mdz> mjg59: 5230
<mjg59> Oh, right. Erm.
<mjg59> I'm not quite sure what you're asking.
<mdz> mjg59: the way to do it would be to add a mkinitrd hook script
<mdz> and the question is in which package it should go
<mjg59> Ah, ok.
<mjg59> acpi-support is wrong, because it ought to work on PPC as well
<mjg59> (if we get kernel support in time)
<mdz> I suppose it could go in initrd-tools itself
<mdz> but it seems awfully specialized
<mjg59> Well, there doesn't seem to be any way to do 5231 with mkinitrd hooks, and that's even more specialised :(
<srbaker> i want to try ubuntu on a minimac
<srbaker> it kicks ass on the indigo ima
<srbaker> c
<fabbione> hey mdz
<Mithrandir> srbaker: they're not shipping yet, are they?
<srbaker> dunno
<mdz> fabbione: feel free to upload linux
<fabbione> mdz: do i have green light for -6?
<fabbione> ok
<fabbione> i will tomorrow.. i am only going to burn the livecd for testing now
<mdz> mjg59: right, 5231 either needs a mkinitrd patch to implement the functionality, or one which implements a new type of hook
<fabbione> because i need to test one fix for the e100
<mjg59> thom: Oh, we should lose the chvts in lid.sh
<mjg59> They don't seem to be needed now
<thom> righto
<thom> um, i should get some rcs set up for acpi-support, and rename it
<mjg59> And lid.sh should probably support going to sleep if not on AC, too
<thom> yeah
<mjg59> mdz: Do you ship powermgmt-base (or whatever it's called) as part of base?
<thom> hmm. that was the least succesful resume i've seen in quite a while
<mjg59> thom: Hrm. How so?
<thom> came back, appeared to reload modules correctly, and then gnome stopped redrawing entirely
<mjg59> Right. Yes, that's the vbe restore stuff.
<mjg59> Which is interesting, because I didn't think I was doing anything massively different to X. Hmm.
<mjg59> Are the text consoles ok?
<thom> yeah
<mjg59> Can you try disabling DRI?
<thom> sure
<mdz> mjg59: no, we do not
* fabbione boots on liveCD
<mjg59> mdz: Well, the choices are pretty much to put it in initrd-tools, or create some other arch:all package to go in base
<fabbione> yeahhhhh network is up
<fabbione> mdz: what's the default user on the livecd?
<fabbione> root?
<fabbione> ahh
<fabbione> neat.. hostname
<fabbione> and password?
<amu> press enter ;)
<pitti> wow, we have 244 MB worth of po files in hoary/main right now
<fabbione> amu: gdm doesn't allow nonpassord users.. and enter doesn't work..
<fabbione> + there is a password.. i can't login in console as user
<pitti> elmo: could you please install zip on rookery?
<amu> fabbione: you logined as root + no password ? adduser foobar, reconfigure X and start gdm ?  
<fabbione> login as root + no password - configure X - found user $(hostname) - attempted to login as such user
<diapolon> you all suck!
<diapolon> >P
<amu> fabbione: i need still 10min. to get the latetest iso from today  
<fablive> no prob amu
<fablive> take the time you need
<fablive> i need to go and cook some food anyway
* mjg59 heads home
<fablive> mdz: net up automagically
<amu> fabbione: it's beeing time you get married *eg* 
<fablive> mdz: looks good.. other than X everything works
<fablive> amu: yes.. in 30 days from now.. at this time i will be fucked^Wmarried
<Keybuk> both simultaneously, one would hope
<lamont> fablive: so did mdz tell you to upload -6 yet?
<fablive> lamont: yes. i will tomorrow. i need to test one fix for a network driver
<fablive> Keybuk: eheh that too
<thom> mjg59: no joy with disabling dri
<fabbione> well nice work guys
<Treenaks> hey, why isn't lbdb in bugzilla? it's in main and it has a bug wrt evolution
<Treenaks> (or the bug is in evolution..)
<lamont> ok
<elmo> pitti: what do you need zip for?
<pitti> elmo: according to carlos I will get the po files from rosetta wrapped up in a zip file
<elmo> freaks
<fabbione> scary
<pitti> elmo: to "emulate" this, I wnat to zip my extracted po files
<mdz> fabbione: why did you need to know the user?
<Treenaks> pitti: kick them into making tarballs
<fabbione> why not a normal tar.bz2?
<mdz> fabbione: it should have done gdm autologin
<pitti> carlos: here?
<fabbione> mdz: well.. it didn't
<mdz> fabbione: hmm, can you walk me through your steps?
<elmo> pitti: done
<mdz> that must have broken in the last casper change
<trukulo> fabbione, did you read what i wrote? you understand anything?
<mdz> I didn't actually test gdm
<pitti> elmo: thanks
<mdz> or maybe gdm.conf changed in some way
<fabbione> mdz: sure.. boot -> login as root to config X -> start gdm -> attempt to login as root (fail) -> back to console -> find a new user called $(hostname) -> attempt to login as such user
<mdz> hmm
<mdz> that code was working for a long time
<fabbione> trukulo: yeah i read some bits of it :-)
<mdz> aha
<mdz> I see the problem
<srbaker> what's the name of that gui tool that's supposed to make switching wifi networks easy that everyone's raving about?
<fabbione> mdz: are you sure gdm doesn't fallback to normal if it fails to start X?
<mdz> fabbione: it's a bug in casper, introduced during the work I did yesterday
<fabbione> ok
<mdz> it doesn't properly set the username in gdm.conf
<fabbione> also mvo reported the same on the mailing list
<mdz> what should the username default be?
<mdz> I thought hostname would at least give some variety :-)
<mdz> rather than everyone logging into IRC channels as 'ubuntu'
<ogra> afaik gdm requires a working lo interface and a hostname for the machine
<fabbione> mdz: $(hostname) is ok imho..
<mdz> ok
<fabbione> mdz: until gdm autologin works :-)
<mdz> er
<mdz> I just fixed it
<mdz> and that's why I was asking :-P
<fabbione> AHHA
<fabbione> mdz: YOU R0CK!
<mdz> hmm
<mdz> I had not thought about hostnames like n2342543443
<ogra> heh
<mdz> well at least it is fairly unique ;-)
<fabbione> mdz: what about a random word from dict?
<srbaker> is it NetworkMonitor ?
<mdz> fabbione: hehehe
<mdz> fabbione: a word from dict based on timestamp and IP address
<fabbione> yeah
<fabbione> something like that
<thom> you sick, sick people
<fabbione> or just ask /dev/urandom
<trukulo> why not make a list for that?
<thom> take Mithrandir's approach and just use pwgen
<fabbione> someone will endup connecting here as "mentruation"
<trukulo> comibining two funny words of the list could be good
<fabbione> trukulo: too many dangerous combinations
<trukulo> as head + fish = headfish
<trukulo> i know, and i like it :)
<fabbione> somebody is going to rant at it
<trukulo> use secure words
<trukulo> fuck him
<trukulo> lol
<trukulo> you can use animals and body parts
<trukulo> i.e.
<trukulo> secure body parts
<fabbione> elephantpenis?
<trukulo> i mean, pussybitch
<trukulo> xDD
<ogra> LOL
<trukulo> lionleg for me , please
<fabbione> ok enough crap for today :-)
<fabbione> i am going to prepare dinner
<trukulo> heheh, ok
<fabbione> cya around tomorrow
<trukulo> bon apetite mon amie
<fabbione> brrr
<thom> yo later
<fabbione> stay at least 30cm away from me dude ;)
<trukulo> hahah
<trukulo> if you want stupid ideas , ask me
<Treenaks> trukulo: well, start spewing them ;)
<trukulo> what spew means?
<Treenaks> uh.. "eject or send out in large quantities", according to dict
<trukulo> ok
<trukulo> :)
<trukulo> so, first, we need a good wallpaper
<trukulo> like this one: http://mercurio.homeip.net/ficheros/ubuntu-lion.png
<trukulo> then we need stupid hostnames
<trukulo> as lionleg
<trukulo> or cowass
<Treenaks> monkeybottom!
<trukulo> :)
<trukulo> you got it !
<randabis> I know a good gdm theme :p
<trukulo> or longhorn
<trukulo> oh, wait...
<Treenaks> trukulo: and then?
<randabis> *smacks theme manager for not working* 
<randabis> I don't have permission to change my own friggin theme... lol
<trukulo> and then we need a centralised experimental repository with open cvs
<randabis> root doesn't even have permission lol
<trukulo> and inserted into sources.list by default
<trukulo> we need tetris in installation, for the waiting
<Treenaks> trukulo: how about moon-buggy?
<Treenaks> trukulo: or nethack?
<trukulo> then we need to execute automatically files on evolution with setuid
<thom> moon buggy would rock
<trukulo> umm, better, user can choose the game
<trukulo> as emacs
<trukulo> lol
<Treenaks> trukulo: eliza?
<trukulo> that would be cool !
<trukulo> "it's you feel alone why you want to install ubuntu?"
<trukulo> and we need by default, all the icons on gnome be nude girls
<trukulo> that would be superb
<trukulo> and a gdm splash with jdub looking for his trousers
<Treenaks> no, the gnome "now logging in" splash should be an animation of Jeff looking for his trousers
<randabis> nah use this one
<trukulo> do you want any stupidity more?
<randabis> http://www.gnome-look.org/content/pre1/18179-1.jpg
<Treenaks> randabis: OOOH!
<Treenaks> randabis: Coolness!
<randabis> lolz
<trukulo> I LIKE IT
<randabis> I use that one currently :p
<Treenaks> randabis: download page?
<trukulo> yeah, for me too
<thom> guys, this is *way* off topic :-)
<randabis> http://www.gnome-look.org/content/show.php?content=18179
<trukulo> i have to go
<trukulo> we'll continue making the wanker later
<randabis> I just wish my themes would work...I want black panels :(
<Treenaks> thom: we'll continue somewhere else :)
<lamont> mdz: nuking xplc from wvstreams appears to be somewhat problematic...
<lamont> thoughts on promotion to main?
<pitti> fabbione: can you please deactivate pkgstriptranslations on your sparc buildds for now?
<pitti> fabbione: right now it also strips universe packages, but these shall not be covered by the language packs
<lamont> pitti: glad you didn't have me stripping things, then
<mdz> lamont: what's the name of the source package for xplc?
<lamont> xplc
* lamont works on recovering from the packet storm on the wireless subnet
<lamont> mdz: 4k blocksize fs, compressed at 8K is 580MB.  at 4K is 612MB
<lamont> how much room do you have?
<mdz> well, until we start adding the OpenCD stuff back, we have 650M
<lamont> there's more on the cd than just the livefs...
<lamont> and if it's testing only, then we have 700, no?
<lamont> we can build both images without any real pain, I believe...
<amu> hmm as i remember there was a speedtest with different blocksizes, and 64k win over all   
<tseng> fabbione: do you have a patch for the smp privelage esc. bug?
<lamont> amu: shooting for rsync-happiness here
<lamont> production bits get 65536
<amu> lamont: you get a speed improofment with you put the cloop on a special block at cd, knopper did once a sort before writing them to the iso, letme find a doc about it  
<amu> lamont: ;) hehe got it, i downloaded it today 3 times a full set *g* 
<mdz> lamont: the d-i bits look like about 23M
* sivang wonder where are the livecd iso for testing :)
<tseng> fabbione: http://lists.netsys.com/pipermail/full-disclosure/2005-January/030826.html
<mdz> sivang: www.ubuntu.com/wiki/LiveCD
<lamont> remotely reconfiguring a router to kill a packet storm on the network you're using is a royal PITA
<trukulo> Mithrandir, new video, fabbione_small_dick.avi
<azeem> que cazzo
<cartman> ummm
<sivang> mdz: tnx
<lamont> mdz: want to go with 4k/4k for now?
<amu> lamont: http://www.knoppix.net/forum/viewtopic.php?t=15&start=10
<mdz> lamont: let's try it for the next couple of days and see how it works out as far as rsync
<sivang> mdz: you based anything Morphix build script or had casper rebuilt from scratch?
* lamont also switches to a fixed 2GB- size for the filesystem, to encourage things to land in the same place.
<mdz> sivang: scratch
<mdz> lamont: shouldn't matter much
<mdz> unless you mean for the snapshot
<mdz> should help the snapshot
<mdz> amu: so I'd like to set up casper to eject the CD on shutdown
<mdz> thinking about the best way to do it
<mdz> probably create a tmpfs or something, and pivot into it
<amu> mdz: well, last time it was done by a modified init  
<mdz> amu: yes, I want to do better ;-)
<lamont> mdz: fssize affects block placement which affects file placement which affects how well the blocks align if someone adds some stuff early in the install....
<lamont> or how agressive is rsync in looking for blocks with the same md5sum?
<amu> mdz: what about going back to d-i ?   
<mdz> lamont: rsync will look everywhere
<mdz> iirc it sends a list of blocks that it has available to the other side
<mdz> amu: we unmounted d-i, it's gone :-)
<mdz> otherwise it stays around and uses memory
<amu> mdz: hmm, who you want handle the install2hdd in this case?   
<mdz> amu: the what?
<Mithrandir> trukulo: seeding
<mdz> trukulo: haha, I remember that talk
<trukulo> cool
<Mithrandir> seb128: gnome seems to not want to start due to some process holding some futex.. where would I even start debugging this?
<trukulo> :)
<trukulo> mdz, i don't
<trukulo> i was smoking joints in that talk and drinking beer
<trukulo> heheheh
<amu> mdz: hmm, most user prefer install the liveCD to hdd, i thought going back to d-i and start a normal installprozess ... fits for a dvd edition   
<seb128> Mithrandir: arg
<seb128> Mithrandir: stay on the splash ?
<mdz> amu: most users prefer to install it??
<Mithrandir> seb128: nope, splash goes away, but panel isn't painted, nor is nautilus receiving root window events.
<mdz> I find that hard to believe
<seb128> oh, just that
<seb128> nice :)
<seb128> wait
<Mithrandir> seb128: happened when I tried to log in on a fairly up-to-date hoary just after powering up.
<seb128> Mithrandir: #4794
<seb128> Mithrandir: that's a random bug, I thought it was due to the hal support
<jdub> morning
<amu> mdz: ... the liveCD like it is, to their hdd  
<seb128> I've not had it since mataro (and since I've turned hal off in gnomevfs)
<seb128> but mdz got it too
<seb128> Mithrandir: if you could get a backtrace of the lock which is probably due to gnome-vfs-daemon
<seb128> Mithrandir: BTW a killall gnome-panel nautilus gnome-vfs-daemon trashapplet drivemount_applet2 should fix it
<seb128> hey jdub 
<Mithrandir> seb128: that fixed it, yes.
<Nafallo> seb128: me and my girlfriend has it. (she went back to warty, but I still have it from time to time).
<mdz> jdub: do you have someone lined up for the LaunchpadIntegration bounty?
<mdz> jdub: it's specced now and needs to get going
<seb128> Nafallo: a full backtrace would be appreciate if you can get one ... do you know how to debug ?
<Mithrandir> seb128: which ones of the ones you list actually unhang it?  g-v-d?
<Nafallo> seb128: not exactly, no.
<seb128> mdz: did you get it again during the time you had the debugging gnomevfs ?
<seb128> Mithrandir: gnome-vfs-daemon
<Nafallo> seb128: most likely to get it when I don't have the battery at 100% :-P.
<mdz> seb128: no, I almost never log out on this machine
<Mithrandir> seb128: I'd take a look at the signal handling in that -- I think it's doing unsafe stuff.
<seb128> Mithrandir: ok, thanks
<jdub> mdz: where's the spec?
<mdz> jdub: wiki
<jdub> ok
<lamont> mdz: script changed, will test it this afternoon to make sure I didn't fat finger things, and then there'll be both a 4096:4096 and a 1024:65536 file
<Nafallo> could someone die if they get a server dropped from the third floor in the head?
<Nafallo> seems I might have fried the PCI-bus :-/.
<Mithrandir> Nafallo: certainly, yes.
<kent> Nafallo, do you have to aim for the heads?
<Mithrandir> ignoring air restistance, the it'll have a speed of about 10m/s after falling 10m (which is roughly falling from the third floor).
<Mithrandir> s/the//
<Nafallo> *a*
<Nafallo> *s*
<Mithrandir> kent: kinda hard to aim for anything else when dropping something on people, no?
<mdz> Kamion: here?
<Nafallo> Mithrandir: you're in Norway. You should get over here and help me ;-)
* lamont lunches
<Mithrandir> Nafallo: heh :)  I can't do wonders for fried PCI buses.
<Treenaks> Mithrandir: speaking of speed... fabio_small? :)
<Nafallo> Mithrandir: baah, you're just saying that ;-)
<Treenaks> Mithrandir: oh wait, that's done already :)
<lamont> mdz: you looking at xplc for supportability, I gather?
<lamont> s/gather/assume/?
* lamont will look at it after lunch as well.
<Nafallo> Mithrandir: I'm starting to hate servers :-/.
<Mithrandir> Treenaks:  :)
<thom> grah, firefox orig timed out, fucker
<Mithrandir> Nafallo: don't, they'll just hate you back.
<Mithrandir> thom: you're not finished with that _yet_?
<Mithrandir> didn't you start downloading that like six hours ago?
<thom> oh, this is the upload to jackass
<Mithrandir> heh, ok
<Nafallo> Mithrandir: I just got 768MB Reg ECC PC-133 Memory with the snailmail this morning, and now something probably is fried :-P. Imagine how happy I am at the moment ;-).-
<Keybuk> seb128: ?  libgtksourceview1.0-0: Depends: libgtksourceview-common (>= 1.1.90-0ubuntu1) but 1.1.1-1 is installed
<amu> 20050112.3 ppc works, including network, execpt for X, tried on a pb4 
<seb128> Keybuk: seems to be an archive problem, or build problem
<seb128> Keybuk: no idea on it, works fine here
<Keybuk> strange
<Keybuk> I've certainly got libgtksourceview-common 1.1.90-0ubuntu1 as my candidate
<trukulo> Mithrandir, jeff_small.avi is broken? can you confirm me ?
<Mithrandir> trukulo: it is?
<trukulo> don't know
<trukulo> one of badopi is telling me
<trukulo> can you see if anyone is downloading it?
<Nafallo> anyone good at hardware? ;-P
<Keybuk> dpkg: error processing /var/cache/apt/archives/libgtksourceview-common_1.1.90-0ubuntu1_all.deb (--install):
<Keybuk>  trying to overwrite `/usr/share/gtksourceview-1.0/language-specs/nemerle.lang', which is also in package libgtksourceview-cil
<Keybuk> seb128: that looks like the problem
<seb128> Keybuk: oh, I don't have mono stuff installed :p
<Mithrandir> trukulo: yes, somebody is downloading it.
<ogra> ogra@honk:~ $ uname -a
<ogra> Linux honk 2.6.8.1-4-amd64-k8 #1 Sat Jan 8 19:34:42 UTC 2005 x86_64 GNU/Linux
<ogra> :-D
<Mithrandir> trukulo: can you get me a md5sum/sha1sum?
<trukulo> sure, wait a moment
<trukulo> 16f545979e7ace1d45bacb4ac685a599  jeff_small.avi
<Mithrandir> 16f545979e7ace1d45bacb4ac685a599  jeff_small.avi
<Mithrandir> looks the same to me.
<trukulo> ok, so it's my friends problem
<Mithrandir> what client is he using?
<rburton> ok where are these movies?
<trukulo> don't know
<Mithrandir> rburton: on the internet! :P  http://tracker.err.no/
<Mithrandir> the _small torrents are fully seeded
<trukulo> umm, he has it working now
<trukulo> forget it
<Nafallo> in what way could the memory prevent vga from initalising?
<amu> cooool booting in arabic and chinies lang works also ;) 
<sivang> amu: does booting in hebrew work also?
<amu> sivang: didnt checked, it should work also   
<sivang> amu: ok, I shall check myself with when my iso download finishes
<thom> seb128: pingyping
<amu> sivang: yes pls  
<seb128> thom: pongypong
<thom> seb128: gtkhtml2 python module? where have you hidden it?
<mdz> lamont: supportability
<seb128> cf irc.gnome
<thom> yah
<thom> ta
<mdz> daniels: ping?
<seb128> mdz: totem-gstreamer should default to me :p
<tseng> fabbione: have the patch now it you are interested: http://linus.bkbits.net:8080/linux-2.5/gnupatch@41e54bb0N3nn6d27fDGZeiDAxAZ3qg
<mdz> seb128: I fixed it after assigning that bug
<mdz> seb128: you had totem and totem-xine already
<seb128> ok
<Nafallo> is there any memtest somewhere on the warty livecd?
<Nafallo> seems it haven't. the hoary should have it then?
* lamont de-lunches
<lamont> seb128: you know gnome-session isn't happy, yes?
<seb128> nop
<lamont> gdm-logout-action.c:41:23: X11/Xauth.h: No such file or directory
<seb128> ok
<lamont> feel free to beat on daniels
<seb128> thanks
<lamont> mdz: for faster rsync, we could just make the unpacked FS available, along with the 'pack me into a cloop' script - then you just rsync the filesystem (what little has changed), and presto...
<lamont> rather than syncing the filesystem image, or compressed fs image
<mdz> sivang: did it work?
<mdz> lamont: jigdo for live CDs
<Nafallo> damnit! I should have bought 68L coke instead of those fucking RAM-modules :-(
<lamont> basically
<Nafallo> memtest initiates the smell of burning computer parts :-(.
<lamont> "Preparing for live session"  - cool.
<lamont> "The system is going down NOW!!this console"???
<lamont>  etc/fstab is b0rked, it appears
<lamont> well, empty-but-for-a-comment /etc/fstab, that is
<lamont> mdz: why no entry for / in df output?
<mdz> lamont: because it isn't in mtab
<lamont> mdz: well, yes.. that was the real question - why isn't it there?
<mdz> lamont: because I don't add it to fstab
<mdz> probably should
<lamont> ew. sh: gcc: command not found
<lamont> dpkg-architecture: warning: Couldn't determine gcc system type, falling back to default (native compilation)
<lamont> and X says 'No devices detected'.  Feh
<mdz> lamont: daniels said he fixed that dpkg-architecture thing
<mdz> maybe he didn't upload it
<lamont> we really should have irc.ubuntu.com...
<rover3> moof
<lamont> but the networking works just fine
<mdz> lamont: it does now, yep
<mdz> unfortunately, it's looking a bit like I'll need to rewrite dpkg-reconfigure to get X config working
* Mithrandir hugs squid
<lamont> ouch
<lamont> and don't forget /etc/papersize...
<rover3> uptime
<rover3> df
<rover3> mount /dev/hda5 /mnt
<rover3> ls /mnt
<lamont> do0h
<lamont> although, I dunno about this empty root password thing...
<lamont> shouldn't that be star'ed out eventually?
<lamont> mdz: btw, any conclusions on xplc?
<Mithrandir> hm
<Mithrandir> I get OOo running on amd64 with gtk widgets for about fifteen seconds at a time. :P
<lamont> Mithrandir: that's like 10 seconds too long. :-)
<thom> that's about all you need, right?
* thom ^5s lamont
<Mithrandir> you know it's good when the stack trace is about 200 lines long.
<thom> run! AWAY!
<lamont> lol
* thom goes to bed
<lamont> thom: so how's mono?
<thom> lamont: making baby jesus cry
<lamont> yeah, figured that...
<lamont> progress, though?
<mdz> lamont: let's ship it
<lamont> mdz: xplc, or mono? :-)
<mdz> lamont: xplc
<mdz> we already ship mono
<lamont> ok.
<mdz> no?
<mdz> (it's just busted)
<lamont> no.  we ship mono source.
<lamont> oh, and broken old binaries
<thom> ok, so the problem is that you have to bootstrap mono. and, it also seems you can't use mono 1.4 to bootstrap mono 1.4; so, we need to find mono-utils 1.2 and so on, get them in the chroots, and build 1.4 using them
<lamont> 1.2 or 1.0.2?
<thom> sorry, 1.0.2
<lamont> and are any chickens involved in this process?
<thom> (and 1.0.4 rather than 1.4)
<thom> i think an elephant
<thom> and waders
<lamont> well, the chicken will fit that way... :-)
* lamont heads to the morgue
<Mithrandir> this is icky.
<lamont> but first he looks around frantically for anything else to do
<Mithrandir> pango hardcodes libs in /usr/lib
<thom> heh
<thom> lamont: are you some kind of coward? ;-)
<lamont> mdz: so I need to propose xplc to you and jdub so you can approve it, then ask elmo to sync it???
<lamont> thom: live coward, thank you very much
<mdz> lamont: email me and elmo, I'll ack it
<lamont> ok
<lamont> mdz: for maintaining my sanity, I'd like to not upload the merged wvstreams until the sync happens - is ok?
<mdz> lamont: hmm, ok
<lamont> otherwise, the buildds will loop on it.
* thom goes to bed
<Mithrandir> anybody got any half-decent ways to trick warty's libpango to load its lib from another directory?
<lamont> and 4 log files every 30 minutes gets rather boring.
<Mithrandir> or at least not significantly more insane than ooo-on-amd64 already is.
* Mithrandir notes the channel got _very_ quiet.
* jinty drinks some tea
<Mithrandir> I could write a wrapper which just redirects opens on /usr/lib/pango to /usr/lib32/pango
<lamont> mdz: sent
<Mithrandir> that's just ugly, not _bad_.
<Nafallo> Mithrandir: I'm about to bury my new server and get back to the old one, atleast if the disks made it.
<jinty> mdz: LiveCD docs? talk about that now?
<mdz> jinty: someone else was interested in working on them as well, sivang I think?
<mdz> or else someone on the list
<mdz> you guys should collaborate
<lamont> Mithrandir: extra points if you do it in a kernel module...
<Mithrandir> lamont: nah, just a preloaded library.
<lamont> yeah, that's a bit better.
<jinty> mdz: but what to document? thin air?
<mdz> jinty: if you need me to walk you through it, I don't have time for that right now
<mdz> jinty: you might try amu
<lamont> mdz: since I'm thinking of 64 bit things and oo.o....  anyobjections to a per-arch exclude list in ubuntu-meta?
<jinty> ok
<jinty> amu?
* Nafallo wants oo.o on amd64. I do my schoolwork in there :-P.
<amu> mdz: ;) 
<lamont> Nafallo: my problem child for oo.o is ia64, amd64 is golden
<mdz> jinty: on the same hand, the infrastructure is only about a week old at this point, and it's entirely possible that it will change in incompatible ways before the release
<amu> jinty: g'moring 
<mdz> jinty: so one might say that it could be too early to document ith
<Nafallo> lamont: *puuh*
<mdz> it
<jinty> I'd rather not write docs multiple times.
* jinty goes back to his tea
<Nafallo> tea... english... butler... for Kamion? :-)
<jinty> amu: evening, guess we speak a bit later
<Nafallo> a bit slow thinking... *blames the fried-computerparts-smell*
<amu> jinty: better ask 1 week later, and try to cooperate with sivang, i'm not sure whether he allready made something 
<jinty> thanks
<amu> jinty: wait, i'm sure you can drop some info's to the wiki ;)   
<jinty> amu: I'll mail sivang and get back to you with some more specific questions
<amu> or did you want information, which is similar to a book, e.g. the knoppix manual, which appeared recently?
<jinty> basically, just a starting point, something I can take apart to see how it works
<jinty> my only expierience is re-writing the fai-bootcd script
<lamont> Mithrandir: btw, xplc is ftbfs on amd64, log inbound
<lamont> to p.u.c/~lamont/buildLogs, that is
<mdz> daniels: re-ping
<lamont> mdz: while were on the subject of migrations... gnopernicus (main) build-depends libgnome-mag-dev (universe).. Or is that a 'seb128 needs to fix it' thing?
<mdz> lamont: that's an "ask seb128 if it's correct" thing
<amu> jinty: ic, you want something like how i can setup all those things on my local maschine?  
<seb128> lamont: libgnome-mag-dev should be in main (it's needed to build gnopernicus)
<jinty> amu: yeah, something like that, or a shell log. so I can see the process
<seb128> lamont: libgnome-mag1-dev -> libgnome-mag-dev name change may be the reason of the universe instead of main ? 
<mdz> seb128: please send mail to elmo asking to move it into main, CC me
<seb128> ok
<Mithrandir> lamont: ok, it's night here now and my vfshack needs a bit more love before it works, so I'll just upload what I have so far, since I now have a working ooo for amd64.
<Mithrandir> though, gtk widgets are broken because of pango.
<doko> elmo: please sync bash and readline5 from unstable
<crimsun> heh, talk about great timing. I just triggered that bug in bash's history this morning.
* Mithrandir throws a few hundred MB into incoming and goes to bed.
<seb128> lamont: could you retry evolution-webcal ?
#ubuntu-devel 2006-01-16
<LaserJock> mdz: ping?
<poningru> so question
<poningru> if fat is patented can we still support it?
<HiddenWolf> poningru, patent didn't or will not hold up.
<psusi> they can't possibly patent it this late in the game... but if they did, no, we couldn't
<HiddenWolf> psusi, I think they did, then dropped it.
<psusi> they tried, yes... I saw the storry
<psusi> and with the crap the patent office has been approving lately, I wouldn't be surprised if they got it
<psusi> but I would be surprised if it held of up court if someone with money challenged it
<poningru> they just allowed it
<HiddenWolf> they did?
<psusi> if they actually got a patent approved, I'd like to see it... so I can shoot the clerk who approved it
<poningru> http://news.com.com/Microsofts+file+system+patent+upheld/2100-1012_3-6025447.html?part=rss&tag=6025447&subj=news
<psusi> you can NOT patent something 25 years after inventing it and after it has become public knowledge
<poningru> psusi: my sentiments exactly
<HiddenWolf> Microsoft's attempt to create a lucrative future revenue stream from its patent portfolio has tripped at the first hurdle. After an appeal, the US Patent Office has struck down Microsoft's '517 patent (USPTO 5,579, 517) on the FAT file system.
<HiddenWolf> 30th september 04
<poningru> HiddenWolf: yeah 3 months ago
<HiddenWolf> Hm, weird shit.
<psusi> even if it meeds the novel and non obvious requirements, once it becomes public knowledge, you can not patent it
<mjr> the patents, iirc, had to do with storing long filenames on FAT (truly innovative, yes...)
<mjr> so it was not FAT per se
<poningru> oh
<poningru> gotcha
<psusi> he... yea... that was bloody well non obvious.... NOT
<psusi> and in any case, it's been widely known and used public knowledge for years, which invalidates any new applications for patent
<HiddenWolf> gees, it's been around since '77
<poningru> doh thats me not reading the articles
<HiddenWolf> psusi, someone first has to go to court for it. :)
<mdz> LaserJock: pong
<psusi> only if the dumb fucking twits in the patent office actually issue a patent
<psusi> then yea... someone has to be willing to fork out big bucks for lawyers to go after the patent
<poningru> mdz: sorry to bother you but how come you dont blog?
<psusi> or rather, someone has to violate the patent, then get sued for it, then fork out big bucks defending themselves
<LaserJock> mdz: I'm Jordan Mantha, the plotdrop packager. I was a little uncertain of you your debian-mentors email
* psusi doesn't like the term "blog"... sounds like something you do in the bathroom
* HiddenWolf agrees
<zul> heehehe...you said blog
<psusi> speaking of that... I'm working up a good blog right now...
<psusi> hehe
<psusi> oh sheesh.. I'm a retard
<psusi> I added the -g to the CFLAGS in the makefile... didn't notice it had a -s in there...
<psusi> well, that's enough... time to go home
<segfault> that new logout window is nice
<segfault> however, it doesn't lock the screen 
<segfault> maybe something like gksudo does would be great
<Amaranth> it's kind of not finished yet :)
<sorush20> Amaranth: anyone here working on making dvd playback and codec32 native linux?
<HiddenWolf> sorush20, impossible
<HiddenWolf> patentend stuff
<HiddenWolf> illegal in the us.
<HiddenWolf> and other nations.
<Amaranth> not to mention hard/impossible to actually code
<HiddenWolf> Amaranth, there is that. :)
<HiddenWolf> That's what undocumented, unspecified closed standards give you. :)
<HiddenWolf> jdub, ping
<sorush20> actully code?
<sorush20> how hard can it be?
<HiddenWolf> quite
<Amaranth> sorush20: You have absolutely no details on the format.
<sorush20> Amaranth: we are talking about takeing millions of frames are running them in sequence with a sound layer too in sequence.. right?
<Amaranth> no
<Amaranth> that's the easy part
<Amaranth> the codec turns the video file into that
<HiddenWolf> getting to the point where you have frames to work with, that's tricky. :)
<sorush20> the encoding is just the compression , what you are sying is decompressing is hard right? 
<sorush20> and the codec's act as a key to decompress?
<sorush20> Linux for human beings is one that can be free and can decode dvd and etc. not one that enables hours of chat and etc. 
<HiddenWolf> sorush20, without actually knowing the specifications of the format or the codec, it is working in the blind with a hand tied behind your back
<Amaranth> sorush20: Blame the United States Government
<Amaranth> and/or the media industry
* HiddenWolf agrees with Amaranth 
<HiddenWolf> sorush20, closed source means there is _no way_ of knowing what a complex thing does and how it does it without very extensive trial-and-error testing and engineering by very good programmers.
<sorush20> HiddenWolf: I'm sure obtaining the file format spec is easyier than getting your hand on the spec for a uranium centrifuge. 
<Amaranth> No.
<HiddenWolf> sorush20, reverse engineering is forbidden in a lot of countries to complicate matters.
<HiddenWolf> sorush20, microsoft is very, very tough on security for it's specs.
<Amaranth> One is available with the right friends, the other is only available from a single company that guards it closely.
<HiddenWolf> besides, you'd be suid for a felony of IP theft.
<HiddenWolf> sued, even.
<sorush20> a files format can not even be reverse engineered?
<kent> sorush20, if it was possible to ship dvd-support it would have been shipped,  there is no way to expect more friendlyness.  :(
<sorush20> the open source formats are not good enough for dvd? 
<sorush20> ogg etc. 
<HiddenWolf> sorush20, it can be, by talented and dedicated people
<HiddenWolf> sorush20, we can write it if we get the specifications
<HiddenWolf> we don't have the specs
<HiddenWolf> if we had, we'd have no right to use them
<HiddenWolf> if we'd ship them if we had we would be sued
<HiddenWolf> there is at present no way to legally play dvd or wmv on Linux
<sorush20> are we allowed to read the files in alternative methods?
<kent> HiddenWolf, but OSX can do it right? so its just about the $ in the end?  Cant say, lika..  a former astronout pay for it? haha. :)
<sorush20> what about the blueray disk
<Amaranth> sorush20: even worse than DVD
<sorush20> shit
<HiddenWolf> kent, The question is, do you want to fund development for a couple of years, or pay for mp3 support
<HiddenWolf> kent, dvd, bluray, wmv are not for sale at present
<Amaranth> kent: Pretty hard to get a license for everyone in the world to use and freely distribute something that usually gets billed per user.
<HiddenWolf> Fluendo is likely to change that with gstreamer-nonfree plugins, but that is a legal minefield.
<kent> HiddenWolf. I understand. I dont have dvd in my computer so id rather the monny went to development. ;) hihi
<Amaranth> HiddenWolf: Only with GPL'd frontends and GPL'd plugins.
<sorush20> what is fluendo
<Amaranth> HiddenWolf: Banshee is MIT and most plugins are LGPL'd
<HiddenWolf> Amaranth, and gpl players linking to gstreamer.
<sorush20> gstreamer-nonfree 
<Amaranth> HiddenWolf: I mentioned that already.
* kent hopes for free hardware in the future. Devloped freely with open specs but sold commersially.  :)
<HiddenWolf> Amaranth, hm, right.
<HiddenWolf> kent, nice, but OT here. :)
<HiddenWolf> sorush20, fluendo.com
<HiddenWolf> sorush20, this is getting off topic
<Amaranth> sucks that the only player you can use with nonfree plugins needs a software stack that may or may not have it's own legal issues
<Amaranth> This is why software patents suck. :P
<HiddenWolf> Amaranth, yeah, well. :)
<HiddenWolf> Go EU.
<Amaranth> heh
* Amaranth wonders if canada has software patents
<Amaranth> that's less than 1000 miles away...
<HiddenWolf> Amaranth, http://en.wikipedia.org/wiki/Software_patents
<sorush20> HiddenWolf: I though they rejected the patent think
<poningru> sorush20 and others: we do have a #ubuntu-offtopic 
<Riddell> infinity: please give back kmymoney2
<infinity> Riddell: Done.
<HiddenWolf> Amaranth, if you think patents are bad...
<HiddenWolf> An Ohio man who claims that he was humiliated by two other participants in an AOL chatroom has sued the two men for causing emotional distress and the ISP for failing to stop the alleged abuse, according to a report from Law.com.
<HiddenWolf> And if you tell me to go to -offtopic, I'll sue. ;)
<Amaranth> *boggle*
<Riddell> anyone know what icon gnome uses for its zeroconf stuff?
<poningru> avahi?
<Riddell> hmm, avahi seems to use a funny bear icon, hardly intuitive
<mjg59> Riddell: The service discovery applet is a globe with a small question mark on it
<Riddell> ah, globes, can't go wrong with them I suppose
<zakame> elmo : please sync octave2.1 from Sid, overriding Ubuntu ok, thanks :)
<freestone> Mithrandir: U there?
<daniels> freestone: it's like 6am in norway
<freestone> It's Wednesday there.
<freestone> Where is infinity located?
<daniels> yeah.  4:32am on wednesday.
<freestone> infinity: U there??
<HiddenWolf> daniels, sorry to ask, had a debate about it earlier, what is the roadmap for X and acceleration, (xgl, exa etc) Is any of it likely to become mainstream in a reasonable time?
<infinity> freestone: Here.
<freestone> Anyone - Yesterday Mithrandir said he'd get me an updated base system with cd boot fix, but he didn't email me.
<freestone> Hi infinity
<freestone> infinity: see my continued question about base sytem
<infinity> freestone: On which architecture?
<freestone> Does anyone know if the base was updated to handle firewire cds isos, and if so, how I can get the updated iso?
<freestone> infinity: 386
<daniels> HiddenWolf: exa is the short-term, and people are working on fixing its problem snow
<freestone> infinity: btw, where are you located?
<daniels> xgl is the longer-term handwavy future
<HiddenWolf> daniels, shortterm as "within a couple of releases" ?
<daniels> HiddenWolf: short-term as in touch and go for dapper but definitely dapper+1
<daniels> it's already a lot better than xaa in most regards (if you haven't tried exa + xcompmgr -a, do so now)
<HiddenWolf> damn
<HiddenWolf> I'm mildly impressed now.
<mjg59> daniels: Can we build stuff with EXA support for Dapper, even if it's not enabled by default?
<daniels> mjg59: we already are
<HiddenWolf> Considering the acceleration - eyecandy chicken-egg problem...
<daniels> mjg59: i'll be patching i810 and probably nv before I leave, and sis/radeon is already there.  but no guarantees on future maintenance obviously.
<mjg59> daniels: Excellent
<mjg59> daniels: Is the i810 stuff in a sensible state now?
<daniels> semi
<infinity> freestone: a) I'm in Australia, b) I have no idea if Mithrandir made firewire work yet.
<daniels> hopefully anholt will beat it into better shape
<mjg59> Is he going to give us mode-setting code?
<freestone> infinity: thanks
<freestone> daniels: Hi - just for completeness, where are you located?
<daniels> freestone: i have nothing to do with that sort of stuff ...
<freestone> infinity: can  you do what is necessary to make ieee1394 firewire cd work on the base system?  If no, do you know if anyone on this channel can?
<freestone> daniels: what "sort of stuff"?
<daniels> freestone: live cd, base system, install cd, kernel, etc
<HiddenWolf> daniels, the deb is still called kdrive? or is packages.u.c out of date?
<freestone> daniels: Er, ok, thanks, nice to know.  But, where are ou located?
<daniels> freestone: .au
<daniels> HiddenWolf: the deb of what?
<daniels> HiddenWolf: there's xserver-xorg-* for xorg (some with exa), xserver-xglx for an out of date xgl (but that'll change), and xserver-xephyr for xephyr
<daniels> i'll hopefully be producing kdrive packages in a week or so
<freestone> daniels: thx.  &, now, for the other completeness, what stuff is your specialty?
<daniels> xorg
<HiddenWolf> daniels, ok. thanks, i'll take no more time, rock on. 
<freestone> thx
<infinity> freestone: The casper changelog doesn't look like Mithrandir has tackled firewire in livecds yet.  He'll get to it, I'm sure.
<freestone> infinity: thx
<freestone> infinity: btw, is the casper changelog something I can access, if so where & how?
<infinity> http://changelogs.ubuntu.com/changelogs/pool/main/c/casper/
<freestone> infinity: thx
<fabbione> morning
<mdke> infinity, nudge nudge wink wink
<jdub> yay, my quebecistani craptop can halt now! (fglrx unfucked.)
<infinity> No radeon love for the Quebecois?
<Burgundavia> seb128, with rb doing cd burning, are we going to drop serpentine?
<jdub> Burgundavia: it's a pretty unclear UI; i wouldn't back it.
<seb128> Burgundavia: same as jdub
<seb128> hey jdub :)
<jdub> yo seb128 
<Burgundavia> jdub, seb128 ok, just wondering
<Keybuk> jdub: still dealing with insurance for your old one?
<jdub> yeah
<Mithrandir> grrrr.
<jdub> oddly the synaptics thingy still isn't working though\
<Mithrandir> ubuntu-desktop is uninstallable.
<infinity> SHOCK AND HORROR.
<Mithrandir> infinity: well, it means the live cds won't work, and I would _really_ want them to.
<Mithrandir> also, ravel seems to be down.
<Mithrandir> or just dog slow
<infinity> Yeah.  Looks like the gimpprint->gutenprint thing is hung up on main promotions.
<infinity> Anyhow, let me see about getting you some squashed filesystems.
<Keybuk> jdub: mine got fixed with the new package that got installed yesterday
<Mithrandir> \o/
<Mithrandir> infinity: that's just promotions, no inclusion reports needed?
<infinity> You find an ftpmaster to help you. :)
<Mithrandir> sure, Kamion? :-)
<infinity> gimp-print -> gutenprint is a project rename, shouldn't need an inclusion report.
<jdub> Keybuk: the updated xserver-xorg-input-synaptics?
<jdub> maybe i should re-dpkg-reconfigure xserver-xorg
<Keybuk> yeah
<Keybuk> as apposed to the one that installed the files in the wrong place, and didn't work at all
<lucas> hi
<lucas> is it possible to inline images on the ubuntu wiki ?
<lucas> somebody has an example page ?
<jdub> lucas: wiki.ubuntu.com/JeffWaugh
<lucas> thanks
<lucas> easy ;)
<jdub> Keybuk: least i can restart my xserver without bringing down the machine now ;-)
<jdub> no love with mousey
<infinity> Mithrandir: Do you want anything special on this squash?... Or just a vanilla invocation?
<Mithrandir> infinity: squashed vanilla, please.
<jdub> ... and still can't use ati driver. 8)
<jdub> Mithrandir: tasty.
<Treenaks> jdub: have you seen daniels? I was supposed to kick him about xorg/ati last Monday
<Mithrandir> Kamion: it seems like foomatic-db-gutenprint and cupsys-driver-gutenprint needs main-promotion., as per infinity's and my conversation above.
<jdub> Treenaks: he mentioned that
<Treenaks> hmm
<infinity> Kamion: Though it's not (yet) stopping desktop installability, I'd love if all the MySQL 5.0 stuff (mysql-{client,server}-5.0, libmysqlclient15{,-dev} could find its way to main too, so I can start rebuilding the world.
<Mithrandir> elmo: please sync ttf-dejavu from unstable, overriding ubuntu changes is ok.
<infinity> Argh.
<infinity> libc6-dev-i386 depends libc6-i686, and I have a libc6-i386.  YAY.
* infinity fixes.
* ..[topic/#ubuntu-devel:irc.freenode.net] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 2 released
<Kamion> Mithrandir: gutenprint stuff promoted
<Mithrandir> Kamion: thanks a lot.
<Kamion> argh, hope I didn't collide with the unfortunate bit of cron.daily
<Kamion> probably not ...
<lucas> is there currently a problem with automatic syncing from debian ? clamav, dpkg-awk or sodipodi are packages that should have been synced but aren't
<sivang> good morning
<Kamion> lucas: all those packages were uploaded after cron.daily on 9 Jan, and thus were not actually part of Debian unstable until after the sync run yesterday; they should be part of today's sync
<lucas> oh ok
<lucas> thank you
<Kamion> infinity: I assume mdz's OKed mysql 5.0?
<mvo> is there a good way to recover from a machine that is trashing because of memory pressure? I would like to save the runing processes before forcing a reboot (to analyze what went wrong)
<Keybuk> there's a SysRq for that isn't there?
<mvo> I think there is, I just can't remember it
<Keybuk> SysRq-E is send TERM to all processes
<Keybuk> SysRq-S is sync filesystems
<Keybuk> SysRq-U is unmount them
<Keybuk> SysRq-B is reboot
<StevenK> mvo: Ctrl-ScrollLock
<StevenK> It's incredibly verbose, though.
<mvo> Keybuk: I know S-U-B by heart from the the good old days :) 
<mvo> StevenK: thanks, trying that now
<Keybuk> mvo: I always think "dive! dive! dive!" when I type that
<StevenK> It doesn't seem to work on my Breezy box.
<mvo> Keybuk: haha, yeah!
<dholbach> hello developers!
<dholbach> hey mvo, hey Keybuk
<mvo> dholbach: the apt-get.org build script made my machine trashing
* mvo stares at dholbach 
<dholbach> mvo: what? who? where? what is trashed?
<mvo> StevenK: SysRq-T is show tasks, it's on it, but to busy to show them :)
<StevenK> Ahh
<dholbach> mvo: do you run pbuilders in parallel? :)
<mvo> dholbach: 1G mem/1G swap is not enough, the machine is full (memwise) and dosn't do anything but runing over it's swap and trying to get some pages 
<mvo> dholbach: no!
<mvo> (I hope)
* StevenK wonders if Magic SysRq is disabled.
<dholbach> mvo: do you know what it is building momentarily?
<mvo> works in dapper
<StevenK> Well, it isn't. Maybe I've forgotten how to use it.
<mvo> dholbach: no, I don't get answers from SysRq-M currently
<mvo> it's in a pretty bad state
<dholbach> :/
<infinity> Kamion: It was okayed before I had it synched, yes.
* mvo wonders if he can blame the kernel team somehow. where is the OOM killer when one needs it
<Kamion> infinity: ok then, promoted
<Kamion> not built on ia64 yet?
<infinity> Nothing's building on ia64 while we sort out the gcj-4.0 failure (which causes a chain reaction that ends up in debhelper being uninstallable)
<sabdfl> seb128: morning
<seb128> sabdfl: hi
<sabdfl> i'm trying to fix the default browser issue locally
<sabdfl> system -> preferences -> preferred applications
<Keybuk> . o O { don't you just hate it when the boss joins, and says morning to *just* you?  you know something's gone wrong :p }
<seb128> sabdfl: just run the sytem, preference, preferred app capplet
<seb128> sabdfl: and pick firefox
<sabdfl> 'k willdo, thanks
<sabdfl> morning keybuk ;-)
<Kamion> infinity: ah, ok
<dholbach> :)
<dholbach> hi sabdfl
<StevenK> Keybuk: This happens at work more than I care to admit ...
<Mithrandir> seb128: do you know anything about inotify?  I'm wondering how I can get notification about stuff being mounted.
<seb128> Mithrandir: inotify like the linux inotify, or like libnotify?
<Mithrandir> like linux inotify.
<seb128> nop, not really
<Mithrandir> pitti might, when he gets around
<seb128> maybe mvo has some clue on it, he did some hack with gam stuff
<Mithrandir> mvo: do you?
<Keybuk> Mithrandir: you can't through inotify ... I thiiink there's a uevent for that though
<Keybuk> though I can't see it
<Mithrandir> Keybuk: if I watch a path which doesn't exist (say /media/sda1/foo) and it then gets mounted and something accesses foo, I'll get told?
<Keybuk> afaik, no
<Keybuk> there's some notification for it, but I'm buggered if I can remember what off hand
<Keybuk> fabbione is who you may need to ask
<Keybuk> or pitti
<mvo> Mithrandir: I use it in update-notifier (using libfam). but for mount events libhal might be the better choice
<Mithrandir> mvo: this is going to be code in the initramfs, so I was hoping not to use lots of libraries.
<mvo> Mithrandir: I'm sorry then, I haven't used inotify directly (only through a library)
<Mithrandir> mvo: ok, thanks anyway
<Mithrandir> libfam is 27k, that's decent enough
<Mithrandir> hal needs dbus and stuff, so that's out, I think.
<Mithrandir> I can just watch /proc/mounts, I guess.
<mvo> Mithrandir: sorry, make that libgamin0
<StevenK> "What do you mean we now need 128Mb of RAM for the initramfs?!"
* StevenK giggles.
<dholbach> StevenK is obviously in a good mood.
<Mithrandir> mvo: does it need any daemons or stuff running?
<StevenK> dholbach: There's a thunderstorm happening - I love storms.
<blue-frog> strace totem > file would be something that is needed when filling in a bug?
<StevenK> blue-frog: strace -f -o file totem
<blue-frog> k ty
<StevenK> Oh, and I have ice cream, so doubly happy here.
<dholbach> that sounds good :-)
<mvo> Mithrandir: probably gamin server, so it might be the best to use inotify directly. there was a lwn article about the interface a while ago IIRC
<blue-frog> hum no i belive this command is to open a file, totem crashes when i just launch it
<Mithrandir> mvo: I have it mostly working
<dholbach> blue-frog: http://wiki.ubuntu.com/DebuggingProgramCrash is more important then
<blue-frog> k
<Mithrandir> mvo: the interface is nice enough, it's just that it doesn't give me all I want, like mounting of file systems.
<mvo> Mithrandir: I see, the only solution I know off-hand is libhal, sorry
<seb128> blue-frog: no
<Keybuk> Mithrandir: there appears to be a inotify mount/unmount event
<seb128> blue-frog: strace is not useful, gdb "bt" is
<seb128> blue-frog: for a crasher I mean
<Mithrandir> Keybuk: not in /usr/include/linux/inotify.h?
<blue-frog> am reading the page but unfortunately i won't be able to help in that case as i don't see a totem-debug in synaptic
<Keybuk> oh, that just has UNMOUNT
<dholbach> blue-frog: if you follow the instructions that's enough
<adrian15> Hello to all. I've developed a grub disk called Super Grub Disk that can be used to restore grub on mbr automatically. Is there any possibility that you mix it into your live/ installation cds? What do you think about it? http://adrian15.raulete.net/grub/ Any ubuntu boot loader developer round here, perhaps ? Thank you.
<Mithrandir> Keybuk: yeah, that works fine
<blue-frog> dholbach, yeah ok used command line got the stuff downloading
<fabbione> adrian15: it would probably be better to mail to ubuntu-devel@lists.ubuntu.com
<fabbione> adrian15: so that people can have time to read and look at it
<Kamion> adrian15: I was intending to integrate grub-installer with our existing rescue mode instead; all the code's there, it just needs to be glued together
<Kamion> in fact I have most of the code here ...
<Kamion> that way, everything works the same way
<adrian15> Kamion: https://wiki.ubuntu.com/RecoveringUbuntuAfterInstallingWindows?action=show  Would it be the same as I can found in this wiki with the mounts with bind options and all of this ?
<Kamion> adrian15: basically, yes
<StevenK> Whee, I love how sick this drive is.
<StevenK> Every operation results in at least 5 IDE bus resets.
<adrian15> Kamion: User needs to select the partition where ubuntu is installed ?
<Kamion> adrian15: yes
<adrian15> Kamion: With my tool grub partition is automatically found.
<Kamion> (since you might well want to restore grub from another partition, not Ubuntu, if you're multi-booting Linux distributions)
<adrian15> Kamion: Yes, you're right.
<Mithrandir> infinity: when you've got the squashfs stuff working, I'd love to see a full cd build, so I can test it.
<adrian15> Kamion: Do you want to continue conversation in #grub or in a private or is it ok here ?
<Kamion> it's OK here, but I might as well say now that I don't want to take new grub-related code that mostly duplicates things we already have
<Kamion> just because it's one more thing to maintain in an area that gets fairly complex (especially with strange storage controllers and stuff)
<adrian15> Kamion: Well, currenly apart from a bug fix, it's only various lst files
<adrian15> Kamion: So you don't need to apply patches or recompile grub... although you will need it in next SGD releases... cause I'm adding variables and CALL command and other things. Currently ubuntu installation cds don't boot grub but isolinux, isn't it ?
<Kamion> adrian15: isolinux, yes
<Kamion> I know we don't need to recompile grub, but grub-installer sees non-trivial maintenance work that would have to happen in anything that duplicated it too
<adrian15> Kamion: I'll tell you one thing. Super Grub Disk does not make use of grub-installer but grub is run from cdrom itself.
<infinity> Mithrandir: You'll have a full squash-enabled build before I sleep tonight.
<infinity> Mithrandir: Just let me finish sorting my glibc woes. :)
<Kamion> adrian15: We used to ship live CDs booting with grub, and they failed to boot on a wide variety of machines. We won't be switching our CDs to boot with grub.
<adrian15> Kamion: wasn't it grub + gfxboot... the problem was mainly grub or gfxboot?
<adrian15> Well, I have to go... see you in 3 minutes.
<adrian15> Kamion: The problem was a grub problem a gfx one... or what ?
<Mithrandir> infinity: sure, sort whatever you want. :-)
<adrian15> Kamion: grub or gfxboot ?
<dexem> mdz: did you decide something with the locales/calendar bug?  (#16216)
<Kamion> adrian15: as far as I know it was a grub problem
<Kamion> grub on a CD just required that bit more of the BIOS
<Kamion> and one question would have sufficed
<blue-frog> dholbach, sry to disturb. followed the debugging program crash instructions. up to (gdb) run all goes well (that means the program -totem- is starting and ends up as totem couldn't start). but i have no ouput when doing (gdb) thread apply all bt. Any hint, pls?
<adrian15> Kamion: Sorry about the 2 questions. It was the error 25 perhaps ?  And another thing... if with a pc the grub cdrom didn't work... the grub in hard disk did it work?
<Kamion> yes, grub worked fine when installed on the hard disk. I don't remember the exact error.
<Kamion> (since I never saw it myself)
<seb128> blue-frog: could you copy what you get on pastebin.com ?
<blue-frog> sure
<Keybuk> http://people.ubuntu.com/~scott/restart-req.png
<Keybuk> http://people.ubuntu.com/~scott/restart-dialog.png
<Keybuk> ^ mvo
<Kamion> anyway, isolinux works fine, we have gfxboot integration for it now (still needs a few fixes, but minor), and don't fix what isn't broken
<adrian15> Kamion: So... it may be the error 25 which I've fixed.
<Kamion> *shrug* isolinux works
<adrian15> Kamion: Do you have any options that choose kernel parametres in installation cds or is there only one... and in the live cd ?
<Kamion> it's incredibly important that Ubuntu CDs boot; failing that, they should at least fail to boot consistently, not flip-flop between two sets of bugs :-)
<Kamion> various places
<Kamion> debian-cd, the bootloader installers, base-installer
<martinex> hello all
<mvo> Keybuk: very nice!
<adrian15> Kamion: You're nearly always in this channel? I'll send you a piece of news of the new SGD that let's you choose the options passed to the kernel with menues when it is ready... and that support variables and all that.
<Keybuk> now I've just got to figure out how to hook into gnome-session to do the actual restarting thing
<martinex> question - is there something like - development changelog - with for example list of changes in packages... since yesterday etc. ? daily changelog or sth?
<Keybuk> ungodly hack coming right up! :D
<Kamion> adrian15: I'm generally here, yes, but I have to be honest and say I'm really not all that interested unless it comes in the form of patches to the systems we're already using
<Kamion> patches to those systems are most welcome
<bluefrog-10> dholbach, http://pastebin.com/500530
<Kamion> entirely new systems are a very different matter
<Kamion> particularly three months before a release that we need to support for five yerars
<Kamion> years
<adrian15> Kamion: :) Ok. I understand.
<Kamion> but best of luck with SGD all the same
<dholbach> bluefrog-10: if you type 'bt' after that - do you get a different output?
<Kamion> Mithrandir: ubuntu-desktop's installable right now; good time for a live fs rebuild?
<bluefrog-10> dholbach, no stack
<dholbach> bluefrog-10: i'm not quite sure it crashes then :)
<adrian15> Kamion: One more question: I wanted to edit https://wiki.ubuntu.com/RecoveringUbuntuAfterInstallingWindows?action=show in order to say that they can also use SGD if they have only one system installated in their system. Should I? Shouldn't I? I put it in the top of the page... in the bottom.... what do you think of ?
<Kamion> adrian15: don't see why not; maybe link to it from the "GRUB Resources" section?
<seb128> bluefrog-10: it doesn't crash
<seb128> bluefrog-10: is that breezy or dapper?
<adrian15> Kamion: If you think so... :(
<Kamion> or whatever really, I'm not the wiki police :-)
<blue-frog> seb128, dholbach, indeed it's a "totem couldnot startup" window that i receive. weird that you don't have this as well. using dapper daily 09-01-06 updated as of today
<Kamion> I'd never seen that page before you mentioned it
<seb128> blue-frog: gconftool-2 --type string --set /system/gstreamer/0.10/default/videosink ximagesink
<seb128> blue-frog: and try again
<blue-frog> seb128 ouot of gdb i assume?
<seb128> yep
<dholbach> seb128: i was just looking for that key, remembering that you mentioned it in a bug report :)
<bluefrog-10> totem launches
<seb128> dholbach: nice :)
* dholbach hugs seb128 :)
<bluefrog-10> so do i do anything about bug or i just leave it as it is?
<seb128> bluefrog-10: seems your videodriver doesn't support "xv", what video driver do you use?
<Mithrandir> Kamion: I asked infinity to do one as soon as he has the squashfs stuff in.  Or we could just do one now and one when he's done his stuff
<blue-frog> seb128, thought about driver. vesa at the moment as the install didn't setup i810 as it did in breezy
<seb128> ok
<seb128> blue-frog: if you set it to "autovideosink", does it work?
<blue-frog> seb128, yes it does
<seb128> so we should probably use autovideosink by default
<jamesh> seb128: out of interest, are Launchpad bug notifications getting through to desktop-bugs@lists.ubuntu.com?
<dholbach> no more totem bugs! :)
<dholbach> jamesh: the list has to be unmoderated, but yes, of some packages they get "through" to the list (rather the moderator)
<seb128> jamesh: every time I comment on a desktop bug I get a moderation mail
<seb128> if that's the question
* seb128 kicks launchpad
<dholbach> but they go to 1) the 'gnome' team, 2) desktop-bugs@ and 3) seb128 :)
<jamesh> seb128: I can give you the magic incantation to allow the mails through if you want
<seb128> would be useful, thanks
<dholbach> (at least that's what i observed for some packages)
<seb128> but when I comment on a malone bug I should not have to care of who is subscribed to the bug and get moderation mails
<seb128> I mean I comment on launchpad
<seb128> that part should be launchpad's issue
<seb128> the user doesn't care there is a list with moderation plugged somewhere on the launchpad way
<Mithrandir> seb128: the list should turn off the "notify sender when posts are held", then
<jamesh> seb128: from the mailman list admin interface, choose "Privacy options", then "spam filters"
<seb128> Mithrandir: launchpad should not send the mail as coming from me
<Mithrandir> seb128: that depends.. see the discussion on warthogs?
<seb128> Mithrandir: I did comment on a bug tracker, I didn't mean to send a bug to some list subscribed to it
<jamesh> seb128: for "Spam Filter Rule 1", enter "X-Generated-By: Launchpad" as the regexp, and set the action to "accept"
<seb128> jamesh: thanks
<Mithrandir> seb128: I'm arguing it's a bug in the list setup, not in LP.  You seem to disagree
<seb128> yeah
<seb128> I argue than as an user I should not have to care about that
<seb128> I comment on a bug tracker
<seb128> who is subscribed to the bug and what list is misconfigured is not my issue
<siretart> is there an ETA for the next flight release?
<Mithrandir> siretart: this week or next, I think Kamion said.
<seb128> I know what is happening, but how a standard user would react?
<siretart> Mithrandir: thanks.. I'm having still heavy trouble with 2.6.15 and hope that a fresh install could fix that..
<fabbione> siretart: !
<fabbione> siretart: igor is down
<fabbione> siretart: any chance to get it back online?
<Kamion> seb128: IME as owner@bugs.debian.org, we totally ignore moderation mails
<siretart> fabbione: yes, I read your query
<fabbione> siretart: a reboot would do. it was my fault
<fabbione> siretart: ok thanks
<Kamion> do you think launchpad admins are going to be any better after reading thousands of them? :)
<siretart> fabbione: we will change the ram with this chance
<fabbione> siretart: great
<Kamion> although I suppose they could be sent to /dev/null
<siretart> fabbione: I don't know when joerg will get to the datacenter next time, but I'm quite sure it will be this week
<seb128> I just say it's confusing for an user commenting on a bug
<blue-frog> seb128, if i play with gstreamer-properties and hit test on Xwindows(X11/Xshm/XV) I get "failed to construct test pipeline for Xwindows(X11/Xshm/XV. Guess it's coming from the video driver and that I shouldn't bother  you with that, correct?
<siretart> fabbione: I will ping you when it's back online
<seb128> sending them to some log would be good enough
<seb128> blue-frog: you have no xv that's all
<fabbione> siretart: if he can't manage this week, please tell him NOT to power it up
<fabbione> siretart: because i am going VAC and we don't want a buildd without a babysitter
<siretart> fabbione: oh. ok, when is the deadline?
<fabbione> siretart: saturday. i will leave sunday very early in the morning
<siretart> allright. will do
<fabbione> thanks
<adrian15> Kamion: Can you reload the page and tell me what do you think?
<adrian15> Kamion: Another question. Is there any place where I can find hipotetical fixes that you did to the grub that you were using in the first ages of ubuntu ?
<Kamion> adrian15: they should all be in the .diff.gz files in the archive
<adrian15> Kamion: url?
<Kamion> http://archive.ubuntu.com/ubuntu/pool/main/g/grub/
* Kamion commits his rescue-mode integration for grub-installer
<Kamion> should get that into dapper
<adrian15> Kamion: I've you've used graphics... is it the current patch for having image support on grub or another one?
<Kamion> parse error?
<adrian15> Kamion: Are you talking to me ?
<Kamion> yes
<adrian15> Kamion: I've seen you include Graphics.h which I think it is not included in official grub
<adrian15> Kamion: I'm looking at: http://archive.ubuntu.com/ubuntu/pool/main/g/grub/grub_0.97-1ubuntu2.diff.gz
<Kamion> that patch just comes from Debian
<Kamion> we don't modify it in any way
<adrian15> Kamion: Ummm.... So it is a debian patch for images... ok... but what about the patches you told me about not booting in many machines... or did you not try to patch it ?
<Kamion> no, we didn't try, because *isolinux worked fine* :-)
<Kamion> at least, we didn't try as far as I know
<Kamion> but we had a perfectly good and well-tested alternative option available
<pitti> Hi
<siretart> wheee
<ogra_ibook> pitti !
<siretart> just upgraded to latest udev/linux-2.6.15, now I get a 'ALERT! /dev/hda2 does not exist. Dropping to a shell!'
<pitti> ogra_ibook: hey :)
<siretart> grmbl
<Keybuk> siretart: did you also upgrade module-init-tools and initramfs-tools ?
<ogra_ibook> pitti, how far is the "automatic audiosink" stuff ? my changes for ltsp sound enetred dapper yesterday 
<siretart> Keybuk: isn't there a hard depends on them, too? 
<pitti> ogra_ibook: it's implemented since one or two weeks
<Keybuk> should be
<Keybuk> but worth checking
<ogra_ibook> pitti, i'd like to have a look at the autodetection stuff, where is it hidden ? 
<siretart> booting live cd and rechecking
<pitti> ogra_ibook: what do you want to change? it's easier to explain that way
<pitti> ogra_ibook: in general, each sink plugin registers itself with a priority
<pitti> ogra_ibook: and the autosink tries each one in succession with descending priority until the first one succeeds
<ogra_ibook> we agreed on a ltspsink that gets probed before the others and points to the esdsink if we detect LTSP_CLIENT is set, remember ? 
<Keybuk> siretart: actually, could you boot your ordinary system to the point where it does the ALERT and gives you a shell instead
<pitti> ogra_ibook: yes, I remember; does an ltspsink exist already?
<pitti> ogra_ibook: it's no problem to change the priorities of the sinks, I can do it easily
<pitti> ogra_ibook: oh, wait; we can just decrease the priority of the alsadmixsink if LTSP_CLIENT exists, so that esound is first priority
<ogra_ibook> nope, doesnt exist yet, thats why i wanted to have a look 
<ogra_ibook> ahuman01, cool !!
<ogra_ibook> oops
<pitti> ogra_ibook: does it do any other magic on top of esdsink apart from checking the env var?
<ogra_ibook> s/ahuman01/ah
<ogra_ibook> nope
<ogra_ibook> esddsp is set by the loginmanager pointing to the thin client already ... nothing needed on the server side
<ogra_ibook> so its only the part that makes sure that esd is really used on the desktop that missing (ltspsink)
<ogra_ibook> (or a change in autosink that respects LTSP_CLIENT as you like :) )
<pitti> ogra_ibook: ok, so if we change the priorities to esd > alsadmix > alsa if LTSP_CLIENT is set would be enough?
<ogra_ibook> yup
<ogra_ibook> absolutely :)
<pitti> ogra_ibook: (by default, we have alsadmix > esound > alsa
<ogra_ibook> yup, i understood 
<pitti> ogra_ibook: ok, I'll do that
<ogra_ibook> cool !!
<siretart> Keybuk: how can I boot into my ordinary system? it won't boot without my /dev/hda2 (root device)
<ogra_ibook> thanks a lot :)
<pitti> no problem
<ogra_ibook> :-D
<Keybuk> siretart: boot until it fails, it'll give you a shell, then we can "debug" :)
<pitti> infinity: ping
<siretart> Keybuk: ah, that was the point I was before. Now I have the live cd started, where I can check the versions of the packages
<infinity> pitti: pong
<Keybuk> /var/lib/dpkg/status
<siretart> module-init-tools Version 3.3.2-1ubuntu2
<siretart> initramfs-tools: 0.40ubuntu13
<Keybuk> ok
<Keybuk> so reboot into the failed state
<StevenK> Hrm, at least that's better than what the Debian did.
<StevenK> "Waiting x seconds for /sys/block/dev/hda" ad infinitiem.
<siretart> Keybuk: ok, I have a shell now
<Keybuk> we don't wait for hda, no point
<Keybuk> siretart: cat /proc/modules and list me the module names loaded
<siretart> ide_generic thermal processor fan fbcon bitlit softcursor capability commoncap vga16fb vgastate cfbimgblt cfbfillrect cfbcopyarea tileblit font
<Keybuk> ok...
<Keybuk> udevplug -v -Bpci -Iclass=0x01*
<Keybuk> what does that say?
<siretart> /sys/devices/pci0000:00/0000:00:1f.1
<Keybuk> cat /sys/devices/pci0000:00/0000:00:1f.1/vendor
<Keybuk> cat /sys/devices/pci0000:00/0000:00:1f.1/device
<StevenK> Keybuk: My point was that Ubuntu gives you a shell
<Keybuk> cat /sys/devices/pci0000:00/0000:00:1f.1/class
<Keybuk> StevenK: and if you exit that shell, it tries to carry on assuming you fixed the problem <g>
<siretart> Keybuk: does it help you if I say its a Thinkpad R40 with Pentium M and atheros? ;)
<Keybuk> siretart: nope
<Keybuk> siretart: not unless you mail it me ;)
<StevenK> Muahaha
<StevenK> siretart: Quick, take a picture and e-mail it to Keybuk.
<siretart> vendor is 0x8086
* StevenK ducks.
* Keybuk smiles at Intel's "oh so clever" vendor-id
<infinity> I like how you've managed to have exactly zero useful block drivers loaded.
<ogra_ibook> lol
<siretart> device is: 0x24ca
<Keybuk> infinity: yes, that is quite special, isn't it <g>
<siretart> class is: 0x01018a
<siretart> what now?
<Keybuk> siretart: I'm guessing that the following produces nada
<Keybuk> grep pci:v00008086d000024ca /lib/modules/*/modules.alias
<Keybuk> uh, sorry
<Keybuk> grep pci:v00008086d000024CA /lib/modules/*/modules.alias
<Keybuk> needs to be in caps
<Keybuk> (at least the id does)
<siretart> it produces 'alias pci:v00008086d000024CAsv*sd*bc*sc*i* piix'
<Keybuk> ok....
<Keybuk> uh, this may seem silly, but ... "uname -a" ? :)
<ogra_ibook> yippie ! edubuntu-desktop is installable again 
<siretart> Linux (none) 2.6.15-11-686 #1 SMP PREEMPT ....
<siretart> the rest too?
<dexem> dholbach: I've just sent the CAMEL_DEBUG log for the evolution/TLS bug.  ask me whatever you need here :)
<Keybuk> nope that's fine
<Keybuk> hmmmmmm
<Keybuk> can you check /proc/modules and confirm for definite that "piix" isn't loaded?
<siretart> triple checked, piix is NOT loaded
<infinity> piix is definitely copied in.
<dholbach> dexem: did you see anything interesting in there?
<infinity> siretart: I assume you can modprobe piix and it works?
<siretart> infinity: loading by hand works
<dexem> dholbach: CamelException.setv(0x8c74cd0, 2, 'Failed to connect to POP server pop.warp.es in secure mode: SSL negotiations failed')
<siretart> but still no /dev/hda2
<Keybuk> infinity: did you ever get around to adding that DEBUG mode to initramfs
* infinity raises his eyebrow.
<Keybuk> siretart: ok, so you've loaded piix and you have no /dev/hda2 ?
<infinity> Keybuk: No, looks like I should do that tomorrow, eh?
<siretart> Keybuk: yes
<Keybuk> yes you have no hda2?
<dholbach> dexem: maybe we can ask the upstream guys, what's wrong
<siretart> Keybuk: /dev/hda2 is my root file system, but I still have no device node /dev/hda2 in that shell
<siretart> there is also no /dev/hda
<infinity> Keybuk: Kernel bug?... piix broke recently, perhaps?
<Kinnison> siretart: has it turned up in /proc/partitions?
<siretart> Kinnison: /proc/partition is empty
<siretart> just the header 'major minor #blocks name'
<Keybuk> infinity: that's all I can think
<infinity> siretart: Is this an upgrade from breezy, or a dapper->dapper upgrade?
<Keybuk> "Dear Mr Kernel, my computer has an IDE controller, could you please SEE THE FUCKING THING!" :p
<Kinnison> Keybuk: and we don't need the ide-<foo> module in order to get piix to probe subsequently?
<Keybuk> anyway, this is so not a udev bug <g
<Keybuk> Kinnison: no, I fixed that
<Kinnison> Keybuk: yay
<Keybuk> and I don't think BenC re-broke it
<siretart> infinity: this is an upgrade from a breezy/dapper mixed system to 2.6.15. I wanted to recheck this bug: http://bugzilla.ubuntu.com/show_bug.cgi?id=21529
<infinity> Although, if ide-generic is winning the evil race of doom...
<Keybuk> Kinnison: either way, ide-generic would steal the devices
<Keybuk> because it's been loaded
<Keybuk> so we have a machine which
<Keybuk> a) piix isn't automatically loaded
<Keybuk> b) devices don't show up even when piix is manually loaded
<Keybuk> c) ide-generic is loaded through the udev "heeeelllp" fallout
<Keybuk> d) devices don't even show up then
<infinity> siretart: After you modprobed it, does piix show up in /proc/modules, or no?
<Keybuk> I'm going for "iz kernel bug"
<siretart> infinity: yes, at the first line
<infinity> siretart: And can you boot without "quiet" or "splash" on the command line, and try to see if anything interesting appears to be happening in the kernel output?
<Keybuk> siretart: silly question ... ps ax ... is udevd running?
<siretart> Keybuk: running at pid 931 with option '--daemon'
<Keybuk> just checking
<dexem> dholbach: ok, thanks :)
<Keybuk> reboot without quiet or splash on the command line
<Keybuk> and with break=premount
<siretart> I also have a 'nolapic' option, shall I remove that too?
<Keybuk> that'll drop you to a shell a bit before things
<Keybuk> well....
<StevenK> Your local APIC is broken?
<siretart> I needed it for suspend/usb terror in 2.6.12
<Keybuk> either remove nolapic and try booting normally
<Keybuk> or leave it in and do our suggestion
<Keybuk> in fact, yes, remove nolapic and boot normally (without quiet/splash though)
<siretart> ok, I now removed all that junk
<siretart> piix still not loaded automatically
<Keybuk> ok
<Keybuk> kill udevd
<siretart> when loading via modprobe I get a funny msg
<Keybuk> then start it with ... UDEV_LOG=info udevd --daemon
<Keybuk> meh, don't modprobe just yet
<Keybuk> reboot again :p
<siretart> ICH4: port 0x01f0 already claimed by ide0
<siretart> ICH4: port 0x0170 already claimed by ide1
<siretart> ICH4: neither IDE port enabled (BIOS)
<infinity> Bing.  ide-generic needs to be blacklisted.
<Keybuk> infinity: no, ide-generic needs to be not loaded in the first place
<siretart> ok, will reboot again, just a sek
<Keybuk> siretart: reboot like this
<Keybuk> siretart: blah blah break=premount
<infinity> Keybuk: well, that too.  But it's loaded rather quickly in some cases.
<Keybuk> with no nolapic, quiet or splash
<Keybuk> infinity: shouldn't be
<Keybuk> infinity: if ide-generic ever gets loaded alongside a real ide driver, it's a bug
<siretart> Keybuk: done. what now?
<Keybuk> siretart: so you're at a shell?
<siretart> yes
<Keybuk> ok run the following:
<Keybuk> UDEV_LOG=info udevd --daemon
<Keybuk> that should print a few messages on screen?
<infinity> Keybuk: The way I read the script, it can easily race and win, if the driver destined for providing the root device is a little too slow to initialise.
<siretart> initialize max_childs to 64
<siretart> initialize max_childs_running to 16
<pitti> Keybuk: you broke cups :) (nm, I'll fix it)
<Keybuk> infinity: ide devices initialise before the modprobe returns ... I fixed that in the kernel
<infinity> Keybuk: Hrm.  Kay..
<Keybuk> siretart: ok
<Keybuk> now run: udevplug -Bpci -Iclass=0x01*
<Keybuk> and see what happens
<Keybuk> describe to the best of your ability everything that gets dumped to the screen
<siretart> 4 lines:
<siretart> udev_event_run: seq 751 forced, pid [846] , 'add' 'pci' 0 seconds old
<siretart> wait_for_sysfs: file appeared after 0 loops
<Keybuk> infinity: more particularly, piix would show up then <g>
<siretart> udev_event_run: seq 751 finished
<infinity> Keybuk: One would expect, yeah.
<siretart> udev_done: seq 751, pid [846]  exit with 0, 0 seconds old
<siretart> fini
<Keybuk> siretart: ooookkkk
<Keybuk> and /proc/modules says no piix loaded?
<siretart> Keybuk: neither piix nor ide-generic
<Keybuk> right
<Keybuk> ls /etc/udev/rules.d
<siretart> 00-init.rules  20-names.rules
<Keybuk> that's it ?!
<siretart> jupp
<Keybuk> !!
<Keybuk> infinity: >?!>?!")($()!*IO_IJKPQEFJPWSFW
<siretart> ??
<Keybuk> WHERE'S THE REST OF THE BLOODY INITRAMFS?! :p
<infinity> DON'T BLAME ME.
* siretart ducks
<Keybuk> hmm, Mithrandir said something the other day that's kinda suspicious too
<Keybuk> siretart: could you ls /lib/udev for me
<infinity> siretart: Can you reboot into a backup kernels and run "update-initramfs -u -k 2.6.15-11-686"?
<Keybuk> infinity: no, don't just yet
<infinity> Keybuk: The thing about 60whatever not working?
<Keybuk> infinity: exactly
<siretart> ls /lib/udev
<StevenK> Apparently, taking over an initramfs has a whole new meaning to infinity. :-P
<siretart> ls: /lib/udev: no such file or directory
<Keybuk> ok
<Keybuk> now can you do what infinity said :)
<siretart> lets try
<Kamion> god, why does bugzilla not link package names on bug lists to the list of bugs against that package
<Keybuk> infinity: it's almost as if the udev hook aborted half way through
<Kamion> it would be such an easy thing to do and helps usability so much
<Keybuk> infinity: you do check the return value from hooks, right? :p
<Kinnison> Kamion: hold onto that thought for malone
<mdz> dexem: yes, see #ubuntu-devel logs
<Kamion> ah well, at least malone does it
<Kinnison> Kamion: oh cool
<mdz> Kamion: yes, mysql 5.0 has my approval
<Keybuk> mdz: shouldn't you be in bed? :p
<Kamion> good
<mdz> poningru_sleep: you had a question about blogging?
<siretart> infinity: done. no output
<mdz> Keybuk: "should" is easy to agree with
<siretart> infinity: reboot/retry now?
<infinity> Keybuk: We might not, actually.  I'll have to write a big blinking note to check that tomorrow.  That said, how on earth could it be aborting?... Oh, you're running it 'set -e', and if one of those files you copy doesn't exist...
<infinity> Keybuk: Hrm. :)
<Keybuk> infinity: exactly
<infinity> Yeah, I'll have to poke that first thing in the morning.
<daniels> Kamion: because being obnoxious ftw.  word up to the component selector.
<infinity> Want to write me a nasty, yes encouraging email?
<infinity> s/yes/yet/
<Keybuk> to whom?
<siretart> infinity: reboot/retry now?
<infinity> siretart: Might not make a difference at all.
<Keybuk> siretart: yes, please get into a real filesystem so I can check something :)
<infinity> siretart: mkinitramfs -k -o /dev/null 2.6.15-11-686
<siretart> woah. 2.6.15 is booting now
<infinity> siretart: And check the directory in /tmp that it mentions.  See if those files Keybuk's looking for are there.
<siretart> just with regenerated initrd
<infinity> Oh.  Crap.
<infinity> That's good.  But not good.
<siretart> wheeee! and gdm finally appears!
<infinity> Keybuk: Nasty email.  In my INBOX.  Too tired to make coherent notes.  Reminding me is on your shoulders. :)
<siretart> thank you gods! :)
<Keybuk> ok, why did that happen?
<Keybuk> initramfs regenerated by initramfs-tools upgrade, but not udev?
<infinity> I'm not positive I want to know.
<Keybuk> which makes no sense, because some bits of udev are there
<Keybuk> hmm, oh
<Keybuk> ahhh
<infinity> Shouldn't matter, cause every postinst should do it over and over and over again, until the last one gets a "complete" initramfs.
<Keybuk> how about this then
<Keybuk> initramfs-tools regenerates the initramfs
<infinity> (inefficient, icky, I want dpkg hooks, but it should work...)
<Keybuk> at this time the old udev conffiles are there, but with the new udev hooks
<Keybuk> so the udev hook bails because it can't find the old conffile
<Keybuk> udev regenerates the initramfs
<Keybuk> but for some reason this refuses to do so
<daniels> ARGH
<daniels> ssh Dssh DESPERATELY needs better back off on packet loss semantics
<Keybuk> Mithrandir: anyway, to get /dev/disk/by-* ... try regenerating your initramfs ;P
<siretart> the framebuffer for usplash is probken on my machine, but thats another but
<StevenK> daniels: The kernel deals with retransmission, not userland processes.
<infinity> Keybuk: It shouldn't refuse, since the last initramfs-tools upload set us to "implicit takeover mode", so any update-initramfs call should plough through.
<sladen> well you want it to be *fast* dontchya?
<Mithrandir> Keybuk: I've worked around it already.
* infinity will need to play with this some more and nail down this corner case.
<sladen> oops, scroll-locked scrollback
<Keybuk> kooky
<Keybuk> either way, it's not my bug :p
<Keybuk> "udev doesn't work if most of it is missing"
<StevenK> Heh
* siretart lunch - cu later
<Keybuk> so what happened was
<Keybuk> 1) no modprobe piix rule
<Keybuk> 2) so ide-generic was loaded
<Keybuk> 3) no modprobe ide-disk rule
<Keybuk> 4) so device creation wasn't kicked
<Keybuk> not to mention no ide_media helper to figure out it needed to load ide-disk
<dexem> mdz: Ok, thanks :D
<daniels> StevenK: ssh has its own exponential backoff semantics.  and they're CRAP.
<StevenK> I'd personally trust the kernel. It seems the OpenSSH guys don't. :-)
<StevenK> (When one of them is that loving-life guy Theo, what the hell do you expect?)
<crimsun> elmo: please sync sndobj, sp-gxmlcpp, seyon, and osdclock from Sid, overriding Ubuntu changes. Thanks!
<ulaas> anyone with info on vpnc
<pitti> Kamion: could you please approve the recent pmount upload to breezy-updates? mdz ack'ed it
<pitti> elmo: please sync pmount, and backport postgresql-{common,8.0,8.1}
<infinity> EURKEKA!
<infinity> I wonder if uploading glibc is going to make me a co-maintainer.
* pitti imagines infinity running out of the tub naked
<infinity> God, I hope not.
<pitti> infinity: you know, seb128 already claimed packages starting with 'g', so you are too late
<infinity> Phew.
* seb128 slaps pitti
<Kamion> pitti: done
<StevenK> So I know why it's 'linux-image' ... so the Kubuntu's guy didn't get their hands on the kernel. :-)
<pitti> Kamion: merci
<pitti> Kamion: btw, I'd like to backport the recent postgresql data loss bugfix to breezy-updates, is that fine for you?
<Kamion> pitti: um, I guess, but I consider that mdz's decision
<pitti> ok, I'll ask him
<sladen> vuntz_: I've wasted more hours on that problem but still can't pinpoint it.  best thing is to set a break on 'submenu_to_display' and start from the backtrace;  it's 47 frames long and further up is the _show() that caused the menu to be displayed
<pitti> elmo: please remove mozilla-firefox-locale-{ca,el,eu,it,ja,ko,nb,uk} from dapper; can you also add it to the blacklist, so that they won't ever bother us again?
<pitti> elmo: (in particluar, we do not want any package but -all)
<vuntz_> sladen: does it work better with the patch in http://bugzilla.gnome.org/show_bug.cgi?id=314854 ?
<vuntz_> sladen: maybe it's just a problem in the way gnome-menus uses fam/gamin
<Treenaks> famine?
<sladen> vuntz_: something is registering with gamin everytime the menu is show.  There might be something do with show()s for the submenu going to the parent object.  
<Simira> hey, who can I blame for XChat-Gnome?
<ogra_ibook> Simira, seb128 changed the seeds, mdz wanted it in ...
<Simira> hmmm
<Simira> grmf
<ogra_ibook> Simira, just make your wannabe husband teach you the wonderful world of irissi ;)
<Mithrandir> ogra_ibook: she knows how to use irssi quite well
<ogra_ibook> heh ... so why do you complan then Simira ? :)
<Simira> ogra: I don't like irrsi. I'm not sure whether I like Xchat-Gnome either. I have to adjust!
<Simira> ah, seb! Just the guy I needed
<Treenaks> Simira: you need gaim's IRC plugin :P
<Simira> seb128: you would save me a lot of irritation by telling me how to get the user lists of channels back on my right hand side instead of a button.
<Simira> Treenaks: no f...... way!
<ogra_ibook> Simira, i dont like it either ... but you have the choice to stay with Xchat :)
<martinex> ogra_ibook, hello
<Simira> ogra_ibook: it wouldn't install. maybe some wrong spelling there
<martinex> ogra_ibook, I'm on windows now - unfortunately...
<martinex> ogra_ibook, this hint about modprobe and then ifup eth0 worked and I had an access to internet
<martinex> ogra_ibook, unfortunately there is propably a lot of things that are broken because gdm didn't work, gnome-session too... in fact console only
<mdke> infinity, nudge #2
<martinex> Kamion, hello - ogra said that you could know something about problems with udev
<ogra_ibook> martinex, nope i didnt
<ogra_ibook> martinex, i said Keybuk
<martinex> aaaah sorry :)
<martinex> Keybuk, ping
<ogra_ibook> martinex, but the problem with the NIC is known ...
<daniels> Treenaks: btw, I have the tool for you.  i'll email you with instructions some time when it's not 12am.
* daniels -> bed.
<martinex> ogra_ibook, hmm so then why ubuntu-desktop doesn't want to work?
<martinex> ogra_ibook, could udev be a reason of this issue too?
<Treenaks> daniels: OK, great
<Kamion> right, with any luck that's all the big outstanding install CD issues from flight-2 out of the way
<ogra_ibook> Kamion, cool, the -desktop packages are installable as well :) lets do a flight3 ;)
<Kamion> assuming that my choose-mirror upload works, I'll start working on Flight CD 3 soon
<Kamion> ogra_ibook: yep, that was the general idea
<Kamion> need to push through a d-i rebuild before that though
<ogra_ibook> yay!
<seb128> Simira: there is no way to move the list
<seb128> Simira: you can install chat
<seb128> xchat
<pitti> mdz: can you please take a look at https://bugzilla.ubuntu.com/show_bug.cgi?id=22221 (postgresql data loss bug fix for breezy-security) and approve/deny? TIA
<jsgotangco> flight 3 weee
<tseng> jsgotangco: yay
<Kamion> ok, you guys are scary
<jsgotangco> i've been avoiding the daily lately....
<tseng> Kamion: are you still up for working on mono/ppc?
<tseng> Kamion: someone passed me some more notes over irc regarding your testing
<tseng> Kamion: (other work permitting of course)
<ogra> tseng, i thought that was ppc64 specific 
<tseng> ogra: hm it seems to be smp specific atm, but regardless it is blocking progress
<tseng> ogra: colin helped us out by getting a backtrace on a similar system in the DC
<Kamion> tseng: did you see the backtraces I put in the upstream bug report?
<Kamion> ok, yes, you probably did
<tseng> Kamion: yes.
<Kamion> I'm up for working on it in the background if given directions on what to do, but I'm kind of stuck on figuring out any more by myself
<Kamion> I don't know mono well enough to diagnose smp-related bugs in it by myself
<tseng> ok, ill post the request on the bug
<tseng> if i can find it again
<tseng> geoff should have put them there himself
<Kamion> http://bugzilla.ximian.com/show_bug.cgi?id=77028
<Kamion> my comment's the last one there
<tseng> ya adding from irc
<Kamion> tseng: christ that's a lot of output
<tseng> Kamion: yeah, just as bad as mono --trace
<ogra> tseng, didnt upstream say they'd work on it as well ?
<ogra> no progress there ? 
<zakame> evening devs :)
<tseng> ogra: geoff said he would work on trying to source an smp ppc
<ogra> yes, thats what i remembered
<tseng> ogra: but he is a volunteer same as me
<ogra> oh, k
<tseng> i havent heard a peep from novell, yet
<tseng> besides miguel saying "osx wfm"
<ogra> heh
<ogra> who cares for osx
<martinex> apple
<ogra> pfft
<tseng> ogra: miguel has different priorities than most of us.
<martinex> ogra, do you know when udev issue is going to be fixed?
<ogra> nope
<ogra> but surely before relese ;)
<ogra> *release
<martinex> ehhh I'll try to install breezy and'll wait for some changes on ubuntu-devel list...
<martinex> but really have no idea why gnome on dapper doesn't want to work now
<tseng> gnome is a pretty wide target, what specifically doesnt work?
<martinex> tseng, nothing...
<ogra> you probably used dist-upgrade instead of upgrade and essential pieces are out of snyc or something
<martinex> tseng, just hangs on ugly brown screen ;)
<tseng> ogra: i always use dist-upgrade
<Kamion> not that dist-upgrade is our recommended upgrade method or anything :P
<ogra> i never use it in development releases
<tseng> (and fix anything that blows up)
<ogra> upgrade and cherrypick the known good pieces ...
<Kamion> dist-upgrade is exactly what you need to use while tracking development releases, except that you need to be careful to keep an eye on what's going to be removed
<martinex> ogra, I'm not sure if dist-upgrade could be reason.. but can try to update ... 
<Kamion> unless you feel like installing every single package that gets rearranged by hand
<martinex> and just 'upgrade'
<ogra> Kamion, if you upgrade often thats mostly not much .. and if a transition is going on its mostly only one package i pull in manually, the rest gets done with the next upgrade 
<martinex> ok need to reboot to get what's going on
<ogra> indeed, if i want to test upgradeability and not only work on my stuff i do a dist-upgrade occasionally
<\sh> pitti: ping
<pitti> \sh: pong
<\sh> pitti: I don't need to call autoreconf or stuff for the breezy wine sec update..it will generated from configure, it's an .in file, and not Makefile.am :)
<\sh> oh a be is missing...uploading now :)
<ogra> a be ? 
<ogra> a belgian ? 
<\sh> yes...looks like my brain is faster then my fingers
<pitti> \sh: oh, I see; so .am doesn't need to be patched? (not that we would in a security update, but in general it shouldn't be modified manually)
<\sh> pitti: there is no .am :) which is nice :)
<Kamion> tseng: ok, done
<pitti> \sh: aah, I see :)
<\sh> pitti: and the hoary I will change to the 0.1 numbering thx for mentioning it :)
<\sh> pitti: both sec-updates uploaded
<pitti> thanks
<pitti> \sh: so we're still faster than Microsoft? or did they release the patch last Thursday?
<\sh> pitti: hmmm...well..they released one patch...but this patch breaks everything what worked with wmf...because some people think that this issue was planned :) 
<\sh> ok...they release the patch on thursday
<\sh> released even
<zakame> wb slomo :)
<slomo> hi zakame 
<\sh> pitti: but this is much nicer: http://www.heise.de/newsticker/meldung/68157
<pitti> lol
<\sh> and ms has regained the FAT patent...should this mean that we have to remove FAT support from the kernel?
<slomo> i guess no... i bet it's not the only patented stuff in the kernel let alone in main
<\sh> slomo: well, we see what MS is doing in the future :)
<tepsipakki> let's just stall like they've done with removing media player ;)
<dilinger> we can remove FAT from the kernel and claim that our kernels are 20% smaller and thinner than our leading competitors
<\sh> dilinger: oh well....what about my usb mp3 stick then...
<zakame> lol
<ogra> format it ext2 :)
<ivoks> \sh: then all mp3 players should abandone fat, cause of the patent :)
<ivoks> or pay to MS
<trappist> yeah when you're selling something you can just license it
<\sh> ivoks: they pay already I think, 0,25 cent
<ivoks> doh...
<\sh> US cent that is
<\sh> max. sum for one manufacture: 250.000 US $
<\sh> to pay :)
<ivoks> i hate patents...
<trappist> me too, and I'll continue to hate patents until I invent something
<ivoks> :)
<trappist> but software patents are the suck
<\sh> and right now, I'm want to be in the US :) This "The Violence against Women and Department of Justice Reauthorization Act 2005" is just fun
<ivoks> uh, uh... hard to install mysql5 over mysql4 :/
<wasabi> flash should be formatted jffs anyways
<wasabi> way more efficient.
<fabbione> Riddell: FYI: kdebase is still FTBFS.
<Riddell> fabbione: yeah, fixing. just me being silly I think
<fabbione> ok
<\sh> Riddell: that can't be...
<tseng> Kamion: thanks!
<Riddell> actually I don't think any KDE stuff will compile until the kde avahi library gets past NEW
<seb128> elmo, Kamion: I've uploaded pygobject, pygtk has been splitted to pygobject/pygtk ... if you could promote it when you accept it that would be nice
<\sh> if someone could elaborate slowly (because I'm really old now with 35 as of today) what the hell is avahi or zeroconf...I don't understand this hype
<ivoks> \sh: mDNS
<HiddenWolf> \sh, congratulations on  your birthday
<ivoks> \sh: aka Bonjour
<hno73> I want to file a bug on the gnome file selection dialog - should I file that under gnome-common? 
<hno73> When I try to open a local file it insists on connecting various servers I have bookmarked, which cannot be right
<\sh> ivoks: what does it do...I just know, that it should automagically determine services
<\sh> ivoks: on hosts in the network 
<ivoks> \sh: if you ask me, i would say it's bloat
<ivoks> \sh: but i find KDE and Gnome bloat, so... I'm not a merit
<ivoks> \sh: purpose is to "brodcast" what services you have
<ivoks> \sh: for example, avahi can brodcast that you have CUPS (wich is kind of silly, cause CUPS does that too)
<Robot101> \sh: it allows broadcast queries/responses to find a) machines and b) services (web, music, printers, whatever) on your local network
<Robot101> \sh: zeroconf is the idea of using this with random link-local (169.254) addresses, so that you don't need to fiddle with IPs to eg share a file or a printer with someone
<Treenaks> Robot101: but it also just uses 'normal' IPs if they happen to be available (because of proper DHCP etc.)
<slomo> or for multiplayer games to find an open game you could join
<Robot101> \sh: rendezvous and bonjour are apple's old and new names for this technology, and they use it as the basis for file, printer, music and chat services on OS X
<ivoks> basicly, osx has it, so we should too :))
<Robot101> mDNS is a stupidly licensed implementation of this, avahi is a sensibly-licensed implementation that uses dbus to expose your system's zeroconf stack to applications
<Robot101> (you need a single responder per system, for reasons of owning the socket, caching, etc, so avahi allows you to register local services, query available services on the network, etc, using the system bus)
<slomo> and avahi has a much nicer API than howl/libdns_sd ;)
<Robot101> also you can plug it in to nss, so you can do "host foo.local" and find a box
<\sh> Robot101: is it "local net" as in "the same network as your requested IP via dhcp, ppp, pppoe etc. with the same netmask" or "local-net" as in "only the ip-network connected to available hardware devices"
<Robot101> \sh: its aimed at local networks, so I think it's ethernet broadcast based, rather than IP broadcasts, but I might be wrong
<Robot101> it might do both of course
<ivoks> it's PITA for admins :)
<ivoks> cause it crates disturbance in organised networks :)
<Robot101> its supposed to alleviate the need :)
<slomo> it uses IP broadcasts... it's definitely not ethernet based and works fine over vpn for example too ;)
<\sh> Robot101: ok..so I need to find a way to disable that easily
<\sh> slomo: argl...you scared me now...
<ivoks> \sh: deinstall it :)
<\sh> slomo: which means we need a simple way to enable it on demand and not by default
<slomo> \sh: it uses all interfaces with the MULTICAST flag set by default... and for disabling, just disable the daemon and everything is fine ;)
<slomo> and the daemon isn't installed by default (unless the package using avahi has an hardcoded dependency on it)
<ivoks> well
<ivoks> we should all install it
<\sh> slomo: no..other way around..those security incidents should be disabled by default...and only enabled, with a lot of warnings and more warnings and "please don't do it", on demand
<ivoks> just cause lathiat works on it :)
<slomo> \sh: just read above... the daemon isn't installed by default normally... you need to install it yourself to get all this magic ;)
<\sh> slomo: phew..
<\sh> and nobody should come up with the idea to install and enable it by default...I will go back to linux from scratch ;)
<slomo> \sh: and for other questions... #avahi  :)
<\sh> slomo: well I only wanted to have a light on "what does it do to my system" ;)
<HiddenWolf> \sh: not to much, by default, due to the no open ports policy
<Nafallo> hmm
<Nafallo> \sh: you think the missing line fixes my bug?
<\sh> Nafallo: no...the missing line was in the libnotify bug patch..but somehow I missed it because it wasn't an add...I think it belonged to the new upcoming 0.10 source dev tree
<\sh> Nafallo: but I received a mail that this belongs actually to this bugfix...
<Nafallo> ah, oki.
<Nafallo> so the patch wasn't complete either way then ;-)
<\sh> Nafallo: right...updated my local bzr archives now...have to rsync them to tiber
<Nafallo> ah
<Nafallo> that's why it wasn't updated then :-P
<Keybuk> hmm, the log out dialog really needs some kind of "I'm On Top!" hint
<slomo> and a stay-on-top-and-disable-everything-else hint ;)
<Keybuk> and it REALLY needs to not segfault and shut down the machine when I click "Cancel" ;)
* Keybuk puts on his grumpy face
<Nafallo> lol
<sivang> Keybuk: owww
* ogra cant imagine Keybuk with a really grumpy face
<Keybuk> heh, I'm too happy?
<Kamion> hooray, my mad syslinux hacks work
* sivang neither
* \sh watched the day before last the movie "Hackers" (somehow from the 90ties)...and the main actor (blond guy) just looked a bit like keybuk...(that's what I thought)
<ogra> Keybuk, s/happy/gentile ?
<ogra> :)
<sivang> \sh: lol
<sivang> \sh: stupid movie :)
<sivang> I also watched it some 5 years ago
<Keybuk> \sh: heh, amusingly Aq (LugRadio/WolvesLug) was ripping into that movie and declared in a loud voice that "yeah, as if you've seen ANY programmer ever go around the place on rollerblades"
<Keybuk> I was sitting opposite him
<sivang> Keybuk: wearing rollerblades?
<Keybuk> not at the time
<Keybuk> wolves is a bit far too skate to
<Nafallo> baah
<\sh> sivang: actually I wanted to know how angelina jolie was looking in her early days...
<Nafallo> he gets the nice girl in the end. I sure hope it's a real story :-).
<\sh> just before she went upstairs to play a computer character
<Keybuk> it has the "I am standing here beside myself" guy from Short Circuit in it
<Keybuk> how can it not be an ultimately great movie?
<Keybuk> sabdfl: Hackers, great movie, no? :)
<desrt> Keybuk; horrible movie
<desrt> Keybuk; i was actually discussing this with a friend last night.  it's his favourite movie but he admits it's horrible.
<mjg59> It's not a /horrible/ movie
<Keybuk> bah
<mjg59> Antitrust is a horrible movie
<desrt> (his attraction to it is for nostalgic reasons)
<Nafallo> mjg59: word!
<Nafallo> :-)
<Keybuk> Anti-trust is like a car crash though
<Keybuk> you watch it with rapt attention
<mjg59> "Apple's shares yesterday closed at $80.86" ha ha ha
<desrt> how appropriate given recent circumstances.
<\sh> well..hackers is just like weired science (http://www.imdb.com/title/tt0090305/) 
<\sh> a nice teenie movie :) just replace Kelly LeBrock with Angelina Jolie
<Nafallo> that's another reason Hackers rocks! Angelina! :-D
<sivang> \sh: weird scient..hmmm :)
<desrt> wow
<desrt> that's _weird_
<desrt> that actually happened yesterday?
<\sh> sivang: 1985...funny movie...but just a typical "I'm a model and try to act..so I need to show my boobs only and shake my bum"
<desrt> i thought that was a quote from the movie or something
<sivang> \sh: exactly :)
<sivang> \sh: I didn't know angelina was in hackers 
<Nafallo> sivang: she's the girl :-)
<Keybuk> "Acid Burn"
<sivang> Nafallo: with the short hair?
<Riddell> elmo: please reject kdnssd-avahi from NEW, agreed with debian to just include it in kdelibs
<\sh> sivang: yepp
<sivang> I didn't recognize her in so short hair....
<Kamion> lamont: what happened to the daily d-i build I triggered by hand a little while ago?
<Kamion> I don't see a build log for it
<lamont> Kamion: which arch?
<Kamion> amd64/i386/powerpc/sparc
<Kamion> oh, hmm, it's possible I only processed this morning's build just before triggering the new one and didn't wait for an intervening cron.daily
<Kamion> that would screw it, wouldn't it?
* Kamion kicks off another build
<lamont> there was an i386 build at 1517 your time... sound right?
<lamont> built-successfully
<Kamion> mm, right, I think it must have been uploaded and rejected
<lamont> Jan 11 15:21:00 buildd-mail: Moved debian-installer_20051026ubuntu11.0.20060111 to upload-dapper
<lamont> yeah
<lamont> um, yeah
<Kamion> there've been a couple of intervening cron.dailies so it should work now
<lamont> wanna-build and I don't always see eye-to-ey
<lamont> e
<lamont> it's more a function of whether or not cron.daily runs _during_ the sbuild
<lamont> or something like that
<Kamion> it probably did
<fabbione> Kamion: you are not triggering sparc :) i am doing it manually.. do you want to be able to?
<fabbione> do you need one right now?
<Kamion> fabbione: oh, right, yeah, not sparc sorry
<Kamion> not for sparc, no
<Riddell> Mithrandir: I still get the "underlying authentication module" error on today's kubuntu live cd
<fabbione> :D
<lamont> Kamion: and you don't love hppa anymore?/
<fabbione> Kamion: ok :)
<Kamion> lamont: my script doesn't know how to trigger it, and if I ever knew, I've forgotten
<lamont> Kamion: bld-3.mmjgroup.com, otherwise no diff
<Mithrandir> Riddell: I should probably take a look at kubuntu sometime, then.
<Kamion> lamont: thanks, it knows now
<Mithrandir> Riddell: it helps if you actually ping me while I'm at work and not when I've gone home. :-P
<Kamion> Riddell: the manifest for kubuntu daily-live shows an old timestamp so I suspect it's just an old livefs
<Kamion> http://terranova.buildd/~buildd/LiveCD/dapper/kubuntu/latest/livecd-20060111-i386.out (from chinstrap) confirms build failure
* sivang pokes to try and make libnotify/tests work again
<Kamion>   kubuntu-desktop: Depends: cupsys-driver-gimpprint but it is not going to be installed
<Kamion>                    Depends: foomatic-db-gimp-print but it is not going to be installed
<lamont> go cupsys
<pitti> dholbach: ^ that should be gutenprint now, right?
<Kamion> yes
<ogra> ah, same applys for ubuntu and edubuntu 
<Kamion> the Ubuntu seeds need to be changed too; I'll do that
<ogra> Kamion, could you add gnome-screensaver as well and remove xscreensaver ? 
<Riddell> Mithrandir: you don't work from home?
<ogra> oh and xscreensaver-data
<Mithrandir> Riddell: no, I work from an office.
<pitti> Kamion: NB that gutenprint does produce cupsys-driver-gimpprint, however, it produces foomatic-db-gutenprint now
<Kamion> ogra: it's already done
<sivang> \sh: did you manage to make your notify-daemon to work?
<Kamion> you did it
<ogra> Kamion, oh, thanks
* Kamion wonders if ogra is suffering from amnesia ...
<lamont> Kamion: is cupsys not seeded in dapper then?
<Mithrandir> Riddell: and even if I did work from home, I would have had work hours and non-work-hours. :-)
<ogra> Kamion, do my edubuntu changes get synced ? i only did it for edubuntu 
<\sh> sivang: notify-daemon? you mean gajim?
<ogra> Kamion, else i agree about the amnesia part 
<Kamion> ogra: I beg to differ, you did it in the Ubuntu seeds
<ogra> hmm
<Kamion> bzr log also begs to differ
<pitti> Kamion: (still, c-d-gimpprint is only a transitional package, so changing the seeds is fine)
<sivang> \sh: oops. brain.rollback()
<Kamion> yeah, I'm changing them over now
* Nafallo hopes Mithrandir is finished with his change before the seeds get uploaded ;-)
<ogra> Kamion, hmpf .... i should do a calcination checkup 
<Kamion> Nafallo: doesn't matter?
<Nafallo> Kamion: just to save an upload of them? :-)
<Mithrandir> Nafallo: I'm not, as I haven't even checked them out yet.
<Kamion> Nafallo: *shrug*
<elmo> mozilla-firefox-locale-ca (1.0.6-1/1.0.6-1ubuntu1): in main - skipping.
<elmo> mozilla-firefox-locale-eu (1.0+0.1-1/1.0+0.1-1ubuntu1): in main - skipping.
<elmo> pitti: do we need them?
<pitti> elmo: no, all of them are obsolete and superseded by -all
<elmo> Kamion: are you trying to build an image?
<pitti> elmo: I'll unseed them
<pitti> (after Kamion finished his changes)
<Kamion> elmo: soonish
<Kamion> why?
<elmo> Kamion: was gonna do some removals, but it's not important, I'll wait
<dholbach> pitti: sorry for the gutenprint breakage
<pitti> dholbach: is the package itself broken?
<dholbach> pitti: no, the dependency :)
<pitti> dholbach: I wonder why Kamion has troubles with installing cupsys-driver-gimpprint, it should just be the transitional package
<pitti> dholbach: ah, the seeds
<Kamion> pitti: I don't, the live fs had trouble this morning before I promoted *-gutenprint
<ogra> pitti, all -desktop packages have
<Kamion> there is no breakage now
<pitti> Kamion: ah, ok, that explains
<Kamion> ogra: had, this morning; have no longer
<ogra> yes
<ogra> :)
<Kamion> ogra,Riddell: should xscreensaver-data be in the kubuntu seeds? (I'm merging)
<Kamion> or xscreensaver-gl I guess
<dholbach> anyway, i'm dogwalking - bbl
<ogra> its only the hacks, dunno if riddell wants to use them
<ogra> they shouldnt be in edubuntu
<Kamion> ok
<Kamion> I'll leave them out in the merge for now
<blue-frog> Kamion, so i guess i just need to wait for my repo to be updated. I have the gutenprint problem.
<Kamion> blue-frog: correct
<Riddell> Kamion: no thanks
<Kamion> ok
<Kamion> ouch, this hasn't been merged for long enough that the Kubuntu install CDs will definitely be hosed due to kernel ABI desync
<Kamion> elmo: I'll do this d-i upload unless you're on it already
<ogra> Kamion, so you plan the final flight3 images today already or is this just a test run ?
<elmo> Kamion: knock yourself out
<ogra> i have a edubuntu-artwork change not completely ready yet i'd like to have in
<Kamion> ogra: no harm starting early
<ogra> i know
<blue-frog> ogra do gcompris throw you back to login screen in edubuntu as it does for me in ubuntu?
<ogra> blue-frog, didnt happen to me, nope 
<Kamion> I don't know exactly, but I have lots of stuff I need to verify
<ogra> do you talk about dapper ? 
<blue-frog> ogra yes
<ogra> and the recent gcompris ? 
<blue-frog> 7.2-1ubuntu1
<ogra> yes
<blue-frog> from synpatic 1 hour ago
<ogra> nope, runs fine as we speak
<ogra> just tried it
<Nafallo> *grumble* darkelf just died again. she will have to do memorytest while I sleep :-P
<ogra> at least on amd64 and ppc, i have no i386 handy currently
<blue-frog> ogra am at a loss on how to try to trace that as it kills my session (i386 for me)
<Kamion> ogra: you want xchat-gnome for edubuntu?
<ogra> not really, but i guess we dont want to keep xchat in main
<Kamion> I don't see why not, seb128 seems to have been recommending xchat to people who don't like the UI changes in xchat-gnome
<Kamion> I'll leave it at xchat for now
<ogra> hmm, but duplicating apps is not our usual way of handling such stuff 
<Kamion> true
<Kamion> and no rss-glx, xscreensaver-gl, xscreensaver-data?
<ogra> not for edubuntu, nope
<ogra> it wont use any hacks
<ogra> to evil for ltsp ...
<Kamion> Riddell: ah, the other reason you were getting that error was that the kubuntu seeds hadn't been merged for so long
<Kamion> so no user-setup
<Riddell> Kamion: right, have you done that now or should I?
<Kamion> I have, but please try to do it reasonably frequently in future
<Riddell> yes, will do
<Kamion> I usually try to do a merge everywhere when I'm committing a seed change that's necessary for everything to keep on working, but sometimes I forget
<Mithrandir> Riddell: that should fix your live cd problem as well, I'd imagine.
<Kamion> I'll do *-meta rebuilds in a bit
<Kamion> we'll need those before rebuilding the live fses
<\sh> pitti: can you check the buildlogs of {hoary,breezy}-security?
<ogra_ibook> seb128, btw, the new gconf is impressing from a derivative distro POV 
<ogra_ibook> it even respects symlinks in /usr/share/gconf/defaults :)
<Kamion> er, do we want gnome-screensaver in main now?
<Kamion> mdz: ^--
<ogra_ibook> Kamion, he already asked for flight2 
<Keybuk> seb128: do you know off-hand why gdm is ignoring my "REBOOT YOU FUCKER" command?
<Keybuk> it's saying "OK" and grinning at me
<sivang> Keybuk: this happens to me occasionaly
<ogra_ibook> sivang, i hope you filed bugs :)
<sivang> ogra_ibook: Hrm, that was one too many time that I felt I Had done something wrong, but I'm waiting for this to happen again to me and then I will file one :)
<sivang> ogra_ibook: what sort of info can I provide on such a bug? (where to look, etc)
<ogra_ibook> you can switch on the gdm logging in the config
<ogra_ibook> annd attach the log
<sivang> ogra_ibook: ok, thanks. will do.
* sivang reruns libnotify's tests
<Keybuk> oh, interesting
<Keybuk> it looks like it has actually set the method, just not done anything about it
<Keybuk> *ponders*
<segfault> who's in charge of the new logout dialog?
<mdke> infinity, nudge #3
<HiddenWolf> segfault: lllmanulll in -desktop
<mdke> segfault, desktop team
<segfault> k
<seb128> Keybuk: nop, it works fine for me and we have to bug about it. Does "shutdown -r now" works fine?
<pitti> Kamion: can I mess with the seeds again?
<Keybuk> seb128: figured it out
<Keybuk> seb128: there's code in gdm to explicitly prevent shutdown/reboot/etc. if there's an X session open
<seb128> nice
<pitti> Keybuk: nevermind, I don't need to
<pitti> Kamion: ^
<pitti> Keybuk: (sorry, ETABFINGER)
<Keybuk> seb128: so where's the bug do we think, gdm-signal or gdm?
<Keybuk> bug = gdm-signal --halt does nothing
<sivang> does anybody know if daniels is back?
<seb128> Keybuk: gdm doesn't use gdm-signal
<seb128> Keybuk: gnome-session uses the gdmflexiserver to give the order to gdm and the action is done when you return to the gdm screen (ie: when the session is closed)
<Keybuk> right
<Keybuk> that's not what I'm talking about
<Keybuk> I want to be able to reboot the machine now
<HiddenWolf> sivang: he was here last night.
<seb128> from GNOME or from the login screen?
<Keybuk> from inside GNOME
<seb128> you can't
<seb128> that's a feature :)
<Keybuk> I can see a line of code that'll let me do just that <g>
<seb128> you have to close your session
<Keybuk> there's an ungodly hack going in SOMEWHERE
<ogra_ibook> hmm, but gdm-signal --hibernate apparently works
<seb128> hibernate/sleep doesn't require to close a session
<seb128> reboot/halt do
<ogra_ibook> yup
<Keybuk> ogra_ibook: that doesn't shutdown though, --halt doesn't work
<Keybuk> seb128: does gnome-session provide any way to close the session from an app?
<seb128> --halt wait for you to go back to the gdm login
<seb128> good question, hum
<Keybuk> calling gnome_client_request_save results in the logout dialog popping up
<Keybuk> I want to bypass that
<Keybuk> ooh
<Keybuk> yay
<Keybuk> if I put INTERACT_NONE it doesn't
<Keybuk> hurrah
<Keybuk> solved, send SET_LOGOUT_ACTION REBOOT to gdm, then tell the session to save with no interaction
<segfault> ia ficar melhor, neh?
<segfault> ops, EWRONGWINDOW.
<seb128_> hum
<seb128_> I broke my session :p
<seb128_> if somebody said something for me since 2-3 min say it again
<seb128_> Keybuk: why do you need to reboot without closing your session?
<Keybuk> seb128_: I don't, I just need the machine to reboot
<Mithrandir> 18:17 < Keybuk> calling gnome_client_request_save results in the logout dialog popping up
<Mithrandir> 18:17 < Keybuk> I want to bypass that
<seb128_> thanks
<Keybuk> I solved it though
<seb128_> Keybuk: why not using the session dialog?
<Keybuk> because the user just clicked a "Restart Now" button, and it'd be a bit unsporting to ask them again ;)
<Keybuk> http://people.ubuntu.com/~scott/restart-dialog.png
<Keybuk> (which is what you get after clicking on:
<Keybuk> http://people.ubuntu.com/~scott/restart-req.png
<seb128_> maybe vuntz know :)
<Keybuk> I worked it out
<Keybuk> send SET_LOGOUT_ACTION REBOOT to gdm
<seb128_> there is gnome-session-save --kill too 
<Keybuk> then call gnome_client_request_save on gnome_master_client with the INTERACT_NONE option
<seb128_> right
<Keybuk> hmm
<Keybuk> Monospace is dancing around my screen now, something must have changed in that reboot :-/
<mjg59> Keybuk: It shouldn't say "Cancel"
<mjg59> It should be "Don't reboot" "reboot"
<Keybuk> I know, but I can't seem to change that one
<Keybuk> my glade-fu is not good
<mjg59> Ha
<Keybuk> I wanted "Reboot Now" and "Later"
<mjg59> Have you just inserted a stock cancel icon?
<Keybuk> uh, I just copied the glade file from another program and tweaked it a bit O:-)
<mjg59> Right...
<ogra_ibook> ugh
<mjg59> Better get someone to fix that, then :)
<Keybuk> so if I turn off stock button
<Keybuk> and set the label and icon myself ...
<Keybuk> hmm
<ogra_ibook> that will work fine ... but i'd use something like gazpacho 
<Keybuk> should they have icons?
<Keybuk> both have icons? just one have icon?
<ogra_ibook> follow the gnome setting ? 
<Keybuk> there isn't a gnome setting for dialog boxes
<seb128> Keybuk: use an icon for both
<mjg59> I don't like the fact that the new logout menu seems to present "sleep" unconditionally
<seb128> hum
<mjg59> The tooltip is also wrong
<ogra_ibook> Keybuk, there is a gnome setting for toolbar buttons
<Keybuk> there's a tooltip? :p
<seb128> mjg59: yeah, that's a bug somewhere
<mjg59> ogra_ibook: dialog buttons are not toolbar buttons
<ogra_ibook> mjg59, i know
<mjg59> seb128: Can we have the window preferences back?
<ogra_ibook> 7me would trade the window preferences for windows that dont get stuck on the desktop edge
<seb128> mjg59: no
<mjg59> seb128: It's just there doesn't actually seem to be any way to get at it now
<Keybuk> ogra_ibook: don't hold down the shift key
<seb128> mjg59: it's MenusRevisited spec, people who wants to change their focus can also start an app or unmask a menu entry
<Keybuk> mjg59: gnome-window-properties
<mjg59> Keybuk: Yes, right, I can do it from the command line
<Keybuk> mjg59: you can also turn it on from the menu editor
<seb128> or from alt-f2
<seb128> or use the menu editor
<ogra_ibook> Keybuk, the shift key doesnt change anything 
<ogra_ibook> Keybuk, in fact no key does change it it seems
<Keybuk> oh that's good, the menu editor crashed gnome-panel
<Keybuk> and it's now respawning in a loop
<mjg59> I entirely understand the reasoning behind removing some of the applications
<Keybuk> ogra_ibook: my windows don't stick at the edge
<Keybuk> oh, they do
<Keybuk> neat
<ogra_ibook> with recent metacity ? 
<ogra_ibook> ah
<ogra_ibook> its quite annoying on 12"
<Keybuk> aha!  they've turned on gravity in general
<ogra_ibook> since i tend to move windows half off the screen
<seb128> Keybuk: yeah, gnome-vfs/inotify bug fixed with the cvs
<infinity> Yeah, I like the gravity.
<mjg59> But making it hard to enable sloppy focus is going to crucify us amongst the "power users"
<seb128> mjg59: the starter guide should document that
<mjg59> seb128: These are the people who aren't going to read docs
<seb128> mjg59: you can argue than power user want gconf-editor and .. and ... everything we have hidden by default
<mjg59> (Yes, it's entirely their own fault, but they're *still* the people that are going to blog about it and scream and whinge)
<infinity> mjg59: Aren't "power users" going to end up finding gconf-editor and tweaking everything through there, cause it's, like, the new regedit?
<Keybuk> this is up there with removing the "Enter" button from the gdm theme
<Keybuk> the number of users I've seen sitting there after typing their name going "now what?"
<seb128> Keybuk: that's a point of dapper-desktop-change I think, and there is a bug about that
<mjg59> infinity: I think there's a difference here. I'm thinking of people who are actually in the useful development community, rather than the ricer crowd
<seb128> (putting an "enter" button)
<seb128> mjg59: is there many people changing their focus mode? I use the stock one by example
<mjg59> seb128: I find click to focus irritating, since there's no way to decouple it from "raise window"
* Keybuk changes pretty much every preference in that window
<Keybuk> focus -> sloppy
<Keybuk> no interval
<Keybuk> double-click to roll-up
<Keybuk> and move with super
<seb128> I tend to switch between apps with alt-tab
<Keybuk> in fact, yes, I do change every preference ;)
<infinity> mjg59: There's a "raise_on_click" option you can turn off.
<seb128> and have quite a bunch of stuff maximized anyway
<ogra_ibook> Keybuk, heh, i have the same setup :)
* Kinnison definitely uses sloppy
<Kinnison> and would get really pissed off if it wasn't easy to switch to sloppy
<infinity> mjg59: Of course, that goes back to previous arguments, since you need gconf-editor to find it.
<Keybuk> seb128: yes, but this is about what our users change, not what you change :)
<mjg59> infinity: Fuck me. That's relatively new.
<ogra_ibook> Kinnison, it isnt anymore
<Kinnison> I have to switch my dad's desktop to sloppy when I'm helping him out, and back when I'm done -- to have to use gconf-editor would be really annoying
<ogra_ibook> Kinnison, unless you know the way
<seb128> Keybuk: I think that most users are fine with the default setting
<Keybuk> I think most of our newbie users are
<Keybuk> and I think most of our elite users aren't
<seb128> Keybuk: if that's not the case we should fix the default settings rather than forcing them to use the dialog
<mjg59> seb128: Most users probably are, but this comes back to what jdub keeps pointing out
<infinity> mjg59: It appears that with it off, it raises when you click the titlebar, but will not raise when you click anywhere else (no matter how many times)
<Keybuk> pissing off the elite users will lose us the newbie ones
<seb128> mjg59: that's jdub who suggested to hide the focus configuration btw :p
<mjg59> We can't /just/ appeal to new users. We need to be able to appeal to the people who write about us.
<seb128> right
<mjg59> seb128: Well, in this case he's going against his general statements :)
<seb128> so we shoudl have "complexify the menus" rather than "simplify the menus"
<Kinnison> Who chose to remove the focus type from that dialog?
<mjg59> infinity: Yeah, that does exactly what I want
<Keybuk> seb128: I agree that we need to simplify the menus
<mjg59> Kinnison: The entire dialog is gone from the default menu
<HiddenWolf> Wasn't there some discussion about providing user profiles?
<Keybuk> but I think there was a lot lower hanging fruit than the Windows dialog
<Kinnison> mjg59: You what?!
<Keybuk> all the obscenely complicated ones, for a start
<Keybuk> and, for example
<Keybuk> why is Windows gone, but not Menus & Toolbars?
<mjg59> seb128: No - the idea is that we shouldn't be /less/ appealing to these users than competing Gnome desktops
<Keybuk> (which STILL has the wrong defaults)
<Keybuk> why is Sessions there?
<Keybuk> why is Preferred Applications there?
<Keybuk> etc.
<mjg59> Keybuk: How about we argue about this in London?
<infinity> With bats.
<seb128> Keybuk: preferred app is quite useful for newbies too
<Keybuk> ooh, yah, bats
<Keybuk> and jello!
<Keybuk> seb128: no it's not, because they have only got the application selection we give them
<seb128> session is the only way to save a session now
<Kinnison> multimedia systems selector
<Keybuk> seb128: newbies don't know how to save a session
<Kinnison> is that one still there?
<Keybuk> Kinnison: that went
<mjg59> seb128: That's a bug, not a feature
<seb128> let's drop the menus :)
<Keybuk> seb128: newbies don't know what a session is!
<Keybuk> actually, I'd rather like us to go to a windowed preferences
<Keybuk> with an advanced/power user tab
<Keybuk> tab/button/toggly
<hunger_> Keybuk: Even newbies can learn, you know?
<mjg59> "We've removed this clicky box, so now we have to keep this horrible preferences application because it's got a button that does the same thing as the clicky box we removed"
<Keybuk> hunger_: I'm using seb's argument against him :)
<mjg59> To me that suggests that removing the clicky box was the wrong thing to do, not that keeping the preferences application is the right one
<Kinnison> We're going to be back to the configurability/usability of GNOME 2.0 if we're not careful
<hunger_> Keybuk: Oh, sorry, just returned to the keyboard, I think I missed the context.
<seb128> why do people come 3 months after discussions/changes to complain instead of starting to discuss changes at the right time? :)
<Keybuk> seb128: because it takes 3 months for people's desktops to work well enough to notice them? :)
<seb128> ah ah
<mjg59> seb128: Because I've only recently noticed that it was missing, since I generally don't have any need to change it
<\sh> seb128: it's .... human :)
<Keybuk> and we tend to be "not invited" to the discussions
<seb128> Keybuk: I've mailed devel-announce about that, what kind of invitation do you need? :)
<siretart> elmo: please sync wmfire_1.2.3-1/unstable, ok to override ubuntu changes
<Keybuk> seb128: after the spec was already written and approved
<Keybuk> with the spec drafted in a closed room with just you, sabdfl and jdub wasn't it? :p
<seb128> right, but the spec is clear we will do changes according to user feedback
<seb128> and that's why we did the changes early
<seb128> and put totem back to the menu by example :)
<Keybuk> users said "We don't want the Window Preferences dialog" ?
<seb128> no, that one was in the big room with like 10 people at the table in fact
<seb128> dapper-desktop-plan was the closed room one :)
<hunger> pitti: Could you please remove the pid-file of cups after killing the daemon?
<seb128> anyway we have plenty of time to tweak the menus still
<Keybuk> ooh, the little arrows on the menus are iiiickle
<Keybuk> like 2px by 3px
<Keybuk> what went wrong there?
<hunger> pitti: Feels untidy to leave that after the daemon is gone.
<ogra_ibook> Keybuk, but they are antialiased :)
<pitti> hunger: right, thanks
<Keybuk> ogra_ibook: i can't tell ... doesn't look like it
<hunger> pitti: Thanks for not minding me pestering you with my petty little requests (or at least not complaining too much about them;-)
<siretart> elmo: please sync xmms-jack_0.15-1/unstable, ok to override ubuntu changes
<Keybuk> seb128: it does strike me that we've reached the wrong conclusion to a bug
<Keybuk> "The Preferences menu is too cluttered" -> "Remove things"
<Keybuk> rather than "Find something better than a menu"
<seb128> there is some plan of "find something better than a menu", that's just it's not for dapper
<Keybuk> right, but breaking things now to fix them later isn't great, eh?
<Keybuk> "we plan to move to Xgl for dapper+1, so we removed X.org from dapper"
<seb128> we are not trying to break things
<seb128> the purpose of the spec was mainly to solve the confusing duplications of preferences categories between app and system
<Keybuk> it doesn't seem to have done that though
<seb128> it has
<seb128> you don't have that category to app on a stock install
<Keybuk> Windows was as relevant as Menus & Toolbars
<Keybuk> one has gone, one has remained
<seb128> we did some cleanup too which might be wrong
<seb128> and we said we will adapt according to user comments :)
<Keybuk> and Menus & Toolbars STILL HAS THE WRONG DEFAULTS <g>
<Burgwork> Keybuk, raise this on -devel and lets get some other feedback
<Keybuk> (did I mention that already?)
<seb128> detachable menus?
<Burgwork> seb128, I want xsane to return
<Keybuk> seb128: detachable menus and toolbars should both be OFF
<seb128> Burgwork: and a pony? :p
<Burgwork> seb128, nah
<seb128> Keybuk: menus one is fixed upstream, I've commited the change to CVS 2 days ago
<seb128> ups, toolbars I mean
<seb128> menu is off by default
<Keybuk> cool
<infinity> pitti: BTW, s/--user root/--user cupsys/ in your init script (in the stop target) would go a long way to making it actually WORK. :)
<pitti> infinity: heh, I'm just cleaning up that bit anyway
<Keybuk> seb128: anyway, finished flaming for a bit now :)
<Keybuk> gnome-session loves me again
<pitti> infinity: good morning :)
<Keybuk> so I feel less hate
<Keybuk> pitti: how did I break cupsys? :p
<infinity> pitti: When the user, name, and PID actually match, the next bit you do is pointless, since "--retry TERM/10" expands to "--retry TERM/10/KILL/10"
<pitti> infinity: btw, what would you propose for enigmail? drop the mozilla package, or split the source?
<pitti> Keybuk: nevermind, just the lost /var/run/cups/ issue
<seb128> Keybuk, mjg59: thanks for the rant on on the focus capplets, for what is worth I think we should enable it by default too, I'll ping jdub before doing the change back though
<Keybuk> pitti: ah, I thought that one had a mkdir
<infinity> pitti: We can duplicate the source.  It's tiny, and it's a pretty useful thing that mozilla users would cry without.
<pitti> infinity: seb128 uploaded librsvg2 against ffox today, so enigmail is the last bit that keeps moz in main
* mjg59 mails -devel
<mjg59> pitti: Got a second?
<pitti> mjg59: yes
<seb128> mjg59: if that's for a desktop issue you may want to Cc ubuntu-desktop too 
<mjg59> seb128: Heh. Sorry, should have done that. Never mind.
<infinity> pitti: Remind me after I wake up (I haven't yet slept.  I know, I know...), perhaps via an email sent in 5 minutes which I'll read in a few hours, and I'll merge and split enigmail.
<seb128> np
<mjg59> pitti: I've been talking to davidz about hal privileged operations
<pitti> infinity: oh, then better go to bed :) I'll mail you
<pitti> mjg59: oh, interesting :)
<infinity> pitti: But seriously.  The init script.  Remove all that "wait 5 seconds, try to kill" business.  It's evil.  SSD does the right thing, if you feed it the right info. :)
<mjg59> pitti: Basically, his opinion is that we should have a small daemon that runs as root and sits on dbus. It should only accept requests from hal. The only thing it should accept is a command name. It should validate this (check it's under /usr/lib/hal/scripts, or something) and then execute it as root. It should then pass back stdout, stderr and the return value in a sensible way.
<pitti> infinity: yes, that's what I'm doing
<pitti> mjg59: he plans this for a fair while now; will that be implemented soonish?
<pitti> mjg59: this approach indeed sounds fine to me; just not the current one which does everything in the main hald
<mjg59> pitti: He's hoping that we'll do it, since he's busy with RH stuff and they don't need it
<pitti> mjg59: hmm, *I* don't need it either :)
<mjg59> pitti: *We* need it in order to satisfy at least one spec
<pitti> mjg59: from my POV implementing privileged active elements as separate dbus services would be more sane
<mjg59> pitti: Why?
<pitti> mjg59: power management?
<mjg59> Yeah, power management
<mjg59> We're blocking on this right now
<sivang> mjg59: so this deamon would only take care of sending power mgmt commands?
<pitti> mjg59: well, having a very small daemon that does one thing, has a narrow input and can be audited is always better than a huge daemon that does the world
<mjg59> Basically, hal_util_helper_invoke_with_pipes needs to be broken out to another application that sits on dbus and runs as root
<mjg59> pitti: The only thing this root-running daemon would do is execute commands if they're in the right location
<pitti> mjg59: I see; it's a bit like a suid root program in the dbus architecture?
<mjg59> We're talking about 40 lines of code plus some dbus glue, or so
<mjg59> pitti: Yeah
<pitti> security wise this sounds sensible to me; I was just totally opposed to running the complete hald as root
<mjg59> The only security issue is that getting control of it would allow you to run these scripts as root
<mjg59> Which is the same as getting control of any of the individual daemons would be
<pitti> right
<mjg59> It's probably a couple of hours of work, but I just don't have time to do it righ tnow
<mjg59> (And I don't trust my dbus programming sufficiently)
<pitti> but since these programs hopefully have a limited set of inputs, it wouldn't be total control, right?
<pitti> mjg59: we can't avoid that anyway if we specifically want users to control power management and such
<mjg59> pitti: Right. Worst that can happen is that you can suspend the machine and so on.
<pitti> mjg59: that's why I actually like the networkmanager approach with this dhcdbd; it's a separate dbus service and can be installed independently
<mjg59> pitti: Yeah. I think the proposed hal approach is basically identical in terms of security implications.
<pitti> yes, just different in terms of granularity (packaging-wise)
<mjg59> Yes
<carlos> pitti, hi, do you have some time to talk?
<pitti> carlos: yes, just go ahead :)
<mjg59> pitti: So, can I convince you to code this? :)
<pitti> mjg59: would require me to dig into the guts of dbus/hal as well; it's interesting in any case and has the potential to reunify our and upstream's approaches
<pitti> mjg59: if mdz is fine with me spending time on this, I'll do it
<mjg59> pitti: Ok, cool. 
<mjg59> mdz: ^
<mdz> mjg59: didn't you tell me a while ago that you were going to do this?
<mjg59> mdz: That was the plan, but I'm swamped by real life
<mjg59> I've got half a thesis to write by the end of the week
<mjg59> It's the one thing blocking the power management spec
<mdz> pitti is fairly booked as well; perhaps we could discuss this after the dev meeting?
<mjg59> If you're happy leaving it that long, sure
<mdz> the dev meeting is in about 14 hours
<mjg59> Oh, right
<mdz> i'm in the middle of another meeting right now
<mjg59> Sorry, I managed to confuse it with the distro sprint
<mjg59> Yes, no problem
<lllmanulll> Hey, I'd like to file a bug about dapper not starting on my machine (while booting, freezes on "detecting and activating hardware") : which package should I file it against ?
<Keybuk> "freezes" ?
<Keybuk> or just takes a very long time?
<pitti> hunger, infinity: new cupsd uploaded
<Keybuk> if you wait, say, 3 minutes, does it carry on?
<lllmanulll> Keybuk, loops :)
<Keybuk> "loops" was not an answer
<lllmanulll> Keybuk, "azx_get_response timeout", displaying ad lib on the screen
<Keybuk> ok
<Keybuk> file it against "linux"
<lllmanulll> the motherboard is quite recent
<mjg59> That's the sound driver
<crimsun> I'll take it from here.
<siretart> daniels: is it possible to specify dependencies for libgl/libglu headers in debian/control so that they are satisfiable in both unstable and dapper? I'd like to avoid divergence in my packages
<crimsun> lllmanulll: please see http://lists.ubuntu.com/archives/ubuntu-users/2006-January/063381.html
<siretart> daniels: I'm talking about build deps
<infinity> siretart: libglu1-mesa-dev should work on both distributions.  For GL, you'd need "xlibmesa-gl-dev | libgl1-mesa-dev | libgl-dev" (in that order, since Debian's sbuild will only try the first option, ours will try the first AVAILABLE option.. Neat difference)
<infinity> siretart: In theory, it won't be long before Debian's mesa stuff is in sync with our, though.  In theory.
* mvo is aways for a bit, bbl
<siretart> infinity: do you happen to have in mind what would be correct for glu headers?
<siretart> libglu1-xorg-dev | libglu1-mesa-dev | libglu-dev?
<infinity> siretart: libglu1-mesa-dev exists on both distributions.
<infinity> siretart: But you can prefer the xorg version on Debian if you want.  <shrug>
<siretart> ah, so 
<siretart>  libglu1-mesa-dev | libglu-dev should be just fine
<siretart> thank you so much!
* infinity tries heading back to bed again, after having done his good deed for the... uhh... early morning.
* Mithrandir wonders if infinity should be kicked off work channels so he can actually sleep av couple of hours once in a while.
<Keybuk> *** Unable to join #ubuntu-devel: Banned (go to bed!)
<ogra_ibook> *giggle*
<\sh> pitti: are you planning to be included in the DFN Cert advisory ML?
* lamont wants an http_proxy for apt that only affects apt-get udpate
<HrdwrBoB> set http_proxy=foo; apt-get update; unset http_proxy
<ogra_ibook> and make that a shell alias command ? 
<pitti> \sh: I didn't; should I?
<\sh> pitti: would be a nice idea to have at least some translations of our bugreports in german :) and for free I think :)
<pitti> heh
<\sh> pitti: and we show to the public, that ubuntu is doing as well security patches
<pitti> \sh: translations of bug reports?
<pitti> \sh: that seems a bit stretched
<\sh> pitti: do you know the security mailing list of DFN cert? the prologue is always a german summary of the bugreport which is the epilogue :)
<pitti> \sh: ah, so s/bug report/USN/?
<pitti> \sh: no, I don't know it
<\sh> pitti: http://www.cert.dfn.de/infoserv/mls/win-sec-ssc.html
<pitti> mdz: I'm not sure whether you got my question for the postgresql-8.0 breezy-updates patch?
<pitti> mdz: also, we should walk through the list of pending -updates uploads and process/remove them (some of them are scaringly old)
<\sh> pitti: I'd send you an example of one of those mails 
<mdz> pitti: I did, I have the tab open in firefox but haven't read it yet
<pitti> mdz: ok, thanks
<mdz> pitti: I'm not sure that we have a means to remove things from there apart from asking elmo to fix it by hand
<pitti> mdz: yes, that's what I mean
<pitti> mdz: but I think some stuff can also be approved
<mdz> pitti: I'm just saying that the reason things stay there is because it's inconvenient to remove them, but yes, we should clean it up
<pitti> mdz: e. g. xine-lib, evince, ubuntu-docs uploads look pretty reasonable
<pitti> mdz: and the ancient old evms uploads to fix RAID-5 corruption
<Mithrandir> mdz: uhm, that's not ancient.
<Mithrandir> s/mdz/pitti/
<\sh> taking a nap...cu later :)
<pitti> Mithrandir: oh, sorry; I did a similar upload months ago, seems that this is another flaw
<Mithrandir> pitti: oh, ok.
<Mithrandir> pitti: since I did an upload a week or two ago, fixing raid 5 corruption issues. :-P
<pitti> Mithrandir: yes, I just read the .changes file :)
<psusi> pitti: I swear I read somewhere that hal runs async with callouts so the callouts can do things like hal-set-property, only I have found that hal-set-property fails to connect unless I background it and sleep for a few seconds... is that supposed to work right?
<pitti> Mithrandir: btw, I assigned that live cd user breakage bug to you, was that right? (seems that you are the new Mr. Casper now)
<Mithrandir> pitti: yes, I seem to own the live cd now.
<Mithrandir> pitti: uhm, what was the bug #?  Or is it a bit of time ago?
<mdke> infinity, nudge #4
<pitti> Mithrandir: #22052
<Mithrandir> mdke: he's asleep
<Mithrandir> (hopefully)
<mdke> Mithrandir, that's ok, he can collect em
<Mithrandir> pitti: that should be fixed with the newest dailies.
<pitti> Mithrandir: great
<ogra_ibook> Kamion, gnome-screensaver is missing ed/ubuntu-meta 
<Kamion> oh, yeah, I should've promoted it first
<Kamion> meh
<Kamion> right, promoted now, will reupload ubuntu-meta/edubuntu-meta, er, later sometime
<ogra_ibook> fine with me
<blue-frog> system>preferences>sessions what package is that pls?
<dholbach> blue-frog: gnome-session
<blue-frog> ty
<dilinger> BenC: are you still maintaining pam_mkhomedir?
<daniels> siretart: libgl1-mesa-dev | xlibmesa-gl-dev | libgl-dev
<siretart> daniels: thanks. but infinity already answered with this: 19:31:17 < infinity> siretart: libglu1-mesa-dev should work on both distributions.  For GL, you'd need "xlibmesa-gl-dev | libgl1-mesa-dev | libgl-dev" (in that order, since Debian's sbuild will only try the first option, ours will try the first AVAILABLE option.. Neat difference)
<freestone> Mithrandir: Hi - got your email, but don't know where I am supposed to get the cd iso from - from the base system? Where?
<daniels> siretart: oh, righto
<siretart> btw, wasn't it a habit of sbuild always taking the last alternative in build dependencies first? do I mix it with something?
<daniels> you'd be mixing that up
<sivang> he following packages have unmet dependencies.
<sivang>   bzrtools: Depends: bzr (= 0.7+200512311044)
<sivang> E: Broken packages
<sivang> anybody idea?
<BenC> dilinger: I haven't touched that code in years
<dilinger> BenC: ok.  seems kind of dangerous nowdays
<dilinger> BenC: given that privsep makes it run as non-root, and it doesn't do any sort of randomization of the home directory name
<BenC> dilinger: it was mainly used for debian's chroot's
<BenC> it wasn't meant to be random :)
<dilinger> i just started using it for a router where / is ro, mounting homedirectories in /tmp (which is tmpfs)
<dilinger> heh, i know
<dilinger> i assume it was meant to be run as root, though
<Kamion> sivang: grab the source package and build it from source, it'll work fine; I did that this morning
<sivang> Kamion: I just tried, but I guess I'm getting some other error:
<sivang> pooh@tigershark ~/specs/home-user-backup $ bzr push sivan@mercury.linuxguru.net:/home/sivan/public_html/home-user-backup
<sivang> bzr: ERROR: Parent directory of sivan@mercury.linuxguru.net:/home/sivan/public_html/home-user-backup does not exist.
<sivang> that's is not related to the package itself..
<HiddenWolf> BenC: do you have any indication of what that FAT patent of microsoft means to us?
<ogra_ibook> sivang, try adding a second / before home
<mdke_> ah shit, friday the 13th has been chosen to switch to malone?
<sivang> not working, oh well. I'll just manually rsync the branch there
<sivang> mdke_: yep, 13:13 is the time :)
<mdke_> crazy
<sivang> kidding about the time :)
<BenC> HiddenWolf: from l-k, it means nothing (it only covers long filenames living in the same namespace as short filenames)
<BenC> IMO, it really only affects vfat, and also, it isn't actually a done deal yet
<mdz> infinity: ping
<Burgwork> HiddenWolf, patents are never reallly done deals
#ubuntu-devel 2006-01-17
<HiddenWolf> Burgwork: they are major annoyances. :)
<neuralis_> mdz: i think he's still asleep
<mdz> neuralis: he'll see it when he wakes up
<ogra_ibook> seb128, still here ? 
<seb128> ogra_ibook: yep
<seb128> why?
<ogra_ibook> would it be possible to ship gdm.conf-custom in /usr/share7doc/gdm instead of /etc/gdm ? 
<ogra_ibook> */usr/share/doc/gdm
<seb128> no
<ogra_ibook> with the current setup i have to overwrite or divert an empty file
<seb128> what is wrong about it?
<ogra_ibook> which is kind of silly and leaves me with the ompression i'd rather stay with sed'ing the theme entry in gdm.conf instead of using it
<seb128> ?
<ogra_ibook> its in the way if i want to customize gdm from another package
<ogra_ibook> i.e. edubuntu-artwork
<ogra_ibook> gdm now uses gdm.conf-custom to read the defaults, right ? 
<seb128> no
<seb128> the default is gdm.conf
<ogra_ibook> huh ? 
<seb128> -custom is user changes
<ogra_ibook> i thought that was the new introduced feture ...
<ogra_ibook> oh, then i misunderstood, so i still have to use gdm.conf to set the theme ? 
<seb128> no
<ogra_ibook> but ? 
<seb128> hum, depending who is you
<seb128> as an user no
<seb128> as a packager yep
<ogra_ibook> packager in this case ...
<seb128> the default package settings are gdm.conf
<ogra_ibook> i thought the -custom should enable easier cdd stuff 
<seb128> gdm.conf-custom is what you change with gdmsetup by example
<ogra_ibook> oki
<ogra_ibook> i just saw an announcement a while ago ...
<ogra_ibook> seems i misunderstood it ...
<seb128> it said he would make easier package management
<seb128> because gdm.conf is the package version stock
<ogra_ibook> ahuman01, k :)
<seb128> gdmsetup doesn't modify it
<seb128> it used ot
<seb128> to
* ogra_ibook GRRRs loud at his tabkey
<seb128> so the conffile change whenever you run gdmsetup
<seb128> with the new system your user config are to -custom
<seb128> so you have no conffile on gdm.conf change due to local setting
<seb128> so it doesn't break when a binary location changed by example and you choosed to keep your version
<ogra_ibook> hmm, we should add something between these two files (dapper+1) for derivative customization
<seb128> could be a good idea
<ogra_ibook> it always feels bad to sed through gdm.conf
<seb128> you could ship a -custom too
<ogra_ibook> yes, but i'd have to divert yours from the gdm package ...
<ogra_ibook> i dont gain much with it ... 
<dholbach> good night developers!
<seb128> right
<seb128> 'nigh dholbach
<ogra_ibook> optimal would be to just drop my file in a dir 
<ogra_ibook> like the new gconf does
<seb128> agreed
<ogra_ibook> lets not forget about it for dapper+1 ;)
<ogra_ibook> i'll stay with sed for now
<seb128> yep
<robertj> is php5-mcrypt omitted from debian for some legal issue or another?
<sladen> mjg59: did bluez-firmware disappear?
<Riddell> mdz: could you promote libavahi-qt3-dev to main?  new kdelibs just uploaded will need it
<sladen> mjg59: or even bluez-bcm203x
<netdur> p.u.o is broken... I noticed it few days ago!!!
<rob1> is there a i686 gcc package for ubuntu?
<mdz> Riddell: done; in the future, please check first if any additional dependencies need to be promoted at the same time
<infinity> elmo: How often does autosync run?... I'm waiting on mysql-dfsg-5.0 from sid to re-sync...
<desrt> hey.. what's the word on the repositories being messed up?
<ritvik> mdke_, 
<ritvik> sorry 
<ritvik> ping mdz 
<mdz> ritvik: hi, looks like we were disconnected again.  I was just calling back to wrap up and say goodbye
<ritvik> yeah .. its good 
<ritvik> thanks for calling . i'll wait for your reply then
<lifeless> desrt: ?
<mdz> ritvik: ok, cheers
<desrt> lifeless; a few people have been asking me why 'apt-get update' is broken
<ritvik> bye
<lifeless> desrt: oh, that repo ;)
<desrt> heh.
<poimen> someone kwos how to enable multiverse in dapper?
<Burgundavia> poimen, please use #ubuntu as this is not a support channel
<DrZeus> Hi all.  I would like to ask if there is a way to check that a patch is integrated in the next release
<DrZeus> because I had a problem with the acpi of my laptop, and found some kernel patches for fixing that(battery not detected), and I want to know if they are or could be included in the next release
<womble> DrZeus: Check the changelog for mention of the patch?
<DrZeus> dont know how to do that
<DrZeus> this is the link where I found the patches.  Is a member of the linux on toshiba mailing list
<DrZeus> http://www.minet.uni-jena.de/~ferdy/l10.html#sbs
<DrZeus> how do I check that log?
<DrZeus> how can I check that the patch is included?
<womble> DrZeus: See http://packages.ubuntu.com/<packagename>, select the distribution you want to look at, and down the bottom there's a 'changelog' link.  That'll take you to the changelog for the package.  For the kernel, you probably want linux-image-2.6.15-11-386 for the package name.
<DrZeus>  womble: it tells to view the "debian changelog".  Is that the one I have to see?
<womble> DrZeus: Yep
<DrZeus> ok
<DrZeus> it is not found in the page
<infinity> The acpi-sbs stuff isn't included in our kernel, no.  And according to that page, it doesn't apply / won't work on kernels > 2.6.13 (and we're using 2.6.15 right now)
<DrZeus> its curious; why is not included, or listed in any sort of "official" patches repository, i dont know
<DrZeus> the page doesnt says it wont work, it keeps the benefit of the doubt; but thats not enough for a release, I understand
<infinity> Of course, if an updated DSTS is what's really needed for stuff to be a bit happier, you can follow their DSTS instrustions, toss the result in /etc/mkinitramfs/DSDT.aml, "update-initramfs -u" and reboot.
<infinity> I suspect the kernel patches may be required, though, and if you find that's the case, please file an enhancement bug on the "linux" package.
<mjg59> There's already a bug on it
<infinity> Then never mind. :)
<zakame> hi devs
<LaserJock> hi zakame 
* ..[topic/#ubuntu-devel:infinity] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 2 released | If your initramfs is broken in any way, please save a copy for infinity
<ajmitch> sigh
<ajmitch> mine was broken, but works now
<ajmitch> such a shame
<infinity> Yeah.  If anything breaks again, please save me a copy.  It's easy to dig through a broken one and see why it broke, next to impossible to resolve after the fact with anecdotal reports like "well, it didn't boot.  I regenerated the initramfs.  Now it boots."
<infinity> :/
<Keybuk> infinity: did you see that Malone bug, btw?
<Mez> god damn - this whols **** about the conflicts between debian and ubuntu ****es me off
<infinity> Keybuk: #?
<Keybuk> infinity: 6696
<infinity> Keybuk: The only recent Malone bug I've had assigned to me was something nvidiaish.
<Keybuk> yeah I'm not sure if I can even assign bugs to you
<infinity> Don't see why not..
<Keybuk> I can't find anything like "Assign Bug" in Malone
<Mithrandir> in the bug overview, click on the bug in the "fix requested in" column.  There you can reassign.
<Mithrandir> it's a really unfortunate UI, very non-discoverable.
<infinity> Yeah, you described it, and I still can't find it.
<infinity> Keybuk: Well, "/dev/.initramfs" is new, I suppose, but not the idea of using /dev to save state over the remount.
<Keybuk> right
<infinity> Keybuk: Anyhow, I can just test that I have the file before I play with it.  No big deal.
<Keybuk> but after init-bottom there is no /dev
<infinity> It's all just a hack until usplash grows internal state anyway.
<infinity> Of course, log_end_msg will fail (well, "not work", rather) either way in that case, since it can't send anything to the usplash fifo either.
<Keybuk> right
<infinity> OTOH, initramfs does still create /dev, so it may make sense for us to be the ones that move it too.
<infinity> Hrm, no, I see why that would suck, if there was no udev.
<Keybuk> maybe, though it prevents the udev script from being able to bail out
<infinity> Then we'd be moving a (nearly empty) /dev to the root.
<mdke_> infinity, hi, the usual nudge
<infinity> :)
* infinity is nudged.
* Keybuk tries to remember how to spell "BLOCKED ON INFINITY" in his bingo card
<mjg59> Oh, dev meeting, hnngh.
<dholbach> good morning
<ajmitch> morning dholbach 
<dholbach> ajmitch: hey andrew
<pitti> hi dholbach 
<dholbach> pitti: hey martin
<mdke_> infinity, you have a T43 right? does it boot with the -11 kernel? mine stops at "detecting and activating hardware"
<infinity> mdke_: Mine boots fine.  I have other problems (lack of frequency scaling), but it more or less works.
<mdke_> infinity, ok maybe slightly different hardware, or mine just being a pain then
<ogra_ibook> infinity, is there a chance that we see my noblock patch in initramfs before flight3 ?
<Kamion> T-5mins to distro team meeting
<infinity> ogra_ibook: There's a chance if you pester me about it right after the meeting.
<ogra_ibook> infinity, i'd be fine fixing it and preparing it for you if you tell me what you want :)
<Keybuk> mdke_: stops, or pauses for 3 minutes?
<mdke_> Keybuk, i'm not sure I ever left it for 3 minutes. will try that today
<infinity> mdke_: You can boot into an older kernel just fine, right?
<mdke_> yes
<mdke_> i have -9
<infinity> mdke_: If so, can you copy your initrd-2.6.15-11-686 (or whatever) somewhere, so I can have a look at it and see if it's broken?
<mdz> dev meeting in 2 minutes
<infinity> mdke_: I'm trying desperately to find broken initramfs's. :)
<Mez> ooh :D dev meeting :D
<mdke_> infinity, alright
* Mez sits and waitches
<mdke> Keybuk, if it is pausing, shall I cc you to the bug?
<pitti> mdz: postgresql-8.0 breezy-updates uploaded and ready for your electronic thumb :)
<Keybuk> mdke: yeah, though either way it's a kernel bug
<mdke> right
<khermans> can someone tell me how to compile a static binary with all the dependencies inclusive?  I would be doing this with ./configure
<pitti> ogra, ogra_ibook: ping
<Keybuk> khermans: --enable-static ?
<ogra_ibook> pitti, pong
<khermans> Keybuk, yeah i tried but no luck
<khermans> Keybuk, ther eis also enable-shared
<pitti> ogra_ibook: ok, I didn't see your ack in #u-meeting :)
<Keybuk> khermans: --disable-shared --enable-static ?
<Keybuk> something like that
<pitti> seb128, Diziet: is there a bug report about the epy issue somewhere?
<pitti> seb128: running commands in downloaded .desktop files
<pitti> ogra_ibook: but autostart on CDs is (a) deactivated by default and (b) much less dangerous than automatically executing downloaded .desktop files
<ogra_ibook> yes, i only happen to remember the discussion came up with it 
<ogra_ibook> i dont say they are related :)
<seb128> pitti: ?
<seb128> pitti: there is nothing epiphany specific, .desktop are app launchers for GNOME
<seb128> ie: GNOME display the icon/name defined by the .desktop and run the command specified by it
<ogra_ibook> but we probably should restrict their execution from a browser
<pitti> yes, the browser should not automatically execute these
<seb128> nothing specific with a browser
<seb128> you download them and double click from nautilus that's the same
<pitti> I'll take a look at this after the meeting
<pitti> seb128: it sounded as if clicking onto a .desktop link in the browser would already execute it
<ogra_ibook> yes, to me too
<seb128> what are you talking about
<seb128> ?
<seb128> is that a list discussion I didn't read?
<seb128> what sounded like that?
<pitti> seb128: you did :)
<ogra_ibook> seb128, iwj sounded like it would be executable directly
<seb128> anyway, is there a difference with "open directly" and "download and have to double click on it"?
<ogra_ibook> yes
<pitti> yes
<pitti> since you can trick users to automatically be redirected to a .desktop file
<seb128> anyway you can trick and user
<pitti> if merely visiting http://foo/bar.desktop will execute the file, that's scary
<seb128> read the mail I pointed on -meeting
<seb128> the icon looks like a .doc
<seb128> the name looks like a document
<seb128> and it does a tricky command
<seb128> so do use the browser option to automatically open attachements you click on
<seb128> my browser is configured to open the download dialog
<pitti> seb128: if it spawns the download dialog, that's fine
<seb128> that's an user option
<seb128> if you remove the option some people will scream at you :p
<seb128> s/scream/yell rather :)
<Kamion> seb128: that should be controlled by the executable bit
<Kamion> if the .desktop file isn't executable, double-clicking it shouldn't execute it
<Kamion> (imho)
<seb128> a .desktop is not executable
<Kamion> maybe it should be
<seb128> a .desktop is a launcher
<Kamion> it is having the effect of interpreting it and executing it
<seb128> you don't want a confirmation when clicking on a launcher from your panel by example
<Kamion> I don't care what you call it
<Burgundavia> part of this is also that Nautilus has a crap UI for .desktop files. It hides the extension by default
<pitti> hm, executable bit could do the trick, yes
<pitti> so we would ship our deskto files in .debs executable, and the browser would save them as non-exec
<seb128> pitti: .desktop are -x
<ogra_ibook> but the command inside will still be executed, even with -x
<pitti> yes, I know, that's the problem :)
<seb128> I agree that's an issue
<seb128> but that's a GNOME issue, not an epy one
<pitti> at least it's not half as scary as I initially thought 
<pitti> so it's just about trojans, not automatically executing stuff with a malicious URL
<mjg59> ogra_ibook: ?
<ogra_ibook> mjg59, i did a patch for hoarys hal to be able to execute dmidecode to get the bios information 
<pitti> well, that used a suid root helper
<ogra_ibook> should be similar to what you want
<mjg59> ogra_ibook: Oh, in terms of running code as root?
<ogra_ibook> yup
<mjg59> Basically, but upstream wants it on dbus
<pitti> it should get a bit different design
<ogra_ibook> mjg59, ah, ok, mine didnt involve dbus
<pitti> mjg59: AIUI hald should fork right at the start, and the main process drops privs, and the other stays root and only accepts dbus messages from the main hald and executes stuff
<mjg59> pitti: That would work, or the alternative is to have an entirely separate piece of code to do that (possibly less to go wrong)
<mjg59> mvo: Any idea why g-p-m is giving me dialog boxes rather than notification bubbles?
<pitti> well, yes; however, startup is more complicated then
<Kamion> ogra_ibook: what's the nfs timeout issue?
<jdub> hrm, google doesn't seem to index morgue.u.c
<ogra_ibook> Kamion, the issue we already had in breezy, nfs / mounts time out for the first attempt
<mvo> mjg59: ? dialog boxes? like in "gtk dialog boxes"?
<ogra_ibook> Kamion, the second works fine, as well as a normal (non /) nfs mount does
<Kamion> ogra_ibook: have you tried mounting with -o nolock?
<ogra_ibook> not yet 
<Kamion> ogra_ibook: since we don't run the portmapper by default
<mjg59> mvo: Yes
<Kamion> thus nfs can't get at lockd
<ogra_ibook> Kamion, we do with ltsp
<mjg59> mvo: I get a dialog saying "AC power has been unplugged" with an "OK" button
<Kamion> ogra_ibook: ah
<Kamion> jdub: pretty irrelevant considering how out-of-date morgue.u.c is
<ogra_ibook> thats not the issue ... mdz initially thought its a klibc issue in initramfs
<seb128> pitti: in fact I've just tried, epiphany displays .desktop inline like a text file
<ogra_ibook> Kaloz, i think i'll look deeper in there ... since it only happens from initramfs the cause is likely to be in there
<mdz> pitti: approved
<pitti> seb128: and doesn't execute it?
<pitti> mdz: yay, thanks
<mvo> mjg59: sounds like g-p-m is build without libnotify support and falls back to that. maybe a bug in my upload, I can check after the meeting
<ogra_ibook> s/Kaloz/Kamion
<seb128> pitti: no, it display it inline as a text file
<jdub> Kamion: it covered what i was looking for, but turns out i have a backup of what i needed anyway 8)
<pitti> seb128: hm, that's even better IMHO
<Kamion> jdub: fair enough :)
<seb128> pitti: http://people.ubuntu.com/~seb128/, click on gedit.desktop
<mjg59> mvo: Thanks
<pitti> seb128: right, in ffox too; *phew*, thanks :)
<seb128> pitti: np
<Keybuk> http://opensourceversus.com/modules.php?op=modload&name=News&file=article&sid=447&mode=thread&order=0&thold=0
<Keybuk> ^ heh
<pitti> seb128: I think requiring .desktop files to be executable would still be an improvement, though
<Burgundavia> Keybuk, how to make KDE and GNOME look identical
<seb128> pitti: was difference would that make?
<Burgundavia> pitti, upstream has done a lot of work on gobby since UBZ
<pitti> seb128: you could avoid hard-to-see trojan horses
<Keybuk> btw, everyone saw yesterday's stuff about FAT, right?
<pitti> seb128: since nautilus hides the .desktop extension by default
<pitti> Keybuk: it was about VFAT, not FAT :)
<Burgundavia> seb128, pitti can we drop that hiding?
<seb128> pitti: and it doesn't use the real filename neither
<seb128> Burgundavia: no
<mjg59> It's not even about VFAT
<Burgundavia> seb128, why not?
<mjg59> It's about long file names
<pitti> mjg59: isn't that what vfat is about?
<seb128> Burgundavia: you don't want to have all your launcher on the desktop having .desktop do you?
<mjg59> pitti: I was under the impression that vfat included FAT32
<Keybuk> pitti: and FAT32
<Burgundavia> seb128, the user is almost never going to actually be exposed to a .desktop through nautilus
<pitti> mjg59: could be, I'm not sure about the terminology
<seb128> Burgundavia: dnd a menu item to the desktop ...
<Keybuk> (it's also a US patent, and we're safely tucked away in the EU)
<Burgundavia> seb128, how does showing the extension hurt that?
<pitti> any way, AFAIUI it's not about the low-level file system itself, just about the rock-ridge-like mapping of long filenames to short ones
<ogra_ibook> Burgundavia, its pretty ugly ...
<seb128> Burgundavia: I've a nice "gedit" icon to start gedit on my desktop, I don't want it named "gedit.desktop", that's just ugly
<Burgundavia> ogra_ibook, better than having a security problem
<Keybuk> pitti: indeed, the filesystem itself is over 30 years old, so the newly issued patent would expire immediately :)
<ogra_ibook> Burgundavia, i dont really see the security problem ...
<seb128> people will not know what .desktop is and click on it anyway
<pitti> Burgundavia: I'd rather prefer  desktop files to be executable, then you could hide the extension as before
<seb128> you are not going to fix it that way
<pitti> Burgundavia: and since it is kind of a script, it is interpreted (executed) in some way
<ogra_ibook> Burgundavia, as long as your browser doesnt silently download and execute it...
<Burgundavia> pitti, true
<Kamion> Burgundavia: it wouldn't be a security problem if there were a way to have a .desktop file that was marked as having come from somewhere insecure (e.g. executable bit)
<Kamion> obviously it's not the same as SELinux-like MAC, but it's what we have
<Keybuk> Burgundavia: most users I've seen drag icons from the menu and panel onto their desktop
<Keybuk> (until you teach them about panel launchers)
<Keybuk> because that's what they do on Windows
<Keybuk> a ".desktop" extension would confuse them, and make them thing it wasn't "the application icon"
<Keybuk> though .desktop files should *so* be +x to work though
<Burgundavia> Keybuk, true, I retract my request
<Burgundavia> Keybuk, +x means an upload for every application that includes a .desktop file though, no?
<pitti> sadly yes
<seb128> +x means to change every user already created .desktop too
<pitti> which is harder
<Mithrandir> Keybuk: moo.
<Keybuk> better than the current situation, where a user can be given a .desktop file that looks like a text file, but does bad things
<Keybuk> Mithrandir: #ubuntu-boot ?
<Mithrandir> Keybuk: sure
<ajmitch> doko: zope 3.2 & 2.9 before UVF? I see that 2.9 needs python 2.4, which will affect quite a few products
<infinity> ajmitch: zope2.x has gone completely to universe, so you guys are free to break it however you want.
<infinity> ajmitch: THough I'm not sure if you WANT to. :)
<doko> ajmitch: why is the python version problematic?
<doko> it should not
<Kamion> elmo: could you update germinate on jackass, please? It's too old to understand %sourcepkg syntax in seeds.
<ajmitch> doko: just some zope products that depends on python 2.3 libs, not too many thankfully
<ajmitch> eg zope-cmfplone has a dep on python2.3-imaging
<mdke> dholbach, can you do another ubuntu-docs upload to dapper sometime, when you're not busy
<dholbach> mdke: sure
<mdke> great thanks
<dholbach> mdke: now that we sorted out the problems, it's fairly easy - so if you have important/big changes feel free to ping me and i'll do it asap
<mdke> :)
<dholbach> mdke: but i'll do it once a week anyways
<mdke> rockin
<mdke> i've put in a short FF homepage this morning, to replace the old long one
<mdke> needs work, but i'd like to get it in for people to review
<dholbach> mdke: you could do with another call for testers/helpers on the fridge
<mdke> we'll put it in the next newsletter :)
<dholbach> let me do an update before ;)
<dholbach> cool
<mdke> in any case, if the BrowserDefaults spec happens, it won't be relevant, but this is just in case that spec doesn't happen
* Keybuk reads LWN and thinks "Flash Gordon"
<Keybuk> On Wed, Jan 04, 2006 at 07:36:05PM -0800, Linus Torvalds wrote:
<Keybuk> > Yeah, I "forgot" to start that particular flame-war.
<Keybuk> *giggle*
<dholbach> mdke: done
<dholbach> mdke: arg, uploaded it to REVU
<ogra_ibook> lol
<ajmitch> heh
<ogra_ibook> need reviewers ? 
<ajmitch> whoops :)
<dholbach> ogra_ibook: no, i think other people need them more urgently than ubuntu-docs does
<ogra_ibook> heh
* pitti tests live CD, brb
<Kamion> oops, well that was a fun bug
<Kamion> slight mistake in a cdimage script caused it to attempt to copy my entire home directory on little into the CD image it was creating
<Kamion> which includes stuff like backups of old CD images, unpacked DVD images, that sort of thing
<hunger> Kamion: You shouldn't waste space on the cdimages with your backups:-)
<Kamion> not the images I'm creating and expecting people to burn, no
<ogra_ibook> hmm, only backups ...
<ogra_ibook> your personal mail and gpg key would rather be intresting to distribute on an iso :)
<Kamion> ogra_ibook: funnily enough, I don't keep those on little
<ogra_ibook> oh, i read s/on/to
<ogra_ibook> :)
<Kamion> haven't done an Ubuntu CD image build on a machine with my GPG key since Sounder CD 1
<Keybuk> Kamion: hmm, I thought we agreed not to ship porn on our CDs anymore?
<Kamion> although there is *a* GPG key on little for Release.gpg
<Kamion> Keybuk: I'm not volunteering to tell Mark
<\sh> infinity / lamont-away : can you please give back kdebase, thx :)
<Riddell> infinity, lamont-away: kdebase and kdenetwork give back please
<infinity> Riddell: Done.
<mvo> what would be a good tooltip for "Get Help Online..."? "Connect to the ubuntu webservice to get online help"?
<hunger> mvo: Why not write website?
<Kamion> "Connect to Launchpad for online help" (saves having to rebrand for Kubuntu, Edubuntu)?
<Kamion> or "to the Launchpad website"
<hunger> mvo: People are way more likly to know that than webservice.
<hunger> Kamion: I'd keep the "website" to emphesize that this is on a remote computer.
<ogra> i'd take "get online help ..."
<mvo> "Connect to the Launchpad website for online help" <- good?
<ogra> i find it to long
<Kamion> for a tooltip?
<seb128> it's something display to the bar on the bottom of the app
<seb128> like for every other menu item
<seb128> not a mouseover tooltip
<mvo> tooltip for "Translate This Application" -> "Connect to the Launchpad website to translate this application" ?
<vuntz_> will people know what is Launchpad?N
<ogra> oh, yes, for the tooltip its fine ...
<mvo> "Connect to the Launchpad website to help translating this application" ?
* hunger does not find the onlinehelp very helpful.
<ogra> hunger, so contribute to it to make it better ;)
<seb128> vuntz_: "Launchpad website" ... seems clear it's a website :)
<vuntz_> seb128: right, but I don't trust a website I don't know...
<seb128> vuntz_: dunno if that would be confusing to people to have the Launchpad name
<seb128> vuntz_: we can't put a complete description of what launchpad is in a tooltip :)
<vuntz_> I agree :-)
<mvo> might be good to have the launchpad name, to make it a stronger brand 
<vuntz_> it's just that there should be some document explaning what launchpad is
<vuntz_> in ubuntu-docs
<dholbach> vuntz_: sounds good
<dholbach> maybe after the LPI paragraph
<vuntz_> don't ask me to write it :-)
<mvo> ok, if noone complains then its "Connect to the Launchpad website to help translating this application"
<Kamion> grammar: "help translate"
<Kamion> or "help to translate"
<mvo> does "to help to translate" sound right? two "to" so close?
<Kamion> either "to help translate" or "to help to translate" is fine; the former is perhaps slightly more colloquial / less forced
<seb128> vuntz|miam: speaking about writting ... UDN? :)
<Kamion> or "to help with translating", although I don't really like that as much
<mvo> I will pick "to help translate" then I guess
<ogra> dapper-live-i386.iso  12-Jan-2006 01:05  9.9M  ... wow, i didnt know squashfs would gain us *this* much
<ogra> :)
<\sh> lol
<Kamion> edubuntu?
<ogra> Kamion, yup, tonights build
<Nafallo> haha :-)
<Kamion> I think that predates squashfs
<ogra> i thought its already in ...
<Kamion> yeah, but 20060111 had the same problem
<ogra> ah
<Kamion> I think you've just got no working livefs build
<ogra> oh, i wasnt referring to the error with squashfs, just joking ...
<Kamion> or, hmm
<Kamion> yeah, your build dates from 20060102
<ogra> ah
<ogra> then most likely edubuntu-desktop was broken at this time ...
<Kamion> exactly why it didn't add the cloop is a good question
<Kamion> obviously there's no point debugging the 20060102 livefs build, but see http://terranova.buildd/~buildd/LiveCD/dapper/edubuntu/latest/ (accessible from chinstrap) for the livefs build log
<Kamion> that's for i386, amd64 and powerpc are on king and royal respectively instead of terranova
<Kamion> dpkg: error processing edubuntu-artwork (--configure):
<Kamion>  subprocess post-installation script returned error exit status 1
<Kamion> I suspect your debconfiscation is broken
<ogra> meh
<ogra> worked fine on all test setups i had ...
<Kamion> why do you do db_get in config? it's not a reason for it to fail, but it's pointless
<Kamion> remove the db_capb; you don't do anything on backup anyway
<ogra> oki
<Kamion> (and just do db_go || true)
<ogra> but why doesnt it fail on tests here ... weird
<Kamion> (gdmflexiserver:26880): Gtk-WARNING **: cannot open display:
<Kamion> I think that's the error
<ogra> ahhh
<ogra> ok
<ogra> indeed i didnt test without X
<ogra> will add a check ...
<Kamion> instead of checking, can gdmflexiserver be made to work without a display?
<Kamion> since we do want to enable the theme, we just don't want to need a display to do so
<ogra> good question... seb128 ?
<Kamion>           gdmflexiserver --command="UPDATE_CONFIG greeter/GraphicalTheme"
<ogra> the command isnt needed if gdm isnt running ...
<seb128> what is the question about?
<ogra> its in fact only needed for "switch user" 
<ogra> seb128, making gdmflexiserver --command run without DISPLAY being set
<Kamion> ogra: oh, right
<Kamion> seb128: edubuntu-artwork postinst
<ogra> if you end your session the greeter is restarted anyway ... i'll just check for DISPLAY being non zero and it should be fine ...
<seb128> right, it should not require xorg
<Kamion> ogra: sounds fair enough then, yes
<seb128> x running I mean
<Kamion> ogra: ping infinity for a livefs rebuild once you're done; if he's not around, ping me
<ogra_ibook> oki
<Kamion> ah, ok, I see why the cloop went missing anyway, fixing
<Kamion> rather overenthusiastic cleanup after failed fetch of the livefs kernel output (which wasn't delivered until a week or so ago)
<janimo> elmo, please sync/override xfce4-terminal, thanks
<Kamion> d'oh, little's update to breezy killed report.html
<Kamion> ImportError: libapt-pkg-libc6.3-5.so.3.9: cannot open shared object file: No such file or directory
<mvo> Keybuk: did I tell you already that bzrk really rocks?
<\sh> mvo: everyone knows :)
<mvo> :)
<ogra_ibook> it urgently needs a cache for websources
<Mithrandir> is there any gui tool to edit fstab and mount partitions?
<\sh> ogra_ibook: we actually need hct asap :) in the moment I'm doing Mhct work
<ogra_ibook> Mithrandir, the disk manager app should be able to do it
<Mithrandir> ogra_ibook: thanks
<pitti> Mithrandir: disk manager is pretty broken; pysdm is much better IMHO
<pitti> ogra_ibook: did you ever manage to alter your fstab with disk manager?
<pitti> I didn't
<Mithrandir> pitti: it's a user who asks "how do I access my fat32 partitions from the live cd"
<ogra_ibook> i never tried
<ogra_ibook> but its supposed to do it
<pitti> Mithrandir: mounting it for the current session works well with disk manager
<pitti> Mithrandir: it just doesn't alter fstab
<DocTomoe> There might be a problem in dapper, concerning glibc6 and konqueror
<fabbione> DocTomoe: such as?
<DocTomoe> jam
<fabbione> jam?
<Kamion> pitti: locale-gen doesn't do anything if /etc/locale.gen doesn't exist, which it doesn't in a freshly debootstrapped chroot. Is this intentional?
<Kamion> I'd like to be able to do 'sudo debootstrap breezy /space/breezy; sudo chroot /space/breezy locale-gen en_GB.UTF-8'
<pitti> Kamion: actually not; /etc/locale.gen is not supposed to exist any more
<Kamion> yeah, I thought it seemed odd
<ogra_ibook> fabbione, marmelade ...
<Kamion> pitti: oh, er
<pitti> Kamion: what does /var/lib/locales/supported.d contain?
<Kamion> pitti: sorry, I'm very stupid indeed, I'm debootstrapping *breezy*
<fabbione> ogra_ibook: i know what jam is.. i don't see the relation between libc6 konqueror and jam
<pitti> oh, heh, right
<DocTomoe> jam = just a minute ... I just have written the problem to raphink in #kubuntu. basically, konqueror somehow does not like the current glibc
<ogra_ibook> fabbione, me neither :)
<raphink> hmmm
<raphink> DocTomoe: the thing is that I see no glibc nor konqueror in the latest updates 
<raphink> there is kdelibs-data though
<raphink> does it happen with other programs than just konqueror DocTomoe ?
<DocTomoe> raphink: none that I know of.
<Kamion> DocTomoe: why do you believe that it's related to glibc? presumably there's some error message that makes you believe that
* raphink finishes to upgrade his dapper box
<raphink> [2006-01-12 13:03]  <DocTomoe> martin@haguchan:~/.kde/share/apps/konqueror$ konqueror
<raphink> [2006-01-12 13:03]  <DocTomoe> *** glibc detected *** corrupted double-linked list: 0x4033d278 ***
<raphink> Kamion: that's what makes him believe so ;)
<Kamion> that's glibc detecting an error in the application
<DocTomoe> Kamion: konqueror says "*** glibc detected *** corrupted double-linked list: 0x4033d278 ***", then dies
<Kamion> it's not konqueror not liking glibc, it's glibc saying konqueror (or one of the libraries it uses) has a memory allocation bug
<raphink> konqueror wasn't upgraded lately though
<fabbione> DocTomoe: that's a bug in konqueror
<DocTomoe> Kamion: I am no developer ... However, I thought this is glibc
<shawarma> On which package do I report bugs in drivers in the kernel images in Dapper? The only package beginning with linux-image is linux-image-k7 in the Bugzilla web interface.
<Kamion> DocTomoe: I am, and it's not :-)
<fabbione> shawarma: linux
<ogra_ibook> shawarma, drop -image
<raphink> oh yes it was
<Kamion> how did linux-image-k7 creep in again? I deleted that component
<shawarma> fabbione, ogra_ibook: Great. Thanks.
<fabbione> shawarma: no problem. you own me another 5lt of beer :)
<Kamion> I'll not delete it again now because I think the script to convert component assignments to Malone has already been run
<fabbione> shawarma: pretty good btw..
<shawarma> fabbione: LOL.
<DocTomoe> maybe that last bit of info I gave on #kubuntu is helpful ... I deleted ~/.kde/share/apps/konqueror/*history* and konqueror seemes to work nicely for about 30 minutes.
<shawarma> fabbione: Great. I haven't actually tasted that one.
<fabbione> shawarma: i did :P
<raphink> DocTomoe: what exactly do you do to make it crash?
<DocTomoe> raphink: I just entered a domain name in the adress bar. the first character appears, then it freezes for about 3 seconds, then it quietly dies (even w/o KDEs Crash assistant)
<raphink> ok
<DocTomoe> I think after the first character it performes a search in its history file that somehow screwes up because of some memory leak or something
<DocTomoe> as stated above, I am no developer :)
<raphink> can't reproduce here
<raphink> could you report the bug please DocTomoe ?
<DocTomoe> raphink: to what of the 7 million existing bugzillas out there? ;)
<DocTomoe> boy, I really have to do some work on my english grammar -_-
<raphink> DocTomoe: I know no project that has no bug
<raphink> and a distro is not declared stable when it has no bugs anymore
<raphink> but reporting bugs helps tracking them down
<DocTomoe> raphink: thats not exactly what I meant. ubuntu has a bugzilla and launchpad. on which one should I file the bug report?
<lifeless> malone
<raphink> oh ok
<lifeless> bugzilla is about to shut down
<raphink> :)
<raphink> and malone looks nicer :)
<DocTomoe> you wouldnt happen to have the url handy, would you?
<ogra_ibook> launchpad.net
<raphink> http://launchpad.net/malone
<Kamion> https://launchpad.net/distros/ubuntu/+filebug is probably more direct
<DocTomoe> ok, done. thanks for your support
<DocTomoe> https://launchpad.net/distros/ubuntu/+source/kubuntu-konqueror-shortcuts/+bug/6706
<\sh> DocTomoe: what is it about?
<DocTomoe> \sh: seems like a memory problem in dappers konqueror or something
<\sh> bugs for my invention needs to have my attention :)
<ogra_ibook> Kamion, hmm, assumingly the broken edubuntu-artwork is on the install images as well ... i guess i'll need a new build there as well ...
<raphink> hmm
<\sh> DocTomoe: oh well..then it's the wrong source package :)
<raphink> why did you report it against kubuntu-konqueror-shortcuts DocTomoe ?
* ogra_ibook twiddles thumbs while waiting for the package to show up on buildlogs ...
<Kamion> ogra_ibook: yeah, will do once it's built
<\sh> DocTomoe: it should be kdebase
<raphink> yep
<\sh> chaging to kdebase
<raphink> :)
<DocTomoe> raphink: thats the package malone suggested
<raphink> hmmm ok
<\sh> DocTomoe: to find a source package of a binary package :) apt-cache showsrc konqueror e.g.
<raphink> but it's kdebase though ;)
<\sh> therefore launchpad must search the binary package names as well and find out which source package it is
<\sh> anyways...changed to the correct source package and assigned to the kubuntu team :) 
<\sh> DocTomoe: thx for the report :)
<Lathiat> daniels: ngghhh my alps touchpad is going at the speed of a snail again :(
<Treenaks> daniels: re-poke, I haven't received your ATi thing yet ;)
<ogra> Treenaks, ati thing ? 
<Treenaks> ogra: yeah, a register dumper; my HP laptop works with flgrx but not with ati
<Treenaks> ogra: daniels and mjg59 said they wanted to diff the output to see what's going wrong
<ogra> where did you get fglrx ? 
<Treenaks> ogra: apt
<ogra> i'd love to see my ati card in the ibook on it ... but there is no fglrx in dapper yet 
<Treenaks> ogra: oh? I have working X _and_ dapper on my laptop
<Treenaks> ogra: maybe because it's ppc?
<ogra> hmm
<ogra> i remeber having seen it before ... 
<ogra> (on ppc) 
<infinity> There's never been fglrx on powerpc.
<Treenaks> ogra: I'm having weird problems that look like sync problems with the 'ati' driver; fglrx works fine on the same resolution
<ogra> infinity, ah, thanks 
<infinity> (And there probably never will be)
<ogra> yes 
<ogra> very unlikely since ppc for home users will die ...
<ogra> infinity, you could trigger a livefs build for edubuntu as soon as you have time for it btw, edubuntu-artwork is there now 
<ogra> Kamion, do i have to poke you separately for install images ? 
<infinity> When I'm done with the ubuntu builds, I'll trigger edubuntu, but I won't wait around to see if they succeed.  It's 8 minutes to midnight here.
<ogra> infinity, fine with me ...
<ogra> thanks 
<infinity> ogra: Note that these images won't rsync from the last ones (switching from cloop to squashfs), so you're in for a big download.
<ogra> oki
<ogra> the last working ones were around flight2 anyway ... 
<Treenaks> cool, a Dutch library has 'Ubuntu CDs' in their catalog, and when you go there, they just give you a fresh set of Breezy discs :)
<ogra> wow
<Treenaks> ogra: instead of charging you for it, and asking them back, that is :)
<ogra> cool
<pitti> ANNOUNCE: malone/launchpad discussion meeting in #launchpad now
<Kamion> infinity: don't trigger edubuntu please
<ogra> still something missing ? 
<Kamion> ogra: debootstrap's broken at the moment due to a slightly-experimental change I made in debian-cd to save a bit of space; looking at whether it's easily fixable. in the meantime I'm not going to build more install CDs
<ogra> ok
<Kamion> (no point)
<infinity> Kamion: Oh.  Too late, but I won't trigger livecd builds, just let the filesystems go to waste when they're done.. <shrug>
<infinity> Kamion: Or, wait.  Do you mean "debootstrap is broken in the context of install CDs", or "it's broken, period"?
<infinity> Kamion: Cause I was just doing Live builds right now, not triggering install builds.
<Kamion> infinity: only in the context of install CDs
<infinity> Okay, good.
<Kamion> I've decided to fiddle debian-cd in a different way
<infinity> Then I'll let the live builds go on.
<infinity> ubuntu-live should be publishing shortly, and I'd like to get some testing while I'm in bed. :)
<infinity> (Mithrandir said amd64 was okay, powerpc and i386 are dailying as we speak)
<ogra> infinity, i'll do some live testing (so i can rsync from ubuntu-live later)
<infinity> Kay, I'll let you know when the publishing run is done...
<infinity> Okay, ubuntu-live ISOs should be published for all arches.
<infinity> http://cdimage.ubuntu.com/daily-live/current/
* ogra wgets ...
<infinity> (rsync works too)
<ogra> i know, but my last ubuntu liove iso also dates back to flight2
<infinity> Oh, no, I didn't mean "they'll rsync well over other ISOs", I just meant "you can download with rsync"...
<infinity> Mostly, I'm just paranoid about wget screwing up my download. :)
<infinity> (but you can wget, then check MD5SUMs, I guess, then rsync to fix if it's broken.. <shrug>)
<ogra> yup
<ogra> i already have two rsyncs running, so i resort to wget for more images :)
<mdke> infinity, any luck with ubuntu-docs?
<infinity> I've been swamped, I'm sorry. :/
<mdke> yeah, np I can see :)
<infinity> I have a big note here, telling me that it's important.  It's just one or two bullet points below some other things on that same note.
<mdke> infinity, ok, in that case I'll stop nudging for a while :)
<infinity> ogra: Live filesystems for edubuntu built, livecd build running.  And from here on, I think you can expect radio silence from me (bed), so just keep refreshing http://cdimage.ubuntu.com/edubuntu/daily-live/current/ until the timestamps get newer. :)
<ogra> i will, thanks and sleep tight 
<sistpoty> ping mdz
<infinity> elmo : Can you sync mysql-dfsg-5.0 from Debian (or do an autosync run, which will catch it)?  Thanks.
<infinity> ogra: Those images are published, BTW.
<infinity> elmo: Oh, nevermind, looks like you did a run when I wasn't looking.
<ogra> infinity, and they llok good (size and report wise), thanks again ... and to bed with you
<Riddell> seb128: what's your thoughts on having avahi-daemon installed by default but turned off?
<seb128> would be nice
<seb128> we just need an easy way to turn it from the UI then
<ogra> and a big popup warning what its doing :)
<ssam> seb128, how about a zeroconf tab in the network setting control panel
<Kamion> ogra: (you know that report.html is irrelevant for live CDs, right?)
<Kamion> I've been meaning to stop publishing that
<ogra> Kamion, yes, but i'm so used to it :)
<sistpoty> elmo: please sync ocamlcreal from unstable, ubuntu override ok. Thx.
<seb128> ssam: yeah, could be a place for that
<Kamion> ogra: ok, well it's no longer published now
<ssam> seb128, perhaps letting you choose which interfaces you want it on. you might want it for wireless, but not when you plug into your office network
<ogra> Kamion, great, so it wont fool me anymore :)
<Lathiat> ssam: unfortunatley that is not yet available in avahi
<Lathiat> ssam: short of using iptables
<seb128> ssam: it has been discussed on the zeroconf spec on the wiki
<seb128> ssam: those points are mentionned IIRC
<ssam> seb128, ok thanks
<\sh> hmm..do we need avahi/zeroconf/scary magic for network and system administrators by default? I think it should be only for the brave users...
<Lathiat> 'network administrators' ?
<Lathiat> how is that role defined within ubuntu?
<ogra> people that use more ubuntu-server than -desktop installs ?
<\sh> Lathiat: the network admins have to close all incoming ports towards all workstations in the network to prevent any harm
<Lathiat> \sh: its already decided that avahi has to be off by default so i dont really see point in this conversation anyway?
<\sh> and blocking all multicast addresses
<Lathiat> blocking multicast on a local network is hardly going to make anything more secure
<Lathiat> and not even possible on a switch?
<\sh> Lathiat: with a normal 3com switch of course it's not possible..thinking about real life and expensive switches with router logic inside, it is possible
<Lathiat> true
<Lathiat> that really has nothing to do with whether its enabled on the PC tho
<Lathiat> it just wont work if they block it
<Lathiat> i dont know anyone who blocks multicast accross their network tho for security
<Lathiat> and avahi is LL so it wont cross routers anywhere where its most likely to be blocked
<\sh> Lathiat: yes. that's why it should not be installed by default, because when there is no lighter to play with, there will be no fire
<Lathiat> \sh: so why dont we not install firefox? they cant goto bad web pages then
<Lathiat> maybe skip network drivers? ;)
<\sh> Lathiat: in coporate environments :)
<Lathiat> \sh: corporate environements are customized
<Lathiat> and usually dont give users root
<Lathiat> so they couldnt turn it on in the first place
<\sh> Lathiat: okok...next time I use my live cd to turn it on :)
<Lathiat> \sh: and then its blocked at the switch? ;p
<Lathiat> \sh: yo ucould do lots more damage with a livecd than use avahi :)
<Lathiat> and avahi is coded to be fairly secure its not like its a big gaping security hole (im not saying it doesnt have any security bugs, odds are it does somewhere)
<\sh> Lathiat: actually that's why most of the companies have more problems with the internal network then with external conncections :)
<Lathiat> heh
<Lathiat> most companys just need to shoot their employees :)
<Treenaks> Lathiat: AND their customers!
<pitti> Lathiat: I reviewed the code for maybe 30 minutes, and I just found one obvious flaw, which I told lennart, and he fixed it in upstream cvs some hours later
<Lathiat> pitti: i saw
<pitti> Lathiat: ah, yes, I remember
<Lathiat> in fact we even discussed it :)
<pitti> that doesn't mean that there are no bugs, but the code looks fairly sane
<Lathiat> any which way, its off by default, turning it on isnt much harder than going and installing sshd and adding a user claled test/test
<Lathiat> pitti: i said 'coded to be'.. 'not sayign it doesnt have any..' :)
<pitti> Lathiat: right :)
<\sh> starting VMS 
<Lathiat> trying to say it doesnt have any security bugs would be silly :) just saying that its designed to be OK, we check data all about the place, and not just blindly accept things, so its not a 'gaping' hole :)
<Lathiat>  having said that
<Lathiat> whats the bet someone finds a really big hole tomorrow :P)
<Lathiat> garrr
<Lathiat> im hitting my P key again
<Lathiat> im going to rip it out
<pitti> Lathiat: but then you couldn't type tongue smileys any more :-p
<Lathiat> but then i wouldnt look like a dickhead typing combination tongue-smile smileys :)
* desrt abuses Lathiat 
<Lathiat> see what i mean :(
<pitti> hi desrt 
* pitti sighs on the utopia list
<pitti> I'm so sick and tired of discussing hald privileges
<desrt> this is why i didn't abuse you
<desrt> you've had enough abuse
<jk__> what's the right place to tell how I got madwifi running in restricted WEP mode?
<pitti> elmo: please sync libapache2-mod-auth-pgsql and pmount
<pitti> desrt: heh :)
<pitti> desrt: I just wonder why I'm the only dickhead who wants to go that way
<\sh> jk__: #ubuntu :)
<desrt> pitti; dude.  i'm with you.
<desrt> pitti; you're the voice of reason and sanity
* pitti hugs desrt 
<desrt> i think there is _no doubt_ that hal has about a million holes in it
<desrt> and allowing users to shoot strange command packets at it is only going to introduce more attack possibilities
<Treenaks> desrt: little ones, or huge, gaping ones?
<desrt> at the same thing, moving the entire thing to run as root.... heh... are we morons?
<pitti> Treenaks: not sure, but it took me about 30 seconds to find that you can probably own hald with a specially crafted mac partition signature on your usb stick 
<pitti> Treenaks: (at least crash)
<Treenaks> pitti: whee.. sanity..
<pitti> I phear the moment if somebody actually looks for holes in the code
<desrt> and most hax0rs are more bored an an overworked ubuntu hacker :)
<pitti> and I'm not even very experienced with finding holes
<Treenaks> So Ubuntu needs a few professional secuirty auditors? :)
<Treenaks> -typo
<desrt> well
<desrt> a trivial workaround is available
<desrt> DON'T RUN HALD AS ROOT
<desrt> -ahem-
<\sh> those people can be really expensive :)
<pitti> desrt: shiny idea, go tell upstream :)
<pitti> Treenaks: still, security auditing can never hurt, but please one hole at a time :)
* desrt has code in hald
<jk__> \sh: Tell, not ask. I was hoping for something less ephemeral than irc
* desrt certainly didn't make any above-average effort to make sure it was hax0r-proof
<desrt> and i know a lot of the other hal contributors aren't as talented as i am :p
<janimo> pitti, aren't there tools already to find typical bugs like the alloc() one you just sent to the hal list?
<Riddell> infinity: I'm probably being impatient here but do you know why kdelibs -0ubuntu8 isn't listed in dapper.all.i386? uploaded an hour Ago
<janimo> besides grep :)
<\sh> jk__: wiki.ubuntu.com
<pitti> janimo: I used advanced static code analysis
<pitti> janimo: (a.k.a. 'grep')
<desrt> woh
<janimo> your brain? 
<desrt> oh.
<desrt> i know that method!
<\sh> jk__: to have your experiences written down :) and archived forever :)
<jk__> :-)
<pitti> janimo: but yes, there are tools to find the common holes; I never used them, though (although I would like to)
<pitti> janimo: in fact some of the recently discovered holes were discovered by these systems
<pitti> janimo: in experienced hands, they can be really powerful
<desrt> hmm
* desrt should find out
* pitti goes back to fix cups
<desrt> hax0r/slashing is one of the pieces missing from my skillset
<\sh> so..bbl...
<Riddell> pitti: how come CUPS browsing is off by default?
<Robot101> Riddell: aren't all network services off by default?
<desrt> Robot101; that's not really a valid way of approaching it :)
<desrt> Robot101; since it's only bound to localhost but still the interface is disabled
<desrt> Riddell; you mean the web interface, or ...?
<Robot101> the localhost:631 is not the same as browsing for printers
<desrt> k.  i'm probably wrong then :)
<Robot101> although I agree, both disabling and binding to localhost is quite annoying
<Robot101> just the latter would be sufficient for me
<desrt> it prevents abuse by people not in the printer admin group
<desrt> but the gnome cups utilities are nowhere near as functional as the web interface :(
<Robot101> er, you need to log in to effect any changes
<Riddell> ...knowing little as I do about CUPS. I'm just passing on a query
<Riddell> browsing sounds like searching the network not opening any ports
<jdub> Riddell: not the way CUPS works
<jdub> Riddell: it listens for broadcasts
<jdub> (bong like SMB!)
<Riddell> right, and like dnssd
<Robot101> even if it only sent out queries and listened for responses, it could still potentially be exploited with malicious responses
<janimo> is new cups supposed to autoconfigure usb printers?
<sivang> Riddell: if you use g-c-m to enable this, you will be prompted to confirm opening port 639 on your machine
<Robot101> hence off is a good plan.
<janimo> i.e no need for setting them up with g-c-m?
<Mithrandir> Robot101: so can web browsers, etc.
<Robot101> Mithrandir: yes, but not without the user knowing
<jdub> janimo: i don't think we have the red hat changes to do that yet
<pitti> janimo: no, we aren't quite that far
<janimo> planned for dapper?
<pitti> janimo: mainly because selecting the correct driver is not trivial
<pitti> janimo: no, completely automatic is not even spec'ed
<pitti> janimo: we wanted to make it much easier than it is now, though
<sivang> pitti: IIRC upstream were going to take care of that, no?
<pitti> sivang: automatic conf? no, they won't
<sivang> pitti: ah sorry, got confused with automatic detection...
<janimo> is there a printing spec for dapper with the improvements vs breezy written up?
<janimo> planned improvements that is
<pitti> yes, https://wiki.ubuntu.com/AutomaticPrinterConfiguration
<janimo> got it thanks
<janimo> LP does not have search for specs right?
<janimo>  I always load up the whole page then look in it
<janimo> takes quite a bit
<Riddell> infinity: ignore me, I was being impatient
<Lathiat> hrm, what happened to unrar-nonfree
<Mithrandir> it was renamed to unrar
<Mithrandir> and unrar to unrar-free
<Lathiat> err
<Lathiat> i dont see either?
<pitti> unrar-free |  1:0.0.1-2 | http://archive.ubuntu.com dapper/universe Packages
<pitti> unrar-free |  1:0.0.1-2 | http://archive.ubuntu.com dapper/universe Sources
<tseng> unrar is broken because its trying to go into non-free
<tseng> not overridden into multiverse
<janimo> pitti, what about PrinterSharing, does not seem approved
<Lathiat> ah
<pitti> janimo: we don't have manpower to tackle either spec so far
<Lathiat> pitti: umm, i only see sources
<Lathiat> pitti: do you have it installed?
<Lathiat> tseng: do i have to ask elmo to fix that?
<janimo> I wonder if I can help, I'll look at these specs
<tseng> Lathiat: yes
<pitti> Lathiat: http://archive.ubuntu.com/ubuntu/pool/universe/u/unrar-free/ -> it's really, really there
<pitti> Lathiat: and yes, apt-get install unrar-free WFM
* Lathiat boggles
<Lathiat> i have dapper{,-updates,-security} main universe multiverse restricted and i dont have a binary for it
<Lathiat> i must be doing something silly
<pitti> Lathiat: what does 'apt-cache madison unrar-free' say for you?
<Lathiat> [lathiat@qaplaH lathiat] % apt-cache madison unrar-nonfree
<Lathiat> unrar-nonfree | 1:3.5.2-0.1 | ftp://archive.ubuntu.com dapper/multiverse Sources
<Lathiat> [lathiat@qaplaH lathiat] %
<pitti> and -free?
<pitti> (nonfree is fucked, we already know that)
<Lathiat> unrar-free |  1:0.0.1-2 | ftp://archive.ubuntu.com dapper/universe Packages
<Lathiat> unrar-free |  1:0.0.1-2 | ftp://archive.ubuntu.com dapper/universe Sources
<Lathiat> well, nonfree is what im trying to sort out
<Lathiat> since the free version doesnt unrar pretty much anything i want it too
<pitti> ah, ok, I wondered about <Lathiat> i dont see either?
<ogra_ibook> so you want unrar now :)
<Lathiat> well
<Lathiat> i didnt realise it was called -free
<Lathiat> i cant see 'unrar' or 'unrar-nonfree'
<Lathiat> 'as binary
<Lathiat> so i need to mail elmo and say that unrar-nonfree needs to be overridden into multiverse?
<pitti> Lathiat: hm, 'unrar' rather, right?
<Lathiat> err
<Lathiat> ah ok
<Lathiat> well
<Lathiat> no
<hunger> apt-get install unrar gets me a note informing me that apt will install unrar-nonfree instead.
<Lathiat> actually yes
<Lathiat> i thin
<Lathiat> source is unrar-nonfree
<Lathiat> binary is unrar
<Lathiat> hunger: mine says its not available
<hunger> Lathiat: Yeap, after purging unrar-nonfree I get that message.
<Lathiat> right
<hunger> Lathiat: unrar-free does install here though... but it does not really unrar much.
<Lathiat> hunger: exactly what i said above :)
<Lathiat> its fairly useless
<hunger> Lathiat: Right.
<janimo> where is the specs current status for dapper in the wiki?(colors, estimated times etc)
<sivang> janimo: this is now in LP, IIRC
<pitti> jdub, desrt, sjoerd: I'd appreciate your opinion on the utopia list, so that the guys see that I'm not the only weirdo here :)
<janimo> pitti, yeah you;re quite outnumbered there :)
<janimo> btw the spec says try eggcups early in the cycle. has that happened?
<pitti> janimo: no, this spec was just assigned to me because nobody else wanted it; but ENOTIME from my side
<janimo> ok
<pitti> janimo: if you are interested in improving printer support, we'd appreciate
<pitti> it badly needs love
<janimo> I am interested
<pitti> I can keep up with fixing the most horrible cups bugs, but not with adding features
<janimo> all my friends give me the weird looks when using ubuntu and printing issues is one of the reasons :)
<pitti> janimo: sad, but true
<jdub> pitti, janimo: that's going to involve cups patches and stuff too :(
<tseng> pitti: its hard to sound crazy when you give such specific examples
<janimo> did RH have it fixed or we'd have to do more work beside what they have?
<pitti> janimo: there are handfuls of cupsys bugs in bz, fedora's hal-cups-utils (and it's g-v-m integration) needs a look
<janimo> means I'll have to install gnome :)
<janimo> ok then
<pitti> jdub: certainly; what's wrong with patching cups? (well, ok, upstream is not really accepting patches, but still...)
<pitti> janimo: not for triaging cupsys bugs and for hal-cups-utils
<pitti> janimo: if the current system would at least be less buggy, it would already help a lot
<janimo> sure, but I want to look at the ui side too
<pitti> janimo: merely installing gnome-cups-manager should do; you don't actually need the whole gnome
<pitti> it talks to cups and configues it, and you can manage jobs with it
<pitti> i. e. it doesn't talk to many other gnome stacks
<janimo> yeah, but I will do it anyway (laptop-testing team :) and want to see if something like g-c-m can be written for xfce
<Diziet> So in python I have a list containing several lists.  How do I flatten it into one big list ?
<sivang> janimo: I might be able to put some help for small fixes, and gui changes if you like help :) I did the gui part of the "Enable LAN printer detection" ubuntu patch in g-c-m.
<Diziet> I don't seem to be able to find the standard library function to do this.
<janimo> sivang, ok :)
<Diziet> I could roll my own with reduce but surely it should be in the library ?
<pitti> Diziet: lemme look in my 'Python Cookbook', 1.12 "Flattening a nested sequence"
<jdub> pitti: stuff to maintain, work to do, changes to test... usual gumpf :)
<Diziet> Why oh why oh why is everything so difficult in Python ?
<pitti> jdub: yes, today is not my best 'upstream love' day either
<janimo> Diziet, I think ff needs to depend on libnss3
<janimo> for https access to work
<Diziet> janimo: You have a system with no libnss3 ?  Well done :-).
<Diziet> But seriously, yes, it should.  Doesn't it ?  If not, please file a bug.
<janimo> Diziet, it needs to be depended upon to be installed ;)
<janimo> I did file a bug two days ago
<Diziet> Oh, right.  Well, I'm not working on ff this week.  I'm wrestling with a very silly programming language instead.
* Diziet gives up and uses reduce.
<pitti> Diziet: no standard lib for that, you need to write your own function
* jdub defends pitti's honour on utopia-list
<janimo> ruby has Array#flatten :)
<janimo> too bad it wasn't around when thawte was founded ;)
<sjoerd> pitti: i'm quite far with a patch for hal, so that it uses a helper running as root to invoke programs
* pitti hugs sjoerd 
<sivang> Diziet: do you have anything to say in favor or, against dropping users' home directory suggestions and instead just letting a user add dirs he wants to backup (re: HomeUserBackup)
<sjoerd> pitti: first version should be finished tomorrow evening or maybe even tonight :)
<Diziet> sivang: Err, what would it do by default ?
<Diziet> I think it is more important that it backs up users home directories by default than that there is any way to configure what it backs up.
<sivang> Diziet: by default I will make it check /home , if it finds it, it backes up everything underneath is that has an /etc/passwd entry. If not, I am thinking of letting the user specify the home toplevel. "I couldn't identify where users' homes are stored. Please choose the home toplevel"
<sivang> Diziet: bad, drop the passwd bit. home can also be /users/s/sivan...
<Kamion> why not just go through the home directory fields for non-system users in /etc/passwd, then?
<jdub> hrm, 'tis a pity lenovo's recent lappies don't have DVI ports
<sivang> Kamion: hmm.. good point. thanks, I hope there's a nice and easy way API to walk through /etc/passwd ;-)
<ogra_ibook> is this a single user app ?
<sivang> ogra_ibook: the backup one?
<ogra_ibook> the $HOME should suffice 
<ogra_ibook> s/the/then
<Diziet> ogra: No, bad idea.
<sivang> ogra_ibook: if you're not an admin that can sudo, it's going to let you backup only your home
<ogra_ibook> sivang, yes
<Diziet> Right.
<sivang> ogra_ibook: if you are, then backup all homes.
<sivang> or at least, offer to backup all homes
<Diziet> But having things accidentally left out of a backup is very bad.
<ogra_ibook> good, whats wrong with that ? 
<sivang> wrong with using $HOME? 
<ogra_ibook> wrong with $HOME only, for non admin users
<Diziet> Err, if you're just doing this user then $HOME is right but that shouldn't be the default for the admin user.
<ogra_ibook> true
<ogra_ibook> thats why i asked if its a single user app
<Diziet> Any sensible language will have an easy way to iterate over users in the passwd database.
<sivang> Diziet: :)
<Diziet> If you tell us what you're using we can probably produce a reference :-).
<sivang> Diziet:heh, once I found it, I will tell you.
<Kamion> sivang: getpwent
<jdub> mmm, can't wait to see the T60p
<sivang> ah, Kamion , always fast as a snap :)
<Kamion> it's in the python pwd module
<Kamion> (getpwall there)
* sivang experiments in ipython with that
<Kamion> http://docs.python.org/lib/module-pwd.html
<Gagatan> ipython is teh sweetness
<sivang> Gagatan: word :)
<sivang> Kamion: I usually print the docstrings in ipython, for quick simple stuff this is quite enough docs to get started.
<Diziet> Oh, I meant, what language.
<sivang> Diziet: oh, sorry. I thought it was taken for granted it's python.
<Diziet> Yers.  Don't get me started again :-).
* sivang now looks for the "what uid am I running with" module.function.
<Keybuk> Riddell: if someone installs kubuntu-desktop, but kdm still logs them into gnome, what do they need to fiddle?
<Diziet> os.getuid() etc.
<Kinnison> Keybuk: a quick fix is probably to delete ~/.dmrc
<Kinnison> Keybuk: Otherwise they need to find how to tell kdm to use the kde session
<Riddell> yes, ~/.dmrc or click the Session menu same as in gdm
<sivang> jdub: that's nice, Ubuntu appears on http://www.python.org/Jobs.html ;-)
<Keybuk> are you sure the session menu didn't get removed in one of seb's "that's useful, get rid of it" purges? <g>
<Keybuk> who's good at art?
<Keybuk> we need a "mom" hackergotchi on launchpad
<pitti> Keybuk: ask jdub for the 'mom' part :)
<mgalvin> Mithrandir: might there be any more info about live cd persistance anywhere?
<Mithrandir> mgalvin: there's a little bit in my blog, but no, there are no docs yet.
<mgalvin> i saw that, ok, thanks
<Mithrandir> mgalvin: basically, make a file system on something the live cd initramfs will see, make sure it's label is "casper-cow" and make sure persistence is turned on in the boot menu
<Mithrandir> mgalvin: I'd _love_ to get testing and feedback on how it works, since I've just tested that it works at all. :-)
<sivang> Keybuk: mom is getting a launchpad account? :)
<mgalvin> Mithrandir: are there any specific size requirements, will a 128MB usb key be fine?
<Keybuk> sivang: mom has one now
<Keybuk> https://launchpad.net/people/mom-ubuntu
<sivang> Keybuk: why does it need a launchpad account?
<Keybuk> so shean file bugs
<sivang> ah, right, cool
<Mithrandir> mgalvin: it'll work, but it'll naturally limit the size of the changes you can do.
<Keybuk> mom has a bugzilla account for the same reason
<sivang> Keybuk: I knew it had, didn't notice it's been filing merge bugs in bugzilla last time
<mgalvin> Mithrandir: right ok, cool, i'll give it a try in a bit and let you know how it goes :)
<Mithrandir> mgalvin: also, if you want to write some user docs, that'd be great, since I suck at that.  I can always document something along the lines of what I wrote above, but it's not exactly easy for non-techies to understand
<Yagisan> sorry for bothering, but I'm preparing a test patch to build 32bit compatibility packages for amd64, on i386, and wanted to know if it is ok to put -march=k8 in the cflags, or will the buildds have trouble with that ?
<ulaas> how can i force a cdrom eject
<ulaas> my dvd drive is eating my starwars disc
<Yagisan> ulaas: paperclip in the little hole ?
<ulaas> i hope to find an elegant solution :)
<Mithrandir> ulaas: eject /dev/hdc ?
<ulaas> well busy
<ulaas> ahhh there it spit it out
<mgalvin> Mithrandir: the first notes about it from me will be on DapperFlight3, i'll put together a seperate user level wiki page about it too
<ulaas> now there goes the second question. is there a way to fix a dvd which is not perfectly a "disc" shape.
<Mithrandir> mgalvin: thanks.  Feel free to Cc me if there's anything you want proofread
<dilinger> ulaas: scissors?
<mgalvin> Mithrandir: k, thanks
<Mithrandir> ulaas: turn down the speed of the DVD/CDROM drive
<ulaas> dilinger, well thats a last resort
<ulaas> Mithrandir, hmm that sounds like an idea
<ulaas> Mithrandir, commands?
<Mithrandir> setcd - Control the behaviour of your cdrom device
<Mithrandir> I'd guess
<dilinger> ulaas: machete?
<ulaas> dilinger, you are a warrior arent you? ;)
<dilinger> only with petulant dvds
<ulaas> dilinger, mine is like cone :) i wonder how did this got out QA.
<segfault> How the LiveCD will save its state? Create some file in the user's partition?
<ulaas> dilinger, i am gonna glue a blank cd on top of it. want to know the result?
<Kamion> segfault: usb stick
<segfault> humm, nice.
* Kamion climbs slowly over the squashfs live CD rsync hump
<ogra> lucky you ... my DSL is still glowing ...
<Kamion> so's mine, 20 minutes to go
<ogra> 1:20 
<Mithrandir> segfault: it needs a writable partition with the right label.  It can, in theory, be on anything (as long as the initramfs can see it)
<segfault> it wont erase the usb stick, right?
<Keybuk> brb reboot
* mvo goes to play hockey
<seb128> see you later mvo
<wasabi> http://chir.ag/stuff/sand/
<sivang> seb128: how was the swim?
<seb128> fine
<Mithrandir> segfault: no, it won't erase the usb stick, apart if you put something in directories the boot erases, like /var/run or /var/lock
<mako> i wanted to fix some errors on the website but my access seems to have not have carried over with the latest software transition.. who should i talk to?
<Burgwork> mako, hendrik (hno73)
<mako> Burgwork: i already thought of that.. i was hoping you'd say someone who was around :)
<mako> alright
<tseng> hi mako 
<mako> tseng: hola
<Burgwork> mako, afaik, there is nobody else with write access, including any doc team members (a bug that should be fixed)
<mako> Burgwork: who else should?
<mako> Burgwork: if you send me a list of uncontroversial additions, i can try to get a whole batch done with one motion :)
<Burgwork> mako, I haven't looked much because I know I can't edit it. Let me think about it.
<Burgwork> mako, I guess we really should redirect http://ubuntu.com/community/participate to https://wiki.ubuntu.com/HelpingUbuntu=
<mako> Burgwork: well, i'm going to do it anyway.. i'll put down you, mdke...
<mdke> o.o
<mako> Burgwork: or the other way around :)
<mako> the participate page is much larger
<Burgwork> mako, as long as someone can keep updating the participate page
<mako> but it should probably be in a wiki
<mako> well, that's exactluy the page i was trying to update :)
<Burgwork> mako, the objective was for Helping to be short and fix up the 2nd stage pages
<Burgwork> so that new people don't get bogged down in a lot of text and random things to do
* mako nods
<mdke> mako, elmo probably hands out website access, i would have thought
<mako> k
<Burgwork> mdke, I don't think so, because hendrik did the move over
<mdke> lemme see
<mdke> anyone with access to wikiconfig.py
<Znarl> mdke : I have access.
<siretart> elmo: please sync sdcv_0.4.1-1/unstable overriding ubuntu changes
<mdke> mako, ^^ Znarl is your man then :)
<mako> ok.. wait a second
<mdke> Znarl, can you do docteam svn accounts too?
<Znarl> mako : Please email rt@admin.canonical.com your access requests.
<ogra_ibook> Kamion, wow, you ripped out the annoying part from the partitioner :)
<slomo_> elmo: please sync gazpacho from debian/unstable... ubuntu changes can be dropped
<ogra_ibook> hmm, edubuntu ltsp building fails ... 
<ogra_ibook> Kamion, did something in debootstrap change ? i suddenly get an archive.ubuntu.com line in the client chroot without having network (which fails on CD only installs indeed)
<ogra_ibook> s/line/line in sources.list/
<Burgwork> infinity, can you pass with information to pitti, if you see him before I do? http://www.mozillazine.org/articles/article7895.html (regarding security patcches for FF 1.0.x  series)
<ogra_ibook> debootstrap (0.3.1.9ubuntu1) : * Create a default sources.list for apt. (Closes: Bug#283234, Bug#315225)
* ogra_ibook cries
<ogra_ibook> oh that was 0.3.2 ... wrong version ..
* \sh comforts ogra_ibook 
<lucas> *** MOTU meeting on #ubuntu-meeting NOW! ***
<mdke> elmo, Znarl, pretty pretty please can you expedite the docteam svn access request for LaserJock?
<mdke> anyone reproduce this: opening a file with "Open with Other Application" crashes nautilus. 100% reproducible here
<seb128> it's fixed since yesterday
<mdke> ah great
<seb128> update your libgnomevfs2-0 package
<mdke> thanks seb
<seb128> np
<ulaas> any issues with gamin?
<seb128> ulaas: what?
<seb128> the gnome-vfs bug?
<seb128> no an issue with the gnome-vfs inotify implementation
<ulaas> i got a dialog when i first launched in gnome session
<ulaas> pressed ok quickly by mistake
<ulaas> it was saying ssmthing about gamin/fam though
<ulaas> and i get nautilus crash whenever i rightclick-properties to follow size onf a downloading file.
<ulaas> hmm prbably thats what i have
<Riddell> Kamion,mdz: please promote kdnssd to main
<ogra_ibook> Kamion, same postgresql locale problem as with flight2 :(
<ds> has anyone brought up the idea of shipping debug symbols by default with ubuntu packages?  /me is getting tired of getting empty backtraces from users
<ogra_ibook> pitti, ^^^
* ogra_ibook tries a workstation install 
<pitti> ogra_ibook: hm, locales are all back into the 'locales' package
<pitti> ogra_ibook: so it seems that /etc/environment wants to use a locale that isn't installed?
<ogra_ibook> i have the same locales error
<pitti> ds: yes, indeed
<ogra_ibook> and postgres failing with the same eroor
<pitti> ds: we plan this since ages, but we never got round to actually implement it completely
<Burgwork> ds, would doing so increase the size of the download/archive?
<ogra_ibook> pitti, sorry, already trying the next install, i'll go for the prob details later 
<pitti> ds, Burgwork: https://wiki.ubuntu.com/AutomatedProblemReports, feel free to comment
<ds> Burgwork: not so much.  90% of the debug information I find useful is the name of the function in the backtrace, which is only a tiny fraction of the debug information
<ds> Burgwork: so my personal opinion is: put that info into every package, regardless
<ds> other info, like source files, line numbers, etc., is nice, but takes more bytes
<Burgwork> ds, ok, just wondered why they were not turned on by default. I seem to remember some sort of debian policy
<ds> it is
<lamont> seb128: pinbg
<seb128> lamont: ponbg
<lamont> any reason not to sync sid's pilot link?
<ogra_ibook> background communication :)
* lamont is testing it right now to see if it fixes his sync problem
<lamont> seb128: it's currently "merge needed"
<lamont> if we merged it, the only thing I see it possibly wanting is a Build-dep change from python (>=2.3) to python (>=2.4)
<lamont> which will happen automatically on the buildds
<seb128> I don't know, that's universe stuff
<seb128> ask a motu ... :)
<lamont> OTOH, it doesn't fix my sync problem though...
<lamont> pilot-link is main
<lamont> nfc why, figured it was for evo or something
<seb128> $ apt-cache show pilot-link | grep Filename
<seb128> Filename: pool/universe/p/pilot-link/pilot-link_0.11.8-17_i386.deb
<lamont> oh. hrm.
<crimsun> source is in main, though.
<seb128> libpisock8 is used for main
<lamont> seb128: doh.
<lamont> ok
<lamont> libpisock9 comes with the upgrade to current
<pitti> Burgwork: debian policy is to compile with -O2 -g, and strip debug symbols, unless you build a package with DEB_BUILD_OPTIONS=nostrip,noopt
<lamont> seb128: so source is main
<seb128> I don't know pilot-link and I don't have any device to play with that sorry
<seb128> right
<lamont> and out-of-date needs-merged
<lamont> I'm tempted to just have it sync'ed then...
<seb128> lamont: I'll have a look now, a min
<seb128> pitti: do you know what the IPP messages are defined?
<pitti> seb128: EPARSE
<seb128> for  "** (gnome-cups-manager:7075): WARNING **: IPP request failed with status 1030" by example
<seb128> what is 1030
<Burgwork> pitti, I am just reading a good thread between jdub and marilliat in 2002 regarding gnome2. It strikes me as insane optimization
<pitti> seb128: oh, I see; no, I'd have to debug it
<seb128> ok
<lamont> seb128: the specific issue is that resources > 64KB on the palm are (1) out of spec according to the palmos spec, (2) existant, and (3) require(d?) changes in pilot-link API to deal with the reality.
<seb128> API changes are not nice
<lamont> my Palm T|X being an example of something that doesn't believe that 64k should be the limit.  damn developers anyway.
<lamont> haven't looked, but given that the current package doesn't fix that problem, I'm betting that the API changes are still a bit out.
<lamont> seb128: in any case, we shouldn't ship breezy's pilot-link in favor of sid's without a good reason...
<seb128> lamont: current dapper version is the debian one
<lamont> sigh
<lamont> pkgs.debian.org is not talking, so I forgot about experimental.
<lamont> which must be where the others (prerelease all) live.
* dilinger pokes around at http://www.opensuse.org/AppArmor_Detail
<ogra_ibook> GAH
<ogra_ibook> wrong edubuntu-artwork version in the isos 
<fabbione> dilinger: that's the result of lazyness
<dilinger> fabbione: hm?
<fabbione> dilinger: clearly.. developers can't write code.. so let's make them even more lazy, creating a tool that will attempt to keep them secure
<fabbione> tsk
<dilinger> fabbione: nah, i like the concept
<fabbione> dilinger: nah.. developers should learn to write.. :P
<fabbione> hmmm
<fabbione> i am also a developer..
<fabbione> dilinger: when are you uploading that? ;)
<dilinger> i liked it in the st jude model, which had a learning mode and enforced exec() calls from one binary to another.. i liked it in grsecurity, w/ its acl checks , and i like it here
<Burgwork> dilinger, so apparmour solves the issue with selinux of needing to create a seperate policy for  everything?
<dilinger> i don't particularly like selinux
<dilinger> fabbione: i'm considering it
<dholbach> good night guys
<pitti> night dholbach 
<dholbach> night Martin
<dilinger> pitti: i'm curious if you've looked at it at all
<pitti> selinux?
<dilinger> pitti: app armor
* pitti only knows grsecurity
<pitti> dilinger: no, I didn't
<dilinger> see the opensuse link i posted
<Kamion> ogra_ibook: sorry, what annoying bit about the partitioner?
<Burgwork> pitti, http://www.mozillazine.org/articles/article7895.html (regarding security patcches for FF 1.0.x  series)
<ogra_ibook> Kamion, the part that asked "do you *really* not want to use the partitions you marked not to be used" :)
<Kamion> ogra_ibook: I don't think that's changed; perhaps you did something different with the combination of the use method and the mount point
<Kamion> Riddell: kdnssd promoted
<Riddell> Kamion: thanks
<ogra_ibook> nope
<ogra_ibook> i always had it in breezy
<pitti> dilinger: heh, this indeed reminds me of the grsecurity policies, although these were mightier
<ogra_ibook> i always have at least 2 partitions i mark "dont use"
<pitti> Burgwork: cool, that means that upstream supports 1.0.x as long as we support it in Breezy :)
<pitti> Burgwork: thanks for the link
<Burgwork> pitti, np
<pitti> Burgwork: or, wait, do they mean 'from last November'? hmm
<Kamion> ogra_ibook: you don't need to mark partitions explicitly to make them not be used
<Burgwork> pitti, I think they mean 2005, which means your hosed I'm afraid
<Kamion> you only need to say "keep and use existing data" if you want to assign it a mount point as well
<pitti> shit
<Kamion> that's what the partitioner was complaining about; you said "keep and use" without a mount point
<Kamion> (without proof, but I'm fairly sure)
<pitti> dilinger: looks nice, though, as an LSM it's easier to support
<ogra_ibook> it doesnt anymore
<ogra_ibook> Kamion, but much worse, i have the return of the locales bug here :(
<Kamion> ok, wasn't me who changed it
<ogra_ibook> and the edubuntu-artwork package is -11
<Kamion> ogra_ibook: I need to go do other things right now, but could you put /var/log/syslog from the installer somewhere I can get it?
<ogra_ibook> (should be -14) i wonder how that happened
<Burgwork> pitti, you realize that 6 months means both breezy and hoary, no?
<Kamion> old install CD?
<ogra_ibook> Kamion, will do... first i'll finish the tests ... workstation install x86 is fine already
<pitti> Burgwork: Yes, I'm looking forward to tell mdz that we need to put 1.5 into hoary :/
<ogra_ibook> i download /current/ ....
* ogra_ibook looks at the link
<Kamion> I've turned off the cdimage cron jobs for now, BTW, but I'm rebuilding kubuntu/install and edubuntu/install by hand now
<Burgwork> pitti, lets just say I don't envy your job right now
<Riddell> Kamion: can you wait until I update kubuntu-meta?
<Kamion> Riddell: no, too late
<Kamion> Riddell: I can certainly rebuild later, though
<Riddell> ok
<Kamion> ogra_ibook: I did try to adapt localechooser for the new locale-gen syntax, but it's possible I got it wrong, and I'm afraid I didn't test that change much
<ogra_ibook> i'll look into it ...
<Kamion> log-output -t localechooser chroot /target /usr/sbin/locale-gen "$LOCALE"
<Kamion> log-output -t localechooser chroot /target /usr/sbin/locale-gen $EXTRAS
<Kamion> it just does that now
<ogra_ibook> currently i'm just runnnig through the testcycle once
<ogra_ibook> later i'll revisit the noted bugs
<mdz> pitti: ...
<Riddell> Kamion: I made a bunch of changes to the language packs in kubuntu ship today but kubuntu-meta isn't picking them up, any idea why?
<Kamion> there's no metapackage for ship
<Kamion> and no need for one
<Riddell> aah, of course
<pitti> mdz: nevermind, I'm sure that fabbione has some Sizilian friends who can convince the mozilla guys to support it until 2007 :)
<fabbione> pitti: what do i need to do my friend... you know that i can do everything for you
<ogra_ibook> fabbione, send some people to mozilla foundation headquaters :)
<pitti> fabbione: in http://www.mozillazine.org/articles/article7895.html, we need to do s/6 months/18 months/ :)
<sistpoty> mdz: do you have orphaned mythplugins/should I set the maintainer to a motu-team on next upload?
<mdz> sistpoty: I'm hoping that the packages will be adopted by someone; I can't maintain them anymore
<mdz> I don't use mythtv
<mdz> due to not watching television anymore
<sistpoty> mdz: ok, then I'll set maintainership to motumedia, if you don't disagree with that ;)
<Burgwork> mdke, no time or no interest?
<mdz> sistpoty: sounds good
<fabbione> sistpoty: you better be sure that package will work REALLY well
<mdz> Burgwork: both
<sistpoty> k, thx 
<sistpoty> fabbione: he, I'm just touching mythplugins... crimsun is the one to blame for mythtv soon ;)
<fabbione> sistpoty: because i use it.. and if it breaks you can ask slomo.. i can become unpleaseant when i can't watch dvd/tv
<fabbione> :)
<sistpoty> hehe
* sistpoty better tests thoroughly
<mdz> Burgwork: I used to use mythtv regularly, and so created the packages and maintained them for some time.  however I have since cancelled my cable TV service and have no real use for it anymore, even if I had time to spend on the packages
<mdz> fabbione: maybe you want to become the new maintainer?
<fabbione> mdz: no no.. i prefer to use the cluebat on MOTU's.. it's more fun :)
<fabbione> mdz: more seriously.. i use it as a user.. i don't want to become the slave of my dvd player
<fabbione> otherwise i will be soon maintaing 3/4 of Ubuntu myself :)
<fabbione> sistpoty: but i will take notes .... slomo -> xine, crimsun -> mythtv, you the plugins..
* sistpoty hides behind slomo and crimsun
<sistpoty> *g+
<fabbione> sistpoty: speaking of which... there is at least mythphone and another plugin that are in the source, but compiled/installed/shipper
<fabbione> shipped
<fabbione> plan to fix it?
* fabbione switch to real bitching mode :P
<sistpoty> fabbione: I'm planning/having a fix already which makes the individual myth* go away and build all from mythplugins (as it's done upstream wise)
<ogra_ibook> mdz, debootstrap installs a default sources list now ... which breaks the building of the thin clients on install 
<Kamion> my inclination there is that ltsp should trash the sources.list if that's appropriate for it
<Kamion> I think debootstrap's new behaviour is better in the common case
<Kamion> it used to be very annoying that it didn't set up a sources.list for you
<fabbione> sistpoty: mythplugins is already in multiverse, packaged that way
<ogra_ibook> Kamion, mdz, thats what i wanted to ask :) 
<fabbione> sistpoty: you need to build mythphone and the other one i can't remember.. and package them.
<fabbione> sistpoty: the source is tehre already
<ogra_ibook> Kamion, the other option would have been to add an option to debootstrap
<ogra_ibook> (to supress the default sources.list)
<sistpoty> fabbione: as I wrote, I alread have a fix at hand which does this ;)... but I'll test it again and upload then
<fabbione> ok
<hile> any kernel packagers? I just filed a trivial bug for 2.6.15-x kernels, #22351 
<hile> just wanted to ask if there is any reason _not_ set number of UARTs from 4 to 8 (see bug for details)
<Kamion> ogra_ibook: I guess that's possible
<Kamion> but I'd need to talk with aj to make sure we pick the same option name as Debian; for now I recommend hacking it in ltsp somewhere, I think
<hile> and btw, anyone using encrypted root filesystems, I've got new initramfs-cryptsetup package ready (still not yet in repositories, just in http://ner.dy.fi/deb/ - read sources and build from scratch, it's quite trivial)
<ogra_ibook> Kamion, yes, but i dont think anybody else benefits from such an option in debootstrap and a simple rm in ltsp-client-builder will do as well
<ogra_ibook> so i'll go this path if mdz doesnt object
<lamont> daniels: ping
<Kamion> right
<crimsun> hile: redirect to #ubuntu-kernel
<hile> oh, there's such channel as well
<ogra_ibook> mdz, any objection to add a rm for the sources.list to ltsp-build-client ? 
<mdz> ogra_ibook: why does a pre-existing sources.list break it?
<mdz> I thought it installed its own sources.list anyway
<ogra_ibook> mdz, because on non networked machines you have the default archive.ubuntu.com entry
<mdz> ltsp-build-client should be creating a fresh sources.list without regard for whether one exists
<ogra_ibook> mdz, yes, it did, until deboostrap started shipping and installing one by default :)
<ogra_ibook> it does
<mdz> ...
<ogra_ibook> and deboostrap adds archive.ubuntu.com to it
<pitti> ogra_ibook: oh, interesting, since when? my last created chroot had an empty one
<mdz> ltsp-build-client creates sources.list after debootstrap runs
<ogra_ibook> in front of the cdrom entry
<ogra_ibook> (in the installer)
<ogra_ibook> mdz, then its the opposite and ltsp-build client just adds its entry ... i'll inspect that further, but are you ok with just wiping the one from deboostrap instead of adding a suppression option to deboostrap ?
<mdz> yes, that's how I'm pretty sure I originally wrote it
<mdz> unless I typod >> for >
<ogra_ibook> i'll look at it later 
<ogra_ibook> currently all machines are running test install here :)(
<ogra_ibook> pitti, in 0.3.2 this was added
<ogra_ibook> i never noticed it before ... since i built my chroots on connected machines ...
#ubuntu-devel 2006-01-18
<mdz> ogra_ibook: around?
<ogra_ibook> sure 
<jdub> http://jon.oxer.com.au//blog/id/79
<Burgwork> jdub, that makes about 8 books underway or published
<seb128> is there a page with the books listed?
<Burgwork> not currently but I can make one
<seb128> do you have the new Eyrolles one on your list? 
<tseng> Burgwork: is ubuntu hacks in the oreilly hacks series?
<tseng> ah, it is
<Burgwork> https://wiki.ubuntu.com/UbuntuBooks
<seb128> it's listed
<jdub> i didn't realise that annoying french guy wrote a version of his "moving to..." book about ubuntu
<seb128> is "annoying" something you put automatically before "french guy"? :p
<jdub> seb128: no, in this case he really is
<jdub> marcel gagne
<jdub> he abuses his frenchness
<seb128> I you say so, I don't know him
<seb128> ah
<jdub> to give you an impression
<jdub> his articles are all about bad food and wine metaphors to linux/foss
<jdub> and he throws in a bunch of french about as usefully as i did at montreal
<seb128> I see :)
<HrdwrBoB> not just bad, terrible
<jdub> aww haw haw! je ne sais pas! madamoiselle! oui oui!
<jdub> seb128: dude, i'm going to be doing spanish lessons. :-)
<seb128> un vrai abruti :p
* seb128 runs
<jdub> haha
<seb128> jdub: need them for next Ubuntu tour?
<jdub> seb128: one of the girls up the hallway is a tastefully well-endowed uruguayan, who we'll be having "group sessions" with.
<jdub> ;-)
<seb128> jdub: btw are you going to the distro team week coming?
<seb128> rofl
<jdub> seb128: nup
<seb128> :(
<seb128> but you come at fosdem right?
<jdub> yup!
<seb128> ah, nice :)
<psusi> anyone ever debug a coredump from a multithreaded program?  I was trying to do that today and gdb was showing complete nonsense for the register content of the other threads
<lifeless> psusi: if its a single cpu machine, only one thread can have register contents
<lifeless> the rest will be in process control blocks
<lifeless> (I forget the exact linux term)
<psusi> well, yea, they are't in real hardware registers, but gdb knows that and should be getting them from the thread control block where they are stored
<psusi> hell, the registers for the thread that crashed aren't in real hardware registers either... they are in the coredump file ;)
<psusi> so I'm thinking that I am missing something obvious you need to do to get gdb to understand the multithreaded coredump right, or get the process to generate a correct multithreaded coredump
<TheMuso> c
<jdub> http://raw-output.org/20060113/solutions
<jcape> heh
<Amaranth> http://raw-output.org/20051103/the-real-threat-for-debian is funnier :)
<lifeless> they spelt it wrong
<lifeless> its 'grumpy'
<tseng> that post is months old
<Riddell> mdz: please promote to main cdrdao (http://wiki.kubuntu.org/MainInclusionReportCdrdao), ttf-arphic-uming (http://wiki.kubuntu.org/MainInclusionReportTtfarphicuming), ttf-arphic-ukai (http://wiki.kubuntu.org/MainInclusionReportTtfarphicukai)
<jsgotangco> Amaranth, i really like gentu heh
<mdz> Riddell: did pitti approve the reports already?
<Riddell> mdz: yes
<mdz> Riddell: cdrdao is already in main
<mdz> though it build-depends on pccts, which is not in main
<mdz> pccts doesn't seem to have a report yet 
<mdz> promoted the font packages
<Riddell> oops, sorry, will look into that
<lucasd> will dapper have support to winmodens?
<Amaranth> some
<Amaranth> no conexant or whatever the name is though
<Amaranth> which seems to be the most common
<lucasd> hm, I see..
<lucasd> just that one?
<Amaranth> no
<Amaranth> lots
<Amaranth> only a couple of others work that didn't in breezy
<lucasd> hmmm
<Amaranth> there was a thread on u-d about it awhile ago
<lucasd> I'll look for it
<lucasd> thanks ;)
<infinity> I may or may not try to get slmodem support into dapper, depending on how much effort it turns out to be.
<infinity> But at least we got ltmodem in, which seems to make some people happy.
<infinity> (Or, rather, not having it in breezy made some people angry, so I'm assuming they're now happy)
<lucasd> hehe
<desrt> is hal-device-manager broken for everyone right now (dapper)?
<Riddell> mdz: please promote kthesaurus to main, part of koffice
<jamesh> bugzilla migration day today
<jsgotangco> weee
<Lathiat> jamesh: fun :)
<daniels> jamesh: hoorah
<daniels> mdz: does malone mean the death of debzilla?
<jamesh> daniels: we'll be working on a debzilla equivalent
<daniels> jamesh: phat, thanks
<daniels> also, in other news, accelerated indirect support just got committed to xserver/xorg CVS
<Burgundavia> daniels, what does that mean in practical terms?
<jamesh> Burgundavia: accelerated OpenGL for remote programs, for one.
<daniels> right
<Lathiat> daniels: is there an open bug about ALPS touchpads slowing down again?
<Lathiat>  / known ?
<jdub> daniels: did you see my xorg logs? still don't have touchpad love
<daniels> Lathiat: yes
<daniels> jdub: yes, they're flagged
<Lathiat> daniels: known or bug? if bug, url?
<jdub> daniels: thanks
<daniels> Lathiat: bug, don't have it offhand, sorry
<daniels> Lathiat: basically the solution is to multiply your accel factor by 1.5 (IIRC)
<Lathiat> yeh i did up some custom attributed in xorg.conf
<daniels> actually, hm
<daniels> jdub: can you please resend or put them up quickly?
<floam> Burgundavia: man, I don't think I could disagree with you more over the walkman thing. The mail I was replying to was commenting on how the walkman had you hold two buttons down at once to pause it.
<floam> I don't think anything on a physical device should translate into a GNOME music player UI
<Burgundavia> floam, I am not saying replicate the whole UI. I am saying that those bits which work and keep them
<floam> I assume you got my reply and the comment about gnome-cd
<Burgundavia> yes I did
<floam> which does a pretty good emulation of a physical CD player
<jdub> daniels: hrm
<Burgundavia> actually, gnome-cd fits into the "later and crappier" cd players I was talking about
<daniels> jdub: i thought it was an email, but I can't seem to find it now
<floam> the walkman never played cds
<Burgundavia> floam, media player then
<daniels> floam: actually, the discman and md lines were rebranded to walkman
<floam> the walkman "ui" wouldn't work too well for anything with tracks, I don't think
<jdub> daniels: 'twas
<Burgundavia> floam, a singel big button is great
<floam> daniels: oh, really?
<daniels> floam: indeed
<floam> Burgundavia: I agree
<daniels> jdub: yeah, what I have from you is ati and fglrx, not touchpad
<Burgundavia> floam, that is the functionality I was talking about regarding a walkman, not lots of buttons the same size
<jdub> daniels: oh, you want logs of the two different drivers? neither work
<floam> Burgundavia: I thought the discussion was going on about the label changing?
<Burgundavia> floam, that was part of it
<floam> and then a guy brought up that a label (obviously) can't change on a walkman, which toggles in
<daniels> jdub: i already have logs from both ati and fglrx from you, but nothing about touchpads ;) got xserver-xorg-input-synaptics installed? (i.e. not xorg-driver-synaptics)
<Burgundavia> floam, that is a restriction of the format (a piece of plastic)
<floam> and I think that basing your UI on the limitations of a plastic player, even if correct in one situation, is a sort of bad thing to begin doing often
<floam> Burgundavia: absolutely
<jdub> daniels: yeah
<Burgundavia> floam, that is not what i am saying. I am saying lets look at what works on physical media players and see if they can be applied to Muine.
<floam> Burgundavia: sure.
<Burgundavia> floam, sorry if I was not clear. Anyway, we should stop filling the logs on this channel
<floam> Burgundavia: I was really commenting on that guy and his one situation
<floam> Burgundavia: it seemed to me in your email that you wanted to use the walkman as the ultimate GNOME UI for a music player for all circumstances, which sort of worried me
<floam> perhaps I read it too quickly
<Burgundavia> floam, likely I was not complete enough in my explanation
<floam> log filling done
<floam> :)
<Burgundavia> jdub, would you call Xubuntu a partner project ala Kubuntu and Edubuntu?
<jdub> Burgundavia: well, not really
<jdub> mostly
<jdub> but not in an officialish kind of support way
<Burgundavia> jdub, I am writing a piece of partner projects and derived distros and am thus stuck with Xubuntu. It sort of falls into the middle
<jsgotangco> "community" partner?
<Burgundavia> ick
<infinity> It's developed and integrated in the same way (ie: hosted entirely in the Ubuntu archive), but maintained entirely by volunteers and not supported by Canonical.
<jsgotangco> the base is supported but not the de
<jsgotangco> heh
<jdub> Burgundavia: 'community supported ubuntu derivative'
<infinity> That works.
<infinity> jsgotangco: You take away the desktop and you don't have Xubuntu anymore, you have Ubuntu, so the distinction of what is and isn't supported is a bit meaningless. :)
<Burgundavia> jdub, but that wording could also apply to Nexenta and nUbuntu
<jdub> Burgundavia: indeed, that is its beauty
<jsgotangco> one term to rule them all?
<jsgotangco> heh
<Burgundavia> jdub, but Nexenta has a company behind it and Guadelinex has a government
<infinity> Okay, this kernel bug has finally irritated me enough to figure it out.
<infinity> Having music skip when I'm compiling is unacceptable.
<jdub> Burgundavia: so simplify
<Burgundavia> jdub, classify it as simply an Ubuntu derivative?
<jdub> sure
<infinity> Where the files are hosted may be technically relevant, but doesn't really matter to end users.
<infinity> So, a derivative is a derviative, regardless of where they download it from.
<Burgundavia> jdub, the other issue is that xubuntu.org redirects to ubuntu.com
<jdub> Burgundavia: i figure the admins will fix that when the xubuntu dudes are ready
<Burgundavia> jdub, ok. <troll>will we fix it for the utubnu people too?</troll>
<jdub> i dunno, nor do i know if they've requested it
<fabbione> morning
<floam> hm
<floam> it seems like some change in GTK recently made my filechooser default to my ~/Documents dir. Is there a way to set the default? gconf?
<floam> in dapper, last few days
<Burgundavia> floam, see the thread on -desktop
<Burgundavia> sadly that is currrently hardcoded I believe
<floam> oh, maybe not
<floam> http://lists.ubuntu.com/archives/dapper-changes/2006-January/004624.html
<floam> if GTK_DEFAULT_FILECHOOSE_DIR can be set in the environment
<floam> ... which it can't.
* infinity does the "I think I found the stupid bug" dance.
<infinity> Or, at least, found another bug, and it may be the last one...
* infinity does more glibc test builds and prays.
<jamesstansell> is the progress on the conversion from bugzilla to malone being tracked anywhere?
<ajmitch> morning pitti 
<pitti> Hi ajmitch
<pitti> good morning
<desrt> pitti is here.
<Tm_T> oh, what a pitti
<desrt> pitti; will you be merging any new hal versions for dapper?
<Tm_T> errr pity
<Tm_T> ;)
<desrt> pitti; wb, G.
<pitti> one crash later...good morning take #2
<pitti> hi desrt 
<desrt> my question: will you be merging a new hal version for dapper?
<pitti> desrt: I hope that 0.5.6 will come out soon enough
<pitti> desrt: Friday 19th is UVF
<desrt> nod.
<pitti> on the list it sounded as if it could make it earlier
<desrt> 19th is thursday
<desrt> i saw you on the hal list kicking ass
<desrt> <hal> we don't have bugs!! if we do, prove it!!
<desrt> <martin> uh.  that took about 5 seconds and grep.
<fabbione> ehehhe
<fabbione> pitti: you rock dude
<pitti> heh
<desrt> fabbione; be careful about what USB keys you go plugging into your ubuntu system.  some of them can crash hald :)
* pitti does the linux distro quiz: debian, kubuntu, ubuntu
<pitti> desrt: usually you can exploit these kind of bugs to execute arbitrary code, too
<fabbione> desrt: fix hald :)
<desrt> pitti; right.  any sort of buffer smashing....
<desrt> pitti; are our stacks executable?
<pitti> fabbione: well, my main point is to keep it as confined as it is ATM, then I don't care so much about these bugs
<desrt> pitti; you really substantially improve your position with non-executable stacks
<pitti> desrt: yes, but that one was a heap overflow
<desrt> ah
* desrt read alloca() for some reason
<pitti> desrt: I'm aware of that, and I so much look forward to switch to gcc 4.1 with ssp/fortify
<Yagisan> pitti: me too
<pitti> desrt: nonexecutable stack always requires external patches, a bit tricky to get that approved for main
<Yagisan> pitti: oh, and G'day :)
<desrt> pitti; or cpu support
<pitti> desrt: that's why grsec rocks so much, one patch to cover it all :)
<fabbione> pitti: gcc-4.1 will have ssp/fortify upstream?
<pitti> hey Yagisan 
<pitti> fabbione: s/will have/has for a while/
<pitti> fabbione: yes, finally
<fabbione> pitti: ok :)
<Yagisan> fabbione: their own version (non-ibm developed) yes
<Yagisan> pitti: will it be on by default when ready ?
<fabbione> i wonder how bad is going to break on non i386 arches
<Yagisan> fabbione: not much it seems amd64 has 0 performance impact from it. pitti, do you remember if the ibm ssp patch broke on non-i386 ? I don't think it did
* desrt watches pitti upload gcc 4.1 cvs to main
<pitti> Yagisan: even if it's not on by default upstream, I will fight for enabling it in Ubuntu :)
<Yagisan> fabbione: i386 gets a small performance hit, because of lack of registers, other should be ok
<pitti> Yagisan: I didn't hear stories about breakage; also, SSP is so old and proven, I don't expect many problems
<Yagisan> pitti: please please do. Fight hard
<pitti> it's not that this would be an innovation, several other distros use it for literally years
<fabbione> Yagisan: i am not worried about performances.. really..
<ajmitch> pitti: it will really be a good improvement in dapper+1
<pitti> yes, it was rejected for dapper due to its long support cycle
<pitti> but then it's time to rock the house again :)
<Yagisan> :( boo
<ajmitch> :)
<ajmitch> Yagisan: it's hard to put something new & untested in dapper though
<Yagisan> ajmitch: this reminds me of when I had this discussion for breezy ....
<ajmitch> Yagisan: I know..
<ajmitch> I would have liked 4.1 to be ready & tested so we could trust dapper with it
<Yagisan> ajmitch: universe ?
<ajmitch> there's been no 4.1 release that I've seen
<mdke> mako, any chance of pushing through my mail to -news from a couple of weeks back?
<Yagisan> ajmitch: I like to call it cvs ;) but this should really be on by default - esp for servers, firewalls, it's a good selling point.
<pitti> hi doko 
<doko> pitti: good morning
<ajmitch> Yagisan: sure, that's what I would like ;)
<ajmitch> morning doko 
<Yagisan> G'day doko
* ajmitch wonders if doko's irc client was highlighting on gcc :)
<Yagisan> ajmitch, pitti - so after ssp, pax or similar next ? 
<doko> ajmitch: only if ssp doesn't match in a ten line context :)
<pitti> Yagisan: I for my part love PaX; there was a lot of bitching about exec-shield, but I'm no expert to say for myself whether that's justified
<pitti> Yagisan: what do you say? You should be an expert :)
<Yagisan> pitti: pax is technically better, but lags kernel releases. Will never go upstream
<ajmitch> doko: nearly all universe zope packages have been requested as syncs now, so we have little deviation - just some debian packages that don't use zope-debhelper still :)
<Yagisan> pitti: execsheild is pushed by red had
<pitti> Yagisan: will any stack protection go upstrem? it's high time for sth like this IMHO
<Yagisan> pitti: they also maintain glibc - so they pushed it in
<ajmitch> Yagisan: reminds me of the discussion in sydney :)
<Yagisan> pitti, ajmitch: exec sheild will get in, because red hat pushes it, and has already begun digging it into glibc, not because it is better, but because they have more kernel and glibc hackers
<Yagisan> pitti, ajmitch: and there will continue to be pax vs exec sheild flames
<ajmitch> and PaX lost a fair bit of momentum with that hole that was discovered, and that no mainstream distro carries it as default
<Yagisan> ajmitch: exec sheild also has been discovered to not provide as much protection - diff is pax was more upfront
<pitti> hm, sad
<pitti> and exec-shield cannot be improved?
<Yagisan> ajmitch, pitti: that particular pax issue only effected i586 and earlier boxes
<Yagisan> pitti: it's a design issue :(
<ajmitch> Yagisan: sure, but it didn't help them much
<ajmitch> the technically superior design is often not the one that succeeds
<Yagisan> ajmitch: I know - that's why there is windows :(
<Yagisan> bbl - bye all
<ajmitch> see you later
<StevenK> Right.
<StevenK> Finally got moin sorted out.
* StevenK was evil, and decided to package 1.5.0 before Debian did.
<ajmitch> great
<mdke> what installation method does it use?
<ajmitch> StevenK: you probably got my nag email then :)
* mdke has never tried installing moin via a package
<StevenK> mdke: It just stuffs everything underneath /usr/share/moin. It up to you to copy it out to the moin's.
<StevenK> 1.5.0 is way slicker.
<mdke> what about the webserver?
<StevenK> The config of the webserver is up to you too.
<mdke> ok
<Keybuk> Today is Rex Manning^W^WMalone Day?
<pitti> quick, seb128, fix all your bugs before you have to deal with them in malone :)
* pitti -> breakfast
* Mez doesnt like the way malone lists bugs
<Burgundavia> Mez, you are not the only one. It is something I have seen nearly every bug reporter/triager complain about
<Mez> Burgundavia, I remember it being bitched about at UBZ lol - I think by Scott ...
<Mez> lol - it's very annoying and i hope moving bugzilla to malone will make people realise it's horrible
<Mez> bring back the old way
<Burgundavia> you could actually sort the columns on the fly in the old table
<Burgundavia> I told bradb exactly why the new layout sucked at UBZ
<Mez> I know :'(
<Mez> because you cant get any information out of it quickly ?
<Mez> ok, it looks "purdy" but it's not useful
<Burgundavia> it expect malone to move quickly once the distro team starts using it
<Keybuk> Burgundavia: the plan is to tie bradb to a chair, and force him to code at gunpoint
<Keybuk> without the luxury of the girl in his lap, either
<fabbione> ehehe
<Mez> Keybuk - wouldnt it be very hard to code with a girl in your lap ?
<Burgundavia> Keybuk, can I help buy the ropes? I might start doing bug triage again
<Keybuk> tsk, clearly Mez has never seen Swordfish
<Mithrandir> uhm, I'm apparently clueless.  How do I close a bug in malone?
<Mithrandir> oh, I could click the status.
<Mithrandir> it's _obvious_ that orange stuff is a link
<Mithrandir> *sigh*
<Keybuk> yeah, great isn't it
<Keybuk> that's a Markism
<ajmitch> at least the UI *probably* won't radically change every 2-3 weeks now
<Keybuk> ajmitch: HAHAHAHAHAHAHAHAHAHA
<Keybuk> ;)
<ajmitch> I know, I shouldn't be an optimist
<Burgundavia> oh and orange on orange is a great way to display text
<jamesh> ajmitch: it hasn't radically changed in a long time
<ajmitch> jamesh: certain parts of launchpad have changed a bit in confusing ways recently
<Mithrandir> Keybuk: I'm considering just writing xml-rpc helpers and custom stylesheets for stuff I actually want to do.
<jamesh> Mithrandir: and it looks like mpt has just made a commit to make the unconfirmed status text easier to read
<StevenK> Yes, like the statuses of bugs.
<Mithrandir> jamesh: well, I would like something like "edit bug" or "change status" or something in the list of actions on the right hand side.
<jamesh> Mithrandir: sure.
<jamesh> Mithrandir: it would probably be in the table though: you can have multiple rows in that "fix requested in" table.
<pitti> ajmitch: heh, I for my part hope that the UI will change soon, to make it a smaller clickfest
<ajmitch> pitti: as long as I don't spend 10 minutes trying to figure out what to click :)
<Keybuk> Mithrandir: heh, it's not that bad once you get used to it
<jamesh> Mithrandir: we'll probably have RDF dumps of bug info at some point, which could help.
<Keybuk> it's certainly no worse than, e.g. Bugzilla
<Keybuk> but it's no debbugs
<jamesh> thank god it's no debbugs.
<Mithrandir> Keybuk: but bugzilla is really, really bad. :-)
<Mithrandir> jamesh: debbugs is _excellent_ from the developer's point of view.
<jamesh> Mithrandir: don't worry.  I just had bad experiences with older versions of debbugs.
<hunger> Keybuk: It takes a lot of getting used to though.
<Keybuk> hunger: so does Bugzilla :-/
<jamesh> Mithrandir: we used to use it for Gnome
<Mithrandir> hunger: well.. I don't care if it takes time to get used to, when I'm going to spend half my time trawling through it.
<Keybuk> jamesh: to be fair, the version you used for gnome was ancient and not even set up properly!
<hunger> Keybuk: Bugzilla is *WAY* less confusing.
<Burgundavia> Mithrandir, an awful to quickly parse information in the web interface
* Keybuk hates Bugzilla with a passion
<jamesh> bugzilla pages seem to take a lot longer to load compared to Launchpad bug pages for me.
<hunger> Keybuk: That following the bug link takes me to different places depending on where I started keeps confusing me without end.
<jamesh> (for bugzilla.ubuntu.com, that is)
<Keybuk> Malone's editing sucks right now though
<Keybuk> it needs an edit-everything-in-one-place makeover, preferably with edit-and-read-everything-in-one-place
* hunger agrees with Keybuk.
<Burgundavia> currently the bugzilla list view kicks the crap out of malones
<Keybuk> yeah that needs to be improved too
<Burgundavia> the old way was much better
<Burgundavia> with the sortable tables, one bug per one line
<StevenK> mv #ubuntu-devel #beat-on-malone
<Keybuk> the trouble with the sortables in Malone is they got way too big
<Burgundavia> you know what is really really sad. I (and others) have been saying this for ages and *nothing* has been done
<Keybuk> you needed an ultra-high-res widescreen laptop to read them
<Burgundavia> Keybuk, the final version before they canned it wasn't bad
<Keybuk> Burgundavia: that's sadly a general lp problem, it takes a long time to persuade the developers that they're wrong and the users are right :D
<Keybuk> and then a few months later, they change it back anyway <g>
<Keybuk> and you had to beat them up
<Keybuk> like bradb trying to break the e-mails again <g>
<Burgundavia> I remember the instant that tables change happening, ajmitch, myself and others bitching out the lp devs about it
* StevenK wonders who he needs to tie to a chair and threaten at gunpoint to get his @u.c e-mail address working.
<Burgundavia> I think lp is great, it just need serious UI work
<hunger> Burgundavia: So far I only saw the UI and did not like it a bit.
<Keybuk> Burgundavia: yeah, jbailey and I had fun at UBZ with the UI ... it's improved a bit since then
<Keybuk> the navigation almost makes some sense now
<Keybuk> though the pages still feel sqashed
<Burgundavia> Keybuk, I was there when you presented your idea. I liked it
<hunger> Burgundavia: Try viewing it in IE for the full viewing fun.
<Keybuk> Burgundavia: though you're not always right ;)  you're wrong about how e-mails should be sent, for example
<Burgundavia> Keybuk, I never pretend to be always right. I simply argue what I think is best
<Keybuk> :p
<Burgundavia> Keybuk, at least the emailing doesn't break threads like it used to
<jamesh> we do need to get some of the mailing list configs fixed to work with LP emails though
* vurdak is away: I'm currently away, please leave a message
<Burgundavia> jamesh, is there a "high priority, must fix because otherwise the distro team will kill us" bug list?
<Keybuk> jamesh: will Malone send all "main" package bugs to the ubuntu-bugs list?
<jamesh> Keybuk: that's something that needs to be fixed up.  We don't have a "distro component bug contact" idea.  Just initial contacts for packages, products and distributions
<jamesh> Keybuk: Burgundavia there is a 1.1 milestone for stuff we want to get fixed soon.  It would be good to bring up the requests on #launchpad or launchpad-users
<Burgundavia> jamesh, ok
<Burgundavia> jamesh, https://launchpad.net/products/malone/+milestone/1.1/+index
<Burgundavia> ^ should I have access to that page?
<jamesh> Burgundavia: weird.
<jamesh> Burgundavia: sounds like an issue with private bugs
<Burgundavia> jamesh, hmm, ugly
<Kamion> StevenK: AIUI all new @u.c e-mails are broken at the moment due to some script having broken due to a launchpad change; James said he'd rather fix the script than fix individual people's addresses
<dholbach> good morning
<jsgotangco> dholbach!
<Burgundavia> dholbach, you saying good morning means it is way too late for me to be up. Night all
<pitti> night Burgundavia 
<dholbach> night Burgundavia
<dholbach> hey jsgotangco
<jsgotangco> night
<jamesh> Kamion: the problem was with people setting their preferred email address in LP to an @u.c address
<jamesh> Kamion: which is a problem if the @u.c addresses were acting as redirects to the user's preferred address in LP
<Mithrandir> dholbach: any idea about 16216?  It's not a locales issue.
<dholbach> Mithrandir: we have a bunch of those, and to be honest: i have no idea what goes wrong
<Mithrandir> dholbach: it appears to be a bug in the calendar control, since I can reproduce it using glade.
<dholbach> Mithrandir: let me try to find the bug where upstream told us it was no g* bug :)
<Mithrandir> dholbach: please do
<Mithrandir> hmm, apparently, our locales are broken in that respect
<Mithrandir> dholbach: 87977 might be the bug
<Kamion> jamesh: right ...
<dholbach> Mithrandir: oh yeah, looks good - most upstream 'week' bugs for gtk seem to be resolved as DUP or NOTABUG :)
<Mithrandir> dholbach: but then, I'm utterly unable to actually change the day the week starts on.
<dholbach> Mithrandir: i suggest we try to talk to mclasen in #gtk+ on gimpnet - he will know what we have to look out for.
<Kamion> argh, kernel ABI bump
<Kamion> now I have to rebuild d-i and all CD images before flight 3 :(
<highvoltage> yay
<Kamion> hmm, mind you, it's all in NEW ...
<Kamion> elmo: please defer NEWage of the kernel ABI bump for a while, thanks
<Mithrandir> grr, you can't regenerate a locale, it seems.
<fabbione> Kamion: meh.. i need the new kernel today :(
<Mithrandir> pitti: around?
<Kamion> fabbione: you can have it later; I need the new kernel not now
<Mithrandir> pitti: can I blame you for line 77 through 80 in locale-gen? :-)
<fabbione> Kamion: you do.. there is a very important fix for amd64.. 
<Kamion> fabbione: you all suck :P
<fabbione> Kamion: and we do it good!
<Kamion> what breaks?
<fabbione> the old one has severe I/O issues because the SMP2UP patch was not applied properly
<fabbione> in some cases it just dies
<Kamion> damn it
<Kamion> elmo: belay that
<Kamion> I still hate you all
<fabbione> Kamion: we do love you :P
<fabbione> really
<Kamion> as penance you can test CD images for me when they're rebuilt
* jsgotangco chants flight 3 flight 3 flight 3...
* jsgotangco hides
<fabbione> Kamion: at what time do you expect to have them done?
<fabbione> Kamion: i really can help test them.. but i would like to plan some sleeping activities too :)
<fabbione> i am dead tired today
<Kamion> well, sure, I'd like some sleep too
<Kamion> dunno, a few hours
<fabbione> ok
<Nafallo> fabbione: ehrm. that means my computer will stop sometime later today? if you fixed it you will get the largest HUG in history :-)
<Nafallo> ehrm, will stop freezing even :-P
<fabbione> Nafallo: it should.. yes
<Nafallo> yay!
* Nafallo have constantly banging his head against the wall everytime that happened, often while watching the end of a movie.
<fabbione> Kamion: this new kernel will also actually fix -server stuff
<fabbione> so we can start switching the images
<Kamion> not going to attempt that until next week, but sure
<fabbione> of course
<fabbione> i didn't expect you to do it now
<ajmitch> sigh
<ajmitch> upstream trying to convince me to ship another set of gtk# source+binaries, built with their compiler, not mono's
<Keybuk> ugh, I'd forgotten how obtuse Launchpad's login system is
<dexem> what time is the change to Malone expected?
<siretart> elmo: please sync arson from unstable, ok to override ubuntu changes
<viviersf> daniels, ping
<Kamion> dexem: http://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-January/000051.html
<Kamion> ogra_ibook: oops, just found out the reason for your locale breakage
<Kamion> ogra_ibook: new localechooser hasn't built
<dexem> Kamion: thanks :D
<rleigh> Hi folks.  How do I find who the last person to upload my packages?  They no longer appear in the changelog for some reason.
<dholbach> rleigh: doesn't http://packages.ubuntu.com have the changelogs?
<dholbach> hi btw :)
<siretart> hi rleigh. I think the changelog should help you out
<rleigh> dholbach: Yes, but later versions of my (Debian) package seem to have superseded the ubuntu change history.
<ajmitch> rleigh: which package, btw?
<rleigh> gimp-print
<dholbach> rleigh: I "synced" the gutenprint package; gimp-print is superseded now, no?
<rleigh> There were three ubuntu-specific bugfix uploads last year (since integrated), but the record is gone.
<rleigh> dholbach: Yes, it's gone from testing/unstable.
<siretart> gimp-print | 4.3.99+cvs20051122.dfsg.1-2 |      unstable | i386, powerpc
<siretart> huh?
<dholbach> rleigh: did you want to look up the changes?
<siretart> in sync with dapper
<ajmitch> rleigh: they'll still be recorded on the dapper-changes list (or breezy-changes)
<dholbach> rleigh: i have the package locally - let me check
<rleigh> dholbach: Yes.  I just wanted to contact the last person who changed it, because a user reported a rather bizarre problem.
<dholbach> package source
<dholbach> rleigh: i'll paste it in the query
<siretart> rleigh: the last persons who touched gimp-print seem to have been pitti and infinity 
<rleigh> Thanks folks.
<dholbach> :)
<siretart> :)
<siretart> does anyone know how to contact fabian franz best?
<mvo> mjg59: you still get messageboxes from g-p-m instead of notifications? this is odd, because g-p-m was build with notify support and the buildlog looks ok
<mjg59> mvo: I haven't upgraded since earlier this week, but yes
<mjg59> Just let me check
<mvo> mjg59: I wonder if you get anything in ~/.xsession-errors about a failed init of libnotify or something
<mjg59> mvo: Nope
<mjg59> mvo: Hmm. I don't have a notify-daemon running.
<Treenaks> doesn't that get started automagically?
<mjg59> I'd have thought so
<mjg59> No, starting that and restarting g-p-m doesn't change anything
<mjg59> So something seems broken
<mvo> mjg59: and no messages somewhere? do you still have "notification-daemon" installed? does it help if you remove it first?
<mjg59> mvo: Still no messages, notification-daemon is not installed (though its config files are)
<mjg59> mvo: Which means there's still a /etc/dbus-1/system.d/notification-daemon.conf, though that shouldn't break anything?
<mvo> mjg59: no, that shouldn't break anything. I'll have a closer look now. IIRC update-notifier did send you "correct" notificiatons, so the notificaiton system itself is working?
<mjg59> mvo: I'm not running update-notifier right now. Hang on a sec.
<mjg59> mvo: Yea, update-notifier works
<mvo> mjg59: ok, thanks for testing that
<siretart> elmo: please sync dx from unstable, ok to override ubuntu changes
<mjg59> My power_on_hours seems to be in minutes
<mjg59> Oops
* jsgotangco out for a beer
<jsgotangco> cheers
<dholbach> have fun, jsgotangco
<Gagatan> too early for beers here I'm afraid..
<siretart> Kamion: do you know what to do with these package currently in universe: linux-kernel-di-i386-2.6 and linux-kernel-di-powerpc-2.6?
<siretart> Kamion: remove and blacklist from syncing?
<Kamion> siretart: yes, that would be reasonable
<ogra_ibook> Kamion, ouch ... 
<ogra_ibook> Kamion, do you know why it didnt build  ?#
<Kamion> ogra_ibook: already fixed
<siretart> Kamion: can you do that (or ask elmo to do it)?
<ogra_ibook> cool :)
<Kamion> elmo: please remove and sync-blacklist linux-kernel-di-*
* vurdak is back (gone 03:01:02)
<dholbach> vurdak: please turn the away-script off
<vurdak> dholbach, ok
<vurdak> sorry
<dholbach> vurdak: merci beaucoup :)
<janimo> Kamion, please tell elmo to also remove xfprint and xffm4-icons source packages too from the archive. they are deprecated/replaced by xfprint4 and xffm4 thanks
<crimsun> janimo: same for xterminal, correct?
<crimsun> no real reason to have it hanging around due to xfce4-terminal
<Kamion> janimo: please do it yourself
<Kamion> I'm not an elmo-proxy; I only did the above because I know about linux-kernel-di-*
<janimo> crimsun, right
<janimo> Kamion, ok I asked him a couple of times this past week already
<siretart> what about these kernel-patch-* packages, shouldn't we remove and blacklist them as well?
<ajmitch> siretart: yes, we should
<janimo> elmo, please remove xffm4-icons, xterminal, xprint source packages from the archive. also sync xfce4-terminal from sid. thank you
<janimo> elmo, xfprint above sorry
<jamesh> seb128: did the config change for the desktop-bugs mailing list help with the malone emails?
<Riddell> Kamion: today's install CDs for Kubuntu are good but the live CDs from yesterday are broken (couldn't open directory /lib/modules/2.6.15-11-powerpc), will rebuilding the live CDs magically fix that?
<siretart> I'd propose to blacklist  kernel-patch-* kernel-source-2.4* kernel-tree-2.4* kernel-image-* kernel-headers-*
<siretart> does anyone think this would be unreasonable or why this hasn't been already done?
<Kamion> Riddell: yeah
<Kamion> well, should do
<Riddell> I'll give it a shot
<Kamion> siretart: (syncs are of sources, not binaries)
<siretart> gnarf. you are right
<Kamion> Riddell: do you have access to rebuild the live filesystems?
<Riddell> Kamion: ah no, that's not done automatically overnight?
<Kamion> Riddell: yes, but it hasn't been done since I NEWed the current batch of kernels
<Kamion> I'll kick off a rebuild now
<Riddell> ok, thanks
<siretart> I'd propose then to blacklist  kernel-patch-* kernel-source-2.4* kernel-image-* 
<seb128> jamesh: I've made the change yesterday and not triaged bugs on malone since but it should be fine, I'll let you know soon
<ogra_ibook> hmph ... looks like ubuntu-users slowly becomes an advertizing platform for the automatix script ...
<pitti> siretart: in fact we should BL kernel-source-* (our's is linux-source)
<Mithrandir> pitti: isn't it a bit weird that locale-gen is not run when the locales package is installed, as well as locale-gen $LANG not regenerating?
<pitti> Mithrandir: I can change that if necessary
<Mithrandir> pitti: it just feels wonky.
<pitti> Mithrandir: the latter is for avoiding regeneration if you specify a complete  language
<pitti> Mithrandir: i. e. if you install a language pack, you don't want to regenerate all locales if you already have them
<Mithrandir> sure, but it should still generate that locale.
<Mithrandir> if you do locale-gen nb_NO.UTF-8 and already have that made, it doesn't do anything.
<pitti> Mithrandir: if it doesn't exist, 'locale-gen $locale' should work; doesn't it?
<pitti> right
<pitti> ok, I'll think about the second case
<pitti> what should locale's postinst do?
<Mithrandir> regenerate all locales, I'd guess.
<pitti> every time?
<Mithrandir> since the definitions might have changed.
<Mithrandir> yes.
<pitti> hrmkay
<Mithrandir> I was bitten by this so my week began on sunday since this was how it was set up in breezy, and the locale was never regenerated.
<pitti> Mithrandir: do you want to file a bug? or shall I just add it to my todo list? I'm a bit busy with debugging ATM
<Mithrandir> pitti: if you're fine with the changes, I can just fix them and upload. :-)
<pitti> Mithrandir: oh, sure, go ahear
<pitti> ahead, even
<janimo> smurf, libgnutls11-dev does not have a .pc file. the newer 12 does, but the former is depended on by most ubuntu packages
<pitti> I think that's on purpose
* ..[topic/#ubuntu-devel:jamesh] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 2 released | If your initramfs is broken in any way, please save a copy for infinity | Bugzilla migration underway
<pitti> janimo: all new builds shuold use the latest one
<janimo> pitti, looking at rdepends for both packages shows 11 is used a lot more
<pitti> yes, it's a transition we still have to do
<janimo> in dapper?
<janimo> should MOTU be notified?
<pitti> yes, preferably for dapper
<pitti> for the sake of ReducingDuplication
<gouchi> Hi
<janimo> oh is it already in the reducingdups spec?
<pitti> I think so
<janimo> ok thanks
<gouchi> no update for #17871 that means I can't boot to kubuntu liveCD :(
<pitti> janimo: hmm, 102 packages against 11, 76 against 12
<gouchi> #1787 ide=nodma didn't work 
<Kamion> gouchi: the bug log says it's fixed in dapper and won't be fixed in breezy
<Kamion> gouchi: does the dapper live CD not work for you?
<gouchi> Kamion : didn't test  I have to dl Dapper :)
<gouchi> Kamion : I will report if there is a problem
<Riddell> seb128: can I update libmeanwhile0 to libmeanwhile1 and gaim-meanwhile to latest version?  kopete-meanwhile needs the newer version of the library
<seb128> Riddell: no objection from me, they are universe stuff that's motu land :)
<Kamion> jdub: is ubuntu-bugs@ set up to accept bugs from Malone?
<Riddell> I'll just have to make sure dholbach doesn't notice then :)
<seb128> he he
<ajmitch> Riddell: you break it, you keep it. those are the MOTU rules :)
<infinity> pitti / janimo : I suspect a lot of mass-rebuild transitions will happen after UVF, since we'll stop focusing on new upstreams and start focusing on minimizing version bloat. :)
<infinity> Speaking of....
<dholbach> Riddell: have fun, update it :)
<infinity> doko: What's the current roadmap for punting python2.3 to universe?
<pitti> doko_: <infinity> doko: What's the current roadmap for punting python2.3 to universe?
<ogra_ibook> ARGH
<ogra_ibook> who broke kig ? 
<Riddell> wasnae me
<infinity> Oo, oo, blame me!
<ogra_ibook> hmm
<doko_> pitti: getting python-all-dev and python-central/python-support into the distribution and then reuploading packages
<siretart> doko_: any reason to not sync the libpng package from unstable? pbuikder/piuparts on amd64 is fine for me
<ogra_ibook> infinity, you removed libboost-python1.33.0c2a ?
<infinity> No, I just like taking blame.
<siretart> doko_: I ask because in debian libpng has been updated and libpng3 has been removed. I think we should avoid unnecessary divergence
<ogra_ibook> heh
<doko_> siretart: IIRC, that was just diverged because the package was miscompiled
<freeflying> doko_: hi
<siretart> doko_: you stated in the changelog that it was ok to sync it next time
<freeflying> doko_: OOo in dapper keer crashing when input chinese or paste any cinese in it 
<fabbione> Kamion: can you please NEW the sparc kernel
<fabbione> ?
<doko_> freeflying: how do I input chinese from a US keyboard?
<infinity> siretart: Yes, we do want the new libpng as part of ReducingDuplication, as well as ReducingHeadaches.
<freeflying> doko_: you can try open a chinese font with zh_CN locales
<infinity> siretart: I was going to give it a sanity check first thing Monday.
<freeflying> doko_: s/font/file
<siretart> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338016 is the relevant request for removal from debian
<dexem> How can I know what is doing my boot sequence? I can't show the usplash I need for my live CD distro, and I don't know if it's my fault... or the png fault... or...
<siretart> infinity: ok. so you are aware of it. great!
<freeflying> doko_: you'd have a try under zh_CN locales ., it will not crash under en_US locales
<ogra_ibook> elmo, around ? 
<doko_> freeflying: ok, please could you add this information the appropriate bug report?
<infinity> dexem: Are you turning that PNG into a bogl image with pngtobogl, before you install it to /usr/lib/usplash/usplash-artwork.so?
<freeflying> doko_: I've filed bugs on launchpad , and alse sent it you a mail about this 
<dexem> infinity: yup, and I've rebuild my initramfs
<infinity> dexem: If you're unsure that you're doing it right, test usplash at a console by hand, don't test it from the initramfs, that's just a pain. :)
<dexem> infinity: can that be done? I didn't know that... 
<ogra_ibook> Kamion, coud you unleash the libboost stuff from new ? seems it changed its name and dropped the c2a
<dexem> infinity: yes, I was getting crazy
<infinity> dexem: Just call "usplash" from a console as root.
<infinity> dexem: Odds are it throws an assertion failure at you due to the image being the wrong size or something.
<infinity> dexem: (If you're using our vga16fb patch, the default console is only 640x400, your image can't be bigger...)
<infinity> dexem: (You'll have to wait for it to time out.. It's not smart enough to return immediately if it can't load the image... Which I really should fix..)
<Kamion> fabbione: done
<Kamion> ogra_ibook: no, NEW's empty
<ogra_ibook> hmm, thats strange
<ogra_ibook> according to the buildlogs it has build
<Kamion> and libboost binaries are in sync with source
<ogra_ibook> i dont see them in the archive ...
<Kamion> maybe you could tell me which binary out of the several dozen you're actually looking for rather than making me guess?
<infinity> Probbaly went to universe instead of main?
<fabbione> Kamion: thanks
<Kamion> I've promoted libboost-python1.33.1 to main, since that was the only one anastacia mentioned
<ogra_ibook> Kamion, ah, its gone to universe
<ogra_ibook> Kamion, yup, thats the missing one
<ogra_ibook> Kamion, thanks a lot
<dexem> infinity: how long should I wait for the timeout?
* ogra_ibook grumbles about the kdeedu rebuild he has to do now 
<doko_> freeflying: https://launchpad.net/distros/ubuntu/+source/openoffice.org2/+bugs doesn't show any scim related reports
<infinity> dexem: ~15 seconds..
<infinity> dexem: Or change to another VC...
<winkle> any eta for flight3 images?
<infinity> dexem: Switch to X and back if you're not getting your console back at all.
<jamesh> we are about 45% of the way through the migration
<dexem> infinity: then... something strange happens :S It doesn't show anything, I can switch to X again, yes, but I don't know what's happening
<infinity> dexem: And if you switch back to the console you ran usplash from.. You have a prompt again?.. And no errors?
<Riddell> ogra_ibook: what's up with it?
<dexem> infinity: the prompt line overwrites the output message
<ogra_ibook> Riddell, the c2a was dropped from the libboost binarys
<ogra_ibook> Riddell, so i have to doa dependency rebuild ...
<infinity> dexem: So there was some sort of output, then?
<dexem> infinity: seems so
<freeflying> doko_: https://launchpad.net/distros/ubuntu/+source/openoffice.org2/+bug/5981
<infinity> dexem: Can you decipher any of it? :)
<freeflying> it dosen't care about scim
<Kamion> winkle: no
<Kamion> winkle: (the more people ask, the later it'll be :-))
<dexem> infinity: I just can see it ends with "to". Can the output be redirected to a file?
<winkle> hehe, better shut up then ;)
<dexem> infinity: is there a size limit for the .so image?
<highvoltage> .so or .iso?
<infinity> dexem: File size, or image size?
<dexem> highvoltage: .so   I'm asking about usplash
<infinity> dexem: The image needs to be 640x400, 16-color, indexed.
<infinity> dexem: File size is pretty much determined by that (it's hard to have a big one that fits that description)
<dexem> infinity: uhmmm maybe is that the problem... I'll try with 400 for height (it was 480, but I thought I tried one with 480 and worked...)
<infinity> dexem: Our default vga16fb console is 640x400.  If you're using vesafb or a custom kernel with a different framebuffer, that limit doesn't necessarily apply.
<infinity> dexem: Usplash just checks to see if the image will fit in the current FB, if it won't, it bails out.
<dexem> infinity: ok, probably it's vga16fb because I haven't selected anything different than default
<freeflying_> doko_: would you mind have a try
<sladen> dexem: previous we were setting the video mode to 640x480, but that causes issues
<dexem> infinity, sladen: thanks :D I have to rebuild correctly my ISO, but usplash loads the image from console
<infinity> dexem: Excellent.
<infinity> dexem: Sorry about the crap error reporting.  usplash has a fair way to go to be "friendly".
<ogra_ibook> sigh, yes... usplash ... i still have to fix the puched edubuntu image ...
<dexem> If you don't mind, I'm going to change the wiki. It says 640x480 ;)
<infinity> dexem: Please do.  I didn't know there was a wiki page.
<infinity> ogra_ibook: Hey, at least the edubuntu image WORKS.  It's just ugly. :)
<ogra_ibook> infinity, exactly ...
<infinity> ogra_ibook: AndyFitz was working on several designs for replacement for {edu,ku,u}buntu usplash images.
<ogra_ibook> infinity, and the color for the text is wrong since breeky, the "ok" is way to dark
<infinity> ogra_ibook: "ok" should be the same colour as the text itself...
<infinity> ogra_ibook: Though I've never booted with the edubuntu image, so I don't know what it looks like in action.
<ogra_ibook> infinity, oops, i hope he doesnt clash with the company that is supposed to do the designs
<infinity> ogra_ibook: Oh, we've contracted this out already?  Or just for edubuntu?
<dexem> infinity: https://wiki.ubuntu.com/USplashCustomizationHowto  <--- check it for possible errors if you have time, please. I haven't written it but is good to have correct and updated info :D
<ogra_ibook> infinity, the image is fine, but the test and progress bar are to dark
<infinity> ogra_ibook: Yeah, that's easy to fix.  Just replace the one colour in the palette index that is the text colour. :)
<ogra_ibook> infinity, i was told we'll have a company for the three default designs ... but i have no further info
<infinity> ogra_ibook: Curious.  First I've heard of it.  <shrug>
<neuralis_> infinity: has someone given thought to having the numerical *buntu version in the usplash image?
<ogra_ibook> infinity, its indexed ... if i replace this color, the logo breaks :)
<infinity> neuralis_: I thought about it, yes.
<infinity> ogra_ibook: Oh, you're reusing an image colour for the text?
<neuralis_> infinity: what were the cons? 
* sladen was thinking have to display the contents of  /etc/lsb_release
<infinity> ogra_ibook: Guess you need to reorder your palette, then. ;)
<ogra_ibook> infinity, isnt that done by default ?
<infinity> neuralis_: None, really, just haven't done it.
<infinity> ogra_ibook: No, with an indexed palette, the palette stays in a specific order.  You can reorder it in the GIMP and re-save it.
<infinity> ogra_ibook: The HOWTO page just pointed out to me tells you which palette locations are "magic" (ie: reused)
<neuralis_> infinity: cool. you want a wishlist bug or somesuch filed to remind you, or do you have it in some todo list already?
<ogra_ibook> infinity, i mean that a certain color is picked from images the palette 
<ogra_ibook> if i reorder it, that also changes the image colors
<ogra_ibook> yes, i saw that page 
<infinity> Erm.  Let me fire up the edubuntu logo and look at this. :)
<ogra_ibook> infinity, i think there is no big poinnt in editing it now, if we get new images anyway
<ogra_ibook> i just will crop the breezy image instead of scaling it to make it not look punched
<infinity> ogra_ibook: No, I suppose not, but if you just want the colors fixed for your text, that's simple enough.
<infinity> ogra_ibook: Err.. "punched"?
<infinity> ogra_ibook: If you crop it, it'll be stretched out on 640x400.
<ogra_ibook> yes, it looks like you hit it with a sledgehammer on the top :)
<infinity> ogra_ibook: Think about it.  The aspect ration didn't change, but the image height did.
<infinity> ogra_ibook: You're using vesafb, aren't you? :)
<ogra_ibook> sure
<infinity> s/ration/ratio/
<infinity> ogra_ibook: Yes.  Boot without "vga=" intead (which is our default)
<infinity> Fixing things for 4x3 video modes is on my TODO for later.
<ogra_ibook> if i cut off 80 pixels of the height from the breezy pic instead of scaling the height it will be fine 
<infinity> Not on vga16fb, it won't.
<ogra_ibook> huh  ?
<infinity> vga16fb is 640x400.  not 480.  400.
<infinity> That's not 4x3.
<infinity> Not the same aspect ratio as your vesafb console.
<infinity> What looks "square" in one is a rectangle in the other.
<ogra_ibook> i know about ratios ...
<ogra_ibook> what i need is an image that doesnt look squeezed 
<OpsVentus> Hello all,  question: is there a plan for a 'Airplane mode' for ubuntu?
<mdke> Znarl, elmo, would really really appreciate rt #1610 getting done, if you possibly can
<Kamion> the aspect ratios of 640x400 and your vesafb console are different. it is not possible to produce a single image that works with both.
<mjg59> ogra_ibook: You need different images for the two. You can't just chop 80 pixels off the bottom.
<mjg59> Otherwise the vga16fb one will look stretched compared to the vesafb one
<infinity> ogra_ibook: The one you have doesn't look "squeezed" on vga16fb.  We'll later deal with having two images for the two ratios, but for now, I'd rather have one that displays correctly on our default mode, not on your video mode.
<ogra_ibook> hey, it looks like arse in a fresh install, i just want to crop instead of scale it 
<mjg59> ogra_ibook: It's *not scaled*
<ogra_ibook> it *looks* scaled
<mjg59> The problem now is that the old picture has been cropped
<neuralis_> OpsVentus: airplane mode?
<mjg59> It needs new artwork
<mjg59> ogra_ibook: There's no scaling code in usplash
<infinity> mjg59: No, it is scaled.  I scaled it to be the right aspect ratio on 640x400.
<infinity> mjg59: It's not pretty, but at least it's the right ratio.  (except on his vesa console)
<mjg59> infinity: I meant when usplash loads it
<infinity> Oh, yes.  Not scaled then, obviously.
<ogra_ibook> the old pic was 640x480, the content will look identical if i dont scale the height but cut off 80px in height to make it 640x400 
<OpsVentus> neuralis:so you're shure when turning on you're laptop in an airplane, wifi and bluetooth ar turned off
<ogra_ibook> since there is no scaling code in usplash
<mjg59> ogra_ibook: No it won't
<doko_> freeflying: thanks, I was blind. will do later
<infinity> ogra_ibook: No.  It.  Won't.   It'll look stretched vertically.
<infinity> ogra_ibook: Your monitor doesn't change shape depending on what video mode I choose.
<ogra_ibook> i cant belive that
<jamesh> infinity: maybe your monitor doesn't
<neuralis_> OpsVentus: there are no plans for it, and a number of newer laptops contain a hardware switch for that functionality, so implementing it in software is impossible.
<ogra_ibook> why should it look streched vertically ? 
<mjg59> ogra_ibook: Nngh.
<ogra_ibook> it has a fixed size value
<infinity> ogra_ibook: But not a fixed aspect ratio.
<jamesh> ogra_ibook: think non-square pixels
<ogra_ibook> if i change the size but not the content, it simply *cant* look streched
<OpsVentus> I see
<ogra_ibook> hmm
<infinity> ogra_ibook: Draw two identical squares.  Fille one with 4 horizontal lines.  Fill the other with 3 horizontal lines.  Note that one has bigger "scan lines" than the other.
<jamesh> ogra_ibook: if your pixels are 1mm by 2mm, then an image that doesn'
<jamesh> t look stretched with square pixels will look stretched
<ogra_ibook> jamesh, ahhh, now i understand
<jamesh> (that's an exageration)
<mjg59> ogra_ibook: You take a picture. It's 640x480 at a 4:3 aspect ration. You chop off 80 pixels from the bottom, you no longer have a 4:3 picture. You now display that non 4:3 picture on a 4:3 screen
<mjg59> The result is that it's stretched
<mjg59> ogra_ibook: vga16fb's 640x400 mode fills the entire screen. It's a non 4:3 mode displayed at 4:3, and the picture needs to take that into account or it'll be distorted.
<mjg59> ogra_ibook: Simply chopping 80 pixels off the bottom of a 640x480 image doesn't take that into account, so it'll be distorted
<ogra_ibook> mjg59, yup, jamesh seems to have a talent to explain stuff to idiots ;) understood now :)
<OpsVentus> neuralis:  how dificult is it to add a boot option in grub which disables wifi/bluetooth?
<infinity> OpsVentus: "airplane mode"?
<mjg59> Not difficult
<OpsVentus> infinity: boot option which disables wifi and bluetooth
<mjg59> As long as you're happy to lose ethernet as well
<infinity> Last time I booted on a plane and wasn't sure if the wireless was off, I just disabled it in the BIOS before I booted. :)
<OpsVentus> that's an option, but for the users who don't like to go to BIOS
<OpsVentus> and if it's posible in GRUB, it's much easier
<infinity> Oh, I agree.
<neuralis_> mjg59: yes, but are you able to kill the wifi radio from grub as well, even on laptops that have a hardware switch for it? i didn't think it was possible.
<OpsVentus> example: boot in plane(whitout wifi), boot on connecting airport(downloading new email), boot in connecting plane(whitout wifi)
<OpsVentus> If the laptop has a hardware switch you don't need it
<OpsVentus> but my laptop(for example)(Acer travelmate) dosn't have a hardware switch
<mjg59> neuralis_: Not from grub, no. But it's trivial to ensure that we don't load networking modules.
<mjg59> Which can be done by passing an option from grub
<neuralis_> mjg59: clearly, but i don't know how much that does to prevent the radio from emitting anything at all, which is what an "airplane mode" would have to do.
<mjg59> neuralis_: If nothing ever loads, nothing ever enables the radio
<OpsVentus> is that sure?
<LaserJock> so the new intel iMacs can't run Ubuntu out of the box because of EFI, am I reading -devel right?
<OpsVentus> dosn't a wireless network card try's to search for networks automaticly
<infinity> OpsVentus: Not without a driver telling it to.
<mjg59> LaserJock: That depends on whether they've implemented BIOS compatibility code
<mjg59> Even if they have, you're not going to get X
<infinity> OpsVentus: I've never seen wireless tftp booting.
<infinity> (though that would be handy)
<OpsVentus> and what about bluetooth?
<mjg59> OpsVentus: Ditto
<mjg59> (I believe)
<OpsVentus> so somehow we need to diable the drivers
<LaserJock> mjg59: ah, I will have one as soon as it get's shipped so I was wondering if there was any testing that I could do to help
<OpsVentus> if we only disable then at boot they can be activated later on
<ogra_ibook> infinity, jbailey was thinking about making wlan netbooting possible
<infinity> ogra_ibook: Yes, but that would still require a local disk and an initramfs.
<ogra_ibook> yup
<mjg59> OpsVentus: That's easy enough - just blacklist the bluetooth drivers and anything that would bind to a PCI device with a class of 200 or 280
<neuralis_> mjg59: i'm trying to recall the specific laptops, but in the process of some previous research, i definitely had at least a few send out a couple of quick radio bursts as soon as you hit the wifi enable switch
<ogra_ibook> infinity, but you could put that on a usbstick and boot ltsp thin clients from it, which would rock
<mjg59> neuralis_: If the driver is loaded, that's what you'd expect
<OpsVentus> so is there anyone that can do this, I don't know to much about this
<neuralis_> mjg59: this was pointedly without any drivers loaded. i ignored it at the time as it wasn't pertinent to what i was doing, but i'll see if i can find which chipsets these were.
<Kamion> OpsVentus: only being able to do that at boot kinda sucks, though. When I'm travelling, I only suspend my laptop whenever possible rather than turning it off entirely.
<infinity> Yeah, disabling on resume would be handier.
<infinity> I pulled a battery from a suspended laptop to work around that one once.
<OpsVentus> do's the airlines like suspended laptop's during landing/taking off, they always tell you to turn all electronics off
<infinity> (One that didn't have wireless disable in the BIOS, IIRC... Or I wasn't thinking clearly.. Pick one)
<Kinnison> OpsVentus: Well, mine tends to travel with me suspended
<infinity> OpsVentus: Suspended may as well be off, like they notice or care...
<OpsVentus> Me for one, always trys to follow the rules(maybe I'm nuts or something)
<OpsVentus> But I have to go now, is this something to make a wiki about or something?
<Kamion> Riddell: you have reasonably up-to-date Kubuntu install/live CD builds; fancy starting a test run?
<Riddell> Kamion: just burning now
<Kamion> ta
<Kamion> edubuntu images building
<ogra_ibook> Kamion, wont work
<ogra_ibook> Kamion, kig still needs a rebuild ... kdeedu is building here since 20 min
<Kamion> ogra_ibook: why not?
<Kamion> oh
<Kamion> ok, cancelled
<ogra_ibook> it should work with just re-uploading it, but i dont like it without a test build
<Kamion> Ubuntu CDs all built if anyone wants to help me test
<Riddell> Kamion: aiming for flight today I presume?
<Kamion> Riddell: hope so, we'll see
<Kamion> might wind up actually releasing it tomorrow morning or something
<\sh> any messages about bugzilla -> LP migration?
<Kamion> it's in progress, but fell over on one of the bug aliases apparently
<dholbach> \sh: an hour ago they were half way through
<dholbach> go launchpadders go! :-)
<ogra_ibook> oh, my email won in the duch email lottery :) 
<dholbach> ogra_ibook: mine too
<ogra_ibook> i wonder why i never win in a german email lottery 
<\sh> dholbach: ah..because i didn't read any "we beginning now" mail :)
<dholbach> \sh: they said they'd start at 12:00 UTC
<dholbach> \sh: and it was in a mail to u-d-a too iirc
<Diziet> Grrr.  I hate Python.   dict.has_key['thing']   but  hasattr(obj,'thing') 
<Diziet> Anyone would think we hadn't learned anything from the standard C library.
<neuralis_> Diziet: actually, "key in dict"
<neuralis_> Diziet: in works for all iterables.
<\sh> dholbach: in the announcement yes...but i thought they wanted to give the start mail today 
<\sh> dholbach: anyways..pressing thumbs, that everything goes well
<Diziet> So   hasattr(obj,'thing')  vs  'thing' in dict   ?  That's even less consistent.
<neuralis_> Diziet: it's not. i think you don't have a good enough understanding of the object model.
<Robot101> Diziet: 'thing' in obj.__dict__? :)
<Kamion> AttributeError: 'pwd.struct_passwd' object has no attribute '__dict__'
<Kamion> you don't get __dict__ in all objects
<Diziet> neuralis_: No, my _understanding_ is fine.  It's my _temper_ that it has broken ...
<neuralis_> Kamion: you get __dict__ in all instances of user-defined classes.
<Kamion> though "'thing' in dir(obj)" works
<Diziet> 'thing' in dir(obj)  is probably O(n).
<Kamion> probably O(n log n) actually given that dir() is sorted
<Kamion> unless dicts maintain a sorted list of their keys behind the scenes
<Mithrandir> Kamion: if you need more than n to search through a list, you're doing something very silly. :-)
<neuralis_> Kamion: they don't
<Kamion> Mithrandir: dir() needs to sort the keys of obj.__dict__ (or equivalent) before giving them back to you.
<jdub> Kamion: don't believe so (ubuntu-bugs) -> what do i need to do?
<Kamion> it's not the 'in' bit that's O(n log n) ...
<Kamion> jdub: I think either kiko or seb128 has the recipe
<Mithrandir> Kamion: oh, true.  Well, dir() shouldn't, then.
<Kamion> heh, all my machines are now offering me Broadcom wireless interfaces on install
<Kamion> I didn't even know that one of them *had* built-in wireless
<pitti> Kamion: the airport express?
<Nafallo> hehe, sweet :-)
* pitti should really buy an Airport Extreme card for his iBook soon
<Kamion> pitti: haven't tried the powerbook yet
<\sh> hmmm....errors while dist-upgrading
<pitti> elmo: please sync libapache2-mod-auth-pgsql and pmount from sid, and sysfsutils from experimental
* ogra_ibook kicks evo 
<\sh> cupsys-driver-gimpprint depends on cupsys-driver-gutenprint which is not configured yet...well this is during configure state of cupsys-driver-gutenprint
<\sh> looks like a circular dependency
<ogra_ibook> isnt -gimpptrint gone ? 
<\sh> dpkg: dependency problems prevent configuration of cupsys-driver-gimpprint:
<\sh>  cupsys-driver-gimpprint depends on cupsys-driver-gutenprint (>= 4.3.99+cvs20051122.dfsg.1-2); however:
<\sh>   Package cupsys-driver-gutenprint is not configured yet.
<\sh> dpkg: error processing cupsys-driver-gimpprint (--configure):
<\sh> with latest update from the archives...it doesn't look like that :)
<ogra_ibook> there should be no cupsys-driver-gimpprint package anymore, its replaced by cupsys-driver-gutenprint
<pitti> yes, but you need the transitional packages for upgrades
<\sh> ogra_ibook: yes...and this error occurs while setting up driver-gutenprint :)
<Kamion> ogra_ibook: it's a dummy package
<ogra_ibook> yes
<Kamion> I really wish you'd check the archive first
<ogra_ibook> sorry
<Kamion> \sh: -gutenprint doesn't depend on -gimp-print though
<pitti> no, it shouldn't
<pitti> (just the other way round)
<\sh> well..we have then a problem
<\sh> dpkg: error processing cupsys-driver-gutenprint (--configure):
<\sh>  subprocess post-installation script returned error exit status 3
<\sh> dpkg: dependency problems prevent configuration of cupsys-driver-gimpprint:
<pitti> \sh: can you add a set -x to /var/lib/dpkg/info/cupsys-driver-gutenprint.postinst and check where it fails?
<Kamion> so -gutenprint fails to configure for some largely-unspecified reason (exit status 3) and -gimpprint therefore fails to configure too because it depends on it
<Kamion> that's not a circular dependency, it's just a dependency
<\sh> Kamion: yes...right..used the wrong term
<\sh> pitti: 10secs :)
<\sh> bah
<\sh> after having it now 10 times...but setting now -x solves the problem? i'm hallucinating
<mako> mdke: yes! there is a script that makes this very easy now
<\sh> sorry to say, it's just gone..which is somehow strange..because since just now I could reproduce it every time
<pitti> \sh: -x means 'fix it', you know? :)
<\sh> pitti: if it would be so easy to set -x ... I would mass close all bugs with "set -x" ;)
<\sh> but wait...let me try it again with the laptop here
<\sh> hope it was something after this early morning when my last dist-upgrade happened
<pitti> Keybuk: the other day you mentioned you were interested in bugs caused by existing .la files? wanna take a look at Debian #347901?
* ogra_ibook twiddles thumbs .... go kdeedu, go !
<Keybuk> pitti: not right now
<pitti> 'k (I'm just removing it from libsysfs-dev, as proposed)
* ..[topic/#ubuntu-devel:jamesh] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 2 released | If your initramfs is broken in any way, please save a copy for infinity | Bugzilla migration mostly done
<\sh> jamesh: i never subscribed to this bug: https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/23949 :)
<jamesh> \sh: you are CC'd to https://bugzilla.ubuntu.com//show_bug.cgi?id=17792, which it is an import of.
<\sh> but why?
<jamesh> what do you mean by why?
<jamesh> https://bugzilla.ubuntu.com//show_activity.cgi?id=17792 <- that's you subscribing yourself to the bug in bugzilla
<\sh> jamesh: I don't remember this bug...and why I should have added my email address to it...
<jamesh> \sh: I don't know why you would have done that.
<\sh> jamesh: I see my email address yes, but I don't remember to add it there ...but regarding the data in bugzilla, it was no mistake in the migration...
<ogra_ibook> \sh, see who's the original reporter ;)
<jamesh> the bugzilla activity log clearly states that the account "sh@sourcecode.de" added "sh@sourcecode.de" as the contact
<\sh> ogra_ibook: bah...this guy..now I know
<ogra_ibook> hehe
<\sh> he added me there
<ogra_ibook> yup, thats what i suspected :)
<\sh> I'll kill him later :)
<jamesh> \sh: other people using your bugzilla account?
<\sh> jamesh: known people adding my email address to a bugzilla bug yes...happens sometimes when this very special guy was a colleague of mine :)
<spacey_ki> i also got launchpad mail a whle back for a bug i never subscribed to
<jamesh> \sh: the activity log says you added yourself, rather than someone else adding you thouhg.
<jamesh> (you or someone using your account)
<\sh> jamesh: this is more strange..because I know I never added myself to this bug..or he was sitting at this time at my place and was using my laptop when bugzilla was open...what time was it?
<jamesh> 2005-11-24 13:04 UTC
<spacey_ki> https://launchpad.net/distros/ubuntu/+source/installation-guide/+bug/4637
<\sh> during work hours
<spacey_ki> i got an launchpad mail for that one
<spacey_ki> but i'm not subscribed
<spacey_ki> and never seen it
<\sh> a thursday..
<\sh> I'll have a shower now, and go and kill him...
<ogra_ibook> \sh, send my greetings before :)
<spacey_ki> i'll bother #launchpad with that
<LaserJock> \sh: you might want to shower after... ;-)
<\sh> oh..I can't kill him... I have to wait until I meet him for a drink..I'm not allowed anymore to put one foot into the holy halls of ISH
<jamesh> Kamion: by the way, you can target an existing bug task at a different source package, rather than rejecting the old one and creating a new one
<\sh> ogra_ibook: did you know? http://kapsi.fi/~tm_travolta/kuvat/temp/kedubuntu-1d.png
<Riddell> Kamion: kubuntu CDs good on i386, I'll try the other arches
<ogra_ibook> \sh, :(
<ogra_ibook> \sh, why dont they contact the rest of the edubuntu community about that ?
<\sh> ogra_ibook: there are other things in temp/
<ogra_ibook> yes, i looked already
<\sh> ogra_ibook: just grabbed the url from kubuntu-devel...so I was surprised as well
<ogra_ibook> i would find it odd if they'd not work with the rest of the edubuntu community
<mdke> mako, thanks
<Kamion> jamesh: sure - did I do the latter at some point?
<jamesh> Kamion: I misread the activity log on the bug.  It was dholbach who made that change
<Riddell> ogra_ibook: it's just a random bit of artwork, not the start of a kedubuntu distro
<ogra_ibook> Riddell, ah, i thought it was the long discussed start of kedubuntu 
<ogra_ibook> Riddell, i'd be happy about it, i just wouldnt like to have two distinct communitys, there is too much overlap
<Kamion> so, anything people particularly want to have in the Flight 3 release notes?
<Mithrandir> Kamion: shinier live cd, I'd love to get more testing of that
<Kamion> https://wiki.ubuntu.com/DapperFlight3 is shaping up nicely
<Keybuk> Kamion: make sure you note that sound card mixer setting restoration is erratic; and that a bad shout-down can result in network cards not getting plugged ever again
<Keybuk> uh, shut-down <g>
<Keybuk> might be worth adding the new "Restart Required" bubble to it too
<Keybuk> uh, where one goes on the negative bits, and the other on the cute bits
<Keybuk> oh, someone added placeholders already
* Keybuk adds screenshots
<HiddenWolf> Keybuk: the bubble is "cute" ?
<Keybuk> HiddenWolf: well, I think the new bubbles are frakking ugly myself; but the premise is cute
<HiddenWolf> hm.
<HiddenWolf> :)
<Keybuk> actually, looks like the screenshots are all done the same way, so I'll let someone else do that
<HiddenWolf> They should be themeable at the very least. =)
<ogra_ibook> doko, j2re in universe ??
<Tm_T> ogra_ibook: ?
<ogra_ibook> Tm_T, ? 
<Tm_T> ogra_ibook: that pic is meant to show ubuntu,edubuntu and kubuntu to be the same community ;)
<Tm_T> nothing else
<Tm_T> atleast I hope we are all same one big family
<ogra_ibook> Tm_T, i thought it was the start of the kedubuntu distro 
<Tm_T> oh no
<HiddenWolf> Oh please. :P
<Tm_T> well, that's idea I like ;)
* Tm_T plans to ditch whole gnome from us
<Tm_T> whoopsie
<ogra_ibook> Tm_T, in which case i woud have liked that the edubuntu users get notified about.... there is some interest in a kde based version
<Riddell> I've had people asking for one too
<Tm_T> aye
<Tm_T> ogra_ibook: you have seen KOffice peoples simple office mockups?
<Tm_T> office for kids, I like :)
<ogra_ibook> yup
<ogra_ibook> seen that
<ogra_ibook> edubuntu is not aimed at *kids* it shall be for all ages (even if breezy appears different through the artwok)
<Tm_T> aye, I mean that could be part of kedubuntu some day
<Tm_T> but that's future
<ogra_ibook> sure, up to the kedubuntu devels :)
<ogra_ibook> whoever that may be
<tepsipakki> kamion: umm, pkgsel doesn't allow packages from universe?
<Tm_T> ogra_ibook: but what you think as an idea, combining all three and that way show we are not three totally separate distributions (as too many thinks)
<Tm_T> in artwork I mean
<ogra_ibook> looks nice 
<jdub> Tm_T: but they *are* different distributions, sharing a common platform
<Lathiat> mdz: ping
<Lathiat> mdz: whats this about discussing zeroconf in detail with you?
<Tm_T> jdub: yes, but people thinks they don't share a thing, but truth is it doesn't matter what you use, they work together and mixed and just as you like :)
<tepsipakki> kamion: nevermind, I'll file a bug
<Keybuk> Lathiat: you could discuss it with my bat, if you like <g>
<Keybuk> assuming you mean "zeroconf" and not "avahi and friends" :)
<Lathiat> see
<Lathiat> "zeroconf" is a group of things
<Lathiat> not just the program
<Lathiat> that a few people dislike ;p
<jdub> Keybuk: the newer versions of zeroconf are not broken (and if we don't ship n-m, we should ship zeroconf)
<Lathiat> network manager seems to be doing LL ips now so
<Lathiat> jdub: you sure? i didnt notice an update
<Keybuk> jdub: dude, zeroconf stops ifup from working!  so we shouldn't ship it even then
* Lathiat tries
<jdub> it was already fixed in unstable while we were in montreal
<jamesh> jdub: have you seen the "logins disabled" page on bugzilla.ubuntu.com?
<jdub> jamesh: no
<Lathiat> ah cool
<jdub> jamesh: i don't have any access to change bz
<jamesh> jdub: try logging in :)
<jdub> despite being listed as an admin...
<jamesh> jdub: just seemed amusing :)
<jamesh>  If you believe your account should be restored, please send email to jeff.waugh@canonical.com explaining why.
<Keybuk> Lathiat: yeah, that's why it's sometimes easier just to refer to source package names <g>  then we know what we're talking about
<Lathiat> ah
<Lathiat> but in the dapper status pdfi
<jdub> jamesh: uh huh. and they keep coming...
<Lathiat> it literally says zeroconf
<Lathiat> so i was asking what it said :)
<Lathiat> because i dunno if he means in general, or the source package, or what
<Lathiat> but the spec is called 'zeroconf' so its ambigious
<Lathiat> :)
<Keybuk> probably refers to the spec then
<Lathiat> so i assume
<Kamion> tepsipakki: did you preseed apt-setup/universe=true?
<tepsipakki> kamion: yes
<Kamion> no particular reason I can see in the code why it should ignore universe
<tepsipakki> i have backports enabled as well, but of course it isn't found, could that matter?
<ogra_ibook> ARGH !! dpkg-deb (subprocess): data: internal gzip error: read(4096) != write(0): No space left on device
<Lathiat> hrm, packages.d.o is down :(
<stratus> Lathiat, sure it's but you can retrieve some useful information through PTS, it depends what you need.
<stratus> ogra_ibook, blame dpkg!
<Lathiat> just wante dto know th eversion of rails in unstable
<ogra_ibook> stratus, i blame KDE crazyness ... 35MB source packages are so mean
<stratus> ogra_ibook, wow
<doko> ogra_ibook: sorry, multiverse, could you correct me?
<ogra_ibook> and i have 1G free in /var for the pbuilder ...
<ogra_ibook> doko, will do :)
<Kamion> tepsipakki: possibly, dunno, can't look at it now
<tepsipakki> i'll try
<Keybuk> we have an mhz now?!
* Keybuk cries
<ogra_ibook> Keybuk, since ages
<ogra_ibook> Keybuk, you should come more often to #edubuntu, we have a lot of nice nicks there :)#
<ogra_ibook> Keybuk, at least he has no d in the middle :)
<Keybuk> ogra_ibook: there's an mhy on #debian-uk
<ogra_ibook> hehe
<Keybuk> which means there's now an mdz, mdy, mhy, mhz as well as a plain md to sort out
<Keybuk> my poor brain
<ogra_ibook> *giggle*
<ogra_ibook> you should drop one or the other channel then 
<Keybuk> I'm only on one other apart from work ones
<Keybuk> work and #debian-uk
<ogra_ibook> heh
<ogra_ibook> i have work and #ltsp :)
<Mithrandir> I have ETOOMANYCHANNELS.
<Keybuk> ye, but you're an IRC whore
<Kamion> infinity: powerpc live CDs appear not to work on my powerbook; I get /lib/modules/2.6.12-powerpc64-smp instead of the correct -powerpc
<Keybuk> could be worse, you could be one of the australians who seem to need to join any channel anyone could possibly talk about them on ;)
<Kamion> infinity: install CDs work fine, so I don't think it's the bootloader
<Kamion> infinity: any chance you/somebody could figure out whether cdimage or the buildd or casper or what is broken here? I have to leave in -25 minutes
<Keybuk> Kamion: have a great weekend, btw!
<Kamion> thanks
<pitti> bye Kamion 
<Kamion> Ubuntu/{install,live}/{amd64,i386} are good to go for flight 3
<Kamion> but I'll hold off until I get back
<Kamion> install/powerpc is hopefully ok too, at least it boots properly
<pitti> Kamion: shall I test the current daily on ppc?
<Kamion> please do
<Kamion> if you can figure out what's up with daily-live, that'd be good too; you have the hardware
<pitti> I tested it three days ago, it worked fine, I'll do the current one now
<pitti> ^ (install)
<Kamion> infinity has access to change more or less everything that might conceivably need to be fixed
* pitti jigdos
<Keybuk> meh, if only my AMD64 wasn't in waiting-for-stock-hell this'd be the first CD I could test on all three architectures
<psusi> WTF is wrong with gdb damnit?  it catches the sigsevg but the process terminates anyway before I can examine it... it's like it doesn't get all the threads stopped and oen of them exits the entire process out from under gdb
<Kinnison> mmm debugging with threads
<Kinnison> welcome to hell
<psusi> hell is debugging with gdb it seems...
<psusi> I have no problem debugging multithreaded apps under msvc for instance
* ..[topic/#ubuntu-devel:jamesh] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 2 released | If your initramfs is broken in any way, please save a copy for infinity
<mdke> mako, do I need to do anything to push it through, or do you do it all?
<Keybuk> done?
<mdz> Riddell: kthesaurus promoted
<pitti> yay, malone finished?
<jamesh> yeah.  Kiko will send out an announcement soon
<Riddell> mdz: thanks
<sorush21> guys why isn't there a downgarde option ?
<pitti> sorush21: you can downgrade a single package with apt
<pitti> sorush21: but you can't downgrade an entire install, that'd just break
<sorush21> pitti: well how do i do that
<pitti> (well, you can, but it's nontrivial)
<sivang> yay, seems like migration is over :)
<pitti> sorush21: apt-get install package=version, or package/release
<pitti> sorush21: btw, that's #ubuntu stuff
<mdke> ah, the bug bot
<mdke> cool
<Keybuk> yeah, I asked Seveas to pop it in here for a bit ... I think it's useful :)  feel free to direct complaints at me rather than him :p
<Seveas> @config channel bugtracker.bugsnarfer
<Ubugtu> Error: 'supybot.bugtracker.bugsnarfer' is not a valid configuration variable.
<pef> hello
<mdke> Keybuk, full agreement here
<HiddenWolf> Seveas: what the hell is a bugsnarfer? 
<HiddenWolf> Seveas: sounds icky
<Seveas> something that snarfs for bugs
<Keybuk> and that gives you an error? :)
<Seveas> no, I'm trying to set the default snarftarget
<Seveas> if you say bug 1000 (watch closely) it'll take that as ubuntu bug 1000
<Ubugtu> Ubuntu bug 1000: "Can't start samba" Product: Ubuntu, Component: samba, Severity: major, Assigned to: debzilla@ubuntu.com, Status: RESOLVED, Resolution: WONTFIX http://bugzilla.ubuntu.com/show_bug.cgi?id=1000
<Seveas> but that's a per-channel thing and it should be malone now :)
<Seveas> @config channel plugins.bugtracker.snarftarget malone
<Ubugtu> The operation succeeded.
<pitti> Seveas: oh, I wasn't aware that ububtu works in -devel, too
<Seveas> pitti, since a few minutes, Keybuk asked for it
<pitti> nice
<Seveas> (so complaints go to him :))
<pitti> thanks
<pitti> bug 1
<Ubugtu> Malone bug 1: "Microsoft has a majority market share" Fix req. for: Ubuntu, Severity: Critical, Assigned to: Mark Shuttleworth, Status: Confirmed http://launchpad.net/bugs/1
<Robot101> lol
<Keybuk> bug 28463 ?
<Ubugtu> Malone bug 28463: "New changes from Debian require merging" Fix req. for: udev (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Rejected http://launchpad.net/bugs/28463
<Keybuk> \o/
<Seveas> @bugtracker list
<Ubugtu> debian, freedesktop, gnome, gnome2, kernel, malone, mozilla, and ubuntu
<Seveas> prefix it with one of those names to indicate a specific tracker
<Seveas> like: debian bug 400000
<Ubugtu> An error has occurred.
<Seveas> ugh
<Seveas> and poke me if that happens :)
<pitti> Seveas: what's the difference between gnome and gnome2?
<Seveas> pitti, bugs.gnome vs bugzilla.gnome
<pitti> Seveas: no worries, Debian is in the 300K'ish
<Seveas> not useful here, but useful for the other feature: the urlsnarfer
<Seveas> gnome bug 10000
<Keybuk> debian 340198
<Ubugtu> Error: Error getting Gnome bug #10000: NotFound
<Ubugtu> Debian bug 340198: "PowerPC : Impossible to create a logical RAID 1 root partition" Package: installation-reports, Maintainer: Debian Install Team  http://bugs.debian.org/340198
<Keybuk> debian bug 340198
<Ubugtu> Debian bug 340198: "PowerPC : Impossible to create a logical RAID 1 root partition" Package: installation-reports, Maintainer: Debian Install Team  http://bugs.debian.org/340198
<Keybuk> yeah, it was just too high
<Seveas> it should not error out, but say "Not Found"
<spacey_ki> ubuntu 1
<Ubugtu> Ubuntu bug 1: "openssl: Expired certificates and recertification" Product: Ubuntu, Component: openssl, Severity: normal, Assigned to: fabbione@ubuntu.com, Status: RESOLVED, Resolution: NOTWARTY http://bugzilla.ubuntu.com/show_bug.cgi?id=1
<Seveas> hmm, debian BTS does not return 404 on nonexisting bugs?
<fabbione> oh god
<fabbione> more spam in the channel?
<Seveas> fabbione, It's just the "Hey we have a new toy" phase
<Keybuk> fabbione: let's trial it for a bit and see if it's a useful thing ... I think it will be
<Seveas> it'll be less funny and more helpful in a few hours
<fabbione> ok
<Diziet> I have a bad feeling.  But OK.
<Seveas> -desktop -bugs #malone and #bzr quite like it
<fabbione> Ubugtu: die my little friend
<fabbione> :)
<Keybuk> if it saves us having to fire up Launchpad just to find out what someone's talking about, it's good by me <g>
<fabbione> i don't like autoanswering bots
<Seveas> fabbione, this one only answers on bug id's and urls, specifically rigged to not answer to anything else 
<Seveas> (I hate autoansering bots too :))
<fabbione> let's try
<fabbione> Keybuk: did you see ubuntu 10 and debian 200 ?
<Ubugtu> Ubuntu bug 10: "Ports open but not response from dovecot daemon (hppa)" Product: Ubuntu, Component: gnutls7, Severity: normal, Assigned to: debzilla@ubuntu.com, Status: RESOLVED, Resolution: NOTWARTY http://bugzilla.ubuntu.com/show_bug.cgi?id=10
<Ubugtu> An error has occurred.
<fabbione> there you go
<fabbione> no
<fabbione> it's triggable even talking with other people
<Keybuk> fabbione: that's a useful usecase no? :p
<fabbione> no it's not :)
<Keybuk> because that'll tell *me* what bug you wanted me to read
<fabbione> it floods the channel
<Keybuk> one line isn't a flood
<fabbione> it depends how you read that line.. for me it's like 8
<pitti> fabbione: it's used for ages in #ubuntu-desktop, maybe seb128 and dholbach can share their experience?
<fabbione> and i am at 1600x1200
<Seveas> fabbione, must be a huge font :)
<fabbione> Seveas: a readable font
* ogra_ibook switches to #ubuntu-bugs if he needs the bot ... its one click away
<pitti> for me it's 3 lines, and I only have 1/3 of the screen width for this xchat window
<seb128> pitti: about? Ubugtu? we find it really useful
<pitti> seb128: that's my impression, too
<dholbach> yeah
<seb128> 3 lines here, 1280x1024
<pitti> (otoh my font size is just 8 pixels, or so)
<Keybuk> anyway, like I said, let's trial it and decide after having used and/or suffered it for a while whether we think it's a useful thing or not
<dholbach> same on 1024x768 :)
<dholbach> Keybuk: ++
<Seveas> fabbione, if after the trial period yous till don't like it, there's always /ignore :)
<hordur> pitti: ping
<Diziet> There's too much clutter in the output, certainly.  We don't need to know all of that stuff about the status and the URL is trivial to guess.  The title might well be useful though.
<Diziet> Also, strings like `Product: ' are just wasted space.
<Keybuk> Diziet: sadly Malone URLs aren't trivial :-/
<Diziet> keybuk: Then we should make a redirector so that they can be trivially typed.
<pitti> Diziet: but it's nice to just click on the URL instead of typing it manually
<pitti> hi hordur 
<hordur> hi
<Keybuk> I have to agree with pitti here I think, I like the clickyness :)
<Diziet> Yes, it's nice for the 1% of times you want to visit it but annoying for the 99% where it's just noise.
<Diziet> I'd prefer something like:
<Diziet> <Ubugtu> Ubuntu bug 10: "Ports open but not response from dovecot daemon (hppa)" [gnutls7, normal, notwarty] 
<Ubugtu> Ubuntu bug 10: "Ports open but not response from dovecot daemon (hppa)" Product: Ubuntu, Component: gnutls7, Severity: normal, Assigned to: debzilla@ubuntu.com, Status: RESOLVED, Resolution: NOTWARTY http://bugzilla.ubuntu.com/show_bug.cgi?id=10
<Seveas> Keybuk, actually: malone bugs are trivial
<hordur> pitti so what now?
<pitti> ah, I remember, the hal issue
<Keybuk> Seveas: aren't they /distros/ubuntu/+source/$package/+bug/$number ?
<pitti> hordur: hrm, I have to leave in 10 minutes unfortunately
<Seveas> Keybuk, they all have shortcuts, see ubugtu output
<Seveas> malone bug 1001
<Ubugtu> Malone bug 1001: ""Distribution Members" is confusing" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Needs Info http://launchpad.net/bugs/1001
<hordur> pitti: no problem
<pitti> hordur: do you think you have some time next week?
<pitti> hordur: oh, and welcome in the channel :)
<hordur> pitti: sure, and thanks
<Burgwork> Keybuk, lp being dump https://launchpad.net/distros/ubuntu/+bug/28465
<Ubugtu> Malone bug 28465: "New changes from Debian require merging" Fix req. for: cdebconf (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/28465
<Keybuk> Seveas: but those shortcuts don't have the association to the package they're filed against, so it's harder to change the status, no?
<Burgwork> dumb, even
<Seveas> Keybuk, they're all redirections to the real url
<Keybuk> Burgwork: uh ... why does it do that?!
<Burgwork> jamesh, what is up with that URL is just posted? Not reported in Ubuntu?
<Keybuk> that's got to be new
<Burgwork> Keybuk, the UI is at war with itself (No, its not reported in Ubuntu. Yes it is....)
<Keybuk> that isn't there on the exact copy of that bug I have open in a different window
<Burgwork> Keybuk, different URL
<Keybuk> oh
<Burgwork> I was testing URLs to see what worked and found that breakage
<lamont-away> pitti: how do I get pmount to quit upshifting all the filenames when it mounts a vfat partition?
<pitti> lamont-away: erm, by filing a bug and asking me to add a --vfatnames option, I guess
<lamont-away> I see
<Keybuk> have you paid your licence fee to able to mount said vfat partition? :)
<pitti> lamont-away: shortname=mixed does not DTRT?
<pitti> heh
<lamont-away> pitti: dunno
<pitti> lamont-away: it does what win$ does
<lamont-away> I used to just say 'mount /dev/sdd1 /xx' and pull files... when pmount mounts it these days, all the filenames are uppercase
<pitti> yes, shortname=lower is the kernel default, but it's not compatible to windows
<lamont-away> pitti: except that windoze also does case-insensitive matching in file searches (it seems) - I have at least one CD that was completely busted for browsing, because the links differ from the names-as-seen
<pitti> right
<lamont-away> otoh, must run
<Q-FUNK> hi! I'd like to know, which lines do I need to put in pbuilderrc to add security and updates?
<Burgwork> Q-FUNK, #ubuntu for those sorts of questions
<Burgwork> Q-FUNK, or #ubuntu-motu , sorry
<Q-FUNK> Burgwork: since when is pbuilder an end-user application?
<Q-FUNK> right :)
<Keybuk> ... a paged bug tracking system
<Keybuk> *cries*
<Keybuk> who's idea was that?!
<Burgwork> Keybuk, what do you mean>
<Burgwork> ?
<Keybuk> "21 -> 40 of 76 results"
<Burgwork> ah yes
<pitti> Keybuk: ask Seb, he's in the three-digits
<Keybuk> well, Malone should certainly reduce the number of bugs in Ubuntu
<seb128> Keybuk: "1   20  of 686 results"
<seb128> who wants some? :)
<Burgwork> dholbach, do you have the chance to sync scribus?
<dholbach> Burgwork: sync? merge?
<Burgwork> dholbach, merge. I haven't touched it, but I have some people asking me about it for dapper
<dholbach> Burgwork: i'll have a look
<Burgwork> dholbach, thanks
<Keybuk> good night all
<pitti> Kamion: ppc/install success (offline, German, manual partitioning)
<pitti> Kamion: the ppc/live pproblem just seems to be the usual lagging with a new kernel abi
<pitti> Kamion: oh, no, it's not; the live CD has the powerpc64-smp kernel installed (which boots, but the live system tries to access /lib/modules/2.6.15-12-powerpc/, not powerpc64-smp)
<ogra_ibook> pitti, Kamion infinity: powerpc live CDs appear not to work on my powerbook; I get /lib/modules/2.6.12-powerpc64-smp instead of the correct -powerpc
<pitti> ogra_ibook: right, that's the issue I'm chasing right now
<ogra_ibook> :)
<pitti> Kamion: I'm puzzled; the linux-image-2.6.15-12-powerpc_2.6.15-12.17_powerpc.deb has the correct path, and uname -a shows nothign about powerpc64 or smp; still, the installed system has above ppc64 path in /lib
<pitti> Kamion, BenC: this almost looks like BenC's patch for autodetecting 32/64 selected the 64 bit kernel on my system
<pitti> so iz yaboot bug
<BenC> pitti: can you cat /proc/device-tree/comptaible?
<pitti> BenC: I can, minute
<BenC> compatible
<BenC> and also, can you paste the yaboot.conf somewhere?
<BenC> from the cd
<BenC> also, you can watch the second stage loader and it should say something like "Loading Elf{32,64} kernel..."
<pitti> BenC: compatible: "PowerBook6,3MacRISC3Power Macintosh
<pitti> "
<pitti> BenC: I can't watch it, it appears for like 0.2 seconds
<pitti> BenC: at the busybox stage, there is no /etc/yaboot.conf
<pitti> BenC: do you mean from the cloop image on CD?
<BenC> from /install on the cd
<pitti> oh, squashfs now
<pitti> BenC: http://paste.ubuntu-nl.org/7106
<BenC> file /install/powerpc/vmlinux, please
<BenC> yaboot.conf looks correct
<pitti> BenC: scp is running, ETA 50 s
<BenC> guess I should download the cdimage
<pitti> http://people.ubuntu.com/~pitti/shots/vmlinux
<pitti> BenC: ^ that kernel you wanted
<pitti> vmlinux: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped
<BenC> but I did test the yaboot with a config similar to the one you showed, and it worked on my pb and G5
<BenC> ok, that should be good
<BenC> are you hitting return or typing "live"?
<pitti> just hitting return
<ogra_ibook> i guess its restricted-modules ...
<pitti> but that booted live AFAIK
* pitti tries again
<BenC> canyou try typing live?
<pitti> default=live
<pitti> hmm, shouldn't make a difference
<BenC> shouldn't
<pitti> there are a ton of warnings right before the yaboot screen
<pitti> but waay to fast to read them
<pitti> BenC: same result when typing 'live'
<BenC> wish we had smaller cd images
<pitti> BenC: any idea why I see /lib/modules/...-ppc64-smp in the initramfs?
<BenC> -ppc64-smp or -powerpc64-smp?
<pitti> BenC: if uname -a spits out a name without 64 or smp, I should have the 32 bit image, or not?
<pitti> BenC: powerpc64-smp, sorry (just was lazy)
<BenC> yes
<BenC> cat /proc/version should help too
<pitti> right, 2.6.12-12-powerpc
<BenC> then it booted right
<pitti> BenC: so I do have the normal 32 bit powerpc kernel running
<pitti> and I just checked the .deb
<pitti> it has the correct path
<BenC> yeah, so yaboot did it's job
<pitti> so I wonder where this lib path comes from ?
<BenC> check /lib/modules/
<pitti> what in particular?
<BenC> it just has -powerpc64-smp?
<pitti> 2.6.15-12-powerpc64-smp is the only directory, and it has modules and all
<BenC> does /install/powerpc/initrd.gz correct? (does it contain -powerpc)
<BenC> can you get that for me?
<ssam> todays live wont boot my g4 powerbook either
<pitti> BenC: yes
<pitti> BenC: /lib/modules/2.6.15-12-powerpc
<pitti> whoo, an initd is a cpio archive? interesting
<BenC> initramfs is, yes
<pitti> BenC: anything else I need to do? I actually have to leave now (or actually 30 minutes ago)
<BenC> nah, I understand the problem now
<BenC> I can take it from here
<BenC> thanks
<pitti> oh, cool
<pitti> BenC: what's the reason?
<BenC> sounds like it is overiding the 32-bit entry with the 64-but values (macrisc4 stuff in yaboot.conf)
<BenC> so it is loading hte right kernel, but the wrong initrd
<pitti> so how comes that dir into the initramdisk?
<pitti> if it's not in the kernel deb, and not in the initramdisk...
<Riddell> pitti: did the ubuntu powerpc live CD candidate work for you?
<pitti> Riddell: no, see current backscroll
<pitti> Riddell: <BenC> nah, I understand the problem now
<pitti> BenC: thanks Ben for fixing it
<pitti> ok, time for Friday evening
<pitti> have a nice weekend everybody
<tseng_> bye pitti 
<dholbach> hmmmmmmm
<sivang> you too pitti 
<dholbach> i just tried to merge scribus, it build-depends on python2.4-dev and ends up with a python2.3 dependency
<dholbach> (no dh_python is used), no manual python2.3 dependency
<dholbach> *gnarf*
* dholbach wonders wants wrong
<dholbach> s/wants/what's
<dholbach> if this wasn't b0rked we could just sync it
<dholbach> nevermind me
<dholbach> forget what i said
<dholbach> . o O { must be getting late }
<sivang> dholbach: do you know what the procedure for approving <= 2000 cds from shipit ?
<Burgwork> sivang, talk to marilize
<sivang> err, >= 200 that is
<sivang> Burgwork: it's for someone else, not for me
<Burgwork> sivang, she manages all of shipit
<sivang> Burgwork: should I tell him toe mail here directoly ? or does needs to go through silbs?
<elmo> just place the order, shipit will flag it, if it's super-size-me large
<LaserJock> I was wondering why octave2.9 is in Debian but not in Ubuntu. Is there a place I can go to find out or does anybody know offhand?
<sivang> elmo: ok, and then the requester will get contacted? 
<Burgwork> sivang, likely it will just get downsized by marilize
<Burgwork> sivang, if the person wants lots and can prove the need, they are best left contact marilize directly
<sivang> Burgwork: ok, I'll let him know. what's her email?
<Burgwork> sivang, I think shipit@ubuntu.com works
<sivang> ah right, thanks Corey
<Treenaks> ooh.. shiny new kernelness
<Burgwork> sivang, it appears to be info@shipit.ubuntu.com
<sivang> eh, oops
<sivang> ok, I'll let him know
<sivang> thx again
<mgalvin> Mithrandir: https://wiki.ubuntu.com/LiveCDPersistence
<dholbach> elmo: do you know why octave2.9 is in debian but not in ubuntu?
<Treenaks> BenC: Will drivers get a final upgrade before breezy?
<BenC> ah, it's Kamion's fault that yaboot is broken
<Treenaks> BenC: (I just saw this patch: http://article.gmane.org/gmane.linux.drivers.ipw2100.devel/7063)
<BenC> Treenaks: depends, I'm in "only if it needs it" more right now
<Amaranth> eek, yaboot is broken?
<LaserJock> Seveas: is there a way to tell Ubugtu to not look for a bug in a line?
<Treenaks> BenC: (which will make WPA work in NetworkManager in NM's next release)
<BenC> Aman: only for cd boots
* Amaranth makes a note: don't upgrade yaboot
<Amaranth> oh
<BenC> Treenaks: file a bug report, or email a working patch to kernel-team@lists.ubuntu.com
<Amaranth> i wonder if the bcm43xx driver does WPA-PSK using the card or only with dscape
<Treenaks> BenC: ok
<Seveas> LaserJock, there is no way (yet)
<Amaranth> Seveas: the line should need to say 'bug' or 'malone/supported tracker'
<ogra_ibook> bug is fine
<Seveas> Amaranth, that's already the case
<Treenaks> BenC: hm, on what package?
<LaserJock> Seveas: yeah, maybe if had more stringent syntax
<Amaranth> Seveas: how does "install -m 0644 plotdrop.png $(PREFIX)/share/pixmaps in a Makefile" make it show malone bug 644 then?
<Ubugtu> Malone bug 644: "sharp libgecko-cil (Ubuntu) - Dependencies problem in libgecko-cil" Fix req. for: gecko-sharp libgecko-cil (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Fix Released http://launchpad.net/bugs/644
<Amaranth> ack
<ogra_ibook> yes, chmod 0644 shouldnt matc
<BenC> linux-source-2.6.15
<BenC> someone please tell me there is an archive of packages that get moved out of the pool?
<Seveas> Amaranth, because you say mal.one bug 644 in that line :)
<Seveas> ah
<Seveas> wait
<ogra_ibook> BenC, there is ... but i dont know where 
<Amaranth> Seveas: i meant the commented part
<Seveas> right, there's a call to shorthand too much
<BenC> I _need_
<Seveas> fix0ring
<ogra_ibook> BenC, elmo knows i think 
<BenC> I am _not_ writing this yaboot patch all over again
<Amaranth> does the morgue work?
<ogra_ibook> mdz, seems kdeedu_3.5.0-0ubuntu2 is in the archive, could you start a CD build ? 
<dholbach> Burgwork: done
<LaserJock> dholbach: scribus?
<dholbach> yeah
<Burgwork> dholbach, thanks very much. I owe you one
<LaserJock> sweet, I was just going to start working on a research poster
<dholbach> de rien :)
<dholbach> have a nice evening
<Burgwork> why do packages contain -dfsg in them?
<Burgwork> is it because of policy violations or license problems by upstream?
<Seveas> yes
<sivang> Seveas: which , lcs problem or policy viols ?
<Seveas> afaik could be both, but IANADD
<ogra_ibook> seb128, seems Gtk::EventBox in gtk perl stopped working with the recent gtk upgrade
<seb128> ogra_ibook: file a bug with a testcase and a description of the issue
<ogra_ibook> Can't locate object method "signal_connect" via package "Gtk2::EventBox"
<Burgwork> ogra_ibook, http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.8/gtk+-2.8.10.news
<Burgwork> ogra_ibook, there is other breakage in perl:gtk in the latest gtk
<seb128> right
<ogra_ibook> Burgwork, ah, thanks, couldnt find anything in the changelog
<seb128> don't file a bug :)
<seb128> Burgwork: thank you
<ogra_ibook> i wont :)
<poningru> I had a question regarding libpng
<poningru> I thought if libmng is used you dont need libpng
<BenC> Kamion: ping
<elmo> [Updating]  gal (0 [Ubuntu]  < 2.5.3-1.1 [Debian] )
<elmo> E: gal is trying to override libgal2.4-common_2.5.3-0ubuntu1 without -f/--force.
<ogra_ibook> BenC, he's gone 
<elmo> seb128/dholbach: do we want that version of gal in Ubuntu at all?
<elmo> daniels: should renderext be blacklisted?
<seb128> elmo: get gal, that's a rename of gal2.4
<seb128> and you can drop gal2.4
<elmo> seb128: overwriting the ubuntu changes in gal2.4 ?
<seb128> no Ubuntu change required
<BenC> oh well, fixed yaboot uploaded
<elmo> seb128: k
<seb128> yep
<seb128> thanks
<elmo> daniels: specifically:
<elmo> [Updating]  renderext (0 [Ubuntu]  < 1:0.9.2-1 [Debian] )
<elmo> E: render-dev is in main but it's source (renderext) is not.
<torkel> oh, joy, I'm getting moderator approval mails from ubuntu-bugs when filing bug reports...
<elmo> doko: your turn
<elmo> [Updating]  zopeinterface (0 [Ubuntu]  < 3.0.1-1 [Debian] )
<elmo> E: python-zopeinterface is in main but it's source (zopeinterface) is not.
<seb128> torkel: known issue
<torkel> seb128: k
<seb128> torkel: it will be fixed don't worry
<doko> elmo: zopeinterface is built by zope3, which should be at version 3.1
<LarstiQ> would this be a good place to ask about upstream freezage?
<seb128> maybe, depending of the question :)
<elmo> doko: 'zopeinterface' source package (for 3.0) is in Debian tho - should it be blacklisted or removed from Debian?
<LarstiQ> seb128: basically, blender is trying to release 2.41 before the 19th, but it might slip a couple of days
<LarstiQ> seb128: it is possible to do a release without some of the gameengine fixes if that ensures a place in dapper
<ogra_ibook> LarstiQ, stability > featuritis for dapper 
<seb128> we can probably update the the new version some days after the freeze if that's worth it
<seb128> ie: stable version with fixes, etc
<LarstiQ> ogra_ibook: 2.41 is a bugfix release over 2.40
<LarstiQ> ogra_ibook: so most probably 2.40 is a worse idea
<ogra_ibook> LarstiQ, then it should be possible ...
<seb128> does blender has a nice documented list of changes (NEWS, Changelog)?
<LarstiQ> seb128: fsvo nice, no
<ogra_ibook> (depending on the fixes)
<Tm_T> and again, someone is complaining about console app in kubuntu, saying it work better in ubuntu... ok
<seb128> "fsvo"?
<LarstiQ> seb128: for some values of
<seb128> k
<LarstiQ> seb128: the changelogs are more user oriented
<seb128> because that kind of stuff makes easier to determinate if that's the sort of changes we want
<LarstiQ> seb128: http://blender.org/cms/Blender_2_40.598.0.html is the 2.40 one
* LarstiQ nods
<LarstiQ> seb128: I'll hammer on stability, we'll see if we manage to wrap everything up in time
<seb128> LarstiQ: mail ubuntu-devel when the new version is available with a list of changes and why it would be nice to have it if it comes after the freeze
<LarstiQ> seb128: will do, thanks!
<seb128> np
<seb128> thank you for working on that :)
<linuxboy> hello
<Burgwork> linuxboy, hello. What brings you here today?
<linuxboy> Burgwork: a question :)
<Burgwork> linuxboy, if it is related to support, please ask it in #ubuntu
<linuxboy> I want to know if there is a bash package with....
<linuxboy> --disable-net-redirections
<linuxboy> not used
<Burgwork> linuxboy, if you need that, please file a bug and that sort of question is best asked in #ubuntu
<linuxboy> Burgwork: I don't think its a bug. I just wanted to know if one of the devs had some unofficial package i could use
<linuxboy> if not, I'll make my own
<mdz> ogra_ibook: which CDs?
<Burgwork> linuxboy, if Ubuntu is not providing you something, it is likely a bug, because other people will need it
<ogra_> mdz, edubuntu install images
<mdz> ogra_: in progress
<ogra_> mdz, sadly liboost was silently autosynced over night, i wanted to finish them with kamion this morning...
<ogra_> mdz, thanks
<linuxboy> Burgwork: I don't see this as a bug. I think I'll just make my own package
* Burgwork grumbles
* ogra grumbles about the scribus upload ....
<ogra> mdz, could you trigger another one, scribus was just half built when the image was created, i missed the upload from dholbach
<mdz> ogra: in progress
<ogra> thanks
<tepsipakki> hmm, the devstatus pdf on u-d-a was the same as last week
<ajmitch> morning all :)
<sistpoty> hi ajmitch
<ajmitch> hello sistpoty 
<ulaas> are ubuntu kernels preemptible?
<ajmitch> yes
<ulaas> thnax
<ajmitch> at least dapper's is
<ogra> ARGH !!!
<ogra> DHOLBACH !!!!
<crimsun> uh oh
<ogra> no flight3 for edubuntu 
<ogra> :(((
<ulaas> why oh why?
<ogra> because of a way to quick scribus upload that depends on stuff in universe the images are broken
<ogra> seems debian added a dependency on python
<ogra> err
<ogra> python-imaging-tk
<ogra> what a wasted day
<doko> elmo: please blacklist zopeinterface, ubuntu only, I'll address this in debian with the maintainer
<elmo> doko: k, done, thx
<Burgwork> ogra, I apologize, I asked dholbach for a scribus merge, without thinking of the consquence
<ogra> Burgwork, there shouldnt be a consequence if he had looked at the dependencys ... my prob is now that i wont get python-imaging-tk included before pitti is back on monday, and we wanted to release flight3 then ...
<Burgwork> ogra, still, I did start this stone rolling down the hill. I feel bad
<ajmitch> elmo: please sync hztty, dropping the ubuntu changes
<elmo> "allegro4.2", "kde-icons-nuvola", "kde-style-lipstik", "octave2.9", 
<elmo> ^-- MOTUs, that's the list of "BROKEN" packages in josie atm
<ajmitch> ok, thanks
<elmo> if someone would like to examine them, see if they should be synced or merged, that'd be nice, kthx
<elmo> ajmitch: done
<sistpoty> elmo: kde-icons-nuvola has different sourcepackages in debian and ubuntu... and it's ubuntu version is higher than debians. what do you suggest?
<sistpoty> (it looks that it has been packaged differently)
<elmo> sistpoty: you mean ubuntu packaged it's own version?
<sistpoty> yep
<elmo> ugh
<sistpoty> elmo: should I rename it?
<elmo> $ dpkg --compare-versions 1.0.0-1 \< 1.0.final-2ubuntu1; echo 0
<elmo> 0
<elmo> it's a lower version
<elmo> so IMHO, we should switch to the Debian packaging, if we can, and merge our changes?  or sync if there aren't any
<sistpoty> ok, will do... (and damn, I got --compare-version wrong again *g*)
<elmo> err
<elmo> echo 0 isn't very clever is it
<elmo> anyway, it's still right ;-)
<elmo> (I meant echo $?)
<ogra> elmo, it was most likely packaged ahead of debian by amu, i guess you can take the debian package 
<elmo> ogra: I don't want a guess :-P
<ogra> elmo, i suspect we have some packages of this kind in the KDE area 
<elmo> I want someone to look at it and tell me to sync, or do the merge, based on having looked at the package
* sistpoty will look
<elmo> sistpoty: thanks
<sistpoty> np
<sistpoty> elmo: kde-icons-nuvola can be synced (but would be a lower version then?)
<elmo> sistpoty: no, it'd be higher?
<elmo> 1.0.0 is >> 1.0.final
<elmo> I
<elmo> 'm getting dejavu
<Riddell> elmo: please sync kde-style-lipstik, overwriting ubuntu package
<sistpoty> he, I'm confused, I guess *g*
#ubuntu-devel 2006-01-19
<Riddell> mjg59: do you know anything about powersaved?
<Riddell> like if it's sane to use in kubuntu
<sistpoty> elmo: please sync nvtv from unstable, ubuntu override ok
<LaserJock> elmo: octave2.9 built fine for me in a dapper pbuilder and installs and runs. Is there anything else that would need to be done get it from Debian into Ubuntu?
<elmo> LaserJock: read scroll back
<LaserJock> elmo: so I don't understand how it is broken?
<elmo> [Updating]  octave2.9 (0 [Ubuntu]  < 2.9.4-8 [Debian] )
<elmo> E: octave2.9 is trying to override octave_2.1.71-2ubuntu3 without -f/--force.
<elmo> 22:17 < elmo> if someone would like to examine them, see if they should be synced or merged, that'd be nice, kthx
<mdke> elmo, i know I'm bothering you a lot recently about this, but hopefully you don't mind. it's important for us :) LaserJock for docteam svn access pls
<LaserJock> elmo: I gotta go right now but I will get back to you on octave2.9 Sid has both with octave depending on octave2.1 but I guess when it builds in Ubuntu it wants to depend on octave2.9 and replace octave2.1
<wasabi> Which menu did synaptic disappear to heh
<crimsun> wasabi: it hasn't...System> Administration> Synaptic[..] 
<whiprush> someone from the distro team awake?
<whiprush> jdub: ping
<desrt> man.  i love freenode.
<\sh> ogra: ping
<\sh> well...is it just me, or is ssh -X <remote host> not setting the $DISPLAY on the remote host correctly?
<\sh> both machines were dist-upgraded just now
<desrt> is DISPLAY getting set at all and/or is X forwarding enabled on both ends and/or are you getting any diagnostic messages?
<\sh> desrt: it worked before with just ssh -X 
<\sh> and I can see via ssh -vX that it should be set
<\sh> debug1: Requesting X11 forwarding with authentication spoofing.
<\sh> debug1: Sending environment.
<\sh> I didn't change anything regarding the config.
<\sh> well..let me completly restart my x11 session..
<\sh> give me a sec :)
<\sh> no change
<\sh> strange very strange
<ogra> \sh, works for me
<\sh> ogra: hmmmm....very very strange
<ogra> DISPLAY should be localhost:10.0
<\sh> yes...normally...but it doesn't work a) automatially with ssh -X anymore, and setting it b) manually it won't work either
<pef> someone from laptop team here ?
<ssam> \sh do you have xauth on the machine you are sshing to?
<\sh> ssam: yes
<\sh> ssam: well...as I said, it worked until the last dist-upgrade
<ssam> \sh, ok, thats what usually makes it not work for me
<ogra> what was upgraded ? 
<\sh> ogra: I'm just looking what could change the behaviour of ssh/sshd which is not ssh 
<ogra> ipv6
<\sh> ipv6?
<Treenaks> ipv666
<\sh> debug3: Ignored env DISPLAY
<\sh> thats what ssh -vvv -X <remote> gives me
<Treenaks> \sh: does the sshd allow X forwarding?
<\sh> Treenaks: yes
<\sh> Treenaks: I checked it, didn't change anything, so it was working yesterday morning but strangly not anymore
<ogra> \sh, try setting "AddressFamily inet" and restart sshd
<\sh> ogra: on the remote host, yes?
<ogra> yup
<ogra> in the sshd config
<\sh> nope
<\sh> ebug2: x11_get_proto: /usr/bin/xauth  list :0.0 . 2>/dev/null
<\sh> debug1: Requesting X11 forwarding with authentication spoofing.
<\sh> debug2: channel 0: request x11-req confirm 0
<\sh> and again..ignored env DISPLAY
<ogra> \sh, ignoring display means it ignores the set variable on the client, not the one on the server...
<\sh> ogra: ok...but it's strange, that it doesn't set the env anymore on the remote host
<\sh> how can I debug the connection on the host?
<ogra> ssh -vvv drops out client messages....
<ogra> you can set the LOGLEVEL in the server config to DEBUG3
<ogra> it logs in /var/log/auth.log
<\sh> ogra: that's what I pasted ...
<\sh> ok
<\sh> Jan 14 12:33:41 amd64-home sshd[28464] : error: Failed to allocate internet-domain X11 display socket.
<\sh> Jan 14 12:33:41 amd64-home sshd[28464] : debug1: x11_create_display_inet failed.
<\sh> and before that
<\sh> Jan 14 12:33:41 amd64-home sshd[28464] : debug2: bind port 6995: Cannot assign requested address
<\sh> Jan 14 12:33:41 amd64-home sshd[28464] : debug2: bind port 6996: Cannot assign requested address
<\sh> a lot of those..starting from port 6010
<ogra> and you have set "AddressFamily inet" in the sshd config ???
<\sh> yes
<ogra> weird
<ogra> you also restarted sshd after setting it ? 
<\sh> ogra: what do you think>
<\sh> ?
<\sh> and someone tries to hack my box with a big shitload of standard usernames and a big bunch of normal first names..funny
<\sh> ogra: any other thought?
<ogra> not now, no
<\sh> some tweaks on the xdm configuration should not change the behaviour
<\sh> hmmm...I should reboot the box somehow.
<ogra> xdm ? 
<ogra> not really, no
<mjr> hmh, what was that free (as in speech) multiplatform SIP VOIP solution by that company that also sold call-out?
<ogra> what did you change ? 
<\sh> ogra: nothing..I was thinking to set "listen tcp" on my client side...but this is not the problem at all..ssh -X should work without any modifications on xdm...
<\sh> mjr: skype? which is not sip anyway? 
<mjr> umm, no, skype is as proprietary as can be
<mjr> OpenWengo it was
<\sh> mjr: other sip providers you can usewith any sip compatible client
<ogra> you run xdm through the tunnel ? 
<\sh> ogra: no
<ogra> how else ? 
<ogra> sounded like 
<\sh> ogra: nono 
<siretart> is main still open for merges in 'main'? I just merged a the new pbuilder from unstable, and wanted to ask if it was ok to upload
* HiddenWolf swallows silly joke about business hours
<infinity> siretart: Merges in main are still fine for a while, but don't upload anything that could mess with Kamion's attempts to do a Flight release (ie: I'm holding off on a neon upgrade that will bump SONAMEs and make several packages uninstallable)
<infinity> siretart: pbuilder should most likely be fine and do no harm.
<siretart> infinity: the only change in pbuilder is the change that we don't use cdebootstrap in ubuntu (yet?)
<siretart> I'm currently running the testsuite, of nothing too suspicous happens (I think of cdebootstrap breakage or so) I'm going to upload it
* hunger thinks it would be nice if developers would install a maildaemon so that at least they do see their cron-jobs failing.
<\sh> what is failing?
<hunger> \sh mandb, cups logrotate, occasionally some other things as well.
<hunger> \sh: I keep writting bugreports about the issues I see.
<hunger> Could someone please allow launchpad to send mails to ubuntu-bugs? I get a mail about "waiting for moderator approval" almost each time I report a bug there.
<hunger> \sh: See malone #28529, #6418, #6412, #6414, #6415, #6416.
<Ubugtu> Malone bug 28529: "logrotate script for cups fails" Fix req. for: cupsys (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/28529
<\sh> oh well...another task for konquis "lpbug" searchprovider which I added yesterday..nice
<hunger> \sh: looks like some of the issues got fixed in the meantime... at least the mail cron send me today is somewhat shorter then usual:-)
<\sh> hehe
<hunger> Did somebody look into malone #23388 already? That is targeted for dapper if I understand malone properly.
<Ubugtu> Malone bug 23388: "base (Ubuntu) - tput used in /lib/lsb/init-functions after /usr is unmounted" Fix req. for: lsb lsb-base (Ubuntu), Severity: Minor, Assigned to: Michael Vogt, Status: Unconfirmed http://launchpad.net/bugs/23388
<sivang> hey \sh , already hacking konqueror's stuff to help you work with bugs in malone? :-)
<\sh> sivang: already done :)
<\sh> sivang: kubuntu-konqueror-shortcuts I uploaded yesterday
<sivang> \sh: let me see if I have konq installed, I will install your package :)
<\sh> sivang: if you install kubuntu-desktop it should be installed by default :)
<sivang> eh, it's in main :)
<\sh> sure it is :)
<sivang> (I searched for in universe)
<sivang> bah, 225MB for k-desktop, I guess I will just install konq :)
<sivang> \sh: ok, installed, does it support only what's said in the package description?
<\sh> sivang: what is written in /usr/share/doc/kubuntu-konqueror-shortcuts/README yes...feel free to bug me with more nifty tools for kubuntu searchproviders :)
<\sh> or whatever you need and which is not in the upstream source :)
<sivang> \sh: sure, if I feel too adventures, I Might take a shot at giving you a patch :)
<sivang> \sh: man, konqueror is sweet.
<\sh> sivang: it is
<ulaas> slomo, i cannot ping localhost. and this is a new issue.. any ideas?
<slomo> ulaas: no idea... works fine here
<\sh> check /etc/hosts
<\sh> and check /etc/network/interface if auto lo is in this file
<sebest> ulaas, what error do you have?
<sebest> could be that lo is down or a firewall issue
<ulaas> i cannot even ping my dhcp received ip. but i can ping the server.
<ulaas> there is no error
<ulaas> and no firewall i guess
<ulaas> hmmmmm. strange
<ulaas> how can i check if i have iptable rulez?
<sebest> ulaas, iptables -L, show that everything is accepted?
<ulaas> sebest, oh. chain input is empty..
<sebest> all chain should be empyt, and policy should be set to ACCEPT if the firewall is disable
<olemke> ulaas, try running sudo ifdown lo; sudo ifup lo
<olemke> fixed it for me this morning
<olemke> same for other interfaces
<ulaas> olemke, yeah worked for me. reallly strange.
<ulaas> olemke, just lo made other interfaces start responding as well.
<olemke> ulaas, ah ok
<ulaas> bugzilla depends on mysql?
<\sh> yes
<ulaas> \sh, then why apt only recommends mysql-server
<jdub> ulaas: you might be running your database server on a different machine
<\sh> oh it doesn't depend on it...because it's not necessary to install it on this machine...but bugzilla without a db server makes no sense
<\sh> and I'm totally tired of tracking down libXft.la corpses
<ulaas> jdub, good point.
<hunger> is malone the official tracker now?
<\sh> hunger: yes :)
<\sh> finally
<hunger> \sh: Good... maybe my bugs will be worked no now;-)
<hunger> \sh: ... even though I do prefer bugzilla to lp ...
<HiddenWolf> hunger: you are not the only one.
<\sh> hunger: well...i don't know poke the last uploader :)
<hunger> \sh: I started assigning stuff to people.
<hunger> \sh: I picked the names more or less randomly though, but so far noboby complained;-)
<\sh> lol
<\sh> take me from the list...I'm a bit overloaded right now...have my own adventure running :)
<\sh> fixing kubuntu
<hunger> \sh: Can't... don't know your real name.
<\sh> hunger: good to know that you don't know the /whois command  ,)
<hunger> \sh: LP knows the irc nicks, etc. but it does not list them in the people search page.
<hunger> \sh: Im a IRC idiot... I hang around wherever my irc-client connects me to!
<\sh> hunger: hahahaha
<\sh> I'm happy that launchpad can't work with my nick :)
<hunger> \sh: actually I never wanted to hang out here... but since #ubuntu-devel is the channel I was connected to I started using ubuntu and pester the developers.
* hunger grins.
<\sh> Mithrandir: ping
<\sh> Mithrandir: for what is ia32-libs-kde?
<lmanul> Hey guys, against whihc package should I file my bug if it had been the "linux" product in bugzilla ? There are tons of "linux" stuff in malone, not sure which one I should use (that's the 2.6.15-12 kernel in dapper)
<\sh> linux-source-2.6.15
<lmanul> \sh, Thanks a lot ! :)
<ryanpg> morning all, so I recieved an email on a bug I've filed in ubuntu's bugzilla... when I click the link it says my account has been disabled, due to the switch to malone and to email jeff waugh... before I send off an email, could someone offer come clarification?
<HiddenWolf> ryanpg: bugs got imported into launchpad
<HiddenWolf> ryanpg: should be followed up there.
<ryanpg> HiddenWolf, before I start googling "launchpad ubuntu" do you have an URL explaining this?
<HiddenWolf> launchpad.net
<ryanpg> HiddenWolf, ty
<HiddenWolf> ryanpg: http://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-January/000054.html
<xhaker> hey BenC are you around?
<siretart> elmo: please sync pstoedit_3.42-3 from unstable, ok to override ubuntu changes.
<BenC> xhaker: sort of
<siretart> btw, does james currently process syncs?
<xhaker> BenC: mind to take a look at this bug: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/28433
<Ubugtu> Malone bug 28433: "source-2.6.15 powernowd (Ubuntu) - speedstep-centrino doesn't load on pentium m laptop" Fix req. for: linux-source-2.6.15 powernowd (Ubuntu), Severity: Normal, Assigned to: Debian Bug Importer, Status: Confirmed
<xhaker> haha
<xhaker> yeh
<xhaker> the one the bot spit
<xhaker> gonna make my lunch
<xhaker> bbl
<hunger> Could someone please move ifupdown-clean after checkroot.sh in /etc/rc.S?
<hunger> is mounted ro when ifupdown-clean is run, so it fails to clean... which makes ifup think lo is already up, skipping it.
<Mithrandir> \sh: for the ooo2 kde widget stuff on amd64.
<\sh> Mithrandir: do you need to rebuild them, if there are libXft.la corpses in kdes .la files? 
<\sh> jdub: I'm proud of you that you finally spamed the planet today and not me :)
* sivang checks planet
<Mithrandir> \sh: well, it doesn't work correctly, so *shrug*
<\sh> Mithrandir: i'm just asking, because I'm cleaning kde from libXft.la references ... I'm just finished with it...and I was wondering if we need to rebuild it as well...but when you say: "go away, this package is heavily broken" I'll leave it to you ;)
<Mithrandir> \sh: haha, sure, I can rebuild it
<\sh> Mithrandir: rock :) thx :)
<sivang> \sh: do you know how to fix bzrtool not installable problem on dapper?
<sivang> (everybody told me they rebuilt from source, but that didn't work for me)
<\sh> sivang: use the daily snapshots from jbailey
<\sh> deb http://people.ubuntu.com/~jbailey/snapshot/bzr ./
<\sh> deb-src http://people.ubuntu.com/~jbailey/snapshot/bzr ./
<jblack> Flash isn't working right on my system. I get audio, but no video
<sivang> eh, weird, those were once in my sources list, I must have removed them or something, thanks
<sivang> jblack: James, how's you besides the flash problem? :)
<\sh> sivang: but bzrtools is installable on dapper...I just did it (from ubuntu archives)
<jblack> sivang: I'm good. And you?
<HiddenWolf> jblack: this is not a support channel
<HiddenWolf> jblack: please file bugreport or ask for help in #ubuntu
<jblack> Whoops. I'm in the wrong channel.
<jsgotangco> jblack, nice seeing you again :)
<jblack> js: Hey buddy.
<jblack> jsgotangco: You coming to the next conference? 
<sivang> jblack: there's already a next one planned? :)
<jblack> Not yet. 
<sivang> \sh: I have jbailey's sources, still does not owrk
<jsgotangco> jblack, i hope so dunno where it is yet...been busy with work in au
<jblack> jsgotangco: I know the distro side of the house just went/possibly still are, somewhere. I think Brazil.
<jblack> Or the UK, now that I think about it.
<HiddenWolf> jdub: planet messed up.
<jsgotangco> yay planet jdub 
<sivang> hehe
<pef> I've a question about sponsored uploads, should I leave motu hopefull name on changelog, or use mine and put "sponsored upload for..." in the changelog ? what pros and cons for each method ?
<\sh> pef: leave motu hopful names
<\sh> pef: debuild -S [-sa]  -k<your key uid> is the match :)
<pef> \sh: exactly what I need, thank you :)
<\sh> time to grab some food somehow....
<sivang> \sh: ordering a pizza could be a rememdy, I do that when I feel incompetent to prepare or get food :)
<\sh> sivang: for that I have to go out of my flat, go to a hole in da wall and get some cash :)
<sivang> eh, I see :) bullocks all those pizza places that don't take credit cards for deliveries :)
<\sh> sivang: credit cards in germany and mobile pizza services are too stylish ;) 
<sivang> actually in here as well, I always envy my NYC cousin when he tells me he oders pizza online :)
<\sh> sivang: some services have it (order online) but payment is just still "cash at the frontdoor"
<sivang> outrageous :)
<\sh> actually...I have to get up now (laying in bed the whole day and pbuilding, patching and uploading is quite nice...but it's not healthy)
<StevenK> \sh: Sure it is. :-)
<sivang> \sh: right, might get your body parts fall asleep
<\sh> StevenK: no it's not :) it was dark night when I started, and it's dark now..something is totally wrong with me...
<\sh> bbl
* sivang he coudl go back to working from night to night as he once did
<jsgotangco> hey guys good night :)
<jsgotangco> its almost 2am here
<jsgotangco> heh
<j^> hi, i have a bug filed against network-manager that should be moved to the kernel, since its the iwp2100 module that failes.
<j^> the problem is, i cant find any kernel product in launchpad
<HiddenWolf> j^ try linix-source
<j^> HiddenWolf the' Select Product' windows does not find anything
<HiddenWolf> Then I do not know
<siretart> j^: try linux-source-2.6.15
<j^> oh, the problem was that the bug was not agains ubuntu/network-manager, but network-manager/upstream
<siretart> infinity: lamont-away: can anyone explain me why 'guichan' isn't even tried to be build? it doesn't even appear in http://people.ubuntu.com/~lamont/buildLogs/Lists/breezy.all.i386, but the source is here: http://archive.ubuntu.com/ubuntu/pool/universe/g/guichan/
<siretart> it looks to me like wanna build wouldn't know about it at all *headscratching*
<lamont-away> siretart: could it be that it was dropped from dapper?
<\sh> siretart: check dapper :)
<\sh> siretart: not breezy
<psusi> mjg59, you around?
<siretart> gnarf
<siretart> lamont-away: so it is in dep-wait. could you do something about that then, please? :)
<BenC> yummy, working sound on my PB
* BenC charges a beer from anyone that benefits from it
<zul> whoa...you get a beer!
<siretart> can't we make libgl-mesa-dev just provide xlibmesa-gl-dev? It would reduce a good bunch of unnecessary divergence
<psusi> BenC, does the kernel free the memory used by the initramfs?  and if so, how and when?
<\sh> siretart: it's only a matter of time when it's going away...
<\sh> ok..relaxing time now :) last samurai should be a nice movie to watch for relaxing
<\sh> cu later....
<crimsun> psusi: no, it doesn't.
<BenC> crimsun: yes, it does
<BenC> it free's the initial initrd space
<BenC> and after pivoting out of the initramfs to the real root, I believe it also free's the initramfs space
<crimsun> BenC: right, but ... ok, I'll update the documentation
<BenC> I'd hate for 10-20 megs of memort to just remain used for no reason :)
<psusi> BenC, it tries to you mean right?  if a process starts in the initramfs and continues to run after the pivot, it can't free it right?
<crimsun> if we haven't made any changes to the initramfs code in the kernel, then it isn't freed according to Documentation/filesystems/ramfs-rootfs-initramfs.txt
<psusi> then the question is, does it get freed when that process eventually does terminate?
<psusi> oh my, that would be bad
<BenC> psusi: right
<crimsun> there's a fairly lengthy thread on lkml with Al Viro's comments on why that memory isn't freed
<BenC> hmm, then I guess the ramdisk stays around
<Mithrandir> psusi: run-init rm-s everything in the initramfs.
<psusi> oh my, that sucks... I'll search for that thread
<Mithrandir> BenC: sure, but how much does an empty tmpfs mount cost you?
<psusi> Mithrandir, ahhhh!
<crimsun> Mithrandir: awesome, that's what I was hoping to find
<psusi> then yea, space is freed when the process terminates ;)
<psusi> very cool
<crimsun> psusi: if you're interested, this is what Al said about it: http://www.ussg.iu.edu/hypermail/linux/kernel/0311.2/0191.html
<Mithrandir> if you have something which opens a file in the initramfs, but doesn't close it, that space is kept, though the file is removed.
<psusi> Mithrandir, right, like a running process's binary... but it will be freed when the file is closed ( when it terminates )
* psusi wonders if there is a way to get back to the initramfs after the real root has been mounted over it
<psusi> why does /initrd still exist?  pivot_root isn't used with the initramfs right?  it just mounts the new fs on top of / right?
<crimsun> psusi: right. (http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blob;h=b3404a0325967de5fdce4a29e879258075ede500;hb=615a7c0f63d4c82acee5124138e9f53c5969cd0d;f=Documentation/filesystems/ramfs-rootfs-initramfs.txt)
<ulaas> package configurations fallback to console. it seems it cannot launch gtk interface. any ideas?
<ulaas> debconf: unable to initialize frontend: Gnome
<ulaas> debconf: (Can't locate object method "signal_connect" via package "Gtk2::Window" at /usr/share/perl5/Debconf/FrontEnd/Gnome.pm line 73, <> line 14.)
<ulaas> debconf: falling back to frontend: Dialog
* attroja is away: I am away from IRC at the moment.
<mdke> elmo, Znarl, statutory ping about LaserJock's docteam svn access 
<j^> launchpad keeps sending me "Your message to ubuntu-bugs awaits moderator approval" messages
<j^> *mailman send them, for each bug i file in launchpad, for each list that is subscribed to the bug
<lamont-away> jdub: how about a link on bugzilla.u.c taking us to malone>?
<j^> or a redirect from http://bugzilla.ubuntu.com/ to https://launchpad.net/distros/ubuntu/+bugs
<lamont-away> fortunately, google got me there in under 3 links
<j^> http://bugzilla.ubuntu.com/ links to https://launchpad.net/distros/ubuntu/+filebug | https://launchpad.net/ | https://launchpad.net/distros/ubuntu/+bugs/+login
<lamont-away> this is neat.   I _know_ that there's a way for me to actually close a bug....
<Nafallo> lamont-away: click on what you want to change basically :-)
<lamont-away> have I mentioned this week that hiding links all over the t)%&*&%*_^(+ page is an absolutely non-intuitive interface?
<j^> way to many links
<lamont-away> j^: it's more the total lack of any indicator that it _might_ be a link.
<lamont-away> so I get to wave my mouse all over the page to see what might be one... awesome.
<lamont-away> </sarcasm>
<j^> +editstatus :)
<j^> to me it looks like +edit and +editstatus should be one page
<Burgundavia> j^, the moderator approval thing is known
<Burgundavia> there are a great number of pages that need to be combined
<j^> "Report a Bug in XYZ in ubuntu" should go from the view of an individual bug, thats not an action on the bug itself
#ubuntu-devel 2006-01-20
<mdke> haha jdub is the new \sh on planet
<lexhider> Is there anyway to view all the bugs I'm subscribed to in malone?
<LaserJock> lexhider: yeah, go to your launchpad page
<lexhider> https://launchpad.net/people/lex-hider/ ???
<LaserJock> lexhider: on the right side bar there is a link to "Bugs" and on that page there is a link to "Bugs Subscribed"
<j^> https://launchpad.net/people/lex-hider/+subscribedbugs
<LaserJock> yeah, ^^ too ;-)
<lexhider> LaserJock, thanks, that's exactly what I was after.
<LaserJock> lexhider: np
<lexhider> can someone with the appropriate privileges close:
<lexhider> https://launchpad.net/distros/ubuntu/+source/xine-lib/+bug/12793
<Ubugtu> Malone bug 12793: "lib (Ubuntu) - Trying to play RealAudio makes totem freeze" Fix req. for: xine-lib (Ubuntu), Severity: Normal, Assigned to: Sebastien Bacher, Status: Confirmed
<lexhider> actually, I think I may have privileges after all, since I didn't commit any fixes, do I close "fix committed" or "fix released"?
<LaserJock> lexhider: I believe "Fix Released" will close it
<lexhider> LaserJock, what does "fix released" mean?
<LaserJock> lexhider: means a package that fixed the bug has been uploaded/released, at least that is my interpretation of it
<lexhider> does making the status of a bug "rejected" close the bug?
<LaserJock> lexhider: I believe so, yes
<lexhider> should an ubuntu bug that then opens an upstream bug be marked as confirmed?
<psusi> lexhider, no, it should be marked as upstream
<lexhider> now I'm confused. check out: https://launchpad.net/distros/ubuntu/+source/evolution-data-server/+bug/12430/+editstatus
<Ubugtu> Malone bug 12430: "data-server (Ubuntu) - evolution weather calendars only for US" Fix req. for: evolution-data-server (upstream), Severity: Normal, Assigned to: Sebastien Bacher, Status: Unconfirmed
<lexhider> status is "unconfirmed", but then has status=UPSTREAM
<psusi> I don't know if I will ever get used to malone
<psusi> I certainly wish the UI wasn't so foofy
<psusi> and looking at that bug, malone itself is broken... the "milestone" and "remote bug details" drop down lists are extending over top of the * overview * bugs menu to the right
<psusi> it seems that malone does not have a status=upstream as a choice
<Burgundavia> psusi, I think you are supposed to link the upstream bug tracker to a bug in malone
<lexhider> It is misleading to see your bug is unconfirmed when it is really upstream. To me unconfirmed means that no one has looked at it.
<psusi> Burgundavia, you need to mark the bug in malone as upstream and link it to the upstream bug
<Burgundavia> psusi, no, idea
<psusi> lexhider, aye, "In progress" sounds like a closer match
<psusi> I seriously can not stand malone though... god damnit... 
<psusi> where are MY bugs?
<psusi> can't search by reporter, wtf?
<lexhider> need to go to your version of this page: https://launchpad.net/people/lex-hider/+reportedbugs
<psusi> ahh, I knew I had done that somehow before... WTF is there not a link to that on the normal bugs page?
<psusi> I'm going to have an anuerism trying to use malone instead of bugzilla
<psusi> Mithrandir, what is the current upstream status on that e2fsprogs header issue?  last I heard you had notified upstream... 
<psusi> anyone ever used gdb to debug a multithreaded app?  I've got a problem debugging a crashing 7zip where the process terminates out from under gdb after it catches the SIGSEGV
<psusi> what's the deal with klibc?  should things that go in the initramfs be using it or not?
<zul> how do you close a bug in launchpad?
<zul> oh...never mind
<zakame> hi devs :0
<zakame> :)
<psusi> what is the deal with klibc?  should things in the initramfs use it or the normal libc?
<psusi> hrm... I updated a bug on malone, and it looks like it tried to send an email to ubuntu-bugs and the message bounced back to me saying it's a members only list
<fabbione> psusi: i am not sure why you reassigned the dmraid bug to me, but i am going in holidays right now. nobody will look at it for the next week or more
<fabbione> it was assigned to adconrad for a reason :)
* fabbione takes off for vac
<fabbione> bye
<psusi> fuck
<psusi> adconrad said he had no idea why it was assigned to him... heh
<\sh> infinity / lamont-away: can one of you please have a look on gnotime 2.2.2-1 (which was a sync from debian, which compiles without any hassle in my pbuilder, but it's failing because of dependencies since the sync on the buildd)
* #ubuntu-devel  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
<lexhider> is https://launchpad.net/distros/ubuntu/+source/firefox/+bug/13214 a firefox or gnome-session bug?
<Ubugtu> Malone bug 13214: "firefox (Ubuntu) - Mozilla-firefox complains that gnome-session can not remember it's settings" Fix req. for: firefox mozilla-firefox (Ubuntu), Severity: Normal, Assigned to: Ian Jackson, Status: Unconfirmed
<sivang> morning all
<\sh> elmo: please sync g-wrap from unstable, dropping ubuntu changes ok
<lexhider> robitaille, regarding bug #13214, how did you assign the upstream bug to the correct mozilla bug, that's what I wanted to do, I just couldn't see how to do it.
<robitaille> lexhider,  I added a bug watch first.  Then did the assignment.    I'm also learning all that stuff :)
<lexhider> ok, how do I add a bug watch ?
<robitaille> right-hand side, in the "remote bug watches" box.  Click "add"
<pef> hello
<lexhider> robitaille, if a bug is upstream, should it be marked confirmed or "in progress" instead of unconfirmed?
<robitaille> I think it could be confirmed, since we are all experiencing it.  Reading from that mozilla bug report, I wouldn't say that's it is "in progress", it ssems to be a very quiet bug
<\sh> elmo: please sync ncbi-tools6 from unstable, dropping ubuntu patches, thx
<infinity> elmo: sync wvdial from unstable, please, overwrite okay.
<Lathiat> Has anyoen else had problems with LVM and dapper?
<Lathiat> it didnt work for me (failed to boot) and a mate just told me the same thing
<pef_aw> Lathiat: what's the problem ? (I use lvm)
<Lathiat> pef: they dont come up on boot
<Lathiat> and so it doesnt work as my root was on lvm
<pef> Lathiat: when did you got this problem ? since a recent upgrade or since first install ?
<Lathiat> upgrade
<Lathiat> from working breezy
<Lathiat> in both cases
<pef> Lathiat: on a fresh install of Dapper all is fine, maybe the upgrade miss something ?
<pef> I have / on lvm
<pef> Lathiat: are you using characters like - in your volumes /logical volumes ? 
<Lathiat> nope
<Lathiat> just 'root'
<Lathiat> Ubuntu-root
<Lathiat> (standard install option)
<pef> Lathiat: have you more precise errors messages ?
<Lathiat> the volume group doesnt initialize, e.g. /dev/mapper is empty, no error other than cant find root device
<Lathiat> works fine again if i say, boot the breezy livecd
<lexhider> anyone know what malone classifies as an "untriaged" bug?
<siretart> who is listmaster for ubuntu-bugs?
<ogra_ibook> siretart, jdub
<siretart> seems to be mdz
<ogra_ibook> he's working on the filter afaik
<siretart> ok,
<siretart> then I don't need to bug them
<vurdak> good morning to all
<pef> which part of ubuntu generates /etc/fstab ? base-installer ?
<tenco> hi
<tenco> i have a problem with dapper kernel 2.6.15
<Ubugtu> Linux kernel bug 2: "NUMA-Q hangs during TSC initialization on boot." Product: Platform Specific/Hardware, Component: i386, Severity: normal, Assigned to: mbligh@mbligh.org, Status: CLOSED, Resolution: CODE_FIX http://bugzilla.kernel.org/show_bug.cgi?id=2
<tenco> while powernow-k7 support works in breezy with kernel 2.6.12 it does not with 2.6.15 in dapper
<Ubugtu> Linux kernel bug 2: "NUMA-Q hangs during TSC initialization on boot." Product: Platform Specific/Hardware, Component: i386, Severity: normal, Assigned to: mbligh@mbligh.org, Status: CLOSED, Resolution: CODE_FIX http://bugzilla.kernel.org/show_bug.cgi?id=2
<tenco> how do i make a kernel package with an vanilla kernel, so i can check if this bug originates from kernel changes or is a bug in the ubuntu package?
<tenco> *sigh*
<ogra_ibook> Seveas, !
<ogra_ibook> Seveas, whats the bugbot doing there ? 
<Mez> jdub, ping
<tenco> ok, https://wiki.ubuntu.com/KernelBuildpackageDetailedHowto?highlight=%28package%29%7C%28kernel%29
<Mez> actually - it's what time there?
<tenco> bye
<Mez> is it still just jdub who runs planet?
<Burgundavia> Mez, yep
<Mez> darn :)
<Mez> I need him to remove me from there
<Burgundavia> Mez, jdub is +13 I believe
<Mez> so 2am :D
<mdke_> Mez, planet is broken at the moment and people can't be added/removed
<Mez> mdke_, hmmm
<mdke_> hopefully it will be fixed soon
<mdke> jdub is working on it
<Mez> see thats a problem - my server has dissapeared in the night :D
<Mez> lol
<mdke> why a problem?
<Mez> cause well - it means i have to move host and stuff
<Mez> and have lost ym blog and stuff
<Mez> and URL will be changing anyoo
<mdke> shouldn't be an issue for planet i don't think
<Seveas> ogra_ibook, keybuk asked for it
<Seveas> so complaints can go to him (I warned hem that people in here had some objections)
<mdke> Seveas, it is responding to things which aren't bugs
<mdke>  [11:21:59]  < tenco> i have a problem with dapper kernel 2.6.15
<mdke>  [11:22:02]  < Ubugtu> Linux kernel bug 2: "NUMA-Q hangs during TSC initialization on boot." Product: Platform Specific/Hardware, Component: i386, Severity: 
<mdke>           normal, Assigned to: mbligh@mbligh.org, Status: CLOSED, Resolution: CODE_FIX http://bugzilla.kernel.org/show_bug.cgi?id=2
<Ubugtu> Error: Unknown bugtracker
<Seveas> mdke, actually 'kernel' is a defined bugtracker
<Seveas> s/is/was until a few seconds ago/
<ogra_ibook> Seveas, thanks ... 
<ogra_ibook> Seveas, i can live with the bot, but that behavior seemed a bit wrong ;)
<Seveas> it was correct, but quite annoying, so I removed all bugtrackers that could be followed by version numbers, like 'kernel 2.6' or 'gcc 4'
<mdke> hi infinity, any progress on ubuntu-docs?
<Tm_T> err, what happened to locale settings
<Tm_T> dpkg-reconfigure locales doesn't give any setting dialogs anymore and locale.gen file isn't used anymore at all?
<triceratops> Is there a chance to have trafficwatch as a Dapper deb? It might be very interesting for small office environments, schools, and for me af course. :-)
<siretart> triceratops: did you already package it?
<triceratops> siretart: Hhhm, I know this question will come up. :-)) No, never did a package. 
<siretart> triceratops: I'd suggest that you file a support request in launchpad then
<ulaas> TrafficWatch is packaged as a Debian package, so Debian sarge/sid users can add the APT source:
<ulaas> deb http://software.trinity.unimelb.edu.au/trafficwatch/source/ ./
<triceratops> siretart: There is a deb, but it depends on python2.4-biggles which is uninstallable in Dapper due to dependencies on libplot2 but Dapper offers libplot2c2
<ulaas> maybe this helps no?
<ogra> ulaas, that doesnt help ubuntu users
<ogra> unless you want to build the package yourself
<triceratops> siretart: I  file a support request in launchpad
<ogra> (assuming there is a source package in the repo)
<triceratops> siretart: s/I/I will/
<ulaas> ogra, some sid/sarge debs are spoosed to work. right?
<siretart> ulaas: not necessarily
<ulaas> yeah sure, but trial and error does not kill eh?
<siretart> ulaas: our libraries are compiled with gcc-4.0, sarge with gcc-3.3. C++ apps are likley to break
<triceratops> siretart: But I'm not sure should I request trafficwatch or python2.4-biggles?
<Tm_T> uh, so no idea with my locale issue?
<siretart> triceratops: we already have python2.4-biggles. if it does not work, then a bug should be rather filed
<Tm_T> all was fine until I upgraded locales today
<triceratops> siretart: Thats what I wanted to know... :-)
<siretart> triceratops: I think its best when you assign it to MOTU
<ogra> ulaas, additionally to what siretart said, we'll have most likely differing dependencys 
<triceratops> siretart: python2.4-biggles isn't registered in lanchpad yet... *?*
<siretart> ulaas: whats even worse: debian and ubuntu share packages with the same name and version, but different contents including different dependencies. tools like apt are known to break in this case
<ulaas> ogra, it seems that way. yeah. i just wanted to tell that i had luck installing some debian debs without pain in the past.
<siretart> ulaas: so it could work in simple cases, but are likley to break horribly in general
<ulaas> siretart, sure. agreed.
<triceratops> siretart: What exactly do you want me to do, "I think its best when you assign it to MOTU"?
<siretart> triceratops: assign it to 'universe-bugs@lists.ubuntu.com'. thats the contact address for MOTUs in launchpad
<siretart> triceratops: that way it will show up on my tickets list
<triceratops> siretart: Ok, I will do so... Thanks a lot
<triceratops> siretart: Done...
<siretart> https://launchpad.net/people/motu/+tickets is empty :(
<triceratops> siretart:  Bug #28611 in python-biggles, assigned to MOTU
<siretart> ah, you filed a bug, not a support request. I see
<triceratops> siretart: Should I do a support request?
<siretart> err, wtf? can anyone access https://launchpad.net/distros/ubuntu/+source/python-biggles/+bug/28611
<Ubugtu> Error: I cannot access this bug.
<siretart> same here
<triceratops> siretart: Hhhm, URL works for me... *?*
<siretart> I get a  Sorry, you don't have permission to access this page.
<Lathiat> it makes me login
* Lathiat logs in
<Lathiat> yeh, asme
<triceratops> siretart: Uuups, might be I made a hook on 'keep private' while filling the bug. Any idea how to make it public again? I don't see this option in the moment...
<siretart> triceratops: aha. well, I think on the right side, there should be means to change bug status and so on
<triceratops> siretart: found the right place, 'Bug Secrecy'. Hard to find, adding a checkbox whithin the listed bug properties might be a better place...
<sivang> siretart: I can see it
<siretart> sivang: now its okay :)
<ulaas> does anyone knows the main difference between opendarwin and appledarwin? i did not seem to find a doc about it
<pkern> What kind of initramfs brokeness do you expect? I just did a dist-upgrade to dapper, tried to run lilo which failed because of dm brokeness, then installed grub which seemingly does not work with lvm-on-root. It complains about the sudden end of compressed data (I guess the initramfs is meant), then about root being on invalid 0,0.
<ssam_> ulaas, i know opendarwin is short of a few drivers (eg broadcom)
<ulaas> ssam_, hmm. is that all?
<Tm_T> this is interesting... i reinstalled locales 5 times nad now it works again, finding corner where to shame ->
<pkern> ulaas: OpenDarwin merges all changes to Apple's Darwin (which is the master copy) into itself. They lack proprietary drivers and Apple's GUI.
<pkern> ulaas: So you get the kernel and some userspace stuff, just like Apple's Darwin; but without any of which is commonly known as OS X.
<sivang> phee, python is sweet. I just turned a class from eating a string as parameter, to a list of strings, which made it in about 2 extremly small one line changes, 100% more useful. neat.
<pkern> ulaas: It's just that they package it as something which could be independently installed from OS X, and provide support for it.
<pkern> ulaas: pm ;)
<pkern> So either the initramfs is broken... or well... I should try to give the kernel major und minor, probably.
<pkern> Hm. 2.6.15-k7's kernel is 1,4M, its initrd 2,0M; 2.6.12-10-k7's initrd was 6M
<pkern> So if gunzip isn't expected to fail with initramfs images, it is indeed broken.
<siretart> pkern: initramfs creates cpio archives
<pkern> siretart: Ew, yes. But gunzip -c shouldn't fail anyway? file says it's gzip compressed.
<pkern> Interessting.
<pkern> After a remove/purge cycle it has 6,3M
<pkern> So I got to reboot. Perhaps it does work now, but I still doubt that the kernel will recognize 254,3
<pkern> |:
<siretart> elmo: could you please have a look why we don't have crafty from unstable in universe yet? last upload to debian was dec, 8, 05
<mdke> the css on packages.u.c is screwed too, like planet, does someone need to be bugged about this?
<mdke> i guess they were relying on the old plone css, which disappeared when the new site came in
<Seveas> mdke, Frank Lichtenheld is responsible for that page
<jdub> elmo, Znarl: any time you want to switch to humboldt for planet is good.
<irvin> Seveas, is Frank available on freenode?
<irvin> i sent him an e-mail weeks ago about something else, no reply yet :(
<siretart> elmo: please sync dosage from unstable, ok to override ubuntu changes!
<slomo_> elmo: please sync gazpacho,pygame from unstable... ubuntu changes can be dropped... and please delete the gtk-sharp2-unstable source package as it was renamed to gtk-sharp2 some time ago and will only confuse users
<Seveas> irvin, no idea
* irvin is away: I'm busy
<siretart> elmo: please sync teleport from unstable, ok to override ubuntu changes
<siretart> elmo: please sync cyphesis-cpp from unstable, ok to override ubuntu changes
<Seveas> elmo/znarl, around?
<Riddell> ogra: I might be able to build CDs
<ogra> ohoel, could you trigger a edubuntu install build ? 
<ogra> s/ohoel/oh
* ogra kicks his tabkey
<dholbach> If you kick your tabkey all the time, it's no wonder it does stuff like that.
<ogra> lol
<Riddell> ogra: started
<ogra> thanks :)
<ohoel> ogra: gnome.org forced a nickchange.. blame them! :)
<ogra> nah, i should just stop hitting tab instead of the comma ...
* ogra looks at his keyboard ...
* ogra scratches head
<giskard> hello dholbach :)
<siretart> tab key is empty? ;)
<dholbach> hey giskard :)
<dholbach> hi siretart :)
<ogra> siretart, nope, i just looked at their locations... 
<siretart> huhu dholbach 
<mdke> anyone else getting connection refused when trying to apt-get update? all my computers are getting it
<siretart> mdke: I switched to an alternative mirror
<Seveas> mdke, yes a.u.c is down it seems
<Seveas> or at least apache at that machine
<mdke> siretart, us works?
<BenC> anyone know how to use malone to find all bugs targeted for linux-source-2.6.15 in pending upload state?
<dholbach> BenC: search for the source package name sort by status, maybe?
<BenC> nope
<BenC> linux-source-2.6.15 isn't a product
<dholbach> search for the source package on https://launchpad.net/malone/distros/ubuntu
<dholbach> it seems that you can't sort statuses :/
<BenC> it only shows 56 bugs
<xhaker> BenC: did you take a look at the dothan centrino.c "bug"
<BenC> and I knownot yet
<ogra_> Riddell, damned, seems gcj is still building on ppc, so the ppc build failed ...
<BenC> this really sucks, I can't figure out a way to close bugs I marked as pending upload in bugzilla
<dholbach> BenC: you better ask on #launchpad
<Riddell> ogra_: let me know when you want me to run it again
<dholbach> BenC: maybe they know a clever way to figure it out
<ogra_> Riddell, thanks ... will take a while i guess ...
<Riddell> BenC: do you know if the problem with powerpc live CDs got sorted?
<dexem> BenC, bugzilla is still open to search for old bugs... maybe that's enough for you (but you won't be able to close them :( )
<BenC> Riddell: should be, yaboot got synced to debian version, and dropped my patches
<ogra_> but there is no new livefs yet
<ogra_> someone (infinity or Kamion) needs to build it
<siretart> BenC: https://launchpad.net/distros/ubuntu/+bugs-advanced?field.searchtext=linux-source-2.6.15&search=Search&orderby=-priority%2C-severity&field.assignee=&field.unassigned.used=&field.include_dupes.used=&field.statusexplanation=&advanced=1&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.status-empty-marker=1&field.severity-empty-marker=1&field.attachmenttype-empty-marker=1
<siretart> BenC: https://launchpad.net/distros/ubuntu/+bugs-advanced and enter your search query
<siretart> mdke: de. works. I don't know about us.
<BenC> siretart: how do you get to that without a hard link?
<mdke> siretart, even better
<BenC> siretart: did I miss something in the interface?
<siretart> BenC: I just used this form: https://launchpad.net/distros/ubuntu/+bugs-advanced
<BenC> but how did you navigate to that advanced search page?
<BenC> because I didn't see it
<siretart> BenC: on https://launchpad.net/distros/ubuntu/+bugs, there is on the right side a link called 'advanced search'
<BenC> ah, ok
<BenC> thanks
<siretart> BenC: I complained about more advanced searching in malone before, and was given the notice, that there IS an advanced query page, but not on each package itself, but only on the distro bug page
* sivang -> back
<siretart> I find it quite confusing, too, but *shrug*
<BenC> it should be more available
<zenwhen> hello
<BenC> shouldn't have to search for the advanced search page
<siretart> yeah
* siretart loves bug topics like malone #3122
<Ubugtu> Malone bug 3122: "elmo crashes on startup" Fix req. for: elmo (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Unconfirmed http://launchpad.net/bugs/3122
<zenwhen> who made the decision to make xchat-gnome the default IRC client in dapper
<BenC> zenwhen: pretty surf it wasn't a who, but more of a group agreement
<BenC> s/surf/sure/
<sivang> siretart: heh
<ogra> (not from my side though)
<mdke> i read here that mdz approved it
<zenwhen> oh
<zenwhen> I suppose I just wanted to voice my opnion that it was a really badmove to make such an unfinished and optionless IRC client default in such a polished distro as Ubuntu.
<BenC> really?
<BenC> I use it, and it seems to be perfect for my needs
<ogra> my biggest concern is that the userlist is stuck on the left side... and the topic handling sucks, but the latter is obviously being worked on upstream
<BenC> certainly doesn't make it unfinished and optionless
<ogra> nope
<zenwhen> you cant even turn off the intentation line
<LaserJock> yeah, I tried xchat-gnome out and was really frustrated with its lack of options and the userlist thing so I went back to xchat
<ogra> its much more integrated with the desktop
<zenwhen> indentation*
<mdke> is this another options debate?
<zenwhen> Well, I suppose in a way it is. 
<ogra> mdke, its sunday ...
<zenwhen> I cant picture myself ever using this and most of the people I have talked to hate it.
<mdke> best time for one :)
* mdke goes off to the kitchen
* dholbach likes it.
<zenwhen> I am trying to find the deb for 0.8
* ogra doesnt use it until he can flip the layout
<zenwhen> to make sure it hasnt actually improved
<BenC> day to day use, I don't think xchat gnome is all that bad
<dholbach> zenwhen: it's in dapper
<BenC> most people don't want dozens of options they'll never use
<BenC> most people want simple defaults with power options as an add-on
<psusi> I'm using xchat... works fine for me
<psusi> and if xchat weren't there I'd be using chatzilla in firefox
<zenwhen> I suppose as long as Xchat is still packged, I shouldnt worry about it. I am just afraid it will make new users think "wow I miss mIRC"
<Amaranth> ?
<psusi> bitchx >>>> mirc ;)
<zenwhen> speaking of xchat-gnome
<Amaranth> colloquy > xchat-gnome > *
<zenwhen> Most users are coming from windows and mIRC if they used irc before.
<psusi> the one thing that annoys me about xchat is I can't find a keyboard shortcut to tab between channels
<zenwhen> Xchat is much more similar, and offers pretty much the same set of options.
<Amaranth> zenwhen: that's the problem
<Amaranth> zenwhen: why give them the same thing when something better is available?
<zenwhen> But this tree view of channels that becomes cluttered with the user list is even less navigable.
<psusi> Amaranth, because they are used to it and so that's what they expect
<zenwhen> It isnt better.
<LaserJock> One of the problems I had with xchat-gnome is I couldn't figure out how to set highlight words
<zenwhen> That window is a cluster****.
* dholbach wonders, if this is a #ubuntu-devel conversation or not.
<psusi> 
<Amaranth> here or desktop
<zenwhen> Well if the devs are making the package choices for all of the users, then it certainly is a discussuion for the devs to take seriously.
<psusi> here's a devel question: how do I get my specs reviewed?  I'm trying to get support for hardware fakeraid into dapper... been working on it since just before breezy was released
<sivang> boy, http://bugzilla.ubuntu.com/show_bug.cgi?id=8149 is interesting.
<Ubugtu> Ubuntu bug 8149: "automatically produce debuginfo packages (like RPM does)" Product: Ubuntu, Component: debhelper, Severity: enhancement, Assigned to: jbailey@ubuntu.com, Status: NEW
* psusi modified a package the other day to do that... it was rather easy actually
* j^ stops using xchat-gnome, interface is broken not simple
<Amaranth> i like the colloquy interface better, xchat-gnome is just the closest i can get to it on linux
<Amaranth> but i was using xchat-gnome first... :P
* sivang hugs irssi
<psusi> anyone feel like critiquing?  https://wiki.ubuntu.com/FakeRaidSpec
<ogra> Riddell, ready to go ...
<LaserJock> doh, my xchat-gnome doesn't have highlighting comment was totally wrong, I actually like the way it does it
<psusi> oh shit
<psusi> can you rename a spec on launchpad?
<psusi> I fat fingered it
<desrt> uh.
<ogra> eh ?#
<psusi> oooo
<desrt> modifying bugs in launchpad is causing me to receive bounce emails from mailing lists:     Post by non-member to a members-only list
<psusi> desrt, yep... me too
<ogra> oh, still ? 
<dholbach> hey seb128 !
<zul> same here last night
<seb128> hi dholbach
<desrt> desktop-bugs and ubuntu-bugs
<ogra> zul, but it shoudl be fixed ...
<desrt> a few minutes ago
<zul> havent tried it this morning though
<seb128> desrt: known issue, seems that mailman sucks ... jdub has made some changed for that but seems that's not the correct stuff
* desrt files a launchpad bug about it for the comedy value :)
<ogra> for me it worked since this morning
<ogra> strange
<seb128> desrt: there is already one
<seb128> desrt: https://launchpad.net/malone/bugs/3003
<Ubugtu> Malone bug 3003: "comment on a motu bug and get a moderation mail?" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Bjrn Tillenius, Status: Confirmed
<desrt> bah.  beat me to the punch :)
<dholbach> lamont-away, infinity: could somebody of you please give back gnome-terminal once more?
<seb128> desrt: BTW did the "add bookmark" from nautilus works for you? I was going to comment that on the bug this morning but I noticed it has issues on my box
<desrt> seb128; that's an inotify bug
<desrt> seb128; er.. inotify says it's a panel bug?
<desrt> seb128; either way it's in gnome's bugzilla
<seb128> it doesn't crash my box
<desrt> seb128; it just fails to update the menu, right?
<desrt> seb128; if you restart the panel (or even just the applet) the panel will be updated
<seb128> no, I've read that bug
<seb128> in that case it fails to update .gtk-bookmarks at all
<desrt> oh.
* desrt makes a face
<desrt> i don't know about that one.  local directory?
* desrt notes that there are about 100 gtkbookmarks problems right now :(
<desrt> die libegg, die
<seb128> yeah, local directory
<seb128> and works fine from the fileselector
<ogra> Riddell, did you get my ping ? 
<desrt> lemme check
<desrt> works great for me.
<desrt> "please provide a stack trace of the exact moment at which the program doesn't modify the bookmarks file"
<Riddell> ogra: hi
<ogra> Riddell, could you trigger another build ? 
<Riddell> ogra: building
<ogra> thanks :)
<Coyctecm> Hi. will dappers gnome be brown by default?
* ogra hopes now nobody will upload anything that breaky his Cd builds
<Seveas> Coyctecm, most likely
<Coyctecm> that's not good i think... I have heard many users to say that they dont use ubuntu because it is brown :( of course it easy to change defaults but first impression seems to mean lot
<Coyctecm> don't*
<Coyctecm> bad english :(
<Seveas> Coyctecm, no matter which color is chosen, there'll always be people who complain about it
<ulaas> thats great to hear "color" is now left as the only complain about ubuntu. good job lads..
<Coyctecm> yes that's true, in my opinion, i like brown :)
<ogra> Riddell, thanks so much, i finally have some isos to test ...
<Riddell> ogra: awooga :)
<ogra> even if i have no idea why http://cdimage.ubuntu.com/edubuntu/daily/current/report.html shows so much amd64 crap ... but Kamion will tell me tomorrow if i dont find out :)
<dholbach> brb
<glick> hi
<glick> excuse me no one in #ubuntu can help me so i thought maybe the developers could
<glick> all of a sudden when i plug in a firewire drive, i no longer have permission to write to it.  why is this?
<ogra> glick, please see the channel topic
<desrt> glick; if you think this is a bug then you should file a bug about it
<glick> ok
<desrt> i'd message you to discuss it but freenode is violating the IRC RFC in a way that prevents me from doing so.
<dholbach> there is at least one kino bug about it
<desrt> you lose.  sorry :)
<dholbach> and a recent ubuntu-users@ post
<desrt> dholbach; the kino bug is about accessing the raw 1394 devices
<ogra> i guess the group rights are wrong ...
<dholbach> ah ok
<desrt> firewire/usb storage devices should get perm 660 group plugdev
<desrt> (and they certainly do here)
<glick> it worked till i installed kubuntu desktop
<desrt> glick; do you mean that you can't write to the raw device (/dev/sda...) or can't write to the filesystem (/media/whatever...)?
<HiddenWolf> desrt: you can message if you register.
<desrt> HiddenWolf; i do not want to register
<glick> desrt, i cant write to /media/ieee1394disk
<psusi> desrt, what do you mean it's violating the rfc?
<HiddenWolf> desrt: then you cannot message. :)
<desrt> HiddenWolf; indeed i cannot.
<HiddenWolf> policy decision
<desrt> glick; but you can see your files?
<psusi> ohh... you should be registered ;)
<glick> yes i can see the files
<desrt> https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/GetOffFreenodeSpec
<desrt> glick; it sounds like however kde's equiv of g-v-m works is not doing the right thing (ie: calling pmount as your user).
<desrt> glick; you're really not in an appropriate forum for this.  there are about a hundred better places you could ask :)
<glick> desrt, right, but now it does the same thing in gnome
* glick sighs
<glick> ok
<glick> desrt, like where?
<ulaas> i have x standard mouse icons in dapper. is it so . or it is me?
<desrt> ulaas; you could always use the mouse preferences dialog to get the ubuntu ones back.....
<desrt> glick; kubuntu, kde help channels, ...
<ulaas> desrt, merci monsieur.
<Riddell> glick: we have #kubuntu-devel where I'd be happy to listen to your issue but probably quite unable to help since I don't have any firewire stuff
<sivang> desrt: hmm, nice spec
<desrt> sivang; i say!  i wonder why it has not yet been implemented
<jordi> doko: ping
<sivang> desrt: yes, we should contact mpool and ask him :)
<wasabi> Somebody really needs to lay a foot down and decide on how network interfaces should be managed. I am so tired of ppp overwriting my resolv.conf.
* desrt watches 'modprobe usb-storage' crash
<desrt> good time to reboot, i suspect.
<desrt> woh.  neat new logout dialog
<ogra> its a bit evil in its pop under behavior ;)#
<ogra> you have to search it if you have many windows open 
<desrt> eh.  it's young, yet :)
<ogra> sure, i didnt complain
<ogra> :)
* ogra slaps himself for running rsync in the wrong folder
<dholbach> have a nice evening.
<desrt> cheerio, homes.
<dholbach> Yoohoo. :)
<slomo_> elmo: please sync fatsort from debian/unstable... ubuntu changes can be dropped
<teroedni> hello
<teroedni> Why was xchat repced by gnome-xchat?
<azeem> the latter is more gnomeish I guess
<teroedni> thats the only reason?
<azeem> isn't it a good reason?
<teroedni> you think it is?
<Kamion> ogra: that's a tell-tale sign that you overfilled the amd64 CD. take some stuff out of it
<azeem> I don't use xchat, so I can't compare them
<azeem> teroedni: but AFAIK xchat upstream was rejected patches for further GNOME integration, so it got forked to xchat-gnome
<ogra> Kamion, thanks 
<ds> xchat-gnome is a better application, but xchat is more useful for long-time irc users
* Kamion rebuilds the Ubuntu powerpc live CD; thanks BenC for the yaboot fix
<Kamion> dunno how I lost the patch, I must have merged against an older version - whoops
<ssam> Kamion, when will the powerpc live cd be downloadable?
<teroedni> hmm:/
<Kamion> ssam: are we there yet?
<Kamion> :)
<teroedni> i surely hopes you will let xchat reside in main atleast
<teroedni> so i dont have to tun on universe just to be able to download it in the future
<teroedni> turn
<ssam> :-), sorry, been waiting a few days
* sivang wonders how you initialize multiple vars, with one value in python.
<Kamion> ssam: yes, I've been on vacation
<Kamion> well, "weekend"
<sivang> (a,b,c....) = "" explodes, seems you need to provide an ampty "","",.... tuple fir the rvalue
<ssam> sivang, a = 1; b = 2
<doko> jordi: pong
<ssam> sivang, or a = b = c = ""
<sivang> ssam: that's the one I wanted :)
<Kamion> ssam: righto, try what's there now?
<BenC> Kamion: no problem
<ssam> Kamion, thank you
<Kamion> grr, that pygtk thing mentioned on -devel means I have to rebuild all the install CDs too
<ogra_ibook> meh, my line broke in the middle of a bzr push
<ogra_ibook> bzr: ERROR: bzrlib.errors.LockError: File '.bzr/branch-lock' already locked
<ogra_ibook> does anybody know if i can just remove the lock ? 
<jordi> doko: gotta go now, but we're having trouble building alsa-lib
<jordi> ../configure: line 20520: src/pcm/pcm_symbols_list.c: No such file or directory
<doko> jordi: point me to the package please, so I can have a look
<jordi> hmm, it's in svn. Does that work, or do you want a .dsc/diff?
<doko> dsc/diff would be nice
<jordi> doko: people.debian.org/~jordi/
<jordi> I really need to run now
<jordi> laters
<jordi> doko: I suspect there's some srcdir != builddir issue
<jordi> but haven't had time to investigate
<jordi> doko: pcm_symbols_list.c is a generated file
<jordi> I wonder how it builds in ubuntu, the diff has nothing interesting that would fix it
<doko> jordi: yes, missing $srcdir prefix, this check seems to be new, I cannot find it in 1.0.10
<glick> hello all
<glick> i think there is a bug in the latest pmount
<Kamion> Riddell: building you a new Kubuntu powerpc live CD, btw
<Kamion> Riddell: how did testing go of the rest of it?
<seb128> glick: hi, feel free to open a bug on malone about it :)
<glick> whats malone?
<glick> ive never filed a bug report before
<ogra> our bugtracker on launchpad.net
<glick> and im not sure if it is a bug
<seb128> describe it
<glick> you want me to describe it in here?
<desrt> glick; didn't you already do that earlier? :)
<glick> no
<glick> .join #ubuntu
<glick> desrt: when you mount removable storage device shouldnt pmount be the program trying to mount it?
<seb128> glick: from nautilus? yep
<ogra> glick, only if its mounted automatically or you explicitly use the pmount command ...
<ogra> or from nautilus :)
<glick> for some reason the mount program is trying to mount them and i get errors about mount not being able to find the device in /etc/fstab or /etc/mtab
<glick> the exact error is a pop up that says...mount: cant find /dev/sdb5 in /etc/fstab or /etc/mtab
<glick> so i dont know if thats a bug or a config probleml
<Riddell> Kamion: the rest were all fine
<Riddell> Kamion: so we keep the rest from friday and I should test out this new live CDs?
<Kamion> Riddell: yeah, it's available for download now
* Kamion -> bed
* Riddell downloads
<glick> so is that a bug you all think?
#ubuntu-devel 2006-01-21
<netdur> every open source project can be installed via "configure & make & make install" so shouldn't be there some sort of auto-builder server to track and build them every release?
<azeem> netdur: not every
<mjg59> netdur: That provides no mechanism for generating dependency information, taking into account differences in userspace interface, that sort of thing
<ogra> Riddell, could i ask for a last favor ?
<netdur> I feel hurt :'( by this problem
<lucas> does sbody know who is in charge of popcon.u.c ? it has been broken for half a year
<Burgundavia> lucas, see the recent thead on -devel
<lucas> I'm the one who started it
<lucas> but I didn't receive any answer like 'it's my fault'
<lucas> mdz said it was useless since most people install the standard set of packages, but somebody mentionned that it was useful for universe. thread stopped basically here.
<psusi> anyone know the difference between /etc/mkinitramfs/* and /usr/share/initramfs-tools/*?
<glick> i guess the latet update hosed the automounting facilities in ubuntu
<glick> alot of people are havin the problems i am in the forums
<psusi> isn't there somewhere you can download a nightly build of the dapper install cd?
<floam> psusi: yes
<floam> psusi: http://cdimage.ubuntu.com/daily/
<floam> psusi: http://cdimage.ubuntu.com/daily-live for the livecd
<glick> how useable is dapper?
<desrt> it is.
<teroedni> Glick:Perfect
<HiddenWolf> glick: not advisable if you want a system that you can count on.
<glick> heh apparently i cant count much on breezy either
* desrt makes a face at glick
<teroedni> glick:There have been no breaks yet on dapper but after what i get there will be some soon
<psusi> I thought there was no longer a seperate livecd?
<psusi> dapper has had some minor breakage for me once or twice
<psusi> nothing I couldn't fix
<HiddenWolf> psusi: livecd will allow to install, there'll still be a seperate install cd.
<teroedni> Hiddenwolf:Can the latest livecd install?
<HiddenWolf> teroedni: no idea.
<desrt_> well.  that hasn't happened in a while
<desrt_> hard lockup.
* desrt_ tries to get that to happen again
<desrt> wonderful.  reproduceable.
<desrt> can anyone advise me of a way to get the last words of the kernel just before it pukes?
<glick> well at least i can listen to my music on my externel drive untill the mounting problem is fixed :/
<HiddenWolf> desrt: kernel log?
<teroedni> glick:Whats your problem
<desrt> HiddenWolf; ya
* desrt got a 'screenshot'
<desrt> http://desrt.mcmaster.ca/random/000_1392.jpeg
<desrt> it's a pretty fun crash
<desrt> looks like something is totally nuking all my memory (including video framebuffer)
<HiddenWolf> desrt: sweet. :)
<psusi> HiddenWolf, I see... so you can install from livecd, but setup is install only?  will the setup cd go away when dapper goes stable?
<glick> teroedni: basically when i plug in my firewire drive i get mount errors about the device not existing in fstab or mtab, It creates the folder on the icon and mounts it however i cant write to the devices only read from them
<glick> it creats the icon on the desktop
<glick> and i get error messages but it mounts i just cant write to any of em
<glick> it all worked perfectly before
<teroedni> no permission?
<glick> teroedni: yeah permission is for root only
<HiddenWolf> psusi: install cd will not go away
<glick> but when i plug it in i always get those error messages first
<HiddenWolf> psusi: servers, OEM installs, installfests, etc.
<teroedni> so if you do gksudo and goes to the firewire you cant write?
<teroedni> gksudo nautilus
<glick> teroedni: i havent tried that when i look at the permissions of the mounted device it says the owner is root with permission 744
<teroedni> best is 777;)
<teroedni> 744 have no writing permission
<glick> right
<j^> why is it that konquerer always graps /etc/alternatives/x-www-browser over firefox?
<teroedni> i have never did this on device
<womble> j^: Higher default priority in alternatives, I guess.
<womble> Just update-alternatives it away
<glick> i tihnk an update screwed up udev or pmount
<teroedni> sudo chmod 777  device i guess would fix it
<j^> womble each time a new version is installed?
<j^> it gets anoying, thats all
<womble> Is this after you've run update-alternatives and selected firefox?
<j^> no, each time a new version of konq is installes
<j^> d
<j^> i can fix it by running update-alternatives
<womble> konqueror should not be overriding a local admin choice for x-www-browser, even on upgrade
<j^> it just did again...
<glick> its really cool how in amorak when you press stop the music fades to black
<desrt> oh wow.  bugzilla is dead.
<psusi> the bit torrent download for the nightly builds is also broken
<psusi> rejected by tracker - requested download is not authorized for use with this tracker
<HiddenWolf> desrt: migration to launchpad has happened
<HiddenWolf> desrt: see -deve-announce mail archives
<desrt> what product name do we use for filing kernel bugs?
<HiddenWolf> desrt: linux I think.
<psusi> linux
<desrt> does not seem to be a valid product
<j^> desrt make sure you file the bug inside the ubuntu distribution https://launchpad.net/distros/ubuntu/+bugs
<Chipzz> ugh
<Chipzz> apparently firefox lost its toolbar icons
<Chipzz> known issue?
<teroedni> by the way:I have a small bug:Nothing seriously:But my dapper on a amd 64 bit machine(64 bit dapper)
<teroedni> have 10 virtual floppy disk 
<teroedni> is that a know issue?
<desrt> "linux" is not a valid source package name
<hyperactivecrond> is the gui installer in daily iso's yet/
<desrt> nor linux-image or any of the more qualified version names (linux-image-2.6.15-11-686, whatever)
<HiddenWolf> desrt: ask in #launchpad?
<j^> desrt its the name of the source package, linux-source-2.6.15
<desrt> ah.  wonderful.
* HiddenWolf thinks human-readable names should be mapped to source versions.
<Mez> desrt: couldnt you have apt-cache show package | grep source 
<Mez> ?
<desrt> launchpad certainly doesn't explain this
<desrt> but  thanks for the info :)
<floam> what happened to the little notifier thing in dapper? it's like blue now and has jaggy edges
<tseng> libnotify was redone in the infinite wisdom of J5
<tseng> the man who brought you D-Bus API Madness, Volume 15
<tseng> i mean... "It looks pretty"
<floam> it does?
<tseng> not really.
<floam> heh
<floam> I thought it looked a lot better when it wasn't blurry and round
<Robot101> hurrah
<floam> tseng: is there any discussion about this on a mailinglist or wiki or something that you know of?
<tseng> eh the last time it was on my radar was planet gnome months ago
<tseng> when redhat dudes told chip his implemenation wasnt good because he didnt consult them, and it was due for a rewrite
<tseng> behold, jagged blue lines
<floam> I was really hoping that was just a proof of concept for themeing it or something, but it hasn't changed in a few versions so I'm getting worried ;)
<Robot101> tseng: J5 did discuss the changes in detail with chip, who is still working on it too...?
<Robot101> sorry to impede on the trolling and all :P
<psusi> is the firefox download window ever going to get fixed in dapper? ;_
<tseng> psusi: it was fixed for me some weeks ago
<psusi> really?  hrm.... wasn't for me...
<psusi> I'm amd64 though, wonder if that has something to do with it?
<psusi> or maybe I need to recreate my user profile or something?
<tseng> Robot101: yeah suppose things could be happy and shiny behind the scenes now, its a downgrade on the end-user side
<Robot101> write a new theme or something
<tseng> Robot101: and my rh troll is unstoppable!
<Robot101> you can now I think :P
<Robot101> then I can troll about how ubuntu didn't design it with enough naked people, so you had to rewrite it...
<Robot101> :)
<tseng> I am in favor of more nakedness
<tseng> let the flames begin.
<floam> totem really needs a default movie to play the first time it's opened..
<tseng> Robot101: hah, what goes around comes around.. a mono troll on u-d
<tseng> floam: does it?
<floam> tseng: probably not
<floam> it was in reply to <tseng> I am in favor of more nakedness
<tseng> ah!!
<Robot101> lol
<tseng> my pic would be jono inpersonating jeff
<tseng> +k
<psusi> anyone know the difference between /etc/mkinitramfs/scripts and /usr/share/initramfs-tools/scripts?
<tseng> i believe the first is a leftover
<tseng> but you would want to have someone like infinity or mjg59 confirm that
<mpt> floam, upstream totem may need that, but in Ubuntu afaik it should be quite difficult to open totem unless you're opening a specific movie
<floam> mpt: I was joking :)
<floam> totem being hard to get to on it's own seems like not a great thing though, since it has a sidebar with a playlist
<floam> no easy way just to start it without a movie and see that.
<tseng> floam: how about if i put in a dvd, it autoplays
<tseng> i close it, because i am not ready to play it
<tseng> ..then what?
<tseng> obviously i know several ways to get totem back
<tseng> pretend i was dumb
<floam> tseng: then you have to take the cd out and put it in again
<floam> and that might take the average joe an hour
<tseng> yeah its locked
<floam> you cry
<tseng> like a baby
<floam> I guess if people wanted to keep totem inaccessible they could say nautilus should have something on the right click menu of devices for that
<floam> but I think something like totem you'd want at least a bit handy
<floam> it's not a minor utility
<tseng> its a good thing i have a menu item for Avahi Discovery, though
* ds votes for "Night of the Living Dead"
<tseng> ds: Zombies arent humans
<tseng> ds: you missed the theme
<Tm_T> ogra_ibook: hey, now I ask something stupid but answer if you can. is it legal/right to sell ubuntu discs?
<ogra> if people pay for it ... 
<tseng> Tm_T: i would argue that its not "right" to sell them above cost of the media and production
<tseng> Tm_T: but its entirely legal
<Tm_T> aye
<Tm_T> just annoying
<tseng> unless someone changed the contents in a way that violates the gpl and other applicable licenses
<Tm_T> hope noone buys :p
<tseng> selling the cd as-is is no trouble
<Tm_T> tseng: no, some people order shipit cd:s and sell them
<Tm_T> I understand IF those tell the way to get it free
<Tm_T> but they don't
<tseng> that is definately against the spirit of shipit
<Tm_T> aye
<Tm_T> but as long as it's legal there's not much to do
<ogra> BenC, my laptop suddenly has only eth0 and eth2 (instead of eth1) 
<ogra> eth2 is the airport extreme ...
<floam> haha cool
<floam> I can make xchat-gnome crash real easy. type /, hit tab a couple times
* Tm_T doesn't really use gui irc-clients :)
<floam> I've long been an irssi holdout, but I decided to give this a go
<floam> it has spell checking so I can look a bit smarter
<desrt> where do i file a bug that 'sg' module isn't loading when i connect my cd drive?
<desrt> modutils? kernel? udev?
<ogra_ibook> sounds like udev
<desrt> thx.
<psusi> how can I add a package to the livecd?
<jdub> doko: eclipse not installable due to eventual depends on mozilla-browser/libnspr4 (not the ffox version) - known?
<psusi> I can't just append another .iso can I?
<jdub> psusi: you can do it when running the livecd itself, or if you want it permanently there, unpack the livecd image and install it (see livecd page on the wiki)
<psusi> problem is I need the package for the cd to be able to access my hard disk, which is where the package lives ;)
<psusi> and the instructions on the wiki do not apply for dapper since it isn't using cloop anymore
<psusi> I was really just hoping to be able to add the file to the disk but nautilus won't do that... I guess the .iso is closed?  so can't add a new session
<BenC> ogra: not sure, mine did the same...has something to do with bcm43xx getting a module device table
<BenC> ogra: if I blacklist sungem, I get just eth0 from bcm43xx
<ogra> the intresting part is that this is not the frist reboot after the upgrade
<ogra> it just happened out of the blue ...
<mjg59> ogra: Network device loading order is currently non-deterministic
<mjg59> Use ifrename
<mjg59> (for now)
<ogra> mjg59, since i have to start it manually anyway i dont really care about ifrename ... my order has a gap, thats the part that made me courious
<mjg59> BenC: So it's stable for you now?
<BenC> mjg59: very
<BenC> still at 11M, but pretty solid
<BenC> I think it will be ready for dapper release if we can just get firmware for it (and I'm in contact with someone about that)
<mjg59> Cool
<BenC> ogra: I use this if interfaces to bring up the bcm43xx auto:
<BenC> http://librarian.launchpad.net/1517987/000_1392.jpeg
<BenC> oops
<BenC>         pre-up iwconfig eth0 rate 11M
<BenC>         pre-up ifconfig eth0 up
<BenC>         pre-up sleep 2
<BenC>         pre-up iwconfig eth0 rate 11M
<BenC>         wireless-rate 11M
<BenC> plus essid and key, and it comes up automatically
<mjg59> BenC: If 54 isn't working by Dapper, we should just nail it to 11
<BenC> mjg59: yeah, I did hear they were working on that, and hoping it would be fixed very soon
<BenC> it doesn't affect all bcm43xx chips
<mjg59> Right
<jdub> is there already a tool that figures out if/which packages are uninstallable, or is that not possible?
<mjg59> I thought we had one of those at one point?
<infinity> jdub: Define uninstallable.  "broken dependencies" is handled by britney.
<infinity> jdub: Crazy "install / remove / upgrade / etc" testing can be done with "piuparts", which is pretty neat.
<jdub> oh right
<jdub> yeah, britney-style
<jdub> i'd love graphs of main+universe installability over time
<jdub> with rss feed
<jdub> that'd be sweet
<infinity> You're free to make some. ;)
* HiddenWolf keeps mouth shut
<infinity> britney is run on every cron.daily, and ouput sent to p.u.c/~cjwatson/testing/
<infinity> But it's not (currently) run for universe terribly often, cause a britney run on universe takes longer than the cron.daily window.
<infinity> Of course, this'll all get upended and reinvented when we switch to LP, I suspect.
* HiddenWolf chokes
* HiddenWolf has seen more people begging for help with bugs since friday than in the last month
<infinity> With reporting bugs, you mean?
<jdub> infinity: i'll talk to colin about it
<infinity> (And managing them)
<HiddenWolf> infinity: yeah
<infinity> jdub: That would be best, yes.
<infinity> HiddenWolf: Yeah, with any luck, a constant stream of scary user feedback will help Malone improve rapidly.
<HiddenWolf> "hey, bugzilla is broken" - "help, where do I file bugs now?" - "whoops, I filed a bug upstream when it should be in ubuntu" - "whoops, I filed a bug upstream, but it should be in ubuntu, for another package"
<infinity> I think that was probably the major impetus for the switch.  "Well, it's not getting much better with a handful of regular users, so I guess we should inflict the bugs/design on everyone and get more input."
<HiddenWolf> with "help, i'm lost" and "what do I file a bug on" being the top questions.
<psusi> infinity, hey... what's the difference between /etc/mkinitramfs/scripts and /usr/share/initramfs-tools/scripts?
<HiddenWolf> infinity: I'll be convinced when launchpad gains an interface as simple as the gnome bugzilla.
<infinity> psusi: Debian policy should make that one pretty clear (as well as general UNIX and FHS policy)
<infinity> psusi: /usr/share is stuff from packages that we're free to overwrite whenever we like.
<infinity> psusi: /etc is for either a) packages that need conffile-handling for their scripts (cause they are user-customisable) or b) users writing local scripts.
<psusi> ?  why are the scripts in both places?  and where should I put mine?  in /usr/share?
<infinity> psusi: 9 times out of 10, scripts from a package should be in /usr/share
<infinity> psusi: Stuff you're writing locally should be in /etc
<psusi> ok... thought so... but you can also modify the ones in /etc right?  so what gives?  /usr/share gets copied there when you mkinitramfs or something?
<infinity> psusi: They both get copied.  But this is about how the packaging system will deal with stuff.
<infinity> psusi: If you modify something in /usr/share, the next time that package is updated, dpkg will blindly (and correctly) overwrite your changes.
<psusi> ok... so you can put scripts in /etc and it will work, but you SHOULD put them in /usr/share, yes?
<infinity> psusi: If it's in /etc, it gets special treatment.
<psusi> I see...
<infinity> psusi: Note that, by default, there are no scripts in /etc/mkinitramfs, just placeholder directories.
<psusi> ahh, ok... it is starting to make sense now
<infinity> psusi: I'm assuming somewhere along the line, someone may decide to package a script there, but I can't think of a case where it would really be necessary (since a script in /usr/share and a config file in /etc is more elegant)
<psusi> so for the dmraid package, it should go in /usr/share, but for my howto wiki, it should tell users to put it in /etc?
<infinity> psusi: Well, if you're adding the scripts to the dmraid package, why not just request a backport, and reference that in the wiki?
<infinity> psusi: Rather than having users fiddle low-level with copying random files to random places.
<psusi> hrm.. oh... for some reason I was thinking that the initramfs stuff was not compatible with breezy, but I guess it was...
<psusi> I had users fiddling with it because that's all I knew initially ;)
<psusi> once I get the package uploaded for dapper, I'll ask that it be backported and fix the wiki
<psusi> well.... had to patch xorg.conf on the nightly livecd to get it to not lock up... but it's working now... though xchat looks different... where's the new copy to install option?
<ogra> copy to install ?#
<psusi> yea... the new way to install from the livecd where it just copies the live filesystem to your hard drive
<psusi> I was going to test that out, but can't find it
<poningru> guys I had a question why are we still putting cli answers in documentation?
<poningru> we should be able to give all gui answers
<ogra> poningru, thats rather a question for #ubuntu-doc :)
<poningru> sorry
<poningru> wrong channel
<poningru> I thought this was it
<ogra> the last part starts with d, so you were already near :)
<psusi> so... where's that new ubuntu express copy install thing on the nightly livecd? ;)
<ogra> i havent seen any upload yet
<HiddenWolf> psusi: it's not, it's half-finished and not uploaded
<psusi> HiddenWolf: ohh, I was wondering why ubuntu-express wasn't installed and doesn't actually contain any files when I just installed it... I could have sworn someone ( you? ) said eariler that was working
<poningru> and dont they have a new name for it now?
<psusi> darn.. and I was all excited about testing it in combination with dmraid
<HiddenWolf> psusi: I never said it worked now. I said it would work.
<HiddenWolf> poningru: I believe it's espresso
<HiddenWolf> psusi: kamion is developing it.
<psusi> so... he need a beta tester? ;)
<HiddenWolf> I have no clue.
<sabdfl> doko: firefox has gone hugely flaky on me
<sabdfl> am I the only one or do you have other bug reports?
<daniels> i thought iwj maintained firefox?
<sabdfl> good point
<sabdfl> thanks daniels
<daniels> i live to give
<daniels> what the hell are you doing up at this hour, anyway?
<sabdfl> daniels: timeshifting, i start the asia tour tomorrow
<daniels> oh, fun
<desrt> daniels; question for you.  is there any chance of getting the grab-breaking stuff into dapper's xorg?
<desrt> alt+ctrl+kp/ and *
<daniels> desrt: it's already there?
* desrt blinks
<daniels> you just need the right config stanza
<desrt> ah.  off by default.
<daniels>     key <KPDV> {
<daniels>         type="CTRL+ALT",
<daniels>         symbols[Group1] = [ KP_Divide,   XF86_Ungrab ] 
<daniels>     };
<lifeless> grab-breaking ?
<desrt> lifeless; if an app holds a grab and crashes then you lose control of the xserver
<desrt> lifeless; this cancels the grab
<daniels> lifeless: ctrl-alt-keypad/ closes all currently open keyboard/mouse grabs
<daniels> ctrl-alt-keypad* kills all clients with a currently open keyboard/mouse grab
<desrt> daniels; where does that go?
<daniels> desrt: it's already in the XKB files
<daniels> desrt: Option "AllowClosedownGrabs" or something, ServerFlags section.  should be in man xorg.conf.
<desrt> perfect.  thanks
<lifeless> desrt: evolution does that to me all the time without crashing, just naffed
<lifeless> daniels: sweet tool
<daniels> yeah
<daniels> hell useful
<desrt> works like a charm.
* desrt imagines this has security implications....
<desrt> hahah
<desrt> ctrl+alt+kp* = kill gnome-screensaver
<daniels> something about screensavers, yeah
<daniels> correct
<daniels> your screensaver is useless when your grab disappears
<desrt> in any case, my screensaver serves as a protection against my little sisters
<desrt> i doubt they'll think to type that in
<poningru> whats kp?
<mjg59> Keypad
<poningru> oh
<mjg59> Ooh, IBM are giving away Macs for the LCA hackfest
<sabdfl> daniels: any reason our xserver packages are version 6.8.2 and not 7.0?
<daniels> sabdfl: waiting for flight 3 so I can break things and then stealthily flee ;)
<sabdfl> the ultimate kthxbye
<daniels> sabdfl: xserver-xorg is just a metapackage (as xorg-common and xserver-common), but yeah
<daniels> i have loads of local changes
<mjg59> sabdfl: Are you going to be at all of LCA, or just for your speaking gig?
<sabdfl> mjg59: i'm there for most of it, headed to canberra on sunday
<mjg59> (And why is there no bloody Inprocomm driver for Linux? It's the last real chipset we're missing)
<mjg59> sabdfl: Cool
<Lathiat> mjg59: you coming?
<Lathiat> i'm speaking to the debian miniconf about MOTUish stuff
<mjg59> Lathiat: I'm speaking, yeah
<Lathiat> mjg59: oh, tahts right
<Lathiat> ACPI talk 
<mjg59> Haven't we already had this conversation? :)
<Lathiat> probably :)
<mjg59> Inprocomm's DNS is fucked
<pitti> good morning
<infinity> Morning, pitti.
<dholbach> GOOD MORNING!
<irvin> sabdfl, 
<sabdfl> hey dholbach
<irvin> good morning
<sabdfl> irvin
<dholbach> hellas sabdfl! :)
<zakame> hi all
<dholbach> hey zakame!
<sabdfl> infinity: apache2 seems to have trouble with the new /var/run
<sabdfl> [Mon Jan 16 06:46:20 2006]  [error]  cgid daemon process died, restarting
<sabdfl> [Mon Jan 16 06:46:20 2006]  [error]  (2)No such file or directory: Couldn't bind unix domain socket /var/run/apache2/cgisock
<pitti> hi sabdfl
<sabdfl> wash, rince and repeat
<sabdfl> hey pitti
<pitti> ah, usual problem, similar to cups
<zakame> heya dholbach, pitti, sabdfl :)
<Burgundavia> pitti, are you headed to the osdl printing conference?
<infinity> sabdfl: Yup.  Needs to be fixed in my init script, it's in the next upload already.
<pitti> Burgundavia: we did not talk about this yet
<Burgundavia> ah
<Burgundavia> the dev sprint is next week, no?
<pitti> in two weeks
<Lathiat> hrm, that could potentially break avahi too
<Lathiat> i think it relies on /var/run/avahi-daemon/ existing
<sabdfl> infinity: https://launchpad.net/distros/ubuntu/+source/apache2/+bug/28510
<Ubugtu> Malone bug 28510: "/var/run/apache2 does not exist" Fix req. for: apache2 (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
<infinity> sabdfl: I think there was already a bug, but the more the merrier. :)
<sabdfl> that's it. i'll set to you, and pendingupload
<pitti> bah, this xchat-gnome is annoying, brb
<dholbach> morning JaneW
<Burgundavia> sabdfl, ogra is waiting on some space images from you for the default screensaver image
<Am|NickTaken> *groan*
<mjg59> No porn?
<JaneW> hi dholbach 
<dholbach> pitti: what do you find annoying about it?
<Burgundavia> mjg59, might be fun
<Am|NickTaken> firefox 1.5.0.1 is going to include lots of extras besides security fixes
<Am|NickTaken> it's worse than 1.0.x
<pitti> dholbach: I don't see the channels on the bottom of screen and I can't split windows
<Burgundavia> Am|NickTaken, has mozilla still not figured out security patches?
<Amaranth> Burgundavia: I guess not...
<Burgundavia> Amaranth, they are also ending security support for 1.0.x in about april
<dholbach> pitti: i got used to the channels on the left side and using {ctrl,alt}-{up,down} already
<pitti> dholbach: but I never see when I got a message and such
<pitti> dholbach: well, I'd need to get used to a new window layout for working, that is
<Amaranth> Burgundavia: that's not good...
<dholbach> pitti: i use the notification plugin
<Burgundavia> Amaranth, pitti actually swore when he heard that news
<dholbach> pitti: (or however it's called) :)
<Burgundavia> dholbach, why is notification on by default?
<dholbach> Burgundavia: is it?
<Burgundavia> dholbach, nope
* Burgundavia goes to beat up x-g developers
<dholbach> Burgundavia: what is your question? you think it should be?
<bytee_> hello folk. who is responsible for the mysql packages in Ubuntu ?
<Burgundavia> dholbach, I think it should be installed by default. Gaim does notification by defualt
<dholbach> Burgundavia: i had a quick look, seems like it's not something we can 'just' change by default, this would involved some upstream hackery
<Burgundavia> dholbach, what about shipping ross burtons python plugin?
<Burgundavia> dholbach, http://www.burtonini.com/blog/2005/Apr/05
<dholbach> Burgundavia: that's for xchat, not xchat-gnome
<dholbach> Burgundavia: and it's packaged already
<Burgundavia> dholbach, same backend, should just work (I have not tested it)
<dholbach> Burgundavia: and xchat-gnome does have different plugins (some notifications as well)
<Burgundavia> ah
<dholbach> sf.net's bug tracker is teh suck
<Burgundavia> dholbach, apparently they are working on it
<dholbach> the sourceforge guys on their bug tracker or the gnome-xchat guys turning some plugins on by default?
<Burgundavia> dholbach, the former. I am talking to the x-g guys about the latter
<dholbach> Nice.
<dholbach> (the sf.net bug tracker just closed my bug, because I didn't report back in 14 days. While I like the feature, i *did* report back in 14 days. :-))
<Tm_T> haha
* desrt nods to dholbach 
<zakame> heya pef
<pef> hello zakame :)
<Chipzz> ugh
<Chipzz> !gnome-utils-- ;P
<Chipzz> gnome-utils en gnome-system-tools are both b0rked, shipping files in /var/lib/scrollkeeper
<Tm_T> =)
<dholbach> Chipzz: I'll look into it later.
<Chipzz> which is not a problem if either does so, but it explodes when both do
<dholbach> I'm aware of that. Today is just a bit busy, because the tarballs for GNOME 2.13.5 are rolling
<Ubugtu> Error: Error getting Gnome bug #2: NotFound
<Chipzz> dholbach: I'm not trying to pressure you into anything ;)
<mjg59> If we're going to have a bot, can we have a non-stupid bot?
<Chipzz> just whining a bit ;)
<dholbach> Chipzz: That's what I thought. ;-p
* dholbach hugs Chipzz
* Chipzz hugs dholbach :)
<Chipzz> but.. just a stupid idea... couldn't we build a check for that in dh_scrollkeeper, which gives a warning when there are files in /var/lib/scrollkeeper?
<dholbach> Chipzz: i suppose both packages are bugged
<dholbach> and stuff shouldn't be there at all
* Chipzz nods
<Chipzz> what I was proposing catching these kind of bugs at build time
<Chipzz> +was somewhere
<infinity> Not much point in having debhelper throw warnings.
<infinity> However, if it's true and correct that any package that invokes "dh_scrollkeeper" also shouldn't have files in /var/lib/sk, then you could just make dh_scrollkeeper delete /var/lib/sk in the target package.
<Chipzz> infinity: (I think) it throws warnings anyway?
<Chipzz> infinity: shouldn't that be fixed by giving the right options to make, instead of deleting those files?
<infinity> Probably, but if the upstream makefile's buggered, would you rather fix it, or just remove cruft?
* infinity shrugs.
<Chipzz> maybe I should rephrase: check for presence, if there delete those files and throw warning about it?
<infinity> I'm not a desktop guy, I'll let dholbach and seb128 care. :)
<Chipzz> infinity: I suppose it's the same kinda stuff as with gconf, where you have to append an option to make install to disable the schema install stuff
<Chipzz> anyway, enough whining ;)
<mdke> infinity, a new week, a new round of nudging
<sivang> morning all
<desrt> da
<sivang> hey desrt , what's cracking?
<desrt> wasting time
* desrt wants to go to bed but is not sufficiently tired :(
<Burgundavia> dholbach, https://launchpad.net/products/launchpad/+bug/28665
<Ubugtu> Malone bug 28665: "Bugs from reportbug need to addressed" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
<dholbach> Burgundavia: hm?
<Burgundavia> dholbach, reportbugs is currently dropping on ubuntu-users but there is currently on simple fix. This is a bug to address whether or not lp is going to accept those bugs
<dholbach> Burgundavia: I agree, that it'd be nice to have it fixed, but I daresay, that I'm not going to be part of the solution.
<dholbach> Burgundavia: Why did you think of me? :)
<Burgundavia> dholbach, are you not the bug master?
<Burgundavia> dholbach, the other solution is to remove reportbugs from ubuntu
<siretart> Burgundavia: thats not that easy
<Burgundavia> siretart, which isn't? removing reportbugs?
<siretart> Burgundavia: currently, the malone email interface REQUIRES a valid gpg signature
<siretart> to file new bugs
<Burgundavia> siretart, yes, jamesh explained that
<Burgundavia> hence why this wasn't resolved easily and needs an lp bug for it
<pitti> ogra: gobby & co approved, please seed
<pitti> bah, am I the only one whose firefox segfaults?
<lifeless> no
<lifeless> sabdfls does
<Burgundavia> pitti, might be your plugins/extensions
<pitti> Burgundavia: I didn't change them since ages ago (not that I would have many)
<pitti> $ dchroot -c breezy firefox *grumpf*
<pitti> also happens with a clean profile, btw
<poningru> pitti: if you are still using 1.0.7 then its probably an actual bug
* poningru assumes its 1.5
<pitti> poningru: no, I'm using breezy's ffox now since dapper's current one segfaults immediatel
<pitti> y
<pitti> hi mvo
<mvo> hey pitti 
<mvo> good morning
<poningru> pitti: it may be a good idea to just use 1.5 seperately, with a seperate profile and everything, just dont use the plugins
<pitti> poningru: I already tried that
<poningru> hmm and it still segfaults?
<poningru> hmm
<sivang> pitti: morning martin
<Mithrandir> hmm, why does the "application foo crashed unexpectedly" say unexpectedly?  Is there any situation where crashes are expected? :-)
* sivang watches the panel crashes while dist-upgrading.
<mpt> Mithrandir, report a bug
<mpt> Mithrandir, the Mac says a program "unexpectedly quit", so whoever wrote that message was probably half-thinking of that
<mpt> and Windows has "foo has encountered an error and needs to close"
<sivang> "This program has performed an illeagle operation and will be arrested"
<mdke> "closed unexpectedly" would work
<mpt> yes
<mpt> the worst crash message I've ever seen was from a Tcl/Tk app
<mpt> "Segmentation violation: child killed"
<mpt> (... with a hacksaw!)
<Treenaks> mpt: sounds like a headline from a newspaper
<sivang> what's up with the scrollkeeper b0rkage ?...
<sivang> Preparing to replace gnome-system-tools 1.4.1-0ubuntu2 (using .../gnome-system-tools_2.13.0-0ubuntu1_i386.deb) ...
<sivang> Unpacking replacement gnome-system-tools ...
<sivang> dpkg - warning, overriding problem because --force enabled:
<sivang> for all the locales I have...
<sivang>  trying to overwrite `/var/lib/scrollkeeper/en_GB/scrollkeeper_cl.xml', which is also in package gnome-utils
<sivang> mpt: lol
<dholbach> sivang: aware of that
<sivang> dholbach: pakcage specific , or system wide?
<dholbach> sivang: that was raised 2 hours ago
<dholbach> the former
<sivang> dholbach: ah I see, ok, thanks. (I take it there's a bug report already)
<dholbach> no, hopefully not - i'm looking into it already :)
<sivang> dholbach: lucky you, I was going to file a bug about it :)
<Kinnison> Morning
<dholbach> sivang: fixed.
<sivang> dholbach: cool !
<mvo> mjg59: I uploaded a fix for the missing notifications in gnome-power-manager, please let me know if there are any problems with it (and thanks for pointing it out)
<mjg59> mvo: Thanks!
<mjg59> mvo: What was up with it?
<mvo> mjg59: LIBNOITFY_VERSISON was not set in configure.in. I fixed a small glitch in the arrow pointing code as well, should be more accurate now too
<ulaas> E: /var/cache/apt/archives/gnome-utils_2.13.4-0ubuntu1_i386.deb: trying to overwrite `/var/lib/scrollkeeper/en_GB/scrollkeeper_cl.xml', which is also in package gnome-system-tools
<ulaas> known issue?
<slomo> ulaas: should be fixed with the latest gnome-utils upload
<ulaas> slomo, recently?
<slomo> 2.13.4-0ubuntu2
<sivang> ulaas: dholbach already fixed that, I think
<mjg59> mvo: Thanks!
<slomo> ulaas: btw, can you give me a working browser patch for banshee 0.10.4 when it is released? :)
<ulaas> i will report. doing an apt update now.
<mvo> mjg59: cheers :)
<slomo> ulaas: it isn't build yet... wait an hour :)
<ulaas> slomo, i will. i dont know what abock is upto with it. so i will give you mine no worries.
<pitti> ogra: yay, vulnerability in tuxpaint :)
<Chipzz> ieks
<Chipzz> this is ugly
<Chipzz> /bin/sh segfaults
<Chipzz> /bin/bash works though
<viviersf> pitti, cant believe where you find vulnerabilities :/
<Treenaks> Chipzz: is /bin/sh /bin/bash, or is /bin/sh some other shell?
<pitti> viviersf: I didn't discover that one :) I just have to fix it
<Chipzz> Treenaks: /bin/bash
<viviersf> pitti, hehe its still bad
<viviersf> * ill sploit your pc using tuxpaint * :(
<dholbach> sebest: Hello. Would you mind uploading the latest nautilus-share to REVU?
<Chipzz> hmmm no
<Chipzz> it's dash
<Riddell> ogra: still in need of a favour?
<Kamion> Riddell: powerpc live CD seems to be hosed on Ubuntu; I think it's unionfs issues but haven't dug into it yet. I'm just going to put that in the errata for Flight 3.
<Kamion> Otherwise just doing final testing now
<Riddell> I'm burning kubuntu powerpc live now
<pitti> Kamion: I debugged this for a while with BenC at Friday evening, and Ben said he would see the problem and it was a kernel issue; do you mean a different problem now?
<Kamion> pitti: yeah, it now boots properly but hangs in usplash and can't switch vt
<Kamion> so I assume the kernel's oopsed or similar
<pitti> *sigh*
<Kamion> and s/kernel issue/yaboot issue/ above?
<Kamion> (since that's what BenC fixed)
<pitti> Kamion: no idea, I talked to BenC for a while, and the last line I read was 'Ah, I see the problem now and will handle it'
<pitti> Kamion: probably yaboot then, yes
<Kamion> haven't tried booting without splash to see where it breaks
* infinity needs to get a ppc machine that can boot from CD so he can test this stuff...
<Kamion> Riddell: suspect it'll be the same on both
<Mithrandir> Kamion: could we move the "boot from hard drive" menu item so it's visible by default on the current amd64 cds?
<Kamion> Mithrandir: yeah, already noticed that - I'll make the area for menu items bigger
<Mithrandir> Kamion: thx.
<Kamion> will have to shunt the logo up the screen a bit
<Yagisan> pitti: ping
<pitti> Hi Yagisan 
<Riddell> Kamion: kubuntu powerpc live CD hands on "mounting root filesystem"
<segfault> who handles ubuntu.com DNS entries?
<Znarl> segfault : Myself.
<segfault> znarl: seems that br.archive.ubuntu.com is dead
<segfault> znarl: can you please add another entry pointing that to archive.ubuntu.com too?
<Znarl> segfault : I'll fix it, thanks for letting me know.
<segfault> znarl: thanks!
<pitti> Hi Diziet 
<pitti> wb sabdfl 
<Diziet> Morning.
<pitti> Diziet: can you reproduce the firefox crash? (it doesn't start at all)
<Kamion> Riddell: yeah, that was what I saw
<Diziet> Is this the locale problem ?
<sabdfl> pitti: ff is screwy for me too
<sabdfl> dies on startup often, dies on links too
<pitti> it seems to work on ppc, and immediately segfaults on amd64
<Diziet> sabdfl: Your symptoms sound like either an extension problem, or the result of one leftover patch.
<Diziet> Ah.
<pitti> Diziet: I tried without a ~/.mozilla already, same result
* pitti wonders if that is a b0rkage from the recent glibc multiarch upload
<Diziet> (leftover patch> from breezy, which I still need to expunge.)
<sabdfl> Diziet: fails with or without flash
<Diziet> I haven't touched ff since last Friday.
<Diziet> But there are problems with the amd build which I have been ignoring last week to get something else done :-).
<Diziet> But those problems were to do with the -dev and lack of PIC.  I can't see how it would have just broken now.
<Diziet> pitti: without .mozilla> Hmm.  When did it start going wrong ?
<pitti> Diziet: it still worked at Friday, then it probably broke after friday's dist-upgrade (but I didn't restart my browser after dist-upgrade)
<pitti> Diziet: I noticed the failure on Saturday first
<Diziet> You mean this last Friday, the 13th.
<pitti> yes
* Diziet checks the dapper-changes archive.
<Diziet> So it was working all last week ?
<pitti> yes
<Diziet> Last ff upload was Thursday the 5th.
<Diziet> That's not to say that it's not firefox's fault/.
<pitti> yes, I'm sure it's not due to a ffox upload
<Diziet> Hmm.  Has anyone reproduced it on i386 ?
<pitti> the most plausible explanation might be the glibc multiarch
<Diziet> That might well be something to do with it.  I haven't been following that.  Is there somewhere I can read about it ?
<infinity> Diziet: Did you have changes lined up to make ffox build happily on amd64?
<infinity> (not counting what you're talking about right now)
<pitti> hm, shouldn't 'DEBUG=1 firefox' spawn gdb?
<Diziet> I have no changes lined up, no, but I was going to look at the problem RSN.
<pitti> oh, nm, I found -debug
<infinity> Diziet: Were there plans to sync with Debian's firefox? (hey, they changed the source package name finally, too!)
<pitti> Diziet: stack trace is utterly nonexistent
<Diziet> infinity: Yes, I'm going to synch to it after getting rid of the crufty patch I mentioned above.
<StevenK> infinity: To iceweasel? :-P
<infinity> Diziet: Kay.  I'd recommend merging before trying to attack the amd64 thing.  I find that upstream bumps can often "magically fix everything" and save you a bunch of hassle. :)
<infinity> Diziet: (And we obviously want 1.5final anyway, so..)
<Diziet> infinity: Quite (on both counts).
<Diziet> Oh, err, duh, this firefox crashing can't possibly be anything recent because it FTBFS on amd64 for a week and a half as already noted.
<infinity> Right.
<Diziet> The FTBFS is due to the nspr/nss violence, I think.
<Diziet> Err, I mean `I guess', really.  But I'll look at it.
<infinity> Diziet: If it doesn't get sorted before the sprint, sit down with me and we'll make it go together.
<infinity> Diziet: I hope it builds before then, though. :)
<Diziet> :-)
<infinity> pitti: Getting a useful backtrace from ffox/amd64 yet?
<infinity> pitti: I'm curious if it's glibc's fault (or appears to be..)
<pitti> infinity: no, I just get a ton of 'no debug symbols', but no trace
<infinity> Well, isn't that special..
<StevenK> pitti: Deal with libc6-dbg?
<pitti> infinity, Kamion: do we still need kernel 2.6.12 in dapper?
<pitti> infinity, Kamion: most of the debs want to go to universe, too, and it has open security bugs
<infinity> pitti: I'm pretty sure we want it (and the matching lrm-2.6.12) to go away.
<pitti> infinity: I'm currently writing a mail with some sync and removal requests to elmo, so I'd include it
<infinity> pitti: Can you add "wvdial" to the sync list?.. I requested it >24 hours ago, and I suspect it got lost in the shuffle.
<pitti> sure
<infinity> pitti: (overwrite okay, they've made their postinst stop being chatty)
* seb128 hates malone sending zillion of moderation mails to every commenter
* Yagisan taught spamassasin to eat those messages
<Kamion> pitti: I think it's only still there for hppa/ia64; do we know if that's finally been sorted out (initramfs-tools)?
<Kamion> infinity: if you happen to be uploading sysvinit, fixing the shell quoting in the dpkg --compare-versions call so that it doesn't spew warnings on initial install would be nice
<pitti> no, I don't; I just saw that anastacia wants to drop the debs
<infinity> Kamion: Hrm?  initramfs-tools on ia64 was a klibc issue, not a kernel issue, was it not?
<Kamion> infinity: yeah, but I think we were keeping 2.6.12 until 2.6.15 was actually bootable
<Kamion> (regardless of where the issue was)
<infinity> Well, I know klibc is all good on ia64 now.  Or so I've heard (no hardware here to test)
<pitti> Kamion: actually it's 'source+binary' demotion; AFAIK hppa and ia64 can keep things in main (they did for krb4)
<Kamion> pitti: right, I know the seeds are inconsistent with this
<infinity> Kamion: Hadn't planned on a sysvinit upload, but since I just LOVE uploading it, I may as well.
<pitti> ok, then I'll leave that for now
<pitti> but if we actually need 2.6.12, we should fix the security bugs
<Kamion> lamont-away: what's the word on 2.6.15 on hppa/ia64?
<Kamion> pitti: we certainly won't be keeping it for dapper ...
<janimo> pitti, can you please add xterminal, xfprint, xffm4-icons to the removal list for elmo?
<pitti> janimo: bah, just sent the mail, I'll send a followup
* seb128 kicks launchpad, getting zillions of moderation mail
<janimo> thank you
<seb128> is anybody working to fix that?
<seb128> (probably not the right chan)
<siretart> seb128: do you have access to the mailman admin interface?
<pitti> siretart: jdub should
<siretart> seb128: you 'just' have to tweak the acls :/
<seb128> just for desktop-bugs
<siretart> pitti: well, I asked yesterday (or was it even on saturday) and I was told he was already aware of it. now I get doubts..
<seb128> jamesh gaves some tips to get mails accepted
<seb128> jdub did the change
<seb128> but it seems it doesn't work
<Znarl> siretart, seb128 : I am fixing the mailman moderation mails issue.
<seb128> Znarl: thank you
<pitti> infinity: btw, since you just uploaded sysvinit: I think /etc/rcS.d.s20checkroot.sh should be moved to S16
<infinity> Well, ia64's eaten through half its backlog... Not bad for the three slowest machines in the DC...
<siretart> Znarl: thanks a lot!
<pitti> infinity: this would make bootlogd and ifupdown-clean actually work
<pitti> infinity: do you see any problems with that?
<pitti> (ok, that's initscripts, not sysvinit)
<siretart> seb128: are you aware about the gnome-system-tools vs. gnome-utils issue?
<janimo> pitti, any problems so far with the swicth to alsa from esd?
<janimo> like cards not working?
<pitti> janimo: I didn't hear any complaints
<pitti> janimo: probably because it automatically falls back to esd if dmix doesn't work
<seb128> siretart: yeah, dholbach already fixed it
<pitti> janimo: so I don't expect many bugs
<siretart> great! :)
<janimo> pitti, ah so there's no feedback on which cards need fixing for dmix?
<pitti> janimo: not yet, no
<pitti> janimo: would be a nice addition to hwdb-client
<janimo> indeed
<pitti> infinity: indeed, breezy's checkroot was at prio 10
<dholbach> seb128: you should probably tell all the people WHO broke it, so they start asking me and not you the next time :) (there's not only seb128 breaking stuff)
<seb128> dholbach: I don't break stuff, I debdiff before uploading :p
<dholbach> bllllllllllll
<seb128> and yeah, blame dholbach for uploading 2 packages with a bunch of autogenerated crap and not noticing :)
<Kamion> seb128: speaking of which, CCs of mails about things that affect Flight releases in preparation would be nice
<Kamion> I only noticed that I had to rebuild for the pygobject thing because somebody asked about it on ubuntu-devel@ and you answered
<seb128> Kamion: there is no rebuild for pygobject, pygtk Depends on it
<mjg59> mvo: Yup, that works now
<seb128> Kamion: but right... GNOME 2.13.5 this week but no breakage expected
<Ubugtu> Error: Error getting Gnome bug #2: NotFound
<pitti> haha
<Kamion> seb128: pygobject 2.9.0-0ubuntu2 I mean
<mjg59> GNOME 4 life
<Ubugtu> Error: Error getting Gnome bug #4: NotFound
<janimo> mjg59, is it ok to suspend using hal-system-power-suspend directly, or should it go through g-p-m, or dbus requests?
<janimo> from a logout dialog
<mjg59> janimo: It's ok to do that, but it won't work right now
<mjg59> But yeah, that's the correct answer
<Kamion> assuming that's what you were referring to by Message-Id: <1137256462.9242.8.camel@localhost>
<mjg59> Seveas: Any chance we can make the bot more intelligent?
<Kamion> seb128: I'm releasing Flight 3 now, so it doesn't matter for next week, unless there's critical breakage from yesterday that I don't know about ...
<seb128> Kamion: pygtk.py was misnamed (used to be an alternative, so was renamed, I've cleared the altenative and forget to drop the rename)
<mjg59> janimo: It just needs someone to write the code for hal to run stuff as root
<seb128> Kamion: no, current archive should be fine ... should be stop GNOME 2.13.5 uploads for now?
<Kamion> right, point is it was fairly critical breakage in Friday's CD images which were release candidates
<Ubugtu> Error: Error getting Gnome bug #2: NotFound
<Kamion> seb128: no, go ahead, I've got the images
<seb128> time to get flight3 done?
<seb128> oki
<janimo> mjg59, right now it works with sudo, you mean it needs work to run as normal user?
<Seveas> mjg59, only by reducing the free-form of the inpu it allows
<mjg59> janimo: Mm? What works with sudo?
<janimo> hal-system-power-xxx
<seb128> Kamion: point taken, I will mail you next time in such case :)
<janimo> from the command line
<mjg59> Seveas: At the moment, if it were a person I'd be punching it in the face
<Kamion> seb128: thanks
<seb128> np
<mjg59> (Except I wouldn't, as that would be against the CoC)
<Seveas> mjg59, the gn.ome 2.13.5 is resolvable (will do that asap), but 'gn.ome 4 life' will always match
<Kamion> Seveas: reducing free-form> works for me
<mjg59> janimo: Oh, right. No, you should never be calling that script directly
<mjg59> The right thing to do is to call hal via dbus, which currently won't work
<Kamion> after all, we can always ask it directly in case it didn't understand something
<mjg59> (But will do before release)
<janimo> aha,ok then
<JRe> hello everybody!
<mjg59> Seveas: That would be a lot better, thanks!
<JRe> anyone else than me has trouble to launch SWT java programs (azureus, eclipse)
<janimo> mjg59, and then it will as normal user, no sudo needed rigth?
<jk_work> mjg59: Are you familiar with the new NetworkManager which will do WPA?
<mjg59> janimo: Yup
<mjg59> jk_work: Yup
<mjg59> We're looking into integrating it
<jk_work> Will it also let you configure open/shared WEP?
<jk_work> Reason I ask: http://bugzilla.gnome.org/show_bug.cgi?id=327073
<Ubugtu> Gnome bug 327073: "Handle shared WEP key magic for Atheros cards" Product: NetworkManager, Component: Default, Severity: enhancement, Assigned to: dcbw@redhat.com, Status: UNCONFIRMED
<jk_work> I spent more than a day fighting madwifi - there's some magic you need if
<jk_work> the network uses shared keys.
<jk_work> (which are deprecated btw)
<mjg59> jk_work: I have no idea
<mjg59> We'll be using madwifi-ng
<mjg59> (Whether that makes it more sensible or not, I don't know)
<jk_work> It would be better if users didn't have to worry about driver idiosyncracies.
<jk_work> I guess it's debatable whether you should abstract over them or make sure
<jk_work> that drivers fix them.
<mjg59> madwifi-ng should be in lrm this week
<segfault> is flight 3 already released?
<mjg59> Actually, that's a point...
<mjg59> infinity3: I'll just go and set that machine up now
<Seveas> it'll stop matching on version numbers with dots now, I'll quiet the 'not found' errors
<segfault> i guess bug #28674 is nonsense.
<Kamion> segfault: dude, wait for the announcement
<Kamion> I don't silently release things.
<segfault> kamion: i know, i just asked because i am walking through malone and saw that bug #28674, which states that the link to flight3 is broken
<tseng> segfault: very overeager
<Kamion> segfault: bug rejected
<segfault> heh
<netstar> Why does ubuntu choose non-gnu versions of tools which already have gnu alternative or option for that function.  Like inetutils for example.
<Yagisan> netstar: maybe the others are a better tool ?
<jdthood> Gotta question.  Will openpty(3) attempt to open a unix98 PTY or will it only attempt to open BSD PTYs?
<netstar> Yagisan, is that the reason?
<infinity> jdthood: It'll try both, I believe, but I'm not positive.
<Yagisan> netstar: I have no idea - hence the question mark.
<Kamion> netstar: others are better-tested and more mature
<Kamion> GNU inetutils is relatively new compared to the other inetds available
<netstar> Kamion, that answers my questions.
<netstar> thanks guys
<jdthood> infinity: I thought so too, until I read openpty(3) and pty(7).  Neither gives a definite answer, but I am left with the impression that openpty(3) only looks for legacy PTYs.
<jdthood> Guess I'd better go read the source.
<Kamion> of course it might be that we need to look at our choice of inetd, but not for the sole reason that "there's a GNU alternative"
<infinity> jdthood: Easy enough to find out.  Delete all your BSD ptys, make sure you have /dev/ptmx and a mounted /dev/pts, and see what it does. :)
<netstar> Kamion, the GNU question, I feel, should be put into consideration as well as pragmatic reasons as well of course.  I'd like to see more distributions choosing GNU tools over other alternatives as long as there wasn't too much of an impact on users.  
<Kamion> netstar: BSD versions of tools are perfectly good too
<Kamion> and often others
<infinity> jdthood: Hrm, pty(7) does seem to imply that they require different APIs, though.
<netstar> I think GNU tools should be given preference.
<Kamion> I wouldn't want to see Ubuntu choosing something *just* because it has GNU stamped on it.
<segfault> will LiveCDPersistence work with FAT too?
<Kamion> netstar: no, the *best* tools should be given preference.
<infinity> netkit and iputils are both mature and proven.
<netstar> Kamion, of course not.  But if you had three tools, equally as good as each other, GNU should be chosen.
<netstar> This is my belief anyway.
<Kamion> netstar: perhaps, but that is rarely the case
<Yagisan> netstar: no it should not
<netstar> true Kamion 
<netstar> Yagisan, perhaps if the gnubuntu project ever gets going we'll have the answers to these debates.
<Yagisan> netstar: the best non-propritery tool should be chosen, regardles of if it is PD, BSD, or GPL
<Kamion> it seems perfectly reasonable to have a derivative of Ubuntu that uses GNU tools for everything possible
<Kamion> if nothing else it would probably be pretty useful to the GNU project
<Yagisan> netstar: otherwise, we would still be waiting for the gnu kernel to arrive (how many years now ?)
<jdub> doko: twisted 2.1 all of a sudden? :)
<netstar> Yagisan, you have the GNU/Linux kernel.
<Kamion> er, dude, no, it's the Linux kernel
<Yagisan> netstar: no, the kernel is linux
<Kamion> and the GNU/Linux system
<netstar> :P sorry my bad, was getting overly zealous
<Yagisan> netstar: most core utils are from the gnu project, but you could (with effort) make a BSD/Linux system
<netstar> So can distributions such as ubuntu be considered GNU/Linux?
<jdub> yes
<Mithrandir> Yagisan: mastodon linux, f.e.
<jdub> linux + gnu libc == gnu/linux (in technical terms)
<netstar> are the BSD guys using glibc?
<Mithrandir> no
<Mithrandir> at least, most aren't.
<StevenK> I thought OpenBSD were trying to?
<tseng> StevenK: erm
<Seveas> it can also be the other way around: GNU/kfreebsd for example
<Kamion> StevenK: that was Debian GNU/OpenBSD, I think, not OpenBSD proper
<Seveas> no linux at all in there
<StevenK> Which is what I meant.
<tseng> StevenK: OpenBSD refuses to use anything !BSD where possible
* StevenK should have said.
<Kamion> tseng: there was a port of Debian to run on the OpenBSD kernel, and they were trying to port glibc
<tseng> Kamion: would make more sense.
<Kamion> never got completed though
<StevenK> Until it got dropped due to Fenrar saying "Linux is about as secure as OpenBSD." :-)
<Kamion> ogra: what's the status of Edubuntu CD images?
<jdthood> infinity: stracing a test program, I find that it does first attempt to open /dev/ptmx and to statfs /dev/pts.
<doko> jdub: needed for zope 3.2
<jdub> doko: d'oh. flumotion doesn't work with it yet. 8) oh well, they're looking into it. no biggie.
<infinity> jdthood: Spiffy.
<infinity> jdthood: So the API for UNIX98 PTYs described in pty(7) is likely only required if you want to do interesting things that openpty() doesn't support...
<StevenK> Ouch. transcode is big.
<infinity> jdthood: Or something.
<jdthood> infinity: Right.  Or if you don't want to use legacy PTYs because of security concerns.
<infinity> jdthood: That amounts to the same thing, I suppose (spiffy features, etc)
<Kamion> maswan: can you kick off a mirror of /releases/dapper/flight-3/ and /kubuntu/releases/dapper/flight-3/ please?
<ogra> Kamion, i still need a rebuild of the amd64 install iso ...
<ogra> could you trigger one ? 
<Kamion> have you cut down the seeds or whatever it was?
<ogra> seems that ppc live is broken anyway ...
<Kamion> yes
<ogra> yup and i dropped out postgres, since the locale errors persist
<Kamion> really? those should have been fixed end of last week
<infinity> Kamion: Oh, do all the important installations of germinate (jackass... little?  I dunno) speak %sourcepkg now?
<Kamion> after I fixed localechooser
<Kamion> infinity: jackass doesn't, but I poked elmo about it
<ogra> its still there
<Kamion> ogra: bah. please send me syslog
<infinity> Kamion: Kay.  Will the world blow up if I start committing (huge list)->%sourcepkg cleanups, or should I wait for jackass to play nicely?
<Kamion> if you could put postgresql back in after Flight 3 so that we can diagnose these, I'd appreciate it
<Kamion> infinity: best to wait, anastacia will get complicated if you do that and people aren't aware of the issue
<Kamion> ogra: amd64 install build kicked off
<infinity> Check.  Will wait, then.
<ogra> Kamion, thanks 
<infinity> Kamion: Maybe we can have a quick "Everyone gather around a table so we can put justification comments next to each and every seed entry" session at the sprint.
<ogra> Kamion, err, the others as well then , postgres is still in the old ones from yesterday 
<ogra> Kamion, if one of seb128's uploads breaks the current ones we can fall back on them ...
<Kamion> infinity: sure, would help
<ogra> them == yesterdays
<jdub> Kamion: FirstAgainstTheWall :-)
<Kamion> ogra: gah, ok
<Kamion> running
<seb128> ogra: what broke what?
<ogra> i think i need access to little and the build scripts one day ...
<ogra> i'd have done it yesterday night with less danger of breakage
<Kamion> sure, that can probably be arranged at some point
<ogra> seb128, no idea yet ... but if an essential desktop package is building, my isos are broken ...
<maswan> Kamion: mirroring now
<Kamion> maswan: thanks
<Lathiat> hrm another /var/run bug, mysqld starts but the dir has wrong perms
<Lathiat> i dunno, this /var/run on tmpfs thing has be a bit irked its bringing up lots of bugs and has the potential to break alot of stuff ?
<Lathiat> even stuff outside packages
<jdthood> Lathiat: Debian is moving toward supporting tmpfs at /var/run, so the bugs have to be fixed sometime.
<Kamion> ogra: done
<ogra> thanks
<ogra> Kamion, hmm, not on cdimage
<jdthood> Lathiat: It will take time for Debian to implement support for tmpfs at /var/run.  (It requires adding mkdirs to initscripts, of course.)   Ubuntu folks can help by reporting bugs in the Debian BTS.
<hunger> Could somebody please look in malone #28559? That problem is easy enough to fix and prevents lo from being brought up on boot.
<Ubugtu> Malone bug 28559: "ifupdown-clean script fails" Fix req. for: ifupdown (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/28559
<ogra> Kamion, do you need to copy them manually ? nothing on http://cdimage.ubuntu.com/edubuntu/daily/
<infinity> Lathiat: Can you mail me (adconrad@ubuntu.com) a reminder about the MySQL /var/run issue?  I'll fix it in both Debian and Ubuntu ASAP.
<\sh> infinity: heya..did you get my question about gnotime?
<infinity> \sh: Erm, what's the question, exactly?  The build-deps are uninstallable.
<ogra> seb128, somehow i cant change the icon theme on the flight3 installs, known issue ?
<Kamion> ogra: sorry, I broke publish-daily by mistake. Fixed (well, worked around), and the images are there now.
<ogra> thanks :)
<Kamion> still looks oversized though
<ogra> hrm ... i dropped 25M of gcompris sound packages and the whole postgresql
<\sh> infinity: well..apt-get install libgnomeui-dev says differently in my dapper chroot, that's why I'm asking
<infinity> \sh: apt-get -o Debug::pkgProblemResolver=true install debhelper libgtkhtml3.6-dev scrollkeeper libgnomeui-dev autotools-dev guile-1.6-dev cdbs libgail-dev libqof-dev libxt-dev libgcrypt11-dev libgnutls-dev libxml-parser-perl libgda2-dev
<ogra> seb128, somehow i cant change the icon theme on the flight3 installs, known issue ?
<\sh> infinity: grr...yes...I know I forgot something...*bangingheadondesk*
<infinity> \sh: And now that I'm done "teaching a man to fish", note the conflict between libgnutls11-dev and libgnutls-dev, both being installed.
<ogra> seb128, looks like gnome-settings-daemon isnt changing accordingly to the theme selection
<\sh> infinity: yes..trying to fix this :)
<ogra> and it doesnt happen on upgraded systems
<seb128_> ogra: no
<ogra> i'll look if it still happens on the current builds
<ogra> seb128, ah, nautilus picks up the icon change, only gtk doesnt 
<lamont-away> Kamion: ia64 has uploaded, checking on hppa
<lamont-away> Kamion: and despite the work holiday today, I'll be visiting the office to add another disk to the &*%)& buildd that keeps running out of disk space.
<ogra> hmm, seb128, Kamion whats the reason for having gstreamer 0.8 and gstream 0.10 on the CD ?
<seb128> because not all apps have been ported yet
<ogra> hrm... ok
<ogra> might be the reason that my amd64 iso explodes
<dholbach> ogra: there are surely some other reasons as well :-p
<ogra> dholbach, i dropped averything i could now, and its still oversized
<ogra> dholbach, in breezy i had 30MB free ...
<infinity> lamont-away: Kamion was less asking "are the kernels building" and more "do we still need 2.6.12 on ia64/hppa, or can we now boot 2.6.15 on those arches and kick 2.6.12 out of the archive?"
<dholbach> you added some stuff since then, right? :)
<ogra> nope
<lamont-away> infinity: ah, ok.
<ogra> its exactly the same software selection
* lamont-away doesn't remember where jbailey/kyle got to with klibc the last time we tried it.
<ogra> and apparently its fine on i386 and powerpc ... 
<ogra> only borked on amd64
<infinity> lamont-away: The changelog of Debian's klibc leads me to believe that ia64 and hppa should both be well-supported now (well, ia64 builds statically, eww, but should work)
<lamont-away> infinity: which version in debian?
<infinity> lamont-away: I think we'll need a merge to get the hppa support going in Ubuntu, but otherwise should be okay.  Might be nice if you could test, by building Debian's klibc on dapper/hppa and letting me know if it works for you..
<infinity> lamont-away: 1.1.16-1
<lamont-away> ah, could be
<lamont-away> and I expect that has hppa stuff in it... 1.1.15-1 was borked, but claimed otherwise....
<lamont-away> eep.  must run
<ogra> Kamion, did you look at the ubuntu isos ? apparently something thinks there as well that the isos are oversized ...
<ogra> (amd64 that is)
<ogra> even if its only 658MB and nothing shows up in the report
<Kamion> ogra: yeah, I know they're oversized
* ogra really doent understand it ...
<ogra> but why is it ?
<Kamion> I'm not going to look into it just now
<Kamion> why? there's just too much stuff there
<Kamion> please don't ask why, sounds like our six-year-old ... :-)
<Kamion> "it just is"
<ogra> yes, i know, but we dont have any amd64 specific stuff that could cause such a huge oversizing ...
<Kamion> sorry, I don't know and cannot check just now
<ogra> hrm, seems kdeedu grew by ~10MB  between breezy and dapper
<infinity> ogra: Binaries on 64-bit arches (amd64, ia64, alpha) tend to be a bit fatter than binaries on other arches.
<infinity> ogra: So, as a rule, the amd64 CDs will always be bigger (if they have the same package selection)
<Mithrandir> it's all the extra bits.  They're _heavy_, you know.
<ogra> infinity, yes, but i dropped off ~30MB for amd64 already, i cant imagine that the difference is *this* big 
<Lathiat> is alpha entirely 64bit?
<tseng> Lathiat: yes.
<Mithrandir> Lathiat: yes
<Lathiat> hrm, cool
<ogra> i.e. all gcompris-sound packages ...
<Lathiat> didnt know that
<pitti> Riddell: ping
<maswan> Kamion: ubuntu done, rsyncing kubuntu now
<Mez> sladen: ing - /query
<Mez> s/ing/ping/
<Riddell> pitti: hi
<pitti> Riddell: I'm a bit puzzled about k3b-i18n main inclusion
<pitti> Riddell: as soon as we put it into main, it will be empty
<sladen> Mez has just been shown a picture of sladen's sister+brother by new housemate.  What a small/strange/mad/world...
<pitti> Riddell: and don't we already include k3b translations into kde language packs?
<pitti> Riddell: I wrote code for that ages ago
<Mez> sladen: indeed :D
<sivang> sladen: do you have it online somewhere? :)
<Riddell> pitti: if k3b translations are already included then that's fine
* Riddell checks
* ogra hugs pitti 
<ogra> YOU APPROVED GOBBY !!!!
* pitti hugs ogra back
<ogra> yippie !
<ogra> :-D
<sladen> sivang: I don't know.  It's Mez's housemate that has the photos.  Apparently one of them has a pen up their nose, so maybe best if they weren't
<pitti> well, I'm still not in love with obby TBH
<ogra> pitti, forward the bugs to me, i'll care
<pitti> ogra: but if you need it for edubuntu, my gut feeling is hardly enough to keep it in universe :)
<Riddell> pitti: looks like we do, ignore that main inclusion report then
<pitti> Riddell: ok, thanks
<pitti> Riddell: I'll note that on the page
<freeflying_> Riddell:  how about the skim and scim maininclusionreport?
<Riddell> freeflying_: pitti hasn't reviewed it yet, I'm sure he will soon, but there's the other main inclusion report that need written that I e-mailed you about
<pitti> yes, I'm reviewing some reports currently, but I won't be able to process them all today
<freeflying_> Riddell: y 
<janimo> pitti, thanks for the reviews :)
<pitti> you're welcome, sorry for the delays
<janimo> np
<freeflying_> https://launchpad.net/people/ubuntu-cjk-testers
<ulaas> gaim crashes when try to log to msn account on my dapper laptop.
<ulaas> gdb output is
<ulaas> Program received signal SIGSEGV, Segmentation fault.
<ulaas> 0xb77737df in wcscoll_l () from /lib/tls/i686/cmov/libc.so.6
<pitti> janimo: xfprint did not see an update to 4.2.3?
<janimo> pitti, is one of those I asked for removal from the archive
<pitti> oh, I see
<janimo> it is superseded by xfprint4
<janimo> the former was synced from a non-debian repo before hoary
<janimo> hmm I hope I did not misspell it on the queue page, it should be xfprint4
<pitti> that's right
<pitti> just the name of the page is wrong/misleading
<pitti> but don't worry about that
<janimo> ok, thanks
<freeflying_> anyone can give me some suggestion on how to choose locels in dapper ?
<pitti> freeflying_: the language selector should be able to
<freeflying_> pitti:  it seems they are all set to utf-8 defaultly
<pitti> right, that's what Ubuntu is optimized for
<freeflying_> pitti: if I want to use another one, what can I do ?
<pitti> freeflying_: you can add a new one with 'sudo locale-gen en_US' (for example)
<pitti> freeflying_: I'm afraid there is no gui ATM to generate non-UTF-8 locales
<pitti> freeflying_: why do you need one?
<freeflying_> pitti: I just wonder , you know there are 4 locales about zh_CN , so someone would like to use another instead of utf-8\
<pitti> freeflying_: I don't have any experience with Asian languages; we have 3 locales for European languages, too, but the old latin ones are superseded by UTF-8
<pitti> so at least for latin languages few people will want non-UTF-8 nowadays
<pitti> freeflying_: is that different for Asian languages?
<ogra_> Kamion, did you already announce flight3 ? i only get 5K/s from cdimage ... 
<pitti> freeflying_: I'm still hoping that the concept of an 'encoding' will eventually disappear in the future
<pitti> freeflying_: (well, not the concept, but there should be just one)
<freeflying_> pitti: you know that utf-8 is not supported by windows
<pitti> hm?
<pitti> no, I don't
<pitti> on the few occasions I saw windows in the last years, it did
<freeflying_> pitti: and manyone should exchange file with windows user ,and window user are using gbk 
<Kamion> ogra_: no, waiting for the ftp.acc.umu.se mirror to complete
<freeflying_> pitti: so maybe someone would chosse zh_CN-GBK or orthers
<pitti> freeflying_: that's odd; most files I got from win users had utf8 file names; maybe that's different for e. g. Chinese Windows users?
<mgalvin> Kamion: will the release be today, i am finishing up a few more DapperFlight3 updates
<pitti> freeflying_: yes, I see the point
* mgalvin wonders how much he should rush
<Kamion> mgalvin: yes
<Kamion> rush
<mgalvin> ok
* mgalvin rushes :)
<freeflying_> pitti: : and houw about the maininclusionreport of ttf-arphic-iming and ukai now 
<pitti> freeflying_: since xdelta isn't required any more, they are just fine; they are in 'approved' state for very long now
<pitti> freeflying_: i. e. someone just needs to promote and seed them
<freeflying_> pitti: nice
<freeflying_> pitti: who is in charge on seed in ubuntu ?
<pitti> freeflying_: nobody in particular
<pitti> freeflying_: but it should be ack'ed by mdz or Kamion preferably
<freeflying_> pitti: hope that will be done before release 
<pitti> yes, sure
<pitti> freeflying_: it's mainly a matter of CD space, I guess
<pitti> freeflying_: in general we want as many fonts as make sense, but CD space is always precious and limited, so we need to balance
<freeflying_> pitti: but it can remove the font in CD now about chinese 
<pitti> freeflying_: oh, that'd be nice
<pitti> which package is that?
<ulaas> should i report gaim bug in launchpad?
<pitti> freeflying_: does exchanging the package require any fontconfig changes or similar?
<freeflying_> pitti: ttf-arphic-bkai00mp
<freeflying_> pitti: we just test on fontconfig
<janimo> ulaas, if it occurs with ubuntu's gaim package yes
<pitti> freeflying_: if you confirm that merely installing the package (and dropping the other one) DTRT, I'm happy to change the seeds
<freeflying_> pitti: ttf-arphic-bsmi00lp  ttf-arphic-gbsn00lp ttf-arphic-gkai00mp
<freeflying_> pitti: just a moment 
<pitti> freeflying_: no hurry :)
<pitti> janimo: hm, why does xfce4-utils call ivman, but doesn't depend on it?
<janimo> pitti, hmm my fault
<janimo> I'll add it
<janimo> thanks
<pitti> ok, thanks
<pitti> I approve the report under the assumption that it gets fixed soon
<janimo> ok
<freeflying_> pitti: the configure about umingand ukai have been submitted to fonconfig upstream
<pitti> freeflying_: so there are necessary changes? we can put them into Ubuntu immediately as soon as we switch
<pitti> freeflying_: also, will replacing the old fonts with the new ones work equally well for Korean, japanese, etc., too?
<freeflying_> pitti: these fonts are for chinese 
<pitti> ah, I see: 'Support for CNS 11643, GB 18030, Japanese and Korean is under heavy development'
<freeflying_> pitti: will not affect korean and japanese 
<pitti> ok, wonderful
<desrt> pitti; congrats
<pitti> desrt: what for?
<desrt> pitti; death to the hal-mounting :)
<pitti> death to the thread, rather
<desrt> christian just closed the bug WONTFIX
<pitti> oh, that reminds me... sjoerd? any progress?
<pitti> desrt: oh, in g-v-m or g-vfs?
<desrt> gvfs
<pitti> heh, yay
<seb128> desrt: what bug?
<desrt> seb128; someone proposed that we u/mount over hal
<seb128> he closed a bug with "We have davidz gnome-mount support in gnome-vfs HEAD so I guess this bug is
<seb128> obsolete. "
<desrt> this one
<seb128> it uses gnome-mount
<seb128> is that good or not?
<desrt> i don't know
<pitti> desrt: hm, that uses hal's mounting then
<desrt> BUT BUT BUT
<maswan> Kamion: done
<pitti> seb128: it's not
<seb128> what I though
<desrt> gnome-mount is a great spot to put a graphical unmount progress indicator
<seb128> :)
<maswan> Kamion: enjoy your flight-3
<desrt> :D
<seb128> desrt: Manny commented saying it should be done by nautilus
<pitti> right, but right now it's hal -> g-v-m -> hal -> gnome-mount -> hal -> mount
<seb128> so icon are removed from desktop at right time too etc
<pitti> instead of hal (unpriv'ed) -> g-v-m -> pmount
<desrt> seb128; gnome-mount explicitly gets passed DISPLAY with the expectation that it will show UI
<pitti> (right now == upstream, not in Ubuntu)
<desrt> seb128; and nautilus should just wait until gnome-mount (or whatever) terminates to remove the icon
<seb128> pitti: they use gnome-mount as an alternative to mount I think
<seb128> like we do for pmount
<seb128> just listed as a known binary
<pitti> yes, I think so, too
<desrt> important difference is that gnome-mount gets the environment.  pmount does not.
<pitti> TBH, gnome-mount is very young code, and UVF is the day after tomorrow, so I'd rather stay with pmount for dapper
<Riddell> maswan: kubuntu mirrored?
<desrt> pitti; right.  but i think we can abuse the gnome-mount hook
<maswan> Riddell: yes
<pitti> desrt: I agree that using sth like gnome-mount to read gconf and iteract with the user is a great idea
<Riddell> maswan: great, thanks
<pitti> desrt: so my favourite for dapper would be gnome-mount -> pmount and leave hal unpriv'ed as it is now
<desrt> pitti; ie: to display the unmount progress
<maswan> Riddell: http://ftp.acc.umu.se/mirror/cdimage.ubuntu.com/kubuntu/releases/dapper/flight-3/
<maswan> enjoy
<pitti> it's just too late to introduce such drastic changes into dapper now IMHO
<pitti> desrt: yes, that would rock
<desrt> seb128; nautilus for unmount progress indication really doesn't work
<desrt> seb128; think drivemount applet (possibly others?)
<pitti> desrt: how do you want to get data for a real progress indicator?
<desrt> pitti; i have an ancient patch on bugzilla
<pitti> desrt: a mere 'please wait' symbol/dialog would be easy
<sjoerd> pitti: you should see hal priv. seperation patch tonight :)
<desrt> pitti; it uses Dirty: field from /proc/meminfo
<pitti> desrt: so the kernel exports the state of cache flushing?
<pitti> oh, cool
<desrt> pitti; it's a bit of a hack
<desrt> pitti; but in most cases Dirty: will probably be mostly from your flashdrive mount 
<pitti> desrt: oh, that's just the total dirty blocks, not the #blocks for the device you unmount, right?
<seb128> we should probably do the hack thing for dapper
<seb128> that's not a nice bug the umount one
<desrt> pitti; right.  i don't know how to get device-specific info :(
<seb128> it bites quite a bunch of people
<pitti> desrt: me neither, that's why I wondered
<desrt> pitti; we could probably add love to the kernel :D
<pitti> seb128: I think we can do an easy workaround if everything else fails
<KoruptPryde> is there currently a known bug with wireless in the newest dapper updates?
* desrt hopes pitti isn't thinking what he thinks he's thinking
<pitti> seb128: we can just mount the device r/o, and then umount it
<pitti> desrt: ... which would be?
<desrt> sync mount :)
<pitti> bwah, no
<pitti> it bit us once, that's enough
<desrt> fwiw, my code on bugzilla calls sync()
<desrt> instead of readonly remounting
<pitti> that shoudl work as well
<desrt> so it might do more committing than required
<pitti> (but again syncs all drives)
<desrt> well.. think if you have 2 usb flash drives
<desrt> and want to unmount one
<pitti> desrt: do you see a problem with remount -ro, and then umount?
<desrt> you're now using up the bus speed for both :(
<desrt> pitti; yes.
<desrt> pitti; if someone starts using the files again while the FS is ro then the umount will fail
<desrt> pitti; so you'll be half-way unmounted
<desrt> pitti; but other than that, i like it
<pitti> . o O {chmod 0 /media/usbdisk}
<desrt> that would change the root directory permission of the mount itself
<pitti> right, not that in particular, but maybe something similar
<desrt> in the case of FAT it would probably do nothing :)
<desrt> well
<desrt> you know umount -l?
<pitti> yes
<pitti> pumount even supports that
<desrt> maybe we can figure out something like that
<pitti> but it's nto what we want
<desrt> detach from the filesystem then do the rest in the background
<pitti> we want the drive stay in /etc/mtab as long as it's syncing
<pitti> that's what g-vfs etc. look for
<desrt> uh.  why do i call sync()?
* desrt might be going insane
<desrt> hold a sec.
<desrt> ok.  i don't
<desrt> i just unmount... which forces a sync anyway
<desrt> why remount readonly?
<desrt> indead of just unmounting right away
<desrt> i mean.... that will provide us with the sync we need implicitly...
<pitti> desrt: it's just to leave the mount in /proc/mounts (or /etc/mtab, or whatever g-vfs looks for)
<desrt> aahhh
<desrt> so the icon stays
<pitti> so that the icons don't disappear
<pitti> yes
* desrt thought it was for syncing disk :p
<desrt> tunnelvision.
<pitti> desrt: well, actually it's both
<desrt> does umount() block?
<sjoerd> pitti: doesn't r-o mounting also error if the device is in use ?
<pitti> desrt: the program does at least
<desrt> pitti; ok... so why don't we do the more sane thing
<desrt> pitti; just modify umount not to nuke the mtab entry until the last second
<pitti> sjoerd: yes, but that's not different from normal umount, is it?
<pitti> desrt: WFM
<pitti> desrt: however, I'm not sure whether /proc/mounts or /etc/mtab is the important file
<desrt> right.  i'm just asking david zeuthen how hal works :)
* pitti hopes it's /proc
<pitti> /etc/mtab is such an ugly invention
<sjoerd> yeah /proc
<desrt> ya.  i wouldn't mind seeing /etc/mtab disappear
<pitti> I would actively welcome it
<desrt> or at least not live in /etc
<desrt> you'd have loved my gentoo install.  it was pretty hardcore :)
<pitti> ln -s /proc/mounts /etc/mtab breaks various things for me
<desrt> readonly filesystems with, at various times, /etc/mtab linked to /proc/mounts or /var/run/mtab :)
<pitti> like CD burning (IIRC)
<desrt> ok
<desrt> it's /proc/mounts
<desrt> and it uses the netlink socket to rececive notification of changes
<pitti> ok, so mod'ing mount wouldn't help at all
<desrt> indeed :(
<desrt> mod the kernel!!
<desrt> ahem.
<sjoerd> pitti: gnome-vfs still uses mtab afaik
<Treenaks> kernelmodding! add blue blinking lights etc!
<desrt> sjoerd; gnome-vfs is all hal since a while ago
<Treenaks> transparent casings!
<sjoerd> iirc it currently only uses hal for extra info, not depending on it 
<pitti> sjoerd: only as a fallback IIRC
<pitti> hm, gotta check that
<pitti> sjoerd: btw, what's your general approach wrt hal derooting take #2?
<pitti> sjoerd: separate daemon?
<sjoerd> yeah
<pitti> sjoerd: it would also mean that all policy checks have to go into the hald helpers itself, like the mounting stuff,etc.
<sjoerd> just before dropping privs hal startups a small program that connects to a local dbus socket
<pitti> sjoerd: ok, so that's the solution mjg59 and davidz wanted to implement
<pitti> sjoerd: I think it's a sane compromise
<sjoerd> it was the solution hal 0.5 was designed for in the beginnen
<sjoerd> it just was never implemented
<pitti> but then hald proper must not do any policy checks any more
<pitti> or, rather, the called helpers need to do them
<sjoerd> well, the first patch will just be to add the daemon 
<pitti> yes, that'll be the groundwork for the new architecture, but doesn't help security-wise
<pitti> but thanks a lot for working on that :)
<sjoerd> you've got to start somewhere :)
<pitti> I thought about doing that over the weekend, but since you already worked on it, I didn't
<sjoerd> yeah i actually started last monday but already thought about it some weeks before
<sjoerd> the first patch will indeed be just groundwork.. But for debian the important part is that the addons and probers will start with elevated priv.
<sjoerd> didn't look too much at the callouts yet, they've indeed got some other security issues (like potential policy checks)
<pitti> sjoerd: My feeling is that for dapper we will keep pmount and just use hal for power management
<sjoerd> seems a save choicee
* sjoerd hasn't looked a gnome-mount yet
* pitti neither
<sjoerd> the current powermanagement in hal is just suspend/hibernate/blah and the dimming the lcd right ?
<pitti> sjoerd: I guess so, yes
<pitti> sjoerd: moving that to a callout should be relatively straightforward
<sjoerd> they already are
<hunger> pitti: Could you please move a initscript around for me?
<pitti> so much the better
<pitti> hunger: let me guess - S20checkroot?
<hunger> pitti: ifupdown-clean is run before checkrootfs...
<pitti> haha
<hunger> pitti: Guess so.
<pitti> that's the same bug I talked about with infinity this morning :)
<pitti> hunger: indeed, it's on my todo list and I will discuss this with keybuk as soon as he's back
<hunger> pitti: malone #28559 is the one I filed about this.
<Ubugtu> Malone bug 28559: "ifupdown-clean script fails" Fix req. for: ifupdown (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/28559
<pitti> hunger: I'm not sure how that would interact with this boot modifications (not at all I guess, but ...)
* pitti grabs that bug
<hunger> pitti: As it is now lo is not brought up since ifupdown-clean is trying to delete the state-file on a ro-filesystem.
<Kamion> maswan: thanks!
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity
<pitti> yay flight 3
<pitti> thanks Kamion 
<hunger> pitti: The state file of course claims lo to be up already... thus ifup does not bring it up.
<pitti> hunger: yes, I'm aware of that; bootlogd breaks as well
<sjoerd> pitti: btw policy checking in the callouts is difficult, as you can't know who actually requested the action.. 
<hunger> pitti: Good:-) Then all I have to do is wait!
<pitti> sjoerd: I rather mean checks similar to pmount: only mount hotpluggable drives etc.
<pitti> sjoerd: i. e. if I break hald I must not be able to call the helper to mount /dev/hda1
<Kamion> (waiting for ubuntu-announce approval)
<sjoerd> exactly, only really paranoid checks will work
<mgalvin> Kamoin: DapperFlight3 is all set
<pitti> sjoerd: essentuially these cheks must not rely on the hal database, that's why it's still my impression that they could as well be separate dbus services
<pitti> which would be maximum decoupling
<sjoerd> exactly
<pitti> but upstream doesn't like that
<sjoerd> well the odd thing is that at one point they wanted to throw out policy from hal, but now it's comming back sortof
* Yagisan is tired. I read that as Dapper Fight 3
<pitti> Yagisan: ask Kamion, he'll agree that it was indeed a fight :)
<Kamion> mgalvin: thanks, much appreciated
<sjoerd> pitti: well they fully trust dbus for enforcing it iirc (as in only certain users can call the callout)
<mgalvin> Kamoin: np, glad to help
<pitti> sjoerd: I see more trouble on the list
<pitti> sjoerd: (in my crystal ball, that is)
<mgalvin> segfault: DapperFlight3 is ready to translate, sorry for the short notice
<sjoerd> pitti: like ?
<pitti> sjoerd: well, convincing upstream :)
<sjoerd> hehe
<desrt> Yagisan; it was a fight :)
<Yagisan> heh
<desrt> martin has claws.  i saw them
<desrt> don't fuck with him :)
* pitti looks at his very short fingernails
* Yagisan points out that could be taken quite literally, and is suddenly very scared
* Yagisan claws eyes out
<Yagisan> congrats all on flight 3
<ogra_ibook> :/
<whiprush> jamesh: fridged, thanks for the reminder.
<siretart> Kamion: congrats on flight3!
<Kamion> ta
<whiprush> Kamion: the sprint is in london correct? this month? (wanted to mention it in the next fridge post)
<pitti> whiprush: Jan 30 to Feb 4
<ogra> whiprush, rather beginning of february, it starts on the 30th
<whiprush> thanks guys
<tseng> ogra: well i tell gpm to suspend after "30 minutes", is that X idle time, screensaver time, or cpu idle?
<tseng> s/well/when
<ogra> X idle i think
<tseng> it could even mean "30 minutes after loosing AC"
<tseng> very ambiguous
<pitti> BenC: ping
<ogra> hughsie is in #hal normally ...
<ogra> tseng^^
<ogra> complain at him ;)
<tseng> i will
<tseng> but he's not
<ogra> oh
<ogra> he normally is
<tseng> gnome bugzilla?
<ogra> yup
<tseng> elite
<Diziet> Gah, I've spent an hour trying to find where this patch was and it was somewhere else entirely.
<ogra> Diziet, on new installs firefox segfaults with "Bus Error" if i try to open the preferences 
<ogra> known ?
<Diziet> ogra: Yes.  You're on amd64, right ?
<ogra> yup
<Diziet> We think this is something to do with the new biarch libc but don't know whether it's a ff bug or not.
<ogra> oki
<Diziet> ff itself hasn't changed; it's been FTBFS on amd64 for a week or two.
<ogra> i'll check on powerpc to confirm its amd64 only
<Diziet> Plan is try new upstream (and fix the FTBFS) and see if that helps.
<Diziet> Ta.
<Diziet> (Other reports suggest ppc is ok)
<Diziet> The trouble with carrying lots of patches is that not only do you spend effort finding and applying them, and fixing up the rejected diffs etc., but when eventually they get taken up upstream you have to do effort again to disentangle them.
<elmo> M?rio Meyer, Jerome S. Gotangco, Og Maciel, Carlos Eduardo Pedroza Santiviago, Lionel Dricot, Trent L\loyd, Andi Darmawan, Dennis Kaarsemaker, Jani Monoses, Chris Peterman, Loic Pefferkorn, Sivan Green\berg, Seth Kinast: your ubuntu.com email has been disbaled because it's looping back, please change your preferred email to something other  than you@ubuntu.com
<Mithrandir> wouldn't it be useful if lp refused to add @ubuntu.com addresses as preferred?
<elmo> Mithrandir: and there's a spec for it to do that - are you volunteering to help?
<Mithrandir> elmo: I didn't know, and no, I think my efforts are better spent elsewhere. :-)
<sivang> elmo: I didn't have any trouble so far, what causes the loopback ?
<elmo> sivang: your preferred email is set to ubuntu.com; you can't do that.  set it to whatever you want @ubuntu.com to forward to
<sivang> elmo: I understand the nw situation, but so far it has always worked (I received all lp notifications, and had no issues in receving emails like password reset etc) , what changed?
<elmo> the script updating ubuntu.com got broken by unrelated changes in launchpad, it only just started working again
<maswan> Mithrandir: remind me, tomorrow, to kick ravel. I just thought of it on my way home from work.
<sivang> elmo: ok, I see now that the wording had changed in the email editing page of lp, I changed it then, thank you.
<Mithrandir> maswan: will try to remember.
<Mithrandir> maswan: or do you have a work address I can send the request to? :-)
* tseng gives Mithrandir tomboy
* Mithrandir watches his 1.5GB of memory get eaten by a notetaker.
<tseng> it only uses 17mb :)
<tseng> the mixer applet uses 11
<Mithrandir> depends on how and what you count.  Here it uses 20 or 2.
<maswan> Mithrandir: maswan@hpc2n.umu.se, yes, I won't read that until tomorrow. :)
<Mithrandir> maswan: reminded
<maswan> Mithrandir: I got gthumb to OoM itself with a large jpeg on my 2GB ram workstation. :)
<Mithrandir> gthumb is, for some insane reason eating hilarious amounts of memory
<hyperactivecrond> is there a site admin around here who could un-delete my wiki account?
<ogra> hyperactivecrond, try #launchpad
<hyperactivecrond> thx ogra
<segfault> mgalvin_lunch: thanks, i'll translate ASAP>
<elmo> doko: ?
<ogra> Kamion, maswan, edubuntu ready for release 
<Kamion> ogra: to confirm, edubuntu daily 20060116 and daily-live 20060112.1?
<ogra> Kamion, everything the "current" link points to
<Kamion> ogra: no need to bother maswan until it's actually published
<ogra> oki
<ogra> Kamion, the locale prob only happens with missing langpacks (anything except en in edubuntus case)
<Kamion> ogra: can you clarify that?
<Kamion> oh, I see what you mean, you don't even have the base langpacks on the CD
<ogra> Kamion, i only have the english langpack on the edubuntu CD, if i install in german i get the usual locale breakage
<ogra> yup
<ogra> no space 
<Kamion> ok, but localechooser 0.27ubuntu2 should have fixed that :(
<ogra> even if amd64 installs fine
<Kamion> the locales are all in locales.deb now, and it runs locale-gen on the locales you're using
<ogra> i'll get you the logs
<Kamion> or at least, it's meant to
<Kamion> thanks
<doko> elmo: pong
<elmo> doko: you lose
<ogra> Kamion, http://people.ubuntu.com/~ogra/edubuntu/logs/syslog
<doko> elmo: ?
<ogra> Kamion, erm, sorry, wrong log ...
<ogra> Kamion, updated, now its right ...
<Kamion> I was wondering, the base-installer bits looked really weird
<ogra> heh, thats flight2 :)
<Kamion> ok, there's an error there yes, but it's protected by || true
<Kamion> (although that error does suggest that we shouldn't be trying to install the language pack at that point, because apt-setup hasn't run yet)
<ogra> i only see Jan 16 15:29:03 apt-install: E: Couldn't find package language-pack-de
<Kamion> yeah, that's the error I'm referring to - it's not actually directly related to this problem though
<Kamion> any chance you could do a fresh install, and before you get to installing the base system, edit /usr/lib/post-base-installer.d/05localechooser and change the third line from 'set -e' to 'set -ex'?
<Kamion> if not, don't worry, I'll try it myself shortly
<ogra> i'll try
<Kamion> thanks
<Kamion> this is weird, I can only assume that locale-gen isn't working
<ogra> if i run it in /target it doesnt give any output ...
<ogra> i circumvented the postgres error this way ...
<Kamion> maswan: edubuntu flight-3 up for mirroring too
<ogra> you can det it to C in /etc/locale.gen
<Kamion> ogra: ^--
<Kamion> /etc/locale.gen's obsolete
<ogra> thanks :)
<ogra> ah, k
<Kamion> we use 'locale-gen de_DE.UTF-8' or similar now
<ogra> but it worked if i ran it once chrooted in /target 
<ogra> ah, thats why it doesnt give output, ok
* mvo is away to play hockey
<seb128> elmo: please sync gazpacho
<Kamion> ogra: it's also possible I'm giving it the wrong arguments, hence the request for set -x output
<ogra> yup
<elmo> seb128: done
<seb128> elmo: thank you
<slomo> elmo: please sync fatsort from debian/unstable... ubuntu changes can be dropped
<slomo> elmo: and pygame... for whatever reason it isn't synced automatically
<segfault> mvo?
<segfault> any luck on malone #6506?
<Ubugtu> Malone bug 6506: "selector (Ubuntu) - gnome-language-selector fails to run on dapper" Fix req. for: language-selector (Ubuntu), Severity: Normal, Assigned to: Michael Vogt, Status: Unconfirmed http://launchpad.net/bugs/6506
<maswan> Kamion: ok, doing another mirror run
<Kamion> ta
<maswan> Kamion: I'm going to be off for some hours now though, perhaps as many as 8-10
<Kamion> no problem, we're done with releases for today
<ogra> Kamion, runs through with set -x, i'm at ltsp chroot building now ...
<Kamion> ok, syslog from that much should be fine
<ogra> Kamion, http://people.ubuntu.com/~ogra/edubuntu/logs/syslog.1
<Kamion> ogra: ok, thanks - I claim a locale-gen bug
<Kamion> ah, I see
<Kamion> will look further tomorrow but I think I know roughly where this is
<ogra> great :)
<ogra> Kamion, thanks 
<Kamion> basically it requires a language pack to be installed in order to get out of bed
<Kamion> oh, heck, this is obvious, I'll fix it now
<Kamion>  locale-gen |    1 -
<Kamion>  1 file changed, 1 deletion(-)
<Kamion> trivial once you know which line to delete ...
<ogra> what was it ? 
<ogra> i just saw it searches in /var/lib/locales/supported.d/
<ogra> which seems hardcoded
<Kamion> it checked [ "`ls $SUPPORTED`" ]  unconditionally when it should only have been checking it if you didn't give it any locale command-line arguments
<Kamion> (it checked it in the latter case too, so I just removed the first check)
<ogra> ah, heh, easy
<Kamion> I'll fix the language-pack installation tomorrow
<ogra> its not a race, take your time ;)
<mdke> Kamion, is ubuntu express going to be documented, or is that something the doc team might want to consider working on?
* lamont wonders why /etc/init.d/hostname.sh complains about perfectly the perfectly valid '.' in the hostname
<lamont> hrm.. actually, iz hostname command
<lamont> that's completely b0rked.
<lamont> 2.90:   * A check_name function was added to check whether hostnames follow RFC
<lamont>     1035 syntax.
<lamont> never mind the extensions to that syntax.
<lamont> nevermind allowing you to set hostname to the FQDN..
<lamont> sigh
* lamont files a bug
<lamont> actually, time to add comments to the existing bug
<Kamion> mdke: not sure, there's some documentation from Guadalinex but I think given my time constraints it might be better for the doc team to do it
<Kamion> no point doing it just yet, of course
<daniels> oh, flight 3 during the 'evening'
<daniels> Kamion: woo, thanks
<mgalvin> segfault: just a heads up, i added the edubuntu flight-3 download link to DapperFlight3 as well
<mdke> Kamion, thanks, sure
<HiddenWolf> daniels: latest desktop meeting still has a note from you that you're going to break X early jan. Is that still going to happen?
<ogra> mgalvin, oh, thanks a lot, that saves me a separate announcement :)
<Kamion> ogra: a separate announcement to at least some Edubuntu mailing list would be good
<daniels> HiddenWolf: i'm going to break X when I'm more lucid and less 6:30am
<mgalvin> ogra: sure, np :)
<Kamion> I wouldn't rely on the wiki for announcement value
<ogra> Kamion, yes, but i'm not after LWN publicity :)
<Kamion> it's fantastic for documenting what sort of things have changed
<Kamion> ogra: sure, but you are after testing
<daniels> HiddenWolf: not the server or anything though, just the metapackages
<daniels> HiddenWolf: nothing even remotely resembling breezy's level of, er, entertainment
<ogra> Kamion, yup
<HiddenWolf> daniels: right, so my question is, can I upgrade and have a semi-dependabele testing system, or should I wait a tad longer?
<daniels> HiddenWolf: now is fine
<HiddenWolf> daniels: cool.
<HiddenWolf> daniels: something I've been wondering for a while. My mouse dims it's light under windows when inactive, not under linux. Is that kernel, x, or something else?
<daniels> HiddenWolf: kernel
<HiddenWolf> daniels: ah, right, sorry for bugging you in the early morning. :)
<daniels> HiddenWolf: no worries.  wasn't you who set the alarm.
<elmo> daniels: did you see my question about renderext the other day?
<daniels> elmo: yeah; guess you didn't see my /msg telling you to please trash it
<elmo> no, sorry, apparently not
<elmo> were you registered?  I don't have anything in my scrollback from you ;-P
<daniels> probably not
<daniels> WHOOHOOHOO FREENODE
<ogra> elmo, did you get my message to wipe the ltsp-client-builder source in dapper ? 
<janimo> elmo, please sync/override xfce4-terminal and xfmedia . thank you
<LaserJock> elmo: I looked into why octave2.9 and basically Debian made a mistake that made both octave2.1 and octave2.9 build an octave virtual package
<LaserJock> elmo: so I think we should wait for Debian to clean up and then everything should build ok
<Simira> good evening, sabdfl 
<daniels> god, xmms == teh win.  give it a non-existent filename on the command line and it segfaults.
<Chipzz> AAAAAAAAAARGGGGGGHHHHHHHHHH
* Chipzz kicks ubuntu live cd in the nuts
<Chipzz> grrrrrr
* HiddenWolf gives Chipzz his pills
<Chipzz> I just want a fucking console
<Chipzz> configure keyboard, alt-f2, chroot
* ogra gives ubuntu live a bag of ice
<Chipzz> damn thing starts fucking the console I was working on
<Chipzz> *sigh*
<HiddenWolf> Chipzz: dude, chill, then file bugs
<Chipzz> yeah
<Chipzz> :)
* Chipzz rolls his eyes :P
<Burgwork> the new ugly non-themed libnotify popups, who do I beat up for them?
<HiddenWolf> Burgundavia: if you find out, i'll get tar and feathers. :)
<ogra> Burgwork, the app developer
<Burgwork> HiddenWolf, sounds good
<ogra> in case ayou mean popping up standalone windows, thats from apps that reant fully ported to the new libnotify yet
<Burgwork> dholbach, yer has a typo in dasher
<Burgwork> ogra, the new pop dialog that has the non-straight edge
<ogra> s/reant/arent/
<dholbach> Burgwork: tell me
<Burgwork> dholbach,  dasher (3.99.1-0ubunut1) dapper; urgency=low
<ogra> Burgwork, ah, you mean the bubble with the stairs :)
<HiddenWolf> ogra: any popups should be themed human/$yourtheme rather than whatever decoration $developer thinks is appropriate.
* daniels giggles.
<Burgwork> ogra, yep
<daniels> at least we've not had 'ubunto' in a version that I've seen
<dholbach> Burgwork: nice... we'll have to stick to it until 3.99.1-1 in debian ot 3.99.2 upstream
<Burgwork> dholbach, yep
<ogra> or until you upload a -zubunutX :)
<ogra> -0zubunutX*
* dholbach takes away ogra's crack pipe.
<dholbach> :)
<ogra> :)
* ogra sighs about his bzr push ... pushing 1 line change ... 30min ...
<Burgwork> HiddenWolf, do you know who is upstream for libnotify?
<HiddenWolf> Burgwork: http://cia.navi.cx/stats/project/galago/libnotify
<HiddenWolf> Burgwork: chipx86, johnp, mike, mikeh are listed as authors
<Burgwork> HiddenWolf, don't see in upstream bug reports over this annoyance
<HiddenWolf> Burgundavia: best ask one of the upstreams about it. If a bug is filed, it'll soon have a few confirm messages. :)
<dexem> is there any known bug with ndiswrapper/dapper? my bcmwl5a doesn't create any network interface...
<Burgwork> HiddenWolf, I just emailed chipx86
<sivang> Burgwork: found a bug ?
<Burgwork> sivang, in libnotify? no, merely that the popup is not themable and currently looks rather ugly
<sivang> Burgwork: it doesn't blend nicely..
<Burgwork> sivang, no, it doesn't and being able to fully theme it fixes 2 bugs with one hit
<sabdfl> BenC: ping
<sabdfl> mdz: ping
<sivang> Burgwork: what's the other one?
<siretart> elmo: did you get the sync requests from the last days or shall I resubmit them via email?
<HiddenWolf> daniels: ping
<Burgwork> seb128, have you seen the new stuff gnome-panel upstream has done with logout
<seb128> Burgwork: sure
<seb128> they didn't change gnome-session though
<seb128> they just have extra items from the panel
<Burgwork> yes
<Burgwork> just wondered how we are going to merge upstreams work with ours
<seb128> why?
<seb128> they is no conflict
<seb128> the hack is one gnome-session
<seb128> the panel applet stills open gnome-session dialog
<seb128> that doesn't conflict with the new panel dialogs
<Burgwork> http://bugzilla.gnome.org/show_bug.cgi?id=92277
<seb128> I know about that bug, I'm subscribed
<daniels> HiddenWolf: pong
<daniels> seb128: good morning mc sebtastic
<Burgwork> seb128, ok
<seb128> hey daniels
<Mithrandir> seb128: it seems like gdm loses focus when you point your mouse pointer outside it now.  It didn't in breezy.  Is this known or should I file a bug?
<seb128> Mithrandir: outside of what? It's supposed to be fullscreen, no?
<daniels> oh, that reminds me
<Mithrandir> seb128: no, it just covers one screen.  I have two screens.
<daniels> seb128: is the gdm nested login stuff using xephyr yet?
<Mithrandir> as in, two monitors and xinerama.
<seb128> daniels: no
<daniels> seb128: boo
<seb128> daniels: patches are welcome :)
<daniels> heh
<daniels> got too much else to tie up
<seb128> Mithrandir: dunno about that ..
<Mithrandir> seb128: I'll just file a bug, then
<seb128> daniels: I've quite overloaded with GNOME stuff atm
<seb128> Mithrandir: yeah better
<daniels> seb128: fair enough
<seb128> s/ve/m
<Burgwork> lamont,  hostname (2.91.0ubuntu1) dapper; urgency=low <-- should that not be -0ubuntu1 ?
<lamont> Burgundavia: if the previous version weren't 2.91, then probably
<HiddenWolf> daniels: guy with a working but messed up xorg here, http://www.fruk.org/stuff/Screenshot.png
<HiddenWolf> daniels: Guess you'd want a bug, but what info should he report?
<daniels> HiddenWolf: Option "AccelMethod" "EXA" in Device section of xorg.conf, or probably Option "XaaNoOffscreenPixmaps"
<lamont> but since there's already a hostname_2.91.tar.gz in the archive, it'd be bad to upload 2.91-0ubuntu1
<daniels> i have *lots* of bugs about that
<Burgwork> lamont, just wondering if it was a typo
<Den> Mithrandir: Hi U there?
<HiddenWolf> daniels: that's exa's doing?
<daniels> something in cairo triggers xaa badness, and no-one's quite sure where (especially since I can't reproduce it locally)
<lamont> nah, my script originally called it '2.91ubuntu1', but that had it's own issues...
<daniels> HiddenWolf: nope, it's xaa's doing; exa should mitigate the problem
<Burgwork> lamont, I trust that you are smarter than me
<HiddenWolf> daniels: told him.
<daniels> HiddenWolf: ta
<Den> Anyone know if Mithrandir is actually here now?
<Mithrandir> Den: 'sup?
<HiddenWolf> daniels: EXA option helped him. Anything he can do to help debug?
<daniels> HiddenWolf: not really, to be honest
<Den> Mithrandir: Hi - Thanks for you r help.  Do you know i f the firewire cd update you did went into the live iso for kubuntu as well as ubuntu?
<daniels> it just needs some benh/anholt love\
<Mithrandir> Den: except that I didn't get around to actually _uploading_ it, it does, yes.  I'll just commit it on the trunk and hope for the best now.
<Mithrandir> Den: sorry about that. :-(
<Den> Mithrandir: noprob.  I would like to get at as soon as possible - any idea when it will get uploaded?
<HiddenWolf> daniels: ok, cool, thanks
<Treenaks> daniels: did you see my registerdumps?
<Den> Mithrandir: Also, any idea when you might be able to respond to the aprox two to 3 emails I sent you a few days ago?
<daniels> Treenaks: i did, thanks
<Treenaks> daniels: (speaking of ATi :))
<daniels> Treenaks: i'm looking at those today
<mdke> Riddell, did you move the build directory for kubuntu up a directory in the ubuntu-docs repository? Some of the web targets aren't working any more and the preview server hasn't updated the kubuntu stuff for ages
<Treenaks> daniels: cool :)
<Mithrandir> Den: new casper uploaded now
<LaserJock> is it normal for Xorg to have RES 278MB in top?
<Den> Mithrandir: The "base" cd - did you get that one uploaded properly a fw days ago?
<Mithrandir> Den: yes, I think so.
<Den> Mithrandir: is casper the daily dapper?
<daniels> LaserJock: the answer to those questions is always 'yes'
<Mithrandir> Den: yes, the image on http://cdimage.ubuntu.com/daily-live/current/ is, well, current.
<Mithrandir> Den: that's rsyncable too, so the download should be smaller.
<LaserJock> daniels: really, my system is crawling to a halt and I've only got 50MB of memory free (out of 512) and all I have is firefox, thunderbird, and a termianl
<Mithrandir> Den: note that the change I committed won't be visible until the next live rebuild which will finish in about 12 hours.
<Den> Mithrandir: Will that change go into kubuntu daily live besides ubuntu?
<Mithrandir> Den: yes
<Den> Mithrandir: Thanks!  I'll be eagerly awaiting the next live rbuild.
<daniels> LaserJock: close those first two and your free memory will soar
<Mithrandir> Den: I'm writing up a presentation and need to get up early tomorrow, but I'll answer your mails tomorrow.
<daniels> LaserJock: the Xorg RES figure includes such insignificant figures as, oh, your entire video RAM
<Den> Mithrandir: The "base" iso you had me dl didn't boot to a command line prompt, should it have?
<Mithrandir> Den: yes, I'd think so, unless something went wrong.
<LaserJock> daniels: oh, ok. but my system seems to be stuttering a lot and using swap a lot
<Den> Mithrandir: it got further than the ubunt live, which perhaps means the firewire fix worked, but it died saying something about (I really forget this, it's been several days since) about maybe trying some names, them not working, and the names being repeated too often.
<Mithrandir> Den: yes, I remember that, it's a sign of it not finding the cd, really.
<LaserJock> daniels: ok, closing firefox and thunderbird gave me back 55 MB but I'm still using 397MB with only a terminal open
<Mithrandir> Den: and it shouldn't, ever, spit out those messages, but that's less important.
<Den> Mithrandir: If you  really want to know, let me know & if I can find that cd I'll try it again & record the err messages - do you want me to do that?
<Mithrandir> Den: no, that's not needed.  If you could just test tomorrow's CD when it's out and give me feedback, that'd be nice.
<lifeless> are there any 'how to debug that pos evolution after it hangs' guides ?
<Den> Mithrandir: Is there some web page that shows the fix you did to try to make the firewire cd work?
<Mithrandir> Den: I just asked the live cd to include two more modules in the initramfs.
<Den> Mithrandir: Is that in a text file, or compiled into something?
<Mithrandir> Den: text file.
<Mithrandir> Den: that is, the text file is used for building an initramfs image which is stuck into the iso image.
<Den> Mithrandir: Where can I find that text file?
<Mithrandir> Den: install bzr and do bzr get http://people.ubuntu.com/~tfheen/bzr/casper/trunk
<LaserJock> daniels: I don't want to be a pain about this but I have seen a big change in my desktops performace from a few weeks ago. My system really drags when I do anything CPU intensive
<daniels> lasti don't know, man
<ogra> hrm ... i do a bzr get, change a file, commit and do a bzr push ... 
<ogra> bzr: ERROR: These branches have diverged.  Try a merge then push with overwrite.
<lifeless> ogra: that means that someone else pushed before you
<ogra> DEAR bzr i only have changed one line !!
<Den> Mithrandir: What's an "intramfs image"?
<lifeless> ogra: so you have to integrate their changes before you can push
<ogra> lifeless, i did this procedure 5 times in a row now ... (including wiping the whole local tree every time)
<LaserJock> daniels: so is it worth a bug report? I can't imagine anything useful I could report other than "It used to be better"
<ogra> i doubt taht anybody except myself pushes to the edubuntu seeds
<Mithrandir> Den: do you know what an initramdisk is?
<lifeless> ogra: dont wipe the local tree, theres no need to do that
<Den> Mithrandir: no
<johnl> LaserJock, have you tried asking on #ubuntu?
<lifeless> ogra: and if its reproducible, come on over to #bzr and get someone to help you!
<johnl> LaserJock, that's the place to discuss that stuff
<Mithrandir> Den: http://lwn.net/Articles/14776/ has a little bit of explanation.
<ogra> lifeless, i will ... one last try ... have to wait anyway 20-30 min until sftp decides to finish the push :)
<LaserJock> johnl: well, perhaps, I just want to know if it is worth a bug report
<Den> Mithrandir: Thanks!
<johnl> LaserJock, tell you what, take it over to #ubuntu first and I'll see if I can help
<LaserJock> johnl: ok, thanks
<slomo> elmo: please sync taglib, fatsort and pygame from debian/unstable... ubuntu changes can be dropped
<lamont> grumble.
<lamont> I want a way to tell apt to use a proxy, but only for update
<tseng> lamont: export http_proxy="http://yourproxy:80
<tseng> "
<tseng> apt-get update
<tseng> unset http_proxy
<tseng> alias that all together or something.
<lamont> tseng: that's what I _am_ doing
<lamont> but I want an apt.conf entry to do it for me... :-)
<tseng> :)
<lamont> or better yet, they could fix the stupid non-transparent proxy I'm behind
<tseng> we have a cisco content engine in line at work, its pretty unintelligent as well
<lifeless> lamont: transparent' proxies generally aren't.
<lamont> lifeless: exactly
<lamont> but without the proxy, they can't play big-brother and waste money scraping log files to make sure we're all good little kids
<lamont> the proxy is transparent enough for upgrade, but not so good for Packages.bz2
<azeem> lamont: you could use a different apt.conf for update, like apt-get -c /etc/apt/apt.conf.update update
<lamont> azeem: I'm trying to make it so update-notifier actually (a) works, and (b) doesn't trash the package cache
<lamont> s/cache/lists/
<azeem> ah
<lamont> that and so I don't have to remember the funky differences
<lifeless> lamont: send it off on wild goose chases
<lifeless> i.e. ask for cnn.com at the playboy ip address
<lamont> lifeless: how does one encode such a URL?
<lifeless> GET /index.html HTTP/1.1
* lamont used to know, but can't remember
<lifeless> Host: www.cnn.com
<lifeless> 
<lifeless> 
<lamont> ah, ok.  any way to get firefox's UI to do that for me? wget?
<lifeless> firefox - add a local alias to hosts
<lamont> generally, I want that for testing a virtual-hosted domain before making it production
* lamont vomits on firefox
<Seveas> lamont, /etc/hosts can be useful there
<Kamion> 21:18 < ogra> i doubt taht anybody except myself pushes to the edubuntu seeds
<Kamion> ogra: bzr log says I've made about half as many commits to the Edubuntu seeds as you have
<Kamion> one of those was this evening
* dholbach hugs Kamion.
<ogra> Kamion, but i did a bzr get in a new location after your commit and still couldnt push
<Kamion> that I dunno about
<ogra> its solved now ...
#ubuntu-devel 2006-01-22
<Seveas> When will flight 3 be announced?
<Kamion> Seveas: the announcement's been in the ubuntu-announce@ moderation queue for hours; I can't do anything about it
<Kamion> jdub: please moderate kthx :)
<Seveas> hehe
<jdub> Kamion: morning!
<daniels> GOOD MORNING FREEDOM LOVERS
<daniels> et al
<daniels> i'll be your jdub for this evening
* dholbach hugs daniels
<Seveas> hmm, /me gets a vision of daniels in an orange overall....
<daniels> dholbach: hug day, eh
<jdub> Kamion: whooosh
<dholbach> Everyday's a HUG day! :)
<Kamion> jdub: ta
<daniels> dholbach: hoorah
<mpt> daniels, "et al" meaning "and those who hate freedom too"? :-)
<daniels> mpt: more along the lines of 'and other jdubisms'
<mpt> ah, et seq
<dholbach> good night everybody.
<tseng> Kamion: the one stage installer is amazing, nice work
<Kamion> tseng: glad you like it; well over half the credit belongs to joeyh, mind
<Kamion> though I admit to writing debconf-apt-progress, which helped :)
<tseng> :)
<poningru> how come the flight 3 email isnt sent yet?
<tseng> poningru: its sent since hours.
<poningru> oh sorry
<Kamion> poningru: it was only just moderated; the list server is presumably chugging its way through the thousands of subscribers
<poningru> ah gotcha
<poningru> cause I still havent gotten it
<poningru> thanks tseng, Kamion 
<HiddenWolf> poningru: it's in here.
<HiddenWolf> on it's way.
<infinity> elmo: Around?
<elmo> infinity: maybe
<infinity> Oh, yay!
<infinity> Care to hit the big red button on an autosync run?
<elmo> oh, right
<elmo> err, hang on
<elmo> autosync?
<elmo> no
<infinity> As well as syncing wvdial (overwrite okay), and neon from experimental (so we can get the new subversion)?
<elmo> our mirror doesn't get updated for a while yet
<infinity> No more autosync?  UVF isn't for 3 days... Oh.  Mirror update.  Right.
<elmo> UVF is in 3 days?  eek
<infinity> Eek indeed.
<daniels> haha
<daniels> suckers
<daniels> (ahem)
<jdub> what does << mean in depends definition again?
<daniels> less than
<elmo> must be less than
<daniels> <<, <=, =, =>, >>
<jdub> oh, i see
<jdub> thanks
<jdub> thought it might be an extra special less than
<daniels> it doesn't mean left shift :)
<daniels> haha
<jdub> LESS THAN OR DIE
<daniels> really, seriously less than
<daniels> we're not shitting you this time
<Kamion> it used to be < and > but was changed; I forget why
<mpt> it looks prettier
<Kamion> mpt: ah, no, found the reference
<Kamion> < and > were (I suspect mistakenly) used to mean <= and >=
<jdub> Kamion: !
<Kamion> since that was obviously confusing and fixing it would've broken compatibility, << and >> were introduced instead
<jdub> compatibility >> stupidity
<jdub> ;-)
<Kamion> I guess it was originally < = > and then < and > were each split into two forms
<Kamion> but the changelog isn't clear and the bug report predates bug archiving
<elmo> infinity: done
<infinity> elmo: Yay.
<jdub> hrm, can i optionally build depend on something?
<daniels> Build-Depends: some-crap | libc6
<jdub> i was thinking python-gst | python-gst0.10
<jdub> but i actually want both
<jdub> oh right
<jdub> cheeky
<jdub> thanks
<daniels> (if you actually upload that to the archive, I am totally not responsible.  especially if elmo finds out.)
<jdub> heh
<jdub> is there a sensible way of doing it that elmo will not yell at me for?
<daniels> well, it's not really a Build-*Depends* if it's optional ...
<infinity> jdub: Optional build-deps are just plain wrong.
<jdub> it's for breezy source compat :-)
<infinity> jdub: We want homogenous builds on the buildds.  Saying "well, sometimes would could install this and the package will be different" is just..  Eww.
<jdub> yeah, it just means that the builds will differ between breezy and dapper
<infinity> jdub: For breezy backporting, then use the form "dapper-build-dep | breezy-build-dep", so we'll pick up the dapper on and ignore the breezy one.
<jdub> yeah, but in this case, that's python-gst0.10 | libc6
<infinity> Erm, no.
<daniels> i can't remember how the sbuild semantics work
<infinity> Oddly, I can. :)
<jdub> it's python-gst0.10 on dapper or nothing on breezy
<daniels> i think in debian it always tries the first one if possible, but ubuntu's will happily continue if one of the alternatives is already installed
<jdub> both will depend on python-gst (0.8)
<jdub> btw, is this correct for build-depends: python-twisted (>= 1.3.0), python-twisted (<< 2.1.0)
<infinity> daniels: In both cases (Debian and Ubuntu), if one is installed, it wins.
<daniels> obviously the only solution is to make python-gst depend on python-gst0.10 in dapper ;)
<daniels> infinity: i see
<infinity> daniels: Our difference is that if the first is uninstallable, we try the alternatives.
<infinity> s/uninstallable/unavailable/
<jdub> daniels: python-gst == 0.8, python-gst0.10 = 0.10
<daniels> jdub: i know, hence the ;)
<jdub> you're a bad person
<daniels> infinity: ah.  i remember debian's being retarded, but not the exact stupidity.
<jdub> so, afaics, | libc6 is the solution here
<daniels> jdub: well, duh.  hacking X, remember?
<infinity> jdub: No.  No, no, no. :)
<azeem> infinity: but in Debian, if the alternative is already installed, sbuild continues anyway, right?
<daniels> jdub: mmm, but that won't get installed in dapper either, since libc6 is already installed
<infinity> azeem: Right.
<jdub> daniels: nice!
<jdub> so is there a solution, or do i molest the package for breezy compat?
<daniels> yeah.  it was a cute idea though.
<daniels> molest is always best
<infinity> jdub: Erm, why would you want BOTH python-gst and python-gst0.10 as build-deps in dapper anyway?
<infinity> jdub: That seems broken.
<jdub> infinity: it sounds broken, but makes total sense. flumotion will happily use either.
<jdub> some will want to run it with 0.8, some with 0.10
<infinity> jdub: Anyhow, if you do, you can use "Build-Depends: python-gst, python-gst0.10 | python-gst (<< 0.8.2)" may do what you want.
<jdub> ahr!
<infinity> (Note that breezy is 0.8.1, dapper is 0.8.2)
<daniels> note the <<, rather than <
<jdub> << >> <
<daniels> bad man
<jdub> infinity: that's pretty sick. thanks.
<infinity> Sick as in "wrong", or "fully"?
<infinity> (Why has this country perverted me to the point where I have to ask that?)
<jdub> infinity: there are a few cultural mistakes you should dodge while you're here.
<jdub> ha ha
<jdub> DODGE
<Burgwork> jdub, for example content, I completely failed in getting those gnumeric example files. Do you want me to create some from scratch?
<jdub> Burgwork: no, don't worry about it - there'll be an e-c release schedule this week for us to work to, with some modified responsibilities and so on
<Burgwork> jdub, ok. I should still be able to work on some of the smaller things
<whiprush> jdub: going to bed, can you do the flight3 announcement for fridge?
<jdub> whiprush: yeha
<whiprush> woo!
<Lathiat> elmo: How come?
<Lathiat> elmo: (change preferred email)
<Kamion> Lathiat: it's used for figuring out where your @ubuntu.com mail should redirect to
<Lathiat> oh
<Lathiat> heh
<Kamion> obviously there's a bit of a problem there if you set it to @ubuntu.com
<Lathiat> changed
<zul> Kamion: there is a new version of grub to be synched..do you want me to test it out?
<psusi> ok damnit... these patches must be on top of some other changes since the last released kernel sources... can someone learn me how to use git to get the most current sources?  I'm used to svn
<HiddenWolf> psusi: ubuntu-kernel
<psusi> wait... think I found it bundled for download at kernel.org... how nice of them...
<zul> https://wiki.ubuntu.com/KernelGitGuide
<psusi> ahh...
<infinity> Kamion / elmo: If someone can NEW the neon binaries for me, I can get the new subversion in right away (which would be spiffy)
<infinity> Kamion / elmo: Should go to main, not universe (will be a build-dep of stuff in main)
<HiddenWolf> infinity: still needs an inclusionreport then?
<infinity> HiddenWolf: No, it's just an SONAME bump.
<HiddenWolf> ah, ok.
<infinity> HiddenWolf: But those sometimes get NEWed to universe, so I was being specific. :)
<elmo> infinity: hey, what about apache? :/
<desrt> elmo; do you know what the story with my RT request is?
<desrt> (about non-working email)
<elmo> desrt: try it
* desrt waits
<desrt> oh.  awesome.  it works now :)
<desrt> did not a few days ago.  thx.
<desrt> (plz close RT ticket)
<infinity> elmo: What about it?  You want 2.2 you mean?
<sistpoty> elmo: I've got some sync requests (6)... should I send you a mail or may I spam right here?
<elmo> sistpoty: either is fine
<sistpoty> elmo: ok... first for motu-hopeful Yann Rouillard <yann@pleiades.fr.eu.org>: dosage, gnome-backgrounds, openbox, oroborus and sailcut (ubuntu override ok, I verified these)
<sistpoty> elmo: for motu-hopeful Raphael Pinson <raphink@gmail.com>: eagle (ubuntu override ok, I verified this one as well)
<sistpoty> elmo: and for me ;): nvtv, ocamlcreal (ubuntu override ok)... thx!
<infinity> elmo: Oh, if autosync isn't in the cards for a while, an apache2 sync would be nice too (security updates).
<jdub> how do i try bz2 packages?
<crimsun> elmo: please sync nvu, osdclock, rxvt-unicode, seyon, and sp-gxmlcpp from Sid (overriding Ubuntu changes), thanks
<elmo> jdub: look at dive-into-python
<jdub> elmo: ta
<SwitchBoxz> must go today 1 alienware laptop area51-m 5700 price $500 price includes shipping, wireless router and carry case, 1 alienware desktop area51 7500 price $550 including shipping, monitor, speakers.  message me if interested on aim at mikcomputing, aim at mcsltd3@hotmail.com or yahoo at mcsltd2 only if interested and wanting to buy.  willing to put on a yahoo buy it now auction
<mjg59> SwitchBoxz: ?
<jdub> elmo: hmm, is source bz2 possible?
<tseng> jdub: no.
<jdub> bummer
<elmo> yes it is
<elmo> see glibc or gcc
<elmo> it's just not direct
<jdub> bz2 in the tarball?
<elmo> yes
<jdub> yick ;)
<elmo> *shrug* it works
<jdub> 258K -> 228K, 655K -> 489K, 156K -> 127K, 113K -> 109K
<jdub> elmo: gentoo -> humboldt for planet sometime?
<elmo> jdub: please send it to RT?
<jdub> i already did
<elmo> ticket #?
<jdub> no idea, i wasn't getting replies when i sent that one
<elmo> rt@admin.canonical.com ?
<jdub> (i no longer use sender address verification)
<elmo> jdub: those aren't great savings, considering the cost of bz2
<jdub> yeah
<jdub> flumotion-common is tempting, but not enough
<elmo> also bear in mind every time we bz2 a package, it's a permanent fork from debian
<elmo> jdub: your ticket didn't make it, pls resend?
<jdub> elmo: done
<wasabi> Oh geeze. 
<wasabi> When did notification bubbles becomes so crazy.
* Lathiat wonders why the character map is in accesibility
<Mez> jdub:ping
<jdub> Lathiat: upstream bug
<jdub> Mez: pong
<Mez> lo :D can you temporarily remoe me from planet - I'm having a few problems with my host :D have just transferred to a new one - nee to set up my website again
<jdub> Mez: no, can't edit planet as is.
<jdub> Mez: i'll comment you out from the new one.
<Mez> jdub: ok - well hopefully ... It should only take a day or two to fix things
<infinity> elmo: sync+overwrite xplc, please.
<elmo> should someone maybe send out a reminder about UVF, btw?
<elmo> infinity: done
<crimsun> elmo: done last week.
<crimsun> (err, well, for the MOTU)
<elmo> really?  go my reading comprehension skills
<infinity> Yeah, I think I missed it too.
<elmo> oh, well, how about core-dev?  they have sucky memories too ;-)
<infinity> Of course, I knew it was coming anyway..
<infinity> elmo: Speaking of you and UVF, how do you feel about the binutils snapshot in sid/dapper right now?  Happy enough with it to keep it for 5 years?
<elmo> not desperately, but there's not much I can do about it
<infinity> drow's not planning an upstream release anytime soon, I take it?
<elmo> well, actually, ubuntu could have stuck with 2.16.1 - I dunno who chose to sync with Debian
<elmo> he said before April - which of course, I realise now was the wrong question, but drow's release schedule is err, super-fluid
<infinity> I think we synced for the sake of an SCC (hppa, maybe?), but you'd have to ask doko.
<infinity> Or maybe it was sparc.  I dunno.
<infinity> Somebody was unhappy with 2.16.1
<elmo> you guys backported the patch to 2.16.1 and disabled the testsuite for those arches
<infinity> Oh, good point.
<infinity> Then I have no idea why.
<infinity> Could have just been the general ickiness of having testsuites disabled.
<elmo> to be honest, using a cvs snapshot isn't so bad, it's pretty close to what other distros use ("Linux Binutils") just modulo the hj specific crack
<elmo> I'll ping drow anyway
<mjg59> Nngh.
<mjg59> I *really* hate kernel bug reports where the backtrace makes no sense
<psusi> doesn't the setup cd have a cramfs on it or something that is mounted as the root?
<mjg59> Memory overwriting is a bastard to fix
<infinity> Yeah, I don't care one way or the other, just wanted to know if you were comfy with it, since you maintain it in Debian, and we're likely to come whining to you if we have a problem (since we know where to find you). :)
<elmo> mjg59: valgrind the kernel
* elmo <-- helpful
<psusi> mjg59, I've got a similar problem... coredump from a multithreaded app and gdb gives nonsense for the non segfaulting threads... try to gdb it and catch the segv, and the process terminates out from under gdb
<jdub> elmo: http://perkypants.org/blog/2006/01/17/kthxbye/
<jdub> elmo: thought you'd enjoy that
<whiprush> jdub: dude, about my business cards ...
<psusi> does the setup cd have a root filesystem image of some kind or does setup run entirely out of the initrd?
<elmo> jdub: haha
<elmo> infinity: yeah, bzzt, we lose, cvs love.  I'll update debian over the next day or two and recommend we sync that
<elmo> 2.17 will be close to that, so we may be able to exception it later, or not, but *shrug*
<infinity> Hrm.  Cute wanna-build bug.
<infinity> elmo: wanna-build -b ia64/build-db -i apache2
<infinity> elmo: Spot the oddity. :)
<infinity> elmo: (I'll --forget it after it's been installed to clear that, but.  Uhm.  WTF?)
<elmo> I don't get it?
<infinity> It's in state "building", but has a dep-wait.
<infinity> (It was previously in "installed", also with a dep-wait)
<elmo> I think the Depends just doesn't get cleared?
<infinity> That doesn't seem possible. :)
<elmo> it's harmless?
<infinity> it's harmless in this case, but it does normally get cleared with cron.daily.
<infinity> Just odd, that's all.
<jdub> whiprush: hrm?
<elmo> w-b odd, and now here's tom with the weather
<whiprush> jdub: I was joking ...
<jdub> whiprush: oh, i thought you were wondering about an ubuntu business card or something
<whiprush> jdub: I was attempting to poke fun at your blog entry ...
<jdub> oh
<infinity> elmo: Oh, also, in the interest of cleaning up the seeds (part of ReducingDuplication and AdamIsAnallyRetentive), can we get a newer germinate on jackass that understands the %srcpkg syntax?
<infinity> _pg.error: FATAL:  user "adconrad" does not exist
<infinity> Erm.
<infinity> -EWIN. :)
<elmo> pfft
* elmo beats infinity
<elmo> I hate it that every germinate update breaks cron.sync, I REALLY DO
<lifeless> can you write a check script ?
<infinity> elmo: Oh, while I'm being irritating, xplc was an SONAME bump as well (again, NEW to main)
<elmo> lifeless: the best test case would require the entire ubuntu archive
<elmo> or at least the indices for it
<lifeless> elmo: well, indices might be doable.
<elmo> actually in this case it might more be a case of concurrent cron jobs and my famous inability to master such complexities as, err, locking.  but _anyway_
<infinity> Cron locking is just a crutch for people who can't tell time.
<elmo> infinity: done anyway - the diff looks odd, but not enough for me to care at this time of morning
<robertj> hrmm, are flight announcements fridge material?
<elmo> robertj: if they're ubuntu-announce material, I'd say so, yes
* bddebian gives elmo a big smooch
<teroedni> is network-admin unstable in dapper?
<dooglus> what is the source-package name for dapper's new "Exit" window?
<Mithrandir> we need a tool which you can use to say "who owns this window".  A bit like xprop.
<dooglus> I tried "xwininfo" on it, but it didn't tell me anything useful
<Mithrandir> it says: WM_CLASS(STRING) = "gnome-session", "Gnome-session"
<Mithrandir> here at least.
<dooglus> yes, I noticed that Mithrandir, just before I got disconnected from my IRC machine :)
<dooglus> thanks.
<dholbach> good morning
<desrt> hello.
<pitti> Good morning
<Yagisan> pitti: morning
<desrt> hello too.
<Yagisan> pitti: do we have a rss feed for USN ?
<pitti> Yagisan: I think Seveas has
<HiddenWolf> I believe so too, but couldn't find it.
<Yagisan> pitti: HiddenWolf: thanks
<bytee_> so, is there a way to find who owns a package from Malone ?
<pitti> packages are not owned in Ubuntu
<bytee_> ah, fair enough. so if there was a bug, it should be upstreamed at Debian then ?
<pitti> bytee_: everybody has his pet packages of course, but everybody can do everything in principle
<pitti> bytee_: no, it's fine to report it to Malone
<bytee_> pitti: fair enough. i'm just after who own's the mysql package in Ubuntu
<Yagisan> pitti: /me thinks of a few packages that could have been 0wn3d in ubuntu :-P
<pitti> bytee_: if a package has a de-facto maintainer, then it will be automatically assigned to the right person
<bytee_> btw, hi pitti. long time since UDU :)
<pitti> heh, hi :)
<bytee_> pitti: i haven't found a bug, but am building up a list of MySQL contact points for distros shipping MySQL. so was wondering who'd be the best person in the Ubuntu team
<pitti> bytee_: mysql is one of the packages nobody is really attached to, but file it nevertheless, please. infinity might be interested :)
<pitti> hmm
* pitti is the postgresql dude
<bytee_> hmm, maybe i should give it some love, if required.
<pitti> bytee_: I think infinity or I wouldn't be the worst initial contacts; we can still forward it to Debian or to another Ubuntu dev
<bytee_> pitti: heh, thanks. i'll note that down.
<pitti> hey mvo
<dholbach> hey pitti, mvo
* pitti hugs dholbach 
<mvo> hello pitti, dholbach! good morning to the rest of the crew
<mdke> infinity, nudge?
<Burgundavia> pitti, I have a few reports int he forums of nautilus not showing icons on mounting. I assume that is a bug, not a policy decision?
<Seveas> Yagisan, HiddenWolf, pitti: http://ubuntulinux.nl/files/usn.xml
<doko> pitti: could you have a look at the rp, build failure?
<pitti> Burgundavia: indeed, I just replied to a similar email on u-devel
<pitti> thanks Seveas 
<pitti> doko: rp ?
<Burgundavia> pitti, ok, I will calm those on the forums
<pitti> thanks 
<pitti> odd, sounds like a gamin bug or so
<pitti> although gvfs should use inotify now
<slomo_> elmo: please sync taglib, fatsort and pygame from debian/unstable... ubuntu changes can be dropped
<desrt> interesting how gamin is still running on dapper
<Burgundavia> desrt, don't jinx it
<Burgundavia> desrt, funny that gamin works on my dapper machine but not on my (supposedly stable) FC4 box at work
<desrt> Burgundavia; afaik it has no reason to run?
<doko> pitti: rpm
<pitti> ah
<Burgundavia> desrt, inotify should do it?
<desrt> Burgundavia; gnome-vfs uses inotify now
<Burgundavia> desrt, what about local file changes?
<desrt> Burgundavia; you use gnome-vfs for local access too
<desrt> Burgundavia; and in fact inotify _only_ works for local
<Burgundavia> desrt, ah, my mistake. I don't understand how that part of the system works at all. I will just shut up now
<desrt> Burgundavia; used to be gamin lsitened to inotify and gnome-vfs registered watches with gamin
<desrt> Burgundavia; and apps registered watches with gnome-vfs which would go through gamin
<desrt> Burgundavia; now the middleman is cut out and gnome-vfs goes straight to inotify bypassing gamin
<Burgundavia> pitti, new hal coming down soon
<desrt> Burgundavia; probably, though, some weird app is using gamin directly still
<desrt> Burgundavia; released already, i think
<pitti> Burgundavia: tomorrow is UVF, I hope it'll make it in time
<dholbach> on the 19th, no?
<Burgundavia> desrt, shoudn't the build deps be change, so it makes it fairly easy to find which app?
<desrt> pitti; this needs to make it.  gnome desltop components already depend on it :)
<Burgundavia> pitti, new gpm requires it
<desrt> pitti; new nautilus-cd-burner needs it too
<dholbach> what are you talking about?
<Burgundavia> looks like g-p-m and g-screensaver are a go for 2.14
<dholbach> what is required?
<desrt> we're bullying martin into breaking UVF :)
<desrt> (non-exitant UVF... all the more fun)
<Burgundavia> desrt, not yet, that starts on the 20th
* desrt is annoyed at g-p-m
<dholbach> if you refer to gnome-vfs, that's GNOME, that has exception anyway
<desrt> dholbach; we refer to hal
<pitti> desrt: welll, in this case it will fall under the gnome desktop goal exception
<dholbach> ah ok
<desrt> i love that exception
<Burgundavia> desrt, you figure beagle for 2.16?
<desrt> Burgundavia; mono is still a touchy issue
<desrt> Burgundavia; i figure if mono made it in for 2.16 we'd have some killer awesome apps come with it
<Burgundavia> like f-spot, instead of gthumb
<desrt> and muine or banshee instead of rhythmbox
<desrt> and tomboy instead of stickynotes
<pitti> desrt, Burgundavia: oh, 0.5.6 was just released
* desrt just said that :p
<Burgundavia> desrt, I figure if mono goes in, it needs to go in a big way, to justify it
<desrt> Burgundavia; pressure is building
<pitti> desrt: oh, I didn't see that
<desrt> Burgundavia; there's no doubt in anyone's mind that it would be an asset to the platform
<stub> launchpad will be going down in just over 5 minutes for its regular update. Estimated down time is 20 mins. This will put the wiki's into read only mode.
<Burgundavia> desrt, what are you doing still up, anyway?
<desrt> stub; best of luck
<desrt> Burgundavia; i'm retarded.  my sleep pattern is totally whacked
<Burgundavia> desrt, do you work at usual hours like real people?
<desrt> i'm a student
<desrt> but this term is pretty cool... classes don't start until noon
<Burgundavia> ah, not real people like those of who actually work ;)
<Burgundavia> desrt, even if .16 does do mono, dapper+1 needs to
<desrt> Burgundavia; dapper+1's name is edgy
<Burgundavia> desrt, choosing rb vs banshee is going to suck a lot of wind out of the other
<desrt> banshee isn't mature enough for dapper..  not by a longshot
<Burgundavia> no
<desrt> but by edgy things will probably be quite a different story
<Burgundavia> I am thinking upstream here
<pitti> doko: weird, it looks as if libsepol would not provide a static library, or so
<desrt> ahh
<desrt> Burgundavia; well.. release-team likes to be ... non-controversial
<Burgundavia> desrt, yes, because they need to be neutral
<desrt> Burgundavia; so i doubt they'd drop rhythmbox unless there were uhm.. circumstances
<Burgundavia> desrt, rb is not a default module
* desrt fairly sure it's desktop?
<desrt> k.  i was dead wrong.
<Burgundavia> http://live.gnome.org/TwoPointThirteen_2fDesktop
<Burgundavia> everybody (including myself) assumed that
<desrt> cool.  looks like the decision is still open then
<Burgundavia> because every gnome distro ships it
* desrt votes muine :)
<Burgundavia> I like muine, but they need a way to burn cds, etc.
<desrt> fair.
<Burgundavia> playing a cd within muine does not break the interface, nor does burning
<desrt> hey... speaking of distros not shipping gnome-defaults
<desrt> is flash working in firefox for you?
* desrt can hear it but not see it
<Burgundavia> no idea, my dapper machine needs to be resurrected tomorrow
<desrt> works great in ephy....
* Burgundavia wishes we shipped ephy
<desrt> ya.  seriously
<desrt> it's better in absolutely every way except for the availability of plugins
<Burgundavia> the ephy people are racing hard to fix that
<Burgundavia> but the issue is sort of dead until xulrunner is in decent shape
<desrt> are they planning on running ff plugins?
<Burgundavia> no, but the big ones they are recreating
<Burgundavia> and to be honest, it will be like evolution and thunderbird
<Burgundavia> some will install firefox, and others will leave it ephy
<desrt> it will not be like that.
<desrt> epiphany is good :)
<Burgundavia> I have heard evo has gotten some serious love this time around
<desrt> who told you that and from where did they hear it?
<Burgundavia> just things I have picked up from mailing lists, etc.
<desrt> hmm
* desrt had to erase parts of it to get it to work properly
<desrt> and sometimes i have to xkill it because it randomly crashes
<Burgundavia> the current evo on my work computer is 2.2, which really sucks at forwarding anything
<Burgundavia> desrt, http://www.cbc.ca/fifth/nextpandemic/index.html <-- if you get a chance, see this
<desrt> hmm
<desrt> fictional blogs are an interesting concept
<Burgundavia> desrt, what are your thoughts on the divergent paths ubuntu and upstream are taking on the logout dialog?
<desrt> it's such a little issue
<desrt> the ubuntu one looks flashy
<Burgundavia> yes
<desrt> and it meets the requirements that we layed out in the power management BOF
<Burgundavia> but doesn't really fit in and feels unpolished
<desrt> (or at least it's a lot closer to meeting them)
<dholbach> lmanul is happy to get suggestions improving it.
<desrt> it needs to be less of a dialog and more of a 'right now i own your desktop' type thing :)
<Burgundavia> dholbach, I am stuck for actual concrete suggestions, beyond that
<dholbach> But that's the only thing that helps.
<desrt> the fact that you can move, background, windowshade, etc it.... very bad
<Burgundavia> why can the logout dialog not use the gksu greying of the screen
<Burgundavia> ?
<desrt> Burgundavia; yes.  like this.
<desrt> Burgundavia; that's exactly what i want to say
<dholbach> Ask him.
<dholbach> :)
<desrt> what's this guy's email address?
* desrt has a few suggestions
<Burgundavia> desrt, email ubuntu-desktop
<desrt> man i hate that list
<Burgundavia> desrt, why?
<desrt> every time i email it people are like "oh that's a HORRIBLE idea!"
<desrt> :)
<dholbach> That's not true. :-)
<Burgundavia> the icons need to "de-shinyified"
<Burgundavia> desrt, you going to email the list to start a thread?
<desrt> yes.
<Burgundavia> desrt, what do you call it when you set a window like gksu does? transient or intransient?
<Burgundavia> anyway, I need to crash. I will respond to that email on the logout dialog tomorrow
<desrt> thread started
* desrt includes some subtle pro-HIG propaganda :)
* desrt goes to bed too.  night.
<dholbach> night desrt
* desrt hugs dholbach and pads off
<janimo> anyone else got about the lower one fifth of the install screen unused (black?) as if it inherited 640x400 from usplash instead of 640x480...
<janimo> flight 3
<janimo> and  it again does not install on 64M RAM, debconf and frontend get alternately OOM killed in a cycle after getting over the networking setup (lack of it since I delayed it)
<janimo> will file bugs as soon as LP gets up
<lexhider> anyone tell my why launchpad is down?
<crimsun> because it's routine maintenance
<jamesh> lexhider: scheduled maintenance (rolling out new code)
<jamesh> lexhider: shouldn't be too much longer
<lexhider> cool
<janimo> jamesh, are the new features documented somewhere as they are being rolled out in LP
<janimo> or are we just supposed to be pleasantly surprised from time to time?
<jamesh> janimo: not at present.  We do have plans to put up a "what's new" page at some point though
<Mithrandir> maswan: ravel-prod
<dholbach> mjg59: new gnome-power-manager :))
<mdke> elmo, Znarl, is there a problem with adding new accounts to the docteam svn repository?
<mvo> does anyone know if there is a maximum for the amount of conffile dpkg can have in it's status file?
<Mithrandir> mvo: apt freaks out if you have too many conffiles, at least.
<mvo> Mithrandir: thanks, I got a report about a problem with ~600 of them
<Mithrandir> mvo: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174945 
<Ubugtu> Debian bug 174945: "installing package with lots of conffiles breaks apt (field larger than 32k)" Package: [tagfile]  apt, Version: 0.5.9;, Severity: <em, Maintainer: APT Development Team
<mvo> nice! thanks
<sivang> hmm, any idea why when subclassing (dict), and "initializing" it on the constructor, to = {} make any additition to it later on in the code disapper?
<Den> Mithrandir: U there?
<Mithrandir> Den: yes
<Den> Mithrandir: I tried the new cd iso, same problem as before
<Mithrandir> Den: it appears that ubuntu-desktop (and kubuntu-desktop), so the build failed. :-(
<Den> Mithrandir: it comes to the start screen, where I tell it to load the live system,
<Den> Mithrandir: it says 'loading the kernel', some stuff flashes by, it says "no record for /block/ram0" in database",
<Den> Mithrandir: then it drops me to an ash busybox shell.
<Mithrandir> Den: yeah, but as the build failed it's not very useful, since the image is identical to the last one.
<Den> Mithrandir: Your last msg to me makes no sense
<Mithrandir> Den: the build of the live image failed.
<Den> Mithrandir: "it apperas that u-d ___ so the build failed"   
<StevenK> infinity/lamont: mkfontdir SEGVs on yellow and floe (as seen in the jnethack build).
<infinity> Den: s/___/were uninstallable/
<Mithrandir> Den: yes, ubuntu-desktop needs to be installable for it to be, well, installed.  If it's not, the build fails.
<Den> Mithrandir: OK, so do oyu know why it failed?
<Mithrandir> Den: some dependencies were broken, I'm looking at why now.
<pitti> straw poll: what do you guys use for debugging? gdb plain, some vim/emacs integration, any IDE that doesn't suck?
<Mithrandir> pitti: gdb + printf.
<infinity> StevenK: Fix it? :)
<Den> Mithrandir: ok, well, I'd love to get an email from you as soon as you think it will be fixed, so I can try again :)
<Mithrandir> pitti: + valgrind.
<Mithrandir> Den: yup, will do.
<pitti> I find it pretty annoying to always switch between a source window (e. g. vim) and the gdb shell
<Den> Mithrandir: thanks.  Any idea when the fix will likely occur?
<infinity> StevenK: I'd assume we're looking for a mismatched types bug, since yellow and floe are both 64-bit machines (amd64 and ia64).  I like patches!
<Mithrandir> Den: when I understand where python-musicbrainz went.
<Den> Mithrandir: ???
<Mithrandir> Den: a package called python-musicbrainz (which ubuntu-desktop depends on) isn't in the archive any more.
<janimo> pitti, gdb/vim switching here too..
<maswan> Mithrandir: poked
<maswan> (an hour or so ago :) )
<pitti> janimo: I found a pretty nice looking vim plugin, but it requires vim to be built with some server extension, which it isn't in ubuntu
<Mithrandir> maswan: yeah, noticed.  Thanks.
<Den> Mithrandir: OK, so, does that sound lke sonething that will be fixed & a new daily live iso is up tomorrow?
<Mithrandir> Den: hopefully before tomorrow.  What time zone are you in?
<janimo> pitti, yeah I just googled for vim gdb plugin and there are some hits, never tried though
<Den> California
<Mithrandir> Den: ok, so it's middle of the night for you now, then.  It should be ready in your morning, then
<janimo> like this http://www.vim.org/scripts/script.php?script_id=1386
<Den> Mithrandir: That soon! Great!
<Den> Mithrandir: You mean about 4-6 hours from now?
<Mithrandir> Den: yes, I certainly hope so
<Den> Mithrandir: Great!
<janimo> pitti, do you need vim during a gdb session or is this for edit/build then debug cycles?
<pitti> janimo: oh, during debug I just want to view the source (and jump around in it), not actually edit it
<pitti> janimo: but vim has nice movement/jump stack features, that's why I use it for just about everything anyway
<janimo> pitti, can;t you build all with source line info in the exe?
<janimo> aha
<pitti> janimo: of course I do, and I see the current source line in gdb and all, but that's too limited (at least for *my* brain) to get a better overview about the source
<janimo> I see that's true
<Mithrandir> pitti: you can list context, you know that? :-)
<pitti> Mithrandir: I know
<pitti> Mithrandir: but still using sth. like ddd with watches and the full source is more comfortable IMHO
<pitti> Mithrandir: but ddd doesn't work over remote ssh debugging and such, that's why I try to train myself to use gdb pure
<pitti> but a nice vim plugin would really rock
<Mithrandir> pitti: ddd makes me want to poke my eyes out, at least last time I used it.
<Den> Mithrandir: BTW, when I'm at that busybox console, ash, I don't see an 'lsmod' to find out what modules are loaded.  Will modprobe -l, or -c or something else list the modules?
<infinity> Den: cat /proc/modules
<Mithrandir> Den: cat /proc/modules
<infinity> Den: Or "more", if you like pagers.
<Mithrandir> well, infinity just beat me.
<Den> infinity: & Mithrandir thanks
<infinity> Mithrandir: It's been suggested in a Debian initramfs-tools bug that I should alias "lsmod" to "more /proc/modules" in the rescue shell.  This seems to be a frequently asked question. :)
<Mithrandir> infinity: it would be a reasonable thing, I guess.  Care to fix the exit 1 if it can't resolve deps too? :-)
<tepsipakki> kamion: ping?
<infinity> Mithrandir: Do I have a bug about it?  I'm getting too swamped to remember random nags and suggestions lately.
<koke> is the live-cd installer working in flight 3?
<infinity> koke: No.
<infinity> koke: It's not included yet.
<koke> I'm going to do download one of the images for LaptopTesting
<koke> ok, thanks
<Den> Mithrandir: You'd told me before that yesterdays live iso would have the firewire in it.  Did that actually get in?  Or, did the build fail cause firewire to not get in?  I ask cause in /dev there was no cdrom listed, and based on you saying "u-desktop needs to be installed" & dependencies were broken" makes me think that maybe the firewire fix got in, and therefore I should have seen /dev/cdrom - right?
<Mithrandir> infinity: #28747, nice and fresh, assigned to you.
<pitti> Mithrandir: try 'bug 28747' :)
<Mithrandir> Den: no, I didn't get around to uploading it before yesterday (my) evening .
<pitti> hmm - Ubugtu, AYT?
<Den> Mithrandir: OK, thanks for the info.
<pitti> bug 28747
<Ubugtu> Malone bug 28747: "tools (Ubuntu): should not exit 1.  Ever" Fix req. for: initramfs-tools (Ubuntu), Severity: Wishlist, Assigned to: Adam Conrad, Status: Unconfirmed http://launchpad.net/bugs/28747
<pitti> Seveas: ah, so ubugtu ignores stuff in quotes?
<Den> Mithrandir: Um, if you uploaded it your yesterday evening, it should have been in the iso I dl'd a couple hours ago, right?
<Seveas> pitti, the only characters allowed behind the number are a comma and a space (or no character at all), otherise it would match too much :)
<StevenK> infinity: Surely mkfontdir SEGVing is daniels' problem? :-)
<Den> Mithrandir: Maybe you call that "today's" iso, not "yesterdays"?
<StevenK> infinity: Sorry, I was away doing the dishes.
<infinity> StevenK: If that's the daniels who is a) on a bit of a vacation and b) not actually working for Canonical anymore, I agree.
<siretart> let's hope I didn't make the situation not even worse.. 
<StevenK> Eeek.
<Mithrandir> Den: no, it wouldn't because the build (of the live image) failed.
* StevenK makes use of pergolesi.
<Den> Mithrandir: gotcha, thanks!
<StevenK> infinity: When did that happen?
<infinity> StevenK: Well, he's not moved on just yet, but he does in early Feb.
<StevenK> Crap. mkfontdir works on pergolesi.
<infinity> StevenK: Basically, when he's done vacationing. :)
* StevenK wonders how to get a strace of mkfontdir off yellow.
<infinity> StevenK: Well, sure.  pergolesi's running Debian...
<Mithrandir> StevenK: ask infinity nicely? :-)
<infinity> StevenK: Bug me again tomorrow morning, and I'll hunt it all down for you with straces and backtraces and such.
<infinity> StevenK: And if it leaps out at me, I'll even fix it too, otherwise I'll give it to you, since I have a full plate.
<StevenK> Before or after the TB meeting? :-)
<infinity> StevenK: I won't be at the TB meeting, so.  Uh.  "whenever".  I start work at 10ish, local, usually.
* StevenK nods.
* mdke nudges infinity a bit harder, in desperation
<hunger_> What about transitional debs (hoary->breezy)? Will they get removed in dapper? Is it OK to depend on them for dapper-debs or should I file a bug when I notice something like that?
<infinity> mdke: I hear you, honest. :/
<infinity> hunger_: Depending on a transition package (if it's clearly such) is a bug, yes.
<hunger_> infinity: I.e. xlibs claims to be transitional, but todays gnome-control-center depends on it. So that is a bug?
<hunger_> Why are those debs still around to depend on in the first place?
<infinity> hunger_: Erm, yeah.  Anything depending on xlibs is very much a bug.
* hunger_ is off to report that then.
<infinity> hunger_: They're around to easy partial upgrades.
<hunger_> infinity:  ?
<hunger_> infinity: You support upgrade from one version to the next only...
<hunger_> infinity: So transitional debs for hoary->breezy can get removed after breezy is out, can't they?
<hunger_> apt-cache search transition lists 127 packages...
<infinity> hunger_: As a courtesy, we also try (though don't promise) to allow sidegrades from the current debian stable to our current release.  Ish.
<infinity> hunger_: That said, xlibs was split in sarge as well, so it really should not be depended on.
<hunger_> infinity: Oh! hadn't noticed that yet:-)
<Tm_T> ;)
<lite> hm
<lite> I'd like to report ubuntu bugs (breezy/dapper)
<Simira> then you use Malone in launchpad.ubuntu.com
<dholbach> lite: http://launchpad.net/malone
<lite> where to do it or can I do it here?
<lite> ok
<pitti> Kamion: do you know the difference between pcmcia-cs and pcmciautils? do we need both? /etc/init.d/pcmcia vomits in current default install ("linux >= 2.6.13 requires pcmciautils instead of pcmcia-cs")
<lite> oh
<lite> my bug is already reported :)
<lite> (partially)
<dholbach> lite: It's nice of you, you checked beforehand.
<Tm_T> lite is good kid ;)
<Tm_T> use him wise
<lite> hm. perhaps I cannot use the search very well, or it doesn't work :o
<pitti> Kamion: btw, the proxy dialog still appears for netless installs
<pitti> doko: I'll fix the rpm ftbfs now
<doko> pitti: thanks, selinux related?
<pitti> doko: probably, yes, but it failed much earlier on my machine because libneon24 doesn't exist any more
<pitti> (so I build against 25 now)
<doko> yes, that was a recent change as well
<Diziet> What does the `Uploaders' field do in source packages in Ubuntu, if anything ?
<pitti> elmo, Kamion: can you please NEW sudo so that we can test the changes asap? TIA
<\sh> Diziet: the original meaning was "co-maintainer", but for ubuntu we don't use maintainer or uploader as far as I know...correct me when I'm wrong
<ogra> Diziet, its only inherited from debian, we do use it (i hope)#
<dholbach> ogra: use it? how?
<ogra> s/do/dont
<ogra> typo, sorry
* dholbach thought so.
<infinity> pitti: Oh, yeah.  I was about to rebuild all of neon's rdeps.  If you've got rpm covered, cool.
<pitti> well, as soon as I find out about that sepol linking FTBFS
<Diziet> Right, good, that was what I hoped the answer was.
<Diziet> Thanks.
<pitti> oh, yay, seems to work
* pitti really hates packages that call autoreconf and configure at clean
<infinity> pitti: Even if not unpatching?
<pitti> infinity: dpkg-source -x, debuild -S, nothing else
<infinity> Ick.
<pitti> infinity: it's integrated into the clean rule
<pitti> instead of build
<pitti> which makes reading debdiffs a nightmare
<infinity> Well, if configure.in are patched, it does need to be in clean, but only iff unpatching.
<infinity> (PHP used to do this unconditionally too, when someone (vorlon, dilinger?) added the patch system, I fixed it to only do it when it had to do an unpatch first)
<infinity> Still ugly, and I should probably move to a tarball-in-tarball scheme, so clean can just be "rm -rf build-tree", but I'm lazy.
<infinity> Well, and unconvinced that the current state of things is a real problem.
<pitti> doko: rpm fixed
<Kamion> tepsipakki: yes?
<Kamion> pitti: we still need pcmcia-cs because not all the stuff it contains has been moved somewhere where pcmciautils can get at it yet
<Kamion> chiefly CIS firmware for weirdo cards
<pitti> Kamion: ok, so shall I just drop the check from /etc/init.d/pcmcia?
<Kamion> pitti: NOOOO
<pitti> Kamion: it aborts on our kernels
<Kamion> leave it alone, it's harmless
<pitti> well, it broke the installation of linux-wlan-ng
<Kamion> it's meant to fail
<Kamion> ?
<pitti> I now added an || true to cover that
<mjg59> Kamion: It's not harmless when it exits 1, surely?
<pitti> at least it should exit with 0 then
<Kamion> mjg59: I didn't think anyone would be silly enough to call it from a maintainer script
<pitti> Kamion: linux-wlan-ng is
<pitti> Kamion: it adds a new script and wants to reload it
<Kamion> stupid thing
<mjg59> Kamion: Isn't it going to result in failure messages on boot?
<pitti> Kamion: nevermind, the latest version should fix it
<Kamion> I'll make it exit zero, but note that linux-wlan-ng probably doesn't work if it's relying on that sort of thing
<Kamion> mjg59: no, see the code
<pitti> Kamion: btw, I'll talk with scott about fixing that 'network failure after unclean reboot' bug, but I'd like to know whether moving checkroot around interferes with his init modifications
<Kamion> mjg59: during the boot process, it suppresses the message and exits zero
<mjg59> Kamion: wlan-ng's package installs files that override pcmcia-cs (pcmcia_cs->prism2_cs), so it restarts it
<Kamion> mjg59: well that won't work with pcmciautils ...
<mjg59> It won't work in Ubuntu anyway, because we don't ship that module
<p9goBou_LLlyTHuK>  
-p9goBou_LLlyTHuK:#ubuntu-devel- 
-p9goBou_LLlyTHuK:#ubuntu-devel- 
-p9goBou_LLlyTHuK:#ubuntu-devel- 
-p9goBou_LLlyTHuK:#ubuntu-devel- vi huli spite
-p9goBou_LLlyTHuK:#ubuntu-devel- boti
<tepsipakki> kamion: I'm about to make a patch for apt-setup to support a local repository.. it will of course touch some other places as choose-mirror et al. should I post it directly to debian-boot or make a bug on malone?
<pitti> can an op please deal with this?
<p9goBou_LLlyTHuK> che
<p9goBou_LLlyTHuK> ?
<p9goBou_LLlyTHuK> do u spik russian?
<p9goBou_LLlyTHuK> Oo
<p9goBou_LLlyTHuK> russians r cool
<p9goBou_LLlyTHuK> :D
<p9goBou_LLlyTHuK> USSR forever B)
<ogra> mjg59, do we want g-p-m 0.3.4 ? 
<p9goBou_LLlyTHuK> yuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu
<p9goBou_LLlyTHuK> noobz
<Tm_T> ogra: nice waether, isn't it
<Tm_T> weather even
* mode/#ubuntu-devel [+o jdub]  by ChanServ
* mode/#ubuntu-devel [+b *!*n=iNfErNo@80.81.208.*]  by jdub
* p9goBou_LLlyTHuK was kicked off #ubuntu-devel by jdub (jdub)
<ogra> Tm_T, nah, some kind of snowy rain is falling outside, its wet and cold here
* mode/#ubuntu-devel [-o jdub]  by jdub
<chmj> ^5 jdub 
<pitti> ogra: btw, hal | 0.5.6-0ubuntu1 | http://archive.ubuntu.com dapper/main Packages :)
<ogra> pitti, yes, i checked before asking ;)
<pitti> ogra: but NB that it still doesn't run as root; sjoerd is working on a solution, though
<mjg59> ogra: Yes
<ogra> pitti, evil you ... :)
<Tm_T> ogra: heh, -25'C and brrright and windy, just good
<ogra> mjg59, okis
<infinity> pitti: Dude.  Why didn't you just fix libselinux1-dev to depend on libsepol1-dev instead of libsepol1?  Clearly, it's at fault.
<pitti> hm, true
* pitti does
<infinity> Don't forget to "unfix" rpm afterward. :)
<pitti> infinity: oh, the debian/rules change is still necessary
<infinity> (You can do both uploads together, if you don't want to wait, I can give-back RPM to get it to build after selinux is fixed)
<lite> any kernel gurus? I'm having a problem with agp driver.
<pitti> infinity: is the redundant b-dep so important that it justifies another uplaod?
<infinity> pitti: No, not really.  And if you have to explicitely -lsepol (do you really?), then you are justified in making the build-dep explicit.
<infinity> pitti: Oh, wait.  lsb-rpm is static, isn't it?
* infinity wants to vomit right about here.
<pitti> infinity: yes, I have; lsb-rpm is manually linked together in debian/rules
<Kamion> tepsipakki: debian-boot please, I'd like to keep apt-setup as unforked as possible
<pitti> infinity: yes, it's totally crazy and needs the .a file
<Kamion> tepsipakki: I don't see why it should need to touch choose-mirror
<tepsipakki> kamion: ok
<pitti> infinity: so the b-dep is not that wrong IMHO
<tepsipakki> kamion: templates..
<infinity> pitti: Either way, libselinux1-dev's deps are wrong, since it clearly needs the other.
<Kinnison> lite: This isn't a support channel really, I suggest you find a kernel channel to ask on
<pitti> infinity: sure, I just uploaded a fixed version
<Kamion> tepsipakki: I was coincidentally just thinking about this a moment ago; surely preseeding a string containing custom sources.list lines would be good enough
<Kamion> tepsipakki: templates> huh?
<tepsipakki> kamion: it would yes
<lite> Kinnison, yep, sorry.
<infinity> pitti: Yeah, the build-dep isn't wrong if you link it manually (it's a nice reminder that one leads to the other), but eww.  :)
<Kamion> tepsipakki: ok, no reason for that to need to touch choose-mirror's templates then
<Diziet> WTF!  patch says hunks 1,2 and 7 succeeded, 4,5,6 failed, and 3 out of 7 failed.  What about hunk 3 ???
<tepsipakki> kamion: that's what I thought of at first
<Kamion> tepsipakki: just need an apt-setup generator that looks at your preseeded question then
<Kinnison> lite: sorry :-)
<Kamion> they're pretty straightforward to write
<tepsipakki> kamion: yes, that's what I've done
<Kamion> ok, sounds good
<Diziet> Ah, it doesn't list them if the offset is 0.
<infinity> Diziet: Hunk 3 is a figment of your imagination.
<Diziet> If I'm going to be imagining hunks they won't be of patches.
<infinity> <rimshot>
<tseng> he really set himself up on that one
<pitti> ogra: did you happen to fiddle with dhcp3-client? my dhclient.conf just contains a 'NetcfgDHCLient' line with an invalid syntax
<pitti> ogra: (clean flight-3 install)
<pitti> ogra: and i have a .dpkg-orig that looks fine
<ogra> pitti, not particulary with the client, but i can fix it, yes :)
<Kamion> pitti: that's netcfg, what's wrong with the syntax?
<pitti> ogra: any idea which package modifies that?
<pitti> Kamion: at least there shuold be a semicolon
<Kamion> it is a netcfg bug though; that shouldn't be copied to the installed system
<pitti> hm, there is
* Kamion aims a rock at Geert
<Kamion> I'll see if I can fix that
<pitti> ok, so the intention is to not change the conffile? ok
<ogra> /etc/dhcp3/dhclient.conf line 1: no option named dhcp-class-identifier
<ogra> send dhcp-class-identifier "NetcfgDHClient"
<ogra>      ^
<ogra> /etc/dhcp3/dhclient.conf line 1: semicolon expected.
<ivoks> ogra: ah, that happens all the time :)
<Kamion> yeah, the problem there is that the installer uses a different version of dhclient to the installed system for size reasons, and the name of that option changed between dhcp 2 and 3
<ogra> ivoks, add an semicolon or remove the line 
<Kamion> yet another reason it shouldn't be copied
<Kamion> just remove the line, future versions of the installer won't put it there
<ivoks> ogra: semicolon :)
<Kamion> and it's wrong to have it on your system
<ogra> ivoks, rather what Kamion said ;)
<ivoks> ogra: my point was that 'semicolon' mistake is very often in dhcpd/dhclient
<ogra> ivoks, did you file bugs about them ? 
<ivoks> ogra: ok, /me had just 4 hours of sleep, so maybe doesn't talk so clear and people around me don't understand me :)
<infinity> pitti: Yay.  I though I owned all the paper bags in Ubuntu.
<pitti> *cough*
<ogra> lol
<pitti> 'let's just fix this quickly'
<ogra> hrm .... latest xscreensaver is evil to me ...
<infinity> pitti: Don't look too closely at the archives for dapper-changes.  You'll see a LOT of "3 uploads of the same package in one dinstall run" from me.
<infinity> pitti: Last week was a bad brain week. ;)
* pitti thinks we need a new lintian check 'E: foopackage: brainfuck in debian/control'
<ivoks> pitti: that's AI :)
<ogra> jdub, tango looks pretty complete already, why not switch to it for dapper ? 
<jdub> ogra: might be doing so
<ogra> cool
<slomo_> ogra: look at evolution for a reason not to switch ;) the toolbar buttons are partially old-gnome style, partially tango style
<ogra> slomo_, for me there are 2 icons from the old style 
<ogra> thats easy to fix
<ogra> its just that we are 2 days before UVF so a decision should happen soon ;)
<slomo_> ogra: i count 7 in the toolbar, and all in the dropdown menu which opens when you click on new
<ogra> slomo_, in my pulldown there are 2 or three old ones, but i couldnt even decide which ones come from hicolor and which come from tango ...
<slomo_> ogra: weird... which tango version?
<ogra> recent
<slomo_> 0.6.5?
<ogra> 0.6.5-0ubuntu1
<dholbach> Diziet: Hello. I just found that gnome-panel has a 'static' libnspr4 Depends, because the shlibs of firefox seemed to be broken. Can you confirm that fixed?
<Diziet> Err, no, I can't confirm it fixed.  Err, do you mean the shlibs of the old libnspr-dev were broken or of the firefox-made one ?
<dholbach> Diziet: The firefox-made one.
<pitti> sjoerd: I'm currently packaging gnome-mount for universe (it doesn't do anything interesting yet, so we won't ship it for now); shall I upload it to Debian experimental, too?
<Diziet> Do you know what was wrong with it ?  I wasn't aware of a problem but it's quite plausible.
<dholbach> Diziet: I suppose the shlibs didn't get "picked up" automatically.
<ogra> Diziet, i also noted that in my ppc testinstall yesterday the firefox homapage was mozilla.org ... intrestingly that didnt happen in i386 or amd64 installs
<dholbach> Diziet: Oh well, I have to build it anyway, I'll just try and report back.
<sjoerd> pitti: it's patched to call pmount or ?
<Diziet> OK.  I'm in the middle of a moderate-sized merge.  Debian have changed their package name, which is nice in the long run but means quite a bit of untangling now.
<pitti> sjoerd: I will do so, yes
<pitti> sjoerd: at least for dapper the priv separation code in hal is too late for my taste
<jdub> Znarl: YAY!
<jdub> HOORAY FOR NEW PLANET!
<jdub> http://planet.ubuntu.com/
<jdub> HOORAY!
<sjoerd> pitti: dunno when dapper is scheduled ? two months ?
<pitti> sjoerd: uvf is tomorrow, feature freeze in one or two weeks
<pitti> sjoerd: release is end of April, or so
<Kamion> sjoerd: http://wiki.ubuntu.com/DapperReleaseSchedule
<dholbach> And it has Colin Watson!
<jdub> 1000% less suckage!
<Treenaks> jdub: is it planet 1.0-patch9?
<dholbach> and Zak B. Elep
<jdub> Treenaks: yes
<Treenaks> jdub: and did you see feedparser-4.0 has been released? :)
<jdub> Treenaks: 4.1 even :-) there are some minor incompatibilities i need to sort out (looked at it the other day)
<Treenaks> jdub: great :)
<crimsun> and feedparser actually builds! yay for missing b-ds.
<jdub> whoa, it's packaged?
<jdub> oh, no, the ruby one
<crimsun> ah.
<jdub> none of that crap in planet!
<jdub> ;-)
<dexem> dapper loads ndiswrapper and bcm43xx for my bcm4318 wifi card... the problem is that both drivers loaded, conflicts. It's intended to change the default to bcm43xx? or... does it work correctly?
<Treenaks> dexem: in a lot of cases, it appears to work, yes
<dexem> Treenaks: well, I have a Dell, but it seems to have that wifi card... and, maybe it's my fault, but bcm43xx doesn't work correctly
<sjoerd> pitti: i ran into some small problems with the patch yesterday, but it should be finished in a few hours now
<sjoerd> pitti: do you know how dapper will do the pwrmgmt callouts ?
<pitti> sjoerd: with your patch, I suppose/hope :)
* infinity bangs his head on his desk.  "Never.. Delete.. Your working directory.. Until after you get an ACCEPT from katie."
<sjoerd> pitti: :)
<sjoerd> pitti: well then the discussion start what policy we should have for the power callouts and stuff, but gettng the patch finished is the first step :)
<pitti> sjoerd: we want to allow it for users which have an associated X session
<pitti> sjoerd: mjg59 wrote a pam module for this (libpam-foreground)
<sjoerd> is that already available ?
<sjoerd> i knew he was working on it, but that was all.
<Nafallo> infinity: been there, done that :-/.
<pitti> sjoerd: it's not as generic as pam_console, but it avoids pam_console's weirdness
<sjoerd> :)
<pitti> sjoerd: it's in universe, and it still has a couple of bugs
<sjoerd> k
<pitti> sjoerd: that's why I didn't accept it for promotion yet
<pitti> mjg59: btw, what's the status of this? will you upload a new version soon so that we can test this in main and use it?
<sjoerd> would be great to have that in debian too 
<sjoerd> pitti: for debian i was thinking of either you belong to some group or are behind the machine
<sjoerd> but we can't express ``behind the machine'' yet (pam-foreground could solve that)
<sjoerd> and for a goup i guess we should discuss with the http://powermgmt.alioth.debian.org/ guys
<pitti> sjoerd: yes, we don't have a special group for that yet either
<sivang> Kinnison: you're not using autoconf for Lua as it seems, right?
<Mithrandir> doko: any chance you could get ooo2 to be installable again?
<Kinnison> sivang: No, Lua is not autoconfed
<Kinnison> sivang: for portability reasons
<doko> Mithrandir: what is uninstallable?
<sivang> Kinnison: very cool
<Kinnison> sivang: but if you're playing with libgfshare then yes, it is autoconfed
<pitti> heh, wasn't portability the primary idea of autoconf?
<sivang> pitti: I was going to ask that exactly! :-D
<Mithrandir> doko: ooo2-*.  Or has it been renamed to ooo now?
<jk_work> it's portable among unices,
<jk_work> so in addition to the 5-10% of machines which run Linux,
<jk_work> it gains you an additional .5 - 1&
<jk_work> it gains you an additional .5 - 1%
<doko> Mithrandir: no, not yet
<ogra> hmm, didnt we want to keep xchat in main ? 
<doko> Mithrandir: and AFAIK the amd64 experimental packages need a fixed firefox-dev
<doko> Diziet: ^^^
<seb128> desrt: just curious, who asked you to comment on the dialog? :)
<Mithrandir> doko: ooo2-amd64 is installable just fine.
* pitti shakes his head on gnome-mount - it needs to tell hal which user id the drive needs to be mounted for???
<ogra> pitti, sure, and you are not allowed to use the drive unless *you own all the files on it* ;P
<pitti> sjoerd, seb128: hmm, if I patch gnome-mount to use pmount, then nothing from the original code will be left
<Mithrandir> doko: ooo2-evolution and ooo2-gnome seems to be gone, at least?
* sjoerd rotfl
<pitti> sjoerd, seb128: at this point there is just *nothing* in gnome-mount in addition to calling hal's mount/unmount/eject methods, which we won't use, soo
<Mithrandir> doko: and ooo2-core needs a rebuild for new libneon
<sjoerd> pitti: doesn't it have a fancy ui yet ?
<seb128> pitti: don't bother so
<pitti> sjoerd: well, g-m-properties is a trivial dialog with some labels 'drive_name_goes_here' and a 'close' buttonn
<pitti> seb128: ack, it would be easier to read gconf stuff from pmount-hal, or add a pmount-gconf or whatever
<pitti> s/from/in/
<sjoerd> right, leave it for now
<Mithrandir> pitti: did you start the libneon rdeps rebuild or did somebody else do that?
<infinity> Mithrandir: Oh neat, I skimmed right over Ooo2 in my rdeps listing for neon.
<infinity> Mithrandir: So much for "hey, I can rebuild it all in 5 minutes"
<pitti> Mithrandir: I didn't, I only changed rpm because I fixed the FTBFS anyway
<Mithrandir> pitti: ok, it seems like infinity has confessed. :-P
<Mithrandir> infinity: care to rebuild it?
<pitti> I can help you with that, if you want
<Mithrandir> pitti: making infinity confess?  Yeah, I'm sure you can. ;-P
* pitti hides the whip
<pitti> infinity, Mithrandir: I take bazaar and tla, fine for you?
<Mithrandir> pitti: please do.
<Mithrandir> pitti: I just want -desktop to be installable, really.
<infinity> pitti: Go nuts.
<infinity> pitti: I needed the new neon for the new SVN upstream.
<pitti> yep, I wanted to leave svn to you :)
<Mithrandir> I wonder where ooo2-{evolution,gnome} is, though.
<Kamion> pitti: netcfg bogosity fixed
<pitti> yay, thanks
<infinity> Mithrandir: It's too late for me to fix Ooo2 right now.  I really need to catch some Zs.  If you want to push a rebuild, go nuts.  If it fails, we'll have to deal with it in the morning.
<Mithrandir> infinity: go to bed, then.
<Mithrandir> infinity: I might poke it, or get doko to do so
<doko_> Mithrandir: starting a OOo test build
<infinity> Mithrandir: If it's just the neon thing that broke it, a pure rebuild (with fixed build-deps) should make it happy...
<infinity> doko_: Any chance of a db4.3 bump while you're doing the neon bump, or is the db bump more problematic?
<Mithrandir> doko_: thanks.
<Mithrandir> infinity: I think it is.
<infinity> doko_: (If you need specific fixed to db4.3, let me know)
* infinity heads out.
<doko_> infinity: yes, it's problematic ... still on my todo
<doko_> Kamion: about 25509, does usplash has support now for appending to a line?
<Kamion> doko_: I wasn't aware that that was blocking it
<Kamion> please add that information to the bug
<Kamion> I reassigned to lsb because that's what's responsible for the implementation of log_progress_msg
<zul> Kamion: ping
* pitti grumbles at bazaar
<lucas> hi
<lucas> to help solve the communication problems towards Debian, I worked on https://wiki.ubuntu.com/UbuntuDemystification
<mdke> nice work jdub
<lucas> it was already reviewed by some MOTUs. do you have some comments ?
<mvo> lucas: """ Ubuntu's way of ''contributing to Debian'' really sucks.": """ <- might be a bit strong worded. for many packages in main we have a very good working relation ship with the debian people or are ourself heavlily involved in the upstream development
<lucas> ok, can you suggest something ?
<lucas> I'm basically trying to match the debian's opinion
<ogra> lucas, why ? 
<lucas> ogra: I mean in the titles
<ogra> lucas, we are ubuntu... match the ubuntu opinion ;)
<lucas> the goal is to be read by DDs here
<mvo> lucas: right, I'm not very good at this (no native speaker), but I would like to have something more positive in here because (unlike some ppl like to believe) we do contribute a lot back
<jdub> lucas: not sure that requires bad messaging in the titles, though
<lucas> ok
<lucas> """Ubuntu's way of ''contributing to Debian'' is insufficient for me""" ?
<lucas> (not a native neither)
<mvo> lucas: so, something along the lines "while we do contribute a lot and have a good working relation with many debian developers, we try hard to get better " (in the body maybe)
<jdub> lucas: "How does Ubuntu work with Debian?"
<lucas> that's too general I think. this paragraph is really about giving back
<lucas> "How much does Ubuntu give back to Debian ?"
<lucas> ?
<Treenaks> lucas:  ...,..
<Treenaks> ?
<lucas> ok, and what about "How does Ubuntu give back to Debian ?" then ?
<ogra> lucas, i vote for jdub's sentence ...
<pappan> https://launchpad.net/projects/fatalnetwork click http://www.fatalnetwork.com shown in square brackets...lol
<lucas> "How does Ubuntu work with Debian?" could apply to a lot more things than just "giving back to Debian". For example,  the paragraph before this one could fit under this title as well
<pitti> wow, that's the first of my patches that was accepted by cups upstream
<ogra> pitti, what was it ? a string change ? 
<pitti> ogra: heh, no, I fixed authentication for non-printer admins
<pitti> ogra: i. e. before the current ubuntu version any user could kill print jobs of other users
<ogra> ah, yes ... cool :)
<tepsipakki> pitti: ah, the convenience ;)
<pappan> pitti: that seems a sec hole ??
<ogra> gah, my foot is getting blisters froim kicking xscreensaver ... evil thing 
<pitti> pappan: well, more of an inconvenience
<pitti> ogra: btw, can I kick g-screensaver once, too? it still locks the screen after the screen saver timeout. *pretty please make it not to*
<ogra> pitti, dholbach told me twice he had changed that setting 
<ogra> i'll look into it
<ogra> note that the default wont override user changes once you changed the key
<dholbach> Yes, I changed the default.
<ogra> pitti, dholbach told me three times he had changed that setting 
<ogra> ;)
<pitti> dholbach: in g-s-preferences, 'lock screen when screensaver is active' is enabled and greyed out
<ogra> must be our user setting :)
<sladen> lucas: ''Ubuntu is constantly dependant on Debian.  One of the ways Ubuntu supports this is by employing Debian Developers, as of January 2006, Canonical employs 20 DD's (more than any other organisation) ensuring that changes go directly back to Debian. ...''
<ogra> sladen++
<ogra> +++
<ogra> +
<lucas> sladen: we all know it is supposed to be the case, but regarding universe, it is far from being the case
<lucas> if it was, the threads on debian-devel would be much shorter
<sladen> lucas: actually doing it is harder than rolling out the bullshit-o-meter, but saying it is a good start;  I like the example of various DD's joining MOTU.  Are there any people apart from Daf who've finished NM /because/ of Ubuntu?
<sladen> lucas: or focus of any MOTU people that have been pursuaded to start NM in an attempt to get patching flowing back even faster
<lucas> ok, I'll try to add something about people being both active inside debian and ubuntu
<lucas> not specifically targetting canonical employees or the MOTU/NM case
<ogra> sbalneav, scottie !!
<sbalneav> Hey there ogra!
<ogra> sbalneav, we have UVF in two days, any changes in ltspfs/ltspfsd that i should package before ? 
<sbalneav> oh, yeah, just made some bug fixes the other day.  Let me commit my changes.
<ogra> even if we dont support local devices by default it would be neat to have the pieces you need in shape ...
<ogra> cool, i'll package it tonight then ...
<sbalneav> Did localdev fall by the wayside for this time?
<ogra> yup
<ogra> we want it specced a bit better and implement it in dapper+1 
<sbalneav> Thats cool.  It's a complicated topic, and needs lots of thought.
<ogra> yup
<sbalneav> It'll be better for dapper+1
<ogra> i think we'll have some more different impelmentations by dapper+1 to look at and pick the best from them ...
<sbalneav> excellent.
<ogra> seeing drawbacks and problems others had
<janimo> Kamion, is it possible the install CD integrity check comes out ok but there are still errors during install?
<janimo> I got udev/ubuntu-minimal/initramfs related errors about 75 % in the base install
<janimo> by integrity check I mean what's in the boot menu
<sbalneav> ogra: ok, changes committed.  I've never done much with the actual debian/rules stuff, but I'm keen to learn.  When you package it, let me know, and I'll add the debian/* stuff into cvs.  I'd like to see it in etch as well. (Hope that's not an unmentionable word around here :) )
<ogra> sbalneav, rather keep the source and the packaging distinct ...
<sbalneav> ok, np.
<ogra> (indeed you *can* add the debain dir, but its not appreciated by debian)
<sbalneav> ah, ok.
<lucas> sladen: can you re-review UbuntuDemystification ?
<Kamion> janimo: bugs are always possible
<doko> Mithrandir: OOo2 FTBFS due to the new neon :-/
<Kamion> janimo: and yes, it's also possible that your CD or the drive is on the edge of readability so that it sometimes succeeds and sometimes fails
<Mithrandir> doko: ugh. :-(
<doko> /home/doko/ooo/2.0/openoffice.org2-2.0.1/ooo-build/build/ooa680-m1/ucb/source/ucp/webdav/NeonSession.hxx:269: error: 'ne_header_handler' has not been declared
<doko> dmake:  Error code 1, while making '../../../unxlngi6.pro/slo/DAVSessionFactory.obj'
<Mithrandir> doko: any chance you could spend time fixing it?
<doko> not today, maybe it's better to re-upload the neon source as neon24.
<Mithrandir> either way works for me, but I'd like to see -desktop being installable
<martink> Mithrandir, doko: there's an upstream bug for this (with the last comment: go fix it yourself)
<doko> martink: yeah, waiting is always a way ;)
<janimo> Kamion is .deb integrity checking expensive? Would it be hard to fall back on downloading a package just as it;s done with updates if a .deb turns out to be corrupt on the CD?
<Kamion> janimo: yes
<Kamion> the installer doesn't do any of this stuff by hand, it just calls apt
<Kamion> any clever fallback algorithms would have to be implemented in apt
<mvo> janimo, Kamion: I think this might actually work already if apt has a fallback source in it's sources.list
<Kamion> it does for the main bulk of the installation, but not for the base system
<Kamion> hard to change that at the moment since apt-setup currently requires the base system to be installed in order to work
<mvo> Kamion: so the problem is that there is no fallback source in sources.list?
<Kamion> right ...
<zul> Kamion jbailey: there is a new grub to be merged..
<Kamion> zul: I was going to get to all my merges this week. Are the changes at all complicated?
<Kamion> janimo: er, vga16fb is *supposed* to be 640x400 now
<janimo> Kamion, so it does not stretch on laptops with other resolutions?
<zul> no..i did a merge and was running it for a couple of days before i re-intalled my laptop
<janimo> the problem is there's a black band at the bottom
<janimo> 1/5 of the csreen
<janimo> on another laptop it's ok
<mjg59> janimo: What kernel are you running?
<janimo> flight 3 install problem
<mjg59> Right
<janimo> native res is 800x600
<mjg59> A black band is preferable to part of it vanishing off the bottom of the screen on other machines
<janimo> the console message is setting up vga16fb 80x25
<mjg59> Yes, that should be correct
<Kamion> janimo: deliberate, use the gfxboot menu if you want something different
<janimo> so there's a set of resolutions which will have the black band?
<mjg59> janimo: No...
<janimo> ah, ok then
<Kamion> as mjg59 said, 640x480 just broke on many other systems
<mjg59> Some machines may not scale 640x400 to full screen (since it's not a 4:3 resolution)
<janimo> this is no longer usplash, the installer used to work just fine on this laptop
<janimo> mjg59, so this is d-i not usplash
<mjg59> janimo: Yes. They use the same framebuffer
<janimo> ok then
<janimo> so the res is hardcoded in the kernel I remember now
<janimo> and vesa I guess is breaks even more machines
<mjg59> vesa tends to break suspend/resume
<mjg59> It's possible that it doesn't on dapper now, but...
<janimo> bios problems not vesafb?
<mjg59> No, the assumption that the video hardware works immediately on resume
<BenC> Kamion, Keybuk: I found the cause of the oopses in unionfs
<BenC> will be fixed in -13.18 (wish it was in for flight3)
<mgalvin> Kamoin: when I tried to install flight 3 with xfs it tried to use lilo and the install failed, is this know or shall I just open a bug (other fs's work fine)
<mgalvin> s/know/known/
<Kamion> BenC: hooray, thanks
<Kamion> mgalvin: er, maybe ... sure, open a bug, I can always dup it
<mgalvin> k, thnx
<BenC> Kamion: I didn't really "fix" anything, but the oopses were coming from the debug code, so I just disabled debug
<BenC> probably run a lot faster with that turned off anyway
<rod> im trying out xchat-gnome for the first time now
<rod> after this sentence i click this window away; could you say my name in here so ill see if i get notificated? THanks
<pitti> rod: ping
<rod> thanks pitti :)
<Kamion> BenC: !
<Kamion> BenC: I was seeing real breakage as well as the oopses ...
<Kamion> unless that was actually *caused* by the oopses, I guess
<BenC> probably collateral damage
<Kamion> ok
<Kamion> let's hope so ...
<BenC> anyone know if there is a iTunes share client for linux?
<tseng> BenC: rhythmbox supports it badly
<tseng> BenC: banshee cvs is pretty decent
<SEJeff> BenC, Try banshee
<BenC> ok, thanks
<ogra> and iTunes is natively supported by crossover
<SEJeff> BenC, you are talking about DAPP support, right?
<slomo_> BenC: you'll get a banshee supporting it tomorrow probably ;)
<tseng> build from cvs and enable the MusicSharing plugin
<tseng> ogra: eww?
<BenC> slomo_: from apt-get?
<ogra> tseng, did they drop it ?
<tseng> ogra: i said eww
<slomo_> BenC: yes... if you're too lazy to build from cvs :)
<tseng> ogra: emulation is pretty lame when you have a native gnome app
<BenC> slomo_: well, if there's a source package I can download now that would be better :)
<slomo_> our rhythmbox doesn't support it currently afaik because the daap support doesn't work properly with gst 0.10
<BenC> build the .deb locally
<ogra> tseng, sure, just wanted to point out all options ...
<slomo_> BenC: i haven't done one for cvs ;P i wanted to wait for the release this night
<ogra> i didnt mean i support it :)
<tseng> ok :)
<BenC> funny thing is that I have daap running on an ubuntu box :)
<BenC> the server that is
<BenC> crap, I can't even get the build-deps to install
<slomo_> BenC: why? what is missing/broken? ;)
<BenC> elmo: Build-Depends dependency for banshee cannot be satisfied because the package libnjb-cil cannot be found
<BenC> s/elmo/E/
<BenC> this is on powerpc
<slomo_> mono is broken on ppc anyway atm :( sorry
<slomo_> but you could build everything yourself unless you have a SMP ppc
<BenC> UP
<BenC> just build mono, that it?
<Kamion> pitti: I'm just going to promote the split-out bits of sysutils; I don't think they need inclusion reports
<slomo_> BenC: fine then... you need mono, gtk-sharp2 and njb-sharp... that's it iirc
<pitti> Kamion: sure, go ahead
<Kamion> (memtester, procinfo, tofrodos)
<pitti> Kamion: if you do archive stuff anyway, could you please NEW sudo?
<Kamion> pitti: ok, will do once cron.daily has finished
<pitti> thank you
<pitti> Kamion: the new version has the new env var handling semantics
<BenC> slomo_: this is an aweful lot to listen to music, but what the hell :)
<pitti> Kamion: I'm eager to get beaten up^W^Wqualified user feedback
<Kamion> heh
<slomo_> BenC: sorry, not my fault ;) the corresponding bugreport is http://bugzilla.ximian.com/show_bug.cgi?id=77028 if you want to take a look
<janimo> join #fridge-devel
<janimo> sorry :)
<teroedni> hello
<teroedni> hope someone knows this
<teroedni> How do you run debug with network-admin?
<teroedni> Thanks for help
<pitti> sudo gdb /usr/bin/network-admin $(pidof network-admin)  ?
<janimo> Kamion, I did not see other timezones such as europe but will look better as I am doing a new install shortly
<pitti> teroedni: ^
<janimo> related to the non-english timezones bug I filed
<janimo> any fridge admin you happen to know by nick around here?
<janimo> jdub maybe? ^
<janimo> or even ubuntu-meeting moderator will do
<Kamion> janimo: it only displays the timezones for the country you selected, on the assumption that if you were in a different timezone then you'd have selected an appropriate country
<janimo> Kamion, oh silly me I mistook the country selection for keybord layout selection then
<Kamion> pitti: done
<janimo> english keyboard, US variant
<Kamion> janimo: they're certainly separate questions
<Kamion> language: English, country: United States, keyboard: American English
<janimo> did it used to ask that in the same order before?
<janimo> for some reason I think the first 3 questions I always got right so far
<janimo> mechanically
<doko> infinity:  python2.4 on the ia64 buildd: test_ioctl skipped -- Unable to open /dev/tty
<doko> then the testsuite hangs
<janimo> I think language/kb is related and so is country/timezone, but they may not be asked in this order for other reasons
<Kamion> janimo: yes, same order since pre-warty
<Kamion> janimo: although depending on the language you might not get the country question (er, which kind of exposes a design flaw in how the timezone question works, but that doesn't apply to your particular case ...)
<janimo> right, today was the first time I got this wrong and I am sure I did not read these 3 first questins before. Oh well.
<ogra> dholbach, ping
<sjoerd> pitti: hal patch works, if you want i can put it online for you to eyeball... Before sending upstream, i want to eyeball it myself one more time, check some things and probably clean up the debugging a little
<pitti> sjoerd: yes, I'd like to take a look at it after your fixes
<pitti> sjoerd: and thanks, you rock :)
<sjoerd> np
<desrt> seb128; daniel and corey
<seb128> desrt: hi, oki :)
<dholbach> ogra pong
<desrt> they put me up to it, i swear :)
<ogra> dholbach, popsuqres is in xscreensaver and gnome-screensaver ... where do we disable it (i used to supress it in xscreensaver-data, but tht never really seemed clean to me)
<ogra> *popsquares
<dholbach> ogra: didn't you disable it in a huge list of screensavers?
<dholbach> ogra: in gnome-screensaver?
<desrt> seb128; why?
<seb128> desrt: just curious as said
<ogra> dholbach, i'm splitting the screensavers so we only have to ship the ones we really want
<desrt> (if you get to ask, so do i) :)
<desrt> seb128; what did you think of the suggestions?
<dholbach> ogra: sounds cool
<ogra> dholbach, doing this, i wanted to clean up the situation a bit ... do you think gnome-screensaver will survive if we disable it there ?
<ogra> not sure if it needs at least one hack to work
<dholbach> ogra: *sing o/~ it will surviiiiiiive ~\o*
<seb128> desrt: I think I'll comment on it later, I've just quickly read it, flooded with GNOME 2.13.5 tarballs for 2 days now, but basically you point some bugs (most known) and the non-locking behaviour was because mpt/lmanul argued it is this way on macOS and jdub said it was worth a try
<desrt> hmm.
<ogra> dholbach, ok, cool, then i'll leave it in xscreensaver and disable it in gnome-screensaver, thanks
<desrt> macos invariably comes up when talking about this logout/poweroff dialog :)
<dholbach> ogra: sounds good.
<ogra> :)
<dholbach> ogra: *crossing fingers*
<ogra> heh
<jdub> desrt: mostly because they (and to a certain extent, windows xp) got it right
<jdub> desrt: we're just mucking about in the shallow end of the pool while vuntz_ gets it right upstream (in gnome-panel)
<desrt> jdub; we're a long way from macos.
<jdub> not in gnome-panel
* desrt hasn't seen the changes there
<desrt> does it have a separate "power off" menu item?
<jdub> yes
<seb128> jdub: you think vuntz got it right?
<desrt> ah.  there we go.
<jdub> log out / turn off
<desrt> perfect
<jdub> seb128: still waiting to see it, but from the bug it looks very close if not right
<seb128> desrt: http://bugzilla.gnome.org/show_bug.cgi?id=92277
<seb128> jdub: mark will not be happy I guess :/
<seb128> that's going to conflict with what he asked
* seb128 grumpf
<jdub> seb128: it doesn't conflict
<ogra> i agree with jdub, but adopting the icon stuff from ours into vunz' suggestion would be nice
<mjg59> Is there a screenshot of what it currently looks like?
<jdub> mjg59: see the attachments on that bug
<seb128> on the bug I just pointed
<ogra> mjg59, in the bugreport
<ogra> our current one looks way more shiny ... 
<ogra> we should merge both attempts ...
<desrt> wow.  i had no idea so much discussion was going on upstream
<SEJeff> The logout dialog doesn't grab focus and raise to the front by default. This should be a bug
<desrt> seb128; thanks for the bug
<seb128> desrt: np
<desrt> the icons have a huge problem
<desrt> they're totally not-hig and you get non-obvious default behaviour as a result
<desrt> in effect 'cancel' becomes the default action :/
<azeem> are the icons taken from Tango?
<ogra> nope
<azeem> they look familiar, though
<ogra> they are developed for the dialog
<azeem> ok
<jdub> ogra: where 'shiny' ~= 'totally odd'
<desrt> they're very shiny
<mjg59> Is the icture of our one still current?
<mjg59> +p
<mjg59> If so, can we lose the sleep and hibernate by default?
<ogra> jdub, where shiny == i like it :)
<desrt> mjg59; it's about right....
<ogra> jdub, but vuntz' suggestion is more logical ..
<desrt> mjg59; how do you propose to trigger these things?
<ogra> desrt, gnome-power-manager
<desrt> what UI for it, though?
<seb128> http://www.manucornet.net/GNOME/logout_dialog/Capture.png
<ogra> it has the items in its menu
<mjg59> davidz: g-p-m, and optionally in the menu but only if they're enabled in g-p-m
<janimo> Kamion, I think I can now rule out broken media, as install fails the same way from another CD, and both iso md5sum and intergrity check pass
<desrt> ogra; where is the g-p-m menu?
<ogra> desrt, on the g-p-m icon
<janimo> it stops with udev --configure failed, with ubuntu-minimal and pcmciautils not installing
<ogra> right click it
<jdub> mjg59: we could hack it to only display those icons if g-p-m say so
<desrt> on the tray?
<ogra> yup
* desrt wasn't aware that was visible
<janimo> and saying in RED that things will be retried 5 times
<mjg59> jdub: Yup
<ogra> desrt, you can disable the icon 
<jdub> my concern is the g-p-m ui is just decentralised splat-on-splat
<mjg59> jdub: We still can't ship with suspend to RAM enabled by default
* desrt raises an eyebrow at the logout submenu
<jdub> just gotta make sure manu knows what he needs to do to integrate it
<Kamion> janimo: attaching the installer's /var/log/syslog to a bug report should help me
<janimo> Kamion, ok I'll retry and save it if possible
* ogra vomits over cdbs in gnome-screensaver
<Kamion> janimo: if not, finding out for me more detail on why pcmciautils fails would be nice
<Kamion> nano -v /var/log/syslog and look for the actual erroor
<Kamion> error
<janimo> pcmiautils fails because it depends on udev
<janimo> which failed do dpkg --configure
<janimo> as far as I see
<janimo> oh, nano. I tried less but it wasn't there
<janimo> Kamion, so IIRC when loking at the tail of the errors it went dpkg --configure failed for udev
<janimo> then ubuntu-minimal and pcmciautils which depended on it failed too
<janimo> will produce more details hopefully, I'll reboot soon
<Kamion> janimo: ok, then finding out exactly why udev failed would be good
<janimo> Kamion,  /usr/sbin/mkinitramfs: line 36: /etc/mkinitramfs/initramfs.conf: No such file or directory
<janimo> Jan 17 19:55:15 debootstrap: dpkg: error processing udev (--configure):
<janimo> Jan 17 19:55:15 debootstrap:  subprocess post-installation script returned error exit status 1
<janimo> but I'll attach the whole file to a LP bug 
<Kamion> nice ...
<Kamion> you must have no swap partition configured?
<Kamion> otherwise base-installer ought to have created /etc/mkinitramfs/initramfs.conf
<Kamion> but yeah, bug report'd be good
<janimo> I have swap configured
<janimo> at least it detected the existing swap
<janimo> but I chose root as hda4 and home hda10 or so I hope it did not get confused by the partition layout somwhow
<janimo> swap is on ext2
<ogra> ?
<janimo> could that be it? These all should be in the syslog for you to see I assume
<janimo> ogra, right  I am silly
<ogra> you mean s/ext2/hda2 ?
<janimo>  boot is on ext2
<ogra> heh :)
<janimo> yeah swap was detected as swap
<janimo> Kamion, indeed in syslog I now see : Device or resource busy for times for trying swapon
<janimo> so that may be the cause
<janimo> four times not for times
<Riddell> do I use Fix Committed or Fix Released in Malone if the package is in dapper?
<ajmitch> fix released, I think
<Riddell> sounds best to me
<ajmitch> fix committed was previously called pending upload
<mjg59> Robot101: http://ralphm.net/blog/2006/01/17/gtalk_s2s
<Riddell> seb128: do you know if gnome needs libnss-mdns for avahi DNS?
<Robot101> mjg59: I know
<mjg59> Does it work, then?
<Robot101> not tried it, don't really care. the implications for me are just annoying
<seb128> Riddell: I don't think so, but avahi-daemon Depends on it, why? slomo_ probably knows better about that though
<mjg59> Haha
<Kamion> janimo: dunno, probably not
<Kamion> janimo: swap's only relevant in that base-installer uses it to guess a resume partition
<janimo> Kamion, I attached the full log anyway to a bug
<Kamion> ta
<Kamion> oh, hey, base-installer's initramfs stuff won't have run at that point anyway
<\sh> Robot101: does it mean, that google is completly open for every s2s communications for jabber?
<ulaas> what the heck!? i have a debian root menu item in Applications.. any ideas?
<dholbach> ulaas: it's the 'menu' package
<seb128> ulaas: remove menu-xdg
<Robot101> \sh: yes
<ulaas> i wonder how it did get installed
<nbgast> seb128, You confirmed gnome-bug 323724 (g-s-d BadValue)?
<Riddell> seb128: avahi-daemon only Recommends avahi-daemon
<seb128> nbgast: I did, why
<Riddell> slomo_: do you know if gnome zeroconf needs libnss-mdns?
<Riddell> s/Recommends avahi-daemon/Recommends libnss-mdns?/
<mdke> Riddell, did you see my highlight from yesterday?
<nbgast> I pasted some debugging logs at the end. But, my debufgging skills are certinly dubious.
<Riddell> mdke: don't think so
<Riddell> mdke: hmm, build directory for kubuntu docs.  may well have done
<nbgast> seb128, the patch wasn't effective. I contacted marienz, hwo in turn recommended posting gdb output there.
<mdke> Riddell, ok. did you move the build folder from kubuntu up a dir in the ubuntu-docs repository? the preview server hasn't been updating because it syncs from the old folder. If the new build dir is trunk/kubuntu/build I can adjust the server
<mdke> but some of the www make targets need to be fixed too
<seb128> nbgast: g-s-d can crash for different reason
<nbgast> yes, but the tracebacks occur in the same function that marienz patched. he ackknowledged the relatedness.
<Riddell> mdke: please adjust the server, I'll try and look at the build targets
<seb128> nbgast: join #ubuntu-desktop about it if you want
<mdke> Riddell, awesome thanks. "make web" is what the server runs, so if that finishes, we're good to go
<seb128> Kamion: could you accept/promote new binaries from evolution-data-server?
<mdke> Riddell, it might just be enough to create the trunk/kubuntu/build/kubuntu directory
<mdke> Riddell, i think that will do it. And remove server-web from the "make web" target because that builds on the ubuntu Makefile and we don't need two on the website.
<mdke> Riddell, i'd do it but I left my svn account at the office
<janimo> Kamion, from your comments I see nothing that would be particular to my setup
<janimo> how is this working in other installs?
<Kamion> janimo: note the "random" bit in my comment ...
<Kamion> seb128: I don't see anything relevant in the queue
<Treenaks> argh, no wpasupplicant on the install-CD
* Treenaks adds 10m of Cat5 to his shopping list
<Treenaks> Kamion: any reason for that (space?)
<seb128> Kamion: I've uploaded e-d-s 1.5.5, libcamel1.2-8 and libedataserver1.2-7 are new packages (soname change)
<Kamion> Treenaks: space, and that it's in universe
<ajmitch> Treenaks: it's not in main?
<seb128> Kamion: maybe it has not been accepted yet, or maybe elmo processed it already ... in case it show up would be nice to get them promoted so we can rebuild GNOME stuff again new soname :)
<Treenaks> Kamion: hm.. isn't that bad (the it's-in-universe thing)?
<Kamion> seb128: oh, they just haven't built yet
<Kamion> I'll have a look after dinner
<ajmitch> Treenaks: write up a main inclusion report then :)
<seb128> Kamion: thank you
<Kamion> Treenaks: somebody needs to look over it, verify that it's sane and supportable, etc.
<seb128> dinner time here too
<seb128> bbl
<Treenaks> Kamion: ok... how does that work? (where do I submit a request?)
<BenC> slomo_: banshee needs avahi-sharp, where can I find it?
<Kamion> Treenaks: see http://wiki.ubuntu.com/UbuntuMainInclusionRequirements and http://wiki.ubuntu.com/UbuntuMainInclusionQueue
<Kamion> I'll write up something about that for DeveloperResources after dinner
<ajmitch> BenC: libavahi-cil
<BenC> thanks
<pitti> to all the native English speakers here: it's 'detailed', not 'detailled', right?
<Burgwork> pitti, yep
<pitti> thanks
<pitti> Hey Keybuk 
<Keybuk> pitti: hey
<ogra> Keybuk !
<Keybuk> pitti: so I was thinking ... how did bootlog work before then?
<BenC> ok, banshee installed, and it's reading my itunes share, but it crashes when I try to play a song from it
<Keybuk> it used to be at S02, which meant it wouldn't have a writable filesystem then either
<ogra> Keybuk, it never worked in ubuntu
<Keybuk> I moved it forwards because it depends on /dev/pts, tty, etc.
<pitti> Keybuk: in breezy checkroot was at 10
<pitti> Keybuk: hm, then it apparently didn't work either
<Keybuk> pitti: yeah, but bootlog was at 02 ... 02 < 10 :)
<pitti> Keybuk: but still we could make it work in dapper :)
<ogra> Keybuk, i had a BOF with dilinger about it at UDU
<pitti> Keybuk: or drop it completely (it's pretty reduntant anyway)
<Keybuk> if it needs a writable /var, it needs to be moved to after mountall
<pitti> redundant, even
<Keybuk> so, err *checks whiteboard*, S37 or so
<ogra> there must be a UDU spec somewhere 
<Keybuk> and by that point, you've missed most of the boot that was worth logging ;)
<pitti> Keybuk: if it's started that late, it doesn't make much sense any more I think
* Diziet uploads ff 1.5.  Still no fix for amd64 that I know of but at least I'll get a build log.
<pitti> Keybuk: heh :)
<Diziet> Also I have a vague hope it might reduce general crashiness compared to the rc3 we've had so far.
<pitti> Keybuk: I wonder if there would be any information in it which isn't already in kern.log and syslog
<Diziet> Of course Debian reorganised everything in the meantime so instead we're going to have even more reorganisation-induced breakage.
<Keybuk> pitti: so yeah, either drop it entirely (something I won't cry about) or modify it to write to /var/run and move to /var/log later?
<Keybuk> pitti: it logs the console output
* dholbach hugs Keybuk
<pitti> Diziet: maybe it also fixes the menu dizzyness
<Keybuk> I'm not sure whether it even works with usplash :p
<Keybuk> or we could make it part of usplash
<Diziet> Menu dizzyness ?
* Keybuk hugs dholbach 
<ogra> Keybuk, i tried to switch my thin client chroots to dash for a test the other day ... hearly everything worked fine apart from udev ...
<pitti> Diziet: sometimes, the menus go crazy and I have to navigate thorugh them with the left mouse button pressed (and even then it fails sometimes)
<ogra> s/hearly/nearly
<Diziet> How odd.
<pitti> Diziet: but it's hard to reproduce and happens only seldom, so I didn't bother filing it so far
<Diziet> Well, let me know.  (If you can get the damn thing to run at all.)
<pitti> Diziet: no, not now. I'm still using dchroot -c breezy firefox
<Diziet> :-)
<Keybuk> ogra: what broke?
<pitti> Diziet: maybe 1.5 final works, /me crosses fingers
<ogra> Keybuk, is that worth a bug or is it intentional
<ogra> it didnt start 
<Keybuk> bug please
<ogra> oki
<Keybuk> in particular, make sure you note the kernel version and stuff
<ogra> dash brings a great speedup :)
<Diziet> There's definitely at least one crappy patch still in there that needs to go out but I'm hoping the Debian maintainer will get rid of it first so it doesn't show up backwards in the d->u diff.
<Keybuk> yeah, bash is slow, news at 11
<Keybuk> I probably used a bashism unknowingly
<Keybuk> but I didn't think IU ha
<Keybuk> I had
<Burgwork> Diziet, do you love FF yet?
<janimo> Diziet, did the libnss3 dep got added?
<janimo> err, get added
<Diziet> janimo: Err, probably not.
<mjg59> mdz: Meeting?
<janimo> Diziet, it's ok I have it hand-installed. It occuers mostly with xubuntu-desktop installs where there's no gnome software to bring libnss3 in
<ogra> mjg59, its martin luther king day ... he might not be around ...
<BenC> yesterday was MLK day
<lotusleaf> today is Richard Simmons day
<ogra> oh....
<ogra> muddled the dates then :)
<dilinger> today we sweat to the oldies?
<lotusleaf> dilinger: that's the spirit!
<sjoerd> pitti: http://beast.luon.net/~sjoerd/hal.patch
<pitti> sjoerd: thanks, I'll give it an eyeballing
<sjoerd> thanks
<DoeRayMe> hey, as the forums are down, how come this isnt in the repo, universe or main? http://gift-fasttrack.berlios.de/ its a plugin for giFT, like the Gnutella and OpenFT
<mdke> jdub, awesome work on planet. got a (pretty rubbish) hackergotchi for you if it's trivial to add to planet. it's at launchpad/people/mdke
<HiddenWolf> DoeRayMe: this is a development channel.
<mdke> DoeRayMe, normally if a package isn't in Ubuntu, it means it isn't in Debian. ask in #ubuntu-motu if they will add it
<HiddenWolf> DoeRayMe: basicly, probably nobody has requested it to be packaged, and nobody has done so for ubuntu.
<dholbach> DoeRayMe: http://wiki.ubuntu.com/UniverseCandidates might be what you want.
<Mithrandir> mdke: btw, I'm going to get the breezy-docs stuff done for you, so no need to ping infinity about it any more.
<mdke> Mithrandir, oh that's the best news ever
<mdke> thanks so much
<pitti> sjoerd: OMG, that's a mega-patch :)
<Mithrandir> mdke: it might take a day or so to work out, but I hope that's ok.
<sjoerd> pitti: what did you expect ? :)
<pitti> sjoerd: mjg59 expected 'some 40 lines' :)
<mdke> Mithrandir, sure, mail me if there is anything that isn't clear: mdke@
<Mithrandir> mdke: sure.
<mdke> :))
<pitti> sjoerd: anyway, it's not something I can review besides the meeting, I'll dig into it tomorrow
<sjoerd> pitti: np, didn't expect you to do it tonight 
<Kamion> elmo: please sync installation-locale, overwriting our changes
<trappist> I posted a bug on malone and was informed by a bounce that I wasn't subscribed to ubuntu-bugs and that my message was pending moderator approval.  is there an active moderator for that list or should I repost now that I've subscribed?
<Kamion> trappist: no, it's a bug in list configuration, ignore it
<dholbach> trappist: no, just leave it and better unsubscribe, the mailing list is HIGH volume. the problem will be resolved.
<dholbach> :)
<Kamion> if you repost you'll create a duplicate in malone
<trappist> cool, thanks
<sivang> hrm, UVF means no more changes from upstream right? what about ubuntu local specs?
<trappist> I prepared myself for high volume via .procmailrc so I'll see how it goes before unsubbing
<dholbach> sivang: Feature Freeze
<wftl> Can anyone suggest a quick way to reset the desktop menus (when I do a dist-upgrade on Dapper). I want to make sure I'm always looking at the latest incarnation, but I don't want to blow away all my data.
<HiddenWolf> sivang: packages requested, considered harmless, or needed for goals stand a good chance of getting past the freeze, of course. :)
<sivang> dholbach: phew, that what I thought :) thanks for reassuring
<sivang> HiddenWolf: Nahh, I'm gonna die hard to make it before FF. if I need more time, I will ask only if those are toufh finishes, or fixes etc..
<ulaas> superkaramba depends on xmms. nonsense?
<daniels> Kamion: do you mind if we diverge a bit in base-files?
<daniels> Kamion: actually, nevermind.  i'm just being stupid.
<HiddenWolf> daniels: did your blog just tell me that you put your computer in your luggage on a trip?
<daniels> HiddenWolf: hard drives in carry-on, of course, but yeah.
<HiddenWolf> daniels: dare I ask, why?
<daniels> HiddenWolf: mostly in the name of getting DRI working on r4xx chips + pcie + amd64
<daniels> HiddenWolf: it seemed cheaper than buying airlied an amd64, a decent motherboard, and an r4xx pcie card
<HiddenWolf> ah. :/
<sd-tux> hi people, is locales package maintainer on this channel  ?  ubuntu package don't offer ka_GE.UTF-8 locale .. same version on debian SID offers it
<Mithrandir> it doesn't seem to be supported
<HiddenWolf> isn't that pitti?
<pitti> sd-tux: yes, that sounds like I am to blame
<pitti> sd-tux: I'll resync with belocs
<sd-tux> pitti: ok cool
<mhz> jdub: ping
<bronson> Bug in Dapper: /dev/fuse is groop "root" where it should be group "fuse"
<Keybuk> bronson: file a bug
<bronson> ok.
<Keybuk> http://launchpad.net/distros/ubuntu/+source/udev/+filebug
<daniels> Kamion: we only support upgrading through each stable release, right?
<daniels> Kamion: i'd like to ditch the /usr/X11R6 symlink<->dir migration logic
<bronson> Keybuk, hey thanks!
<pitti> mjg59: btw, will you upload a new version soon that addresses the issues in the main inclusion report?
<pitti> mjg59: pam-foreground, that is
<mjg59> pitti: Yup
<Kamion> daniels: yes, but we would also like to support Debian relatively-recent-ish to Ubuntu sidegrades, and I think that logic is still needed there
<HiddenWolf> Kamion: isn't debian -> ubuntu a recipe for definite pain?
<pitti> mjg59: btw, it isn't actually 'foreground', more 'console', right? so did you just name it like this to avoid name clashes with Fedora's pam_console, or can you actually find out which is the active display?
<Kamion> HiddenWolf: it had better not be
<Kamion> HiddenWolf: there may be some issues, but we can and should resolve them IMHO
<pitti> mjg59: it would totally rock if the current console could be determined by unprivileged programs
<mjg59> pitti: It would, but, well.
<mjg59> You need to be able to open the current tty, and that's owned by root in X's case
<pitti> mjg59: well, actually I don't even need the current tty number, just the information whether or not a given $DISPLAY is active or not
<mjg59> pitti: Uh. No, there's absolutely no way of doing that.
<pitti> bu this seems to be incredibly difficult to find out
<mjg59> The concept of an active DISPLAY doesn't really make any sense
<ogra> mdz, do you have an opinion to using /bin/sh -> /bin/dash on thin clients ? 
<mjg59> It's perfectly valid to have more than one
<pitti> mjg59: well, it breaks removable devices in interesting ways if you have a spare session on an inactive x session
<daniels> Kamion: mmm, okay
<mjg59> pitti: How?
<pitti> mjg59: yes, I'm aware of the multihead problem
<pitti> mjg59: say I'm at vt7, and my gf has a locked display at vt8
<mjg59> pitti: Yes
<pitti> mjg59: then both g-v-m's race about grabbing a newly plugged usb stick
<mjg59> pitti: No, that's the point of this code
<mjg59> (Well, amongst others)
<mjg59> That's a solved problem
<pitti> mjg59: so if I'm unlucky, my gf gets the stick assigned, and I can't access it
<pitti> mjg59: oh?
<mjg59> You just ensure that mount requests are coming from the current VT
<pitti> mjg59: so 'foreground' is indeed justified?
<mjg59> Yes
<mdz> ogra: I'd be interested in measurements of the performance impact
<pitti> yay
<mjg59> pitti: At the moment, it requires dbus to have a small root helper
<ogra> it *feels* faster... i havent done any relevant measuring yet
<mjg59> (which is in our dbus)
<pitti> mjg59: I thought it just records which user is at which console
<mjg59> pitti: Yes, that's what it does
<pitti> mjg59: ah, I see, and this helper calls fgconsole?
<mjg59> Then dbus checks that
<pitti> I see
<pitti> or s/call fgconsole/just do the system call to find it out/
<mjg59> It's an ioctl, but yeah
<pitti> I saw the code once, it was fairly easy, yes
<dholbach> mjg59: I wondered, if you were going to include gnome-power-manager 0.3.4 - which was released with gnome 2.13.5.
<ogra> dholbach, just packaging it :)
<dholbach> ogra: ah ok, cool.
<ogra> dholbach, will get in tomorrow with a bunch of other stuff from my disk ;)
<Kamion> elmo: please sync aalib, chucking changes
<netdur> hey, I don't know how to report bug about this problem http://www.flickr.com/photos/77122833@N00/87969378/
<HrdwrBoB> that means  either the initrd is broken
<HrdwrBoB> or your hard drive is broken
<netdur> can vmware hard drive be broken?
<HrdwrBoB> if you break it in the options
<HiddenWolf> bugs seen on an emulator are always unreliable
<netdur> I did not change anything... I used recommended options (which vmware choose per default), and that screenshot is on first boot after first stage instalation
<netdur> do dapper support ide hd well?
#ubuntu-devel 2007-01-15
<doko> Mithrand1r: please requeue kde-guidance
<woodwizzle> Is there a good reference or tutorial to explain how to make a derrivative distro of Ubuntu
<Hobbsee> !derivative
<Hobbsee> oh darn
<woodwizzle> oops =)
<Hobbsee> there's stuff on the wiki somewhere, and heaps on th eubuntu-devel mailing list, in previous months
<Hobbsee> that should be a start
<HombreMagique> hi all
<HombreMagique> where can i find patches applied to ubuntu kernels 2.6.17?
<crimsun> there is no patchset per se; it's tracked in git
<HombreMagique> and how can i get them?
<crimsun> see www2.kernel.org/git/ under ubuntu-edgy
<HombreMagique> :)
<HombreMagique> ok thanks
<HombreMagique> so when i found what i need
<HombreMagique> what should i do in order to download patches?
<crimsun> there are no patches per se. You must download a stock 2.6.17 tree (or use the stable git) and ubuntu-edgy, then use diff -uNr
<pitti> Good morning
<fabbione> yo pitti
<pitti> Hey Fabio!
<Treenaks> Is there some kind of 'This is REALLY ugly, we should fix this'-program for dapper (and if there is, where can I read more about it? :))
<fabbione> Treenaks: ???
<Treenaks> (s/ugly/buggy/)
<Treenaks> fabbione: well.. the racoon package is very badly broken.. I was wondering if there was any chance of it being updated, or if I had to upgrade my server to edgy (*shudder*)
<Treenaks> or backported
<fabbione> Treenaks: https://wiki.ubuntu.com/StableReleaseUpdates
<Treenaks> fabbione: thanks
<pitti> marcheu: hi 
<Mithrand1r> doko__: given-back
<Hobbsee> Mithrand1r!!!
<Mithrandir> Hobbsee :-)
<Hobbsee> :)
<Mithrandir> how's life?
<Hobbsee> good :)
<Hobbsee> Mithrandir: went to the LCA pre-dinner last night, that was fun :)
<Mithrandir> Hobbsee: lucky you.  I want to be there too, but nobody offered to pay for my flight.
<Hobbsee> Mithrandir: awww :(
* Hobbsee only had to train, fortunately
<Mithrandir> cheapest flight with KLM is like 8kNOK which is about 1600 AUD.
<Hobbsee> ouchy
<Mithrandir> did you meet up with any of the other ubuntu devs there?
<Hobbsee> Mithrandir: well, i met stevenk, obviously, which i'd done previously, a few other people.  one german guy...forgotten his name.  saw jono bacon, but he didnt recognise me, was talking at his table so i didnt go over
<Mithrandir> sounds fun
* Hobbsee nods
<mantiena> hello all
<mantiena> pitti, hi, are you alive ?
<Hobbsee> no, we shot him
<pitti> mantiena: yes, I am
* pitti pokes Hobbsee
* Hobbsee pokes pitti back
<mantiena> pitti, few months ago (before feisty release) we were talking about ability to mount hard drive partitions, especially in LiveCD, then you told be, that you will have time for this after 2 monts after release, so, now is that time ;)
<pitti> mantiena: well, it's implemented in Feisty :)
<mantiena> pitti, sorry, I was talking about edgy release ;)
<pitti> mantiena: well, too late to change edgy
<mantiena> pitti, I understand, that too late for edgy, you told this 3 months ago ;)
<pitti> mantiena: sure, but three months ago it was already too late for edgy :)
<Mithrandir> tepsipakki: hi, regarding your sync requests.. any progress on finding somebody to ack them?
<mantiena> pitti, so, could you tell me how user can mount hard disk partitions in feisty ? with gnome-mount ?
<Hobbsee> Mithrandir: which are they?
<pitti> mantiena: right click -> mount
<pitti> mantiena: or, on the shell: gnome-mount -d /dev/hda2 
<Mithrandir> Hobbsee: https://bugs.launchpad.net/~tepsipakki/+reportedbugs?field.searchtext=sync&orderby=-importance&search=Search&field.status%3Alist=Unconfirmed&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Needs+Info&field.status%3Alist=Fix+Committed&field.assignee=&field.owner=&field.omit_dupes=on&field.has_patch=&field.has_no_package= at least
<Mithrandir> (go lp URLs)
<Hobbsee> hah
<Mithrandir> Hobbsee: 76704 76711 76719 76727 76751 76752
<Hobbsee> Mithrandir: just looking at the last one
<Mithrandir> Hobbsee: cheers.
<Hobbsee> oh ouch...
<Hobbsee> tepsipakki: can you find a decent diff for the last one?  that's unreadable
<tepsipakki> mithrandir: haven't tried to find one yet..
<tepsipakki> hobbsee: I'll check them when I get to work.. maybe the same reason as with one of the merges
<Hobbsee> tepsipakki: OK.  just https://bugs.launchpad.net/ubuntu/+source/gmail-notify/+bug/76752
<Ubugtu> Malone bug 76752 in gmail-notify "Please sync gmail-notify (universe) from unstable (main)" [Undecided,Confirmed]  
<tepsipakki> ngh, that's ugly :)
<Hobbsee> tepsipakki: beaglefs is on manual - were the tarball md5sums the same?
<tepsipakki> have to check that one as well..
<tepsipakki> but I'll be back in one hour
<mantiena> pitti, so, what you think about mounting hard disk partitions automatically for LiveCD (not for installed systems), look at bug #16356 ?
<Ubugtu> Malone bug 16356 in casper "LiveCD does not mount hard disk partitions (yet)" [Wishlist,Confirmed]  https://launchpad.net/bugs/16356
<pitti> mantiena: I'm totally opposed to automatically mounting hd partitions, at least r/w. r/o would be okay for me
<pitti> mantiena: we have a spec stub for this, a minute
<pitti> mantiena: https://blueprints.launchpad.net/ubuntu/+spec/live-system-fs-mounting
<mantiena> pitti, I agree with you on r/w mount, especially when Linux will have ability to mount r/w NTFS filesystems :) But I think read-only automounting hard disk partitions is a must for LiveCD :)
<pitti> Mithrandir: can you please try to give-back apport? seems to suffer from transient python transition fallout
<Hobbsee> hey dholbach!!!
<dholbach> good morning
<dholbach> hey Hobbsee
<Hobbsee> dholbach: might have been nice to warn people about the bughelper bugs, maybe?
<_ion> Hi
<Hobbsee> heya _ion 
<Hobbsee> dholbach: was trying to figure out why my filters failed :P  eventually figured it was from the ML being subscribed to all the bugs.
<Mithrandir> pitti: given-back
<pitti> Mithrandir: thank you
<dholbach> Hobbsee: I didn't file them
<dholbach> Hobbsee: it's simply subscribed to bughelper bugs, not to "all the bugs" :-)
<Hobbsee> dholbach: all the bughelper bugs, i meant :P
<dholbach> :)
<Amaranth> bughelper bugs?
<Hobbsee> Amaranth: yes
<Hobbsee> Amaranth: bughelper is for help with bugs...
<Amaranth> Really? I thought it was something to do my laundry. :)
<dholbach> Amaranth: that's for v2.0
* dholbach hugs Hobbsee
<dholbach> Hobbsee: is there anything you'd like to suggest?
<Hobbsee> Amaranth: hehe :P
* Hobbsee hugs dholbach 
<Hobbsee> dholbach: dunno.  the [bughelper]  in front of all the bugs is a good start, makes it easy to filter
<dholbach> Hobbsee: phew... not sure we can prepend that to bug mails, since they're automatic and I'm pretty bad at mailman foo - regex rules always failed for me
<Hobbsee> dholbach: hrm.  good point
<mantiena> dholbach, Hi, could you stop reject Baltix bugs, which are reported/assigned to Baltix by main Baltix developer (me, Mantas) ? ;)
<mantiena> dholbach, please :-*)
<dholbach> mantiena: these were bugs that were fixed already... I was under the impression that if they were fixed for us, they were fixed for you too
<dholbach> mantiena: I didn't reject all Baltix bugs
* mdke hugs dholbach 
* dholbach hugs mdke back! :)
<mdke> :)
<dholbach> mdke: how's it going?
<mdke> dholbach: very well, you?
<dholbach> waking up slowly - but very good thanks :)
<mdke> same
* mdke dholbach 
<mdke> whoops
* dholbach mdke
<mdke> that's evidence of my waking up, wrong command
<dholbach> hehe :)
<_ion> You type the right commands when you're asleep? ;-)
<Treenaks> Strange Case of Dr. Holbach & Mr. East?
<mdke> _ion: haha
<Treenaks> _ion: when he's asleep, he's dholbach 
<dholbach> hehe :)
<mantiena> dholbach, Baltix doesn't follow Ubuntu release schedule, so, some bugs are fixed in Baltix later, than in Ubuntu and some - faster ;)
<dholbach> mantiena: right
<dholbach> hey seb128
<seb128> Hey dholbach
<mantiena> pitti, btw, 3 months ago I sent you patch for pmount to allow globs (2 lines patch ) :) It seems this patch is still not accepted, maybe you forgot ?
<pitti> mantiena: Admittedly I didn't care for pmount development very much recently, because we do not use it any more in Ubuntu/Kubuntu
<mantiena> pitti, so, where I should send my 2 lines to be accepted ? ;)
<pitti> mantiena: just leave them in LP, I'll apply them at some time
<mantiena> pitti, btw, pmount upstream is www.piware.de/projects/ , right ?
<pitti> mantiena: right
<mantiena> pitti, but there are no CVS, no BTS, etc :(
<pitti> mantiena: those are on LP
<pitti> mantiena: you can file them as Ubuntu bugs or /products/pmount upstream bugs, and there is a bzr branch
<pitti> LP just doesn't allow me to publish tarballs
<mantiena> pitti, evil LP ;)
<fbenites> hi! 
<fbenites> does someone use uml(user-mode-linux)?
<dholbach> hey seor doko
<dholbach> hey mvo
<doko> hey ballerina dholbach
<dholbach> hahaha
<mvo> hey dholbach!
<doko> pitti: postgresql-plpython-8.1 and postgresql-plpython-7.4 seem to have hardcoded dependencies on python2.4
<pitti> doko: can't see any
<pitti> doko: it b-deps on python-dev, python-central (>= 0.5)
<doko> pitti: most likely scripts using the versioned interpreter name
<pitti> doko: ah, I see; I'll check the upstream bits
<tepsipakki> hobbsee: beaglefs md5sums matched debian, but you noticed that already?
<doko> ogra, seb128, dholbach: gcompris currently ftbfs for some reason. could one of you have a look?
<Mithrandir> doko: one of its build-deps contains a .la file which references libartsc.la, I'd guess.
<Mithrandir> libsdl-mixer probably needs a rebuild.
<fbenites> i can get uml to run... sombody anyhints? (seems my kernel doesnt support skas)
<doko> hmm, packages.ubuntu.com doesn't allow me to search for files in feisty ...
<Mithrandir> doko: I've uploaded a new sdl-mixer which should make a give-back of gcompris work.
<doko> Mithrandir: thanks
<mneptok> doko: ping
<doko> mneptok: pong
<tepsipakki> doko: python2.5 is default now, so a package depending on python-gtk2 (and not python2.4-gtk2) is ok?
<mneptok> doko: have some reflections re: bash_profile. can we discuss on the phone when you have 5 minutes?
<mneptok> doko: (not urgent doesn't need to be today)
<doko> tepsipakki: in principal yes; the extra dependency on python2.4-gtk2 enusres that the python-gtk2 package still provides python2.4-gtk2; you can change it to python2.5-gtk
<doko> mneptok: sure
<mneptok> doko: ping me when you have time. i'll dial. i'm here 0400-1300UTC all week.
<tepsipakki> doko: it's gmail-notify which you uploaded on Friday and I'm checking if it is syncable from debian
<tepsipakki> +still
<doko> tepsipakki: we do not want to depend on python2.4 for feisty anymore; so you have to change it
<tepsipakki> doko: but it doesn't depend on python2.4* :)
<Hobbsee> tepsipakki: i didnt check
<tepsipakki> but build-dep on python, and dep on python-gtk2 and python-gnome2-extras
<tepsipakki> Hobbsee: ok, but they are the same :)
<Hobbsee> tepsipakki: cool
<marcheu> pitti: hi
<doko> Mithrandir: please requeue bzr
<Mithrandir> doko: given-back.
<doko> tepsipakki: you have to look at the binaries, so that you don't have any python2.4* dependencies
<tepsipakki> doko: well, the version in ubuntu now does have python2.4 deps ;)
<pitti> marcheu: hi! did you see my /msg?
<doko> tepsipakki: fix it :)
<pitti> doko: do you have an idea about http://librarian.launchpad.net/5747089/buildlog_ubuntu-feisty-i386.apport_0.39_FAILEDTOBUILD.txt.gz ?
<tepsipakki> doko: if we sync it from debian, it'll fix itself ;)
<tepsipakki> doko: but I'm working on it
<doko> pitti: neither a b-d on python-dev or python?
<marcheu> pitti: yep
<pitti> doko: right, only on python-support; that worked fine so far
<pitti> doko: ok, so I need python-dev (>= 2.4)?
<doko> pitti: yes, as everybody does ;-P
<pitti> doko: ok, thanks!
<pitti> doko: (just weird that I need -dev at all; after all, I only ship pure python modules
<pitti> doko: so if python-central requires a header file from -dev, -central should have a dependency
<tepsipakki> Hobbsee: there's a new diff now
<doko> pitti: I have to check; apparently 2.5 now uses config.c by default, even if building pure python modules
<pitti> doko: postgresql-8.1> I just rebuilt the source on current feisty, and now I get a 'python2.5 (>= 2.5)' dependency
<doko> pitti: no; just dh_pycentral needs the dependency, not the runtime
<pitti> doko: so a mere rebuild is enough
<pitti> doko: I don't understand: p-c ships dh_pycentral, that needs the header file, so it should depend on it?
<cjwatson> Mithrandir: for bug 73955, does the system on which you can reproduce it have the fbcon module loaded?
<Ubugtu> Malone bug 73955 in console-setup "Clobbered X screen state during installation" [High,Confirmed]  https://launchpad.net/bugs/73955
<cjwatson> crimsun: ^-- same question
<doko> pitti: just tried: https://launchpad.net/ubuntu/+source/postgresql-8.1/8.1.5-2build1
<pitti> doko: I saw; seems it needs another retry
<doko> pitti: we do not want to install python-dev by default.
<pitti> doko: ah, I see
<pitti> doko: anyway, I filed sync requests for psql 7.4 and 8.1, thus we'll get the rebuild for free
<pitti> if we can bribe Mithrandir to do these syncs now, then we don't need to build it twice
<doko> yeah, there are other python related syncs ;)
<crimsun> cjwatson: yes
<Mithrandir> cjwatson: probably, yes.  I can reboot and test if you'd like, but the installed system has it at least.
<Mithrandir> pitti: I'm in the middle of reviewing a 1682 files big source package, so not right now, no.  Afterwards.
<pitti> Mithrandir: oh, no problem; thanks
<cjwatson> ah, fbcon is built in on powerpc, so it may not be exactly that
<fbenites> i can't get uml to run... Does somebody have anyhints? (seems my kernel doesnt support skas)
<Chipzz> hi
<Chipzz> is the firefox maintainer present?
<Treenaks> Chipzz: just ask your question :)
<Hobbsee> that's iwj, isnt it?
<Chipzz> I suspect a (IMHO) critical bug in the last firefox edition
<Chipzz> I cannot submit forms anymore in plesk, and some forms in OWA (Outlook Web Access) anymore...
<cjwatson> the bug tracker is --> that way; we don't have anyone dedicated to maintaining firefox just now
<Chipzz> uhu ok
<cjwatson> (this should be resolved in the not so distant future, but for now ...)
<Chipzz> is it a known issue?
* Hobbsee wonders why people often try to come in here to report bugs
<Hobbsee> Chipzz: the bugtracker will tell you that.
<cjwatson> if it is a known issue, the bug tracker will say
<Chipzz> Hobbsee: I'm trying to figure out if it's a known issue; might potentially affect a lot of people
<Chipzz> anyway, off to the bug tracker it is
<Hobbsee> Chipzz: out of the great number of bugs in firefox, let alone the entire bugs in malone, the chance that we'd remember one in particular, particularly it's severity, is almost nil
<pitti> argh, argh, bzr push broken ('Unable to import paramiko (required for sftp support)')
<pitti> and no python2.5-paramiko; /me waits
<pitti> cjwatson: could I upload new dapper/edgy-proposed langpacks today or is it a bad time for some reason?
<pitti> carlos: speaking of langpacks, any ETA for feisty?
<cjwatson> pitti: today is fine
<carlos> pitti: blocked on kiko
<carlos> pitti: I'm waiting for him
<dholbach> [ 7889.666280]  [drm:radeon_cp_idle]  *ERROR* radeon_cp_idle called without lock held
<dholbach> [ 7889.678289]  [drm:radeon_cp_reset]  *ERROR* radeon_cp_reset called without lock held
<dholbach> [ 7889.678314]  [drm:radeon_cp_start]  *ERROR* radeon_cp_start called without lock held
<dholbach> [ 7889.678328]  [drm:radeon_cp_idle]  *ERROR* radeon_cp_idle called without lock held
<dholbach> .....
<dholbach> is not good, hm?
<mneptok> dholbach: if you have an nVidia grfx card, that is definitely not good.
<dholbach> ok, the machine doesn't even listen to magic sysrq anymore, nice
<Mirv> dholbach: only existing bug report with similar stuff seems to be https://bugs.freedesktop.org/show_bug.cgi?id=7128
<Ubugtu> Freedesktop bug 7128 in DRM modules "Radeon R300 lockup on 2 clients accessing XV" [Major,New]  
<dholbach> Mirv: oooh, great - thanks, having a look
<dholbach> Mirv: thanks - I followed up on the bug report
<Mirv> I've come to a habit to browser ati/radeon DRM/X.org problems in both fd.o and malone, since I'm trying to fix problems on my X800 (now 2 of 3 bugs fixed, and both are in feisty!)
<Treenaks> Mirv: I've reported all of my radeon bugs on both malone and fd.o (and linked the bugs), but so far, not much progress
<Mirv> Treenaks: yes, well I finally managed to make some patches.. https://bugs.freedesktop.org/show_bug.cgi?id=6796 and https://bugs.freedesktop.org/show_bug.cgi?id=7697 - the former even got applied as such
<Ubugtu> Freedesktop bug 7697 in DRM modules "r300_check_offset fails on PCI-E R420 (5D4F)" [Normal,Resolved: fixed]  
<Treenaks> Mirv: https://bugs.freedesktop.org/show_bug.cgi?id=8038
<Ubugtu> Freedesktop bug 8038 in Driver/Radeon "Wobbly image on Radeon Mobility X700 (RV410)" [Normal,Needinfo]  
<Mirv> more people would be definitely welcome on the open source ati drivers, I think... too many current developers have working cards, I think :)
<Treenaks> Mirv: yeah.. they're all doing nouveau stuff now
<Treenaks> the good ones, at least
<doko> pitti: requested a paramiko sync
<pitti> doko: thanks, but that already happened
<pitti> doko: p-paramiko is already for 2.5, but it tries to import a missing module
<fabbione> pitti: would you like to take care of bug #79371 ? it might require SRU
<Ubugtu> Malone bug 79371 in cyrus-sasl2 "saslauthd init script does not allow movement of PID" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79371
<Mithrandir> fabbione: /etc/init.d/saslauthd is a conffile, if the user changes it, it's fine.  It's a wishlist bug at best and surely not something appropriate for an SRU.
<seb128> grumpf
<seb128> dia doesn't start with the new python
<fabbione> Mithrandir: changing the default pid in /etc/default/sasl2 makes the init script to barf.. and imho that's a bug
<Mithrandir> fabbione: yes, a wishlist or maybe minor one.
<fabbione> Mithrandir: i didn't set the importance yet :) but yes it's not critical.
<fabbione> and i was looking for a volunteer to fix it :)
<pitti> fabbione: depends on how urgent it is
<pitti> fabbione: today and tomorrow I'll cover for kees doing security updates, and then I'll be on vac
<Mithrandir> hurrah!  the NEW queue is empty, except for xen-source which needs feedback from one of the people caring about that.
* pitti hugs Mithrandir 
* seb128 hugs Mithrandir
<fabbione> pitti: not urgent.. just to be done sometimes
<gpocentek> Mithrandir: could you please give back sim on all arches?
<Mithrandir> gpocentek: given-back
<gpocentek> Mithrandir: thanks
<Hobbsee> Mithrandir: quick, lets put more crap in NEW!
* Hobbsee dumps all of REVU stuff into NEW
<gpocentek> Hobbsee: yay! a clean REVU :)
<Hobbsee> gpocentek: *grin*
* Hobbsee hugs Mithrandir 
* Mithrandir ruffles Hobbsee 
<Hobbsee> :)
* Mithrandir goes to run "queue reject"
<Hobbsee> [22:52]  <afflux> i just downloaded the hurd 2 alternate cd and wanted to run the cdromupgrade script, but that fails because it can't find it's tar.gz file. i opened the script and noticed, that this is because a variable (CODENAME) that is set to edgy instead of feisty.
<cjwatson> -> mvo
<Hobbsee> cjwatson: is this known?  it's from #ubuntu+1, it's the alternate amd64
<cjwatson> like I say, -> mvo
<Hobbsee> ah right, sorry
<Hobbsee> mvo: ping?
<mvo> Hobbsee: thanks, just read scrollback
<Hobbsee> mvo: :)
<mvo> Hobbsee: thanks and fixed. sorry :(
<Hobbsee> mvo: any ETA for the fix being published?
<mvo> cjwatson: it should be part of the next daily image. IIRC debian-cd pulls in the latest bzr version of the script automatically
<mvo> ^--- Hobbsee
<mvo> cjwatson: sorry, that was for Hobbsee 
<Hobbsee> mvo: way cool :)
<mvo> Hobbsee: the user can test it via the following command:
<mvo> /usr/lib/update-notifier/cddistupgrader /cdrom
<mvo> (assuming /cdrom is the mountpoint)
<robepisc> rodarvus, can you please take a look at bug 59618 ? It's a really high impact bug with a trivial patch.
<Ubugtu> Malone bug 59618 in xorg ""Safe graphics mode" doesn't use VESA" [High,Confirmed]  https://launchpad.net/bugs/59618
<afflux> mvo, i did it via... adding the cdrom to sources.list and apt-get dist-upgrading
<cjwatson> mvo: not bzr, no - it pulls in whatever's been uploaded to the archive
<cjwatson> dists/$CODENAME/main/dist-upgrader-all/current/
<mvo> cjwatson: right. 
<mvo> afflux: right, that should work fine as well. its just less convenient
<seb128> lunch time, bbl
<Mithrandir> ugh, reading diffs of diffs of diffs is icky.
<Hobbsee> haha
<Hobbsee> yes
<Mithrandir> seb128: in the future, please, please, please don't start two SRUs for the same package at once.  It's really painful for me trying to untangle the different bits.
<Treenaks> 4~4~
<Treenaks> oops, sorry
<gpocentek> Does this mean something to somebody: "Error: Package: and Architecture: do not alternate in debian/control" ?
<gpocentek> sim FTBFS with this error, and it built fine in pbuilder
<pitti> gpocentek: yes, that's from pkgstriptranslations IIRC
<pitti> gpocentek: or from pkg-create-dbgsym
<gpocentek> pitti: and how can I fix this? :)
<pitti> gpocentek: well, the error message is pretty clear...
<pitti> gpocentek: apparently some package has two Architecture: fields or so
<seb128> Mithrandir: ok, will try, what package was that?
<Mithrandir> seb128: gnome-vfs2
<seb128> Mithrandir: I think I asked Colin if having different SRU on the same package was fine and he was ok with it
<Mithrandir> seb128: accepted now, though
<seb128> ok, thank you
<Mithrandir> seb128: ok, it just made my head explode for a little while.
<Mithrandir> but I found all the pieces and glued it back together, so it's fine now.
<Mithrandir> doko: in bug #79358, it's ooo-l10n-km which needs removal, correct?
<Ubugtu> Malone bug 79358 in openoffice.org-l10n "openoffice.org-l10n-km has broken dep on myspell-dictionary-km" [High,Confirmed]  https://launchpad.net/bugs/79358
<doko> Mithrandir: yes
<Mithrandir> doko: cheers; removed.
<mvo> thanks doko for taking care of this bug!
<doko> mvo: which one?
<cjwatson> doko: feisty-python-roadmap should be further along than "Not started" now, yes?
<doko> cjwatson: will fix =)
<fabbione> wasabi: ping?
<fabbione> wasabi: FYI: jmartin account has been removed from Ubuntu Directory Team because he is spamming people. You want to tell him to remove Out Of Office replies to LP mails.
<fabbione> ajmitch: same for you. you are the other admin there
<_ion> E-mail should have something akin to IRC's privmsg vs. notice.
<_ion> It's defined that bots, scripts et al. send automatic messages using notice, and *never* trigger anything automatically based on a received notice.
<Mithrandir> _ion: Precedence: bulk, you mean?
<_ion> Btw, Ubugtu violates that. :-)
<cjwatson> bulk|junk|list
<\sh> if one package wasn't build because of a broken build-dep should we reupload or can one of the buildd admins rebuild it without a new upload? :)
<fabbione> \sh: the latter
<Hobbsee> \sh: ask for a giveback, of Mithrandir 
<Mithrandir> \sh: what package?
<\sh> Mithrandir: knoda..
<\sh> Mithrandir: it failed because of a broken dep of kdelibs4-dev
<pitti> marcheu, rodarvus: Rodrigo, please meet Stephane, nouveau upstream; Stephane, please meet rodrigo, our current X bitch^Wmaintainer
<Mithrandir> \sh: given-back.
<\sh> Mithrandir: thx a lot :)
<pitti> marcheu: so, rodarvus said that packaging the nouveau driver itself is easy, but that we'd need nontrivial mesa/libdrm changes
<pitti> marcheu: now, I'm just parroting (I don't know anything about those bits)
<rodarvus> marcheu, hi there
<rodarvus> I was telling pitti that, from what I understand, nouveau follows Mesa HEAD (and libdrm HEAD), so we'd need to update mesa and friends to their latest versions before 3D is usable on nouveau
<rodarvus> otoh, if we stick to 2D support, it should be quite easy to just package nouveau itself.
<pitti> rodarvus: context: I talked to marcheu about automatic problem reports for that driver; I think we found a pretty good solution now
<rodarvus> pitti, kernel will likely need nouveau patches too (again, for 3D support)
<pitti> rodarvus: right, we quickly talked about that, I'll speak to BenC/kylem
<rodarvus> our current Mesa package is (or was, a few weeks ago) 6.5.1-rc2
<rodarvus> with one patch for r200 support (which can be dropped for 6.5.2) + ubuntu changes
* pitti hugs rodarvus, thanks! (marcheu was here some minutes ago, he should answer soon)
<rodarvus> updating mesa to 6.5.2 would mean merging interesting changes from debian, and merging configs/ with upstream Mesa
* rodarvus hugs pitti
<rodarvus> if there is anything else I can do, please ping me
<marcheu> rodarvus: hi
<marcheu> rodarvus: yes, that's the case, we follow both mesa and drm heads for now
<marcheu> rodarvus: the issue with drm being that 2D depends on a drm module in any case
<marcheu> rodarvus: ATM I think packaging only DDX/DRM would be a good target, not many people are interested in a DRI driver that does only glxgears
<jsgotangco> rodarvus: !
<Amaranth> anyone have an example of a package using python-central that works with feisty?
<Amaranth> following the guide on the debian wiki it blows up quite nicely :)
<cjwatson> ubiquity works fine with python-central in feisty, but is probably more heavyweight than you'd like ...
<cjwatson> besides, it uses a private installation directory
<marcheu> rodarvus: I was also saying to pitti that if you need help in backporting the drm stuff, it should not be too hard, and there's usually a couple of hackers in #nouveau
<Amaranth> i just need an example of something the generates a value for XB-Python-Version that doesn't make pycentral explode
<persia> Amaranth: telepathy-butterfly
<rodarvus> marcheu, I was under the impression that libdrm wouldn't be *so* hard? (but I haven't looked at the nouveau patches on libdrm)
<rodarvus> marcheu, anyhow, I'll talk with pitti and see how we are going to proceed with this (and will quite likely talk to you guys soon)
<marcheu> rodarvus: well I think libdrm is the same, and for the drm component, it should be pretty much a case of copying the nouveau_* files over and adjusting the makefiles
<rodarvus> nice!
<marcheu> also, we have steplocking versioning between the DRM and DDX for now
<marcheu> you might be interested in knowing that for updates or such. we did this because we don't want to handle backwards compatibility just yet (the interfaces are still evolving)
* Amaranth stabs
<marcheu> at some point in the future we might start doing backwards compatibility though
<Amaranth> my XB-Python-Version says "$(python:Versions}"
<Amaranth> err, stays
<Mithrandir> you might want to fix that to ${python:Versions} instead?
<Amaranth> *facepalm*
<Amaranth> no, that's what it is in the control file...
<Amaranth> but pycentral is getting $(python:Versions}
<Amaranth> wtf
<Amaranth> whoa, even if i completely remove the XB line pycentral gets $(python:Versions}
<iwj> Amaranth: What's in debian/substvars ?
<iwj> Amaranth: completely remove> Err, are you editing the right file ?  debian/control is processed into the .deb by dpkg-gencontrol (called by dh_gencontrol), so you could try running that on its own and seeing what it does.
<Amaranth> i, uh, reverted back to old-style packaging and left it for upstream to figure out (it was their package)
<iwj> Mmmhmm.
<carlos> pitti: ping
<pitti> hi carlos 
<carlos> pitti: did you manage to do the lang pack update?
<pitti> carlos: yes, they should be in -proposed now for dapper and edgy
<carlos> pitti: I wonder whether we could stop doing daily exports for a couple of days
<pitti> carlos: yes, we can
<carlos> pitti: We need that to test Feisty translations opening
<carlos> ok
<pitti> carlos: now would be a good time to stop them
<carlos> pitti: ok, cool
<bddebian> Heya
<pitti> doko: can we get rid of libsvn0 and neon? (we have libsvn1 and neon26)
<tepsipakki> doko: bug 79085
<Ubugtu> Malone bug 79085 in Ubuntu "apt-get dist-upgrade error (faisty)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79085
<jonibo> jimmy:  nyckel till WIFI p kontoret...????
<jonibo> sorry
<dholbach> heno: libcolorblind upstream is a nice guy
<dholbach> heno: that worked out really well
<heno> dholbach: cool, I saw the CC
<heno> PD, very generous to the world too :)
<doko> pitti: a removal request should be filed for libsvn0 
<dholbach> heno: as soon as he gives his ACK, I'll upload
<pitti> doko: oh, NBS packages aren't automatically removed?
<doko> pitti: neon24 could be removed as well
<doko> pitti: AFAIK no (but please ask Mithrandir or cjwatson)
<doko> pitti: neon24 sources are still in the archive
<pitti> doko: right, these are universe (should still be removed, of course)
<pitti> cjwatson: I did the -updates uploads for the new timezones and added comments to bug 72125
<Ubugtu> Malone bug 72125 in tzdata "Daylight Saving changes in Western Australia" [High,Fix committed]  https://launchpad.net/bugs/72125
<dholbach> Riddell: why does cmake have colours in pbuilder but not without it? ;-)
<Riddell> dholbach: no idea
<Riddell> something to do with what it thinks your terminal is I guess
<dholbach> right... I like the colours :)
<dholbach> Riddell: i uploaded decibel - it should be sitting in NEW now
<Riddell> ooh, exciting
<jordi> hey
<jordi> how's the ubuntu kernel timestamp written?
<jordi> ie, what's the format? And, can date(1) reproduce?
<Amaranth> jordi: i think it's seconds since the computer turned on, dunno about date outputting the same format
<kylem> which timestamp?
<zul_> i think the one in the dmesg
<kylem> the one in dmesg is jiffies... it starts large because it is designed to wrap early in boot (so people can test their code handles jiffies wrapping, which used to not happen for months)
<kylem> oh, but you won't see that on x86, ignore the latter half of that.
<cjwatson> pitti: NBS are semi-automatically removed; you don't need a removal request bug, but it does need human processing of an automatically-generated report
<cjwatson> pitti: timezones> thanks
<pitti> cjwatson: ah, I see; I assume it must not have any reverse dependencies any more in order to get removed?
<cjwatson> ... or the archive admin has to be in a "what the hell" kind of mood
<cjwatson> sometimes I check, but sometimes I just decide that people need a push to rebuild against the new library
<pitti> ok, I'll check and do a few rebuilds
<Mithrandir> cjwatson: it also helps that remove-package.py doesn't support -R :-P
<davmor2> Help please I have Feisty installed and updated till a couple of weeks ago now dist-upgrade reports no updates.  Yet if I boot from the herd cd and in the live session do a dist-upgrade there are shed loads of updates.  I am on the gb server.
<davmor2> sorry herd2 cd
<cjwatson> davmor2: gb.archive is behind for some reason
<cjwatson> archive.ubuntu.com is up to date
<davmor2> cjwatson thanks thought it might be something like that.  You might want to get the gb server checked out though;)
<cjwatson> davmor2: yes, I've already raised the issue (about 15 minutes ago, since I noticed the same thing myself earlier)
<davmor2> nice one
<cjwatson> hmm, actually, more like 2.5 hours
<cjwatson> I'll raise it slightly more formally
<davmor2> don't kick them to hard they bruise easily :)
* cjwatson files an RT request
* heno waves to davmor2
<heno> Thanks for testing ISOs :)
* cjwatson very belatedly accepts a bunch of dapper-updates language packs
<wasabi> fabbione: Message acknowledged.
<dholbach> heno: I hope I just fixed the bughelper 'crash' - if the fix looks good to you (and works), we could push it to ~bugsquad and ask people more publically to make use of it and contribute to it - maybe even share their "recipes" or ask how their workflow works
<davmor2> No probs
<davmor2> Like testing stuff as a non tech means I get to contribute
<heno> dholbach: thanks, I'll pull it down
<dholbach> rock and roll - thanks, heno :)
<davmor2> heno maybe you should get onto the marketing team and talk about the isotesting and get it better publicized
<heno> davmor2: internal marketing :) good idea! 
<heno> davmor2: it's ok that we are building it up gradually so we can get better organised as we go too
<heno> 50 volunteers is already quite a lot :)
<davmor2> :)
<Riddell> cjwatson: could you give back mailody 0.3.0-1 please, kdelibs should be installable now
<cjwatson> Riddell: no, I'm not a buildd admin; look for members of the launchpad-buildd-admins team
<doko> dholbach, seb128: gnome maintainers are not subscribed to vte?
<Riddell> damn yes, I just remembered that
<zul> can someone accept xen-source pls k thx bye
<mvo> doko: whats up with vte?
<doko> mvo: python-vte should build all supported python versions
<seb128> doko: mvo maintains vte :p
* mvo kicks seb128
* seb128 hugs mvo
* mvo hugs seb128
* mvo leaves for ~1-2h 
<dholbach> heno: seems that 'series' is not the same as 'milestone'
<dholbach> heno: I wanted to set a milestone for a few bugs
<dholbach> heno: but I don't know where to set it either...
<Riddell> Mithrandir: could you give back mailody please?
<Mithrandir> Riddell: given-back
<Riddell> thanks
<shawarma> Who responds to mailmain@l.u.c mails?
<shawarma> Er... mailman@... of course.
<mdke> shawarma: the administrators
<shawarma> mdke: Well, yes. Any of the usual suspects?
<mdke> shawarma: well, all of them
<mdke> it goes into the request tracker
<shawarma> mdke: I see. Thing is that mailman discards my mail to a specific mailing list, so I thought it might be discarding my mail to mailman, too. But if it goes into the request tracker I'll give it another few days.
<mdke> shawarma: can you contact the administrator of the specific list?
<shawarma> mdke: Heh.. That's the other thing. He's MIA, so I'm trying to take over administration of that particular mailing list. :-)
<mdke> shawarma: in that case, seems reasonable to contact the lists administrators
<shawarma> Indeed. 
<elmo> mdke: any particular reason you want us to do #26462 rather than newz2000?
<mdke> elmo: lemme look at which one that is
<mdke> elmo: ah, if he has access, I can ask him, sure. Sorry
<elmo> mdke: it's fine, just wasn't sure if you were aware he could do it - I'll assign it to someone in the meantime, just to get it off the list and newz is busy too
<mdke> elmo: whichever you prefer
<doko> Riddell: please could you have a look at the kdeutils build failure?
<Riddell> doko: powerpc?
<doko> Riddell: yes
<Riddell> doko: that'll be my fault, I'll fix it
<eamonn> Hi all. I was trying Herd 2 on my thinkpad Z60t (which works perfectly with edgy) and it doesn't boot correct: udev and hal don't start, network-manager doesn't work, etc., although Gnome starts OK. I'm using the LiveCD. Assuming I can save a file to a usb pen drive (or find some other way to get the file off the PC for sending), I'd like to attach it to a bug report. Can someone tell me which files in particular are 
<mdke> eamonn: your message ended after "particular are"
<mdke> eamonn: probably dmesg?
<eamonn> sorry: most helpful. Thanks. I'll see if I can get dmesg. 
<mpt> https://help.ubuntu.com/community/LinuxLogFiles might be useful
<psusi> shouldn't install-info add ALL the listed sections in the installed info file to the top index?  because for some reason it won't add the individual commands section for coreutils
<thafreak> Don't mean to waste anyone's time...just want to know where I can find the .config file used to make the install cd's kernel...
<thafreak> no one in the support channel knew
<thafreak> and maybe even the source package for the install cd kernel if it's different...
<LaserJock> thafreak: the config file should be in /boot
<LaserJock> thafreak: and I'm pretty sure the kernels on the CD are the same that are installed
<thafreak> I switched to a console on the boot cd and looked for a /boot dir, and there wasn't one...
<thafreak> also no /proc/config.gz
<thafreak> didn't know if some one had it somewhere tucked away
<LaserJock> thafreak: ah, it might not be in /boot on the cd
<Mithrandir> thafreak: it's the -generic one.
<LaserJock> I was meaning once you've installed it
<thafreak> yeah...sort of can't install it without the updated 3ware driver :)
<thafreak> but the /boot/config-blahblah should be the same one used for the boot cd kernel?
<tonyyarusso> I'm doing a spot on Main Inclusion Requests for UWN (deferred from before), so if anyone has a spare few minutes to tell me what they think is important to know about them, please join #tonyyarusso (as a suplement to the wiki bits I've found already).
<somerville32> tonyyarusso: They are important because it is the process of promoting a package to the main repository :P
<thafreak> I'll try grabbing the .config from a running system...maybe that will work...thanks and sorry for wasting anyone's time
#ubuntu-devel 2007-01-16
<lifeless> in edgy, why does ubiquity not allow xfs/reiserfs / partitions ?
<tonyyarusso> I'm doing a spot on Main Inclusion Requests for UWN (deferred from before), so if anyone has a spare few minutes to tell me what they think is important to know about them, please join #tonyyarusso (as a suplement to the wiki bits I've found already).
<Burgundavia> tonyyarusso: you want to talk about it now
<Burgundavia> ?
<tonyyarusso> Burgundavia: Sure
<tonyyarusso> Whoever's up for it, I'm listening :)
<Burgundavia> basically main inclusion reports means Canonical is willing to support it, at the current moment
<tonyyarusso> right
<Burgundavia> packages into main must not be duplicative and have a fairly good security record
<bhale> hello Burgundavia 
<Burgundavia> hey bhale
<Burgundavia> the primary person who reviews them in Martin Pitt
<tonyyarusso> What's duplicative?  Matching features of another?
<Burgundavia> how goes life?
<Burgundavia> basically yes
<bhale> Burgundavia: ltns
<bhale> Burgundavia: life is good
<tonyyarusso> Yeah, pitti's apparently gmt+1 though :(
<Burgundavia> so we will accept on KDE text editor, one GNOME one, etc.
<tonyyarusso> gotcha
<Burgundavia> most main inclusion things recently have been hole filling in existing desktops
<Burgundavia> the last major bit brought in was XFCE
* Hobbsee well maybe two kde text editors...
<bhale> it is also new libs that introduce new features into existing packages
<tonyyarusso> XFCE overall was one MIR?
<bhale> I wrote one most recently for Sametime IM support in gaim
<bhale> pulling in libmeanwhile
<Burgundavia> no, several
<tonyyarusso> ah
<Burgundavia> one MIR is required for each source package accepted
<Burgundavia> in general, if the source has already been in main, in another package, it will be accepted
<Burgundavia> ie: if you split a source package for whatever reason
<tonyyarusso> What parts of the application process are most frequently done incorrectly/insufficiently?
<Burgundavia> for the MIR?
<tonyyarusso> Yeah
<tonyyarusso> Things people should be extra-aware of if they've never done one before, but are somewhat interested.
<Burgundavia> generall people just don't fill all the details out
<Burgundavia> all the bits needs to be filled out and the rationale needs to a strong one
* tonyyarusso nods
<tonyyarusso> Would there be anyone I could say to contact for guidance on one other than pitti / would it be appropriate to mention a name?  (UWN)
<Burgundavia> in general, ask around for one of the core devs to look it over
<tonyyarusso> All right, I'll see what I can do with that.  Let me know if you remember anything else.
<Burgundavia> ok
<Burgundavia> MIR are really not that hard
<Burgundavia> it is getting a package that is worth it
<Burgundavia> hey jono
<jono> hey
<Hobbsee> jono!!!!
<jono> hey Hobbsee :)
<jono> Hobbsee: you at LCA?
<Hobbsee> jono: no, but i was at lowenbrau
<jono> Hobbsee: really?
<Gman> mmm, steins of lowenbrau.....
* mjg59 is unsurprised that jono can remember little
<jono> Hobbsee: shame we didnt meet up
<jono> mjg59: :P
<Hobbsee> jono: yes.  i saw you in the room, but you were happily talking, so didnt go up
<Hobbsee> oh, and StevenK and i left at about 11pm
<jono> Hobbsee: come and interrupt next time :)
<jono> right
<Hobbsee> jono: hehe.  i thougth about it.
<mjg59> Hobbsee: You'll be here for the open day?
<Hobbsee> mjg59: yes
<mjg59> Excellent
<Burgundavia> hey mjg59
<Hobbsee> mjg59: i dont know what you look like though, so it's fairly impossible to come say hello
<mjg59> Hobbsee: images.google is your friend
<jono> the legend of Matthew Garrett
<mjg59> Except I have longer hair at the moment
<Gman> look for an angry man trying to avoid fixing everyones laptops
<mjg59> I've fixed no laptops yet!
<mjg59> But I'm helping to run a session on fixing laptops in the kernel miniconf this afternoon
<mjg59> (And desperately trying to write my talk for tomorrow right now)
<Hobbsee> hehe
<Gman> mjg59, how about power management on opensolaris? :)
<Hobbsee> jono: lca is crap for the people who already live in sydney, but not the city :P
<mjg59> Maybe you guys will implement it some day
<jono> heh
<Hobbsee> mjg59: hrm, okay, didnt notice you at lowenbrau then
<mjg59> Hobbsee: Oh, I wasn't there
<mjg59> Sorry, should have been clearer
<Hobbsee> mjg59: ahhhh.  that explains
<Hobbsee> mind you, with 80+ people there, it's understandable that i didnt see you :P
<Hobbsee> even if you were there
<jmg> hi all
<jmg> is there a policy document or something that talks about why ubuntu uses python
<Hobbsee> about *why* ubuntu uses python?
<Hobbsee> or how to package python stuff for ubuntu?
<jmg> why
<LaserJock> Ubuntu doesn't in particular
<LaserJock> there is no policy
<LaserJock> it's just that a lot of people (not just Ubuntu) like it
<jmg> oh
<Hobbsee> because of the libraries for it, and it's an easy programming language, and people like it.
<jmg> i thought there was a pythonise everything policy
<LaserJock> no
<jmg> ok then
<jmg> my mistake
<jmg> im sure ive seen it
<jmg> "why python"
<LaserJock> it's a common one. Mark Shuttleworth likes to push Python as a good programming language
<LaserJock> and we tend to favor it for sure
<LaserJock> but there is no policy
<LaserJock> and we don't intentionally go and rewrite stuff just because it's not Python
<jmg> alright then
<somerville32> :)
<mynameisdeleted> hi
* Hobbsee waves
<mynameisdeleted> who do I email if I want my xubuntu mirror listed in the official mirrors list
<mynameisdeleted> and what are the requirements for that?
<mynameisdeleted> its on gigabit ethernet connected to a datacenter
<mynameisdeleted> so it can provide a full gigabit of bandwidth theoretically
<mynameisdeleted> and it syncs once a day automatically
<Amaranth> hmm
<Amaranth> can't remember who to email, sorry
<_ion> mirrors@ubuntu.com probably
<fabbione> morning
<Burgundavia> morning fabbione
<Hobbsee> heya fabbione!
<pitti> Good morning
<fabbione> yo Martin
<doko> good morning
<Burgundavia> hey doko, pitti
<doko> Mithrandir: please requeue pygresql (all archs) and bzrtools (i386)
<pitti> doko: right, new libpq-dev is in the archive
<pitti> Mithrandir: if you are at it, please give-back qt-x11-free as well (it failed due to the same bug in libpq-dev)
<Mithrandir> doko,pitti: given-back; 
* fabbione waves to the german crowd
<pitti> Mithrandir: thanks
<tepsipakki> Mithrandir: about those sync-requests.. all but one are ack'd now
<tepsipakki> oh wait, I made some new ones yesterday
<Mithrandir> tepsipakki: please don't subscribe ubuntu-archive until they're acked, they'll just clutter the list I use to do them.
<tepsipakki> ok, sorry
<Mithrandir> subscribing ubuntu-archive is akin to saying "please process this report" which we obviously can't do before it's complete.
<tepsipakki> I recall some doc saying that when requesting a sync u-a should be subscribed
<tepsipakki> but can't find it now
<StevenK> Exactly, but not if you're not a MOTU.
<tepsipakki> right :)
<StevenK> If you aren't, request a sync, and the MOTU will ACK it and then subscribe ubuntu-archive
<StevenK> s/the/then/
<Mithrandir> correct.
<fabbione> WHHEEEEEe
<fabbione> between doko and pitti we could have just reupload all of feisty
<fabbione> it would have been faster
<pitti> fabbione: hey, I only had 10 uploads or so
<fabbione> i saw a bunch too from yesterday :)
<doko> fabbione: fewer uploads than for the 2.3->2.4 transition :)
<fabbione> Mithrandir: we need the big green button on LP: "Rebuild world"
<doko> fabbione: just the automated language packs ;-P
<fabbione> oh i am happy if you rebuild everything
<fabbione> it will make more pkgs debuggable on sparc
<fabbione> just upload even more
<fabbione> ALL of the archive
<Mithrandir> fabbione: no, we won't do mass rebuilds and put the resulting binaries in the archive.
<doko> hmm, did the gnomies break things yesterday?
<fabbione> Mithrandir: i know we don't. we should be able with LP adding a proper source entry and reupload the source automatically
<doko> Mithrandir: could you give back revelation? (just on one arch to try my theory)
<Mithrandir> doko: amd64 and ppc had gtk uninstallable for a little while yesterday, yes.
<Mithrandir> doko: given-back on amd64
<Mithrandir> pitti: you asked for an strace sync two months ago, it seems.  It failed to build on i386; would you care to investigate?
<pitti> Mithrandir: oh, sure
<Mithrandir> pitti: also, python-apport-utils is not built any more?
<pitti> Mithrandir: right, that can go away
<mvo> pitti: python-apport-utils is a package that is removed on every upgrade currently
<mvo> that is ok I presume?
<pitti> mvo: then it works correctly :)
<pitti> replaced by python-apport
<Mithrandir> pitti: thanks; removed from the archive.
<pitti> I moved everything into a proper python package now
<mvo> great, thanks
<Mithrandir> dear bzip2 developers.  Please do not call fprintf, nor fclose, nor exit in a signal handler.  Love, Tollef.
<doko> holy crap, how long does it take to tidy a chroot with gnome build-deps installed?
<thom> not long... rm -rf chroot; mkdir -p chroot; debootstrap feisty chroot
<doko> Mithrandir: please requeue revelation on powerpc as well
<doko> Riddell: kde's detection of python versions is so broken ...
<Mithrandir> doko: given-back.
<doko> Mithrandir: please give back papaya on amd64 (gnome ...)
<Mithrandir> doko: not on ppc?
<doko> Mithrandir: hmm, this has still "Needs building", yes, sparc as well
<Mithrandir> rideout: debtags uploaded over a month ago is FTBFS.
<rideout> Mithrandir: what?
<Mithrandir> rideout: oops, tab-completion error.
<Mithrandir> Riddell: debtags uploaded over a month ago is FTBFS.
<\sh> packages with unmet deps, can we still force a rebuild with adding buildY as version add to debian/changelog?
<Mithrandir> \sh: that is the correct way to just do a rebuild, yes.
<pitti> mvo: do you know that current u-manager immediately crashes with a python exception?
<seb128> pitti: I told him yesterday
<seb128> pitti: he blames python-dbus and doko :p
<mvo> pitti: yes, I haven't debugged it yet, but it looks like it was introduced from python2.5 dbus 
<seb128> hey pitti mvo
<doko> mvo: python2.5-dbus is gone
<mvo> heyhey seb128
<seb128> doko: what do you mean, it's using python2.4 again?
<pitti> hey seb128
<pitti> seb128: btw, your patch for bug 58373 changed things for the worse
<Ubugtu> Malone bug 58373 in xorg-server "Blue compiz for PowerPC" [Unknown,In progress]  https://launchpad.net/bugs/58373
<seb128> Mithrandir: could you promote gstreamer-tools binary (from gstreamer0.10 package) so gst-plugins-base0.10 and gst-plugins-good0.10 which Build-Depends on it can build? ;)
<pitti> seb128: instead of a tinted blue screen I now get a completely white screen with compiz enabled
<fabbione> and turned x86* on white
<doko> seb128: python-dbus ;-P
<pitti> fabbione: oh, then it's not just ppc any more
<fabbione> pitti: dunno :) i was trying to give some X hell to seb128 :P
<mneptok> doko: ping
<seb128> pitti: same for everybody apparently, and that's not due to the patch, that has been triggered by the package rebuild
<doko> mneptok: bash pong?
<fabbione> pitti: but i saw several reports
<Mithrandir> seb128: promoted
<mneptok> doko: do you have access to a PPC machine running Edgy?
<pitti> hey hey dholbach 
<seb128> pitti: rebuilding the package without the patches from the new revision does the same :/
<seb128> hi dholbach
<mneptok> doko: (not bash. Java.) :/
<seb128> Mithrandir: thank you
<seb128> Mithrandir: BTW what is libgimme-codec to NEW?
<doko> mneptok: chroot in the data center, nothing more at the moment
<seb128> s/what//
<Mithrandir> seb128: it'll be visible in about an hour.
<dholbach> good morning
<dholbach> hey pitti, hey seb128
<dholbach> mneptok: i do
<mvo> hey dholbach!
<Mithrandir> seb128: libgimme-codec didn't ship a copy of the licence in the orig.tar.gz, it was in the diff.
<dholbach> heya mvo
<seb128> Mithrandir: right, and I uploaded it again like half an hour after the rejected mail
<mneptok> doko: looks like sun-java5-jre on PPC has a dependency on sun-java5-bin(i386)
<seb128> Mithrandir: with the COPYING.LIB to the orig that time
<mneptok> that .... doesn't work so well ;)
<doko> mneptok: sure, please convince sun to release sun-java for ppc, kthxbye ;-P
<Mithrandir> seb128: oh, you just missed my NEW processing yesterday, then.  I'll go look at it when I get bored at fixing stuff from feisty_outdate.txt.
<pitti> doko: hm, pygresql finally built, but not on sparc/ia64
<seb128> Mithrandir: ok thank you, it's needed for EasyCodecInstallation ;)
<mneptok> doko: *gasp* i thought they did that like 8 months ago!?
<pitti> doko: ah, seems that new psql is not yet built there, I'll chase this
<mneptok> doko: pardon the smell of my brain fart. i'll go back under my rock.
<doko> mneptok: np
<pitti> Mithrandir: can you please give-back pygresql on ia64 and sparc?
<Mithrandir> pitti: given-back
<pitti> Mithrandir: and qt-x11-free on powerpc?
<pitti> Mithrandir: merci
<Mithrandir> pitti: qt-x11-free> given-back.
<pitti> argh, a broken bzr push really hurts
<pitti> doko: there's a sync request for paramiko; will the new version fix the Crypto.Util.randpool module or shall I file a bug about that?
<pitti> doko: hm, no, it doesn't
<pitti> doko: ok, I filed a bug and sub'ed lifeless
<pitti> seb128: is it really deliberate that the System menu is so empty now, and I must use this control-center thingy?
<Mithrandir> seb128: http://librarian.launchpad.net/5650834/buildlog_ubuntu-feisty-ia64.evolution-data-server_1.9.5-0ubuntu1_FAILEDTOBUILD.txt.gz ; You are winn0r.  (I have no idea why it fails there, but please check)
<doko> pitti: thanks
<seb128> Mithrandir: gtk-doc b0rked on ia64
<seb128> pitti: yep
<Mithrandir> seb128: ugh.  Any idea if/when it'll be fixed?
<seb128> pitti: that's the way to not get those crowded menus we had
<pitti> seb128: :-(
<pitti> seb128: and now we get a crowded c-c where it takes even longer to find stuff
<seb128> Mithrandir: it's b0rked for months, probably not soon, my usual workaround it to not build the documentation during the build since they ship it with the tarball anyway
<pitti> and not even with admin/user stuff clearly separated
<seb128> Mithrandir: I'll change that, we probably made it build when we synced with Debian
<Mithrandir> seb128: ok, thanks.
<seb128> pitti: categories are going to be fixed, they are not set correctly for many items atm
<Mithrandir> fabbione: you are the winner of a graphviz build failure on sparc; bus error.  Care to investigate?
<seb128> pitti: and when you open the shell the focus is on the search entry to filter
<seb128> pitti: just type there :p
<pitti> seb128: ok, I bow to the power of approved specs (I assume?), I still don't like it :)
<seb128> pitti: no, that's the power of upstream
<pitti> ("What is a GNOME and why should I control it?")
<seb128> pitti: there is a bug open about the item name, it's going to be fixed
* pitti registers pitti-wants-preferences-menu-back spec
<seb128> :)
* pitti hugs seb128
* seb128 hugs pitti back
<seb128> pitti: it's probably not that hard to get a menu back, the problem is that you will get submenus for the categories
<seb128> pitti: having the menu is just a matter of changing /etc/xdg/menus/*.menu
<pitti> seb128: what's your preference?
<pitti> if I'm the only one who doesn't like it, I just shut up
<seb128> pitti: well, we are trying to "solve" the crowded menus problem for some time and the new shell is what Novell did after doing usability studies, etc
<seb128> pitti: so I would give a chance to the new way, though I'm used to the menus and I find them easier to use atm
<pitti> seb128: but now it's one entry ("GNOME c-c") instead of two (prefs and admin), and the system menu itself got less useful
<seb128> pitti: well, the shell has categories
<seb128> pitti: we could do one "admin" category
<pitti> Mithrandir: ugh, that strace thing really sucks, will take me a while
<Mithrandir> pitti: sure, no hurry for me,  I just noticed it was out of date.
<fabbione> Mithrandir:  i already did and there is a but open for it
<fabbione> Mithrandir: and no, i am not the winner
<fabbione> Mithrandir: https://bugs.launchpad.net/ubuntu/+source/gs-esp/+bug/76749
<Ubugtu> Malone bug 76749 in gs-esp "[SPARC/feisty]  gs-esp BUS ERROR" [High,Unconfirmed]  
<fabbione> Mithrandir: that causes graphiz to FTBFS
<fabbione> Mithrandir: and it's easy to reproduce on faure. so Ian or whoever can fix it
<Mithrandir> it's still a sparc-only bug, so you win anyway. :-P
<fabbione> Mithrandir: nope.. i don't
<fabbione> i swear.. i don't
* mvo grumbles about broken python-dbus with python2.5
<dholbach> mvo: works in underway on the debian dbus experimental package afaik
<dholbach> mvo: at least smcv told me that
<mvo> dholbach: do you have more details? it looks like the real problem is pyrex
<pitti> Mithrandir: strace FTBFS fix uploaded
<dholbach> mvo: that's what smcv said too
<dholbach> mvo: he said he's working on it and will upload it to experimental
<dholbach> mvo: he's on #telepathy if you want to talk to him
<Mithrandir> pitti: yay you!
<mvo> dholbach: I'm testing a paatch currently, lets see if that one works
<dholbach> mvo: ROCK
<fbenites> hi!
<fbenites> i want to use skas to build the ubuntu-kernel, does someone have experience with it?
<cjwatson> mynameisdeleted: mirrors@ubuntu.com; information at http://www.ubuntu.com/download/mirror
<mvo_> dholbach: hrm, patch not working. *grumpf*
<fabbione> iwj: could you please look at bug #76749 ? i don't know the code base there....
<Ubugtu> Malone bug 76749 in gs-esp "[SPARC/feisty]  gs-esp BUS ERROR" [High,Unconfirmed]  https://launchpad.net/bugs/76749
<fbenites> why does ubuntu not support skas? 
<mneptok> huh?
<iwj> fabbione: Sure, but I think it actually needs debugging.  I'll assign it to me.  Is it urgent to investigate ?
<fabbione> iwj: Mithrandir keeps bugging me about graphiz that FTBFS on sparc because of that.. 
<fabbione> Mithrandir: ^
<fabbione> iwj: it's reproducible on faure easily
<Mithrandir> fabbione: seriously, I don't "keep bugging you", I've asked you once about it.
<Mirv> mvo_: is the fix for bug #68553 going to be in dapper or not? update from 6.06 LTS to 6.10 is apparently still breaking for anyone using Finnish locale
<Ubugtu> Malone bug 68553 in update-manager "Dapper upgrade to Edgy: Frozen dist-upgrade and failed second run (in finish locales" [High,Confirmed]  https://launchpad.net/bugs/68553
<fabbione> Mithrandir: twice :P
<fabbione> Mithrandir: but no.. you don't bug me..
<fabbione> there was some hirony there...
<fabbione> sorry if it was not spottable
<Mithrandir> fabbione: no, I did it once.  Colin did so too before xmas, but I'm not cjwatson.
<fabbione> well you are all RM's :)
<fabbione> same team
<iwj> Mithrandir: So is it urgent ?  You should bug me about it now instead of fabbione :-).
<Mirv> (your one line working fix for python-apt was at http://librarian.launchpad.net/4937800/dist-upgrader-fix-68553.diff )
<fabbione> iwj: thanks for looking at it
<Mithrandir> iwj: no, it's not urgent, but I don't count on people reading http://people.ubuntu.com/~cjwatson/testing/feisty_outdate.txt and being able to interpret the output there.
<iwj> Mithrandir: Err, I'm not sure I follow the relevance of feisty_outdate.txt ...
<Mithrandir> iwj: it shows that graphviz is out of date on sparc, which in this case is due to it failing to build on sparc due to the beforementioned bug.
<iwj> Mithrandir: OIC
<mvo_> Mirv: I preare a SRU for it now
<Mithrandir> and I'd so much rather have ftbfs bugs fixed early rather than late; experience shows they're not fixed in the last month when we're in a rush.
<iwj> Mithrandir: Right.  I'll take a look at it today.
<Mithrandir> iwj: excellent, thanks.
<mvo_> Mirv: it should be fixed with the latest language-pack update though. strnage
<Mirv> mvo_: well, maybe I heard it from someone who hasn't updated his dapper. I should probably test it myself, then.
<mvo_> Mirv: having this python-apt bug fixed is still a good idea
<Mirv> mvo_: probably, as it's no-risk anyway
<Mithrandir> SRUs are never no-risk.
<seb128> Mithrandir: do we know when http://people.ubuntu.com/~cjwatson/testing/feisty_outdate.txt has been generated?
<seb128> Mithrandir: it lists "control-center 1:2.17.5-0ubuntu4 gnome-control-center-dev(i386/all) 1:2.17.1-0ubuntu2 from 1:2.17.1-0ubuntu2" by example where the package has built some days ago and is available
<seb128> ah
<seb128> hum, no
<seb128> that package has been renamed
<Mithrandir> seb128: yes, the gnome-control-center-dev binary package is no longer built.
<seb128> right, why is it listed?
<seb128> not built from source should be dropped no?
<Mithrandir> because the binary hasn't been removed yet.
<Mithrandir> yes, but it's done when an archive admin gets around to it, it's not done automatically.
<seb128> that requires manual work?
<seb128> ah ok
<seb128> makes sense then
<Mithrandir> yes (intentionally)
<seb128> I though the archive was clever enough to clean things not built from source
<\sh> I just asked it on #ubuntu-kernel but does anyone know why UTS_RELEASE is not set anymore in /usr/include/linux/version.h from linux-libc-dev ?
<Mithrandir> no, it's done by hand, which is how we want it.
<seb128> ok
<Mithrandir> cjwatson: could we have a timestamp at the top or bottom of feisty_outdate.txt?
<mvo_> doko_: will openoffice.org-l10n-km come back at some point? or is it gone forever? 
<Mirv> Mithrandir: yes, right about that "never no-risk" thing, though that one line patch seems like quite near that
<cjwatson> Mithrandir: sure, give me a minute
<cjwatson> Mithrandir: (there's a timestamp on feisty_probs.html)
<Mithrandir> cjwatson: sure, no hurry
<cjwatson> Mithrandir: done for next update
<Mithrandir> thanks
<seb128> hum
<seb128> why does feisty_probs lists that:
<seb128> rhythmbox 0.9.6-0ubuntu4 produces uninstallable binaries:
<seb128>     * rhythmbox-dbg (amd64 i386 powerpc sparc) 
<seb128> where rhythmbox version is 0.9.7-0ubuntu4 to feisty
<fabbione> seb128: does rhythmbox-dbg exists from 0.9.7 ?
<seb128> fabbione: no, we have -dbgsym packages now, I've stopped adding -dbg packages were Debian didn't have them
<cjwatson> seb128: because rhythmbox-dbg is still in the archive and hasn't been NBS-removed yet
<fabbione> seb128: that's probably why
<cjwatson> you can ignore that
<fabbione> it needs NBS.. as cjwatson just wrote faster than me
<seb128> ok
<seb128> cjwatson, fabbione: thank you
<cjwatson> Mithrandir: I'm just going to do a quick Ubuntu/alternate respin so I can progress with intel-mac-support today; hope that's ok
<Mithrandir> cjwatson: oh, sure, I'm in archive-admin mode today, it seems.
<mvo_> pitti: can we remove the openoffice.org-l10n-km dependency from langauge-support-km? openoffice.org-l10n-km is currently not in the archive (doko will know if it is just temporarly removed or not)
<pitti> mvo_: sure, no problem
<mvo_> thanks
<pitti> doko: please confirm?
<mvo_> it currently breaks my "try-to-upgrade-all-of-main" testcase. not that bad, but I would prefer to be able to keep testing :)
<pitti> mvo_: will do once doko confirms
<doko> pitti, mvo_: confirmed
<iwj> mvo_: Did you see my mail about apt-ftparchive and signing ?  If you could point me to the docs if there are any that would be very nice ...
<seb128> doko: do you reply to questions about python-support? ;)
<doko> seb128: yes. just one answer
<doko> how to convert to python-central ;-P
<seb128> doko: I'm trying to look at your bug about python-vte, but I'm not sure what the problem is
<seb128> is that because debian/pyversions contains "2"?
<seb128> should it be 2.4-?
<doko> rm -f debian/pyversions; sed s/python-support/python-central/g debian/*
<seb128> I don't fancy diverting from Debian when not required
* Mithrandir notes that syncing 165MB orig.tar.gz files takes a while
<mvo_> iwj: sorry that I have not replied yet, I will answer it right after lunch
<davmor2> you might want to keep your eyes on gossip telepathy it is crashing out when I try to add an account for irc.
<davmor2> bug has been sent to both malone and upstream
<Zdra> ah, davmor2, did you tried last package update of gossip-telepathy ?
<iwj> mvo_: NP.
<iwj> mvo_: I've got plenty else to be getting on with :-).
<davmor2> Zdra:  Did a dist-upgrade about 20 minutes ago is that up-to-date enough?
<davmor2> Just checking again
<Zdra> davmor2: and please install debug package before reporting crash, like said on the page I gave you: http://telepathy.freedesktop.org/wiki/Gossip
<Zdra> davmor2: dholbach uploaded it recently, don't know if it's already build
<davmor2> Gnome had already asked me to do that with the first bug I reported
<davmor2> Zdra: please check http://bugzilla.gnome.org/show_bug.cgi?id=397220
<Ubugtu> Gnome bug 397220 in General "crash in Gossip Instant Messenger: trying to set up an irc ..." [Critical,Unconfirmed]  
<Zdra> btw, ubuntu guys, the most important thing to change in apport and bugbuddy is to refuse trace with unknown symbols, or install -dbgsym package automatically, or whatever :D
<davmor2> only effect my irc and not gmail
<Zdra> davmor2: jabber account is different
<seb128> Zdra: apport attach the coredump which allow to get a debug backtrace with apport-retrace
<pitti> Zdra: we won't download/install -dbgsym packages automatically, that would be a huge pain for the user
<Zdra> seb128: oh, very good to know, thanks !
<seb128> Zdra: and bugzilla.gnome rejects empty backtraces now
<pitti> Zdra: right, what seb128 says; the initial stacktrace is only for automatic dup finding, etc, we can get a better one
<Zdra> davmor2: ok so you have the choice, install debug packages and post a useful bt or attach the apport file that I can retrace...
<Zdra> but I'm 99% sure your bug is already fixed :)
<pitti> mvo_: new l-support-km uploaded
<mvo_> thanks pitti
<davmor2> Zdra: just got this in terminal ** (gossip:22675): WARNING **: GossipAccount has no parameter named `\u0003'
<davmor2> ** (gossip:22675): WARNING **: GossipAccount has no parameter named `\u0003'
<Zdra> davmor2: that's clearly things that is now fixed, I'll close your bugs, if you can reproduce it with today's gossip-telepathy package please reopen ;)
<davmor2> thanks for clearing that up then I'll just wait for the update
<seb128> doko: feel free to fix vte as you prefer, I don't know what to change and since you don't want to reply to my question :p
<doko> seb128: I would have to look myself
<seb128> doko: you don't know how python-support work?
<seb128> doko: do you have to list versions like "2.4-"? Does that mean than all the source packages will need to be changed when we drop python2.4?
<doko> seb128: maybe, maybe not. python-support did decide to hardcode versions in debian/*, so that you have to look at the package source, instead of looking into the Packages and Sources files
* Mithrandir looks around for a victim^WMOTU.
<seb128> doko: why is not the set of version defined by python-default or something like that?
<doko> seb128: because the author of python-support changes things when he likes; and apparently he now dislikes pyversions. grep the python-support package for other fucked up stuff -> grep -r doko .
<seb128> doko: ok, thank you, maybe using pycentral is not a bad idea then :p
<davmor2> Zdra:  32bit version just updated and now gossip works :).  Thanks for the help.
<crimsun> rodarvus: ping, may I upload a no-change rebuild of mesa to fix bug 79196?
<Ubugtu> Malone bug 79196 in xorg-server "xserver-xorg-core_1.1.1-0ubuntu13_i386 breaks compiz/beryl (white screen)" [Low,Needs info]  https://launchpad.net/bugs/79196
<crimsun> rodarvus: it's incorrectly assigned to xorg-server there; it's not an issue in that source package. I've confirmed locally that a simple rebuild of mesa resolves the issue.
<rodarvus> its quite interesting that a simple rebuild of mesa fixes this problem, but sure, go ahead.
<crimsun> rodarvus: thank you!
<rodarvus> np
<Amaranth> yay
<sivang> morning
<sivang> Amaranth: would you happen to know what to do (I'm on fesity) if none of the apps can get name->ip resolution but dig and nslookup operate without problems ? resolve.conf also has the right nameserver values and I'm using network manager, which up until I did apt-get autoremove everything worked flawlessly
<Amaranth> hrm
<Amaranth> don't suppose you remember what got removed
<sivang> Amaranth: very odd, feels like something wrong with libc or so (or the resolver lib)
<Amaranth> might be zeroconf related
<sivang> Amaranth: hmm, interesting, because it's very odd that the NS settings are dead correct still, no app can resolve
<Amaranth> but i wouldn't think so if nslookup worked
<sivang> it works no prob
<sivang> never seend something like that beofre :)
<fabbione> sivang: if resolver in glibc was broken we would have noticed
<sivang> but it's very annoying
<fabbione> check /etc/nsswitch.conf ? (or something like that?)
<fabbione> perhaps it's broken?
<sivang> fabbione: let me check
<Amaranth> the only thing that sticks out to me is libresolv.so.2 but i know nothing about this stuff :P
<sivang> fabbione: okay, how should it look? mine is as I paste you in pm
<sivang> (can't use pastebin, no resolution here for the browser)
<Mithrandir> there, 51 bugs closed.
<Mithrandir> doko: please don't file bugs about NBS-es, we get to them as part of the regular archive admin work.
<seb128> for some value of "regular" ;)
<Mithrandir> seb128: careful, or I'll enlist you. :-)
<seb128> Mithrandir: well, rhythmbox-dbg has been dropped months ago I think
<seb128> but right ;)
<doko> Mithrandir: ok, but these pop up for python2.4 deps, which is a bit annoying
<Mithrandir> doko: actually, feel free to file for stuff in universe, since _outdate seems to only list main.
<crimsun> Mithrandir: thanks for the syncs
<Mithrandir> doko: but when you file bugs, please file one bug per source package, don't bunch them like you did in one report, please.
<niooi> Hi
<niooi> Please to all the developpers, first of all thanks for your work, second, that would be good if you would leave a CLI installation method on ubuntu. Why? For instance, I have a TV as a monitor and I cannot launch the install process I get a blank or red screen.
<PuMpErNiCkLe> niooi: Have you tried the alternate install cd?
<seb128> hum
<seb128> $ dpkg -L python-vte | grep vtemodule
<seb128> /usr/share/python-support/python-vte/gtk-2.0/vtemodule.la
<seb128> /usr/share/python-support/python-vte/gtk-2.0/vtemodule.a
<seb128> /usr/lib/python-support/python-vte/python2.5/gtk-2.0/vtemodule.so
<seb128> does that looks wrong to somebody else?
<seb128> doko: should .a and .la installed for python modules like that? to /usr/share?
<Riddell> mvo_: see my /msg?
<doko> seb128: no
<seb128> doko: should I drop the .la and the .a or only the .la or none?
<doko> seb128: both, we cannot load static libs
<seb128> ok
<iwj> Hmm.  I really want gpg to support HMAC as an ahem public key ahem signature algorithm.
<niooi> PuMpErNiCkLe, thanks I never understood what was the alternate CD.
<niooi> It means I can install it in CLI mode?
<niooi> That's great
<Riddell> carlos: how would you feel about renaming some KDE translation files on export to ubuntu?
<carlos> Riddell: which kind of rename?
<Riddell> carlos: the upstream extragear KDE apps have translation files named e.g. desktop_extragear-graphics_gwenview, but they need to be exported to just gwenview
<carlos> Riddell: so the .po files are named desktop_extragear-graphics_gwenviewSOMETHING.po ?
<carlos> Riddell: that's fine, what sets the name of the exported file is the translation domain
<carlos> Riddell: so it's just a matter of having it set properly
<Riddell> carlos: set in launchpad?
<carlos> Riddell: yes
<carlos> Riddell: is it for Feisty only?
<Riddell> carlos: yes
<carlos> hmm
<carlos> Riddell: gwenview also exist in dapper and edgy
<seb128> carlos: hi
<carlos> seb128: hi
<seb128> carlos: any news on feisty opening to rosetta?
<carlos> seb128: we are going to do performance tests to be sure that will not make it worse for launchpad timeouts
<carlos> and we will do them
<seb128> ok
<carlos> will do them == Feisty opening
<seb128> do you know when that is planned?
<seb128> like for when we can expect it to be done?
<carlos> sometime between this week and next week
<carlos> I hope to know it tomorrow
<carlos> based in our testing, stub will see the best time to shutdown launchpad for 3 hours or so to do the opening
<seb128> ok
<seb128> thank you
<Riddell> carlos: mm, actually it may not be an issue, let me look into it more
<carlos> Riddell: https://launchpad.net/ubuntu/edgy/+source/gwenview/+pots/desktop-extragear-graphics-gwenview
<seb128> doko: "#! python -OOt", is that a typo?
<carlos> Riddell: https://launchpad.net/ubuntu/dapper/+source/gwenview/+pots/gwenview and https://launchpad.net/ubuntu/edgy/+source/gwenview/+pots/gwenview
<seb128> doko: fixed (that was alacarte)
<Amaranth> eh?
<seb128> Amaranth: bug #79545
<Ubugtu> Malone bug 79545 in alacarte "cannot launch from terminal" [High,Fix released]  https://launchpad.net/bugs/79545
<siretart> Mithrandir: doko: could anyone of you look why http://librarian.launchpad.net/5726711/buildlog_ubuntu-feisty-i386.python-debian_0.1.0_FAILEDTOBUILD.txt.gz FTBFS? - I think it is not a problem in the package but on the buildd
<Amaranth> seb128: oh, that
<seb128> Amaranth: doko changed alacarte to build with PYTHON=python (non versionned)
<Amaranth> i just noticed that, actually
<seb128> Amaranth: I changed it to PYTHON=/usr/bin/python
<Amaranth> yeah, it put a space in the shebang
<Amaranth> or did i do that? :)
<Mithrandir> siretart: you need to build-depend on python-dev
<Amaranth> either way, cool, fixed :)
<seb128> Amaranth: is "#!python" correct?
<Amaranth> no
<seb128> ok
<seb128> then my change to /usr/bin/python is correct ;)
<Amaranth> yeah
<siretart> Mithrandir: err, so the package built in debian by sheer luck?!
<Amaranth> btw, one problem with the change to gnome-control-center
<siretart> or is there someting special in feisty's python?
<Mithrandir> siretart: unsure, but this is not a problem on the buildd, it's a bug in the package.  Just build-depend on python-dev
<Amaranth> if someone changed/added things with alacarte they'll get incomplete Preferences and Administration menus along with the control center item
<siretart> Mithrandir: okay, willdo. thanks
<cjwatson> seb128: #! /usr/bin/env python is commonplace too
<Riddell> enrico: do you have any ideas about this debtags build failure?  it seems to be missing some includes https://launchpad.net/+builds/+build/282888
<Riddell> enrico: I think LIBEPT_CFLAGS isn't being defined
<seb128> Amaranth: you have time to fix that before feisty ;)
<seb128> cjwatson: right
<Amaranth> seb128: the fix would be to remove files from ever user's $HOME
<Amaranth> seb128: not a good idea
<Amaranth> every*
<Riddell> StevenK: or maybe you know?
<seb128> Amaranth: hum, no, not really :/
<Amaranth> seb128: or you could change settings.menu to some other name so ~/.config/menus/settings.menu doesn't merge with it
<Amaranth> that's gnome-menus stuff
<seb128> right, would be nice to do upstream though
<Amaranth> yeah
<Amaranth> there is a valid reason for keeping the same name though
<Amaranth> compatibility with 3rd party changes (like alacarte's)
<enrico> Riddell: let's see
<enrico> Riddell: /build/buildd/debtags-1.6.6ubuntu1/./configure: line 19555: LIBTAGCOLL2_DEFS: command not found
<enrico> /build/buildd/debtags-1.6.6ubuntu1/./configure: line 19556: LIBEPT_DEFS: command not found
<enrico> Riddell: whoever run automake on the package didn't have libtagcoll2 and libept installed
<enrico> (well, libtagcoll2-dev and libept-dev)
<enrico> Riddell: because those packages provide the m4 macro files that are used to expand those _DEFS entries in the configure.ac
<enrico> Riddell: but this isn't a problem of build-dependencies: it's a problem of when the .orig.tar.gz has been made
<Riddell> enrico: so I could try with the .tar.gz from debian
<Riddell> enrico: ah, rerunning autogen seems to have helped, many thanks
<enrico> Riddell: you're welcome
<Riddell> Mithrandir: could you give back mailody on powerpc please
<bddebian> Heya
<Mithrandir> Riddell: given-back
<Riddell> Mithrandir: could you give back kdemultimedia too, libtunepimp should be in the archive now
<Mithrandir> Riddell: given-back
<Riddell> thanks
<doko> seb128: thanks
<seb128> doko: np ;)
<pirast> slomo, could you have a look at bug 79557 (about backporting)?
<Ubugtu> Malone bug 79557 in sword "Please backport sword-1.5.9 from Feisty to Edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79557
<Mithrandir> pirast: I'll reject it, it should be fixed in a stable release update.
<pirast> Mithrandir, okay.. :-(
<Mithrandir> why the :-( ?
<pirast> Mithrandir, Misunderstood what you meant with "it should be fixed in a stable release update".. What do you mean with that?
<Mithrandir> pirast: read https://wiki.ubuntu.com/MOTU/SRU
<pirast> Mithrandir, okay..
<doko> dholbach: you're not a C++ developer, only 1GB RAM, fix it!
<dholbach> doko: I know I'm not :)
<davmor2> quick query is todays 32 bit gossip-telepathy going to be made available for 64bit systems?
<tepsipakki> Mithrandir: now I know why ubuntu-archive was subscribed to those sync-requests.. because requestsync does that for you, MOTU or not :)
<dholbach> davmor2: it didn't build yesterday because the chroot wasn't ready
<dholbach> davmor2: it built today: https://launchpad.net/ubuntu/+source/gossip-telepathy/0.23~svn20070116-0ubuntu1
<dholbach> davmor2: so nothing to worry about
<davmor2> so probably on the servers tomorrow then?
<dholbach> "in a bit" i guess
<dholbach> davmor2: http://librarian.launchpad.net/5767440/gossip-telepathy_0.23%7Esvn20070116-0ubuntu1_amd64.deb if you need it urgently
<davmor2> thanks I just like to use gossip over gaim.  It has it's downsides (like not being able to type /join ....)  but ease of use seems nicer than gaim.
<davmor2> just arrived on the server anyway thanks
<geser> Mithrandir: please give-back wxwidgets2.6 on amd64. thanks
<doko> pitti: could you extend dh_clean, so that the debug packages that you build are cleaned as well?
<pitti> doko: hm, it should automatically clean up after itself in dh_strip already
<pitti> doko: if it doesn't can you please file a bug with the package that this happens with?
<doko> pitti: just seen in glom (the version I uploaded)
<pitti> Riddell: oh, how convenient; the changed method in the xpdf source is private
<Riddell> handy
<doko> Mithrandir, Riddell: any known installation problems with libqt3-mt-dev on ia64?
<Riddell> doko: I see that kdemultimedia failed to build on ia64 only because it couldn't install kdelibs, I don't have a machine to look into why
<pitti> Riddell: oh, care to upload all the koffice and kpdf packages?
<pitti> Riddell: I need them relatively soon in order to publish them still today, and I'll be on vac from tomorrow on
<Riddell> pitti: doing
<\sh> Mithrandir: syncing from debian experimental is possible, right?
<cjwatson> \sh: yes, we can sync from anything with a Sources file
<\sh> cjwatson: thx.
<pitti> Riddell: kdegraphics arrived, but no koffice
<Riddell> pitti: 1 koffice is up, 2 still to go
<Riddell> debuild -S  takes a long time on koffice
<tkamppeter> pitti, ping
<Riddell> pitti: all up
<pitti> tkamppeter: hi! I'm semi-away from my computer ATM, will return and answer scrollback soon
<pitti> Riddell: great
<tkamppeter> pitti, I have my home ADSL now, so I will come to the IRC more often again.
<tkamppeter> pitti, how is it going with printerdrake? Was the info which I provided helpful? Feel free to ask me if you need more help.
<seb128> Mithrandir: could you sync serpentine (bug #79611), the current package doesn't work due to the python transition
<Ubugtu> Malone bug 79611 in serpentine "Please sync serpentine (main) from unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/79611
<niktaris> cjwatson, hi
<cjwatson> niktaris: hi
<niktaris> cjwatson, long time no see. hope all is Ok. (no questions tonight :))
<jwendell> pitti, language packs for feisty are outdated, right?
<cjwatson> blink, this hardware detection hang is weird - I hadn't seen it up close and personal before
<cjwatson> udevsettle seems to be causing udevd to sit and swivel
<cjwatson> and spawn lots of [kstopmachine]  kernel threads
<pitti> jwendell: right, I'm still waiting for Rosetta to export feisty packs
<pitti> tkamppeter_: ah, great; how was the moving?
<pitti> tkamppeter_: I did't touch printerdrake recently
<jwendell> pitti, and your repository? is it feisty ready?
<pitti> jwendell: yup, as soon as Rosetta exports a tarball, I'll build dailies
<pitti> jwendell: and of course upload them to feisty ASAP
<jwendell> pitti, so, is there a bug in rosetta?
<pitti> jwendell: well, it's certainly not 'right' that it takes so long
<pitti> jwendell: but I don't know the details
<seb128> pitti: rosetta will need to know about feisty first, that's still not the case :/
<pitti> seb128: carlos told me Friday that they would shut down daily exports to open feisty, so I'm hopeful :)
<seb128> pitti: he told me this morning that they will probably open it this week or next week
<carlos> pitti: unfortunatelly, I'm a bit behind my schedule on that testing... I hope tomorrow we will know the exact date we will have that done (anytime between this week and next week)
<pitti> carlos: next week would be great, I'm on vac tomorrow
<carlos> if you, the distro team doesn't have any important milestone this week, it should happen this week (or at least I hope it)
<jwendell> pitti, when you back?
<pitti> jwendell: yes, when we're at the distro sprint
<carlos> pitti: oh, right, the distro sprint...
<carlos> is it next week?
<mdz> mjg59: ping
<simira> carlos: yes
<seb128> carlos: yep, next week
<carlos> so either we open feisty for translations this week or we wait for the week after the sprint (we need to shutdown launchpad for a couple of hours, and I don't think is a good idea when you are using it a lot)
<seb128> I would say that shutting it for some hours during european night time would be fine
<seb128> carlos: we are not likely to work during the night during the sprint
<seb128> and distro team will be at european time
<carlos> seb128: ok, anyway, I will try to get it done this week
<carlos> I need to leave now
<seb128> good
<carlos> enjoy!
<seb128> have a nice evening
<carlos> thank you. Same for you
<jwendell> where do i find information about that 'distro sprint'?
<simira> jwendell: I don't thing there's any official info about it, actually. Just that it is.
<pitti> jwendell: it's mainly about the distro team coming together for a week to hack on finishing features
<pitti> jwendell: it's mainly an internal event, no exciting things for guests, etc.
<jwendell> ah, thanks
<sistpoty> Mithrandir: can you do me a favor and sync of wordpress? (bug #79171)
<Ubugtu> Malone bug 79171 in wordpress "please sync wordpress (2.0.6-1) from unstable/main to universe" [High,Unconfirmed]  https://launchpad.net/bugs/79171
<geser> mdz: we should now change the maintainer field in source packages. should original-maintainer also appear in the .dsc or only in the debs?
<tonyyarusso> pitti: If you have a moment, I was wondering if you could look over the piece I just wrote for the UWN (to be released tomorrow), on the process for promoting packages to main.  It's at https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue28#head-5ef344ed8ef53d09966947d336183d9fd74e31fc.  Any feedback or corrections would be great!
<pitti> tonyyarusso: I'll look in some minutes
<tonyyarusso> pitti: Thanks.
<pitti> carlos: can you please have a look at bug 79589? any idea why files disappeared from the tarball?
<Ubugtu> Malone bug 79589 in language-pack-gnome-es "language-pack-gnome-es not fully translated" [High,In progress]  https://launchpad.net/bugs/79589
<saispo> anyone can explain me what /usr/sbin/gnome-pty-helper do ?
<seb128> doko_: what package is responsive to changing python to point to the new default version?
<mvo> seb128: the source package is python-defaults iirc
<pitti> tonyyarusso: sounds great in principle, just some thoughts
<tonyyarusso> pitti: Listening.
<pitti> tonyyarusso: first, please drop the part with mailing ubuntu-devel@
<pitti> tonyyarusso: usually it's just noise, and I'll start a discussion if I deem a package not appropriate
<tonyyarusso> pitti: Ah, okay.
<pitti> tonyyarusso: also, the 'sit back and wait' could be augmented with sth. like 'if it's urgent and you feel forgotten, poke pitti in #ubuntu-devel' :)
<tonyyarusso> noted
<pitti> tonyyarusso: great, I'm looking forward to the newxt UWN
<tonyyarusso> pitti: Me too :)  Thanks for your time.
<shawarma> saispo: /win 2
<shawarma> Doh... sorry.
<shawarma> saispo: gnome-pty-helper creates pty's for libzvt2. why?
<shawarma> Would it be possible to bribe someone to look at a request of mine in the request tracker? Be warned: It's got to do with mailman. :-)
<somerville32> shawarma, Ask in #canonical-sysadmin
<shawarma> somerville32: On my way. Thanks.
<somerville32> np
#ubuntu-devel 2007-01-17
<mdke> how can I grep through a bunch of files for a string ("String X") and replace each occurrence of it with another one ("String Y")?
<azeem> uhm, sed?
<bhale> sed -i yourfile -e "s/StringA/StringB/g"
<_ion> in zsh, for f in foo bar quux; sed -i -e 's/String X/String Y/g' "$f"
<bhale> be sure to escape anything fishy
<bhale> in your strings
<_ion> In other shells, add 'do' and '; done' around the sed expression.
<mdke> bhale: they are urls, so have / symbols, are those fishy?
<mdke> also - and .
<_ion> s#foo#bar# and escape . with \
<_ion> (In the regex, not in the replacement)
<mdke> I need it a bit more spoonfed than that, can you add that into bhale's expression?
<bhale> sed -i foo -e "s#http:\/\/youurl.com#http:\/\/yoururl2.com#g"
<mdke> whoosh
<bhale> escape the . also
<bhale> with \
<shawarma> bhale: No. You don't have to escape the slahes when you separate with #.
<bhale> hm yeah
<bhale> duh
<shawarma> sed -i yourfile -e "s#StringA#StringB#g"
<mdke> here's an example url, does anything need to be changed from shawarma's expression, or can I plug that into StringA? http://www.debian.org/releases/edgy/example-preseed.tx
<mdke> (+t)
<bhale> escape all .'s
<shawarma> sed -i yourfile -e "s#http://www.ubuntulinux.org/#http://www.ubuntu.com/#g"
<bhale> debian\.org
<shawarma> bhale: Oh, right.
<shawarma> Well, it's unlikely to cause trouble if he doesn't do it.
<_ion> Never count on that. :-)
<mdke> ok, I'll compile an expression and check it with you guys
<bhale> yeah its a regex for "any character"
<bhale> worth escaping
<shawarma> mdke: the thing is that dots are wild, so wwwadebianborg would match, too.
<mdke> oh, ok
<mdke> and don't i need grep in there too?
<shawarma> mdke: Nope.
<mdke> it's a bunch of files in a few directories
<shawarma> any sort of pattern in the filenames?
<shawarma> Like */*.html ?
<mdke> yep
<shawarma> Ok, then:
<shawarma> for file in */*.html; do sed -i "$file" -s 'yourexpressionfrombefore' ; done
<shawarma> er..
<mdke> shawarma: that looks into subdirectories?
<shawarma> for file in */*.html; do sed -i "$file" -e 'yourexpressionfrombefore' ; done
<shawarma> mdke: Not recursively. Only one level down.
<mdke> one is enough
<mdke> thanks
<shawarma> Any time.
<shawarma> Grab a backup of the files first. Just in case.
<_ion> shawarma: -i.backup
<mdke> yes, I have those
<shawarma> _ion: Really? then sed -i.backup -e 'asdfasdfasdf' */*.html   should work too.
<_ion> Ah, true, it indeed does accept multiple file parameters.
<shawarma> _ion: I'd expect it to if the -i is just a general parameter.
<shawarma> _ion: I just always treated it as an 'apply the magic to the next argument' sort of option. :-)
<_ion> For recursive search, you could say **/*.html in zsh. In bash, you'd probably need find -name '*.html' -print0 | xargs -0r sed blahblah
<mdke> ok, here's my creation
<mdke> or rather, you guys' creation
<mdke> for file in */*.html; do sed -i "$file" -e "s#http://www\.debian\.org/releases/edgy/example-preseed\.txt#https://help\.ubuntu\.com/6\.10/ubuntu/installation-guide/example-preseed\.txt#g"
<mdke> whoops, forgot the done 
<shawarma> Looks sensible.
<_ion> Don't escape the dots in the replacement, only in the regexp.
<shawarma> Doesn't matter.
<mdke> oh
<mdke> let's get this right :)
<_ion> shawarma: Usually you shouldn't feed programs erroneous input just because they happen to ignore it. :-)
<mdke> seems to have gone alright
<mdke> thanks again bhale, shawarma, _ion 
<shawarma> np
<shawarma> _ion: I wouldn't exactly call it erroneous. superfluous, perhaps. 
<shawarma> _ion: I'm just escaping a character in no need of escaping.
<concept10> does every gtk app use a .gtkrc ?
<mdz> isn't acpi-support in bzr somewhere?
<jdong> mdz: http://people.ubuntu.com/~thom/bzr/acpi-support/ , but that's ancient :D
<bddebian> Heya
<jwaddell> hello
<bddebian> Hello jwaddell
<jwaddell> anything exciting going on?
<bddebian> Not here, I'm just a schlub :_)
<jwaddell> what, schlub's can have excitement too?
<bddebian> Probably, but not this one :-)
<jwaddell> I'll just asume that you prefer it htat way then ;)
<bddebian> heh
<malex> Hello. I wonder what could be wrong with the dapper archive since the debootstrap from edgy cannot create a pbuilder chroot for the dapper. It attempts to install a dependency from universe (libdb1-compat) and an unknown package (slang1a-utf8) and fails when it cannot find them in the main archive. Pleas help. I need a dapper pbuilder chroot to build a package for ubuntu users as a courtesy.
<malex> edgy pbuilder chroot gets created without problems and functions just fine by the way.
<Mez> libdb1-compat has no rdepends
<malex> Mez: Which makes it problematic. I wonder what could be broken - bootstrep's dapper script, ubuntu dapper archive, something else?
<malex> I'd like to paste 4 lines of the output if that's ok.
<malex> I: Resolving dependencies of base packages...
<malex> I: Found additional required dependencies: belocs-locales-bin binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0 libc6-dev libdb4.3 libgdbm3 libpam-foreground libselinux1 libsepol1 libslang2 libstdc++6-4.0-dev linux-kernel-headers locales make patch perl perl-modules
<malex> I: Checking component main on http://archive.ubuntu.com/ubuntu...
<malex> E: Couldn't find these debs: libdb1-compat slang1a-utf8
<Mez> !pastebin | malex
<malex> the bot is dead?
<malex> Mez: http://pastebin.ca/319174
<Mez> it's not in here
<Mez> what system are you using to make that /
<Mez> (aka what is the pbuild-dapper script)
<Mez> s/pbuild/pbuilder
<malex> Mez: pbuilder-dapper script I use http://pastebin.ca/319183. I use the debootstrap from edgy. My system is Debian/sid.
<jono_> do we have a source CD iso?
<lifeless> dont thinkso
<LaserJock> I don't think so
<LaserJock> bah, always late
<sladen> jono_: AFAIK no.  Though there is a promise on the back of the CD cover that you could order a one-off special
<lifeless> there is a source cd
<lifeless> http://cdimage.ubuntu.com/daily/current/source/
<lifeless> jono_: ^
<lifeless> by 'cd' I mean DVD
* sladen is impressed with the speed lifeless hax0red LP to generate one
<lifeless> http://www.google.com/search?q=site%3Acdimage.ubuntu.com+source&ie=utf-8&oe=utf-8&rls=com.ubuntu:en-US:official&client=firefox-a
<jono_> lifeless: cheers dude
<lifeless> jono_: np
<jono_> digging through my huge inbox
<jono_> ugh, that sounds rather disgusting
<Mez> jono_, you're lucky - I've not been able to access my mail since December
<Mez> but my Mailserver messed up and started bouncing everything
<Mez> unsubscribing me from all my lists :D
<jono_> Mez: ugh
<jono_> I have hundreds to reply to
<jono_> gonna do them this afternoon
<Mez> only just fixed it and sent a massive "re-subscribe" message
* Mez sends jono_ another to reply to
<malex> Got a similar chroot creation problem for breezy: "E: Couldn't find these debs: slang1a-utf8". So, no more breezy and dapper packages. Oh well. Mez, thanks for trying to help me.
<Mez> malex, it worked fine for me - I dont know where your issue is
<Mez> possibly something to do with using debian as the main distro (shouldnt be but might be)
<lifeless> malex: try using ubuntu debootstrap ?
<malex> lifeless: I am using edgy debootstrap - 0.3.3.1ubuntu1
<malex> Mez: So, why does edgy chroot gets created without problems if the reason for the failure is in Debian tools?
<Mez> malex: I've no clue...
<Mez> I cant really try it other than using edgy
<Mez> and it works for me in edgy
<malex> Mez: So, you can create both breezy and dapper chroots?
<Mez> er, I could last time I tried
<Mez> lemme see
<malex> bbiaw
<Mez> malex, http://rafb.net/p/2QlwZC40.html
<malex> Mez: It looks like the difference is that it finds "I: Found additional required dependencies: belocs-locales-bin binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0 libc6-dev libdb4.3 libgdbm3 libpam-foreground libselinux1 libsepol1 libslang2 libstdc++6-4.0-dev linux-kernel-headers locales make patch perl perl-modules" on my system.
<malex> If I figure that out - it should work then.
<Mez> pastebin your pbuilderrc
<malex> Mez: http://rafb.net/p/gwABr116.html
<Mez> malex, /etc/pbuilder/pbuilderrc ?
<Mez> also, mine is here
<Mez> http://rafb.net/p/AbvtY840.html
<Mez> theres a few differences
<Mez> (I prefer to use command line switches dfor distro/targz locations
<malex> Mez: I tried going all manual, too.
<Mez> yeah *shrugs*
<Mez> try it after replacing with my config
<Mez> mine works
<malex> Mez: I just purged and reinstalled debootstrap (ubuntu) and pbuilder + deps.
<malex> didn't help
<Mez> *shrugs*
<Mez> prob some weird thing to do with debian and ubuntu incompatibility
<Mez> or
<Mez> wait
<Mez> do you have it install a sources.list ?
<malex> Mez: I'm not sure how that can be done (sources.list). Please elaborate.
<Mez> APTCONFDIR
<Mez> https://wiki.ubuntu.com/PbuilderHowto
<malex> Mez: It's going, the chroot is being built.
<Mez> malex: what you do ?
<malex> Mez: I've used your pbuilderrc and only changed the paths from /var to my /chroot partition. Also I used your basetgz name, not dapper-base.tgz I used before. That's all.
<Mez> *shrugs*
<Mez> weird
<malex> more info - base.tgz name doesn't matter. So, it's some setting in the rc file.
<Mez> lmao I just got email addressed to "mdz@ubuntu.com"
<Mez> malex, more than likely
<malex> BUILDSOURCEROOTCMD="fakeroot"
<Mez> lol
<malex> I had buildd
<malex> Maybe it had some weird deps.
<fabbione> morning
<malex> Where are the backports for dapper? I can see at http://lwn.net/Articles/212655/ that there is cmake-2.4.3 built for dapper, but where is it? It's not in the dapper or dapper-updates archives.
<LaserJock> malex: dapper-backports
<LaserJock> malex: https://launchpad.net/ubuntu/+source/cmake shows 2.4.3-1ubuntu1~dapper1
<malex> LaserJock: Thanks! That's it.
* Starting logfile irclogs/ubuntu-devel.log
<malex> Everything works now.  Thank you people! Best wishes from ubuntu packaging suport underground.
<doko> good morning
<Mez> morning dogmatism 
<Mez> doko *
<dholbach> good morning
<mneptok> dholbach: morgen!
<_ion> Hi
<dholbach> hiya mneptok, hi _ion
<cjwatson> Mithrandir: is there a bug for hw-detect hanging for several minutes in herd 2?
<cjwatson> I know it was in the release notes
<saispo> shawarma: ping ?
<Mithrandir> cjwatson: yes, I filed one, just a minute I'll find it
<cjwatson> it's basically udev spinning, repeatedly trying to modprobe -Q i82365
<Mithrandir> I can't find the bug now, though. :-/
<tepsipakki> a sec
<tepsipakki> https://launchpad.net/ubuntu/+source/hw-detect/+bug/78785
<Ubugtu> Malone bug 78785 in hw-detect "tries to modprobe i82365 a gazillion times (dup-of: 76341)" [Undecided,Unconfirmed]  
<Ubugtu> Malone bug 76341 in linux-source-2.6.20 "[Feisty]  Linux 2.6.20 spams 'Intel ISA PCIC probe: not found.' all over /var/log/messages" [High,Confirmed]  
<Mez> hmm can anyone tell me how to make a change so that when I plugin a USB device, I can read the /dev/input/event* for it (chmod a+r) whenever it's re-plugged in
<cjwatson> it's certainly not hw-detect's fault per se
<Mez> or point me in the right direction
<seb128> Mithrandir: could you have a look on libgimme-codec from NEW today, it's needed for EasyCodecInstallation
<Mithrandir> seb128: no need to prod me about archive admin stuff, it just raises my stress level.
<seb128> Mithrandir: well, you are blocking my work, so how do I unblock it, just wait?
<seb128> Mithrandir: fine, I'll not ping you again and note that the spec is blocked on you
<Mithrandir> seb128: it was actually a comment about a sync request from last night, but in general noting that a spec is blocked on something getting out of NEW is fine.
<seb128> well, I don't prod for syncs usually, that ping was just because the package is broken for now and I was not sure if that was better to ask for a sync now or wait for the next round which can usually take some days
<seb128> noted :)
<Mithrandir> and given that the oldest item in NEW is less than 48 hours old, I don't think NEW processing is proceeding at an unreasonable rate.
<seb128> no, not at all
<seb128> that's just I would like to get moving on the spec
<Mithrandir> I'm trying to get some of my own specs done too, which is bloody hard when we're down to just one active archive team member.
<seb128> right
<seb128> sorry for that :/
<Mithrandir> np, not your fault.
<Mithrandir> we can blame mdz for making 2/3 of the archive team managers. ;-P
<seb128> :)
<Mithrandir> seriously though, we need at least one other person to help out, since it's taking me more or less all my time atm.
<Mithrandir> and while doing it for a while is fine, I'
<Mithrandir> m going to implode if I have to do it full-time for years.
* dholbach hugs Mithrandir
<seb128> right, having only one person to manage the admin tasks is not enough
* seb128 hugs Mithrandir too
* mvo_ hugs Mithrandir
<Mithrandir> stop hugging and volunteer for archive administration instead. :-P
<dholbach> hahaha :)
* mneptok lets a little air out of the overinflated Mithrandir 
<mneptok> no popping.
<seb128> well, I would be fine helping on sync requests
<mvo_> its the bonoboo way of fixing problems. lots of hugging!
<seb128> I don't want to do NEW though because I'm not comfortable enough reviewing copyright problems, etc
* seb128 slaps mvo_, no bonobo, we use dbus now :p
<Mithrandir> seb128: doing the easy ones would be doable though.  Some I pass on or ask for advice on from elmo (who has loads of experience reviewing)
<seb128> Mithrandir: let's not that on the list of things to talk about next week
<seb128> s/not/note
<Mithrandir> yup
<\sh> who is approving NEW binary packages? :) boson has new binary packages which are replacing the old ones ;)
<Mithrandir> \sh: I am.
<cjwatson> \sh: which are only 15 hours old in the queue; relax
<Mithrandir> and generally, I don't process new binary packages before all arches are in, which happened 1.5 hours ago.
<Mez> anyone got any experience with udev rules?
<shawarma> saispo: Yes?
<\sh> Mithrandir: thx...I wondered if we should write a ticket or bug report about those changes
<Mithrandir> \sh: I have no idea what you are talking about.
<cjwatson> \sh: no, you should not
<mvo> doko: https://launchpad.net/ubuntu/+source/python2.5/+bug/79619 seems to be caused by a pickle incompatibility between python 2.4/2.5
<Ubugtu> Malone bug 79619 in gnome-app-install "Add/Remove programs crashed on Feisty" [Undecided,Confirmed]  
<cjwatson> hmm, perhaps I can work around the i82365 brokenness in pcmciautils' udev rules
<cjwatson> so wrong, but ...
<Mez> cjwatson, I want to be able to add the default user (1000) to the "games" group on the install of a package,
<Mez> what's the best way ?
<cjwatson> I don't think that's appropriate at all
<Mez> cjwatson, why not ?
<cjwatson> the games group is meant to be for private data used by setgid games programs that users can't get at
<Mez> cjwatson, ok, maybe not the "games" group
<Mez> but a custom group
<Mez> (which have access to a device that is setup to allow that group to have access through udev)
<cjwatson> Mez: why? this should normally not be necessary; the only thing that adds the first user to a group is supposed to be the installer
<cjwatson> use the plugdev group, if it's pluggable, or something else established
<Mez> cjwatson, cool... didnt think of the plugdev group
<Mez> cheers
<saispo> shawarma: excuse me
<saispo> i investigate about gnome-pty-helper because i have a system which doesn't want to run g-t. I get an error about creatin process child
* Mez growls
<mvo> iwj: I merged your g-a-i--codecs branch and plan to upload it today. is that ok with you?
<Mirv> potentially a big problem (translations wise) in 6.06 - bug #79682
<Ubugtu> Malone bug 79682 in Ubuntu "Bug in the new language update on 16/01/2007" [Undecided,Confirmed]  https://launchpad.net/bugs/79682
<simira> http://www.canis.no/nettbutikk/omtale.php?id=Dtb766 LOL!
<simira> rename needed?
<iwj> mvo: That's great, thanks.
<Hobbsee> hey simira 
<mvo> iwj: it seems like we do not yet have Codec data in the archive though, but IIRC seb uploaded the modified debs only yesterday
<simira> hi Hobbsee. Not coming up for the distro sprint, eh? ;)
<Hobbsee> simira: nope - you?
* Hobbsee didnt know about it, in truth
<slomo> mvo: the codec data for (from what i see) all gstreamer packages is already there
<simira> Hobbsee: it's not really any official info on it, I think. But as it is in my neighbourhood, and Tollef is going, I'll probably show up a day or two.
<iwj> mvo: I agree with slomo; where did you look ?
<Mirv> anyone besides pitti who can debug the language pack problem? if it's possible to prevent missing translations on at least some of ubuntu 6.06 installations, it would be good to try to be quick
<Hobbsee> simira: fun :)
<mvo> iwj: I run the extraction script and looked at the output, no Codec in there. I will investiagte
<seb128> mvo: how come we don't have Codec data in the archive?
<seb128> mvo: ls /usr/share/gstreamer-0.10/plugin-info ?
<seb128> mvo: I did update almost all the packages yesterday afternoon and they built correctly
<mvo> seb128: it was not extraced at least, I will check
<seb128> ok, let me know
<mvo> seb128: the extraction script runs on rookery, it may just take a bit until it is mirroed there
<iwj> mvo: Hmm.  In the tests I did I basically had to `by hand' point the extraction script at my `special' .debs.
<iwj> Oh, yes, if it was just yesterday afternoon it may just be lag.
<mvo> seb128: can you give me one packagename/version number of a updated codec package?
<\sh> Mithrandir: sorry to bother you again, but any clue how to resolve this issue: http://librarian.launchpad.net/5774155/buildlog_ubuntu-feisty-amd64.core%2B%2B_1.7-6ubuntu1_FAILEDTOBUILD.txt.gz (in pbuilder on amd64 it works)
<iwj> gstreamer0.10-plugins-ugly_0.10.5-0ubuntu2_i386.deb
<seb128> mvo: ii  gstreamer0.10-plugins-go 0.10.5-1ubuntu2          GStreamer plugins from the "good" set
<seb128> grah
<seb128> that's gstreamer0.10-plugins-good
<seb128> that's the first one I've updated
<iwj> I think you want to use -ugly because iirc only -ugly has a .desktop file (in g-a-i/menu-data-additional).
<StevenK> \sh: /bin/sh: latex: command not found
<StevenK> \sh: You need to build-depend on tetex-bin
<Lathiat> is the gnome control center an upsream thing?
<Lathiat> or an ubuntu thing?
<Mithrandir> StevenK: move the build-dep on tetex-bin to build-depends, not build-depends-index (or make it not call latex when you build with -B)
<StevenK> Mithrandir: I think you mean \sh
<seb128> Lathiat: upstream
<coyctecm> Lathiat: upstream, I think. Or what do you mean? gnome-control-center?
<seb128> Lathiat: why?
<Lathiat> seb128: just wondering
<Lathiat> thanks
<Lathiat> ('sok, i haven't come to flame ;)
<\sh> Mithrandir:thx :)
<Mithrandir> StevenK: indeed, I do.  I have forgotten to load irssi's psychic module.
<coyctecm> some people believe that this suse/opensuse related gnome control center is upstream thing
<coyctecm> I think it's pretty awful :P
<StevenK> Mithrandir: :-P
* mvo re-runs the data extraction
<seb128> coyctecm: it's upstream now
<StevenK> Mithrandir: Do you mind if I look at your uswsusp merge?
<Mithrandir> StevenK: please feel free.
<StevenK> Mithrandir: Thanks
<Mithrandir> StevenK: note that you need usplash from bzr to build it.
<\sh> guys, I have a very interesting question: src package bidiui resulsts in a binary package icedove-bidiui...should we rename it to mozilla-thunderbird-bidiui?
<\sh> I'm asking because if we do, to match our mozilla-* packaging scheme, we would never get any mom output on the original package
<shawarma> saispo: For what?
<Amaranth> \sh: rename the source?
<\sh> Amaranth: binary package is named icedov-bidiui ... the src package name is just bidiui
<Amaranth> changing the binary package makes mom ignore it?
<\sh> Amaranth: I don't know...
<Amaranth> i would hope it looked at source packages
<Mithrandir> mom only cares about source packages.
<geser> Mithrandir: could you please give-back wxwidgets2.6 on amd64? thanks
<mvo> iwj: what do you think about changing the codec extraction so that it auto-generates a desktop file for them? 
<\sh> Mithrandir: so it's ok to rename the resulting binary-package to mozilla-thunderbird-bidiui
<Mithrandir> \sh: correct.
<Mithrandir> geser: given-back
<iwj> mvo: I did think about that but it seems that the descriptions in the desktop files aren't quite the same as the ones in package control files.
<iwj> mvo: And it didn't seem like too much of a problem to have to explicitly write a desktop file in menu-data-additional for packages we want automatically offered for installation.
<iwj> mvo: I wasn't sure even whether it was right to cause programs to appear in g-a-i that didn't previously.
<iwj> (I see that gstreamer0.10-ffmpeg has one in m-d-a too.)
<mvo> iwj: right. I will probably just add something that warns about codec packages that are not in menu-data-additional
<cjwatson> \sh: "thunderbird-bidiui" would be typical, I thought, not mozilla-*
<\sh> cjwatson: hmmm..our tbird package is named mozilla-thunderbird
<iwj> mvo: Oh, you mean, when you invent a .desktop file, put a warning in it ?
<\sh> cjwatson: I just could need a decision how we name those packages..so it matches our binary package naming scheme for mozilla-* apps ,)
<mvo> iwj: no, just put a line in the log that there are codec packages that are not yet available via g-a-i. so that we know whats missing
<iwj> OIC.  Right.
<iwj> Shall I add that feature ?
<cjwatson> \sh: oh, match the existing naming scheme then
<mvo> iwj: I'm looking at it right now to see why the extraction is not working. I will probably just add it along the way
<\sh> cjwatson: k will do
<iwj> OK.
<iwj> It seems odd that it's not working.  Is it getting the right .debs ?
<iwj> Do you want me to have a poke around in the relevant bit of rookery ?
<mvo> iwj: I figured it out, it was a problem in the fnmatch.fnmatch() line apparently
<iwj> Maybe I broke it somehow between my final test and the checkin/push.
<iwj> mvo: Err, really ?  What problem ?
<iwj> Oh, don't tell me that some of them have filenames of the form ./whatever ?
<mvo> iwj: fnmatch() matches from the start and the tarfile starts with "./" (e.g. "./usr/share .."). I commited a fix as rev 435 
<iwj> I wonder why it worked for me.  Are these packages built in a different way to my test packages ?  Well.
<cjwatson> mvo: soyuz had the same problem
<cjwatson> iwj: are the file names by any chance quite long (say, >100 characters or so)?
<mvo> iwj: the packages come from the buildds, I don't know 
<iwj> cjwatson: No.
<cjwatson> ok, we ran into a problem of that form with d-i uploads
<iwj> mvo: Remind me of your branch URL ?  I don't seem to have it lying around here.
<cjwatson> it manifested once part of a version number changed from 9 to 10. :-/
<iwj> Lovely.
<mvo> iwj: http://bazaar.launchpad.net/~ubuntu-core-dev/gnome-app-install/main/
<iwj> mvo: Err, I think you have to try both because obviously some .debs have it without the ./
<iwj> if filename.startswith('./'): filename = filename[2:] 
<iwj> IJLTS $filename =~ s,^\./,,;
<mvo> iwj: that is strange, where does this inconsitency comes from?
<StevenK> I recall some debs contain just './'
<cjwatson> very old .debs used to not have the ./
<cjwatson> nowadays I'm pretty sure they all do. Unless you constructed test packages using ar and tar directly or something?
<iwj> cjwatson: directly> No, but I'm not entirely sure what dpkg-deb versions I will have been using.  Nothing very old.
<iwj> I wish there were a way to tell tar not to do that.
<cjwatson> oh, by very old I think I mean pre-potato or at least pre-woody
<iwj> No, nothing that old near any of this.
<cjwatson> I think it's due to find invocation
<iwj> Oh, probably someone helpfully changed it to work with broken (non-GNU) find.
<iwj> It doesn't seem implausible that the ./ will go away again.
<mvo> iwj: fair enough, I changed it in my local tree again
<iwj> mvo: Right.
<iwj> Thanks for debugging it.
<saispo> shawarma: for fixing my gnome-term )
<shawarma> saispo: Er... Ok. :-)
<saispo> i don't understand why i get this message...
<saispo> have you an idea ?
<cjwatson> StevenK: most do
<cjwatson> they've got to reference /, after all ...
<cjwatson> oh, you mean just ./ and no other entries? udebs do that quite often, if they only have maintainer scripts. Policy-compliant .debs can't really manage it.
<iwj> cjwatson: Uh ?  Old .debs have ./ as the first entry but the other entries do not start with ./, they just start with the first actual path component.
<cjwatson> I don't think I disagreed with that?
<Adri2000> fridge editors: there is a typo in the events page: "Fiesty Developer Sprint"
<iwj> cjwatson: Oh, I see, sorry, I was just misunderstanding you.
<mvo> iwj: I updated it now and re-run the data-extraction. hopefully all is fine now
<Riddell> enrico: what happened to apt-front-watcher in libept?
<iwj> mvo: Good, thanks a lot.
<seb128> mvo: did you get the gstreamer index files now?
<mvo> iwj: cheers
<mvo> seb128: yes, some small tweaks to the extraction script did the trick
<seb128> mvo: ok, good
<doko> MIthrwhat is the general procedure when builds are failing because .la files cannot be found?
<fabbione> iwj: rocking! (re bug #76749)
<Ubugtu> Malone bug 76749 in gs-esp "[SPARC/feisty]  gs-esp BUS ERROR" [High,Fix released]  https://launchpad.net/bugs/76749
<doko> pitti: in the scipy build log for powerpc, dh_strip ignores files which it cannot recognize, but the -dbgsym creator exits with an error.
<Mez> where can you find the ub untu NEW queue ?
<cjwatson> Mez: I've added a link to http://wiki.ubuntu.com/DeveloperResources, under "Package archive"
<Mez> cheers cjwatson 
<iwj> fabbione: NP
<dieman> /win 2
<ogra> Mithrandir, can you promote pulse and friends please ? its on anastacia now
<slomo> ogra: yay :) are you going to use pulse-alsa or gst-pulse for edubuntu?
<Mithrandir> ogra: if it's on anastacia, I'll get to it when I do archive admin stuff.
<ogra_> Mithrandir, ok, thanks 
<ogra_> slomo, likely pulse-alsa to support volume control on thin clients
<ogra_> slomo, crimsun is working on a libasound2 split to get it to main without jack dependency
<ogra_> s/libasound2/libasound2-plugins/
<cjwatson> argh, pitti is on holiday
<cjwatson> Mithrandir: do you think pitti would scream if I promoted the refit source package just for gptsync-udeb?
<cjwatson> it's a violation of process, but otherwise I can't progress with intel-mac-support until after the sprint
<geser> Mithrandir: please give-back gnuradio on all archs. thanks
<BenC> bug #79109
<Ubugtu> Malone bug 79109 in base-installer "feisty-alternate-i386 for herd-2 cannot install kernel from CDROM" [High,Confirmed]  https://launchpad.net/bugs/79109
<wasabi_> cjwatson: I just noticed your upload of partman-efi. Lots of commednts about "Intel Macs". I hava a 64bit Xeon EFI system here I've had no end of trouble getting booting right... does all this work benefit that as well?
<cjwatson> wasabi_: I'm not sure how the non-Mac i386 EFI stuff works
<wasabi_> Well, I know, at least, that elilo doesn't work right.
<cjwatson> wasabi_: does /sys/firmware/efi exist?
<cjwatson> and how does elilo fail?
<wasabi_> Let me check. Got to SSH through a few layers.
<wasabi_> I don't remember. I set it up almost 4 months now. It's still got the CD with GRUB on it that I use to boot in the drive. ;0
<cjwatson> wasabi_: my change should improve partman for you by avoiding mounting the EFI system partition, which I believe confuses elilo
<cjwatson> but if that's not the problem elilo is having, it probably won't help
<cjwatson>   * Automatically use existing EFI system partitions on Intel Macs as EFI
<cjwatson>     boot partitions (LP: #38225).
<wasabi_> No /sys/firmware/efi
<cjwatson> that was a slightly unhelpful changelog, actually, because that's done regardless of platform
<wasabi_> This system can also boot with regular DOS partitions...
<wasabi_> But, I got it all set up with shiney new GPT partitions...
<wasabi_> And then realized grub broke on those.
<cjwatson> although on Intel Macs, the EFI system partition showed up in a new format (fat32) that partman-efi hitherto hadn't recognised
<wasabi_> And spent 3 days trying to get elilo working before I gave up.
<cjwatson> grub breaks if you don't run gptsync
<wasabi_> gptsync?
<cjwatson> that syncs the GPT partition table to MBR for the benefit of legacy software
<wasabi_> Oh that makes MBR?
<cjwatson> it's not really within the EFI spec, but in practice I believe nothing should care
<wasabi_> I got it to a EFI boot prompt thing...
<wasabi_> Figured out how to navigate to the disk...
<cjwatson> gptsync's in the refit package
<wasabi_> But elilo.exe or whatever it was just wouldn't run properly. I'll give it another try later.
<wasabi_> No refit package....
<cjwatson> I've been running entirely in BIOS compat mode on this intel mac so far
<wasabi_> amd64 arch?
<cjwatson> it's in universe
<cjwatson> oh, not for amd64 yet
<wasabi_> Ahh.
<cjwatson> there's a Debian bug about that - needs some gnu-efi patch I haven't got my hands on yet
<wasabi_> Also, I have no elilo package.
<cjwatson> same reason, probably
<wasabi_> I remember now. Couldn't find a 64 bit version. ;)
<cjwatson> I'll be able to work on that once I get the gnu-efi patch
<cjwatson> well, theoretically, anyway. this mac should be amd64-capable
<wasabi_> Guess nobody's just run a mac on 64 bit mode, eh?
<Mithrandir> cjwatson: should be fine, I guess.
<cjwatson> wasabi_: I'm sure they have - in fact I can probably give it a try shortly with a live CD
<wasabi_> Oh, works fine with a livecd. Just nt with EFI. :)
<wasabi_> Off a GPT partition.
<wasabi_> (Other than the unrelated problem of the LiveCD's X server hard locking this system, and having no way to disable the X server)
<cjwatson> it's all a bit raw
<wasabi_> Yeah. I got that. :)
<wasabi_> I am actually sort of amazed how the x86_64 platform has such a large number of problems still. Would have thought vendors would have given a shit by this point. Guess not. =(
<wasabi_> By vendors I don't mean ya'll. I mean like, the dudes selling the servers.
<enrico> Riddell: it's finally gone!  libept is now smart enough to build the index in ~/.debtags if it cannot write to /var/lib/debtags
<enrico> Riddell: and if it figures out that the index in /var/lib/debtags is up to date, it deletes the one in the home
<enrico> Riddell: no need for that horrid hack
<enrico> Riddell: we how have a much better horrid hack! :)
<Riddell> :)
<Riddell> ok, thanks
<cjwatson> gpocentek: please subscribe ubuntu-sru or motu-sru (as appropriate) to SRU bugs rather than me+mdz individually
<gpocentek> cjwatson: ok
<mdz> Mithrandir: finding an archive admin solution is on the sprint agenda next week
<gpocentek> cjwatson: is one ack enough to upload to -proposed
<gpocentek> ?
<cjwatson> yes
<gpocentek> ok, thanks
<cjwatson> c.f. https://wiki.ubuntu.com/StableReleaseUpdates
<gpocentek> I need to read it again
<somerville32> Would it be possible for Xubuntu to be added to releases.ubuntu.com?
<somerville32> It is currently on cdimages.ubuntu.com but not releases.ubuntu.com
<cjwatson> that would require Canonical supporting Xubuntu directly ...
<cjwatson> I can put in an informational link, but I'm afraid we aren't going to actually distribute it from releases.u.c
<cjwatson> somerville32: link added
<somerville32> cjwatson: Thanks.
<geser> Mithrandir: please give-back libapache-mod-jk on all arch. thanks.
<somerville32> cjwatson, [13:24]  <Znarl> somerville32 : I think cjwatson is talking about a URL link pointing to Xubntu on http://releases.ubuntu.com/, not a link to help with launchpad.
<somerville32> cjwatson, We're trying to set things up so that we can use the mirror prober on launchpad for Xubuntu mirrors.
<cjwatson> oh
<cjwatson> erm, that will have to be resolved some other way - releases.u.c has a lot of mirrors with disk space constraints and I can't just arbitrarily add another flavour to it
<somerville32> cjwatson, Who should I chat with?
<cjwatson> somebody on #launchpad, maybe salgado
<Viper550> I saw that new Windows based Ubuntu installer thing, that is just AWESOME!
<cjwatson> (and unsupported)
<iwj> Hnngg, the state of Xen in Feisty is pretty appalling.
<cjwatson> (i.e. the result of using that installer is unsupported
<cjwatson> )
<Viper550> so don't ask for help here
<cjwatson> Yes; I welcome the effort, but installer bugs have required workarounds in the distro in the past so we need to be clear about its status
<somerville32> Was acroread killed before or after January 11th?
<geser> somerville32: 2007-01-12 11:03:17 CET  	Removed  	feisty   	Release  	multiverse  	text  	7.0.9-0.0.ubuntu1
<somerville32> geser: thanks
<Burgwork> why was it nuked?
<elmo> license
<Burgwork> nasty
<Burgwork> I thought it was distributable
<elmo> no, it's always been dubious
<elmo> it was removed from Debian years and years ago - I believe our import came from Marillat
<bddebian> Do I have to do some magic to get a feisty daily to install from a USB cd-rom drive?
<tincan_30> How can I find out who the package maintainer for mod-mono is?
<cjwatson> tincan_30: folks in https://launchpad.net/~mono may be able to helpl
<cjwatson> help
<tincan_30> cjwatson, Thanks...I'll take a look, edgy needs some package lovin.
<cjwatson> edgy won't get further changes except where absolutely necessary; most development takes place in feisty
<sharms> tincan_30: If you are curious about a package, who maintains it etc, open up a shell, and type in: apt-cache show mod-mono
<cjwatson> libapache2-mod-mono, as it happens
<tincan_30> hmm...mod-mono has dependency issues, they are fixed in debian(stable and stabe)  not sure why this wouldn't be fixed.
<cjwatson> that just gives you MOTU in this case though, since it's synced from Debian
<cjwatson> if it's uninstallable, that would be cause for a stable release update; contact the mono group
<tincan_30> unstable*
<tincan_30> cjwatson, that is correct..I'm on it.  Thanks for the info.
<cjwatson> https://launchpad.net/ubuntu/+source/mod-mono/+bug/65454 and https://launchpad.net/ubuntu/+source/mod-mono/+bug/72912 (possibly duplicates)
<Ubugtu> Malone bug 65454 in mod-mono "[UNMETDEPS]  mod-mono has unmet dependencies" [Undecided,Confirmed]  
<tincan_30> cjwatson, that is it...I talked to the sid maintainer, he was willing to help but did not know who to contact.
* netjoined: irc.freenode.net -> anthony.freenode.net
<frafu> Hello, can anybody please tell me where I can find informations about the Feisty dev sprint scheduled for next week? 
<frafu> http://fridge.ubuntu.com/event
<frafu> http://fridge.ubuntu.com/node/714
<dsas> frafu: It's a week long event where the core ubuntu developers get together for hacking.
<frafu> will there be any reports about what they have talked? 
<frafu> Are there some wiki pages with a plan about what they will talk about? 
<dsas> frafu: Probably, it's not much of a talking meeting though. More of a "getting hands dirty and hacking"
<frafu> So it's not like the summit at Google a few months ago? 
<dsas> frafu: nope.
<frafu> Are there some webpages about what they will work on? 
<dholbach> cjwatson: btw: bughelper now does and/or nested statements in xml and has a  bugxml -sa <..>   (simple add of 'clues')
<frafu> dsas: As far as I understand your reply there is not much information available about the sprint. More broadly, is there any information available on what the core developer are working on? Or does their work mainly consist in importing the debian and adjusting it for Feisty? 
<dsas> frafu: I'm not a core-dev I don't know what's planned or even if much is planned in advance.
<dsas> frafu: the core devs do do that, also administer the archive, package somethings directly (e.g. kernel) or push on ahead of debian (e.g. gnome packaging or python2.5 transition I think), they write the installer, monitor security updates
<dholbach> frafu: we'll work on the specs targetted for feisty release and discuss them, work on them together 
<dsas> frafu: There's lots of things I guess. maybe some of the interviews on http://behindubuntu.org/ will give some insight.
<frafu> dsas: I did not know that website, thanks
<frafu> dholbach: So I suppose you will mostly work on these https://blueprints.launchpad.net/ubuntu/+specs
<frafu> those of the list targeted for Feisty 
<frafu> ? 
<dholbach> frafu: https://blueprints.launchpad.net/ubuntu/feisty - yep
<frafu> dsas, dholbach: thanks for the informations
<dholbach> frafu: anytime
<iankesterhaney> hello, i am having trouble with dpkg --debug=200, it says * options should be piped to less.  when piped to less it shows the same message
<mdke> dholbach: do we build metacity with the compositor flag?
<dholbach> mdke: afaik we do
<mdke> dholbach: thanks. I'll give it a go
<seb128> no we don't
<mdke> ah, i was wondering why the gconf key had no effect :)
<mdke> seb128: is it any good?
<seb128> it adds a Depends on libcm and there was no tarball and there is no ABI compatibility for that lib
<mdke> ah
<seb128> I've just uploaded libcm 0.1.1
<seb128> we might reconsider that for the next upload
* mdke nods
<seb128> hint for dholbach who will do the update tomorrow :)
<mdke> poor dholbach :)
<dholbach> i'll just upload
<dholbach> you guys will figure ou the rest ;)
<seb128> :)
<dholbach> just kidding :)
<mdke> I wonder if it will be a realistic alternative for us to provide instead of the other options
<seb128> I'll probably upload compiz 0.3.6 tomorrow
<seb128> with a new keybinding compat plugin for GNOME
<seb128> and the number of workspaces adapted
<dholbach> ok see you tomorrow
<mdke> night
<dholbach> nightiw
<dholbach> nightie
* mdke lifts up dholbach's nightie
<seb128> which means it should behave in a better way out of the box
* Burgwork hugs seb128
<Mithrandir> geser: given-back.
<Mithrandir> mdz: sounds good.
<Burgwork> seb128: are we going to be testing beryl as well?
<seb128> Burgwork: I'm not for sure
<Burgwork> ok, just wondering
<seb128> dunno what other people are doing
<seb128> I've already too much to do
<seb128> and I would prefer to use compiz than beryl
<Burgwork> if you are doing compiz 0.3.6, I will poke the compiz bugs once that hits the repos
<seb128> thank you for that
<Burgwork> no worries
<_ion> I still wish compiz had the state plugin. You can define rules such as "put firefox windows to desk 1 by default", "view mplayer brighter than other windows" etc.
<seb128> _ion: well, it should not be too hard to adapt to compiz and go upstream if there is a version for beryl done
<Mithrandir> Burgwork: nobody has uploaded packages which are suitable for the archive yet.
<Mithrandir> (for beryl)
<Mithrandir> there was an upload which I had to reject due to licence problems.
<Burgwork> Mithrandir: ah. Which doesn't speak highly for installing it by default
<Mithrandir> well, it was mostly stuff like not shipping the real source.
<Mithrandir> and there are some problematic plugins
<Mithrandir> those'd need to go to multiverse since there's no free shader fragment compiler.
<Burgwork> ah, ouch
* mdke hugs ogra 
<ogra> mdke, thanks, thats needed
<mdke> ogra: that was a proper hug, not one of those bugday ones :)
<ogra> i know :')
* mvo hugs ogra
<ogra> thanks 
<hipertracker> My Ubuntu 6.10 cannot recognize my network, sata disks, even processor is not displayed (athl64x2 4200+). Motherboard is GigaByte K8N Ultra9. There is no drivers for Linux on GigaByte site. What to do?
<Chipzz> hipertracker: not ask here to start?
<Chipzz> this is not a support channel
<hipertracker> where to ask?
<mdke> hipertracker: you might find some help in #ubuntu
<mdke> hipertracker: or other support resources, see http://www.ubuntu.com/support/
<mdke> Chipzz: please be a bit nicer to people who are struggling with Ubuntu
<Chipzz> mdke: hrrrrm
<Chipzz> hipertracker: #ubuntu (and if you don't get an answer there the forums may be a good start; otherwise (I'm not sure about this) certain mailinglists may be a good alternative)
<Chipzz> hipertracker: but please DO pay attention to the rules;
* Chipzz points at the topic
<Chipzz> but the fact remains that not getting an anser elsewhere still doesn't make this the right place to ask
<Chipzz> mdke: polite enough this way? :)
<hipertracker> mdke: I tried usind #ubuntu. no response at all. ok, i will stay with winxp if i have no choice. :(
<Chipzz> hipertracker: like I pointed out to you, try the forums
#ubuntu-devel 2007-01-18
<mdke> Chipzz: so so
<mdke> hipertracker: try and persevere, maybe there is an answer out there for you. Good luck
<hipertracker> Chipzz: ok
<Chipzz> mdke: I think a good idea might be to make this channel moderated and have a bot that sends a /notice to everyone entering this channel explaining the rules; and automatically voicing people after 5 or 10 seconds so they get the chance to read the rules
<allee> tkamppeter_: ping?
<mdke> Chipzz: chilling out would work too. It's easy to point people gracefully towards the right resource
<mdke> especially at quiet times
<Chipzz> mdke: depends on how many people think the support thing is actually disturbing
<Chipzz> mdke: you're right about the quiet times I guess
<mdke> Chipzz: it's less disturbing to point someone quietly and helpfully to the support page than make a fuss about it; just takes a few words, and doesn't end up putting anyone off
<mdke> it's nice to give people a positive impression about the community
<Chipzz> prolly right about the community thing too
<Chipzz> but I did point him in the right direction afterwards
<mdke> yep.
<allee> tkamppeter_: afaik you know the KDE/cups print system quite.  Any idea how to attack bug 54216 . I don't have access to a printer that can print boderless :(
<Ubugtu> Malone bug 54216 in digikam "DigiKam will not print borderless photos" [Undecided,Unconfirmed]  https://launchpad.net/bugs/54216
<Chipzz> but as I (and a couple of other people too) have already pointed out, a channel #ubuntu-advanced or likewise may be a good thing
<wasabi_> MOM question. I'm staring at a package which has progressed in Debian, but in feisty has ubuntu patches, and is a previous version of the Debian package. It isn't listed on merges.ubuntu.com.
<wasabi_> Do I need to poke somebody or something to make it happen?
<wasabi_> geeze and the wiki is never a help because it's too easy to find outdated info heh
<bronson> wasabi_: good question.  Ask on ubuntu-motu maybe?
<geser> wasabi_: which package?
<wasabi_> jabberd2
<geser> wasabi_: Debian has only newer versions in experimental
<geser> and I guess MoM looks only on unstable
<wasabi_> Just noticed that
<wasabi_> Interesting. Looks like the last version unstable had was still earlier than the version we have now
<geser> merging is still possible but you have to do it w/o the help of MoM
<Nafallo> zZzZ
<sistpoty> lamont: can you please give back osgcal for i386? thanks.
<Keybuk> so, err
<Keybuk> resume from hibernate doesn't work
<Keybuk> looks like it didn't find the image, and left a corrupted swap
<sistpoty> Keybuk: can you route two sync requests (both security bugfixes) through? wordpress (bug #79171) and cacti (bug #80227). thanks
<Ubugtu> Malone bug 79171 in wordpress "please sync wordpress (2.0.6-1) from unstable/main to universe" [High,Unconfirmed]  https://launchpad.net/bugs/79171
<Ubugtu> Malone bug 80227 in cacti "please sync cacti (0.8.6i-3) from unstable/main to universe" [High,Unconfirmed]  https://launchpad.net/bugs/80227
<Keybuk> sistpoty: no, please ask Mithrandir 
<sistpoty> Mithrandir: can you route two sync requests (both security bugfixes) through? wordpress (bug #79171) and cacti (bug #80227). thanks.
<sistpoty> Keybuk: ok, thanks
<Keybuk> do these need flagging to the security team as well?  are bad versions in edgy?
<sistpoty> Keybuk: both are flagged as security bugs already... 
<alex-weej> i'm trying to install the build dependencies for libswfdec
<alex-weej> E: Build-dependencies for libswfdec0.3 could not be satisfied.
<alex-weej> any ideas?
<sistpoty> Keybuk: cacti (bug #78453) is nominated for breezy-edgy, but the nomination is not yet confirmed
<Ubugtu> Malone bug 78453 in cacti "cacti remote injection exploit" [Unknown,Fix committed]  https://launchpad.net/bugs/78453
<sistpoty> Keybuk: wordpress is confirmed for dapper to feisty.
<sistpoty> (bug #78145)
<Ubugtu> Malone bug 78145 in wordpress "XSS and SQL injections" [Unknown,Fix released]  https://launchpad.net/bugs/78145
<Keybuk> ==26216== Syscall param waitid(infop) points to unaddressable byte(s)
<Keybuk> ==26216==    at 0x40007F2: (within /lib/ld-2.5.so)
<Keybuk> ==26216==    by 0x804A431: test_poll (test_child.c:147)
<Keybuk> ==26216==    by 0x804B351: main (test_child.c:235)
<Keybuk> BOOM!
<kylem> wossit?
<Keybuk> kylem: waitid doesn't like receiving NULL as the siginfo_t * :p
<kylem> heh.
<dholbach> good morning everybody
<dholbach> mako: http://www.ubuntu.com/community/processes/newmember still mentions your fax number for signing the CoC
<dholbach> also wiki.ubuntu.com/NewMemberProcess and wiki.ubuntu.com/GrantingMembership confuse a lot of people
<dholbach> Riddell: heya - do you have an idea what bug 74151 might be?
<Ubugtu> Malone bug 74151 in gnash "konqueror-plugin-gnash displays no content" [Medium,Confirmed]  https://launchpad.net/bugs/74151
<mdke> dholbach: mako's fax number isn't working any more? If not, you can file a bug on ubuntu-website and we'll remove it. It would be nice to replace it though so people can still sign the CoC by hand
<dholbach> mdke: why should they sign it by hand?
<mdke> dholbach: I did it that way. the reason is that it's the only way to do it properly if you don't have a GPG trust path to you
<dholbach> Does Launchpad check that?
<mdke> no
<mdke> back in the old days that was enforced for ubuntu membership, it's not any more. But I still think it would be nice to retain the possibility for people to sign it with a pen
<dholbach> I think we have a bunch of ubuntu members who never got their gpg key signed
<mdke> for some it might have more significance
<dholbach> mh
<dholbach> I just notified mako of that, because he once said "and there's still a page that references to me for signing it by hand..."
<mdke> anyway, if the fax number isn't working, it should be removed straight away, we can think about replacing it later
<dholbach> I don't know if it's still working
<mdke> ah right
* mdke -> work
<Mithrandir> Riddell: can you do the knetworkmanager bits of NetworkRoaming or would you like a patch for it?
<doko> Mithrandir: please requeue pyqwt on ia64
<Mithrandir> doko: given-back
<Mithrandir> doko: can you look into why python-examples is uninstallable (and has been for a while)?
<doko> Mithrandir: python2.5-examples needs promotion
<Mithrandir> doko: ah, promoted
<doko> Mithrandir: while you are at, could you promote the various java bits as well?
<Mithrandir> doko: sure, I'll do promotions too today.
<Mithrandir> as in, source promotions.
<doko> ok, thanks
<Mithrandir> they require actual thought, binary-only promotions don't really.
<cjwatson> I was about to have a look, but I have an interview to do soon and really ought to prepare for it
<cjwatson> I can look through them later if you like, since I noticed some Java bits in the approved MIR queue yesterday
<bluefoxicy> ... wow
<bluefoxicy> networking sucks.
* bluefoxicy watches an scp over his 100Mbit/s link start transfer at 11.0MB/s, then degrade to 10.8MB/s ... guesses networking code started the TCP window etc in an optimal state and slid them to a less optimal one o.O
<bluefoxicy> just a guess.
<Mithrandir> cjwatson: I'm fine doing them, I just finished most of networkroaming.
<iwj> So as I read the UbuntuMainInclusionRequirements, I'm permitted to sign off on MainInclusionReportLibVncServer-dev.  But since (a) I've never done one of these and (b) I'm not entirely disinterested (it's blocking Xen on feisty) I was wondering if someone else would like to cast their eye over it ?
<iwj> I didn't write the inclusion report although I've just edited it to fix a few links and formatting issues.
<iwj> Am I allowed to improve the report myself and then approve it ?
<dholbach> iwj: pitti and keescook would know
<iwj> Hmm, pitti seems offline.
<Riddell> Mithrandir: I'm happy to do them, have you done the changes for the gnome version?
<iwj> Ah, he's on holiday and Kees Cook is in the wrong timezone.
<cjwatson> Mithrandir: really? that was quick
<iwj> cjwatson: (Picking on you because you're here:) Do you happen to know the answer to my questions above ?  How should I proceed ?  Improve the report and mail Kees about it ?
<cjwatson> Kees is also on holiday
<iwj> Oh, damn.
<iwj> So he is.
<cjwatson> let me invent some policy on the fly :-)
<iwj> :-)
<cjwatson> Personally, I'd trust your judgement, and the most important thing is that it's documented so that we know (a) that somebody actually thought about it (b) who
<cjwatson> To some extent the archive team get to decide whom they trust to review stuff for main
<cjwatson> Improving the report is not a blocker to approving it yourself, since you're really approving the package, not the report
<iwj> Right.
<iwj> OK, I'll do that then.  Thanks.
<cjwatson> the important things to think about are (a) is it so badly designed that we'll be giving our security team a horrible headache (b) are our support department going to be able to deal with issues in it, since they may be contractually obliged to do so?
<cjwatson> deal with> or at least be able to figure out when and how to escalate to distro
<cjwatson> however, we should talk about this at the sprint
<fabbione> cjwatson: low priority ping for bug #78161
<Ubugtu> Malone bug 78161 in glibc "[sparc]  unable to link against optimized libpthread due to wrong symbols" [Medium,Fix committed]  https://launchpad.net/bugs/78161
* cjwatson goes to put it on the schedule
<fabbione> (needs archive love)
<cjwatson> fabbione: can you either get back to me in an hour after this interview, or else ask Tollef to do it if it's purely an archive decision?
<fabbione> cjwatson: sure. i will ask Tollef
<fabbione> Mithrandir: ^^
<Mithrandir> Riddell: yes.
<Mithrandir> cjwatson: it's absolutely trivial, so yes.
<Mithrandir> fabbione: it doesn't require SRU intervention, so I can do it as an archive admin.
<Mithrandir> now I need to un-gdb my X server and get on with archive admin stuff.
<cjwatson> Mithrandir: thanks
<fabbione> Mithrandir: thanks
<iwj> So when it says `Add the package to a seed, or as a dependency of a package in main ...', does a build-dependency count ?
<dholbach> iwj: yes, but it needs still to be promoted to main.
<iwj> Indeed; my next question was whether I need to wait for anastacia to run etc. or if I can just poke an archive admin now.
<dholbach> iwj: I think cjwatson is your man.
<ogra> you need to wait until it shows up afaik
<iwj> Fair enough; from my pov it can wait a bit.
<ogra> (to make sure germinate has picked up the seed change/dependency)
* dholbach hugs ogra
<ogra> dholbach, thanks a lot 
<Adri2000> Mithrandir: can you approve obconf into edgy-proposed please, there is not much to check, it's just a rebuild
<Mithrandir> Adri2000: as long as it's on ~ubuntu-archive/+subscribedbugs, I'll get to it.
<Adri2000> it is
<cjwatson> iwj: we often like to wait for anastacia to run because it saves us having to work out by hand if anything extra is required
<cjwatson> iwj: I've corrected the documentation which talked about dependencies to mention build-dependencies too; thanks
<cjwatson> if there's a hurry and/or it's obvious at a casual glance (few dependencies) we can promote without waiting
<cjwatson> Mithrandir: FWIW I'm OK with you accepting rebuilds into -proposed without explicit SRU-team approval as long as you've checked that that's really the right solution
<Mithrandir> cjwatson: ok.
<Treenaks> c
<cjwatson> i.e. zero-source-change-except-changelog rebuilds
<Mithrandir> seb128: your libgimme-codec upload never actually ended up in NEW, I've reprocessed it now and it should be done today, I hope.
<bhale> Mithrandir: do you have any idea where last-exit_4-0ubuntu2 went?
<Mithrandir> bhale: I'll reprocess it
<bhale> Mithrandir: thank you
<jenda> Hello folks. Anyone here moderating the ubuntu-devel list?
<davmor2> I have been going through the untriaged bugs and there seem to be a lot of issues with gparted I was just wondering if there were any plans to update this package?
<Mithrandir> jenda: yes, all of the distro team has moderation access.
<jenda> Ah, great.
<jenda> I just sent an email there, could someone please let it through?
<jenda> I'm not subscribed.
<bhale> you would typically mail ubuntu-devel-discuss
<jenda> ah
<jenda> I didn't know that :/
<jenda> OK, then, could someone please _discard_ that email?
<jenda> Before anyone lets it through :)
<Mithrandir> jenda: the "User feedback: GUI GRUB setup tool" ?
<jenda> yep
<jenda> I'll resend it to devel-discuss if you remove it.
<Mithrandir> discarded
<bhale> thanks jenda 
<jenda> thanks Mithrandir 
<jenda> resent
<iwj> cjwatson: Thanks for the explanation.  It can wait.
<Mithrandir> seb128: libgimme-codec accepted.  FYI.
<cjwatson> davmor2: they're mostly due to integration between ubiquity and gparted, not so much gparted itself; https://blueprints.launchpad.net/ubuntu/+spec/ubiquity-advanced-partitioner documents a plan to switch to a new partitioner instead
<cjwatson> since the issues are really fundamental to using an external partition editor the way we do at the moment
<cjwatson> updating the package would not help, and would in fact probably consume time that could be better focused on the replacement
<cjwatson> (copied from #ubuntu-bugs where you asked the same question)
<seb128> Mithrandir: thank you!
<davmor2> thanks cjwatson
<cjwatson> damn, this iMac isn't amd64-capable after all
<cjwatson> thought it was Core 2 Duo, but it's just Core Duo
<kylem> cjwatson, bummer.
<kylem> has there been any progress by anyone on being able to write hybrid hfs+ cds
<cjwatson> not to my knowledge, but who cares, grub works now
<cjwatson> so my interest level in that has dropped right off
<kylem> hehe.
<Mithrandir> it requires bootcamp, though, doesn't it?
<kylem> yeah.
<cjwatson> Mithrandir: yes, but all Intel Macs come with that now
<Mithrandir> oh, ok.
<Mithrandir> I thought you still had to pay extra.
<cjwatson> boot camp is three pieces
<cjwatson> http://refit.sourceforge.net/myths/ has a good summary
<cjwatson> the firmware update is the only bit that matters for thhis
<Mithrandir> ok
<Riddell> Mithrandir: there's no need to disable anything in network manager in case of using static configuration?
<Mithrandir> Riddell: no, as long as it's done through /etc/network/interfaces, NM will just ignore the device
<Riddell> oh aye, true
<Mithrandir> if it does static configuration some other way, NM will have to be taught how to cope.
<Riddell> it's the same backends in KDE as in Gnome so it's all good
<Mithrandir> 'k
<dholbach> mjg59: I just had a look into the libcm update, but it seems to changes interfaces quite a lot - I think I'll let you deal with it. :-)
<seb128> dholbach: I did libcm 0.1.1 yesterday, what do you want to update?
<seb128> dholbach: I told you yesterday evening ;)
<dholbach> oh... i updated and still have the old one
<dholbach> seb128: how did you solve the problem?
<seb128> what problem?
<dholbach> changed interfaces
<seb128> nothing use libcm7 out of spifacity
<seb128> I didn't care
<seb128> it's not used
<dholbach> ok
<seb128> grumpf
<seb128> launchpad has eaten my upload again
<dholbach> that explains a bit
<mjg59> seb128: Yeah, I got reject mail
<mjg59> dholbach: I'm on GMT+11 right now
<seb128> mjg59: oh, why?
<seb128> the rejected reason
<dholbach> mjg59: right... I saw pictures of you :)
<mjg59> seb128: No orig.tar.gz
<mjg59> dholbach: So IRC is probably not a great way to get at me :)
<seb128> mjg59: thank you
<dholbach> mjg59: it still worked ;-)
* dholbach hugs mjg59
<mjg59> Only because I'm reading mail instead of going to bed
<dholbach> mjg59: in any case, it was not urgent but I thought I'd (try to) tell you :)
<seb128> I've uploaded again
<seb128> mjg59: who was to the To: from that rejected mail? only you?
<mjg59> seb128: Not sure - I've deleted it, I'm afraid
<seb128> mjg59: ok no problem, I was just being curious to know if launchpad didn't mail me or if I didn't get or dropped the mail
<dholbach> Mithrandir: thanks for the decibel review - uploaded it again (fixed)
<cjwatson> seb128: if you don't get a mail regarding an upload, it's best to ping an archive admin; we can reprocess it
<cjwatson> seb128: the keyserver interaction problems that are causing dropped uploads are being addressed urgently, though
<cprov> cjwatson: in fact, the seb128's case wasn't related with the GPG interaction problems. Although, I support your advice for *forgotten* uploads.
<cjwatson> cprov: ah, ok
<mjg59> seb128: The accept mail went to both of us
<gnomefreak> in feisty debtags and language-selector-qt need to be rebuilt (depends problems) they are conflicting with apt-index-watcher. is this known already?
* mjg59 goes to sleep
<seb128> mjg59: ok thank you, that's confirmed by my procmail log now, not a launchpad bug
<seb128> brb
<seb128> trying new pango
<dholbach> we'll have a meeting about bughelper in #ubuntu-meeting in 6 min - join us if you're interested
<enrico> gnomefreak: apt-index-watcher is not needed anymore
<gnomefreak> enrico: its not?
<enrico> gnomefreak: the new libept should build indexes in the home if it needs reindexing
<enrico> gnomefreak: I worked a lot to get rid of apt-index-watcher
<enrico> gnomefreak: it was causing lots of problems
<gnomefreak> ah ok cool. than it just leaves one issue with it
<zul> iwj: ping thanks for the help
<gnomefreak> enrico: read first comment here https://bugs.launchpad.net/ubuntu/+source/libapt-front/+bug/80426 
<Ubugtu> Malone bug 80426 in libapt-front "removal of apt-index-watcher leaves startup links" [Undecided,Confirmed]  
<Riddell> Mithrandir: knetworkmanager uploaded
<iwj> zul: NP.
<iwj> zul: AIUI we're waiting for it to filter through the pipeline now.
<zul> ill upload a new versioin and new kernel by the end off the week
<Nafallo> zul: XEN?
<zul> Nafallo: yes
<Nafallo> nice :-)
<enrico> gnomefreak: it's normal that a removal (and not a purge) leaves things in /etc
<enrico> gnomefreak: dpkg -l|grep -v ^ii will show you with a 'c' in one of the first two characters all the packages you have removed but not purged, and therefore have configuration still around
<gnomefreak> enrico: just tell him to purge them than?
<enrico> gnomefreak: I'll leave that task to the ubuntu maintainers :)
<gnomefreak> k
<geser> Mithrandir: please give-back libapreq2 for all archs. thanks
<carlos> dholbach: ping
<mako> mdke, dholbach: the problem isn't that i get the faxes
<mako> mdke, dholbach: the problem is that AFAICT, there's no way to approve signatures sent in by hand
<mako> mdke, dholbach: so switching to a different number won't really help in this regard
<dholbach> carlos: pong
<doko> Mithrandir: would you mind promoting stlport5.1 (new upstream version) to main, would be nice for the next OOo upload
<HombreMagique> hi all
<HombreMagique> is there a kernel patch set of Ubuntu?
<davmor2> I have a bit of a problem my 64bit install of feisty just went tits up.  I get rectangles instead of letters except in alt-F1-F6 terminal.  Any Ideas on what I can do
<carlos> dholbach: ping (I was disconnected, not sure whether you answered)
<dholbach> carlos: I ponged
<carlos> dholbach: hi
<dholbach> hiya
<carlos> dholbach: are you still the MOTU 'boss'?
<davmor2> hello
<dholbach> carlos: I work together with other MOTUs if that's the question :)
<HombreMagique> is there a patch set of Ubuntu kernel?
<carlos> dholbach: ok, I need to arrange with MOTUs an agreement to accept some translations for universe accepted in Launchpad/Rosetta
<carlos> dholbach: who should I talk with?
<dholbach> carlos: best to write a mail to ubuntu-motu@lists.ubuntu.com
<carlos> ok
<carlos> dholbach: thanks
<dholbach> carlos: I'll approve your mail and auto-accept mails from you
<dholbach> no problem
<davmor2> I have a problem with my 64bit install of feisty after the last dist-upgrade I get rectangles instead of letters.  Any ideas on what I can do.  It hasn't effected my 32 bit install at all
<dholbach> i'm off for a bit now
<slomo> davmor2: seems to be a problem with the latest pango or somethnig... i have it too now after upgrading pango ;) well, not all letters but many
<devilsadvocate> where can i get help for building a package?
<carlos> dholbach: sent
<davmor2> no this is all my entire desktop :( I took a screenshot but I don't know whether to report it as a bug if it was something that you guys picked up on and were dealing with.
<devilsadvocate> i've been trying to make a .deb of something. It refuses to accept my changelog file. Nothing i found online helped
<gpocentek> devilsadvocate: join #ubuntu-motu
<devilsadvocate> thanks gpocentek
<HombreMagique> gpocentek do you know where can i get a kernel list patch?
<gpocentek> HombreMagique: no idea
<HombreMagique> :(
<dholbach> carlos: approved
<carlos> dholbach: thanks
<mdke> mako: this is true, I hadn't really thought of that
<Yawner> Who would I contact to get the mozilla-firefox-locale-pt-pt package moved from Universe to Main in Edgy and/or Dapper? (This has been changed for feisty, but for Edgy and Dapper are still without official Portuguese language support in Firefox, the version int he currently is Portuguese Brazilian).
<Yawner> https://launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/69663
<Ubugtu> Malone bug 69663 in mozilla-firefox-locale-all "firefox "pt" localization" [Undecided,Confirmed]  
<mdke> Yawner: Martin Pitt or Ian Jackson
<Yawner> aha ok, thanks
<joejaxx> Mithrandir: ping
<Mithrandir> joejaxx: 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.
<joejaxx> Mithrandir: i based the -meta off of the ubuntu-meta
<joejaxx> Mithrandir: the ubuntu-meta package does not contain the full GPL in the tar.gz either
<joejaxx> Mithrandir: i based ubuntustudio-meta off ubuntu-meta that is
<Tonio_> cjwatson: ping ?
<cjwatson> Tonio_: pong
<cjwatson> joejaxx: IMO that's a bug in ubuntu-meta; please file it as one so it doesn't get forgotten
<Tonio_> cjwatson: hi ! may I ping you concerning this : https://launchpad.net/ubuntu/+source/digikam/+bug/73617
<Ubugtu> Malone bug 73617 in digikam "SRU proposal" [Undecided,Unconfirmed]  
<Tonio_> cjwatson: this is my packaging fault, and the error is reported by dozens of people.... I'd like this to be review to provide sru as long as this is possible
<cjwatson> Tonio_: sorry for the delay on that; see comment in the bug
<Tonio_> cjwatson: sure
<Tonio_> cjwatson: thanks a lot, I'm fixing the changelog and upload
<joejaxx> cjwatson: alright will do
<hunger> Any ideas why pam_mount no longer mounts my encrypted user dirs?
<jdong> cjwatson, can I make a plea for backports to be processed in the near future?
<cjwatson> jdong: ok, I'll deal with the queue this evening
<jdong> thank you
<mdke> Mithrandir: cjwatson: I'm waiting on one of you for bug 74555 (but I'm not sure which)
<Ubugtu> Malone bug 74555 in ubuntu-docs "Stable release update" [High,Confirmed]  https://launchpad.net/bugs/74555
<cjwatson> jdong: to explain the delay, both Scott and I recently got promoted to management, so we have much less archive admin time than before
<cjwatson> mdke: probably me
<mdke> cjwatson: I'd be grateful if you just give the nod :)
<cjwatson> oh, no, Tollef really
<cjwatson> I'll leave it in my browser anyway so that I deal with it
<mdke> cjwatson: I think he's waiting for you, I remember a ping on it from him to that effect
<mdke> cjwatson: thanks, and congrats on promotion :)
<cjwatson> hmm, I'll definitely look then
<cjwatson> most people commiserate ;-)
<jdong> cjwatson, congrats on the promotion :)
<mdke> heh, that depends I guess
<LaserJock> I didn't think Canonical had management, just slaves ;-)
<cjwatson> jdong: punted through the ones I got done before the meeting (just four), but the rest will have to wait until afterwards
<jdong> cjwatson: no problem, thanks for your attention :)
<Mithrandir> mdke: you're waiting for me, but the diff of what's uploaded doesn't completely match the ok-ed debdiff.  Some line breaks, etc, are different.
<cjwatson> I'm happy for you to have discretion on whitespace if it's trivial (i.e. not python :-))
<mdke> Mithrandir: there were a couple of things that Colin asked me to change as per the bug report, I don't remember any line breaks though...
<Mithrandir> cjwatson: it's sgml, but it makes reading the diff a lot harder.  I spent some time on it a couple of days ago.
<cjwatson> oh, if it's making the diff much noisier than it would otherwise be, I agree with you
<Mithrandir> mdke: I'd be happy to send you the diffs, if that'd be useful.
<mdke> Mithrandir: ok, thanks
<cjwatson> the diff should be as easy to read as possible - that's an important property
<Mithrandir> mdke: after the distro team meeting if that's fine with you?
<mdke> Mithrandir: sure, I'll look tomorrow
<Mithrandir> cjwatson: it's more that I can't just diff the diffs and get $? == 0, so I have to do it by hand.
<mdke> cjwatson: it's not easy because we need to make text changes sometimes, and docbook isn't necessarily pretty
<mdke> especially translation updates are not the sort of thing the archive managers can just read (obviously that doesn't necessarily apply in this case, but we'll need to do some translation updates sometimes)
<Mithrandir> mdke: what's uploaded and what's in the approved debdiff _should_ match, though.
<mdke> Mithrandir: yeah, I agree. I only changed the changelog, to my recollection, to link to bug reports and so on
<Mithrandir> mdke: I'm not pointing fingers, I'm just pointing out what I see.
<mdke> Mithrandir: yes, I'll look at it
<slomo> Mithrandir: is there a known problem with uploads not being accepted or rejected or anything?
<Mithrandir> slomo: yes, if you notice it happening, prod me and I'll rescue it.
<Mithrandir> (with an approximate time and package name)
<cjwatson> slomo: it's keyserver interaction problems - being addressed urgently
<slomo> Mithrandir: ok, i uploaded pango1.0 at around :03
<Mithrandir> slomo: as in ten minutes ago?
<slomo> Mithrandir: yes
<cjwatson> the queue is processed every five minutes, so normally you can expect a reply in that plus mail delay
<geser> need all uploads to be rescued manually or will this happen automatically once the problem is fixed?
<Mithrandir> once the problem's fixed we won't have to rescue them because the won't get lost in the first place.
<geser> I mean the uploads in the last minutes/hour(?)
<alex-weej> i can't get the build dependencies for swfdec... any idea what went wrong? :
<geser> Mithrandir: could you look after the upload of kdesdk (around 21:46 CET) and mod-vhost-hash-alias (around 21:55 CET)?
<alex-weej> E: Build-dependencies for libswfdec0.3 could not be satisfied.
<Riddell> geser: ?
<Riddell> geser: what's kdesdk doing?
<cjwatson> geser: any that have been lost of late, probably a good idea to rescue them now
<cjwatson> we don't yet have a timescale for the fix
<geser> Riddell: build for libapr0->libapr1 and libsvn0->libsvn1
<geser> Riddell: rebuild
<Riddell> geser: ok, thanks, I have an upload of 3.5.6 for next week but I'll sync it closer to the time
<geser> Riddell: the rebuild fixes bug #80329 (I only had to change one build-depends)
<Ubugtu> Malone bug 80329 in kdesdk "kdesdk-kio-plugins cannot be installed on Feisty" [Undecided,Fix committed]  https://launchpad.net/bugs/80329
<doko> Mithrandir, cjwatson: please can we promote stlport5.1 (all binaries) to main, maybe tonight, so that OOo can build? Once built stlport4.6 can be demoted.
<cjwatson> doko: done
<Mithrandir> slomo: pango upload rescued.
<Mithrandir> geser: both rescued, prod again if you don't get accepted mails.
<slomo> Mithrandir: thanks :)
<slomo> Mithrandir: still not accepted :/
<Mithrandir> slomo: we're having problems with the keyserver; they're being worked on, I don't have an ETA but I'll reprocess the sources as soon as it works again.
<slomo> Mithrandir: ok, thanks... just wanted to make sure that everything is fine before i went to bed ;)
<Mithrandir> slomo: it might not be, but it's on my radar, so I'll reprocess once it has a chance of working.
<Mithrandir> which was now.  Yay.
<Mithrandir> slomo: there, you should get a mail RSN
<slomo> ok, perfect :) thanks again
<geser> Mithrandir: thanks, the accepted mails have now arrived
<Mithrandir> geser: great, thanks.
<geser> Riddell: I missed that kdesdk is in main. I've attached a debdiff with my changes to bug #80329.
<Ubugtu> Malone bug 80329 in kdesdk "kdesdk-kio-plugins cannot be installed on Feisty" [Undecided,Confirmed]  https://launchpad.net/bugs/80329
<geser> Mithrandir: could you please give-back libapreq2, pysvn and modxslt for all archs. thanks.
<Mithrandir> geser: given-back
<Riddell> geser: can you e-mail me that bug jriddell@ubuntu.com so I get it tomorrow morning
<geser> Riddell: sure
<mdke> cjwatson: around still?
#ubuntu-devel 2007-01-19
<kamikaze> re all
<kamikaze> i have somme question
<kamikaze> i would like to use with ubuntu 6.10 my dongle usb wifi wg111 v2
<kamikaze064> re all
<kamikaze064> there is someone
<kamikaze064> on the channel
<kamikaze064> ?
<mdke> kamikaze064: this isn't a support channel, try #ubuntu or http://www.ubuntu.com/support
<kamikaze064> ok
<kamikaze064> thanks
<Hobbsee> kamikaze064: FYI, you'll have to use ndiswrapper for that.  but see #ubuntu
<Mez> I'm thinking of making a backport of gstreamer0.10.11 to edgy... does anyone here have any major concerns ?
<Mez> (this is to backport jokosher)
<mdz> Mez: it's used by an awful lot of other packages
<Mez> mdz: I know that - but I've spoken to the gstreamer guys and basically their respone was
<Mez> "well we all use it - and if it doesnt work - we've done something wrong"
<Mez> it's a point version change, and the API hasnt changed... 
<mdz> Mez: they use it on edgy?
<Mez> mdz: yeah
<Mez> 0.10.11 on edgy
<mdz> oh, that's encouraging then
<Mez> indeed :D
<Mez> I mean - everythings backporting fine
<Mez> the main problem i see is python-gstreamer0.10 - which i'm going to test with serpentine etc
<Mez> but apparently, the gstreamer devs are using 0.10.11 on edgy with no adverse effets (in fact - htye'vepurposely coded it to make sure that it isnt a problem)
<Chipzz> Mez: the "purposely coded it to make sure that it isnt a problem" is imho a rather silly argument in se. I can think of only one project that's silly enough to introduce new or destablizing features in stable releases (the linux kernel :P), but most projects try to avoid introducing bugs. The thing with bugs is that most of them are created by accident. ;)
<Chipzz> but the argument about the developers using it theirselves IS a pretty good one though ;)
<Mez> Chipzz, lol
<Mez> well I'm currently uploading locally backported debs ;)
<Chipzz> but I doubt the kernel matters a lot for the vast majority of users (those with not bleeding new hardware) anyway :)
<Chipzz> both of my laptops happened to work out of the box anyway (except for the nvidia/suspend crap), and little has changed since I installed them (both initially breezy installs)
<Chipzz> only thing that did change for me was a fix in ipw2[12] 00 drivers that made rmmod'ing/modprobing the drivers on iwconfig essid unnecesary :)
<Mez> hmm
<cr3> how can I determine more or less the number of milestones released per year?
<somerville32> I get a kernel panic when I upgrade network-manager :(
<wasabi_> I hate the gnome control center, by the way.
<tepsipakki> rodarvus: ping?
<tepsipakki> rodarvus: bug 67487 seems to have a fix in upstream, maybe we could get it in feisty (and as it seems, edgy too)?
<Ubugtu> Malone bug 67487 in xserver-xorg-driver-ati "[regression] [rv280]  black screen and console freeze when X starts - drm lockup" [Unknown,Confirmed]  https://launchpad.net/bugs/67487
<Treenaks> tepsipakki: upstream should fix #20283 .. that's been in there since 2005-08
<Treenaks> at least
<tepsipakki> hmm, I don't suffer from that
<tepsipakki> but the bug I mentioned... marked a number of dri freezes as duplicates until I understood that there were two (possibly unrelated) issues :)
<tepsipakki> I used fglrx until now, but since the new version doesn't support radeon8500 anymore and tv-out isn't used so gave the free driver a go
<Treenaks> tepsipakki: apparently, it's a video bios parsing issue.. but I haven't had a reply from upstream since october
<tepsipakki> there was 6.6.3 in early october, but no new releases since
<Treenaks> exactly
<Treenaks> every cool kid is now hacking nouveau, instead of fixing at
<Treenaks> ati
<tepsipakki> and I thought I could run compiz :)
<Treenaks> I can.. but my screen looks like this: http://foodfight.org/zut/ati-breakage.ogg
<tepsipakki> hmm, nothing there?
<tepsipakki> my ff shows a blank page
<Treenaks> tepsipakki: it's an ogg/theora video
<Treenaks> try totem
<tepsipakki> wget works
<Treenaks> ok :)
<tepsipakki> eww.. funky :)
<Treenaks> tepsipakki: yeah.. and it's not a hardware failure -- fglrx and The Other OS work
<tepsipakki> naturally
<fabbione> cjwatson: am I right that on cdrom installation, no matter what cdrom the machine is using the CD is mounted in /cdrom ? also.. do you have a good example on how to write preseedable stuff in d-i?
<fabbione> Hobbsee: ping?
<Hobbsee> fabbione: semipong?
<fabbione> Hobbsee: i met the debian maintainer for kommando a couple of days ago and he was wondering when are you going to merge the new release he did a couple of weeks ago...
<fabbione> Hobbsee: nothing more.. nothing less :)
<Hobbsee> fabbione: what was his nick?
<fabbione> Hobbsee: IRC nick.. pulsim or something like that...
<Hobbsee> fabbione: will look when i get off the phone.
<fabbione> thanks
<Hobbsee> :)
<fabbione> Mithrandir: you didn't accept glibc for -updates yet, did you?
<Hobbsee> fabbione: you must be meaning pulsing
<fabbione> Hobbsee: yes possibly..
<Hobbsee> fabbione: done :)
* Hobbsee forgot about it - it's not on MOM, and no one poked me about it
<Hobbsee> recently, anyway
<fabbione> Hobbsee: yes i noticed it was not on MoM
<fabbione> probably MoM is not running
<Hobbsee> fabbione: likely.  rather stupid, that
* Hobbsee should have poked scott over that yesterday, in person, probably.
<fabbione> Hobbsee: MoM needs love once in a while
<fabbione> doko: is there any chance that you can give me info about #78968 ?
<dholbach> good morning
<_ion> Hi
<Amaranth> morning
<Mez> cjwatson: ping regarding backports
<Mithrandir> fabbione: no, I haven't yet.
<fabbione> Mithrandir: ok thanks.
<Mez> Mithrandir, unless you know about the backports process?
<Mithrandir> Mez: if you can phrase a question, I can try to answer it.
<Mez> Mithrandir, 2 questions
<Mez> 1) is it possible to backport already superceded packages from feisty to edgy
<Mez> 2) do backports currently buld against backports
<Mithrandir> no and no, ttbomk.
<Mithrandir> hmm, or maybe they're built against backports.
<Mez> I rememebr there was a rather large debate about it ;)
<Mithrandir> but in general, I'll turn down requests to backport important libraries and such.
<Mez> Mithrandir, does that include gstreamer ?
<Mithrandir> Mez: I would need to decide on that.  I'm not sure.
<Mez> Mithrandir, fair enough
<Mez> well the discussion is on ubuntu-devel, unless you want me to CC you ?
<Mithrandir> nah, I can go look at it.
<Mithrandir> just haven't really had time for email lately.  Too much archive administration work.
<Mez> kk... well am writing a nice email right now
<dholbach> Mez: please don't backport the cvs version of base
<Mez> dholbach... well, I'm poking people right now...
<Mez> we *might* be able to get 0.10.11 
<Mez> (not CVS)
<dholbach> hmhm
<Mez> dholbach, CC'd
<Mez> is ubuntu-devel restricted now ?
<Mez> (the mailing list)
<Mithrandir> yes.
<Mithrandir> as you'd know if you'd read ubuntu-devel-announce. :-P
<Mez> Mithrandir, had my mail server bouncing emails for 2 months
<Mez> Mithrandir, I'm just wondering why it's letting in my "non-ubuntu" email address
<Mez> I guess it uses LP (or emails were harvested from there)
<LaserJock> act
<LaserJock> bah, needs a / :/
<cjwatson> fabbione: /cdrom> correct
<cjwatson> fabbione: er, nearly any bit of d-i is a reasonable example of how to do preseeding in its own way
<cjwatson> fabbione: just avoid doing db_set without first checking if db_fget $question seen returns false
<cjwatson> Mez: it uses LP, but it's hand-moderated anyway
<cjwatson> rather than just rejecting
<cjwatson> AFAIK backports builds against backports, but Adam Conrad would be the authoritative reference for that
<dholbach> morning cjwatson
<fabbione> cjwatson: ok thanks.
<Mithrandir> cjwatson: if not, backporting libraries wouldn't make much sense, especially not if the new libs had a new soname.
<webben> what does ubuntu uses to parse SVG? is there some reason Cairo's libsvg wasn't needed, or even included in the repositories?
<cjwatson> Mithrandir: right
<webben> that's this thing: http://cairographics.org/libsvg
<Mez> cjwatson, so no chance of building against stuff thats already been superceded in feisty ?>
<cjwatson> webben: I think we generally use librsvg from GNOME
<fabbione> hey BenC 
<cjwatson> Mez: well, it could be done if necessary, but our standard backport tool doesn't support it
<BenC> yo
<dholbach> hey BenC
<webben> cjwatson, ah thanks
<cjwatson> I'd be a bit concerned about doing that since obviously fixing bugs is going to be a pain
<BenC> hey dholbach
<Mez> dholbach, did the 0.10.11 (non CVS) version cause those problems for you
<cjwatson> webben: (not sure what Kubuntu uses)
<webben> cjwatson, I was just off to find out, thanks :)
<dholbach> Mez: I'm just asking the folks in #gstreamer what could cause this
<Mez> cjwatson, I see your point, but as far as I'm concerned, I'd be happy, it builds quire nicely... however, daniel pointed out some issues with the current feisty version
<dholbach> Mez: I don't know what's causing the problems
<Mez> dholbach, I saw :D
<Mez> dholbach, if it isn't the new gstreamer, would your opinion on backporting it change ?
<dholbach> Mez: you asked me for my opinion - I wouldn't backport anything until jokosher worked fine for me - because 0.1 *works fine* on edgy right now - I wouldn't like to mess it up
<Mez> dholbach, fair opinion :D
<dholbach> and since gstreamer affects a lot more applications than jokosher, I'd be extra careful
<Mez> dholbach, hence why I'm doing a lot of testing :D and why I'm consulting with gstreamer devs, and asking lots of people rather than just syaing
<Mez> "yeah, works fine, backport it"
<Mez> as I said, I'm happy rto just host it in my own apt-repo :D
* Mez adds a huge warning
<coyctecm> synaptic crashes when I try to lock packages
<coyctecm> I think it's a know bug
<coyctecm> And what's the status of amd64 bootsplash? It's still grey...
<cjwatson> that reminds me, I should upload usplash
<cjwatson> not sure whether amd64 is fixed in there, but it can't hurt (much!) to try
<cjwatson> I know the fix is known, but it's not clear to me whether it's been checked in
<coyctecm> ok
<cjwatson> mjg59 would know for sure
<seb128> Mithrandir: around?
<Mithrandir> seb128: 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.
<seb128> Mithrandir: I've uploaded a new tracker with fixed debian/copyright, the orig tarball has still no LGPL text though, is that ok if that will be fixed with next upstream version? Or should I repackage the orig with a COPYING.LIB? Or better to wait for next version?
<Mez> Mithrandir, where did you get the contentless ping script from?
<tepsipakki> does usplash support svg pictures? In UWN #8 it was reported to do so, but looking at the code it isn't clear to me
<tepsipakki> s/pictures/artwork/
<neuralis> Mez: he wrote it; http://err.no/personal/blog/tech/2006-10-10-12-05_contentless_pings.html and there's an x-chat port somewhere.
<seb128> Mez: he wrote it I think
<Mez> seb128, sweet :P I know lots of people who wnat that
<Mithrandir> Mez: I wrote it.
<Mithrandir> seb128: Please repackage the orig.tar.gz.
<Mez> Mithrandir, you should release it
<seb128> Mithrandir: ok, please reject the upload I just did then
<neuralis> Mez: i gave you a link.
<Mez> neuralis, I'm blind today
<Mithrandir> Mez: http://err.no/src/contentless_ping.pl you mean?
<Mithrandir> seb128: will do.
<Mez> Mithrandir, indeed
* Mez pokes it to work for other things
<Mithrandir> seb128: sorry about having to be so picky, but licences are serious business.
<seb128> Mithrandir: no problem, I don't like licences problems much but I totally understand ;)
<Mithrandir> dholbach: colorblind looks interesting. :-)
<dholbach> Mithrandir: interesting as in how?
<Mithrandir> dholbach: as in I am red-green colour blind and if I can run something which turns problematic combinations into nonproblematic ones, that'd be useful.
<Mithrandir> dholbach: I don't know if anything uses it yet, but I imagine what a theme engine using it could do..
<dholbach> Mithrandir: gnome-mag makes use of it already and we'd like to build it with it - but it's just experimental parts of it that are unfortunately not exposed to the user
<dholbach> Mithrandir: upstream is very responsive and a very nice guy - so if you have crazy ideas, I'm sure he'd listen
<dholbach> Mithrandir: gracias for reviewing it
<Mithrandir> dholbach: np, simple package.
<seb128> Mithrandir: fixed tracker uploaded
<Mithrandir> seb128: great, I'll get to it soon
<seb128> Mithrandir: thank you
* cjwatson discovers http://lists.gnu.org/archive/html/bug-grub/2006-07/msg00037.html
<Mithrandir> cjwatson: aren't intel macs supposed to be getting grub2?
<cjwatson> well, that had been the plan, but I found out that the state of grub on Intel Macs was much better than I'd previously thought
<cjwatson> if this patch works, that should be about it
<cjwatson> don't mind switching to grub2 later if it also works, but this is most expedient
<cjwatson> NEAT
<cjwatson> it works
<Mithrandir> ok, cool
<cjwatson> so theoretically gptsync probably isn't even needed, but that's a problem for another day
<Mez> does it REALLY matter if something doesnt have man pages in the package
<_ion> Usually yes.
<Mez> this thing doesnt come with man pages
<Mez> has no --help output
<Mez> has nothing
<Mez> oh wait
<Mez> it has a html filr
<cjwatson> whatever you do, don't override that lintian warning. If you don't want to write a man page, then just upload it with the lintian warning still there.
<Mez> cjwatson, no problem - will it be rejected if theres no man pages ?
<cjwatson> no
<cjwatson> not by us anyway
<cjwatson> it's still a bug though
<Mez> cjwatson, I know - it's a major PITA though
<Mez> none of the commands take command line arguments
<cjwatson> *shrug*
<Mez> lol :D
<StevenK> Debian's view has always been, "We'd prefer if it had manual pages, but it doesn't require them."
<BenC> I hate programs like that
<_ion> Well, the commands probably *do* something.
<_ion> How about explaining it in the man pages? :-)
<StevenK> I agree with BenC, too, for what it's worth.
<cjwatson> I'm not really interested in how much of a pain it is - I just want the warning not to be overridden, because people are picking up that idea from somewhere and it's wrong
<BenC> with the exception of things like cat, programs should produce a usage with no args
<Mez> _ion, if i could write man ages, I would
<StevenK> Mez: *roff isn't hard. :-)
<Mez> BenC, I agree :D
<cjwatson> it's a pity nobody's bothered to write pages and pages of documentation on how to write man pages, isn't it?
<cjwatson> and example files and stuff
<BenC> cjwatson: File a bug :)
<StevenK> cjwatson: Geez, bitter much? :-P
<cjwatson> BenC: (I have written such documentation, personally)
<Mez> cjwatson, lol :P I f I could only find that copy of LXF where they taught you how to write them
<Mithrandir> cjwatson: yeah, man(7) doesn't exist.
<cjwatson> or /usr/share/doc/man-db/examples/
<BenC> cjwatson: It's part of Debian's stuff isn't it?
<Mithrandir> they're all figments of your imagination
<StevenK> Ahhh, now I remember that cjwatson is the man-db maintainer.
<cjwatson> BenC: yeah, I maintain man-db
<BenC> cjwatson: ick...sorry to hear that :)
* Mez cries and runs away
<Mez> learn one thing at a time and try to change it
<cjwatson> hey, I like it
<Mez> I'm still learning english
<BenC> Mez: groff is easier than english...so I've heard :)
<Mez> BenC, but i've always been taught to learn one thing at a time
<Mithrandir> dholbach: for your decibel upload, you didn't really add a copy of the GPL to the upload, did you?  Or am I blind?
<dholbach> Mithrandir: I added it to debian/ iirc
<StevenK> Mez: If that's the case, you'd never learn packaging, which teaches multiple concepts at once.
<Mithrandir> dholbach: oh, confirmed, I'm blind
<Mez> and i REALLY dont want to be spouting .TH GREETING .SH hello
<dholbach> *phew* I questioned MY sanity
<Mez> StevenK, I see pacakging as one thing
<Mez> lol
* Mez is actually learning stuff for work atm
<Mez> cjwatson, is it ok to override
<Mez> E: nostromo: maintainer-script-calls-init-script-directly postinst:24
<StevenK> Mez: Use invoke-rc.d
<Mez> StevenK, I know - I do
<cjwatson> you should use lintian-info to find out more
<Mez> cjwatson: in my case - I do the following
<Mez> http://rafb.net/p/6eAQFO44.html
<Mez> (check for invoke-rc.d and f it's not there, call /etc/init.d
<cjwatson> it is not OK to override messages from lintian unless it is a special case that isn't worth hardcoding in lintian
<Mithrandir> Mez: why are you trying to restart udev?
<cjwatson> if you use invoke-rc.d when it's available, that's fine and you can override the message - but as Mithrandir says
<cjwatson> use dh_installudev instead
<Mez> Mithrandir, because I'm installing udev rules
<Mez> cjwatson, never come across that one
<cjwatson> you have now
<cjwatson> you don't need to restart udev in Ubuntu, but do in Debian
<Mithrandir> Mez: yes, and?  udev watches its rules directory and reloads on the fly.
<cjwatson> dh_installudev does the right thing
<Mithrandir> cjwatson: that's because the udev policy in Debian is crack. :-)
<Mez> Mithrandir, it didnt for me ;)
<cjwatson> then you've done it wrong
<cjwatson> or there is a udev bug
<Mithrandir> Mez: if you install files directly to the rules directory, it does.
<cjwatson> in any case you should not restart udev in Ubuntu
<cjwatson> if you aren't using dh_installudev, you've almost certainly got it wrong. There are several subtleties.
<Mez> cjwatson, cool :D thanks for pointing that one to me :D
<cjwatson> you're welcome
<cjwatson> hmm, actually dh_installudev doesn't seem to restart udev in Debian
<cjwatson> so if I remember correctly and that's still needed there, you'll have to take care of that in packages intended for Debian users
<Mithrandir> I'd call that a bug in dh_installudev in Debian, then.
<cjwatson> probably ...
<Mez> so - should i keep the postinst or not ?
<cjwatson> not, for Ubuntu
<Mez> cjwatson, cool
<mneptok> cjwatson: you going to be active for the next ... say ... 4 hours or so? (not at all urgent)
<cjwatson> mneptok: yeah
<mneptok> cjwatson: cool. i'll ping you from home in a bit re: bug consolidation and closure
<cjwatson> mneptok: ok
<jwendell> doko, good morning. around?
<dholbach> jwendell: he's off to meet a python guy - he'll be back in an hour or two or something
<jwendell> dholbach, do you know if there is any firefox packager here?
<dholbach> jwendell: at the moment we're a bit maintainerless
<ogra> we have a team ... 
<dholbach> jwendell: iwj took care of that a while ago, the last uploads were done by keescook and doko
<ogra> its just forming ... 
<mneptok> ooo! an alaisd. :)
<seb128> lunch time, bbl
<alaisd> am i allowed to print to STDOUT?
<_ion> Nope, the new legislation forbids it. If you're caught, your name will be added to the list of people who have done that, and you have to report yourself to neighbours and schools near your house.
<alaisd> aw well, forking to the background then
<jwendell> dholbach, firefox is a monster... debian diff does not reside in debian dir only...
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<cjwatson> jwendell: that is true of many packages and is perfectly standard practice
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<jwendell> cjwatson, yes, i understand, i'm talking this because i'm a novice in debian builds...
<jwendell> is there any way for lsdiff work on <package>.diff.gz? or does it only work on unzipped files?
<jwendell> sorry, got the answer (-z)
<giskard> ciao *
<Mithrandir> NEW empty.
* Mithrandir celebrates
<Treenaks> Mithrandir: *\o/*
* StevenK promptly uploads a bunch of new things
* StevenK ducks
<Hobbsee> Mithrandir: woot!!!
<ogra> Mithrandir, what about enabling me to work again by finally promoting pulse ?
<ogra> now that you dont ahve anything to do anymore :P
<Ng> mdke: about?
<jwendell> dholbach, help me: i want to test a fix for firefox; i've done apt-get source. I want to modify configure.in, which was already modified by debian diff
<jwendell> dholbach, how to do this?
<Mithrandir> sfllaw: you're aware that bash is Essential and dependencies on it are not needed?
<Mithrandir> sfllaw: re https://bugs.launchpad.net/ubuntu/+source/oprofile/+bug/69455
<Ubugtu> Malone bug 69455 in oprofile "[SRU]  for oprofile, edgy-updates: bashism in oprofile's opcontrol script prevents user from setting any events" [Unknown,Fix released]  
<dholbach> jwendell: just change configure.in again - afaik firefox doesn't use a patchsystem
<dholbach> jwendell: if you change configure.in just make sure you run autoconf again - and remove autom4te.cache/ - it shouldn't show up in the diff
<Mithrandir> crimsun: I've rejected your updated oprofile upload to edgy-proposed; reasoning is in the bug report.
<sfllaw> Mithrandir: True.  I have no idea what I was thinking at the time.
<Mithrandir> sfllaw: I suspect it was your evil twin or something. :-)
<sfllaw> Mithrandir: For some crazy reason, I thought we had made dash Essential.
<Mithrandir> sfllaw: dash is priority: required
<sfllaw> Mithrandir: Yeah, I looked at it again.
<Mithrandir> doko: any particular reason why you have uploaded two versions of eclipse to edgy-proposed, with the same version number?
<Mithrandir> doko: also, if you want archive admins to take action on requests, subscribing ubuntu-archive is a good plan. :-)
<\sh> who has a clue about the sparc buildds? :)
<doko> Mithrandir: hmm, maybe I forgot that I did upload? ;-)
<Mithrandir> doko: 'k, they're supposed to be the same?
<zul> \sh: fabbione probably
<Mithrandir> \sh: what are you wondering about?
<doko> Mithrandir: yes
<Mithrandir> doko: I'll reject the oldest one, then.
<doko> Mithrandir: ok
<\sh> fabbione: if you have time could you check this buildlog: http://librarian.launchpad.net/5776033/buildlog_ubuntu-feisty-sparc.kmymoney2_0.8.5-1build1_FAILEDTOBUILD.txt.gz and tell me what could I do to prevent the bus error? :)
<Mithrandir> \sh: that's probably fixed in a recent gs upload, I'll give it back and see if it works.
<Mithrandir> \sh: but it fails on ppc too
<\sh> Mithrandir:yes, broken build-deps
<\sh> Mithrandir:on ppc that is
<Mithrandir> yeah, just retried it
<\sh> Mithrandir:cool thx :)
<crimsun> Mithrandir: thanks. I wasn't quite sure how to progress given the conflicting info between Policy and Simon's comment. Thanks for clarifying.
<Mithrandir> crimsun: np.
<sfllaw> crimsun: Yeah, I was just crazy.
<sfllaw> crimsun: Feel free to look me up on IRC if that happens.
<jdong> cjwatson: many thanks for your hard work clearing backports queue!
<cjwatson> you're welcome
<cjwatson> sorry it was overdue
<wasabi> Mithrandir: sorry about my idiotic NEW upgrades. I've been mentally out to lunch the last few weeks.
<wasabi> s/upgrades/uploads/
<wasabi> see, i can't even type what i'm thinking.
<bddebian> Heya
<dholbach> heno: should we add that <sourcepackage> tag to the clue files?
<heno> dholbach: I think so, yes
<heno> will it be optional?
<dholbach> hmhmmh, that'd mean reading all packages/ files first
<dholbach> i don't have a solid opinion yet :)
<heno> me neither
<heno> what was the use case for it again? local files for testing out stuff?
<dholbach> what about this: if no special -r flag (or whatever it will be) is used, we rely on <name>.info files, else the <sourcepackage> xml tag will be considered
<dholbach> yeah exactly
<heno> it's useful if you tell bh to use that file, while if you only give it the package name then the clue file should have that name imo
<heno> yep
<dholbach> like that you can also 'accumulate' say evolution clues over a bunch of files (including the 'officially packaged' ones)
<heno> right
<dholbach> ok: so only read all specificied clue files, if -r is used, then rely on <sourcepackage>
<dholbach> i'll let   bugxml -s   add that tag also
<dholbach> (we had to rename -sa)
<heno> the question is should bugxml create the official ones or secondary ones?
<heno> you can always cut and paste the content to the official one later
<dholbach> it shouldn't matter... bugxml can't write to /usr/share/bughelper/packages anyway - or did I overlook something?
<heno> you're right. would the local files contain only one package or could I have my_clues.info with 5-6 packages, each identified by the source tag?
<heno> dholbach: ^
<dholbach> i'd prefer to have them separated, but we can also agreggate them if need be
<heno> I guess we are getting into areas of personal workflow taste. How hard is it to change this stuff later
<dholbach> once we'll have masses of people committing to ./bughelper/packages we'll also have less conflicts if we don't sum up all clues to one big xml file
<heno> (point being that we should pick a route and go with it)
<dholbach> I don't think it's going to be hard - it'll just mean that we have to parse one giant file instead of being able to pinpoint to one single file based on the source package name
<heno> oh, I wasn't suggesting the official clues be all in one file, just my personal ones
<dholbach> we'd have to change the xml format a bit
<dholbach> i'll think about it... as you said: it's good to decide this early
<heno> yeah, don't bother. Better to just make a directory and stick secondary files in there (locally) with the same name as the official
<dholbach> I think that'd fit well into the spec like discussion we had yesterday about OrganisingClueFiles
<heno> ~./bughelper/clues
<dholbach> heno: I think it's easier to do that, because bugxml -s already does that for you - it adds clues to packages/<sourcepackage>.info
<heno> right
<dholbach> we could use BUGHELPER_LOCAL_CLUES_DIR :-)
<dholbach> i'll write something up in BugHelper/Dev in a bit
<dholbach> now that I reviewed all patches and wait for people to reply
<heno> cool
<dholbach> https://launchpad.net/bughelper/+milestone/0.1 looks quite good, if you ask me
<dholbach> I think I just fixed 79150 too
<dholbach> heno: if you have a good test case for bug 79150 let me know - I'm just trying -A ubiquity
<Ubugtu> Malone bug 79150 in bughelper "Don't dupe on multiple finds" [High,Confirmed]  https://launchpad.net/bugs/79150
<heno> dholbach: a large number of ubiquity bugs do this. the traceback is in the original post and is repeated in the syslog
<heno> dholbach: this https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/52228 would do it if you searched on File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 524, in progress_loop 
<Ubugtu> Malone bug 52228 in ubiquity "Installer crashed" [Medium,Confirmed]  
<heno> say
<dholbach> heno: ok, thanks
<mako> mdke: we need to decide if by-hand authentication for coc signing is important enough that we want to implement it.. i get maybe one request a month.. maybe two, the vast majority of those people end up making keys anyway when i suggest it
<mako> mdke: so i sort of think it's probably not worth the trouble
<seb128> iwj: around? how does the gnome-app-install codec API works? there is no --help nor manpage for it
<seb128> iwj: "gnome-app-install --codec=0.10:decoder-audio/mpeg" is supposed to be correct?
<iwj> seb128: Yes.
<iwj> The wiki spec is the documentation.
<iwj> Sorry about the lack of --help; that's because there's not a proper option parser in g-a-i because python sucks.
<iwj> seb128: I take it that gnome-app-install --codec=0.10:decoder-audio/mpeg didn't do what you wanted ?
<seb128> the wiki has --codec=theora as example
<seb128> no
<seb128> $ gnome-app-install --codec=0.10:decoder-audio/mpeg
<seb128> no suitable application
<seb128> that's ii  gnome-app-install        0.3.6                    GNOME Application Installer
<iwj> (Although I'm not sure whether there's anything for decoder-audio/mpeg.  What package are you expecting it to offer and does it have a .desktop file anywhere?)
<seb128> and there is a .desktop for gstreamer0.10-plugins-ugly listing decoder-audio/mpeg
<iwj> Hmm, must be broken then.
<seb128> /usr/share/app-install/desktop/gstreamer-ugly.desktop
<seb128> ok
<iwj> Err, gstreamer0.10-plugins-ugly is in universe and not whitelisted.
<seb128> is there a way to say that I want to use universe?
<iwj> Yes, there's a file in /etc you can edit.
<iwj> No, apparently the components whitelist is in gconf.   /apps/gnome-app-install/mime-whitelist-components, default is just `main'.
<dholbach> iwj: bughelper now uses optparse - i can send you an example if you like
<iwj> ian@anarres:~ $ time python -c 'import optparse'
<iwj> real    0m3.885s
<iwj> ian@anarres:~ $ time python -c 'import optparse'
<iwj> real    0m0.143s
<iwj> Too slow!
<iwj> (That's on my Athlon 2GHz.)
<dholbach> ok... maybe somebody ports popt or something to python *shudder* :-)
<seb128> iwj: ok, with universe whitelisted it works better
<iwj> Oh, good.
<seb128> hum, it crashes though
<seb128> Traceback (most recent call last):
<seb128>   File "/usr/bin/gnome-app-install", line 212, in <module>
<seb128>     sys.argv, as, transient_for)
<seb128>   File "/usr/lib/python2.5/site-packages/AppInstall/AppInstall.py", line 252, in __init__
<seb128>     self.search_entry.set_text(self.activation_style.searchString())
<seb128>   File "/usr/bin/gnome-app-install", line 115, in searchString
<seb128>     def searchString(self): return self._codecs.join(' ')
<seb128> AttributeError: 'list' object has no attribute 'join'
<iwj> Right, well, the right answer is to whitelist those packages we're prepared to do minimal security support for, as described in https://wiki.ubuntu.com/SuggestedPackagesForFiletypesSpec under Security Considerations.
<seb128> I've not used a transient-for
<seb128> I'm just playing with g-a-i from the command line atm
<cjwatson> is anyone fixing update-app-install, or should I?
<iwj> cjwatson: How is it broken ?
<iwj> seb128: Oh, ffs, that's the stupid Python 'delimiter'.join([list] ) thing again.
<cjwatson> er, the error message is upstairs and I'm not, but it crashes on start with some python module it doesn't know about
<cjwatson> haven't looked into it yet
<seb128> iwj: that's not going to be done today anyway, libgimme-codec need main promotion and pitti is not around, let's do that monday at the distro sprint
<iwj> update-app-install worked when I left it IIRC.  I can believe that seb128's bug escaped my testing though.
<iwj> seb128: Right.
<cjwatson>    File "/usr/sbin/update-app-install", line 17, in <module>
<iwj> cjwatson: If this all can wait I think it'll be much easier when we're all together.  Is it blocking you now ?
<cjwatson>      from AppInstall.CoreMenu import *
<cjwatson>  ImportError: No module named AppInstall.CoreMenu
<iwj> cjwatson: Freaky.  Probably not my fault, either :-).
<cjwatson> not blocking me, I just noticed the crash log right after an Intel Mac install
<iwj> cjwatson: Right.  Fair enough.
<cjwatson> looked like python2.5 breakage maybe
<iwj> cjwatson: You might like to mention that one to mvo.
<cjwatson> I shall, thanks
<cjwatson> iwj: bizarre, it works when I rerun it. I'll have to dig through logs ...
<iwj> cjwatson: Urgle.
<rexbron> hello,
<rexbron> where can I find information on why a source package was rejected from the NEW queue?
<rexbron> there are no bugs filled against the source package
<cjwatson> the admin doing the reject normally sends a mail to the uploader and ccs ubuntu-archive
<cjwatson> what package?
<cjwatson> there can be no bugs filed (not filled) against the source package until it is in the archive
<_MMA_> cjwatson: https://launchpad.net/ubuntu/feisty/+queue?queue_state=4&queue_text=murr
<_MMA_> Thats what rexbron is referencing.
<cjwatson> From: Tollef Fog Heen <tfheen@canonical.com>
<cjwatson> To: Andrew Hunter <andy.hunter@rogers.com>
<cjwatson> Subject: murrine rejected
<cjwatson> Date: Fri, 19 Jan 2007 11:54:03 +0100
<cjwatson> Message-ID: <87lkjzmgms.fsf@thosu.err.no>
<rexbron> ok ty
<rexbron> silly me
<cjwatson> (for those watching: incorrect debian/copyright)
<_MMA_> Thanx cjwatson.
<mdke> mako: seems sensible
<mdke> elmo: major hugs
<Mithrandir> mdke: -docs accepted today, btw.  I was just blind or diff was playing games with me or something..
<elmo> mdke: eh - if you mean ubuntu-it, Ng did all the work
<mdke> Mithrandir: saw it, thanks :)
<mdke> elmo: I'll hug him separately
<mdke> elmo: since you're here and he isn't, is it ok to add users for the other people I mentioned? 
<mdke> oh, some are there already as separate users
<elmo> mdke: still need me to do anything?  otherwise, I need to duck out
<mdke> elmo: if you can yeah. the server directories are owned by root
<elmo> duh
<mdke> thanks
<elmo> mdke: I have to duck out, if you need anything more, best followup to RT for now
<mdke> elmo: fair enough, thanks. Have a good weekend
<allee> doko: any idea why digikam fails to dyn. loading <name.so> libgphoto2 plugins in dapper and still in debian sid? Edgy and feisty are okay.   
<allee> doko: http://bugs.debian.org/390703  http://bugs.kde.org/show_bug.cgi?id=125696 
<Ubugtu> Debian bug 125696 in ssh "on a fresh install sshd_config can't talk with older version" [Unknown,Closed]  
<ogra> Seveas, ^^^^^^^^^ intresting Ubugtu bug
<allee> doko: sorry http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396249
<Ubugtu> Debian bug 396249 in libgphoto2-2 "libgphoto2-2-dev needed" [Important,Closed]  
<Mithrandir> doko: should I remove gcc-4.0 from the archive?
* ogra gives Mithrandir a long hug
<Mithrandir> ogra: you're aware that pulse will now ftbfs due to a missing MIR for libasyncns?
<ogra> meh, no
<ogra> hmm, pitti didnt see that either ... 
<ogra> i'll add the MIR tomorrow, doesnt seem like i'll get it reviewed before the weekend anyway
<Mithrandir> sure, no hurry.
<giskard> MIR?
<ogra> well, i'd like to have it off the table ...
<Mithrandir> ogra: *shrug*, I have enough other stuff to do this weekend.
<ogra> its trivial but took me half the dev cycle already
<ogra> well, me too indeed
<Lure> giskard: Main Inclusion Report
<Mithrandir> ogra: there's no reason why a main promotion should take more than a week or so, even when not fast-tracked.
<ogra> Mithrandir, it were only three days since i added the dep, thats fine ... i had and still have other probs with pulse tat i didnt expect ...
<gnomefreak> are we expecting to see gnome 2.18 this month? gnome has 2.18 beta1 release on jan 22nd. or are we gonna wait for a more stable release
<mdke> gnomefreak: we always get new gnome releases, no?
<Nafallo> gnomefreak: devel always have the latest gnome, no?
<mdke> generally on the *same day*
<Nafallo> mdke: :-)
<Nafallo> mdke: same hour ;-)
<mdke> heh, that would be insane
<gnomefreak> mdke: Nafallo i know we will get it but i dont know if its around the same day or do we wait for a more stable 2.18 release
<Nafallo> mdke: well. we ARE talking about seb and daniel ;-)
<tepsipakki> gnomefreak: 2.18 will be released in March
<mdke> gnomefreak: we've had every 2.17 release as soon as the tarballs were out, I haven't heard any rumours that that will stop happening
<Nafallo> gnomefreak: the two mentioned always package everything all the time. they are like packaging-monkeys :-)
<Nafallo> or worse even :-)
<Nafallo> but I helped them with a package yesterday! *proud* ;-)
<bddebian> heh
<tepsipakki> put seb and daniel hitting 'debuild -S' for an infinite amount of time, and you'll end up with a package including the entire works of Shakespeare, no?
<LaserJock> haha
<tepsipakki> mm, but would it be distributable? :)
<Kw4k> http://www.visitallday.com/default.asp?partner=Kwak
<Nafallo> tepsipakki: that's up to Mithrandir ;-)
<jdong> random community process question: what governance body handles the revocation of Ubuntu membership? the CC?
<mdke> jdong: there isn't a policy for that. But yeah, it would be the CC if it ever came up
<mdke> jdong: it would be sad if that were needed
<jdong> mdke: ok, cool. It was a purely hypothetical question to help me template some forum policies.....
<crimsun> cjwatson: ping, do -metas ({k,x,}ubuntu-meta) need to distribute a COPYING, or is simply using ubuntu-meta's debian/copyright sufficient for ubuntustudio-meta?
<mdke> crimsun: you got any time?
<mdke> crimsun: thought we might go through some audio troubles
<crimsun> mdke: hi.
<mdke> crimsun: fancy it?
<crimsun> sure, awaiting details.
<mdke> crimsun: I can file a bug if you prefer
#ubuntu-devel 2007-01-20
<pochu> hello everyone
<pochu> do you know if we will see thunderbird 2.0 in feisty?
<doko_> Mithrandir: gcc-4.0: please no, we need it to build libgcc2 on hppa (but no need for it on our supported architectures)
<Mez> pitti; are ddebs up for feisty yet
<crimsun> Mez: they've been up. http://people.ubuntu.com/~pitti/ddebs/
<Jillian> hello
<_ion> -lh
<_ion> Whoops.
<Seveas> ogra, hmm, we live in interesting times :)
<_ion> Yay, tracker is in feisty.
<Mithrandir> doko_: ok, so I'll remove the binaries from i386, amd64, ppc, sparc?
<Seveas> _ion, \o/
<Treenaks> morning
<LaserJock> anybody know if deps of a package getting a MIR have to have seperate MIRs?
<LaserJock> and do B-Ds also have to be in Main?
<Mez> B-Ds do LaserJock not too sure about the other Q
<LaserJock> Mez: ok, that's what I was afraid of. But it makes sense ;-)
<netstar> what screen font does /etc/console-tools/config use, i like the new edgy font and am trying to set it up
<gicmo> compiz and metacity startup is now totally fucked up
<Mez> gicmo, feisty ?
<gicmo> yeah
<Mez> gicmo /topic #ubuntu+!
<Mez> gicmo /topic #ubuntu+1 *
<gicmo> Mez: ?
<Mez> Feisty is NOT stable, and not even close to usable
<gicmo> ahh feisty is not stable ... ahh ...
<gicmo> ;-)
<Mez> gicmo, :P
<gicmo> forgive me my sarcasm ;-)
<gicmo> Mez, it was not even formulated as a complaint, a question or something like that, just as a expression of "shit, that is broken" ;-)
<Mez> oh lol
<netstar> I'm sorry I've looked everywhere and no-one is willing to open up a notepad and look at the file /etc/console-tools/config and tell me the default SCREEN_FONT variable for edgy and +
<netstar> please can someone help me, i've googled my ass off
<netstar> I've also done the IRC thing
<netstar> no joy, and so my last resort is developers
<geser> it's set to lat0-sun16 here (feisty)
<netstar> ty
<afflux> jep, here too.
<netstar> thank you very much
<doko_> Mithrandir: yes please (gcc-4.0)
<jsgotangco> man..did dapper had another re-spin after 6.06.1?
<jsgotangco> jeez none
<bhale> jsgotangco: no.
<bhale> jsgotangco: i am starting to get itchy for the next LTS, 2 years is a long time it turns out
<jsgotangco> i bought this cheap BenQ Turion64 x2 laptop and just installed 6.06.1 the updates went over 100MB+
<jsgotangco> so i was thinking it needs another re-spin in a few months before it reaches a year old
<jwendell> doko_, around?
<alefteris> hi everyone! how do i know which code branch is used on the current edgy packages, for example for this https://code.launchpad.net/edgy-gdm-themes/+branches?field.lifecycle=Any+Status&field.lifecycle-empty-marker=1
<mdke> Ng: around by any chance?
<Ng> mdke: only slightly, sup?
<mdke> Ng: those email aliases, how do you test them?
<mdke> Ng: (and if you have the mysql database details to hand, can you mail em over? Otherwise, it's in rt, so no worries)
<Ng> mdke: /usr/sbin/exim -bt pbarnabe@ubuntu-it.org    for example
<Ng> that will show you what exim reckons it will do with that address
<mdke> Ng: oh, perfect. thanks.
<TuxCrafter> http://ubuntuforums.org/showthread.php?p=2040153#post2040153 like to now your opinions :-D 
<Treenaks> python :)
<TuxCrafter> for example if we start a new GNU GUI toolkit withs language should it be
<Treenaks> TuxCrafter: you don't want a new GUI toolkit
<Treenaks> really
<TuxCrafter> bindings  I meant
<TuxCrafter> new language bindings for gtk qt mfc .net 3.0 cocoa enz
<Treenaks> there _are_ good gtk.net-bindings
<Treenaks> and good python bindings
<Treenaks> and good java-bindings
<TuxCrafter> but you prefer python
<TuxCrafter> have you lookt at D
<Treenaks> is it a compiled language? then it sucks ;)
<TuxCrafter> arguments
<TuxCrafter> i really like compiled languages
<Treenaks> TuxCrafter: faster to work with interpreted languages
<TuxCrafter> Treenask: so you believe the GNU/Linux kernel should be interpreted like python?
<Treenaks> TuxCrafter: no. there are places where compiled languages should be used
<TuxCrafter> :-D
<Treenaks> But coding in Perl/Python is _fast_ compared to C
<Treenaks> no cruft..
<TuxCrafter> the learning curve is sorter
<TuxCrafter> but do you thing python is a good combination with hardware systems
<Treenaks> TuxCrafter: only a bit :) 'I know Perl' vs 'I can write clean maintainable Perl'
<Treenaks> but this isn't the channel for this discussion
<TuxCrafter> :-D
<TuxCrafter> just curios doesn't seem to be anyone else tho
<Treenaks> it's weekend
<humboldt> just one little question: why not using evms for raid and lvm setup in ubuntu?
<humboldt> is it not ready for production systems yet?
<Mithrandir> you're free to use it for raid and lvm if you want it.
<Mithrandir> not everybody likes it
<xpander25008> hello.
<xpander25008> hello
<Taku> hey all 
<Taku> Hey tell me all, I've a funny bug ( or misconfiguration ) : I've just installed Herd2 and I can get connected to wifi, but I can't go on any website except google ( but I can ping any websites )
<Taku> have you an idea ?
<Treenaks> hm
<Treenaks> feisty + mac mini != booting
<Treenaks> (ppc mac mini)
<bettsp> What's the best way to contact the Ubuntu maintainer for Gaim (seb128)?
<bettsp> He looks busy, and I want to clarify some stuff wrt NetworkManager support in Gaim (I wrote the patch for it)
<LaserJock> bettsp: is there a bug report?
<LaserJock> bettsp: you could also email him
<bettsp> LaserJock: I tried to create a bug in Launchpad but it told me to use the upstream bug reporting
<LaserJock> bettsp: you need to file the bug against Ubuntu, not the upstream product
<bettsp> Against Ubuntu Desktop?
<LaserJock> Launchpad differentiates between distros and products
<LaserJock> so you can file a bug against gaim in Ubuntu
<LaserJock> or you could file a bug against gaim the product
<LaserJock> but what it was telling you was that gaim the product doesn't use Launchpad for bug tracking
<bettsp> LaserJock: I tried to do the latter and it failed, looks I want the former
<LaserJock> https://launchpad.net/ubuntu/+filebug should work
<bettsp> LaserJock: I saw that, thanks for the help
<bettsp> https://bugs.launchpad.net/ubuntu/+source/gaim/+bug/80776
<Ubugtu> Malone bug 80776 in gaim "Gaim is not built with NetworkManager support" [Undecided,Unconfirmed]  
<bettsp> Is this adequate?
<LaserJock> bettsp: looks like it, you said you had a patch?
<bettsp> LaserJock: It's already in Gaim 2.0 Beta 4, but you have to set configure to use it
<LaserJock> bettsp: if you have a patch you can attach it to the bug report
<bettsp> But I think some distro packagers think you have to pull in all of NetworkManager to enable it which isn't true (because it's D-Bus)
<bettsp> LaserJock: Do I just submit a patch against the files in the ./debian directory?
<LaserJock> bettsp: that could work. whatever is appropriate. if you have added a changelog entry and everything use debdiff
<okaratas> waw
<okaratas> http://www.ubuntustudio.com/
<okaratas> good enter..
<_ion> How web 2.0
#ubuntu-devel 2007-01-21
<jdong> infinity: ping; MOTU Media isn't in the exception list for pkgbinarymangler for ffmpeg... 
<shaya> anyone else having issues w/ the new gaim in feisty?
<shaya> oscar_list_emblems() is segfaulting it seems
<jdong> infinity: can you also look at https://launchpad.net/ubuntu/feisty/+source/avidemux/1:2.3.0-0.0ubuntu2 for me? It failed with a very strange error that I can't reproduce in pbuilders; and interestingly two of the arches built it fine and executed the exact same commands in the buildlog
<jdong> (and it wasn't a compile task either, so arch shouldn't have mattered....)
<alex-weej> is there such thing as an "ubuntu aesthetics team" or something?
<alex-weej> of which the artwork team would be a subordinate i'd guess
<bhale> mpt is the UI snob
<alex-weej> i mean a team that can be tasked with realizing things that people want to make everything just look sexy
<alex-weej> one that decides things such as font settings
<alex-weej> shadow settings, etc. etc.
<snikker> i'm unable to make a .deb package from source. i've got an error: "dh_install: command returned error code 256"
<somerville32> snikker, see #ubuntu-motu
<snikker> somerville32: ok, thanks
<somerville32> :)
<somerville32> np
<snikker> somerville32: :)
<bytee_> hi, does anyone have any news with regards to: https://wiki.ubuntu.com/PowerPCReview ? I don't see a summary from the Technical Board Agenda ?
<mpt> alex-weej, no, that sort of thing is decided higher up
<mpt> And as for fonts, there aren't really any good typefaces to choose from yet (Bitstream Vera is better than Helvetica was, but it's still blah)
<bytee_> hi, does anyone have any news with regards to: https://wiki.ubuntu.com/PowerPCReview ? I don't see a summary from the Technical Board Agenda ?
<StevenK> Mithrandir: Please give-back scgi on all arches, thanks.
<Mithrandir> StevenK: given-back
<Hobbsee> hey Mithrandir!
<Mithrandir> Hobbsee :-)
<Mithrandir> how was LCA?
<StevenK> Mithrandir: Thank you kindly
<Hobbsee> Mithrandir: was good :)  so was the dinner afterwards
<Mithrandir> good to hear.
<Hobbsee> Mithrandir: didnt see the bottle dance or anythign though :P
<Mithrandir> I'd have to loved to be there.
<Hobbsee> Mithrandir: :)
<Hobbsee> Mithrandir: i'm looking into spainn...
<Hobbsee> -n
<Mithrandir> Hobbsee: that'd be fun.
<Mithrandir> Hobbsee: I'm sure you can get sponsorship if you apply for it too
<Hobbsee> Mithrandir: indeed :)
<Hobbsee> Mithrandir: yeah, i'd have to
* StevenK is curious if Spain would work for him.
<Hobbsee> Mithrandir: could you sponsor something for me, in a minute please?
<simira> Mithrandir: he's busy hunting worms
<Hobbsee> simira: ahhh.  hope he's early then
* pochu is back (gone 00:01:06)
* pochu is away: Estoy ocupado
<Hobbsee> Mithrandir: infinity_ ping @ the edgy-proposed queue
<Mithrandir> Hobbsee: hmm?
<\sh> moins
<Hobbsee> Mithrandir: is wxwidgets2.6 stuck in the queue?
* Hobbsee wishes midmark would just cool it.
<Hobbsee> Mithrandir: if you could sponsor the upload of http://buntudot.org/people/~hobbsee/gnome-applets.debdiff to make gnome-applets installable again, that'd be good.
<Mithrandir> https://launchpad.net/ubuntu/edgy/+queue?queue_state=1&queue_text= is the unapproved queue for edgy, there's a wxwidgets2.6 there, yes.
<Hobbsee> Mithrandir: 403'd
<Mithrandir> Hobbsee: sure, I could do that, or just get seb to do it tomorrow.
<Hobbsee> Mithrandir: can you approve that to -proposed please?
<Hobbsee> you could, yes
<Mithrandir> hmm, I thought the queue was supposed to be visible to everybody. :-/
<Adri2000> the feisty one is
<Hobbsee> Mithrandir: seems not
<Mithrandir> I'm working my way through the queue, but try not to work outside work hours, so if you don't mind, I'll get to it tomorrow.
<Hobbsee> Mithrandir: that's fine.  it's just been there a long time.  
* Hobbsee keeps forgetting it's not monday for everyone
<Mithrandir> Hobbsee: yes, I know.  I started on the queue on Friday, but didn't make it through it all.
<Hobbsee> ah :)
<Adri2000> Hobbsee: looking to your debdiff... isn't it depend*e*ncy?
* Hobbsee notes that the SRU process is well and truly just a mess.
<Hobbsee> dependancy dependency
<Hobbsee> hrm.
<Hobbsee> @spell
<Hobbsee> sucky Ubugtu 
<Hobbsee> Adri2000: seems that both are accepted.  http://www.thefreedictionary.com/dependancy
<Adri2000> ah, ok
<Hobbsee> depends which country you're in, most likely
<ogra> that's why english grammar is so easy ;)
<Mithrandir> Hobbsee: we're working on fixing it, and it doesn't really help that I'm alone doing archive work currently.  We'll fix that in the coming week, though
<Hobbsee> okay, cool
* Hobbsee got bored
<Hobbsee> it's too damn hot!
<Hobbsee> ogra: of course!  *grin*
* ogra envys Hobbsee for the heat
<Hobbsee> ogra: you're a german, right?  you dont win that battle
<Hobbsee> heh.  take it!
<Hobbsee> it's still about 26C, and it's 1am here...
<ogra> Hobbsee, i just landed in oslo ... it's a 10-15C drop 
<Hobbsee> lovely :P
<ogra> and freaking snow all around ...
<Hobbsee> hehe
<Hobbsee> mmm...snow...
<geser> Hobbsee: visit the sprint in oslo http://blog.omma.net/
<ogra> the first winter ever where it doesnt get cold in germany at all ... and i fly to oslo ...
<mdke> you get a proper winter there :)
<Mithrandir> we just got one yesterday.
<Mithrandir> perfect timing
<ogra> i would skip winter completely if i could ....
<mdke> yeah Henrik blogged about it
<crimsun> ogra: (sorry to interrupt) Is it acceptable that pulseaudio installs /usr/bin/pulseaudio setuid root?
* Lathiat prefers winter over summer, except here winter doesn't get below 0 very often :)
<Lathiat> crimsun: it does that to get realtime privs
<crimsun> Lathiat: (yes, I'm currently using it thusly)
<Lathiat> crimsun: restricted to users in group pulseaudio-rt, and drops privs on execution
<Lathiat> ah ok, just thought i'd clarify if you werent sure :)
<ogra> crimsun, pitti approved it ... so i guess it's ok, but i'll ask him if he arrives
<crimsun> ogra: ok, I was thinking that as well. Thanks.
<ogra> i know he inspected it before i wrote the MIR already ... 
<ogra> so he should know about that
<\sh> ogra: hey, how it's going?
<ogra> \sh, well ... 
<ogra> \sh, what would you think ... it's less than 36h ago that i buried fred ... so i'm still pretty bad ... but apart from my belly, all is fine 
<\sh> ogra: yeah, I know...I'm sorry about fred...but you know, just feel a bit happy for me :) carine is pregnant :)
<ogra> congrats !!
<ogra> even though i dont know her, send my greetings
<\sh> ogra: done :)
<ogra> :)
<Chipzz> ogra: (a bit off-topic, if no-one cares) I live in Belgium, and we didn't get a real winter here this year... more like a very long autumn
<Chipzz> which quite frankly has me worried
<ogra> Chipzz, its the same in kassel where i moved to from the belgian border this august ....
<Chipzz> feels like global warming is starting to show some effects
<ogra> seems mostly in europe, which is kind of weird ...
<Chipzz> ogra: oh? you from belgium, or near it?
<ogra> none of the other continents seems to see such stuff
<ogra> Chipzz, i'm originally from hannover, but lived in the eifel in blankenheim for three years ...
<ogra> i would have stayed, but my GF inherited a huge house so we had to move ...
<ogra> i love the area around there ...
<ogra> (and i loved it to only have a 1h drive to fosdem )
<Chipzz> ogra: oh, you coming to fosdem? :)
* Chipzz has been helping out organising fosdem for the last 3 years
<ogra> i'll likely be at an EU conference for edubuntu in italy end of feb ... 
<ogra> if it by whatever reason gets moved i'll be there, for sure
<ogra> fosdem is the one and only serious linux fair you have to go to !
<Chipzz> we're trying to have a better wireless network this year btw :)
<ogra> :)
<Chipzz> not very trivial to do :(
<ogra> yeah, its not that it would be small or something 
<Chipzz> problem last year was the ap's crashing due to too many people associating with some of them
<Chipzz> which is not something which is easy to control
<simira> ogra: ah, are you in town yet? Did you bring Daniel as well?
<ogra> yep, indeed but the year before you had no wlan at all iirc
<ogra> simira, nope, i'm the early bird ... i think i was the first to arrive of the ppl coming today
<Chipzz> ogra: that was 3 years ago, first year I helped out
<ogra> ah, right, 3 years
<ogra> time flies
<Lathiat> en masse wireless networks are a bit of fun :)
<Lathiat> 802.11 sucks :)
<Chipzz> yeah
<Lathiat> more than 3 non-overlapping channels would be a godsend.. heh
<ogra> simira, no i'm lying, i travelled with Brian Murray (new QA guy) without recognizing each other ... he saw my canonical laptop bag when we left the train at nationaltheateret :)
<mdke> oh yeah?
<mdke> he's been keeping quiet about that
* mdke goes to kick bdmurray's ass
<Chipzz> anyway we're going with 3com ap's for the main hallway this year, and linksys for the devel-rooms
<ogra> mdke, that was less than 1h ago ... are you wired to his brain or something ? 
<mdke> I mean, that he's working at Canonical
<simira> ogra: hehe, nice. dholbach just arrived. We'll be there in not very long, dropping by to bring some people on our sunday dog walk in the snow :p
<ogra> i'm not sure brian is bdmurray ... we met first some minutes ago ...
<mdke> ogra: yeah, I looked him up just now on Launchpad
<Mithrandir> ogra: do we have canonical laptop bags or is this something you've had done yourself?
<ogra> Mithrandir, its a HP/shuttleworth foundation/canonical/"go open source" bag i got from one of the SF guys at the first edubuntu conf
<ogra> they made a joint project where they produced these bags ... i got the last one eft
<ogra> *left
<ogra> simira, i'll be downstairs and have a smoke then :)
<ogra> (and wait for ian to give him his room key)
* ogra goes to feed his addiction ... bbl
<bSON> hi
<bSON> is somebody from the ubuntu desktop team here?
<Adri2000> bSON: #ubuntu-desktop ? ;)
<bSON> Adri2000: oh.... :)
<bSON> Adri2000: i just thought, because this here is the developers list...
<bSON> /joi #ubuntu-desktop
<bSON> oops
<bSON>  /join #ubuntu-desktop
<bSON> help!...
<pochu> Mithrandir: are you here?
<jdong> grr, dist-upgrader turned off all my repositories except for main
<jdong> and now I'm pulling lrm debs off the archive and transporting them via DVD :)
<jdong> apparently it isn't amused that I use an apt-cacher
<jdong> and turned all those off as 3rd-party :)
<Chipzz> jdong: does apt-cacher actually work for you? :P
<jdong> yeah, quite well
<jdong> since all my boxes are i386 it does indeed save me quite a bit of redownloading
<Chipzz> also with resuming interupted downloads?
<jdong> yes
<jdong> I've only had one problem with it....
<jdong> it was a corrupted Packages index
<jdong> and it would refuse to re-fetch it :)
<jdong> I had to go in manually
<jdong> apt-proxy also ain't bad
<Chipzz> last time I tried it (which I admit is a whole time ago) it broke terribly
<jdong> but apt-cache to me was faster at apt-get update than -proxy
<jdong> Chipzz: I'm running latest fiesty backported version :)
<Chipzz> yeah, must be over 1.5 years ago on debian
<jdong> lol
<jdong> that's a long time :)
* jdong files bug 80853
<Ubugtu> Malone bug 80853 in nautilus "Nautilus unmount progress dialog should show up for writable DVD+RW/DVD-RAM media" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80853
<jdong> and probably will get smacked in the face for being a crack addict :D
* Chipzz thinks flashplugin-nonfree is on serious crack
<Chipzz> https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/80545
<Ubugtu> Malone bug 80545 in flashplugin-nonfree "Don't use /usr/lib/flashplugin-nonfree-unpackdir" [Undecided,Unconfirmed]  
<Chipzz> that's just... so broken :(
<jdong> yeah, I encounted that too when backport testing
<jdong> it's better now then it was with the 1st F9 beta
<Chipzz> whoever came up with that deserves some serious readjustment with a cluebat
<jdong> when it'd ASSUME that flash was already downloaded and not say anything/silently fail
<jdong> unless you run it with debconf low priority
<jdong> infinity_: ping?
<tarzeau> tsmithe: gnu/kfreebsd is pretty nice, you just don't have enough patience
<tsmithe> tarzeau, yeah - i would have thought it was... it just panics in virtualbox though
<tsmithe> and i can't be bothered to use kqemu
<tsmithe> :)
<tarzeau> tsmithe: it works fine in vmware, real and qemu
<tsmithe> not vbox; which is the fastest free vm here. vmware doesn't work (clock problems) and kqemu is slow
<tarzeau> tsmithe: is vbox packaged already?
<tsmithe> not the open source version
<tsmithe> i just built from svn
<davmor2> noticed an error with gossip telepathy but wanted to check if it was being worked on before I submit a bug.  You can't changed you personal details.  When you click save nothing happens.  If you click on edit to check the whole thing is blank again.
<Zdra_> davmor2: contact information are not currently supported by telepathy
<Zdra_> it's not even in the spec
<davmor2> bddebian: this is in gossip so I don't know if it is something that was in the original code base but if you click on edit you get accounts/personal info/preferences
<Zdra_> davmor2: gossip and gossip-telepathy packages are not modified in ubuntu, so I doubt bugs comes from ubuntu... they can be reported upstream ;)
<davmor2> no probs thanks
<Zdra_> davmor2: for gossip-telepathy, features missing are known so it's useless to report them
<Zdra_> bug I would be happy to have crash reports
<davmor2> bddebian: try editing the personal details and hitting save it just freezes.
<davmor2> no crash report though
<Zdra_> if it free you should report too, what I mean is it's useless to open a bug saying for example "I don't see avatars using MSN account" because avatars are just not yet implemented, as for contact information, etc... you should report when there is a problem like a crash or a freeze
<davmor2> right thanks bddebian
#ubuntu-devel 2008-01-14
<crimsun> somerville32: thanks for helping clean up the menu clutter
<somerville32> crimsun, :)
<Seveas> the menu is empty now? :)
<crimsun> as far as PulseAudio apps in Applications>Sound & Video, it's much cleaner.
<pochu> doko: is there any chance we can get in the patch from http://bugs.python.org/issue1583 ? That will allow us to get http://bugzilla.gnome.org/show_bug.cgi?id=481569 fixed in Hardy.
<ubotu> Gnome bug 481569 in gtk "Calling gobject.threads_init() causes a lot of wakeups" [Normal,Resolved: fixed]
<Vad1> Is an experienced coder needed anywhere? One is willing to help - http://ubuntuforums.org/showpost.php?p=4130846&postcount=30. But I don't know where to direct him.
<ScottK2> Vad1: How about #ubuntu-motu.
<Vad1> ScottK2: Mk.
<crimsun> the most apropos one is in the topic of this channel.
<crimsun> --> http://wiki.ubuntu.com/UbuntuDevelopment
<ScottK2> That too
<mjg59> keescook: The currently shipping version of libdisasm (which seems to date from 2004) is Artistic License 1.0, which isn't GPL compatible. The CVS on Sourceforge doesn't seem to have been touched since then. Is there another version you were talking about?
<mjg59> keescook: And the 0.22 tarball doesn't seem to have a license file at all :)
<emgent> Nafallo, ping
 * calc wishes he could resume on amd64 arch
<calc> i upgraded to 4gb ram and ~ 700MB is missing on i386
<RAOF> calc: Sucks that you can't resume.  I can.
<calc> i have 965 video and it won't resume :(
<calc> hmm i wonder if upgrading my bios would help
<calc> i saw a new one is out
<calc> that would be nice if it does
<calc> wow vista is actually responsive after upgrading from 1gb -> 4gb of ram :)
<calc> grr i still lose 700MB in x86_64 for whatever reason
<calc> probably bios is too dumb to relocate the pci stuff
<calc> and still no resume from sleep on x86_64 :-\
<calc> so back to i386 again
<persia> calc: Just stop sleeping :)
<ScottK> Sleep is for the weak.
 * RAOF thought sleep was a WoW game mechanic
<pitti> Good morning
<ScottK> Good morning.
<StevenK> Morning pitti
<pitti> hey guys!
<emgent> morning *
<dholbach> good morning
<ScottK> Heya dholbach
<dholbach> hey scottK
<emgent> heya dholbach :)
<dholbach> hey emgent
<dholbach> hey thekorn
<dholbach> how are y'all doing?
 * pitti hugs dholbach
<emgent> lol
 * dholbach hugs pitti back
<dholbach> man... some people have been very busy over the weekend...
 * dholbach dives head-first into his inbox
 * emgent working to desktop look
<thekorn> good morning dholbach
<ion_> Hi all
<ion_> I slept 20 hours last ânightâ. :-)
<dholbach> ion_: congratulations... my dog kept me up most of last night *yawn*
<ScottK> infinity: Ping - I was wondering how the sbuild problem with virtual versioned provided was going ...
<Burgundavia> ugh, I wish LP did browser agent sniffing to tell us which version of Ubuntu bug reporters used
<Burgundavia> with three supported and one development distro, figuring out which they are reporting their bug against is very difficult
<StevenK> Burgundavia: 4 supported.
<Burgundavia> dapper, feisty and gutsy
<Burgundavia> is edgy still?
<Burgundavia> right, it is
<StevenK> So, four
<Burgundavia> yay
<Burgundavia> anyway, I need to sleep
<Tonio_> hello to all
<dholbach> hiya Tonio_ - hey persia
<persia> good day dholbach
<geser> good morning
<mdke> morning all
<dholbach> hey geser
<geser> hi dholbach
<Mithrandir> slangasek: do you know if kerberos has any concept of .local support?  it might be interesting to have some integration there for hosts where you can't be asked to set up DNS (because it's a home network with five machines and so using .local is convenient, but that loses you kerberos support)
<geser> is there an "inofficial" limit for packages in the archive? will a 700 MB source package building an arch:all data package (probably the same size) get accepted?
<tjaalton> geser: just curious, what package?-)
<geser> tjaalton: urbanterror-data on revu (data files for the urbanterror game)
<tjaalton> that's big :)
<persia> geser: I asked the archive admin ML about inclusion of a 100MB file currently externally hosted a few months ago, and have yet to get a response, which leads me to the belief that it's currently handled by the NEW processor of the day.
<cjwatson> 700MB> I think it would have to be pretty important
<pitti> Richte libflickrnet2.1.5-cil ein (25277-6) ...
<pitti> * Installing 1 assembly from libflickrnet2.1.5-cil into Mono
<pitti> ! Assembly /usr/share/cli-common/policies.d/libflickrnet2.1.5-cil/policy.2.1.FlickrNet.dll does not exist
<pitti> is this a known bug?
<cjwatson> I wouldn't be happy about accepting a package that big
<Mithrandir> pitti: I see it too, at least.
<seb128> pitti: it was supposed to be fixed in -6
<persia> pitti: There was discussion about it in the last 24 hours.  There's some issue with how mono handles alternatives that was last thought to be the culprit.
<cjwatson> bug 182130
<ubotu> Launchpad bug 182130 in libflickrnet "package libflickrnet2.1.5-cil 25277-5 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,In progress] https://launchpad.net/bugs/182130
<pitti> ok, thanks
<Mithrandir> doko: how hard would it be to build icedtea for lpia for gutsy?
<doko> Mithrandir: the current one?
<Mithrandir> doko: yes
<Mithrandir> (in a PPA)
<doko> it should build out of the box; let me have a look at the b-d's.
<Mithrandir> thanks
<doko> ion_: ruby1.9 is universe, isn't it? Does Debian build with -g now?
<ion_> doko: Yes, and Debian has the 1.9.0.0 release, whereas Ubuntu has a pre-1.9.0.0 snapshot.
<ion_> (As in yes, it builds with -g)
<bigon> could someone have a look at bug 182509 ?
<ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
<bigon> this is needed to fix bug 182130
<ubotu> Launchpad bug 182130 in libflickrnet "package libflickrnet2.1.5-cil 25277-5 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,In progress] https://launchpad.net/bugs/182130
<doko> pochu: can you test the patch for python2.5?
<pochu> doko: sure, I'll patch it and see the results in pygtk applications and make a bug report if that's fine.
<cohonen> hey guys
<cohonen> how do i get qt-4.4 installed
<cohonen> ?
<doko> pochu: thanks
<cohonen> anyone
<cjwatson> cohonen: please see the topic
<ogra> cjwatson, do you think its possible to get an entry for "Install a thin client server" on the alternate CD ? UI space should suffice for another entry and i'd like to have it easier than "add ltsp-client-builder/run=true to your bootoptions" ...
 * ogra grumbles about broken mono deps on the daily
<cjwatson> ogra: need to do the planned reorganisation of the whole menu first, I think ...
<cjwatson> (which is on the hardy list)
<cjwatson> would that be ok? I'd rather do it that way round if possible
<ogra> oh, i wasnt aware there was more planned ...
<ogra> sure
<ogra> for testing i can give my users instructions on preseeding its not *that* hard :) i just want it to be easy in the final CD
<Mithrandir> doko: icedtea seems to ftbfs with genCharsetProvider.sh: 51: addNotices.sh: not found
<ogra> pitti, SHRIEK !!!! bug #182262
<ubotu> Launchpad bug 182262 in gnome-screensaver "gnome-screensaver-gl-helper crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/182262
<ogra> looks like apport triggered 650 retraces, one every 4 min over the whole weekend
<seb128> nice ;-)
<seb128> ogra: you got mails? ;-)
<ogra> i didnt have the balls to even open my bugs folder until now sicne it showed over 800 bugs suddenly
<seb128> heh ;-)
<ogra> yeah, tons
<seb128> ogra: you are lucky, the i386 retracer crasher yesterday apparently ;-)
<StevenK> Haha
<seb128> ogra: I'll wait on pitti before restarting it
<ogra> wow, thats like wining the lottery \o/
<pitti> ogra: eww
<seb128> no, in fact that's the gutsy retracer which crasher
<seb128> pitti: where are the hardy retracers running?
<pitti> seb128: hm, 2007-09-21 02:06 retracer-amd64.log
<pitti> that's quite outdated
<pitti> seb128: seems we don't have a current log for amd64
<pitti> and I can't find that bug in the log
<seb128> me neither
<pitti> seb128: it's the very same
<pitti> seb128: crash-digger seems a bug, parses the release out of it and uses the corresponding chroot
<pitti> seb128: I restarted the i386 one, I'll watch it for a bit
<seb128> ok
<pitti> seems it has troubles with removing the tag or so
<pitti> "Consolidating duplicate database...", will take a while
<seb128> why?
<emgent> pitti, can you sponsorize my security patch in universe ?
<emgent> (gutsy, Feisty)
<pitti> seb128: it updates its internal duplication db against the real LP to see which bugs have been fixed, to do the appropriate action on duplication
<pitti> ogra: sorry for the mess
<ogra> pitti, ah, well it was a relief to see they are all on one bug, easily solved by selecting and "mark as read" :)
<geser> ogra: be happy that it didn't happen over the christmas vacation :)
<ogra> geser, i am !
<ogra> i hade over 4000 mails anyway after that ....
<pitti> seb128: log files fixed; amd64 was using the i386 one, and i386 didn't have a log
<pitti> so, I can't find out what happened before
<seb128> ok
<pitti> ogra, seb128: I wrote an apology to the submitter
<seb128> pitti: good idea
<seb128> pitti: did you figure what was wrong with the retracer?
<pitti> still consolidating
<pitti> I should have started it without -i
<Ng> does suspend/resume stuff in hardy use acpi-support or pm-utils at the moment?
<pitti> Ng: pm-utils
<Ng> okidoki, thanks :)
<pitti> Ng: suspend to ram broken for you as well?
<Ng> pitti: the suspend end works, but on resume my graphics get very confused and I wanted to check if I should be trying quirk things or acpi-support things
<pitti> Ng: right, same here (Intel GMA950, dell laptop)
<Ng> pitti: I filed the thing I'm seeing as #182791
<Kmos> geser: you already talk to some lp admin about the package checkstyle problem when moving to universe?
<geser> Kmos: yes, cprov fixed it already
<Kmos> nice :) thanks
<gpocentek> Could an archive admin get the goffice binaries out of new (soname bump)? thanks
 * Hobbsee hides
<Kmos> gpocentek: you need to slangasek wake up :)
<Hobbsee> ooh, it's in main.  i could even do it
<seb128> Hobbsee: are you doing it then?
<Hobbsee> seb128: no, go ahead.
 * Hobbsee doesn't like doing libraries
<geser> Hobbsee: is there a reason why you wouldn't do it if it were in universe?
<seb128> Hobbsee: why?
<seb128> Hobbsee: it's binary new for a soname change
<Hobbsee> geser: yeah - because i'd have to get an archive admin to go and new it.
<Hobbsee> seb128: this is true.  which is why i was even considering it.
<seb128> Hobbsee: you do it ;-)
<Hobbsee> seb128: i'm unsure of whether i'd actually pick the required stuff to change, with a soname change though.
<Hobbsee> geser: er, s/new/move/
<pitti> Hobbsee: cannot override to universe using the web ui
<pitti> s/://
<seb128> Hobbsee: the soname change comes from Debian it should be alright, just new it
<Hobbsee> right
<geser> could someone NEW libdom4j-java (dom4j)? some builds are waiting for it
<Kmos> the same for package mythbuntu-common :)
 * Hobbsee does it then
 * seb128 hugs Hobbsee
 * Mithrandir kicks gnome-keyring-daemon
<seb128> Mithrandir: hanging?
<Mithrandir> seb128: overwriting SSH_AUTH_SOCK which breaks my ssh agent.
<seb128> ah, right
<seb128> there is a bug open about that
<seb128> any reason you don't want to use the keyring agent?
<Mithrandir> it doesn't talk to my smart card reader, I believe?
<Mithrandir> if I can get it to do that, then that's fine.
<Hobbsee> seb128: please shove mythbuntu-common back to universe
<pitti> argh, f-spot-import doesn't even allow me to select a directory now, nor any layout
<Hobbsee> or pitti, etc
<Keybuk> pitti: if I want to get HAL to stop trying to automount a partition on a specific SD card (because it fails because it mounts the entire disk), I need a custom FDI for that, right?
<seb128> Mithrandir: you can put your keyring on a stick yes
<pitti> Keybuk: I'm afraid so, yes
<Keybuk> pitti: where do they go?
<Mithrandir> seb128: uh, no.  My key is on a smart card, similar to a banking card, it's not on a disk at all
<pitti> Keybuk: you can add it to /etc/hal/fdi/policy/preferences.fdi
<pitti> or create a new one in that dir
<seb128> Mithrandir: ah, dunno about that
<Keybuk> there's no ~/.config or anything?
<pitti> Keybuk: there's an enabled example about not mounting internal drives; you need to match on a different property of course, such as a label or UUID
<Mithrandir> seb128: so if it advertises PCSC support or something like that, there's a chance for it working, but otherwise, it probably won't work.
<pitti> Keybuk: there could be something gconfish that gnome-mount reads (like in the volume/drive properties dialog), but there isn't ATM
<Hobbsee> evand: if it was you who unmoderated the falcon stuff, be aware that it's already gone thru the motu list, and the motu-council list, and probably doesn't need to go thru -devel as well
<Mithrandir> seb128: is upstream working on fixing the overwriting of the variable or would you accept a patch fixing it?  It should be simple (if (getenv("SSH_AUTH_SOCK" == NULL) { putenv(...);} )
<seb128> Mithrandir: it's probably not, no, there is a gnome-keyring-daemon command line argument to not use the ssh-agent but since the code to launch it is hardcoded in gnome-session there is no way to use it at the moment
<seb128> Mithrandir: they are working on it and it'll be fixed before hardy
<evand> Hobbsee: ah damn, sorry about that
<Mithrandir> seb128: ah, sounds good
<evand> I'll be sure to reject future attempts to continue the discussion on ubuntu-devel, though.
<Hobbsee> evand: no problem.  you don't read all lists :)
<Hobbsee> newqueue--
<Keybuk> pitti: do HAL matches automatically check the parent too?
<Hobbsee> dholbach: is it worth rejecting falcon until you guys figure out your naming?
<pitti> Keybuk: you have to explicitly match on it
<dholbach> Hobbsee: reject what?
<pitti> <match key="@storage.originating_device:@info.parent:usb_device.product" contains="Motorola Phone (V3i)">
<Hobbsee> dholbach: falcon.  motu ML
<pitti> for example
<dholbach> Hobbsee: is there a falcon still in the queue?
<Hobbsee> dholbach: yes
<bigon> nobody for reviewing (and uploading) the patch in bug 182509 ?
<ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
<Hobbsee> dholbach: the repo creator
<dholbach> Hobbsee: it's already in the archive, isn't it?
<Hobbsee> dholbach: binary new
<dholbach> Hobbsee: I really wished this would have been discussed with the archive admins before :-
<dholbach> :-(
<Hobbsee> yeah, well...
 * Hobbsee notes that she's not on any archive admin list
<dholbach> if the programming language could rename source and binary to falconpl and the other falcon (repo-package) would rename /usr/bin/falcon to something else, I feel we'd be all set
<dholbach> soren proposed this solution
<cjwatson> Hobbsee: you're not on ubuntu-archive@lists?
<Hobbsee> cjwatson: it seems not.
<Hobbsee> cjwatson: i looked thru it once, but never subscribed.
<Hobbsee> it also occurs to me that we have no release team list
<soren> dholbach: Er.. no.
<soren> dholbach: I did not.
<cjwatson> Hobbsee: we do as of quite recently; ubuntu-release@lists
<Hobbsee> cjwatson: excellent.  looks like i have some subscribing to do then
<soren> dholbach: I proposed leaving the programming language as /usr/bin/falcon and renaming the repository thing to something else.
<cjwatson> though nobody's ever posted to it
<dholbach> soren: right... and in another part of the thread the package name "falconpl" was discussed (as it's the name of the home page, etc) already
<soren> dholbach: Yes, renaming the source package to falconpl seems completely sensible to me.
<dholbach> both steps together seem to me to be a technical solution to the problem
<_MMA_> https://lists.ubuntu.com/archives/ubuntu-motu/2008-January/003034.html
<soren> _MMA_: Thanks :)
<_MMA_> ;)
<soren> dholbach: Oh... NOw I see, what you're saying.
<dholbach> soren: does it make sense? :)
<soren> dholbach: When you said source and binary, you meant "source package and binary package" and not "source package and the binary file".
<dholbach> soren: yeah, sorry
<soren> dholbach: ...with that in mind, yes, it makes perfect sense :)
<dholbach> if we can all agree to doing that now and discuss things with archive admins earlier next time I feel it's all good - there should be no need for dispute because of this
<soren> Agreed.
<Hobbsee> cjwatson: right, now i have no excuse to be behind on things
<Hobbsee> or at least, i don't after you approve that
<Keybuk> aha! storage.no_partitions_hint, that sounds exactly like what I want :)
<cjwatson> Hobbsee: done. er, twice, apparently
<Hobbsee> cjwatson: yeah.
<Hobbsee> cjwatson: there is a reason.
<cjwatson> I'll take your word for it
<Hobbsee> it's not a good one
<pitti> Keybuk: btw, I tested f-spot now, reported some bugs about why it is not working at all for me, and updated https://wiki.ubuntu.com/DesktopTeam/Experiences/ManagingPhotos; I guess I can't convince you to rethink the switching of the default :), but you asked me a while back to update that page
<Keybuk> pitti: your bugs are about people who already have photo collections though, right?
 * pitti flips the default now, *shrug*
<pitti> Keybuk: yes
<Keybuk> so those people already have Ubuntu installations
<Keybuk> the default only affects people with new installations, and assumedly, new photo collections
<pitti> Keybuk: bug 182852 affects other people, too
<ubotu> Launchpad bug 182852 in f-spot "photo directory should default to XDG user dir setting, not ~/Photos" [Low,Triaged] https://launchpad.net/bugs/182852
<pitti> but at least that's a relatively easy one to fix
<pitti> Keybuk: well, installing Ubuntu != using a computer the first time
<seb128> pitti: you know about "f-spot -view directory" right?
<Keybuk> pitti: sure, but usually after installing a new OS, you still need to import your photos again
<pitti> seb128: no, I don't; I used View -> Arrange -> By directory, but that doesn't work
<pitti> Keybuk: so far I didn't have to; in Windows, Debian, and Ubuntu I could just continue to use my existing collection on my /mm VFAT partition
<pitti> Keybuk: well, I'm not saying that I'm the average user :)
<seb128> pitti: you can continue doing that, browse with nautilus, double click and eog is used
<Keybuk> you can still open those folders in nautilus to browse the thumbnails, and double-click on one to bring it up larger, and then use next/previous arrows to browse the collection
<pitti> it just feels weird to me to copy the entire photo collection again, and edit that, and suddenly find that your original photos haven't been changed
<seb128> pitti: I'm not sure what else you need to browse your collections
<pitti> seb128: right, I should try that
<seb128> pitti: that's like you don't start rhythmbox to listed to a file on your desktop, you double click on it and totem is used
<pitti> seb128: I see, that works; I wonder why it doesn't work when I select it in the UI
<seb128> right, it's broken here as well
<pitti> seb128: nautilus> that only gives me a single picture, though, no prev/next
<pitti> (or 'parent', etc.)
<pitti> so, viewing works fine
<pitti> browsing only when called on CLI
<pitti> and no directory navigation whatsoever
<seb128> pitti: press F9
<pitti> well, that could be left to eog, I figure
<pitti> seb128: got that, but it only has a single photo
<seb128> right
<seb128> not sure what is your standard usecase
<seb128> I've those scenario
<seb128> - plug an usb key with some photo to show those, nautilus is open, I double click on the first one and click on next in eog to show the photos
<pitti> seb128: use case: "parents come in, I want to show them some of my photos" :)
<seb128> - want to browse my photo collection and do some changes, I start fspot
<pitti> seb128: right, eog is great, no complaints there
<pitti> I just thought we wanted to consolidate to use just one photo app for everything
<Keybuk> pitti: we're not getting rid of nautilus/eog
<seb128> as said before that's like trying to use rhythmbox to listed to a sound file from an usb key
<pitti> well, except that eog and f-spot are totally incompatible wrt. browsing, file locations, UI, etc.
<seb128> my understanding is that we want to keep eog as a viewer and fspot to manage a photo collection
<Keybuk> why incompatible?
<Keybuk> I can browse the f-spot managed folders in nautilus and use eog on the files :)
<pitti> f-spot is 'object'-based, while eog/nautilus are file-based
<pitti> Keybuk: c'mon, you'll never find the one you are looking for in nautilus
<Keybuk> I don't know what you mean by "object" based here
<seb128> well, the issue is that f-spot should work from a directory library
<seb128> like rhythmbox do
<pitti> I see the idea of f-spot about abstracting away from files
<seb128> rather than reimporting everything
<pitti> just like rb abstracts away from files, too
<Keybuk> seb128: it does?
<seb128> Keybuk: no it doesn't
<Keybuk> like rb, it just has an index file of that directory
<pitti> but unlike RB, f-spot owns my photos, while rb just creates an index from my music
<seb128> Keybuk: it creates this layout using directory by year, etc and copy photos there
<pitti> so I can still keep my existing music colletion without rearranging everything
<pitti> I think RB got the concept really well (I love it)
<Keybuk> pitti: rb owns it too
<Keybuk> I have to import the music into my library
<Keybuk> and then it makes up filenames, etc. under that library
<pitti> Keybuk: but it's not requiring the files to be in any particular directory and layout
<seb128> Keybuk: rb monitors a directory on the disk without touching the files
<Keybuk> (arguably they should both just use tracker <g>)
<pitti> f-spot copies them around and hides them with unintelligible names and directories instead of leaving them alone wherever they are
<Hobbsee> Keybuk: you're just asking to be clubbed in the head.
<pitti> which is ok if you never use anything else than f-spot
<Keybuk> Hobbsee: I'm entirely serious
<seb128> let's not start on the tracker discussion now
<Keybuk> if they both used tracker, it wouldn't matter where the photos/music were, what filenames, etc.
<seb128> it's not going to happen for hardy
<pitti> Keybuk: object-based> abstracting away from the close-to-the-metal files and directories
<Keybuk> pitti: this is a good thing, no?
<Hobbsee> Keybuk: if tracker wasn't such a performance hit, etc, then sure.
<pitti> Keybuk: by itself, yes
<seb128> Keybuk: the thing is that f-spot should monitor a directory you give him without touching anything there, like rhythmbox do, it doesn't right now though
<pitti> Keybuk: but the rest of our desktop, including nautilus, is still by and large file/directory based
<pitti> so it's confusing once you leave the domain of f-spot
<Keybuk> seb128: how do you make rhythmbox do that?
<pitti> Keybuk: import directory/file, done
<seb128> Keybuk: I don't import music using rhythmbox
<pitti> there's nothing else
<Keybuk> seb128: cause I can't
<pitti> Keybuk: RB just creates an index
<Keybuk> pitti: of it's own directory
<seb128> Keybuk: by default it monitors Music, copy any song there, watch inotify notice it and rhythmbox list it
<Keybuk> not any others
<Keybuk> if you import any others, it copies them into its own directory
<pitti> ~/.gnome2/rhythmbox/rhythmdb.xml
<Keybuk> seb128: right, but isn't that just what f-spot does with ~/Photos ?
<pitti> Keybuk: how do you mean? ("own directory")
<seb128> Keybuk: well, there is no way to tell to f-spot "use that directory", it wants to create its own layout and import everything
<pitti> Keybuk: you can add arbitrary directories to RB's collection
<Keybuk> seb128: it's in Preferences
<seb128> or I don't know how
 * seb128 tries
<Keybuk> pitti: yes, and it copies them into ~/Music
<Keybuk> organising them itself
<pitti> Keybuk: no, not for me
<Amaranth> since when did rhythmbox do that?
<Amaranth> i wish it did that
<seb128> Amaranth: do what?
<Keybuk> it's entirely possible I'm wrong, but I've always found rb very difficult to use because of the way its library works
<Amaranth> move music to ~/Music and organize it automatically
<seb128> Keybuk: it doesn't do anything, it just list everything which is in the directory he has been pointed to
<pitti> Keybuk: hm; I love how it works; seems people do have different ideas how to organize stuff :)
<seb128> which means you can download things directly there
<seb128> create directories as you like
<seb128> etc
<seb128> let sound-juicer create albums
<Keybuk> ok
<Keybuk> in f-spot I just did
<Keybuk> 1) made a tree of photos under ~/My Photos
<Keybuk> 2) opened f-spot
<Keybuk> 3) unchecked "Copy into Photos directory"
<Keybuk> 4) selected ~/My Photos
<Keybuk> 5) clicked Import
<Keybuk> now my photos appear in f-spot
<Keybuk> with the original filenames and tree
<pitti> just tried it in RB and confirmed that it doesn't copy a foreign directory; it just indexes it
<pitti> and notices that stuff has gone from it, etc.
<Keybuk> pitti: with Music -> Import Folder ?
<pitti> Keybuk: yes
<pitti> Keybuk: that checkbox for f-spot doesn't exist in the import dialog
<pitti> Keybuk: the camera one, I mean (f-spot-import)
<Keybuk> ?!
<pitti> f-spot-import is the program I'll set in gnome-volume-manager
<pitti> as reaction to plugging in a photo cam
<Keybuk> http://people.ubuntu.com/~scott/Screenshot-Import.png
<Keybuk> it's the first one
<Keybuk> right, but that's now what you're talking about
<Keybuk> you have an existing photo collection you want f-spot to look at without rearranging it
<Keybuk> adding new photos, why not let f-spot name them?
<pitti> and obeying my existing structure when importing new ones, too, of course
<Keybuk> how's it supposed to divine your existing structure? :p
<pitti> Keybuk: because I still want to be able to find them without f-spot :)
<Keybuk> ~/Photos/Auntie Maud/Birthday/eating cake.jpg
<tjaalton> is it the libnss-db update that makes ssh output "/var/lib/misc/services.db: No such file or directory"?
<Keybuk> it sounds like you just don't want f-spot
<tjaalton> I'm getting that a lot
<pitti> Keybuk: just giving me the ability to download them into a particular directory would be enough
<Keybuk> and want to just continue making directories and managing them that way
<pitti> right, because it's compatible with the rest of the world
<pitti> as I said, f-spot makes sense if you use it and only it
<Keybuk> so just click "Open Folder" instead of "Import" ?
<pitti> but as soon as you start swapping photos with other people, the object-based approach gets in your wya
<Keybuk> I don't see how
<Keybuk> I find it *so* much easier to find photos in f-spot
<pitti> I think it could be as easy as allowing me to select a target directory in f-spot-import
 * Keybuk double clicks on the "pitti" tag
<pitti> Keybuk: i'm lost there, since I don't have a spare month to tag all my photos
<Keybuk> my albums were originally in the folder-per-album format
<Keybuk> so I just imported them one at a time, with a tag as I did it
<seb128> Keybuk: does f-spot monitors the directory for you?
<Keybuk> seb128: no idea on that one
<Keybuk> it should, obviously
<seb128> Keybuk: if I copy a new directory with photos in the library there it's not picked by fspot
<seb128> library = the photo directory
<Keybuk> seb128: then it doesn't
<seb128> neither after a restart
<seb128> which means it expect you do get everything imported from the f-spot interface
<Keybuk> that doesn't surprise me
<seb128> well, that's my main issue with it
<seb128> it forces you to import your collection
<seb128> rather that taking a directory as rhythmbox do and inotify it
<Keybuk> sure
<Keybuk> as I've said before, I think both should just use tracker and not try and have their own magic directories
<Keybuk> that's just obvious
<pitti> Keybuk, seb128: AFAIR, seed changes were: -serpentine, +brasero, -gthumb, change g-v-m photo import to f-spot-import, right?
<Keybuk> rb already has a tracker plugin now, right?
<seb128> not that I know
<seb128> pitti: -gnome-btdownload +transmission-gtk
<pitti> seb128: ah, thanks
<pitti> oh, transmission is universe
<pitti> seb128: we can demote gnome-btdownload then, right?
<seb128> pitti: +vinagre (-xvncviewer)?
<seb128> pitti: afaik yes
<Keybuk> pitti: hmm, any time I have the match file in, HAL ignores my device entirely! :-(
<pitti> Keybuk: what did you set, storage.automount_enabled_hint=False?
<pitti> seb128: xvncviewer is already in universe
<Keybuk> pitti: storage.no_partitions_hint = true
<pitti> seb128: you mean remove tsclient?
<pitti> Keybuk: for suppressing automount?
<pitti> oh, I remember
<pitti> you want to work around that raw device *and* first partition bug
<Keybuk> pitti: right
<seb128> pitti: no, maybe nothing to remove there then, didn't we have a vnc client in the default installation?
<pitti> seb128: I thought tsclient coudl do vnc? at least it says so in the selector
<pitti>  tsclient also supports:
<pitti>    * VNC clients (*vncviewer)
<Keybuk> pitti: it doesn't seem to matter what I set
<seb128> pitti: right, I though it was using a vnc viewer though
<pitti> Suggests: vnc-viewer
<pitti> ah
<Keybuk> the minute I set *anything*, HAL starts ignoring the card altoghet
<pitti> seb128: so yeah, seems we don't install any by default ATM
<seb128> desktop: * xvnc4viewer      # needed by tsclient
<seb128> in gutsy
<seb128> did we change that?
<pitti> seb128: ah, '4'
<pitti> seb128: I checked xvncviewer
<pitti> seb128: alrighty
<seb128> me too, I just grepped the seed to look what vnc client we had
<pitti> seb128: we can't drop sound-juicer yet, can we? or should we move that to rb?
<Keybuk> pitti: sound juicer is the only decent ripper/player right now, no?
<seb128> no we can't
<pitti> right, that's what I thought
<_MMA_> Keybuk: Grip and abcde. ;)
<seb128> the rhythmbox UI is too confusing and has no proper preferences to set the format of the directories to use, etc
<seb128> we could change the CD playing command to "rhyhmbox device" though
<seb128> that works nowadays
<pitti> seb128: right, would be nice to have the CD as just another music source in the left bar
<seb128> pitti: that's the case
<seb128> pitti: and "rhythmbox device" switch to the source and start playing nowadays
<pitti> hmm; I should have kept one audio CD in my desk for testing; I banned them all into the attic months ago
<SWAT> I'm using gnome-main-menu and when I click on it (I have two of them, dualscreen, seperate x session setup) on my 2nd screen, it opens on my 1st screen. Is this a Gnome or rather an X.org issue?
<pitti> mvo: will update-manager install new *-desktop Recommends: by default? i. e. if I add seeds as recommends to the metapacakges, will that actually have an effect on upgrades?
<Amaranth> SWAT: #ubuntu
<Hobbsee> pitti: it hasn't previously, afaik
<seb128> SWAT: a gnome-main-menu one
<pitti> ogra, cjwatson: hm, ltsp-client-builder went into the ubuntu installer seed recently; is that supposed to be merged to {go,e,k,x}ubuntu as well?
<Hobbsee> cjwatson: when will the new seeds stuff happen?
<Riddell> pitti: I just merged it to kubuntu
<pitti> Riddell: ah, you just merged seeds? thanks, one merge less :
<pitti> )
<Keybuk> pitti: how do you test new FDI rules?
<pitti> Keybuk: mostly they Just Work (TM) after replugging
<pitti> but you might be required to restart hal
<Keybuk> they're never working for me
<pitti> Keybuk: anyway, you should be able to see the changed properties in lshal
<Keybuk> in fact, the device entirely disappears from HAL if the rules aren't commented out
<pitti> hm; sounds like they have a syntax error or so?
<Keybuk> how would I know?
<pitti> Keybuk: you can run hal in debugging mode
<pitti> sudo killall hald
<pitti> sudo hald --verbose=yes --daemon=no
<pitti> then let it settle, then insert the device
<pitti> FDI errors usually appear there
<Keybuk> ok
<Keybuk> restarting hal breaks gnome-volume-manager, right?
<pitti> no, it shouldn't
<pitti> just restarting dbus will
<pitti> ok, all seeds changed; now I wait for the publisher to get my promotions committed, then I can rebuild *-meta
<Hobbsee> pitti: can you demote mythbuntu-common binary to universe please?
<pitti> Hobbsee: done
<Keybuk> pitti: http://rafb.net/p/SGOWib17.html
<Hobbsee> pitti: thanks muchly.
<seb128> pitti: do you have any idea who cups would not be able to listen on 631 when nothing else is using it according to netcat?
<seb128> pitti: we are discussing bug #135832 on #ubuntu-bugs
<ubotu> Launchpad bug 135832 in gtk+2.0 "evince: libgtkprint support is broken" [Low,New] https://launchpad.net/bugs/135832
<seb128> the cups error log has "E [14/Jan/2008:16:58:50 +0100] Unable to bind socket for address 127.0.0.1:631 - Cannot assign requested address."
<pitti> ugh, no idea; is that gutsy?
<seb128> that's stock gutsy alternate install
<seb128> could apparmor do something like that?
<pitti> Keybuk: "parent_bus is NULL - wrong parent?
<pitti> "
<pitti> ugh
<pitti> Keybuk: I have no off-hand idea about that one, I'm afraid; that looks like a genuine bug
<Keybuk> pitti: how do I stop it auto-mounting just one partition btw?
<pitti> Keybuk: you can set volume.ignore=True
<Keybuk> ah, do I <merge> that?
<Keybuk> (there's not a volume.ignore in the usual list)
<pitti> that will not display that partition anywhere (which is what you want, I think)
<pitti> Keybuk: yes
<Keybuk> yeah
<\sh> moins
<Keybuk> the GPS formats the SD card verrry weirdly
<Keybuk> weird enough to make the disk itself look like a FAT volume
<Keybuk> and with three illegal entries in the partition tables
<Keybuk> need it to just mount p1 and ignore everything else
<Keybuk> how do I anti-match?
<ogra> pitti, xubuntu has ltsp already, edubuntu will go away and kubuntu is up to Riddell
<pitti> ogra: I just merged it to xubuntu
<ogra> they have a dedicated ltsp seed
<ogra> the same as edubuntu
<ogra> (not sure if that was dropped in gutsy though, i had no test reports for it)
<Keybuk> pitti: got it working now :-)  thanks for the help
<pitti> Keybuk: ah, good; I'm still looking for an URL to the hal spec
<Keybuk> I just started reading others and worked it out from there
<ogra> is anyone working on the fspot breakage ?
<pitti> ogra: yes, I just made the breakage the default now :-P
<pitti> ogra: seriously, what do you mean?
<ogra> there is a broken dep
<ogra> it breakes the dailies
<ogra> libflickrnet2.1.5-cil ....
<ogra> i had to remove it today to make my dist-upgrade finish ...
<ogra> Richte libflickrnet2.1.5-cil ein (25277-6) ...
<ogra> * Installing 1 assembly from libflickrnet2.1.5-cil into Mono
<ogra> ! Assembly /usr/share/cli-common/policies.d/libflickrnet2.1.5-cil/policy.2.1.FlickrNet.dll does not exist
<ogra> dpkg: Fehler beim Bearbeiten von libflickrnet2.1.5-cil (--configure):
<ogra>  Unterprozess post-installation script gab den Fehlerwert 1 zurÃ¼ck
<pitti> ah
<Hobbsee> ogra: known, bigon's been asking for a sponsorship of that
<ogra> ah, good
<seb128> ogra: apparently nobody did sponsor the upload though
 * ogra would love installable dailies to test the ltsp changes ...
<seb128> ogra: sponsor the update? ;-)
<ogra> bug # ?
<calc> if i already have 4GB of ram on i386 does having swap make any difference (iow can linux address the swap as well)?
<Hobbsee> ogra: [01:54] <ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
<ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
<ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New]
<mjg59> calc: Yes, Linux can address the swap
<calc> ok
<calc> mjg59: thanks for the help :)
 * ogra hugs Hobbsee 
 * Hobbsee hugs ogra back ;)
<Amaranth> mjg59: What was the bit you were talking about with 0x80 io port and random lockups?
<Amaranth> in your blog
<mjg59> Amaranth: In what way?
<Amaranth> mjg59: You said HP laptops had this problem, was just wondering what that was
<Amaranth> I'd love to blame my random lockups on something other than nvidia+compiz ;)
<mjg59> Oh - Linux uses port 0x80 to delay certain io writes, on the assumption that there'll be nothing there and it'll trigger a bus abort
<mjg59> Some HP systems (mostly the dv6xxx series) have a piece of hardware there
<Amaranth> ah
<mjg59> Which then becomes upset if it's fed a large number of writes
<Amaranth> So I probably don't have that problem, I've got a dv8000
<mjg59> Could still be the case
<mjg59> You can hack the kernel to use 0xed instead
<Amaranth> Well, what are the symptoms? Other than "random lockups"
<Amaranth> Is there something that will trigger it easily?
<mjg59> A tight loop reading from /dev/nvram
<Amaranth> I don't have /dev/nvram :)
 * pitti blinks; https://code.edge.launchpad.net/python-distutils-extra -> the autogenerated header really says "distuils" (note the missing "t"); how can that happen?
<mjg59> modprobe nvram
<Keybuk> pitti: did the libpam-foreground problem get fixed?
<pitti> Keybuk: you mean problem == it exists?
<pitti> Keybuk: I ported dbus over to consolekit yesterday, yes
<pitti> or rather, I taught CK how to create libpam_console compatible tag files and dbus to use them
<pitti> thus libpam-foreground is in universe now
<mjg59> pitti: Sweet
<Keybuk> ah, cool
<mjg59> I'm glad that's going away
<Keybuk> apt wanted to remove it
<pitti> I hope the CK upstream will accept the patch
<Seveas> pitti, I don't see "disutils" anywhere
<pitti> but oh well, eventually we'll get rid of "at_console" dbus policies, I guess
<pitti> Seveas: distuils
<Seveas> pitti, but you said you saw the text disutils :)
<pitti> Seveas: no, I didn't
<pitti> but it seems it's not just me and LP who is confsued abotu speling :)
<\sh> mvo, ping cdrkit, will you add some Provides: and some symlinks to the cdrtools binary app names, as discusson on u-d-d, or should I change the package and provide u-m-s with a debdiff?
<Seveas> pitti, hmm, the t shifted in my head :)
<pitti> Seveas: you clearly drink the wrong kind of tea
<Amaranth> mjg59: ok i guess i don't have that problem then
<Seveas> actually, I drank coffee today for the first time since months
<Seveas> must be it :)
 * soren is about to upload a new dpkg and sweats uncontrollably
 * Amaranth remembers not to update
<\sh> soren, go go go :)
<mvo> \sh: a debdiff would be nice, not sure if I manage to look at it today
<Amaranth> Ah, so I guess I shouldn't start transitioning things to cdrkit?
<cjwatson> pitti: a project's ID isn't necessarily identical to its display name
<cjwatson> the latter is probably misspelled
<pitti> aah
<\sh> mvo, ok..I'll create one (hopefully this evening) just to be sure that we don't have any broken packages in our archives :)
<\sh> Amaranth, nope...no need, when we add some symlinks and provides to cdrkit ...
<mvo> \sh:  thanks
<Amaranth> ok, i already did lsongs
<Amaranth> Guess I should switch that back. Although I'll probably wait for a new upstream release
<mvo> pitti: update-manager should install new recommends to u-desktop (or any package in "metapackages") automatically. if not that is a bug
<pitti> mvo: splendid, thanks
<\sh> Amaranth, just wait for the new paclage to arrive :) first I need to check galculator and then cdrkit :)
<glatzor> bryce: hello
<soren> Here goes nothing..
<Amaranth> \sh: I already uploaded it along with a bunch of changes from the new upstream :P
<Amaranth> But the upstream situation there is kind of confused so I've got some time :)
<Keybuk> soren: but it's the wrong day for dpkg uploads
<Keybuk> dpkg should always be uploaded on friday, just before you get on a plane
<pitti> (don't forget: right before the beta release)
<Keybuk> beta?
<Keybuk> final!
<soren> Keybuk: I'll remember that the next time. :)
<_MMA_> seb128: So I have a clean install of Ubuntu Studio here. We switched to PA like ubuntu. Testing the sound through the "Sound Preferences" dialog works but playing the sounds themselves on the "Sounds" tab does not. Playing the files directly with Totem works fine. I get nothing on startup/down either.
<seb128> _MMA_: could you open a bug on launchpad, I'll have a look later
<_MMA_> np
<_MMA_> Ill test another install of Ubutnu as well.
<pitti> Keybuk: for the record, default apps changes are now done
<keescook> can an archive admin sync "hardening-wrapper" from Debian?  (and then shove it through NEW?)
<Keybuk> pitti: cool, thanks!
<pitti> doko: gdb merge> BTW, b-dep'ing on type-handling is ok now, it's in main and harmless
<doko> pitti: who did let it in?
<pitti> doko: me
<doko> elmo: ^^^ ;-p
<pitti> doko: it's just some collection of Provides: nowadays, nothing bad
<pitti> no more control rewriting or other insanities
 * keescook <3 linux-image-2.6.24-4-generic
<Kmos> pitti: how about to demote tuxtype package to universe. it needs libsdl-pango-dev.
<Kmos> and also demote planner package to universe. it needs libgda2-dev
<pitti> Kmos: that's for ogra to decide; it's seeded in edubuntu
<Kmos> ogra: ping
<pitti> keescook: what's new in linux?
<Kmos> :)
<Kmos> pitti: the planner also seeded ?
<keescook> pitti: ASLR of text.  :)
<pitti> keescook: w00t
<calc> how do you determine the uuid for a fs?
<superm1> pitti, there are two uploads for mpeg4ip.  after discussing with jdong a little, you can reject the one without dfsg in the title right off the bat.  it was repacked and the license improved on the second.
<geser> Kmos: what about check if planner builds with libgda3-dev which is in main?
<pitti> keescook: hardening-wrapper synced/NEWed
<pitti> calc: vol_id /dev/foo
<keescook> pitti: great! thanks.  :)
<keescook> pitti: aslr> http://paste.ubuntu-nl.org/51907/
<calc> pitti: thanks :)
<pitti> superm1: done
<superm1> thanks pitti
<jdong> superm1: I passed our agreed debian/copyright and a heads-up about repacking to Christian... I feel sorry for how much spam he's gotten from us two!
<superm1> jdong, :)
<pitti> Kmos: yes, but to supported only, and no reverse depends in main
<Kmos> geser: that's a good idea :) thanks
<superm1> jdong, if we convince him to build depend on the libavcodeccvs | libavcodec  etc, we might be able to get it to the point that we can just sync in the future :)
<Kmos> pitti: we need to check first if it builds fine with libgda3-dev, thanks
<jdong> superm1: that all depends on if we can get the guy to agree to repacking. My gut feeling is that he could care less about the issue and would rather have the convenience of directly pulling upstream tarballs
<superm1> jdong, could always write a get-orig-source that does this for debian/rules
<superm1> i've done that in the past for repacked tarballs that i didn't want to have to deal with having to do manually every time
<\sh>  mvo bug #182934
<ubotu> Launchpad bug 182934 in cdrkit "cdrkit update for cdrtools removal" [Undecided,New] https://launchpad.net/bugs/182934
<Mithrandir> calc: what's up with ooo ftbfs-ing on amd64?
<calc> Mithrandir: it appears gcj uses huge amounts of ram (< 2GB though) and causes it to fail on the buildd
<calc> Mithrandir: it works fine on my home pc that isn't doing other things with 2GB ram available
<calc> Mithrandir: gcj fails for what looks like the same reason on lpia (runs out of memory)
<Mithrandir> calc: why do you think it runs out of memory?
<keescook> doko: libxml2 on hardy FTBFS for some not-obvious-to-me reason
<calc> it says it does on lpia and the type of fault someone mentioned isn't normal and was likely due to memory on amd64 as well (i don't recall who mentioned that)
<calc> Mithrandir: and it builds fine with same source on my amd64 box
 * calc looks at the amd64 build log again
<calc> Mithrandir: the ppc failure is easy to fix, the sparc failure i am not sure about it seems to nearly always ICE on sparc
<calc> oh yea the other thing about amd64/lpia build is it fails in the same spot on both, lpia runs out of ram and amd64 ICEs (well the first time) looks like it retried and just timed out the last time
<bryce> heya glatzor, how goes?
<calc> the previous build failure for amd64 on that code was an ICE of some sort
<glatzor> bryce: looking at the new xorg.conf style not so well :)
<Mithrandir> calc: the amd64 is it timing out, not ICE-ing, which is why I'm asking about why you think running out of memory has anything to do with it.
<calc> Mithrandir: that is the second failure on the same upload
<calc> Mithrandir: the first time it ICEd the second time it timed out
<calc> Mithrandir: both failures are in the same spot that on lpia it ran out of memory
<calc> and i was able to build it fine on my amd64 with the same upload that failed twice on the amd64 buildds
<calc> amd64 is my local arch i build on before uploading
<Mithrandir> using sbuild?
<calc> /usr/bin/gcj-4.2 -c -g -O2 -fPIC -findirect-dispatch -fjni unoil.jar.1.jar -o unoil.jar.1.o
<calc> jc1: out of memory allocating 4064 bytes after a total of 934146048 bytes
<calc> Mithrandir: not using sbuild but a clean chroot that is generated for each new upload
<calc> Mithrandir: and this type of problem has been around for a while with gcj, i just need to talk to doko about it when he is back (if he is back from vacation yet)
<calc> doko: ping
<Mithrandir> he was around earlier today
<calc> oh ok
<doko> calc: around (still in vacation). please check with gcj-4.3 from the ubuntu-toolchain ppa (and/or send me the unoil.jar.1.jar file)
<bryce> glatzor: yes most  of xorg.conf is gone now
<calc> doko: ok i can send you the jar file it builds fine for me on amd64 already so i doubt my testing of gcj-4.3 would show much
<calc> doko: i think i cleaned out the build already but i will regenerate it and copy the file out
<calc> doko: how is the progress of icedtea coming?
<bryce> glatzor: perhaps we ought to re-look at how we do GUI xorg configuration
<bryce> glatzor: I suspect the way xorg.conf is going, it may be invalidating some of displayconfig-gtk's core assumptions
<glatzor> bryce: indeed.
<glatzor> bryce: perhaps we could talk about this tomorrow
<bryce> glatzor: sounds good
<superm1> bryce, is there a proper way to query drivers in use and such when they aren't explicitly listed in xorg.conf then?
<slangasek> Mithrandir: I've never heard of anything being done with Kerberos and mDNS, no.  you can put .local names /in/ Kerberos as principals, but.
<bryce> superm1: the only authoritative way is to parse from Xorg.0.log
<superm1> whew yuck.
<bryce> superm1: yeah I know
<superm1> especially if you end up starting on a different display
<superm1> i'm surprised there are no bindings out there to query the x server and ask such things
<bryce> in my dreams where I have ample extra time, I fantasize about adding an API to X for querying these sorts of things
<bryce> I've dug through the source code and there aren't even hooks to do it though - it'd be a significant infrastructure task
<bryce> yeah, you'd think xrandr or xdpyinfo would have something like that
<bryce> but no, you'd need to build up an API call in the X server, and probably have to extend the X protocol (dunno what's involved there), then add the calls to whatever X clients need it
<bryce> I talked with a couple people at XDC about it, but they didn't see the use of exposing this info to users.  Their opinion was that xserver should autoconfigure itself, and so that info shouldn't be needed at all.
<bryce> so I just nodded and walked away slowly.
<superm1> how very unfortunate.
<superm1> maybe a good proposal for a google summer of code project this next summer
<bryce> well, I think they'd be open to being sent a patch, but it didn't sound like it'd be anywhere on their radar
<superm1> considering the amount of work that will be necessary
<bryce> oh yeah, that could be
<bdmurray> Riddell: I'm looking at the SRU verification for bug 162233 and I'm not certain how long of a username I need to recreate the bug.
<ubotu> Launchpad bug 162233 in kdelibs "KIO FTP is shortening the URL" [Undecided,Fix committed] https://launchpad.net/bugs/162233
<Keybuk> call it the XWTF extension
<bryce> Keybuk: :-)
<Kmos> slangasek: please accept (dom4j) package in NEW.
<Amaranth> superm1: our compiz shell script does this
<Amaranth> superm1: you can discover the log used for the server you're running on so that's no problem
<Riddell> bdmurray: I don't know the exact length I'm afraid, it might even be dependent on the width of your location text field
<bdmurray> Riddell: hmm, I'll experiment a bit more then
<slangasek> Kmos: all in good time
<Kmos> slangasek: ok =) thx
<Riddell> bdmurray: it might get truncated in the popup username/password dialogue, so try entering an ftp url without a username or password and having a small window there
<nxvl_work> i need a given back for bioperl
<nxvl_work> can someone?
<Mithrandir> nxvl_work: given-back
<nxvl_work> Mithrandir: that
<nxvl_work> :P
<calc> yea compiling unoil.jar.1.jar even on my system is a bear, it makes it nearly unnresponsinve
<geser> nxvl_work: a rebuild won't help for bioperl until bug #178536 gets fixed
<ubotu> Launchpad bug 178536 in sbuild "Preinstalled Build-Depends not properly detected" [Undecided,New] https://launchpad.net/bugs/178536
<nxvl_work> geser: here it builds on hardy
<calc> Mithrandir: so it works on my box but uses so much ram/swap that i could easily see why it times out on the buildd
<calc> Mithrandir: i can't get any other apps to respond while it is compiling that bit of code
<geser> nxvl_work: it's a bug in sbuild used on the buildds
<choudesh> I need a bit of help here. I am customizing the liveCD, trying to add the dist/pool folders. It seems when I add these folders, sqaushfs just hangs on boot up
<Ng> mjg59: any idea how much the pm-utils quirks are likely to vary over the various X40 models? I noticed the hal fdi file matches against the product number, but there are a bunch of them, so maybe matching X4* would make more sense?
<Ng> (at least, mine isn't matched, although at the moment resuming is broken with or without seemingly any of the quirks ;)
 * emgent hi
<calc> doko: unoil.jar.?.jar are uploading to chinstrap:~/incoming right now
<mwolson> could I get someone to upload my changes to emacs22 as per LP #172389?
<mwolson> <== maintainer of emacs22 package
<ubotu> Launchpad bug 172389 in emacs22 "Please upload emacs22 22.1-0ubuntu10" [Undecided,Fix committed] https://launchpad.net/bugs/172389
<mwolson> it's in main
<mwolson> it fixes about 5-6 different launchpad bugs
<mwolson> if a .diff.gz file is preferred to a debdiff, i can accommodate that
<azeem> mwolson: ok just curious - I totally see the point that the emacs22 documentation should be present by default, but wouldn't this also be achieved by just depending on emacs22-non-dfsg or are there further user-visable issues with the documentation then?
<mwolson> azeem: have you read https://wiki.ubuntu.com/MichaelOlson/WhyDifferentEmacs yet?
<azeem> yes
<mwolson> mainly the moral aspect of it.  i'll add some additional details to that page to address this question
<azeem> I see.
<Kmos> slangasek: got more time to accept dom4j in NEW? a lot of packages are FTBFS because of it..
<slangasek> Kmos: still several packages ahead of it in the queue; we'll get there
<Kmos> slangasek: thanks. You forgot some backports on U-A and one sync.
<Kmos> :)
<Kmos> just to remind
<slangasek> Kmos: I didn't forget any backports; I have no idea why ~u-a is subscribed to those at all, the archive admins aren't responsible for /doing/ the backports.
<Kmos> slangasek: no? lol.. since I remember, the archive admins do that..
<Kmos> slangasek: you need to ask pitti about that =) if motu's can do it, it's really better..
<jdong> slangasek: you guys are responsible for doing the backports :)
<slangasek> jdong: er?  but backports are sourceful uploads with changed version numbers, surely?
<jdong> slangasek: no those are source-change backports
<jdong> slangasek: non source change (normal) backports are done automatically via some sort of script on your end
 * slangasek goes to refer to his manual
<jdong> similar to a sync
<slangasek> well, fair enough
<slangasek> ok, if I get through NEW and have some time left, I'll have a look
<slangasek> otherwise someone else can take them later :)
<jdong> slangasek: sure; I think I've got a thing or two in NEW that needs loving too, so I'm happy.
<mwolson> azeem: I've updated that page to list three reasons why I don't want to just Depend on emacs22-common-non-dfsg
<mwolson> are ubuntu-main-sponsors the right group to subscribe when I want to upload a new emacs22 package?  it usually takes a few weeks to get a new package uploaded, so I'm wondering if I'm subscribing the right people/group
<Kmos> mwolson: yes, it's the correct group
<Kmos> because the package is in main
<mwolson> Kmos: thanks
#ubuntu-devel 2008-01-15
<matteo> hi all
<matteo> E: aacplusenc_0.13_source.changes: bad-distribution-in-changes-file gutsy
<matteo> what I have to specify instead of gutsy?
<mjg59> For a new package? Hardy.
<matteo> mjg59: i'm using PPA
<matteo> the personal package thing
<matteo> dunno if I can upload packages for hardy yet
<matteo> *already
<matteo> another thing
<matteo> i upgraded from gutsy to hardy
<matteo> but now i have lost my gpg keys
<matteo> why debsign can't find them after upgrade?
<matteo> $ echo $DEBEMAIL
<matteo> rootkit85@yahoo.it
<matteo> $ gpg --list-key |fgrep rootkit
<matteo> uid                  Matteo Croce (Rave is not a crime!) <rootkit85@yahoo.it>
<StevenK> Because you have a comment in the key
<matteo> really=
<StevenK> Matteo Croce <rootkit85@yahoo.it> != Matteo Croce (Rave is not a crime!) <rootkit85@yahoo.it>
<matteo> but gpg asked for one
<slangasek> --list-key does not tell you whether the secret key is available, anyway; but StevenK's probably right with his guess that the uid doesn't match what's in your changelog
<matteo> mm, ok
<matteo> and I guess I can't edit it
<StevenK> matteo: I think you can.
<matteo> can I do it in kgpg?
<matteo> i dunno much about gpg
<StevenK> matteo: It prompts for a comment, enter will set no comment
<matteo> StevenK: i mean, editing the existing one
<slangasek> you should add a new one and expire the old one
<slangasek> by "a new one" I mean a new uid, not a new PGP key
<matteo> ah, ok
<matteo> tnx
<kurt> hello do you think there will be fixes for the marvell atheros cards in the future?
<kurt>  i can't get my atheros marvell card to work.  ndiswrapper tells me that the driver is invalid
 * bddebian tries to beg slangasek or StevenK to join the games team :-)
<slangasek> um?
<StevenK> bddebian: You can't afford my rates.
<matteo> slangasek: aren't you a debian maintainer?
<matteo> teh gcc one?
<slangasek> I'm not a gcc maintainer
<mjj29> slangasek: I think they are short on obscure consonants, and want to collect the set
<slangasek> mjj29: seems fair
<bddebian> Bah, I give up :-(
<StevenK> bddebian: In all seriousness, I have enough to do without another thing to ignore.
<bddebian> I know, I'm just whinging
<matteo> ok i'll create a new key
<matteo> DSA and Elgamal is fine?
<ToyKeeper> matteo: <slangasek> by "a new one" I mean a new uid, not a new PGP key
<matteo> yes but I made a mess
<matteo> has ubuntu a keyserver?
<matteo> keyserver.ubuntu.com
<matteo> found
<pitti> Good morning
<Hobbsee> morning pitti!
<Hobbsee> pitti: FWIW, apt installs new recommends by default, when upgrading the metapackages
<Hobbsee> didn't check update manager
<Hobbsee> (no idea if you got your answer from mvo)
<Kalamansi> hello is there any way to minize setting of pc2 and pc3? like i will not put my isp's dns? pc1 is my server and i have no router. pc2 and pc3 can connect to the internet with assigned ip,gateway,subnet and dns of my isp..how to minimize this without setting my isp's dns? i dont want to expose my dns to the public...
<pitti> Hobbsee: yeah, I got it; thank you
<dholbach> good morning
<desertc> Just wondering if anyone ever considered using bit-torrent for the synaptic package distribution?
<ToyKeeper> jigdo
<ToyKeeper> Not quite the same idea, but... closest thing I know of which is used for it.
<ToyKeeper> Bittorrent doesn't easily handle seeding a large, oft-changing set of files.  You can do a large static set as a batch, or a small dynamic set individually...
<desertc> Interesting.  Thanks for the insight.  I was pondering apt-get cache servers tonight.
<Hobbsee> morning seb128
<seb128> hello Hobbsee
<\sh> hmm...is it me, or is debootstrap not working for any debian release anymore? deboostrap lenny dir/ doesn't work...Retrieving Release that's it
<pitti> dholbach: what do the numbers in parentheses mean on http://people.ubuntu.com/~dholbach/sponsoring/index.html ?
<dholbach> pitti: age of the subscription
<dholbach> in days
<pitti> ah
<geser> good morning
<pitti> hey geser
<geser> Hi dholbach, pitti
<dholbach> hiya geser
<seb128> carlos: hey
<seb128> carlos: any news of the hardy translations?
<carlos> seb128: the imports are still running
<carlos> although I guess we could start preparing language packs, will not include everything
<carlos> but is an option now
 * carlos checks the queue
<seb128> how long is it going to get everything imported?
<asac> carlos: you think we could get mozilla translations going in launchpad? maybe we want to start and try firefox-3.0/xulrunner-1.9? or maybe something smaller - like ubufox?
<carlos> seb128: it's hard to estimate it
<seb128> hey asac
<asac> hey seb128
<seb128> asac: did you get all the epiphany-browser xulrunner 1.9 commited upstream?
<seb128> asac: there is a new version, just asking before looking if patches can be dropped or need to be updated
<carlos> seb128: although we have 19900 entries pending to be imported and we imported already 40400 since last Wednesday
<seb128> carlos: so everything should be imported this week
<carlos> seb128: I would say two or three more days
<carlos> yeah
<asac> seb128: all code-changes iirc ... the build system notyet, because we landed improvements to pkg-config that make things less patchy.
<seb128> asac: ok
<asac> seb128: i will update the patch for us ... maybe update xulrunner before to get the latest build infrastructure
<seb128> asac: ok, I'll wait for now then, there is no hurry, thanks
<carlos> asac: I want to resume firefox work next week or so when I'm back to translations work, I'm not working in translations this month...
<carlos> asac: so I would say that we could do it soon, yes
<asac> carlos: ok, just want to be sure that we can get issues shaken out in time for the hardy release.
<carlos> that's the idea, yes...
<asac> carlos: ok i will bug you regularly from now on then :)
<carlos> asac: don't worry to ping me often :-)
<asac> carlos: we face a new peculiarity: not all translations are in firefox anymore; most texts are now in xulrunner-1.9. unfortunately upstream probably won't split the translations for us so we have to figure something out.
<carlos> so it's a different package?
<asac> yes
<asac> carlos: but the keys of the xulrunner entities should match the ones distributed by the default firefox locales. so using those to populate launchpad with default translations should still work, right?
<carlos> asac: where are the English strings?
<asac> in the packages
<carlos> in xulrunner ?
<asac> parts are in firefox-3.0 ... the rest is in xulrunner-1.9
<asac> the .xpis distributed by upstream will contain translations for both
<carlos> so to get an standard English only installation
<carlos> I still need firefox + xulrunner ?
<carlos> that would be a bit more complicate to handle... but still possible
<carlos> because as you pointed, we have the shared ids to link messages with translations
<asac> why would that be a problem?
<asac> i mean: you import xulrunner en-US  + firefox en-US ... then you have all the ids
<carlos> not a problem, just a bit more difficult
<carlos> because templates come from a single package in our current system
<carlos> and in this case we have two packages
<carlos> that we should convine to get the list of strings to translate
<asac> but ... why not just treat it as if it was two independent packages
<carlos> hmm
<carlos> does it mean that we will end having two different translation packages?
<asac> yes
<carlos> aah
<carlos> then it's quite simple ;-)
<carlos> I misunderstood you
<asac> the funny thing is that the default translations come from one .xpi
<asac> e.g. one huge nl-NL.xpi
<asac> but we export to xulrunner-locale-nl and firefox-locale-nl for instance
<carlos> asac: hmm, ok, if the template (en-US) is in different packages
<carlos> asac: it should be easy to handle that
<asac> if you mean ubuntu package by "package" then thats the case yes.
<asac> fine
<carlos> asac: I mean source package
<carlos> for translations we work with source packages
<asac> carlos: ok ... we have two sources as well.
<carlos> ok
<dan_> longshot: anyone seen an issue where after you kill one process that's listening on one port, then somehow the next highest PID starts listening on that port??
<Mithrandir> this libflickrnet fuckup is getting annoying.
<Hobbsee> Mithrandir: it should be fixed, i thought.
<Mithrandir> Hobbsee: iz not for me.
<Hobbsee> do you have the new mono stuff?
<Hobbsee> poke bigon` over it - he's dealing with ti
<cjwatson> \sh: try with a different mirror
<Mithrandir> bigon`: yo.  ;  ^^
<Mithrandir> Hobbsee: uh, unsure?  I just see the flickrnet thingy blowing up and taking all the shiny mono stuff with it.
<Hobbsee> hm
<Mithrandir> ah, it worked when I told it to install libflickrnet first and then the rest
<Hobbsee> yay, gnome-do is installable again!
<\sh> cjwatson, I tried ftp.de.debian.org the same...a normal http or ftp session works like a charm
<cjwatson> \sh: 'sudo debootstrap lenny lenny http://ftp.de.debian.org/debian' WFM
<cjwatson> (at least it starts retrieving Packages; I'm rebuilding my mirrors at the moment so I can't do a full run)
<\sh> cjwatson, yes...it starts retrieving packages...but regarding /usr/share//debootstrap/scripts/sid it should do it, too...but it doesn't do as been told ;)
<\sh> cjwatson, and as a test I changed the default_mirror in scripts/sid to point to ftp.de.debian.org and this even doesn't work...so I wonder whats wrong
<cjwatson> your error messages are not terribly clear ...
<cjwatson> might be worth looking in $target/debootstrap/debootstrap.log to see if there's anything interesting there
<\sh> cjwatson, it's empty ...and debootstrap itself stays at : I: Retrieving Release
<\sh> cjwatson, invoking deboostrap as "sudo deboostrap lenny $HOME/chroots/lenny/" with another mirror url at the end, it works
<Mithrandir> I just saw that against archive.u.c with wget stalling on a connect to one of the machines in the DC.
<\sh> but "sudo debootstrap gutsy $HOME/chroots/gutsy/" works like a charm...
<cjwatson> \sh: erm, I think I misunderstood your statements above. Could you please restate these bits in different words?
<cjwatson> 10:49 <\sh> cjwatson, yes...it starts retrieving packages...but regarding /usr/share//debootstrap/scripts/sid it should do it, too...but it doesn't do as been told ;)
<cjwatson> 10:51 <\sh> cjwatson, and as a test I changed the default_mirror in scripts/sid to point to ftp.de.debian.org and this even doesn't work...so I wonder whats wrong
<\sh> cjwatson, debootstrap sid sid/ http://ftp.de.debian.org/debian works
<cjwatson> \sh: ok
<\sh> cjwatson, deboostrap sid sid/  doesn't work
<cjwatson> \sh: if you read /usr/share/debootstrap/scripts/sid more closely you'll see that the default mirror set there is only for architectures other than amd64 and i386
<cjwatson> the "real" default is in /usr/sbin/debootstrap
<cjwatson> so either this is temporary breakage on ftp.debian.org, or we need to switch to a different mirror
<cjwatson> given the recent "stop using ftp.debian.org please, use a mirror" announcement on debian-devel-announce I suspect the latter
<Hobbsee> cjwatson: when will the new seed structures be done?
<cjwatson> Hobbsee: no ETA yet, sorry
<cjwatson> before feature freeze though
<Hobbsee> cjwatson: right.  they're blocking kde4 hardy cds :(
<Hobbsee> cjwatson: any useful way of someone else helping out?
<cjwatson> Hobbsee: not at the moment, sorry, I'll try to make progress this week
<Hobbsee> cjwatson: OK, cool.
<cjwatson> \sh: I've changed the default to ftp.us.debian.org in d-i svn
<\sh> cjwatson, grmpf...or much better we set the default mirrors in deboostrap/scripts/<releasename> without setting a default in /usr/sbin/deboostrap?
<cjwatson> I don't see why it makes a difference.
<cjwatson> the method exposed to users for setting the mirror is on the command line. only debootstrap developers should care where it lives in the code.
<\sh> mvo, ping cdrkit debdiff, just remove the versioning from the conflicts/replaces...so it matches all cdrtools versions
<mvo> \sh: thanks, I look at it after lunch :)
 * soren lunches
 * pitti uploads a better python-distutils-extra to Debian and Ubuntu; enjoy
<cjwatson> \sh: I've uploaded debootstrap 1.0.8, which fixes the default mirror
<\sh> cjwatson, thx :)
<\sh> mvo, I'll prepare a new debdiff for cdrkit ;)
<selckin> why doesn't any package install a dummy /etc/hosts with localhost in it when you use deboostrap?
<\sh> mvo, debdiff updated...see bug ;)
<ogra> grmbl ....
 * ogra was wondering why his daily rsync took so long ... 
<ogra> i hate downloading in wrong dirs
<ogra> grrr .... i fix one breakage and another shows up .... i need a working daily, damned ...
<ogra> seb128, do you care for vinagre ?
<ogra> seems it needs libgtk-vnc
<ogra> (which is not on the CD)
<seb128> ogra: it's a GNOME depends but I think soren has interest in it since the server team use it or something
<soren> I use vinagre from time to time, yes.
<soren> It doesn't belong in main, though. It's got a bunch of annoying bugs, but it's the only standalone VNC client that uses gtk-vnc, which is the only vnc implementation with the new input extensions that I use in kvm.
<soren> If something tries to pull it into main, it should get some love first. I have 5-6 ways to make it crash.
<ogra> well, either libgtk-vnc goes to main or vinagre goes to universe
<soren> ogra: Why is vinagre in main?
<persia> soren: Dependency of the new seeds, no?
<soren> ogra: I actually think libgtk-vnc should be in main (I'll need it shortly), but I have no problem with vinagre moving to universe.
<soren> persia: Well, than "why was it seeded?" is my question :)
<ogra> soren, s/should/shouldn't/ ?
 * ogra fails to understad the sentence
<ogra> you want the lib in main but vinagre in universe ?
<pochu> 13:10 <     soren> If something tries to pull it into main, it should get some love first. I have 5-6 ways to make it crash. <--- report them please? :)
<ogra> ah
<soren> pochu: I'll get to it.. :)
<soren> ogra: Yes.
<soren> ogra: I have other stuff, that I'd like to have moved to main that uses gtk-vnc.
<ogra> ah
<soren> ogra: vinagre, otoh, is not mature enough, IMO.
<ogra> well, in any case the lin needs to be promoted then
<pochu> soren: hint: use apport ;)
<ogra> *lib
<ogra> (which vinagre is already, someone approved the MIR)
<soren> O_O
<ogra> (my prob is that it breaks the daily CDs in that state atm)
 * soren is looking forward to having his DSL line upgraded to 2 MBit upstream
<ogra> soren, that helps :)
<ogra> i have it since dec.
<soren> Oh, vinagre 0.4 is out. That might fix a lot of the problems.
 * soren takes it for a spin
<ogra> dholbach, ping ...
<dholbach> ogra: pong
<ogra> dholbach, is there any truth in the comment QFunk made on bug 182941 ? seems OpenSuSE just changes the dep with no further patches
<ubotu> Launchpad bug 182941 in planner "Planner needs transition from libgda2-dev to libgda3-dev" [Wishlist,Triaged] https://launchpad.net/bugs/182941
<dholbach> ogra: try to build it with libgda3-dev
<ogra> thats what i'm doing atm :)
<persia> soren: There's a vinagre upgrade bug floating about with it already packaged, if you haven't seen it yet.
<soren> persia: Hmm.. why hasn't it been uploaded?
<pochu> It's in Debian NEW too.
<persia> I think it was targeted for a sync
<pochu> Once it's newed, right.
<soren> Can I fetch it from Debian somehow? I forget. :(
<pochu> soren: the source or the binaries?
<pochu> soren: I have binaries for hardy, if you want them
<soren> source. I found it.
<soren> ...or I thought I did.
<soren> pochu: Where can I find the sources?
<pochu> sec
<pochu> soren: http://emilio.pozuelo.org/~deb/vinagre_0.4-1.dsc
<soren> pochu: Got it. Thanks.
<pochu> No need to thank me, just report bugs! ;)
<soren> pochu: Well, let's see if it's necessary :)
<pochu> There's only one crash report in LP, and it was with 0.3...
<stgraber> seb128: After updating my evolution to the one you uploaded yesterday I can't connect using SSL to my IMAP server ... known issue ? (that's on amd64)
<seb128> stgraber: no
<stgraber> seb128: hmm, ok I'll create a clean user and check that it happens too
<seb128> stgraber: looks like a good idea
<soren> pochu: Ah.. apport refuses to let me report the bug as the package is not a genuine Ubuntu package.
<ogra> ARGH !!!
<ogra> Mithrandir, how exactly did you make libflickr install ?
 * ogra thought the mono upload he sponsored was supposed to fix that
<ogra> *sigh*
<Mithrandir> ogra: just do apt-get install libflickr-whatever first
<ogra> sounds like a missing dep then
 * ogra tries
<ogra> nope
<pochu> soren: heh. I'll ping you once it's synced then :)
<pochu> soren: or report it upstream ;)
<soren> pochu: I've just reported it on Launchpad. bug 183169
<ubotu> Launchpad bug 183169 in vinagre "Crash if hostname contains invalid characters" [Undecided,New] https://launchpad.net/bugs/183169
<geser> didn't work for me, I tried to remove libflickr first, so mono could complete the installation and tried to reinstall libflickr but still the same error
<stgraber> seb128: segfault with a clean user :)
<soren> pochu: The others I could remember didn't crash anymore.
<snadge> any status on bug #1 yet?
<ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1
<ion_> snadge: MicrosoftÂ® has already began its downfall on the OS side. :-)
<cjwatson> snadge: I think when it's closed *everyone* will know. :)
<stgraber> seb128: http://pastebin.ubuntu.com/3575/
<stgraber> seb128: ^ error message and backtrace
<ogra> Mithrandir, i really wonder how you managed that, the file it wants to inwstall is actually nonexistent
<seb128> stgraber: looks like it's not known upstream
<seb128> stgraber: could you send a bug using apport?
<Mithrandir> ogra: try dpkg -i /var/cache/apt/archives/libflickrnet2.1.5-cil_25277-6_all.deb ?
<ogra> ah, i tried apt ... one sec
<pochu> soren: great, thanks!
<geser> Mithrandir: doesn't help
<ogra> Setting up libflickrnet2.1.5-cil (25277-6) ...
<ogra> * Installing 1 assembly from libflickrnet2.1.5-cil into Mono
<ogra> ! Assembly /usr/share/cli-common/policies.d/libflickrnet2.1.5-cil/policy.2.1.FlickrNet.dll does not exist
<ogra> nope
<snadge> i really hope that hardy heron is going to be less buggy than all the prior releases put together ;) maybe i'm just unlucky, but i've had everything from no video, to no networking and unable to detect filesystems
<Mithrandir> > dpkg -L libflickrnet2.1.5-cil| grep dll$
<Mithrandir> /usr/share/cli-common/policies.d/libflickrnet2.1.5-cil/policy.2.1.FlickrNet.dll
<persia> snadge: I'd encourage you to join the team on #ubuntu-bugs and try to make sure as many as possible are well described, and a solution is possible.  It's the best way to make sure hardy works for you.
<geser> Mithrandir: I have the dll only in /usr/lib/cli
<ogra> ogra@ceron:~/devel/packages$ dpkg -c /var/cache/apt/archives/libflickrnet2.1.5-cil_25277-6_all.deb |grep dll
<ogra> -rw-r--r-- root/root    136704 2008-01-13 07:53 ./usr/lib/cli/flickrnet-2.1.5/FlickrNet.dll
<ogra> hmm
<Mithrandir> hm, I did a rebuild of it, maybe it was that?
<geser> Mithrandir: which md5sum does your deb have? I have here: 9f275e327795820e4942cc52e1a2f1eb
<ogra> Mithrandir, aha :)
<Mithrandir> geser: since mine's a rebuild, it'll have a different md5sum
<geser> :)
 * ogra tries if a pbuilder rebuild changes anything
<ogra> ogra@ceron:~/devel/packages/libflickrnet-25277$ dpkg -c /var/cache/pbuilder/result/libflickrnet2.1.5-cil_25277-6_all.deb|grep dll
<ogra> -rw-r--r-- root/root    136704 2008-01-15 14:04 ./usr/lib/cli/flickrnet-2.1.5/FlickrNet.dll
<ogra> hmm
<ogra> Mithrandir, did you change anything in debian/rules ?
<Mithrandir> no
<ogra> dh_install FlickrNet/FlickrNet.dll /usr/lib/cli/flickrnet-$(VERSION)/
<ogra> seems to only install it there
<ogra> weird
<Drakou> hi there , I'm looking for help with pango but i can't find a #pango channel
<Drakou> I have a cross compilation problem and i don't know how to solve it. The problem is with libtool when making the library
<Drakou> Anybody there knows libtool well ? My error is here : http://pastebin.com/d942cf88
<pochu> soren: I've forwarded it upstream, as I can 100% reproduce it. http://bugzilla.gnome.org/show_bug.cgi?id=509634
<ubotu> Gnome bug 509634 in general "Crash if hostname contains invalid characters" [Critical,Unconfirmed]
<soren> pochu: In 0.3 I can't even store bookmarks. It was surprisingly fragile. 0.4 looks much better.
<soren> pochu: gtk-vnc is really the sanest VNC implementation I've seen, so having a stand-alone client that uses it is really, really good.
<soren> pochu: re bug 183169: If it's a gtk-vnc problem, I'll be happy to update it to a recent hg version.
<ubotu> Launchpad bug 183169 in vinagre "Crash if hostname contains invalid characters" [Medium,Triaged] https://launchpad.net/bugs/183169
<pochu> soren: I'm building vinagre trunk, which is what jwendell asked for, and try to reproduce.
<soren> pochu: Cool.
<soren> pochu: I'll need a fresh gtk-vnc before hardy releases anyway (there's a new version due out soon), so tracking hg is not a problem at all.
<pochu> soren: I'll let you know if I can still reproduce with vinagre trunk :)
<ogra> ogra@ceron:~/devel/packages$ for i in 4 5 6 ;do dpkg -c ./libflickrnet2.1.5-cil_25277-${i}_all.deb|grep cli-common|grep dll;done
<ogra> -rw-r--r-- root/root      3584 2008-01-04 07:31 ./usr/share/cli-common/policies.d/libflickrnet2.1.5-cil/policy.2.1.FlickrNet.dll
<ogra> -rw-r--r-- root/root      3584 2008-01-11 06:50 ./usr/share/cli-common/policies.d/libflickrnet2.1.5-cil/policy.2.1.FlickrNet.dll
<ogra> hmm
<ogra> debian has it in version 5 and 6
<ogra> i wonder why its not in our package at all
<pochu> soren: do I need gtk-vnc trunk? /tmp/buildd/vinagre-0.4+svn132/src/vinagre-tab.c:258: undefined reference to `vnc_display_set_lossy_encoding'
<StevenK> ogra: egrep 'cli-common.*dll$' ? :-)
<ogra> StevenK, hey thanks
<ogra> sadly that doesnt add the missing file :)
 * StevenK chuckles
<StevenK> Stand back, I know regular expressions!
<pochu> soren: nevermind, found it.
<ogra> err Mithrandir you reversed the options mksquashfs uses ?
<Mithrandir> ogra: No?
<ogra>  * Add -lzma switch to enable lzma support.
<Mithrandir> yes?
<ogra> there is a -nolzma switch already we use in liveCD and LTSP builds atm
<ogra> did you reverse that behavior
<ogra> ?
<ogra> (do i need to change my scripts now )
<Mithrandir> yes, I know about that.  Does my changelog entry say anything about that -nolzma is removed?
<ogra> no
<ogra> thats why i ask :) since it doesnt say either that its not touched :)
<Mithrandir> are you going to ask whether I removed the -version switch too? :-P
<ogra> :P
<Mithrandir> (no, I didn't touch -nolzma, since that'd break scripts)
<ogra> i just wanted to know if i have to adjust my scripts ... could have been you dropped nolzma if you default to no lzma anyway
<Mithrandir> I just changed the default and made it possible to go back to the previous default by adding -lzma as an option, since otherwise you couldn't say "please give me lzma".
<ogra> ok
<ogra> thnaks
<Mithrandir> if I had dropped -nolzma, I would have announced it somewhere and mentioned it in the changelog.
<ogra> ok
<Kmos> could someone give back ogre-contrib in hardy ?
<Mithrandir> Kmos: done
<Kmos> Mithrandir: thanks
<ogra> grmbl ... if i build flickrnet locally it works :/
<ogra> if i use pbuilder the file is missing
<soren> I need netcat to support connecting to UNIX sockets. I can a) patch our netcat to do so, or b) replace our netcat with the one from OpenBSD which already has it. The current netcat code is horribly hideous and unmaintained, but the OpenBSD one is not 100% command line compatible, but maintained and the code is much prettier.. I've already whipped up a patch to the OpenBSD one to make it cli compatible.. Any objections to switching? Is it worth disc
<Mithrandir> soren: use socat?
<Mithrandir> soren: also, you got cut off after "worth disc".
<soren> Mithrandir: I'm *replacing* netcat.
<soren> Ah..
<soren> Er..
<Mithrandir> butbutbut
 * Mithrandir hugs netcat
<sladen> socat?
<soren> last bit was "Is it worth discussing on a mailing list?
<soren> "
<soren> Mithrandir: It's still netcat, only a rewrite of it from OpenBSD.
<soren> Mithrandir: Fedora uses it, too, and have done so for years.
<sladen> where, did the current copy of tail(1) come from, it too stopped supporting   tail -0f  and the like
<sladen> did somebody replace that with the BSD version too?
<soren> Part of the problem with socat is that its cli is not compatible at all with netcat, and one of the reasons I'd like to change it is because certain clients might connect to an Ubuntu server and expect certain things to happen, when it calls nc with certain arguments.
<sladen> and then if that person uses $(modified version of netcat) and then switches back to their Debian/Fedora box?   ("OMG forking incompatible Unix all over again")
<soren> Mithrandir: Chances are, that if I had not asked, but just uploaded the new version, you'd never have known the difference. Nevertheless, I felt I should mention it first.
 * ogra decides to hate mono for now and takes a coffee break
<sladen> soren: reckon you can get the Debian maintainer to switch?
<soren> sladen: They've discussed this already.. Hang on.
<sladen> soren: if so, focus the energy there and we get the results for free
<soren> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=145798
<ubotu> Debian bug 145798 in netcat "netcat: openbsd's rewrite of netcat might help some ppl... or not" [Wishlist,Open]
<cjwatson> sladen: tail -0f works for me
<cjwatson> sladen: it's an obsolescent use though, as are most -NUM options in coreutils; use tail -n0 -f
<sladen> cjwatson: I know, I know, but the fingers still prefer typing the shorter version
<soren> Of course, I could just name it netcat-openbsd, but there's a good chance I'll want this in main, so instead of having two 99% compatible implementations in main, I'd rather replace it.
<sladen> ha. tail: warning: following standard input indefinitely is ineffective
<soren> :)
<cjwatson> sladen: I've retrained my fingers at least in the case of head
<sladen> okay.  I'll rephrase.   tail -0  /was/ broken, /somewhere/, at least enough to get me out of the habit of trying to type it
<alleeHol> \sh:  oh, damn.  can't find my fai bazaar branch.  But AFAIR everything is pushed to fai teams bazaar.  Status was FAIBASE pxe install and softupdate were working in gutsy at the time of my last bzr push
<\sh> alleeHol, I wanted to work on the latest fai for hardy...
<\sh> alleeHol, so I wasn't sure if you pushed the new fai into bzr
<alleeHol> \sh:  that's great news.  You'll have pxe boot/softupdate tester next week ;)
<\sh> alleeHol, ok...so I can work on this beast
<alleeHol> \sh: last rebase of fai ubuntu branch is the release in the ppa
<\sh> alleeHol, ok...
<_MMA_> seb128_: Did you want me to file that system sounds bug against Ubuntu or something else? I confirmed I got no sound there as well. Or, should I just did up the old one?
<seb128> _MMA_: gnome-control-center
<_MMA_> ok
 * _MMA_ didnt know sounds were part of the but ok. :)
<_MMA_> seb128: Done. bug 183199
<ubotu> Launchpad bug 183199 in gnome-control-center "System sounds aren't being played in Hardy." [Undecided,New] https://launchpad.net/bugs/183199
<seb128> _MMA_: thanks
<_MMA_> np. Let me know if there's anything else you need me to do. Well, I guess thats what LP and filing the bug is for. :)
<lucky_lucas> Hi, regarding to this http://www.krizka.net/2007/12/27/thinkpad-x61-tablet-and-ubuntu-hardy-heron/ hdaps driver seems to be broken in hardy and gutsy, is there any plan to add the latest driver form sourceforge ?
<lucky_lucas> It concerns almost every thinkpad I guess
<lucky_lucas> Moreover enabling hdaps requires a kernel rebuild, is it planned to patch the kernel to support it ?
<davmor2> hello. I know this isn't the best channel for advice.  But How can I find out if the 64bit hw detection system is working correctly?  re bug 173130
<ubotu> Launchpad bug 173130 in xserver-xorg-video-nv "edubuntu hardy 64bit live cd issues" [Medium,Incomplete] https://launchpad.net/bugs/173130
<pochu> soren: could you point me to gtk-vnc VCS? Or do you want to build it yourself? (I have a source package of vinagre-trunk, but I think it needs gtk-vnc trunk due to a new api used in vinagre)
<soren> pochu: AFAIR, there's no API changes. I could be wrong, though.
<soren> pochu: http://gtk-vnc.sourceforge.net/Code
<pochu> soren: this is the problem: http://svn.gnome.org/viewvc/vinagre/trunk/src/vinagre-tab.c?r1=129&r2=128&pathrev=129
<soren> pochu: Ah, yes, tight encoding was added since gtk-vnc 0.3.2.
<soren> pochu: ...which is lossy.
<soren> ..so that was likely added since 0.3.2.
<pochu> Well I have 0.3.2 and don't have that symbol:
<pochu> emilio@pochu:~/tmp/tmp/vinagre/trunk$ nm -D /usr/lib/libgtk-vnc-1.0.so.0.0.1 | grep vnc_display_set_lossy_encoding
<soren> What I meant was that there's no SONAME bump needed.
<pochu> emilio@pochu:~/tmp/tmp/vinagre/trunk$
<pochu> Right.
<soren> pochu: I won't have time to update it today. I'll put it on my list for tomorrow.
<pochu> I'll try to do it then.
<soren> Cool.
<DarkSun88> Hi all
<pochu> Hey hey DarkSun88
<DarkSun88> Hi pochu :)
<Hobbsee> erm, what's a virtual package that other things depend on?
<Hobbsee> like, an example of one?
<Hobbsee> (which is not libapt)
<Hobbsee> mvo: oops, you broke it.
<Hobbsee> mvo: it appears that doing apt-cache rdepends <virtual package provided by something else> doesn't give any output now.  Any reason why?
<cjwatson> Hobbsee: /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz
<cjwatson> www-browser for example
 * Hobbsee pokes her mirror
<bigon> hi, could someone rebuild libflickrnet against new mono 1.2.6+dfsg-5ubuntu2 ?
<ogra> bigon, i tried that, doesnt work in pbuilder
<bigon> uh?
<ogra> it builds fine if i use a manual debian/rules bianry
<ogra> but the dll is not in the pbuilt package
<bigon> with the newly uploaded version of mono?
<ogra> i think so
<Hobbsee> cjwatson: ah, thanks.  that answers the first question, but not the second.
<Hobbsee> cjwatson: out of interest, how's the easiest way to open that file?
<ogra> let me check my pbuilder again, but i actually created a new one this morning, so it should be in tehre
 * Hobbsee is certain she did *not* do it in the easiest way
<cjwatson> [ -n "$LESSOPEN" ] || eval `lesspipe` # in a shell initialisation file
<cjwatson> or zless
<Hobbsee> ah, zless!
<Hobbsee> thanks.
<cjwatson> the above rune makes less decompress it automagically
 * Hobbsee wonders about the syntax for sticking that into .zshrc
<ogra> bigon, gah ....
<ogra> my pbuilder had ubuntu1
<ogra> builds fine
<bigon> works for me :)
<mvo> Hobbsee: apt-cache show <virtual-pkg> does not display anything too. I'm unhappy about it, but there seems to be some strong sentiment in debian that the apt-cache interface should remain as it is
<Hobbsee> mvo: why, though?
<Hobbsee> mvo: it comes up via apt-cache search
<Hobbsee> mvo: is there any way to find out what packages depend on a virtual package now?
<ogra> bigon, build1 uploaded
<mvo> Hobbsee: synaptic has this ;)
<bigon> ogra: \o/
<Hobbsee> mvo: anything in synaptic should be possible to do via the command line.
<mvo> I agree
<Hobbsee> mvo: i don't understand.  why did it work before, but not now?
<Hobbsee> if the debian protocol was to keep it as it was
<mvo> Hobbsee: oh, sorry. I missed the bit that it worked before.
<mvo> Hobbsee: do you have a rough idea what version it used to work and which it broke?
<Hobbsee> mvo: was working in earlier hardy.
 * Hobbsee checks gutsy
<Hobbsee> hrm, broken on gutsy
 * Hobbsee swears that that worked before.
<Kmos> Hobbsee: have you tried showsrc virtual_package ?
<Hobbsee> Kmos: no, why?
<Kmos> Hobbsee: i think it will show you the virtual package :)
<Hobbsee> Kmos: it doesn't.
<Kmos> :-(
<Kmos> it worked for some java packages based on jbossas4
<Hobbsee> which apparently doesn't exist at all.
<Hobbsee> oh, here it is.
<Hobbsee> Kmos: whatever makes you think that jbossass4 is a virtual package?
<Kmos> Hobbsee: i didn't say that
<Hobbsee> Kmos: did you actually read the backscroll?
<Kmos> Hobbsee: yes
<Hobbsee> Kmos: your statement then had absolutely no relevance to hte previous discussion?
<Kmos> Hobbsee: maybe
<Kmos> forget it :)
<Kmos> i need to go.. time to candidate a job :(
<Kmos> Hobbsee: i'm sorry.. i think you're talking about the same thing I was thinking.
<Kmos> bbl
<Hobbsee> mvo: perhaps i'm wrong.  i swore i used to be able to do something with apt-cache search libapt, take the elongated form, and do an rdeps search on that.
<Hobbsee> Kmos: ....right.  if that's hte case, then what you're thinking wasn't what you said.
<Hobbsee> mvo: including on the old versions of it, so i could see what still needed a rebuild.
<Hobbsee> mvo: which would have beena round the time i last uploaded apt
 * Hobbsee heads to bed.
<pochu> soren: reproduced with gtk-vnc trunk + vinagre trunk
<soren> pochu: But jwendell doesn't see it? That's odd.
<pochu> I've removed your patch to build trunk btw, as it didn't apply cleanly
<pochu> I'll build it with --enable-debug and try to get a useful backtrace.
<tkamppeter> Anyone here who can resync the the REVU uploaders keyring?
<hunger> When will OOo finally get upgradeable again in hardy?
<\sh> tkamppeter, some revu admins can on #ubuntu-motu...or ask on #ubuntuwire :)
<\sh> elmo, do I need to send an email to rt@ubuntu.com to re-enable shermann@ubuntu.com?
<hunger> OOo-l10n-* seem to be outdated for weeks now:-(
<\sh> hmm..archive admins who synced libgcr410 ?
<\sh> Riddell, ping
<tkamppeter> Thanks, \sh, on that channnel no one is answering.
<\sh> tkamppeter, well, siretart or imbrandon could do the revu keyring sync imho..think both are busy or wrong timezone :(
<phaidros> hi, is there already beta iso's around for testing ?
<jdong> phaidros: what kind are you looking for?
<_MMA_> http://cdimage.ubuntu.com/releases/hardy
<jdong> ^^ latest "released" alphas
<jdong> http://cdimage.ubuntu.com/daily-live/
<jdong> ^^ daily-built CD images. not guaranteed to work
<jdong> the released alphas are at least checked to work and install
<phaidros> jdong: cd, amd64 desktop/server/studio .. whatever is there :)
<phaidros> thanx guys
<jdong> phaidros: just explore the cdimage server. Lots of cool things in there :)
<phaidros> I see :)
<phaidros> btw, is there an easy way to boot images via usb stick nowadays?
 * phaidros doenst want to burn for each test .. and it is environmentally very unfriendly :)
<_MMA_> There are HOW-TOs out there. Ive never done it myself.
<phaidros> hm
<jdong> phaidros: with some initrd mods you can boot them off the hard drive.
<jdong> I don't have the time currently to detail them
<jdong> not to mention the installer gods in here would probably come hunt me down with flaming pitchforks if I admitted to it :D
<jdong> but in all reality, it's nice to have a DVD+RW drive to test these. Takes 5 minutes to burn, you can reuse a disc 1000 or so times before you begin to have trouble.
<phaidros> yeah .. you are right.
<phaidros> but usb seemed even nicer
<jdong> it's actually not always faster to write compared to DVD+RW
<phaidros> and: my dvd rw burner is only 4x ;)
<jdong> mine is 2.4x :)
<cjwatson> well, the reason you don't want to boot the installer off the hard drive (without very specialised circumstances) is that partitioning is then impossible
<phaidros> uh? only 5 mins?
<jdong> phaidros: 700MB?
<phaidros> hm, true
<phaidros> cjwatson: but on usbstick ..
<cjwatson> sure; the alternate installer supports it and it's documented in the installation guide
<cjwatson> it's possible with the live CD and I think there's stuff on the wiki
<phaidros> would be neat to let iso boot automatically as well on sticks
<phaidros> I'll go and look :) thx
<cjwatson> we discussed this at UDS-Boston and came up with a plan
<cjwatson> (don't recall where it is)
<phaidros> hm, plan is good! solutions as well ?? ;)
<jdong> lpscrape -x supertux-stable
<jdong> oops
<cjwatson> it's not rocket science to do the small modifications needed at the moment
<cjwatson> like I say, I think it's on the wiki somewhere
<phaidros> https://help.ubuntu.com/community/Installation/FromUSBStick .. nice ..
<phaidros> more easy: just a script :)
<cjwatson> looks like the one
<tkamppeter> siretart, ping
<tkamppeter> imbrandon, ping
<mdz> sabdfl,mjg59,Keybuk: TB tonight?
<Keybuk> mdz: I'm able to attend
<mr_pouit> cjwatson: has something been decided for xubuntu (universe or not?), or not yet?
<cjwatson> mr_pouit: I don't think so
<cjwatson> I'm not up to date
<mr_pouit> cjwatson: well, when I mailed the tb to have the "final" answer, mdz told you were the one to ask :p
<phaidros> nice, isttousb script works and it boots!
<phaidros> isotousb
<mdz> mr_pouit: as I wrote to you, as far as I'm aware, this is in the discussion stage, not the "final answer" stage.  I'd like to see a consensus among the Xubuntu developers and the archive administrators about the best course of action
<cjwatson> ^-- see, this is what I'm not up to date about. :-) I don't read mails sent to the TB list
<mdz> mr_pouit: is there such a consensus already?
<mdz> cjwatson: I replied to the message sent to TB and CCed you (Mon, 17 Dec 2007 15:02:59)
<cjwatson> so you did. there was then no followup (at least none that was CCed to me)
<cjwatson> mr_pouit: at any rate I don't think you should let this block you from proceeding as before (adding entries to seeds, preparing MIRs, etc.) until consensus/decision is reached
<mdz> mr_pouit: as one of the Xubuntu developers, what do you think is the best way forward?
<gpocentek> IIRC the main argument was the fact that xfce/xubuntu is not supported by canonical (might be wrong)
<gpocentek> so is there something that xubuntu dev could do?
<gpocentek> no one works for canonical in the team
<_MMA_> The definition of "officially supported" was also under question.
<_MMA_> I'd like to say as lead on Ubuntu Studio, and someone who has all their packages in Universe, its been no issue. The situation seems to come down to perception for Cody. (somerville32) Moving to Universe looks to be seen as a negative.
<mjg59> mdz: Yup
<mdz> gpocentek: xubuntu is built from main because at the time, we had no facility to build derivatives from universe.  that has since changed, and Ubuntu Studio is (apparently happily) using it
<_MMA_> Correct.
<gpocentek> mdz: yes
<gpocentek> note that I have not a clear opinion about that
<mdz> gpocentek: it makes sense to me for Xubuntu to do the same, as it would avoid confusion for Canonical support and make it easier for new contributors to get involved, but I want to hear from the stakeholders
<gpocentek> mdz: we'd like to know as well, to know in which direction we'll go
<cjwatson> you (plural) are the stakeholders
<_MMA_> mdz: I can pastebin a chat from November about this if you like.
<mdz> gpocentek: if it doesn't matter to you, we can make a decision on our own, but I'd rather hear your opinion
<mdz> _MMA_: sure, could you email it to technical-board?
<gpocentek> mdz: mr_pouit is the leader, so I'd like to ear from him
<_MMA_> Its quite long so Ill link to the pastebin. Do you have the email handy?
 * _MMA_ isnt subscribed.
<mdz> _MMA_: technical-board@lists.ubuntu.com
<mdz> that's the contact address for the entire TB (including the members who aren't watching this channel right now but may have an opinion)
<_MMA_> mdz: Thanx. Im writing it up now.
<mr_pouit> I don't have a strong opinion against that. If there are these facilities to build from universe, why not?
<mdz> ok then, we'll discuss during the TB meeting (in 80 minutes) and vote on it
<mr_pouit> cjwatson: I still updated the seeds, but I was holding my breath for MIRs yes ;)
<_MMA_> For now: http://paste.ubuntu-nl.org/52033
<_MMA_> mdz: sent.
<somerville32> I'm not the only one who is worried about the migration of Xubuntu to universe. mr_pouit has also expressed concern.
 * somerville32 goes to actually read backlog now.
<somerville32> My main concern is the same one shared by mr_puit in his original response to the proposal regarding QA. Just yesterday, when a MOTU asked how he might test a package another MOTU jokingly replied "It is Universe. We don't do testing." Although this was said jokingly, this is often the case. Furthermore, there has been a fair amount of work done to distinguish main as the archive with the "premium" packages and that universe is s
<somerville32> econd-rate and to expect that. I fear that some would see this migration as a reflection on the quality and status of the Xubuntu distribution. TBH, I think the entire model needs to be rethought.
<_MMA_> somerville32: Bring this up in the meeting so we dont duplicate the chat.
<mjg59> keescook: Around?
<keescook> mjg59: hiya
<mjg59> keescook: Did you see my note about the libdisasm license?
<keescook> mjg59: uh-oh, where did it go?
<mjg59> keescook: On IRC, a couple of days back
<mjg59> Might have vanished out of your scrollback
<keescook> mjg59: ah, then no, sorry.  what's the issue?
<mjg59> keescook: It's original Artistic - it's incompatible with everything
<keescook> what?  I diff'd it against common-licenses ...
<keescook> $ diff -u LICENSE /usr/share/common-licenses/Artistic && echo $?
<keescook> 0
<mjg59> keescook: Yeah. That's original rather than clarified, as far as I can tell
<keescook> blargh.  where is the "clarified"?
<mjg59> keescook: http://www.statistica.unimib.it/utenti/dellavedova/software/artistic2.html
<mjg59> keescook: The easiest way to tell is the number of options in sections 3 and 4 - clarified has 5, original 4
<keescook> is there a reason Artistic2 isn't in common-licenses?
<mjg59> keescook: Yeah, it's not all that common
<mjg59> Or, at least, wasn't in the past
<keescook> mjg59: okay.  So, in what way is this going to cause problems for you?  (Since it's a dynamic library, you can link to it without problem, right?)
<slangasek> there still needs to be a clarified butter license
<keescook> slangasek: mmm butter
<mjg59> keescook: The FSF say "no"
<elmo> so does Debian and Ubuntu
<elmo> :-P
<keescook> then why is Artistic even _in_ Debian?
<mjg59> It's not clear
<slangasek> because that's what Perl was released under
<slangasek> at one point
<mjg59> Yeah, but now it's dual Artistic/GPL
<Keybuk> . o O { I wish there were a licence like the GPL, but that allowed dynamic linking }
<slangasek> right, so this means we're giving end users and redistributors their choice of GPL or Artistic
<keescook> so... what license _should_ libdisasm be under, in a perfect world?
<slangasek> (clarified butter!)
<mjg59> keescook: Clarified Artisitc is similar in spirit, but GPL compatible
<mjg59> Artistic is awkward because it's not actually clear WTF it means (hence the clarified version)
<keescook> Keybuk: does LGPL not do that?
<slangasek> if your definition of "ideal" is "maximizing compatibility", then 3-clause BSD or LGPL are good
<keescook> okay, so, just for my sanity, clarified Artistic would mean that it's dl compat?
<Keybuk> keescook: anyone can take LGPL code, and relicence it under the GPL ... meaning any patches made after can't be integrated back into the LGPL version
<keescook> ew
<keescook> mjg59: clarified Artistic would be sufficient for you? (and everyone else that would need to link against it?)
<mjg59> keescook: Yeah, believe so
<subterrific> i'm trying to follow the instructions from https://wiki.ubuntu.com/SponsorshipProcess/ppaput but the bug doesn't seem to be getting updated after i run ppaput my-ppa -sa. so i'm not sure how i get the bug on the sponsorship list?
<subterrific> oops, wrong channel
<Keybuk> keescook: of course, I could take the (simple) LGPL 3, remove the clause that I don't like, and then call it the KGPL :-)
<keescook> \o/ license proliferation
<Keybuk> keescook: ah, no :-)
<Keybuk> the LGPL 3 is clever
<Keybuk> it's simply a set of "additional permissions" to apply to the GPL 3, which GPL 3 allows
<keescook> ah-ha, sneaky, them
<Keybuk> though at that point, I'm not quite sure how you figure the patches coming back if someone claims they removed the additional permissions
<siretart> tkamppeter: yeah?
<bryce> how does one force a package to reinstall itself and its files (exact same version), without having to uninstall it and reinstall?
<slangasek> apt-get --reinstall install $package=$version
<slangasek> this won't restore altered conffiles though, you need some dpkg flags to get that
<bryce> that should be fine, thanks
<ToyKeeper> ... that was particularly handy back when apt corrupted files during install.   "apt-get clean ; apt-get --reinstall install foo"
<ToyKeeper> I'm glad that bug is gone now.
<slangasek> ToyKeeper: I'm pretty sure apt never corrupted files during install, since apt doesn't install the files :)
<ToyKeeper> IIRC, it was messing up the downloads, but it was a while back.
<ToyKeeper> Using dpkg on the cached copy would fail to install some files, but not give any errors.
<slangasek> ah, well, that's possible; requires apt to corrupt the file and then fail to notice it doesn't match its own checksum
<slangasek> then feed it on to dpkg for the full monty
<tkamppeter> siretart, can you resynk the revu keyring, so that I can upload a package into revu? Thanks.
<siretart> tkamppeter: sync is running, but will take some time (~half an hour)
<tkamppeter> siretart, thank you
<pitti> tkamppeter: do you have a bluetooth adapter and a gutsy installation somewhere?
<pitti> tkamppeter: any chance you could do the verification of bug 147800?
<ubotu> Launchpad bug 147800 in cupsys "[Gutsy] : bluetooth printing was working but is not (at the beginning of september)." [Undecided,Fix committed] https://launchpad.net/bugs/147800
<pitti> tkamppeter: I did the patch and upload testing, so someone else needs to verify it
<ScottK> pitti: Is it needed to have a bluetooth printer available to test that?
<pitti> ScottK: no; the test case describes how to create a fake printer
<pitti> well, a real BT printer would be preferable, of course
<pitti> but they are pretty rare
<pitti> and at least the original bug was generic enough for the fake test case
<tkamppeter> pitti, I have a Bletooth laptop and a printer with Bluetooth plug, but unfortunately no Gutsy. In Hardy it prints fine, after some small polishing on system-config-printer setup is as easy as with an ethernet printer, select auto-detected printer, take defualts for make, model, and driver and it works. Only Plug'n'Print as HAL does not autodetect Bluetooth devices.
<ScottK> pitti: I've got Gutsy, bluetooth, but it's Kubuntu.  I can probably test it this evening if that would be helpful.
<pitti> tkamppeter: hardy has the same cups apparmor rules, but AA doesn't work in hardy (new kernel doesn't ship AA module yet)
<pitti> ScottK: u or kubuntu doesn't matter; would be great, thank you!
 * ScottK marks it on TODO...
<tkamppeter> pitti, would booting the Gutsy kernel on the Hardy box do the trick?
<pitti> tkamppeter: that should work, yes
<pitti> we already know from the other three pending bugs (which are verification-done) that the package is good in general
<pitti> but let's stick to the procedure
<pitti> bryce: did you see the last comment in bug 131646? there's a bug in the -proposed upload
<ubotu> Launchpad bug 131646 in xserver-xorg-video-intel "TVout is interfering with screen resolution on Intel graphics" [Undecided,Fix committed] https://launchpad.net/bugs/131646
<nxvl_work> pitti: did you received my mail?
 * antdedyet wonders what it would take get dump pulseaudio! :)
<antdedyet> s/get//
<sladen> antdedyet: provide something better
<pitti> nxvl_work: I don't think so, subject?
<sladen> antdedyet: and support $bbetter
<nxvl_work> pitti: debian-bts-applet
<nxvl_work> pitti: exactly subject was: "Gnome Applet for monitoring Debian bugs"
<pitti> nxvl_work: no 'Nicolas' in my procmail log (thus it's not in spam either)
<antdedyet> sladen: what is appealing about the idea of an audio server to anyone but someone who might be so involved with audio as to need jack support?
<nxvl_work> pitti: mmm i send it to martin.pitt@ubuntu.com}
<nxvl_work> without the } part
<pitti> nxvl_work: ah, no real name; here it is in the log
<nxvl_work> no real name?
<antdedyet> sladen: and I'm sure you know what I might follow that up with if you are familiar with the current status of jack support in hardy :)
<pitti> nxvl_work: nevermind, got it
<nxvl_work> pitti: ok
<TheMuso> c
<TheMuso> ugh wrong tab
<sladen> antdedyet: for backwards compatibility we'll need  /dev/dsp, alsa and esd interfaces;  if you work out how to make those work *and* JACK out of the box, then that would be a solution that would ultimately be shipable
<nxvl_work> TheMuso: use terminator to stop making this kind of mistakes :P
<sladen> antdedyet: I'm not familiar with the /current/ status;  I know a while ago there was an issue with enabling SCHED_FIFO out of the box
<somerville32> interdiffs or .diff.gz for new upstream releases now?
<bryce> pitti, thanks for pointing that out
<_MMA_> sladen: The JACK/PA situation currently is that with JACK in Universe PA cant build the needed "pulseaudio-module-jack". Its been talked about moving JACK to Main but it was decided some more things need to mature 1st. crimsun could most likely better explain it.
<antdedyet> reality of the situation: no one using hardy in it's current condition can use JACK -- and I haven't figured out how to permanently disable pulseaudio.
<antdedyet> It's not a big deal since it's devel software, but I just want to make it known. :)
<antdedyet> I'd hate to see Ubuntu lose appeal to musicians.
<antdedyet> jack is more necessary then a flashy new sound server for us.
<_MMA_> antdedyet: Like I said, its being looked and Ubuntu Studio will revert if need be. You also must remember that Ubuntu Studio just isnt for audio though I will agree that is our biggest user group.
<_MMA_> antdedyet: Just keep reporting in #ubuntustudio to help make things better. I also expect you to test alpha4. ;)
<antdedyet> _MMA_: I don't always use the studio distro, I don't want the desktop to use it!
<antdedyet> :)
<antdedyet> or at least the init script should work. :)
<bryce> pitti, first, I don't understand why the sru request is being blocked
<pitti> bryce: why blocked?
<bryce> pitti, second, quirks are very specific to a given monitor, but the post by Mika is a useless "me too" - he didn't indicate his monitor model so afaik whatever issue he's having is an independent bug
<pitti> bryce: I mean the comment by Andreas Schildbach
<bryce> pitti, third, the workaround he suggests would likely result in breaking things for people who do have working tv out
<bryce> pitti, but your comment that the issue was stalled precedes Andreas' comment
<pitti> bryce: you mean my comment in 28? well, that's outdated, I sponsored it after all
<pitti> I meant https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/131646/comments/34
<ubotu> Launchpad bug 131646 in xserver-xorg-video-intel "TVout is interfering with screen resolution on Intel graphics" [High,Fix released]
<Nafallo> yea... they really are.
<Nafallo> annoying!
<bryce> pitti: I'm tied up with ume stuff at the moment, but may look at it later. Sounds like it's not a regression but just an incomplete fix.
<keescook> Keybuk: is the code that generates the MoM trend graphs anywhere I can see it?
<pitti> bryce: ok, thanks
 * calc sees an article claiming 150lm/w led's for home use < $2/ea within 7 years
<Keybuk> keescook: http://codebrowse.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/
<Keybuk> specifically
<Keybuk> http://codebrowse.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/annotate/scott%40netsplit.com-20080111101255-0i3o82pmgk2pqpd2?file_id=stats.py-20061027124550-8hlr4n4ot3109wnv-1
<Keybuk> ^ adds lines to the stats.txt files
<Keybuk> http://codebrowse.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/annotate/scott%40netsplit.com-20080111101255-0i3o82pmgk2pqpd2?file_id=statsgraphs.py-20061031161731-18opod7556nw7v81-1
<Keybuk> ^ draws the graphs by collating info in the stats.txt file
<Keybuk> http://merges.ubuntu.com/stats.txt
<Keybuk> ^ the stats.txt file it uses
<keescook> Keybuk: ah, so you manually sum the ranges.
<keescook> (in the transform).  There isn't some magic "draw stacked values" graph option.  Okay, good, I'm not doing "too much work" then in my graphs.  ;)
<keescook> thanks!
<Keybuk> keescook: pychart is quite nasty
<Keybuk> but it happens to work :-)
<phaidros> so, installed alpha3 amd64 .. but as soon as I am in X, I have 5 seconds to do something, then all clicks and kbd actions are ignored ..
<phaidros> I can move mouse but click nothing.
<phaidros> a known one? any hints / workarounds known?
<phaidros> kdb seems to work partially
#ubuntu-devel 2008-01-16
<Keybuk> keescook: have you ever seen valgrind affect signal delivery?
<lifeless> Keybuk: you pung
<Keybuk> lifeless: yes, but abentley answered first :)
<emgent> keescook, ping^2
<Keybuk> emgent: a square ping?  but does it go in a round hole?
<emgent> Keybuk, lol
<jdong> keescook: ping
<jdong> keescook: the 1/03 apparmor uploads introduced some regressions. bin.ping still needs "/var/run/avahi-daemon/socket w" to do mdns resolution
<jdong> keescook: also now sbin.klogd needs /proc/kallsyms read access else it segfaults on bootup with profile enforced
<jdong> kthxbye
<jdong> *vanish*
<ScottK> lifeless: If you're still around I'm deeply interested in how sbuild virtual package dependencies is going?
<lifeless> ScottK: sounds fascinating; what is it ?
<ScottK> Argh.
<lifeless> [I think you have the wrong nick]
<ScottK> I do.  It was it was infinity.
<ScottK> Sorry about that.
<ion_> :-)
<jdong> :)
<ScottK> lifeless: Depending on how fascinating you thought it was, the bug is Bug 178536
<ubotu> Launchpad bug 178536 in sbuild "Preinstalled Build-Depends not properly detected" [Undecided,New] https://launchpad.net/bugs/178536
<calc> anyone know is partman being broken on alpha3 is a known issue?
<calc> i installed using it a few days ago but now it hangs and doesn't come up
<somerville32> ScottK, It appears that Edgy is also vulnerable
<somerville32> Erm, wrong channel
<Keybuk> -> #embargo ? :-)
<desrt> hai!  plz to upload debdiff?
<desrt> http://desrt.mcmaster.ca/random/esd.debdiff ???
<desrt> k thx!!
 * somerville32 blinks.
<Hobbsee> desrt is strange ;)
<RAOF> #gnome-hackers gives some context, there :)
<desrt> Hobbsee; hai =)
<jamesh> desrt: have you filed your bug report yet?
<desrt> jamesh; yes.  i have.
<desrt> just attached the patch
<desrt> https://bugs.launchpad.net/ubuntu/+source/esound/+bug/183411
<ubotu> Launchpad bug 183411 in esound "libesd leaks pipe file descriptors" [Undecided,New]
<nenolod> desrt, nono. you say "CAN HAS DEBDIFF UPLOADZ"
<desrt> sry :p
<nenolod> and .. be sure to attach an lolcat to the bug.
<ion_> And preferably a bukkit.
<mekius> Hi, I was wondering what is responsible for auto-loading the battery kernel module at boot?
<desrt> Hobbsee; thanks for the upload :)
<Hobbsee> desrt: hm?
<desrt> nm.  received some bad information from mjg59 concerning who silently uploaded that package for me :p
<desrt> crimsun; thank you instead :)
<jdong> grumble my macbook whines on Hardy now :(
<desrt> jdong; set your max cstate to 2
<desrt> macbook hardware bug :(
<StevenK> Oh don't be silly, Apple makes hardware that has no bugs. Steve Jobs says so.
<StevenK> </sarcasm>
<Mithrandir> calc: any idea when we'll see an amd64 build of ooo?  It seems to still have failed.  Have you talked with Adam about what might be wrong?
 * desrt figured out the most confusing thing at UDS boston
<desrt> that "T = 2 pi sqrt(1/a)" on the bedsheets
<desrt> the 1 is actually a lowercase L!
<desrt> and it's the period of a pendulum of length l and weight a
<slangasek> Mithrandir: hmm? https://launchpad.net/ubuntu/+source/openoffice.org/1:2.3.1-3ubuntu2/+build/491532 lists as 'Successfully built'
<StevenK> Bwahaha, pitti and I spent like 20 minutes discussing the equations
<ion_> I want math bedsheets too
<desrt> s/weight/gravitational acceleration/
<slangasek> ion_: you can buy them at the Hotel@MIT, IIRC
<desrt> slangasek; for $$$
<Mithrandir>   openoffice.org-common: Depends: openoffice.org-core (> 1:2.3.1) but 1:2.3.0-1ubuntu5.3 is to be installed
<Mithrandir> slangasek: ^  Something does at least seem unhappy here.
<Mithrandir> (and yes, I'm using archive.u.c)
<slangasek> Mithrandir: sure, the state is 'finished: 58 minutes ago', so hasn't gotten through a publisher cycle yet? :)
<Mithrandir> slangasek: ah, ok.
<Mithrandir> that'd explain it.
<Mithrandir> why doesn't the kernel and lum use dpkg triggers for update-initramfs?
<desrt> what's the deal with blue titlebars with orange buttons occasionally appearing on hardy?
<somerville32> desrt, Rogue artists
<desrt> i like the look
<StevenK> Kubuntu trying to assert itself?
<somerville32> If it is Kubuntu, we need to beat it down quickly with a stick
<desrt> seriously
<desrt> it looks really nice
<somerville32> Take a screenshot the next time it happens then:P
<Mithrandir> desrt: jpeg!
 * Hobbsee stomps on Mithrandir's feet
 * Hobbsee tickles Mithrandir too, then runs away
 * Mithrandir levitates
<Hobbsee> too slow.  far too slow.
<ion_> mithrandir: Jpeg, huh?
<Mithrandir> ion_: I'm not picky.
<Mithrandir> ideally, it should be png, but jpeg works.
<ion_> Lossy compression for a screenshot is teh evil. :-)
<desrt> it's doing it again!!!
<somerville32> Omgz!! Camera, quick!
<Mithrandir> desrt: pix!
<desrt> hold on
<desrt> i had a blue theme on
<desrt> lemme change it to orange and see if i can get it to happen
<desrt> arf.  no love.
<somerville32> : O
<desrt> ha ha
<desrt> got it!
<somerville32> spiffy
<dholbach> good morning
<desrt> http://desrt.mcmaster.ca/random/weird-theme.png
<Mithrandir> shiny
<desrt> ya
<desrt> awesomeness by accident
<desrt> i think it's a weird race condition
<desrt> where one of the compiz colours is properly updated by the other remains default
<Mithrandir> desrt: what does "bus" on your desktop do?
<desrt> it's a folder.  it has bus schedules in it.
<somerville32> lol
<Mithrandir> ah
<somerville32> desrt, It does look nice
<desrt> i say!
<desrt> when the installer booted up i was like "nice!"
<desrt> i was really sad when i found out it was a bug :p
 * Hobbsee looks, blinks, and looks again
<desrt> how do i submit this to the hardy artwork thing? :p
<Hobbsee> desrt: you apply a large hammer to kwwii until he says "OK, that's the new default"
<Mithrandir> today's xkcd is a work of beauty.
<desrt> Hobbsee; isn't it mark who decides that?
<desrt> (or at least holds veto...)
<Hobbsee> desrt: doubly-apply the hammer, then.
<somerville32> Here is a screenie of my desktop :) http://cody.zapto.org/Screenshot-1.png
<desrt> that's one ugly-ass theme :p
<somerville32> : O
<desrt> it's annoying that they still haven't fixed the bug with the incorrect logout icon
<desrt> it confuses people quite a bit :(
<somerville32> In Xubuntu?
<desrt> maybe?
<desrt> in ubuntu, at least
<desrt> i'm just poking my way around my new hardy install
<highvoltage> show off :)
<calc> and btw i don't know if/when sparc is going to properly build OOo it seems to fail most of the time
<calc> it almost always ICEs
<desrt> seb128 will help me!
<seb128> hey desrt
<desrt> hi seb
<desrt> i'm trying to make a new metacity theme :D
<seb128> I know nothing about themes
<desrt> seb128 will not help me!
<desrt> check out this whacky effect: http://desrt.mcmaster.ca/random/weird-theme.png
<seb128> try to ask to thos on gimpnet?
<desrt> a bug in hardy makes that happen from time to time
<desrt> but it looks so splendid that i want it forever
<seb128> ah ah
<seb128> you are using compiz?
<desrt> yes
<desrt> bad pitti :p
<Hobbsee> guten morgen pitti!
<seb128> that happens when gtk-window-decorator starts before the gnome-settings-daemon
<seb128> hey pitti
<desrt> seb128; it's good.  can we make that happen more often? :)
<geser> good morning pitti
<seb128> mvo: do you know what theme is used when the gtk-window-decorator doesn't use human correctly?
<pitti> Good morning
<pitti> desrt: I love you too
<desrt> pitti; :)
<desrt> good morning :)
<pitti> desrt: what's up?
<mvo> seb128: no
<desrt> seb128; i think it has more to do with GTK
<mvo> seb128: if the problem is reproducable for you, would you mind testing a patch ?
<desrt> it's the "selected" colour from the default GTK theme before the GtkSettings kick in
<seb128> desrt: might be
<seb128> mvo: I get it at every login on my laptop, testing a patch should be no issue
<desrt> pretty sure
<desrt> the metacity theme refers to it like value="shade/gtk:bg[SELECTED]"
<seb128> desrt: nice work on the esound issue ;-)
<seb128> desrt: bug #164971 is likely due to that
<ubotu> Launchpad bug 164971 in nautilus "Gnome freezes after moving or deleting many files" [Medium,Incomplete] https://launchpad.net/bugs/164971
<desrt> a nice
<desrt> i skipped over that report because the summary line is a lie :)
<desrt> should i dup it?
<seb128> desrt: I already did
<desrt> thanks
<seb128> thank *you* for fixing the bug ;-)
<desrt> it was fun :)
<desrt> that's why i said "bad pitti" when he joined :)
<seb128> hehehe
<desrt> how do nominations work?
<pitti> desrt: as if I hadn't done everything possible to get rid of esound :)
<desrt> pitti; you did a little too much :p
<StevenK> Only because esound sucks ...
<desrt> does anyone know anything about this new cpuidle stuff?
<desrt> like how to set a maximum cstate....
<pitti> calc: are you working on the OO.o-l10n FTBFS? it's wreaking some havoc now (lots of uninstallability)
<pitti> soren: hm, 'sudo kvm -cdrom gutsy-desktop-i386.iso' just crashes; is that supposed to work?
<mvo> pitti: why do you need to run it with sudo?
<pitti> mvo: well, otherwise it complains about /dev/kvm not being accessible and falling back to qemu
<pitti> I'll try running it on 2.6.24
<mvo> pitti: there is a kvm group
<mvo> pitti: if you add your user, it should be fine
<pitti> mvo: the device is root:root 660, though
<pitti> I don't need kvm-source, right?
<soren> pitti: If you "sed -e 's/GFXBOOT bootlogo/#FXBOOT bootlogo/g' < yourgutsyimage.iso > thisworks.iso", you're all good :)
<pitti> soren: lol
<soren> pitti: I'm afraid there's no way around it. It's due to limitations in intel's virtualisation extensions and gfxboot.
<soren> pitti: Yeah, it's a bit of a hack.</understatement>
<mvo> soren: wasn't there a patch for this? I remember something on the ML a while ago
<Mithrandir> soren: or just hold shift while it boots.
<mvo> pitti: oh? it is root,kvm for me
<pitti> hm; well, I'm still running the gutsy kernel so that I don't loose wifi; I'll try the hardy one
<soren> Mithrandir: What? Really?
<soren> mvo: YEs, it's fixed in hardy.
<pitti> shift doesn't work for me
<Mithrandir> soren: yes, workaround for broken video bioses.
<soren> Mithrandir: I had no idea.
<Mithrandir> pitti: you might need to try a few times, it seems it sometimes help to just push it every now and then.
<pitti> I have the kvm window for about 0.3 seconds, and I'm holding shift the entire time
<Mithrandir> soren: also, sed -i.
<pitti> Mithrandir: no -i for me, I want a copy :)
<soren> Mithrandir: That works, too, yes. I just didn't want to break the integrity of my isos.
<Mithrandir> well, yes.
<pitti> soren: how is the /dev/kvm group solved in the kernel? I thought this was udev's job?
<soren> pitti: It is.
<soren> pitti: $ dpkg -S /etc/udev/rules.d/*kvm*
<soren> kvm: /etc/udev/rules.d/45-kvm.rules
<pitti> hm, I have that rules files
<pitti> s/s$//
<soren> And you've rebooted since installing kvm?
<pitti> aah
<soren> ...or just removed kvm-intel and inserted it again?
<pitti> soren: I still had it loaded from the test from yesterday
<soren> (that should also do the trick)
<pitti> but without kvm installed :)
<soren> Right :)
<pitti> yep, that did it
<soren> \o/
<soren> I've just finished the changes to virt-manager, I wrote about on distro-team yesterday. I'll upload them in a bit. It's looking really slick now.
<pitti> rockin', booting now
<pitti> soren: the manager allows you to create virtual disks, and so on? or what does it do?
<soren> pitti:  That's one thing, yes.
<soren> pitti: It also makes your vm's run in the background (well, libvirt does that, but virt-manager helps you), so that you can detach from them and attach elsewhere and such.
<soren> It's pretty nifty :)
<soren> I just want to send half my patch upstream, and then I'll upload.
<pitti> soren: can you please give the -proposed .debs of bug 160176 a quick test?
<ubotu> Launchpad bug 160176 in bind9 "L.ROOT-SERVERS.NET record needs an update" [Undecided,Fix committed] https://launchpad.net/bugs/160176
<pitti> soren: I'd like to move them to -updates, so that we can release ubuntu 6.06.2
<soren> pitti: Sure.
<pitti> soren: does KVM have problems with usplash as well? I just get a black screen now while the gutsy desktop boots
<ion_> tjaalton: The updated nvidia_supported apparently didnât make it into the latest linux-restricted-modules-2.6.24. (Bug #182237)
<ubotu> Launchpad bug 182237 in linux-restricted-modules-2.6.24 "restricted manager does not recognize nvidia 8600M GT on hardy" [High,Confirmed] https://launchpad.net/bugs/182237
<tjaalton> ion_: nope..
<ion_> tjaalton: I still donât see why a git repo isnât used for the development of l-r-m. Whenever someone does a release of l-r-m, the pushed changes made by others working on it would be included automatically. :-)
<soren> pitti: I'm not sure about usplash, to be honest. I haven't been using it (only server installs).
<tjaalton> ion_: not my problem really :)
<tjaalton> ion_: but I'm not sure how it scales with large binaries
<tjaalton> perhaps if the packaging could be kept separate, but there are multiple debian-directories..
<mvo> pitti: does your suspsend/resume keeps working with kvm-intel?
<pitti> mvo: suspend was broken previously on hardy; I just did a dist-upgrade, will test with the new pm-utils
<pitti> and then with kvm-intel
<mvo> pitti: thanks, I'm curious, my laptop is not upgraded yet, but willbe soon
<pitti> oh, nifty, with 2.6.24-4 I now have two batteries
<mvo> pitti: cool, if I get a additional battery from 2.6.24-4, I install that too
<pitti> ah, cool, suspend seems to work again, thanks mjg59!
<Amaranth> yay, free battery
<pitti> mvo: suspend works fine with kvm-intel loaded; trying hibernate now
<mvo> pitti: thats great, thanks mjg59
<pitti> tjaalton: any problems with the cups in dapper-proposed so far? (bug 44196)
<ubotu> Launchpad bug 44196 in cupsys "gnome-cups-icon uses 100% CPU" [Medium,Fix committed] https://launchpad.net/bugs/44196
<tjaalton> pitti: no, g-c-i doesn't eat cpu anymore :)
<pitti> tjaalton: rockin'
<pitti> a day of great news as it seems
<tjaalton> hehe
<pitti> tjaalton: can you please add a bug comment about this? (paper trail)
<tjaalton> sure
<pitti> mvo: hibernate works, too
<pitti> hm, previously hibernation destroyed the text VTs
<pitti> now I cannot even switch to them
<pitti> with chvt they are still broken, but *shrug*, I don't care much
<tjaalton> pitti: done
<pitti> oh, and 2.6.24-4 fixes iwl3945, too! cool, I can drop the gutsy kernel now
 * pitti hugs everyone
<pitti> Keybuk: hm, my wifi shouldn't be called 'wlan0_rename', right?
<tjaalton> pitti: btw, I uploaded a new xorg-server for dapper-proposed (bug 113679), not approved yet
<ubotu> Launchpad bug 113679 in xorg-server "xorg freezes when running openoffice" [High,Fix committed] https://launchpad.net/bugs/113679
<tjaalton> oh, should subscribe SRU team to it?
<pitti> tjaalton: yes, please
<hunger> When will the ooo-l10n debs become available? They keep OOo un-upgradeable for weeks now.
<pitti> soren: oh, in case it wasn't clear: please start verifying bind9 on dapper; the other releases aren't as urgent
<Hobbsee> pitti: er, how was that broken before?
<pitti> Hobbsee: bug 177624
<ubotu> Launchpad bug 177624 in linux "iwl3945 has very poor signal reception, whereas ipw3945 works perfectly" [High,Fix released] https://launchpad.net/bugs/177624
<pitti> soren: hm, booting with nosplash doesn't help either (kvm)
<soren> pitti: I've checked on i386. Looks fine.
<Hobbsee> pitti: ah, strange.
<pitti> soren: thanks; please do a followup comment to have a papertrail
<pitti> soren: oooh! x starts in kvm (desktop CD)! even noquiet nosplash didn't help against the black screen
<pitti> hm, but no gdm
<tjaalton> pitti: yes, I played with it on Friday
 * pitti gets a pretty sloppy mouse now and lots of "psmouse.c: throwing 5 bytes away", and "resync failed, issuing reconnect request"; hmm
<geser> pitti: please give-back evolution-exchange. Thanks
<Ng> seb128: is the network-admin gnome system tool known to not work in hardy atm for static network setups?
<Ng> pitti: I get the two batteries thing too
<seb128> Ng: not that I know but I doubt it got lot of testing
<Ng> seb128: mmkay, I do use it, and I've found two bugs so far that I'll report. It lost my Location settings from gutsy, and it's not able to configure an interface ;)
<seb128> Ng: did you upgrade today and did you restart since?
<Ng> seb128: nah, I upgraded a few days ago and have restarted a lot since because suspend isn't working either ;)
<seb128> upgrade to the version uploaded yesterday then and restart
<geser> pitti: I've looked at the beagle depwait (it waits on two packages in universe). I tried to build it without those but it fails to build then. How to resolve this?
<seb128> if you still get the issue using the new version you can report a bug
<seb128> geser: why does it depwait if the packages are available?
<seb128> geser: the standard reply would be to get those to build if they don't
<geser> seb128: beagle is in main
<pitti> geser: we want to move beagle to universe
<seb128> geser: no it's not
<pitti> seb128: it's still in main
<pitti> f-spot still b-deps on it
<pitti> it needs to move to libbeagle-dev
<seb128> pitti: ah, I though we said to make it stop using beagle for now the other day
<pitti> since it's only a b-dep, I'll demote beagle now; that won't render it uninstallable
<pitti> seb128: the fun thing is that f-spot doesn't actually depend on beagle, just b-deps on it
<pitti> so it might even just be an unneeded b-dep
<pitti> geser: demoted; should start building in an hour or two
<geser> pitti: thanks
<geser> seb128: should I wait longer on slomo uploading evolution-sharp or could you do it?
<seb128> slomo: ^
<seb128> I'll do the sponsor if he doesn't reply
<seb128> looks like he's too busy or something
<carlos> pitti, seb128: we are importing Hardy files uploaded 9 days ago so we would be in a good status to start preparing language packs if you don't want to wait one or two more days
<cjwatson> ion_: following the Hotel@MIT experience, my wife made me pillowcases covered in equations for Christmas
<StevenK> Way cool
<ion_> cjwatson: Aaww :-)
 * TheMuso must have missed something with all these equations around the hotel. :p
<TheMuso> I thought they were concerned about accessibility with braille numbers everywhere. Seems that they weren't on the ball. :)
<Mithrandir> TheMuso: I'm somewhat happy my bedsheets weren't braillified.  I think it might be a bit like sleeping with sandpaper-y bedsheets. :-)
<StevenK> Haha
<TheMuso> Mithrandir: Well if it comes to that, I agree with you.
<StevenK> What would the brallie say, though?
<Mithrandir> StevenK: the same as the equations, I'd imagine?
<StevenK> "This is the edge of the bed" "This is next to the edge of the bed" ? :-)
<StevenK> And then the sheets move and confuse TheMuso
 * TheMuso chuckles at StevenK's comment dispite the sillyness of it
<TheMuso> StevenK: They may confuse a totally blind person, but not me. :)
 * StevenK finds his USB key
<StevenK> The cat was lying on it
<TheMuso> Lovely.
<Hobbsee> put the cat outside.  problem solved.
<StevenK> Hmph
 * Hobbsee is surprised the cat didn't chew it.
<ogra> cats dont chew stuff
<ion_> The designers of braille were kind enough to include the Wannabe Hacker Emblem in the symbols.
<Hobbsee> ogra: that one does.  computer cables.
<TheMuso> They just tear it appart
<ogra> crazy
<StevenK> Or electrical cables, like phone chargers
<TheMuso> Does that cat have any other dog instincts? :p
<ogra> you know that you need to feed it, right ? :)
<StevenK> She doesn't sit, stay or roll over and she dislikes the dog.
<StevenK> ogra: Hmph
<Mithrandir> one of our cats knows how to sit.
<ion_> mithrandir: URL?
<Mithrandir> ion_: location://home/top-of-shelf ?
<StevenK> Hah
<TheMuso> Mithrandir: Yeah, when it wants to. :)
<Mithrandir> TheMuso: and with a suitable treat, it tends to want to.
<TheMuso> Right
<pitti> soren: hm, I tried booting the hardy desktop in kvm on my desktop (no VT support, so just qemu), and gfxboot works there
<soren> pitti: Yes.
<soren> pitti: I fixed it in hardy.
<soren> pitti: Well, I'm the one who uploaded it anyway :)
 * soren actually reads what pitti wrote
<pitti> so it just breaks when using kvm-intel
<soren> pitti: Just with qemu, gfxboot should have worked all the time.
<soren> pitti: With kvm, gfxboot works as of hardy.
<pitti> I see
<pitti> soren: is there actually any difference between using kvm and qemu directly?
<pitti> (without kernel/CPU support, I mean)
<soren> pitti: kvm's qemu is slightly more up to date than what's in the qemu package.
<soren> pitti: Other than that, no.
<soren> pitti: And the qemu package should be updated shortly (Debian maintainer is working on it).
<pitti> soren: hm; I thought the Recommends: qemu would mean that kvm just uses the qemu package itself?
<soren> pitti: Hm.. I think that recommendation should probably be dropped.
<soren> pitti: I'd have to check, though.
<pitti>  The recommended qemu package contains the the qemu-img program needed to create
<pitti>  virtual disk images as well as the script /usr/sbin/qemu-make-debian-root,
<pitti>  which uses debootstrap to build a debian disk image.
<pitti> ah
<soren> Oh, right.
 * soren considers splitting those out into a qemu-utils package.
<pitti> wow, module-assistant and kqemu-source work like a piece of cake
<pitti> soren: maybe /dev/kqemu should also get a group
<soren> pitti: I'm considering it. I'm just getting annoyed with all these new groups.
<pitti> yeah :/
<pitti> soren: it's about the same level as, say, 'video', but using video might be confusing
<soren> slightly :)
<soren> Except video actually gives you access to hardware.
 * soren tries to think of a situation where you wouldn't want users to have access to kqemu..
<soren> Well, I guess the memory used by the qemu process in question will be pinned by the kernel module, so it can't be swapped out.
<TheMuso> pitti: Do you have any ideas as to whats happening wrt pulseaudio and the realtime group, for better performance?
<TheMuso> pitti: in terms of Ubuntu?
<TheMuso> pitti: I know users on other distros using such settings, and finding much better performance, especially with on-board cards.
<pitti> soren: kvm: invalid option -- '-kernel-kqemu'
<pitti> soren: how's that called in kvm?
<soren> pitti: Yeah, kvm doesn't support kqemu.
<pitti> ah
<pitti> neither does our qemu, as it seems
<soren> Sure?
<soren> It really should.
<pitti> $ qemu -kernel-kqemu -cdrom hardy-desktop-amd64.iso
<pitti> qemu: invalid option -- '-kernel-kqemu'
<pitti> that's the option described in file:///usr/share/doc/kqemu-common/kqemu-doc.html
<soren> The build logs claim that it's enabled.
<soren> Oh, -kernel-kqemu might not work.
<pitti> soren: ah, qemu-system-x86_64 -kernel-kqemu works
<soren> pitti: Oh, yes, I remember now. kqemu only works when the emulator you're running matches the host, but qemu upstream insists that "qemu" should execute the i686.
<pitti> 10037.001587] kqemu: aborting: Unexpected exception 0x0d in monitor space
<soren> hysterial raisins, but still.
<pitti> *sniff*
 * Mithrandir gives soren a c
<soren> ta
<Mithrandir> (and then eats his raisin)
<soren> Oh, well, that's about as many uploads as I can do before lunch..
<soren> Aw!
 * soren contemplates making a "your mom" joke out of it, but decides not to.
<xst_> Does anyone know when there will be put an effort to make dual monitors (e.g. a laptop together with an external monitor (a fairly common setup)) work? Currently one have to manually edit xorg.conf which is clearly a no-go for laptop users that often plug/unplug the external monitor.
<Mithrandir> xst_: have you tried xrandr --auto?
<xst_> No. What is that?
<Mithrandir> if your video driver supports xrandr 1.2, you should be able to hotplug monitors.
<xst_> I tried to plug in my external monitor using Kubuntu Hardy alpha 3 but it stayed blank. I had to reboot in order to recognize it. But then it stayed at the same (low) resolution as my laptop :-(
<Mithrandir> it probably defaults to clone mode.
<xst_> Unfortunately I wasn't able to alter the monitor settings as the Display&Monitor module was broken in alpha 3. And in alpha 2. And alpha 1. :-(
<tjaalton> xst_: what device?
<xst_> tjaalton: What do you mean by "what device"?
<tjaalton> xst_: gfx card
<xst_> ATI Radeon X1300
<tjaalton> heh
<tjaalton> ok, so you are using vesa, which does not support multihead
<tjaalton> try radeonhd
<pitti> bdmurray, pedro_: btw, I eliminated the 6 hour lag of http://people.ubuntu.com/~ubuntu-archive/pending-sru.html, and it's generated hourly now, after the publisher
<pedro_> pitti: great, thanks
<xst_> I could - theoretically - use the official "restricted" ATI driver but not even the "restricted drivers" module works in alpha 3 (or alpha 2 or alpha 1). It simply doesn't exist in the Settings window
<xst_> So, in summarize, screen configuration in ubuntu/kubuntu is still only practically possible for geeks having the will to manipulate xorg.conf and spend hours/days on getting drivers to work.
<xst_> -it certainly does not meet the "Linux for everyone" goal in Ubuntu
<tjaalton> xst_: mind you that you are running the development version
<tjaalton> besides, restricted-manager is there if you want to enable fglrx
<xst_> I run the test version (from a live CD) in order to provide bug reports to LP. I have Feisty installed on my laptop - but screen configuration is a no-go here also.But besides that, the "restricted manager" is NOT there in Hardy so I can't enable fglrx.
<tjaalton> xst_: oh, it wouldn't work with the livecd anyway
<tjaalton> xst_: it's good that people test things
<xst_> :-)
<tjaalton> xst_: maybe for the next alpha you'll use ati or radeonhd instead of vesa..
<xst_> automatically?
<tjaalton> yes
<xst_> nice!
<cjwatson> xst_: please, we understand that bugs are bugs and we do generally appreciate their importance; we would appreciate it if people didn't resort to pejorative terms in order to try to get bugs recognised
<cjwatson> it isn't necessary and it just inflames the temperature
<cjwatson> appreciate importance> as you can see from tjaalton's comments :)
<Mithrandir> \sh: regarding bug 182920; please don't sync + reapply patches, but rather just get a merge done.  Adilson is going to do that now, so this note is just for the future.
<ubotu> Launchpad bug 182920 in galculator "[MoM Sync] please sync galculator" [Wishlist,Confirmed] https://launchpad.net/bugs/182920
<\sh> Mithrandir, I talked to adilson ... and he was fine with a sync, drop the hildon patches because he needs to to some more work on the new upstream anyways
<Mithrandir> \sh: well, that makes old changelogs get dropped, which we don't want when we have patches that we want to keep.
<Mithrandir> \sh: anyway, no harm done in this case, but please be careful in the future.
<ogra> hrm
<\sh> Mithrandir, as I said, I was discussion this first with him...but you are right, I'll do a fakesync in this case, because the hildon patch doesn't apply cleanly
<\sh> Mithrandir, so disabling the patch is better in this case, imho
<ogra> ifup seems to not like to be run in /target ...
<Mithrandir> \sh: no, please don't.  Adilson said ok because he didn't know the procedure, and he's been told now what the right procedure is.
 * ogra wonders how else to bring up the interface without to much hacking
<Mithrandir> \sh: the patch should just be updated, then.
<\sh> Mithrandir, ah :) this sounds different no problem :) I'll be happy to work with him on that :)
<\sh> Mithrandir, i would be good if we have a bzr tree for those apps which have special patches (for ubuntu-mobile) applied...but I didn't see any of it in the ubuntu-mobile bzr tree
<Keybuk> pitti: it does that if you upgraded from gutsy atm
<Keybuk> pitti: add ', ATTR{type}=="1"' to /etc/udev/rules.d/70-persistent-net.rules lines
<pitti> Keybuk: yes, that's what I did (upgrade)
<pitti> Keybuk: it actually works, it just looks wrong
<pitti> Keybuk: do you want a bug for this? or is it already fixed for gutsy->current hardy upgrades?
<Keybuk> pitti: if it doesn't already have a bug, it should get one
<DarkSun88> Hi all
<calc> pitti: looking into it, i am running a test build on my local machine to see if i can find out what is happening
<pitti> calc: cool, thanks
<Hobbsee> this backlight problem is getting old.
<StevenK> Backlight problem?
<Hobbsee> yeah.  if the machine goes idle for a bit, as soon as it detects mouse or keyboard movement, it goes back to full brightness.
<StevenK> Ah
<Hobbsee> as in, idle for around a minute, without keyboard/mouse input
<Hobbsee> or randomly goes back to full brightness.  gah.
<Hobbsee> strange.  appears to work now.
<slomo> seb128: do it if you want, i'll hopefully find some time to do it tomorrow in the morning if that's early enough (for all my stuff)
<slomo> seb128: and yes, i'm a bit busy... should be better from tomorrow on :)
<slomo> bbl again
<seb128> slomo: I'll wait if you can do those because I've lot to do with GNOME updates
<geser> pitti: please give-back evolution-exchange. Thanks
<pitti> geser: kicked
<calc> wow i386 took 8h20m to fail the l10n build, its 2hr in on my box so far so good, heh
<geser> There was a move from db4.* to db4.6. Does it also apply for the db4.* c++ bindings (move to libdb4.6++)?
<calc> geser: the move is more general than just db4.* its reducing duplication in general so that would be a good idea as well
<calc> geser: db4.* is just one of the more common packages that have lots of copies floating about
<calc> https://wiki.ubuntu.com/HardyReducingDuplication
<geser> calc: is the goal to get those duplicated libraries out of main or out of the archive?
<calc> geser: out of main primarily, but out of the archive would be good as well
<calc> most duplicated libraries have no reason to exist other than packages haven't transitioned yet
<calc> duplicated packages like old gcc, etc sometimes have other uses but probably shouldn't be in main
<jdstrand> amitk, ogasawara: is there any reason why raid1 is not included in the kernel initramfs (esp. server)? I had a bit of a time realizing this was the problem on a gutsy install
<jdstrand> (perhaps it's documented somewhere and I am blind...)
<pitti> seb128: hm, my panel crashes about three times a day now (gnome-panel[6042] general protection rip:7f0d63568d71 rsp:7fff6d268620 error:0)
<pitti> seb128: however, I don't get apport reports; does it have its own crash handler now?
<seb128> pitti: no it doesn't
<seb128> pitti: maybe those are not SIGSEGV and apport doesn't crash those?
<pitti> oh, whoops, seems I blacklisted it; sorry
<pitti> unblacklisted, I'll check it when it happens again
<pitti> seb128: sorry for the noise
<seb128> ok
<seb128> pitti: that is alright
<pochu> pitti: if it crashes during a build, it's likely bug 180463
<ubotu> Launchpad bug 180463 in gtk+2.0 "gtk_recent_files_menu_populate() does not properly guard against recursion" [Medium,Fix committed] https://launchpad.net/bugs/180463
<ogra> zul, !!!!!
 * ogra hugs zul 
<jdstrand> ogasawara: this is probably bug #174428
<ubotu> Launchpad bug 174428 in linux-source-2.6.22 "Gutsy initramfs fails to boot from md partition" [Undecided,Won't fix] https://launchpad.net/bugs/174428
<zul> thanks ogra
<ogra> great news :))
<zul> it is
<pochu> Can someone explain me why tasks is MANUALDEPWAIT in libosso-dev, but libosso was succesfully built about 5 months ago? Is this a soyuz bug, or am I missing something? This is on lpia
<geser> pochu: you mean on lpia?
<geser> pochu: tasks is in main while libosso is in universe
<jdong> any core-devs around who care about Transmission or is willing to invest 2 minutes of effort to update it to the latest version?
<Keybuk> jdong: do you have an update ready for sponsorship?
<jdong> Keybuk: yes, one moment please :)
<Keybuk> jdong: --> https://wiki.ubuntu.com/SponsorshipProcess
<jdong> Keybuk: alright, I'll stick it on the queue :)
<ogasawara> jdstrand: sorry, was in a meeting.  I'm not aware of any specific reason why raid1 is not included
<calc> evand: if you have a chance can you take a look at the bug i filed last night :)
<evand> indeed
<ogasawara> jdstrand: but if you can add a comment to that bug, I'll nudge the kernel guys about it
<calc> evand: i eventually was able to install using alpha3 but it took a lot longer than it should have
<jdstrand> ogasawara: already did ;)
<jdstrand> ogasawara: np on the meeting btw :)
 * calc be back soon, eating brunch
<ogra> cjwatson, i have a slight problem with ssh here ... and like to hear your input
<pochu> geser: oh, thanks. That's a consequence of bug 149275.
<ubotu> Launchpad bug 149275 in osso-gwconnect "First cut of source packages for -mobile promotions" [Undecided,Fix committed] https://launchpad.net/bugs/149275
<slangasek> calc: what needs to happen now to get a working ooo-l10n build?
 * ogra goes for food ...
 * slangasek glares back at the sun glaring through his window
<slangasek> dear Portland, please pick a brightness setting and stick with it so I can stop adjusting my window shades
<amitk> slangasek: can you put in a request for the brightest setting for the last week of this month?
<calc> slangasek: its building on my box right now, trying to track down why its failing
<calc> slangasek: its been running about 4.5hr so far
<calc> evand: back :)
<evand> calc: looking into it and consulting cjwatson.  Nothing in the logs jumps out at me as being erroneous.
<calc> evand: ok
<calc> it eventually got up to 118 cycles or so for partman log when it actually completed
<evand> So I am quite perplexed, especially considering the install ran through just fine, just ridiculously slow.  I suppose I was hoping for a full on failure :).
<calc> i can do any other testing wanted as well, i will be bringing the laptop to sprint so you can take a look then too if you want
<slangasek> amitk: what would you like it to be?  I can put in the request, and then we can file a grievance form after that request gets lost in the paperwork shuffle
<evand> calc: fantastic
<keescook> Keybuk: I haven't used valgrind a lot, but it didn't mess with signals when I did use it.  however, given your deep poking at signals and ptrace, I would not be surprised if you found a bug in valgrind :)
<keescook> emgent: late pong.  :)
<emgent> heheh cool keescook
<emgent> have u saw my emial? :)
<amitk> slangasek: hehe
<emgent> s/emial/email/
<keescook> jdong: did the apparmor profiles actually change in the upload?  I'll double-check the before/after packages.  if so, sorry for the regression!
<slangasek> evand: so is the installer really doing a vfat fsck?  that seems odd to me if it is
<cjwatson> calc: 118 cycles is not particularly unreasonable; that just means 118 communications with parted_server
<evand> slangasek: no, I don't believe it is.
<cjwatson> it's a shame the partman log isn't timestamped
<cjwatson> it could be that ntfsresize is taking ages
<cjwatson> that gets called to determine whether the ntfs filesystem is resizable and if so by how much
<calc> cjwatson: ok so its just the timing that is whats off
<jdong> keescook: I'm 95% sure they changed, as they were correct in the Gutsy release. Anyway, thanks so much for looking into it :)
<calc> cjwatson: btw this is on the same system that does the fsck on boot on fat32 each time (haven't had a chance to verify dosfstools yet)
<calc> cjwatson: and configuring the mount point for that fs takes a while to return as well
<calc> cjwatson: that was why i was wondering in the bug report if fsck is called when you modify settings for a partition in the gui installer
<cjwatson> calc: no, it isn't
<calc> brb, getting laptop
<cjwatson> calc: for configuring the mount point, how much is a whiel?
<cjwatson> while
<calc> i didn't time it but iirc it was over a minute at least
<calc> configuring the mount points for the others was nearly instant (< 5s anyway)
<calc> i'll run back through the process and see how long each part takes
<pitti> calc: openoffice.org-core on sparc is the only package which still holds db4.5 and neon26 in main; it FTBFSed due to a segfault in gcc
<pitti> calc: did you see that before? is it worth trying a rebuild?
<calc> pitti: can we just drop OOo out of sparc entirely?
<calc> pitti: it ICEs 50%+ of the time
<calc> at least from what i recall
<pitti> calc: hm, 50% success rate is pretty good :)
<calc> haha
<pitti> calc: yes, I wouldn't mind unseeding it on sparc
<pitti> calc: I'll give it a shot
<calc> the last time we got it to work on sparc doko had to do something special, i don't know what he did though
<pitti> I think we had it build on the other buildd
<calc> pitti: oh
<calc> pitti: well that might work if it hasn't been tried yet :)
<calc> if that does work doesn't that mean the buildd has bad hardware?
<pitti> calc: I set sejong to manual, so artigas will grab it
<pitti> however, one is busy with gcc, the other with boost, so it'll take a while until they will grab it
<calc> ok
<calc> even if it fails differently that will be interesting
 * calc is watching clock to see how long it takes to reach the main partition screen
<calc> 6min+ so far
<calc> cjwatson: oh yea while its hanging around doing seemingly nothing the hard drive light is lit up constant
<cjwatson> what processes are running?
<cjwatson> ideally look at the last one or two on the list aside from the shell and ps
<calc> /lib/partman/display.d/10initial_auto (twice)
<calc> /lib/partman/automatically_partition/10resize_use_free
<cjwatson> anything below that?
<calc> just gnome-terminal/bash/ps
<calc> parted_server is using some cpu
<calc> not all that much though
<cjwatson> could you reboot, and before starting the installer add 'set -x' on the second line of /lib/partman/automatically_partition/10resize_use_free ?
<calc> 47.3%wa according to top
<cjwatson> should get some useful stuff in /var/log/syslog then
<calc> ok
<cjwatson> err, that's probably /lib/partman/automatically_partition/10resize_use_free/choices actually, but add 'set -x' to .../do_option as well
<cjwatson> it may be in a loop somehow
<slangasek> hmm, i386 alternate size looks ok even with OOo 2.3.1 on it now; time to consider re-seeding -base?
<calc> slangasek: up to you guys... i think once lzma is used it should have plenty of space not to need to get bumped back off
<ogra> cjwatson, ldm uses ssh -X to connect to a desktop session, now that consolekit sets all permissions for admin tasks in the session i need to find a way to make ldm set this, but since people might want to do something like: ssh -X user@server sudo time-admin i wonder if it shouldnt rather be implemented on ssh level than on DM level
<calc> last thing i see in syslog (where i guess the set -x output is going?) is + read exception_type
 * calc is guessing the whole log is probably more useful than just one line ;)
<ogra> cjwatson, we can talk about that later though, no pressing issue atm
<calc> ah more but waited 3.5m
<cjwatson> calc: whole log, yes
<cjwatson> ogra: hmm, ok, I'm not quite sure what's involved in setting such permissions
<cjwatson> ogra: let's talk about it next week?
<calc> now its waiting in do_option
<ogra> there is a libpam-ck-connector in universe ...
<ogra> cjwatson, sure
<calc> i'll stick a set -x in there too if you want?
<pitti> slangasek: alternate size> hm, seems the cdbs fix for reducing gnoem packages finally works
<slangasek> calc: ok, once -l10n is sorted then, I'll look at re-seeding the metapackage
<calc> ok
<slangasek> pitti: ah, what cdbs fix is that?
<pitti> slangasek: to symlink together identical gnome help files, which saves quite a lot (untranslated duplicated screenshots)
<pitti> slangasek: we did this a while ago, but it was missing a dependency (fdupes)
<pitti> (or, rather, it had two Depends: lines, so fdupes got shadowed)
<Keybuk> keescook: heh, oddly enough, it *is* those test cases that fail under valgrind
<slangasek> pitti: right, ok :)
 * Keybuk would have thought you use it a lot to quickly check software for bogus memory operations
<calc> it took right at 14m to get to the main partition screen (guided vs manual)
<ToyKeeper> "perforate" includes an app to hard link identical files together.
<calc> cjwatson: i am going to grab a full install log for the report, it might have something useful in it for the second problem as well
<ToyKeeper> ( finddup --link --dir /foo )
<calc> restarting with all the set -x in place this time
<keescook> Keybuk: I find valgrind too noisy for useful memory analysis -- lots of false positives
 * desrt finishes up the hardy accident theme
<slangasek> keescook: really? the only false-positives I recall seeing from valgrind were passing pointers to uninitialized memory to a syscall where the caller knows the kernel's going to overwrite it on success
<calc> cjwatson: looks like all the issues in the installer are related, its some sort of error handling timeout (afaict) i will be attaching the new logs soon
<calc> cjwatson: the first screen appears to cause the timeout to happen 3 times in a row, then it does a single timeout (i think still waiting) when i tell it the mount point for the vfat/fat32 partition
<calc> the timeout takes about 3.5m each time
<calc> evand: uploading full syslog with set -x output (should be in the bug report in a few minutes)
<evand> calc: great, thanks
<calc> appears to be some sort of error that takes 3.5m to timeout, but that is just a guess
<calc> and it looks like it might be the same error each time, just repeated at the first hang which causes it to hang ~ 14m
<calc> ok the logs are all there now :)
<calc> cjwatson: new logs up for the bug :)
<ceekay>  is anyone able to point me to some info on packaging kernel modules? i am interested in turning intel's ixgbe driver (available on sourceforge) into a .deb
<amitk> ceekay: is this the pci-e ethernet driver?
<amitk> ceekay: an igb module was pushed to linux-ubuntu-modules last week
<ceekay> the project i'm working on is using feisty
<amitk> ceekay: Is this package only for internal use? Typically kernel modules aren't packaged separately. They are integrated in the Ubuntu's external module package. But Feisty won't take new modules anymore.
<ceekay> amitk: yeah just for internal use..
<ceekay> the main issue i have (which i guess isn't module specific) is that the ixgbe driver source is all in  ixgbe-<version>/src rather than in the top-level directory and dh_make doesn't seem to like that
<ceekay> is there some standard procedure to follow when upstream packages its source like that?
<ceekay> i suppose i could rename src/ to ixgbe-<version>/ or copy the contents of src up one level
<amitk> ceekay: I am far from a debian packaging expert. Typically, we just copy the sources to a directory inside linux-ubuntu-modules and create a Makefile.
<amitk> ceekay: download the source for linux-ubuntu-modules to see how the modules have been added.
<ceekay> ah, excellent
<ceekay> i guess i can even grab the one from hardy and see how ixgbe is done :)
<emgent> hello
<ceekay> thanks amitk
<ceekay> by the way, is there a reason feisty is no longer accepting modules? is it just because it'd been released?
<amitk> ceekay: because it is in maintenance mode. So only critical bugfixes are made. No new features are added. For new features, you can upgrade to Gutsy.
<ceekay> gotcha, thanks
<keescook> slangasek: valgrind> there are other things it yells about that are certainly bugs, but not security issues.  perhaps I'm using it wrong.  :)
<slangasek> keescook: ah, well, I find it less effort to fix all the bugs than worry about whether they're security issues :)
<slangasek> but I can see how you might have a different pov
<ceekay> anyone who knows how to use make-kpkg to build platform-dependent modules around?
<Kmos> ceekay: try to ask in #ubuntu-motu
<ceekay> cool thanks
<ScottK> Kmos:  make-kpkg is for making custom kernels.  #ubuntu-kernel would have been a much better suggestion.
<ScottK> ceekay: ^^^
<ceekay> well i guess, the question i actually have is: i have an ixgbe-<version>-source.deb that i put together (because it's not available in feisty), but i want to make a platform-dependent binary ixgbe-<version>-modules.deb so that i can put it on machines that don't have build tools... what tool should i be using for this?
<keescook> jdong: so, I don't see any regressions gutsy to hardy in the apparmor profiles.  looking specifically at "ping", the avahi-daemon/socket was added to the "nameservice" abstraction, and is there in both gutsy and hardy.  if you still still issues, go ahead and open a bug and we can go from there.  :)
<jdong> keescook: ok, maybe I failed to notice it. Did you see /proc/kallsyms in sbin.klogd though?
<jdong> keescook: that seems to be a recent one.
<keescook> checking...
<jdong> it wasn't required just last week in hardy...
<torkel> ceekay: still off topic for this channel :-) but take a look at module-assistant
<jdong> but now klogd segfaults if it's denied access to it
<keescook> Ah, agreed, that's missing from klogd (but it wasn't there in gutsy at all either).  klogd is in complain mode by default.
<ceekay> torkel: thanks
<keescook> jdong: I'll get that into the package.  :)
<emgent> hello there
<jdong> keescook: thanks :)
<Kmos> ScottK: we're always learning..
<lakritz> if I remember correctly there were plans on integrating Totem and MythTV in some way for Ubuntu Hardy. Anyone know how that's going?
<torkel> lakritz: try #ubuntu-mythtv
<emgent> https://edge.launchpad.net/~ubuntu-gnome-enthusiasts
<emgent> ;)
<lakritz> torkel: ok =)
 * snadge knows of a couple of ubuntu contributors who have cracked it and gone to sidux / OpenSuse etc :(
<snadge> apparently over infighting (heated differences of opinion), and too many bugs which make it through to release.. i tried to pull the philosophy card, and failed to win them back... ahh well :)
<snadge> aka haphazard release schedule
<snadge> perhaps more paid contributors are needed in the area of bug fixing / quality control.. and also to help rally the community to get more involved
<lakritz> snadge: you're not responding to me are you?
<snadge> no sorry, just random noise.. its morning here im having my coffee and stalling going to work :/
<lakritz> hehe, alright
<snadge> trying to think of ideas to improve the quality of ubuntu
<snadge> whilst im still not deterred, its saddening to see talented people give up
<crimsun> pitti: may I pick your brain for a few moments regarding CleanupAudioJumble?
<lakritz> maybe making it easier to contribute to the quality. For example I'd really like that, if I encounter bad translations in a dialog box, there'd be a really easy and direct way to fix it and send my changes upstream
<snadge> im sure this idea has been thought of, but what about offering bounties for fixing bugs.. like if someone makes a confirmed fix to a confirmed problem, they could get a prize or money
<snadge> it might even be possible for someone to make a living out of going through launchpad and fixing problems
<lakritz> that'd be cool, and a way for people to assign bounty to bugs that really nags them =)
<lakritz> that would be sort of a self-organizing system
<snadge> thats right, if a bug really (for want of a better way to phrase it) pisses you off.. you could offer your own money to whomever fixes it
<lakritz> yup
<snadge> and perhaps canonical could sponsor the rest
<snadge> it would especially make sense close to release date
<snadge> get as many people testing, reporting and fixing the rc as possible
<lakritz> they could use the system the same way altough they'd probably be like someone with a lot of bugs nagging them and a lot of money to put in =)
<snadge> shock horror, maybe even delay a release if there are too many "black screen on boot", "no networking" etc problems
<snadge> because all releasing with those types of problems does.. is really aggravate a lot of people
<snadge> people who might not be willing to give ubuntu another try
<lakritz> well they do that already don't they? I seem to remember there was a relesase scheduled for April that got pushed back to June
<crimsun> desrt: yw.
<lakritz> gutsy was pushing it a bit hard (that was the point) but otherwise I think Ubuntu does a fine job with the quality/polish in the releases
<snadge> my brother for example.. has an 8800gt, gutsy wont boot in normal or safe graphics mode.. the suggested fix, use the alternate install.. to which he promptly gave up because it was "too hard" .. granted, you can point the finger at nvidia for not having drivers.. and his laziness for not persisting with it
<lakritz> yupp, really there's just so much you can do when dealing with hardware vendors that don't open up their spec
<cj> anyone know whether it's user error that I can't get javaws to work in hardy on amd64?
<cj> when do we get an Open video card?
<lakritz> if by open you mean that specs are available, intel's are already open and AMD are in the process of opening up as well
<asac> imbrandon: there?
<cj> lakritz: excellent.  by AMD, you mean ATI, no?
<lakritz> cj: since AMD acquired ATI some time ago I guess I meant both
<lakritz> =)
<ScottK2> slangasek: Bug 178536 is fixed on the buildd's now, so could I please have a give back on libmail-box-perl and mime-tools?
<ubotu> Launchpad bug 178536 in launchpad-buildd "Preinstalled Build-Depends not properly detected" [Undecided,Fix released] https://launchpad.net/bugs/178536
<geser> ScottK2: you're fast
<geser> ScottK2: add bioperl to that list
<ScottK2> Right.  Forgot about that one.  That one hadn't burned me personally.
<geser> libpod-constants-perl, libtest-base-perl need also a give-back
<geser> and the HASH bug on the buildd got also fixed, scons can be synced the next time
<slangasek> ScottK2: not my department, I'm not a buildd admin
<ScottK2> Right.
<ScottK2> Sorry.
<elmo> infinity: ^--
<ScottK2> elmo: Thanks.
<ScottK2> It's his fix, so he should get the honor anyway.
<infinity> elmo: Yes dear. :)
<ScottK2> infinity: Thanks to you fixing sbuild for the versioned depends thing, we'd hoped for give backs on libmail-box-perl, mime-tools, bioperl, libpod-constants-perl, and libtest-base-perl
<infinity> ScottK2: The first one was already retried (it was my test case), just gave back the rest.
<ScottK2> infinity: Thanks
<infinity> https://edge.launchpad.net/ubuntu/+source/libmail-box-perl/2.078-1/+build/455558
#ubuntu-devel 2008-01-17
<ScottK2> infinity: Is there any way that can get given back for feisty/gutsy (I could get an SRU for it if needed I suppose)?
<infinity> ScottK2: No can do.
<ScottK2> OK.  I'll do the SRU paperwork.
<infinity> ScottK2: We don't change "release" pockets once a dist is frozen.  You could do -proposed/-updates if you really want it.
<ScottK2> Thanks again.
<ScottK2> That's what I was thinking.
<infinity> ScottK2: Good thing I picked libmail-box as my test case, all the others fail. ;)
<infinity> ScottK2: Hrm.  Kay, my fix is clearly incomplete...
<infinity> ScottK2:
<infinity> http://launchpadlibrarian.net/11401592/buildlog_ubuntu-hardy-i386.libtest-base-perl_0.47-1_MANUALDEPWAIT.txt.gz
<infinity> I'll have to look at that in a sec...
<ScottK2> Argh.
<ScottK2> Well that's something anyway.
<infinity> ScottK2: Curious corner case, should be trivial to fix.
<ScottK2> Glad to hear it.
<infinity> (if provided && version_installed) { ver = version_installed }, ish.
<ScottK2> Curious corner cases are what make this stuff interesting.
<infinity> I'd wonder why it worked for one case and not another, but I don't want my head to explode this close to quittin' time.
<infinity> It'll ruin my evening to be headless.
<ScottK2> And the janitors wouldn't appreciate having to clean up the mess either.
<infinity> Where "the janitors" == "my wife and I".
<infinity> Which would, I suppose, reduce to just "my wife" if I'm nonfunctional.
<infinity> And making her angry is double-plus ungood.
<ScottK2> Ah, right.  Even worse.
 * ScottK2 imagined you hidden in the middle of a data center somewhere.
<infinity> Nah, I'm in Canada.
<snadge> i figured if you contributed to ubuntu you wouldn't be able to have a wife
<infinity> snadge: No, no.  That's spelled "life".
<ScottK2> infinity: Where in Canada?
<infinity> ScottK2: Calgary.
<slangasek> (the empty part)
<infinity> slangasek: :P
<ScottK2> slangasek: That doesn't narrow it down much.
<ScottK2> infinity: Ah.  I've been there.
<slangasek> ScottK2: no, but it provides the proper frame of reference ;)
<infinity> I remember when vorlon used to be nice to me.  Those were good times.
<infinity> No good has come of this nick change.
<slangasek> infinity: that may have been when I was still living in Iowa and had no room to talk
<slangasek> :-)
<elmo> now he's part of the oregon cabal
<elmo> who are scarily cabalish
<ScottK2> slangasek: Where in Iowa (my mother-in-law live in Iowa)?
<slangasek> elmo: yes, it's the true mark of a cabal that we're never actually seen in the same place at once except when we're at conferences
<slangasek> ScottK2: Davenport
<jdong> I thought Iowa was that thing the scheduler did when my disks needed to spin up?
<slangasek> (like keithp pointing and expressing his amazement when we crossed paths at an event in town)
<slangasek> ScottK2: where's your m-i-l?
 * infinity frowns at sbuild.
<ScottK2> slangasek: Monticello.  Brothers in law in Des Moines.
<imbrandon> asac: pong
<imbrandon> wasup?
<slangasek> huh, Monticello, I didn't think anyone lived there; I thought it was just an airport :)
<imbrandon> slangasek: :)
<ScottK2> Heh.  Try trying to find a restaurant open on New Years day (managed, but it was tough).
<slangasek> (and by 'airport', I think I mean 'air strip')
<imbrandon> airport-stip,haircare and tire-lube-express :)
<asac> imbrandon: no, flashplugin sru fix :) status?
<imbrandon> asac: i'm advocating removal and let each browser do it, the fixes we could do would be way to invasive
<asac> do you still ahve the source packages lying around and could update the md5sums?
<asac> imbrandon: what do you mean?
<imbrandon> asac: sure , at the expense of breaking every non firefox browser
<asac> he?
<imbrandon> asac: new flash breaks any non firefox browser, old flash has a security flaw
<slangasek> fsvo "every non firefox browser" equal to "konqueror", I thought?
<imbrandon> so its no win
<imbrandon> slangasek: opera and webkit too
<asac> imbrandon: well ... does the current actually install?
<asac> which link does it use? last time i looked the url used by wget doesn't even has a version
<imbrandon> asac: yes it installs and makes them segfault, major regression, e.g. no-go
<asac> (except 9)
<asac> yes, but now it doesn't install at all ... or does it?
<imbrandon> no it doesnt, but i will not introduce a fix that breaks someone more, i'm advocating removal
<imbrandon> if you wish to follow another patch i'll be happy to help
<imbrandon> but i wont, i delt with it for weeks with no good awnser
<asac> imbrandon: so the problem why the sru has been cancelled wasn't a md5sum mismatch?
<imbrandon> correct
<imbrandon> it was because it causes konqueror and opera to segfault
<asac> opera?
<imbrandon> yes only firefox , safari and IE support xembed
<imbrandon> the rest segfault
<imbrandon> and kubuntu shipps konqueror as a default browser, we cant intentionaly break it
<imbrandon> asac: this was all covered in the -devel ML thread iirc
<imbrandon> :)
<edsiper> I'm trying to compile a program and it can't find the strnstr function, is something missed?
<slangasek> edsiper: the fact that strnstr() is not a standard C function?
<edsiper> Standard C Library (libc, -lc)  :/
<edsiper> string.h
<edsiper> t.c:(.text+0x40): undefined reference to `strnstr'
<StevenK> % grep -c strnstr /usr/include/string.h
<StevenK> 0
<edsiper> :/
<slangasek> edsiper: it's not a standard C function, and glibc doesn't implement it.
<edsiper> :/ , thanks
<keescook> asac: do you know if there will there be a newer release of gnash before hardy freezes?
<slangasek> more importantly, why has gnash regressed on my system from gutsy to hardy and no longer able to play youtube videos? :)
<bddebian> heh
<RAOF> slangasek: Because youtube changed their stuff, I think :(.
<RAOF> keescook: http://wiki.gnashdev.org/wiki/index.php/Release_0_8_2 suggests they'd like to get 0.8.2 out before the end of January, so it seems the answer is "yes".
<linxuz3r> hey guys
<linxuz3r> wuddup
 * Hobbsee waves
 * RAOF shores
<slangasek> RAOF: those dirty, stinking apes
<RAOF> slangasek: Indeed.
<srbaker> heya folks
<srbaker> what's the status of the ATI open source drivers?
<kelmo^cc> hi asac. you got a moment to touch base about wpasupplicant
<Burgundavia> srbaker: they exist and work, you are better asking upstream
<Burgundavia> better off, rather
<srbaker> Burgundavia: hey man.
<srbaker> Burgundavia: know where i can find docs on how to get them working on ubuntu?  i have a dell with ati video that's particularly horrible to use with the fglrx bullshit
<srbaker> where is upstream?
<srbaker> the whole ati open source thing confuses the hell out fo me
<Burgundavia> upstream is radeonhd
<Burgundavia> which is Novell/Suse engineers
<srbaker> is there a website for that?
<Burgundavia> well, are you certain that you need radeonhd? it is only for the very newest of ATI drivers
<Burgundavia> cards, rather
<srbaker> Burgundavia: X1400 ?
<Burgundavia> yep, that is r500
<srbaker> the x1400 was listed as supported by the open source effort in an article i read
<srbaker> awesome
<srbaker> phoronix has docs
<srbaker> thanks
<srbaker> i couldn't get any relevant hints until i punched radeonhd into google
<Burgundavia> http://en.wikipedia.org/wiki/Radeon_R520
<srbaker> Burgundavia: any idea if the radeonhd thing will get into hardy?
<Burgundavia> if yes, as alpha only
<Burgundavia> not on by default
<srbaker> that's okay.  as long as it'll be easy to get going
<srbaker> okay, i have to go
<srbaker> thanks
<Burgundavia> they don't even have 2d really nailed down
<dholbach> good morning
<somerville32> good morning, dholbach
<dholbach> heya somerville32
<TheMuso> c
<TheMuso> ugh
<somerville32> TheMuso, It is ok. we understand.
<somerville32> wrong tab
<TheMuso> somerville32: Not this time it wasn't.
<pitti> Good morning
<asac> keescook: i will ask gnash devs about their plans
<asac> pitti: morning!
<warp10> morning pitti!
<Hobbsee> oh noes, it's pitti!
<MacSlow> *yawn*
<MacSlow> greetings everybody!
 * Hobbsee force feeds MacSlow some coffee
 * MacSlow reminds Hobbsee that coffee does not apply
<MacSlow> only coke and flying horse... which might be considered disgusting for some in the morning :)
<MacSlow> hm... "flying horse" is probably not known outside of Germany
<pitti> hey MacSlow, warp10, Hobbsee, asac!
<pitti> calc: hm; building OO.o on artigas didn't help, but at least the giveback now made it build on powerpc
<StevenK> Morning pitti
 * pitti hugs StevenK
<Hobbsee> yay, i get a greeting from pitti today!
 * pitti hugs Hobbsee ecstatically
<Hobbsee> :D
 * Hobbsee hugs pitti lots back!
<Mithrandir> pitti: it's ever so slightly annoying that apport complains about packages that fail to install or upgrade, can we turn that off, or can I turn apport off somehow?
<pitti> Mithrandir: hm, not sure whether apt has a config option for that; mvo?
<ogra> grrr ....
<ogra> since one week i fix depencedcy breakage on the CD to have *one* testable CD before alpha4 .... now all deps are fine and the kernel modules are MIA ...
<mvo> Mithrandir: you can set Dpkg::ApportFailureReport to false, then it will leave oyu alone
<ogra> *sigh*
<Mithrandir> mvo: cheers.
<pitti> ogra: d-i needs a rebuild against 2.6.24-4, right?
<ogra> pitti, yup, indeed
<ogra> i was suspecting that when i saw the linux upload :/
<ogra> pitti, seems colin already did that
<nixternal> any archive admin, did a booboo, need kblogger-kde4 removed please
<pitti> nixternal: done
<nixternal> thanks pitti
<pitti> asac: btw, is there anything being done about making SSL cert violation exceptions actually work in ff3?
<pitti> asac: ATM I have to run ffox2 for such sites (only reason why I still have it installed)
<asac> pitti: any example?
<pitti> oh, and missing flash support, of course
<pitti> asac: https://mail.piware.de/
<asac> pitti: flash support is avail ... on amd64 its broken because ia32-libs need libselinux iirc
<pitti> asac: ah, I see; I'll fix that then (OTOH flash works fine in ffox2, so I wonder why it is a problem in ia32-lis)
<asac> pitti: for me your site works ... i add an exception on the error page
<asac> doesn't that work for you?
<pitti> asac: if I click on "Or you could add an exception" I just get a yellow box with "You should not add ...., do it in the advanced encryption settings"
<pitti> asac: but there I don't see anything where I could add an exception
<asac> pitti: which ffox version?
<asac> i have buttons there
<pitti> Version: 3.0~b3~cvs20080101t1000+nobinonly-0ubuntu1
<asac> 1) "Get me Out of here" 2) "Add Exception ..."
<asac> ok let me try to get that version up here :)
<asac> pitti: same version for xul?
<asac> (well s/3.0/1.9/)
<pitti> asac: http://people.ubuntu.com/~pitti/tmp/ffox-ssl-cert.png
<pitti> asac: xulrunner-1.9 Version: 1.9~b3~cvs20080101t1000+nobinonly-0ubuntu1
<seb128> that's the same error I get on http://bugzilla.freedesktop.org using epiphany-browser
<asac> indeed its broken on that snapshot. i will update it then i guess
<seb128> asac: share the crack of the day version ;-)
<asac> seb128: yes ... for epiphany this feature needs to be implemented
<pitti> asac: ok; as long as this is not the final thing, I'm good :)
<pitti> asac: too bad that I can't get a working cert for my server... but there are four virtual domains sharing one IP, so the server cna only have one SSL cert; and adding alternative names doesn't work with cacert.org
<pitti> so I can only either have a working signature or working alternate names *sigh*
<asac> pitti: your server cannot be configured to use dedicated certs for virtual hosts?
<pitti> asac: no, apache doesn't support that
<pitti> asac: you first need to establish an SSL connection (IP-based)
<asac> right :)
<pitti> and only afterwards apache can decide which domain you want, based on the hostname you requested
<pitti> so, one IP -> one cert
<asac> get more ips :)
<pitti> asac: IPv6 FTW!
<asac> yay ;)
<ion_> pitti: Indeed
<Keybuk> ITYM F::T::W::
<pitti> ?
<Keybuk> :: is used in IPv6 address notation for "all the bits missed out"
<pitti> ah, :0
<pitti> :) even
<ion_> ::)
 * pitti cleans his shift key
 * Hobbsee mourns the loss of her special keys
<emgent> heya
<torkel> pitti: Preferences->Advanced(Encryption)->View Certificates->Add Execption...
<pitti> ah, in the Servers tab
<pitti> not that easy to discover
<torkel> no, took me a while to find it
<pitti> ah, cool, that works
<pitti> thanks
 * soren lunches
 * pitti pokes ia32-libs
 * LongPointyStick pokes pitti 
 * ion_ peeks
 * torkel cuts LongPointyStick in two with an axe. Two sticks does more harm than one :-)
 * LongPointyStick becomes EXTRA pointy, and mutilates torkel 
<persia> pitti: Might it make sense to split that a little?  The package is becoming incredibly huge.
 * torkel looks around to find the chainsaw...
<pitti> persia: well, ideally more source packages would build lib32foo* themselves
<pitti> oh, wow
<pitti> using lzma makes the deb shrink from 38.3 MB to 20.2
<persia> pitti: With multilib, that's now not unreasonable.  Perhaps a full migration away from ia32-libs as a release goal for next time?
<pitti> AFAICS it should be ok to use lzma now (OO.o does it), right? or does that pose a problem for Soyyuz?
<pitti> hm, current OO.o debs use bzip2
<pitti> so the changelog is confusing
<tjaalton> LongPointyStick: what happened to your keys?
<LongPointyStick> tjaalton: my ctrl, alt, win, etc keys all stop working sometimes.
<LongPointyStick> fujitsu also has it, and he has the same video card
<tjaalton> LongPointyStick: oh..
<tjaalton> intel?
<LongPointyStick> yup
<pitti> persia: hm, I was told that lzma is not supported yet :/
 * pitti reverts
<persia> Not yet?  Hrm.  All the tools support it.  Any idea when it is coming?
<pitti> persia: it's supported by dpkg and everything, but not in soyuz
<tjaalton> LongPointyStick: ok, don't have any suggestions right now.. I've had no problems with evdev though (it'll be used when input-hotplug kicks in)
<persia> pitti: Right.  I'm just hoping it's on the feature plan for 2.2 or 2.3 (if I remember my versions correctly).
<pitti> yay flash on firefox-3.0 on amd64
<LongPointyStick> tjaalton: OK
<pitti> asac: cool, purging firefox-2 then :)
<pitti> oh, hm, seems that devhelp still needs it
<pitti> seb128: devhelp resists against xulrunner, or does it just need to be done?
<asac> pitti: i uploaded new devhelp yesterday
<asac> (and hopefully didn't forget to flip depends from firefox to xulrunner-1.9 :))
<seb128> pitti: what asac said
<seb128> pitti: btw the new f-spot uploaded today has no depends on beagle so it should be alright to move it to universe now
 * pitti hugs seb128
<asac> pitti:  0.17-1ubuntu2
 * seb128 hugs pitti back
<seb128> I didn't do the update though ;-)
<Kmos> i installed firefox-3.0 manually for the first time and it says to restart it.. i maybe be confused with firefox 2 :)
<asac> Kmos: yes ... please file a bug
<Kmos> asac :)
<asac> pitti: ok ... apparently control.in struck us here ... it still depends on firefox... reuploading
<pitti> asac: heh; I just wondered, I have that version
<cjwatson> persia: I forget the version number but it's on the feature plan for next week's LP release
<persia> cjwatson: Excellent news.  Thank you.
<\sh> tkamppeter, thx so much for your work on the printing stuff..took me only 1 minute to get my hp laserjet 1200 to run on hardy :)
<pitti> \sh: like, plug it in, wait 10 seconds, done? :)
<\sh> pitti, yeah :)
<soren> How can waiting take an entire minute? :)
<soren> Er..
<soren> How can waiting 10 seconds take an entire minute? :)
<\sh> soren, printing the testpage ;)
<soren> Ah.
<pitti> well, 50 seconds for being so amazed and stunned how easy that was :-P
<\sh> heheh
<\sh> but really, on windows I would have had to install some drivers etc.
<Keybuk> yes, but on windows, you have to install some drivers (finding the CD, dusting it, cleaning it, giving up and finding the driver on the net, downloading it, downloading it again for the right language, installing it, restarting your system) for a USB storage deviec
<ogra> Keybuk, it gets really bad then if the storage device has your NIC driver on it *g*
<\sh> Keybuk, well, this driver problem sucks...I got this printer for free so I don't have any documentation or driver cd around...
<soren> Keybuk: Yeah. There's no doubt we've got the right approach to providing drivers. Now they just need to suck less. :-/
<\sh> pitti, regarding the maintainer field...I'm not sure if we need to change the maintainer field for rebuilding uploads, (-XbuildY) enlighten my horizon pleas :)
<geser> \sh: afaik it's only needed for -XubuntuY. And the tools don't complain about it for -XbuildY :)
<\sh> geser, k :)
 * persia notes that -XbuildY uploads should not contain any changes beyond the changelog
<pitti> \sh: no, it's not necessary for rebuilds (sorry, was at lunch)
 * pitti demotes beagle
<pitti> ... and wv along with it; there goes another HardyReducingDuplication point :)
 * \sh needs to resolve bug #183382 somehow...
<ubotu> Launchpad bug 183382 in claws-mail "[MoM SYNC] claws-mail 3.2.0-2" [Wishlist,Confirmed] https://launchpad.net/bugs/183382
<pitti> \sh: can do now if it's blocking you
<\sh> pitti, would be great...so I can go on with the plugin package for claws
<pitti> \sh: can you please describe the ubuntu changes and why they can be dropped? there's no changelog and nothing else...
<\sh> pitti, source rebuild only was the change
<pitti> oh, I see
<\sh> pitti, Version: 3.1.0-2build1
<\sh> is the old one
<pitti> so, no ubuntu changes actually
<seb128> pitti: I'm going to do sync requests soon I've done those yesterday
<pitti> \sh: done
<\sh> pitti, thx
<pitti> seb128: so, you got one less :)
<seb128> pitti: ok ;-)
<geser> infinity: after fixing the perl-modules problem on the buildds, building libpod-constants-perl still doesn't work: "Setting up libtest-simple-perl (0.62-1) ..." and then "After installing, the following source dependencies are still unsatisfied: libtest-simple-perl(inst =*=PROVIDED=*= ! >= wanted 0.18)" (see
<geser> http://launchpadlibrarian.net/11406108/buildlog_ubuntu-hardy-i386.libpod-constants-perl_0.16-1_MANUALDEPWAIT.txt.gz)
<jpatrick> could someone do the qca2 and libqca2-plugin-ossl backports, please? they're needed for KDE 4
<seb128> jpatrick: I'll do backports soon when I do syncs
<jpatrick> seb128: thanks :)
<seb128> jpatrick: you are welcome
<Mithrandir> Error forking '/usr/lib/openoffice/program//soffice': 'Failed to execute child process "/usr/lib/openoffice/program/soffice" (Bad address)'
<Mithrandir> win.
<pitti> Mithrandir: as a workaround, don't start 'oowriter', start 'ooffice'
<Mithrandir> indeed
 * pitti wonders whether the new OO.o fixes that, but doesn't dare to upgrade and lose all the ooo-l10n stuff
<pitti> ah, the heck with it; /me upgrades
 * LongPointyStick watches the machine blow up
 * Mithrandir waves the LongPointyStick around.
 * LongPointyStick is waved.  argh!
 * LongPointyStick pokes Mithrandir with her other half
<Mithrandir> hah!  You didn't think of that when you chose the nick, did you?
<Mithrandir> I'm holding the other half.  You're not bendy, are you?
 * ion_ unwaves LongPointyStick
 * LongPointyStick is in 2 pieces
 * Mithrandir pokes ion_ with the LongPointyStick
<LongPointyStick> you're only holding the first half.
 * LongPointyStick catches fire
 * LongPointyStick burns Mithrandir 
 * Mithrandir continues waving the FlamingLongPointyStick about
 * Mithrandir catches fire.
 * LongPointyStick watches Mithrandir burn to a crisp
 * LongPointyStick magically recombines, and pokes ion_ to pices
<LongPointyStick> er, pieces
<sladen> LongPointyStick has quite a Long nick
 * pitti puts on his flamewar-proof asbesto pants and cleans up
<Mithrandir> pitti: she'll still burn your hands.
 * LongPointyStick pierces the asbestos pants, with her pointy end
 * LongPointyStick breaks one of pitti's knees in the process.  oops!
<pitti> dang!
 * pitti limps back to his chair and continues python hacking then
 * LongPointyStick breaks the chair
 * LongPointyStick watches pitti fall to the floor
<pitti> not your best mood today, eh? :)
<LongPointyStick> pitti: no, i'm naturally sadistic.  didn't you know?
<pitti> Mithrandir: ah, OO.o du jour doesn't break like that any more \o/
<pitti> LongPointyStick: I can feel it in my knee
<Mithrandir> pitti: but it lacks translations?
<pitti> Mithrandir: yes, since the l10n stuff got uninstalled
<LongPointyStick> sladen: yes.  this is true
<pitti> ooo-l10n FTBFS FTW
<LongPointyStick> pitti: it goes with my full nick, anyway.
<jdstrand> pitti: hi!
<pitti> hey jdstrand, how's it going?
<jdstrand> pitti: I uploaded a new package (ufw) yesterday. Since it's new I know it needs to be manually added-- do I need to do anything else besides the upload?
<jdstrand> pitti: I am well-- and you?
<pitti> jdstrand: it's in the NEW queue and will be investigated; no further action needed from you for now
<jdstrand> pitti: ok thanks
<pitti> Mithrandir, StevenK: we are going to replace gnome-keyring-manager with seahorse in ubuntu-desktop; do you want the same for mobile?
<Mithrandir> does it do the same thing?
<pitti> seahorse does gpg/ssh/the world in addition
<pitti> but seahorse is maintaned, g-k-m not (seb128 knows more details)
<seb128> gnome-keyring-manager is just a GUI to do keyring changes
<Mithrandir> I think we just want g-k-m for NM keys and such, so as long as seahorse supports that, we're happy with having that instead.
<Mithrandir> we care less about the UI than the daemon
<pitti> Mithrandir: independently from that, NM's inability to change  wpa passphrases is a major usability bug which should just get fixed
<Mithrandir> yes
<pitti> Mithrandir: ok, so I'll change the seeds along, and we'll see how it goes? (I confirmed that seahorse can edit keyring keys)
 * LongPointyStick doesn't particularly like how seahorse appears to like being able to show the ssh key passphrase on demand.
<pitti> seb128: oh, seahorse needs a MIR, too, btw
<ion_> I use libpam-ssh and keychain (with some glue between them)
<seb128> pitti: right
<Mithrandir> pitti: we're just interested in the daemon, afaik, but seahorse should be fine, yes.
<pitti> seb128: bug report is enough
<seb128> pitti: ok, thanks
<pitti> seb128: seahorse seeded, seeds merged
<pitti> not rebuilding -meta yet, until seahorse gets promoted
<seb128> pitti: cool
<pitti> ./libseahorse/libseahorse.a - a-haa
 * Hobbsee stabs this keyboard bug
<TheMuso> What keyboard bug?
 * Hobbsee loses metakeys, like shift, alt, ctrl, capslock, win, every once in a while, until restarting x
<TheMuso> oo fun
<Hobbsee> and it's happened twice tonight
<Hobbsee> and it's really starting to annoy me.
<torkel> Hobbsee: it has been hit by a LongPointyStick too many times?
<Hobbsee> torkel: i'm not the only one who gets it
<Hobbsee> but it's happening mor eoften than it used to
<cjwatson> Hobbsee: are you using vmware?
<Hobbsee> cjwatson: nope
<cjwatson> ok, it happens to me sometimes with vmware
<Hobbsee> cjwatson: this is standard hardy, upgraded from gutsy.  real hw.
<cjwatson> I have a button on my panel that does 'setxkbmap <appropriate arguments>'
<cjwatson> that clears it for me; try that?
 * Hobbsee wonders what the appropriate arguments would be, and checks the man page
<Hobbsee> er, is there any way i can close vi without using the colon/
<soren> Hobbsee: <ESC>ZZ
<soren> Hobbsee: It saves, though.
<Hobbsee> soren: ah, thanks
<Hobbsee> soren: no dice.  esc classes as a special key, and has died too.
<Mithrandir> Hobbsee: paste ^[ into the terminal
<Mithrandir> it's esc
<Mithrandir> or use an on-screen keyboard?
 * TheMuso points Hobbsee to onboard
<ogra> open a website and copy paste it :)
<ogra> (or from here) colon -> :
<Hobbsee> ;0
<cjwatson> 14:44 <cjwatson> US keymap?
<cjwatson> 14:44 <cjwatson> setxkbmap -rules xorg -layout us
<cjwatson> 14:45 <cjwatson> the only other way I can think of is 'ZZ', but you may not be able to get that either. Copy-and-paste the colon from elsewhere.
<cjwatson> Hobbsee: ^--
<Hobbsee> cjwatson: ah, thanks.  same problem though
<cjwatson> (or close terminal window, let it get SIGHUPped, and recover the session later, assuming it's vim)
<Hobbsee> yeah
<Hobbsee> cjwatson: anyway, that doesn't clear it for me either.
<cjwatson> ok, worth a try
<Hobbsee> indeed.  thanks for the attempt ;0
<pitti> seb128: (argh autoconf argh)
<seb128> pitti: (autotools are grrrrr)
 * Mithrandir kicks LP in the proverbial SSL nuts.
<Gringo_> is there some kind of alternative patching to -ck in the hardy kernel?
<Gringo_> because -ck stopped after 2.6.22
<Gringo_> does the CFS have the same results?
<Hobbsee> third time lucky
<Gringo_> well actually i thought that -ck also included some I/O work
 * soren is confused
<Gringo_> while CFS is only a scheduler
<Gringo_> i'm not a developer, so i could very well be wrong
<soren> cjwatson: Could you clear something up for me, please? Our CD's can display two different things when they first start up. There's the old orange-only ubuntu logo with the reflection and "boot:" prompt below it, and there's the fancy coloured thing with the menu and such below it... Where do each of them come from?
<cjwatson> a mix of debian-installer (text), debian-cd (images and menu items), and gfxboot-theme-ubuntu (fancy menu)
<soren> cjwatson: Hm. So if I'm using the gfxboot test thing you showed me once, what am I supposed to see? The fancy menu?
<cjwatson> assuming gfxboot is working, you should see the fancy menu
<cjwatson> it might fall back to the old-style one
<cjwatson> (which is plain isolinux)
<soren> Hm.. I see.
<soren> cjwatson: The long description in gfxboot-theme-ubuntu claims that the logos and texts are not in that package.. So they're in debian-cd?
<cjwatson> right, and debian-installer
<cjwatson> my apologies for it being spread around; I was trying to fit it in around where stuff was already being maintained
 * soren fails to see how that would land in the test thing..
<Mithrandir> doko: I get errors install ing icedtea-java7-bin on hardy (lpia)
<Mithrandir> doko: /usr/lib/jvm/java-7-icedtea/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
<Mithrandir> doko: is this known, and is there a workaround?
<soren> cjwatson: As long as you're willing to answer the odd question about it from time to time.. :)
<cjwatson> I constructed the test rather by hand :)
<soren> cjwatson: And you claim that when you run "make" in that directory, you see the fancy menu?
<cjwatson> soren: yup
<cjwatson> perhaps your qemu's screwed, or perhaps you commented GFXBOOT out in tree.safe/isolinux.cfg?
<soren> cjwatson: I did not. An to be sure, I just refetched the test suite and nuked the one I had lying around.
<soren> cjwatson: I only see the simple logo and the boot: prompt.
<soren> cjwatson: Something's not right. Booting the mini.iso (as found on archive.ubuntu.com) gives me the old logo and boot: prompt (just like your test thing), but the daily CD images gives me the fancy menu. Any ideas or should be look at it next week?
<soren> s/be/we/
<pitti> tkamppeter: can you please look into bug 183652 for hardy?
<ubotu> Launchpad bug 183652 in avahi "CUPS fails to start on boot" [High,Confirmed] https://launchpad.net/bugs/183652
<cjwatson> soren: I'm a bit lost and also busy with some other things, so next week would be good
<soren> cjwatson: Alright.
<norsetto> ping pitti
<mvo_> pitti: do you mind if I upload a dbus that restarts itself if upgraded from dapper? unless you come up with a better solution for the current dapper->hardy desktop upgrade problem
<seb128> mvo_: a dbus which restarts itself? doesn't look like a good idea, you will close running nautilus, break network, etc
<ion_> A dbus that can restart itself is a good idea. If it canât handle it, it has been designed stupidly.
<mvo_> seb128: hm, currently on dapper->hardy the postinst of hal (at least) breaks because hal can not restart. pitti said its most likely a incompatible hal/dbus issue
<calc> how do you create message filters in evolution per account?
<calc> eg... how do you map evolution usable for imap
<calc> s/map/make/
<seb128> calc: what do you mean?
<calc> seb128: when i create a filter it doesn't ask me what account to use it for, i want to move all messages of a certain type on an account to a folder in that account
<calc> maybe Edit -> Message Filters is the wrong place?
<seb128> calc: edit, message filter, add
<seb128> calc: then the combo where you have sender, click on it
<seb128> and select source account in the list instead?
<calc> ah source account i see it :)
<calc> thanks :)
<seb128> you are welcome
 * calc hugs seb128 
 * seb128 hugs calc
<seb128> calc: switching to evolution?
<seb128> what did you use until now?
<calc> seb128: yea i switched from thunderbird, newer thunderbird's imap filtering is broken
<seb128> ah, k
<Mithrandir> client side filtering considered harmful
<calc> or at least was last i tested it, i had been holding the version on my box for a while until i decided to finally switch
 * Mithrandir hides.
<calc> Mithrandir: is there a way to filter for our email on the server?
<calc> Mithrandir: if so i wouldn't mind setting that up :)
<infinity> geser: I know, I have another fix in the pipeline.
<Mithrandir> calc: no idea, I run my own mail server.
<calc> Mithrandir: oh ok
<calc> Mithrandir: i just imap directly to i.c.c
<Mithrandir> I like to stay in touch with my inner sysadmin
<calc> Mithrandir: hehe
<calc> one other question, how do i run filters against a mailbox?
<tkamppeter> pitti, about bug 183652, I have rebooted Hardy already several times (due to an X problem) after the boot sequence got changed in Hardy. I never had a problem.
<ubotu> Launchpad bug 183652 in avahi "CUPS fails to start on boot" [High,Confirmed] https://launchpad.net/bugs/183652
<calc> ah i think i found out how
<calc> select all messages and apply filter
<tkamppeter> pitti, ping
<norsetto> must be a very popular person this pitti, I wonder if he offers often drinks here
<\sh> hoho...I didn't see that...sun bought mysql? ,-)
<Mithrandir> \sh: that's so yesterday's news.
<\sh> Mithrandir, did see it on our german newsticker...damn
<pitti> re
<keescook> pitti: say, you use gnome-gpg, right?  does it still work for you in hardy?
<pitti> keescook: no, it stopped working a while ago; I switched to seahorse, that's much better anyway (also works in mutt, chroots, etc.)
<pitti> mvo_: well, if that helps, go ahead
<keescook> pitti: but things like requestsync still call it...
<pitti> mvo_: but I thought it would be more robust to not restart dbus and any client on upgrades from dapper?
<keescook> pitti: what's required to "switch" to seahorse?
<pitti> mvo_: i. e. we should fix postinsts of hal etc. to not restart on such upgrades, only from gutsy ones
<pitti> keescook: if you don't have gnome-gpg installed, requestsync won't use it
<\sh> pitti, hopefully seahoarse works also good with gpg + smartcards ;)
<pitti> keescook: just install it and restart your session
<pitti> norsetto: pong
<pitti> tkamppeter: well, the bug doesn't seem to occur very often, yes
<norsetto> pitti: hey, was wondering if you could glance at bug 183293 when you have 5 min.
<ubotu> Launchpad bug 183293 in kfolding "[FTBFS] kfolding (1.0.0-rc2-5) fails to build in hardy" [Medium,In progress] https://launchpad.net/bugs/183293
<keescook> pitti: oh, yes, that's much better.  :)  much saner caching options too.  yay.  :)
<tkamppeter> pitti. for me the bug looks like that the avahi startup script exits before the avahi daemon is ready to take tasks.
<pitti> tkamppeter: exactly
<tkamppeter> This means CUPS gets started before the avahi daemon is ready, the daemon is half-ready which is even worse for CUPS, as CUPS crashes then instead of running without avahi support.
<tkamppeter> pitti, so the problem is an avahi bug (I have given an appropriate comment in one of the bug reports).
<pitti> norsetto: answered in the bug
<norsetto> pitti: ok, dankeschoen
<tkamppeter> pitti, I have answered on bug 183652, what needs to be fixed is avahi, as other services can break as well as CUPS. It would be enogh to put a loop at the end of the startup script of avahi, which checks the avahi daemon once a second and exits if the daemon is ready or a timeout is reached.
<ubotu> Launchpad bug 183652 in avahi "CUPS fails to start on boot" [High,Confirmed] https://launchpad.net/bugs/183652
<pitti> tkamppeter: the better solution would be to make cups not fall over in this case and try again later, though
<pitti> tkamppeter: that would avoid making the boot process longer unnecessarily, and more robust too
<tkamppeter> pitti, so we should simply add a loop to the CUPS startup script and in the case of failure do two additional start attempts 2 seconds later or should we better patch the daemon to activate and deactivate avahi support on the fly?
<pitti> tkamppeter: the latter would be better IMHO
<pitti> tkamppeter: as a minimum cups shouldn't crash if avahi is not available
<pitti> admins might uninstall avahi if they don't need it
<tkamppeter> pitti could you do this change or should we report the problem upstream?
<pitti> and ideally it would try to register printers to avahi every now and then (perhaps at the same time when it broadcasts its printers over teh cups browsing protocol?)
<pitti> tkamppeter: upstream
 * pitti <- no time for cups hacking ATM
<tkamppeter> pitti, I will file an upstream bug in CUPS and it depends on Mike Sweet's fix whether we can provide CUPS' DNS-SD broadcasting or not. If he does not fix it in time then CUPS and Avahi are not ready yet for DNS-SD printer broadcasting.
<pitti> tkamppeter: right, we can still disable it in hardy if needed
<pitti> but would be cool to fix, and it affects other distros, too
<tkamppeter> pitti, but I will also leave the avahi task open as startup scripts should only exit if the daemons are ready, otherwise there is no control for services which depend on each other.
<pitti> ok
<\sh> pitti, how do I read http://people.ubuntu.com/~ubuntu-archive/NBS/gnustep-back0.11 when gnustep-back0.11 doesn't exists anymore?
<pitti> \sh: that's precisely what 'NBS' means :)
<pitti> the binary still exists, but it's not built from any source package any more
<pitti> \sh: i. e. this lists the currently existing reverse dependencies; they all need to get fixed, since before hardy's release we need to kill all NBS pacakges
<\sh> pitti, ah.....ok :)
<pitti> mostly that amounts to no-change uploads to rebuild against current libs
<\sh> pitti, ok...starting to work on this
<geser> \sh: in case of gnustep-back0.11 some sort of transition is probably needed, other gnustep packages went already through this transition
<tkamppeter> pitti, http://www.cups.org/str.php?L2676, and bug 183652 is updated now.
<ubotu> CUPS bug 2676 in Core CUPS Software "Scheduler does not start if CUPS is started very shortly after the avahi daemon" [Priority moderate,New]
<ubotu> Launchpad bug 183652 in avahi "CUPS fails to start on boot" [High,Confirmed] https://launchpad.net/bugs/183652
<tkamppeter> STR 1
<tkamppeter> CUPS bug 1
<ubotu> CUPS bug 1 in Core CUPS Software "Missing links and out-of-date systems overviews on documentation page" [Priority low,Closed w/resolution] http://www.cups.org/str.php?L1
<pitti> tkamppeter: just saw the mail, thanks
<pitti> wow, ubotu now knows about cups' STR system? neato!
<tkamppeter> pitti, there is only a small thing to improve, it should also react on "STR xxx".
<pitti> well, that might also be 'suspend to ram'
<pitti> cups bug 1234 is great and consistent within ubotu
<ubotu> CUPS bug 1234 in Core CUPS Software "When setting BrowseProtocols to all Cups stops working" [Priority low,Closed w/o resolution] http://www.cups.org/str.php?L1234
<tkamppeter> But "suspend to ram 1234" does not make much sense, so that if someone writes STR 1234, he most probably means CUPS bug 1234.
<ScottK> tkamppeter: STR is a reasonably generic term for Software Trouble Report.  I don't hink of it as CUPS specific.
<tkamppeter> pitti, another problem, I wanted to make use of my MOTU rights and have suggested flphoto as a new package on REVU, as MOTU I need only the vote of one additional MOTU, but no one has touched my package yet.
<pitti> tkamppeter: can you please mail me the URL? I'll have a look at it tomorrow
<tkamppeter> pitti, bug 183243
<ubotu> Launchpad bug 183243 in ubuntu "New Package: flPhoto - Photo Manager with Great Printing Capabilities" [Undecided,In progress] https://launchpad.net/bugs/183243
<ScottK> tkamppeter: It would also be nice if you could find some time for reviewing as there are many more packages on REVU than reviewers to look at them.
<pitti> tkamppeter: ok, I opened a tab, so I won't forget
<tkamppeter> pitti, thanks.
<pitti> what does it take to get an account on REVU, btw?
<tkamppeter> pitti, https://wiki.ubuntu.com/MOTU/Packages/REVU
<pitti> ah, I see; I'll ask on #u-motu
<ScottK> pitti: You have to do an upload to REVU.  It can be anything.
<pitti> ScottK: hm, above wiki page says to just ask there to get ack'ed as a reviewer
<ScottK> First you have to have an account though.
<ScottK> IIRC.
<pitti> hm, then above documentation needs to be updated
<ScottK> It's been more than half a year since I got set up, so I may remember wrong.
<infinity> Building kde4libs 4:3.96.0-1ubuntu1
<infinity> for  Kubuntu Members Ubuntu Gutsy PPA
<infinity> Building kde4libs 4:3.96.0-1ubuntu1
<infinity> for  Sarah Hobbs Ubuntu Gutsy PPA
 * infinity wonders if we really need two. :)
<pitti> nice race
<infinity> Not so much a race, it's different PPAs...
<pitti> ah, ok
<infinity> Just... Duplicate effort, I'm assuming.
<jpatrick> kde4libs 4:3.96.0 is the old package no?
<geser> tkamppeter: I've done a quick review of flphoto for you.
<geser> tkamppeter: is the /usr/share/mimelnk/ directory in use? I've only one file below it here (GNOME)
<tkamppeter> geser, the upstream package contains a mime type in .desktop format, and such mime type files I have only found in /usr/share/mimelnk/  on an installed Hardy system.
<tkamppeter> geser thanks for the review, I will fix the issues and reupload. The package structure is derived from XPP (also FLTK-based), but XPP was not updated for some time.
<geser> tkamppeter: I just wondered because my /usr/share/mimelnk isn't really populated
<tkamppeter> Mine is full, it contains 100s of files in subdirs
<pitti> mine is empty, too, just image/vnd.djvu.desktop
<\sh> pitti, libpt-1.10.0 is replaced with libpt-1.11.2?
<pitti> apt-cache showsrc pwlib|grep ^Binary
<pitti> oh, there's a pwlib-titan in addition now, which has the never version
<\sh> pitti, that's what I wanted to know...what's the right source package...pwlib or pwlib-titan ,-)
<\sh> pitti, and reading http://people.ubuntu.com/~ubuntu-archive/NBS/libpt-1.10.0 I think we go with pwlib-titan ;)
<pitti> \sh: pwlib itself seems to have 1.10.10-<something>
<\sh> s/think/thought/
<pitti> \sh: depends on your build dep; libpt-dev is pwlib, libpt-1.11.2-dev is -titan
<pitti> they both build-conflict to each other
<\sh> pitti, so I think we stay with pwlib only, not with the -titan source?
<pitti> \sh: I don't know TBH
<geser> tkamppeter: are you using KDE or GNOME?
<tkamppeter> geser, I am using GNOME
<tkamppeter> geser, which copyright holders are missing in the debian/copyright file of flphoto
<geser> tkamppeter: grep Copyright *  inside the package dir:
<geser> espmsg.[ch]: * Copyright 1997-2005 by Easy Software Products.
<saivann> Hi everyone, I'm triaging bug #147623 and somebody in the bug report specified that upgrading actual vesafb-tng in the linux kernel to uvesafb would fix problems with AMD64 and usplash with nvidia closed source driver, does this make sense?
<ubotu> Launchpad bug 147623 in usplash "[EM64T]When booting, screen stays black." [Medium,Confirmed] https://launchpad.net/bugs/147623
<saivann> If yes, it could be considered as a improvement for Hardy
<saivann> http://dev.gentoo.org/~spock/projects/uvesafb/
<geser> tkamppeter: grep also espmsglib.c for copyright (ESP and Aladdin), fldcraw.c:   Copyright 1997-2006 by Dave Coffin, flstring.h: * Copyright 1998-2005 by Bill Spitzak and others., jpegint.h: * Copyright (C) 1991-1997, Thomas G. Lane., transupp.[ch]: * Copyright (C) 1997, Thomas G. Lane.
<tkamppeter> geser, so the documentation of the software is a false declaration of copyright and license, as I packaged that I simply trusted in Mike Sweet. An upstream bug should be reported.
<lool> tkamppeter: Hey, I tried stopping avahi and cupsys and then "starting avahi && starting cupsys", then I stopped and started cupsys, both cupsys error logs at debug level 2 were identical; could you hint me into reproducing the cupsys failure?
<tkamppeter> lool, it was only observed on boots of some Hardy and some Gutsy boxes. Strange is why your command line does not reproduce it. Perhaps it depends also on speed and load of your computer.
<lool> tkamppeter: Could very well be
<pitti> pochu: ping
<pitti> pochu: please enlighten me about bug 181088 :)
<ubotu> Launchpad bug 181088 in policykit "/proc/$pid/* gets too restrictive permissions for g-s-t tools" [High,Incomplete] https://launchpad.net/bugs/181088
<seb128> pitti: looks like the issue due to your ptrace changes
<pitti> seb128: I got that much, but what issue? works just fine for me
<seb128> pitti: ah, that's this bug
<seb128> pitti: sec
<pitti> I could reproduce the problem with 0.6, but not with 0.7
<pitti> I tested {network,time}-admin
<seb128> pitti: bug #183673
<ubotu> Launchpad bug 183673 in gnome-system-tools "Users-admin unlock not working" [Medium,Confirmed] https://launchpad.net/bugs/183673
<seb128> pitti: the unable to lookup exe for caller seems to be the issue
<pitti> seb128: can you reproduce it?
<seb128> pitti: let me try, I'm still running the build I did for testing the other day
<seb128> is the version you uploaded different?
<pitti> seb128: I just added the patch to work with non-ext3 FSes
<pitti> nothing else
<seb128> pitti: I've an idea it could be due to policykit-gnome which has not been updated, the binaries were in NEW today
<seb128> pitti: maybe those guys still have 0.6
<pitti> aah
<pitti> hm, that sounds like a too weak dependency somewhere
<seb128> yes
<seb128> or a lack of Breaks
<seb128> maybe policykit 0.7 should Breaks on gnome < 0.7
<pitti> yes, good idea
<pochu> pitti, seb128: Right, I have PK-gnome 0.6
<pitti> ah, that's it then; thanks, pochu
<pitti> pochu: I'll add the Breaks: then as a solution to this bug, ok?
<tkamppeter> geser, I have reuploaded flphoto now. I have addressed all issues and now lintian and linda are without output.
<seb128> pochu: I've newed the binaries this afternoon they should be available
<pochu> pitti: sure, as long as g-s-t works again with 0.7 ;)
 * pochu upgrades
<seb128> pochu: we tested g-s-t with 0.7 before uploading it
<pochu> I did with 0.6. :)
<gu_> hi
 * lamont wonders wth his fresh gutsy install decided to say UTC=no in rcS
<geser> tkamppeter: looks OK to me now, but I'd like a second review as I'm a little bit out of practise in reviewing.
<tkamppeter> geser, OK, Thanks. Pitti told that he will look into the package tomorrow. He is core-dev and so he should be experienced.
<geser> tkamppeter: and an archive admin and tomorrow is his archive day
<geser> tkamppeter: so I could upload it and let him review it as part of his archive work :)
<tkamppeter> geser, what do you mean with uploading? The upload into Universe I should do, as I got MOTU and did not do any upload yet, and before applying for core-dev I should do at least one. I do not ask for upload sponsorship here, I do only the required steps for introducing a new package.
<pitti> tkamppeter: right, just upload it now, and I'll grab it from the queue for review tomorrow
<pitti> tkamppeter: I briefly looked at geser's comments and your debdiff, it looked ok
<pitti> I haven't looked at the actual package yet, though
<geser> tkamppeter: sure, usually the reviewer who adds the last needed ACK does the upload
<pitti> tkamppeter: so please go ahead and use your new upload powers :)
<tkamppeter> Done. My first upload into the Ubuntu distribution.
<tkamppeter> I simply removed the "revu" from the dput command line.
<pitti> https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=flphoto
<pitti> and there it is
<pitti> tkamppeter: congratulations!
<pitti> tkamppeter: ah, please remove edge. (unless you are in lp-beta-testers)
<tkamppeter> pitti, I am in lp-beta-testers
<ScottK2> pitti: Everyone can see edge now.
<tkamppeter> pitti, I have updated bug 183243 now, an annoying bugs for users who like to print photos gets fixed.
<ubotu> Launchpad bug 183243 in flphoto "New Package: flPhoto - Photo Manager with Great Printing Capabilities" [Undecided,Fix committed] https://launchpad.net/bugs/183243
<ScottK> tkamppeter: Once it's built and you're confident you have a good package in Hardy, you might want to consider backporting it to Gutsy.
<emgent> hello people
#ubuntu-devel 2008-01-18
<slangasek> anyone here using xen with hardy?
<nemo> sorry to bother the devs, but I have identical symptoms and similar intel card to this bug  https://bugs.launchpad.net/ubuntu/+bug/145747  <-  is anyone here from audio team who might know if this is a known issue?
<ubotu> Launchpad bug 145747 in ubuntu "Sound system locks up" [Undecided,New]
<nemo> oh. and thanks for whoever put gimp 2.4.2 in gutsy proposed - it has solved all my gimp issues
 * Hobbsee curses keyboard.
<LaserJock> nemo: you probably want to add your specs and problem to that bug and subscribe to it
<nemo> aight
<nemo> pretty similar though
<nemo> slightly newer soundcard
 * nemo does so
<nemo> aand done
<nemo> hm dpkg-reconfigure alsa-base  seems to do nothing, but, since clearly I'm just adding noise to this channel, I'm going to slink away again
<nemo> later y'all
<emgent> heya
<emgent> hello ernesto!
<pitti> Good morning
<warp10> good morning
<StevenK> Morning pitti!
<Hobbsee> morning pitti!
 * pitti waves to Australia, hey!
<pitti> and to Italy, too :)
<StevenK> Heh
<warp10> :D
<slangasek> don't wave to Italy, you'll only encourage it
<TheMuso> lol
<keescook> hm, don't all the core 2 duos have a temp sensor somewhere?
<Hobbsee> now, if i was an ubuntu live cd, where would i be...
<keescook> mine is stuck in a failed CDROM.  :P  need to find a paper clip...
 * keescook is off to bed, g'night all
<Hobbsee> oh dear
<Hobbsee> night keescook!
<keescook> cya Hobbsee
<Hobbsee> ah, i'd be sitting on my desk, away from all the ubuntu cds
<TheMuso> lol
<Hobbsee> had forgotten about that one
 * Hobbsee reboots
<dholbach> good morning
<pitti> \sh_away: can you please use requestsync from now on, so that we get a standard request with changelogs, etc.?
 * pitti hugs dholbach
 * dholbach hugs pitti back
 * desrt piles onto the hugfest, grabbing pitti and dholbach 
 * dholbach hugs desrt too :)
 * pitti jumps for joy and hugs desrt
<desrt> you seem a bit excited =)
<dholbach> desrt: "I like hugging, ... no not that much" ;)
<desrt> dholbach; something like that, yes :)
<desrt> dholbach; you may know: i'm coming to visit you in march
<dholbach> oh really?
<dholbach> tell me more :)
<desrt> 9..16
<dholbach> ahhhh, gkt hackfest?
<desrt> there's a "gtk hackfest" at some rented house in berlin
<desrt> yes
<dholbach> nice... summer in berlin is even better, but I'm sure March will be great too :)
<desrt> i have a bit of a catch 22 situation
<desrt> i have a friend living in berlin who i want to surprise with my arrival
<desrt> but i have no idea where she lives :p
<TheMuso> lol
<desrt> i should say i want to write her a letter or something :p
<desrt> although that may be a little obvious... that's how she got my address :/
<TheMuso> desrt: And you didn't think to make a note of the return address? :p
<desrt> she lived in the US at the time
<TheMuso> ah
<desrt> west coast, too
<desrt> so quite a drive to my place (where she randomly showed up last summer)
<desrt> if i drop in on her on a different continent i figure we're more or less even
<Mithrandir> desrt: tell her you'll send her a post card?
<desrt> eh
<desrt> i know a couple of her friends.  i think i'll implicate one of them =)
<Mithrandir> I mean, you travel to UDS-es and such, so sending a post card isn't that unrealistic.
<pitti> doko: tmda was removed in Debian ("RoQA; unmaintained, useless"); should I remove it in hardy as well?
<doko> pitti: sure, never used it. do we document reasons for removals somewhere?
<pitti> doko: yes, http://people.ubuntu.com/~ubuntu-archive/removals.txt
<freeflying> pitti: I found the broken k-menu(errors in translation) still exist in hardy, but it was fixed already, will you upgrade the language-kde-pack?
<pitti> freeflying: I was promised that by Monday we will get a hardy translation tarball, so that I can build langpacks
<freeflying> pitti: will do a SRU for gutsy? thanks
<pitti> freeflying: hm?
<freeflying> pitti: this was broken in gutsy too
<pitti> freeflying: we'll update the gutsy langpacks at start of February again, yes
<pitti> Keybuk: I finally filed that udev bug about wlan0_rename
<geser> good morning
<desrt> pitti; did you notice the esd bug?
 * Mithrandir boggles.
<Mithrandir> to get maemo mapper to dtrt on the n810, you tell it to connect via bluetooth without an address.
<pitti> desrt: yes
<desrt> pitti; think we can get a gutsy upload?
<pitti> desrt: is there a patch attached?
<desrt> yes
<pitti> desrt: hm, please remind me of the #? can't find it in the list
<desrt> https://bugs.launchpad.net/bugs/183411
<ubotu> Launchpad bug 183411 in esound "libesd leaks pipe file descriptors" [Undecided,Fix released]
 * pitti approves the gutsy task
<desrt> it'd be cool if i knew how launchpad worked :p
<pitti> desrt: so, I take that as "please upload the SRU for me"?
<desrt> sru?
<pitti> stable release update
<desrt> if you think it's appropriate, yes
<pitti> https://wiki.ubuntu.com/StableReleaseUpdates
<desrt> seb128; hihi =)
<pitti> desrt: can you please add a "TEST CASE:" to the description? (see the policy in the wiki)
<pitti> hey seb128
<seb128> hey desrt pitti
<pitti> desrt: uploaded, with some changelog tweaking
<desrt> oh
<desrt> that was fast.
<desrt> i was still reading this wiki page :p
<pitti> "Ryan Lortie  did not previously have any assigned bugs in Ubuntu.
<pitti> If this bug was assigned by mistake, you may change the assignment."
<pitti> wow, LP is clever :)
<Treenaks> pitti: Yes.. it's the new name for Skynet 8)
<pitti> "Ryan Lortie did not previously receive enough hugs. If this was a mistake, please rectify that immediately."
 * pitti hugs desrt
 * desrt grins
<desrt> pitti; i'm not sure i can do a TEST CASE
 * seb128 hugs desrt
<desrt> since i've never experienced the bug myself
<desrt> seb128; thx :D
<pitti> desrt: well, you can probably do some lsof | grep stuff
<desrt> ya... but the thing is that i've never personally hit this problem on my gutsy box
<seb128> desrt: try what the duplicate suggests
<desrt> so i don't know exactly what use case it is that causes the problem to explode
<pitti> desrt: alternatively, you can do the testing on the box of your sister where you can reproduce it
<pitti> desrt: we just need to know that the actual .debs from -proposed are good and fix the bug
<desrt> heh
<desrt> "katie... remember what you were doing before when your computer broke?  can you do it some more?"
<desrt> :D
<seb128> desrt: the other bug suggest that mouseover an ogg would be enough
<desrt> lemme check that out =)
<desrt> oh ya
<desrt> that definitely does it
<desrt> hmm
<desrt> only works if the [x] enable esd thing is checked in the sound prefs
<desrt> probably explains why it's never hit me before
<dholbach> good morning thekorn! :)
<thekorn> moin dholbach
<thekorn> just merged py-lp-bugs
<pitti> TheMuso: any idea about verification of bug 155130?
<ubotu> Launchpad bug 155130 in usplash-theme-ubuntustudio "Ubuntu Studio usplash Fails to Prompt for Passphrase for Encrypted LVMs" [Undecided,Fix committed] https://launchpad.net/bugs/155130
<desrt> ok
<desrt> i think i've added a good test case
<desrt> can someone test it? :)
<pitti> desrt: I subscribed sru-verification, they will
<pitti> desrt: thanks
<desrt> yup
<desrt> thanks for the info on what to do =)
<pitti> you're welcome
<snadge> i ask mercifully in here because someone in here might have a clue ;)
<desrt> snadge; try #ubuntu
<snadge> gnome-settings-daemon error on login
 * desrt grins
<Treenaks> snadge: the 'Language unknown' error?
<snadge> its a known issue that has been around for some time, to do with a failure to start gnome-settings-daemon.. i'd have to reboot my pc to see the error again, its a bit intermittant.. i thought i had fixed it already
<snadge> when i last looked into it, it had something to do with the gnome people deciding to start gnome-settings-daemon either a lot earlier, or later in the normal login sequence
<snadge> ok if thats not ringing any bells i'll dig up more info ;)
<snadge> ok im kinda embarassed now.. i had fixed the original problem, but it seems to resurface if your pc is uncleanly shutdown .. (a flatmates parents did the favour of unplugging the cord)
<snadge> i guess i should check launchpad for an existing bug and see if it has been resolved, and provide more info if not
<pitti> LongPoin1yStick: any idea about the status of bug 133944? (stalled SRU)
<ubotu> Launchpad bug 133944 in kdepim "package kitchensync 4:3.5.6-0ubuntu6 failed to install/upgrade: trying to overwrite `/usr/share/apps/ksync/ksyncui.rc', which is also in package ksync" [Undecided,Confirmed] https://launchpad.net/bugs/133944
<snadge> is alt-sysrq-b equivalent to just pulling the power cord?
<snadge> i guess not really.. as i was not able to reproduce the error
<snadge> sweet.. anybody can reproduce this error now, its quite simple.. standard ubuntu gutsy
<snadge> pull the power cord out of the back of your pc, reboot.. and you're greeted with this error "There was an error starting the GNOME Settings Daemon.. blah blah blah" - none of your settings are loaded
<seb128> snadge: now, like it you didn't had the issue before? what did you change?
<snadge> your hosts file must contain an entry for 127.0.0.1 that has your hostname
<tjaalton> is anyone working on merging libnss-db?
<snadge> can someone else try this on a spare gutsy machine for me? (logged into X)
<slangasek> Nafallo: no, you should never point 127.0.0.1 at anything except localhost
<slangasek> er
<slangasek> snadge: no, you should never point 127.0.0.1 at anything except localhost
<slangasek> Nafallo: sorry
<slangasek> snadge: you should have *an* entry pointing to a valid IP for your hostname, but it should not be 127.0.0.1; the norm is 127.0.1.1
<snadge> i see.. it helps to know this ;)
<pitti> hey mvo
<mvo> hey pitti
<pitti> mvo: I am just doing some cleanup of old SRU bugs; there are quite a few update-manager ones, too
<pitti> mvo: I could clean most of them, but some require your input
<mvo> pitti: ok, I'm happy to help, I have a look now, ok?
<pitti> mvo: can you please check the u-m ones on https://bugs.edge.launchpad.net/~ubuntu-sru/+subscribedbugs?batch=100 ?
<pitti> mvo: you should have quite a lot of bug mail, too; most of the bugs were already in -updates and forgotten to be closed, and some tasks were never really handled
 * pitti hugs mvo, thanks
<pitti> mvo: hm, bug 75273 is weird; Mithrandir said that he accepted it to edgy-updates, but there's no apt in edgy-{proposed,updates}
<ubotu> Launchpad bug 75273 in apt "Apt constantly sigsevs on edgy" [High,Fix released] https://launchpad.net/bugs/75273
<tjaalton> StevenK: why did you change libnss-db to use debhelper?
<tjaalton> StevenK: and dpatch
<pitti> mvo: ah, seems it got superseded in bug 85207, and then removed from -proposed because that bug was deemed obsolete in edgy
<ubotu> Launchpad bug 85207 in apt "SRU request for new DPKG::StopOnError config " [Undecided,Fix released] https://launchpad.net/bugs/85207
<Mithrandir> tjaalton: to get rid of yada, I'd imagine.
<tjaalton> Mithrandir: yes, but is that worth the delta
<Nafallo> slangasek: :-)
<Mithrandir> tjaalton: yes.
<tjaalton> Mithrandir: hmm, ok then :)
<Mithrandir> tjaalton: yada should be wiped off the face of this planet.
<mvo> pitti: ook, looking now
<Mithrandir> (or at least kicked out of main)
<pitti> Mithrandir: it's in universe since gutsy
<Mithrandir> \o/
<tjaalton> one more reason to keep the delta :)
<pitti> seb128: still interested in bug 114770? (feisty-proposed)
<ubotu> Launchpad bug 114770 in nautilus-cd-burner "Cannot burn on RW media because n-c-b does not unmount it" [Medium,Fix committed] https://launchpad.net/bugs/114770
<seb128> pitti: not really, interested to discuss why a simple Build-Depends change is waiting there during months until being deprecated though
<pitti> seb128: I asked for testing feedback from the reporters again; if nobody answers, I'll kill it from -proposed next week
<seb128> pitti: isn't bugsquad supposed to do testing and approve the changes?
<pitti> the change was approved, but someone needs to test the actual .debs in -proposed, not a locally built package
<seb128> pitti: I don't really care, but it's annoying to spend work on SRU to have those ignored
<seb128> pitti: not it's not against you, you did reply pretty quickly ;-)
 * seb128 hugs pitti
<seb128> pitti: well, I though bugsquad was supposed to do that as written
<pitti> seb128: my concern isn't that the patch is obvious and fixes the bug, but that the change had inadvertent side effects (thus the rigorous testing)
<pitti> seb128: right; let's see if someone answers
<seb128> pitti: I don't expect lot of people are still using feisty and we got no new duplicate, so deprecate it if you want, I don't think it's worth the efforts now, we have better things to get working
<tjaalton> we have ~300 feistys :)
<pitti> soren: any chance you could test the bind9 .debs in the other -proposed?
<soren> pitti: Um... Yes, I suppose I can squeeze that in today.
<pitti> soren: thanks
<soren> That also gives me an excuse to get the rest of my vm's moved over to kvm. :)
<mvo> pitti: #75273 -> its still worthwhile to have this fix in edgy-updates, the fix is trivial
<pitti> asac: any idea how bug 138794 could creep back to hardy?
<ubotu> Launchpad bug 138794 in network-manager "Error getting killswitch power arguments: org.freedesktop.DBus.Error.InvalidArgs - Argument 0 is specified to be of type "uint32", but is actually of type "int32"" [Undecided,Confirmed] https://launchpad.net/bugs/138794
<Mithrandir> hm, it would be very useful if the /+archive url included a link to the build records for that upload.
<pitti> Riddell: ping about bug 153500 - the gutsy-proposed patch needs to be uploaded to hardy
<ubotu> Launchpad bug 153500 in kdelibs "Kopete crashes on startup" [High,Fix committed] https://launchpad.net/bugs/153500
<pitti> seb128: is bug 152638 fixed in hardy?
<ubotu> Launchpad bug 152638 in gedit "Permissions and owner/group changed when editing using gedit" [Medium,Fix committed] https://launchpad.net/bugs/152638
<asac> pitti: not sure ... did hal bounce back to use guint32?
<pitti> asac: it didn't change drastically for months (no new upstream version and no patches)
<seb128> pitti: yes
<pitti> seb128: merci, bug closed
<asac> seb128: can you reproduce bug 138794 (i remember that you could in the past)?
<ubotu> Launchpad bug 138794 in network-manager "Error getting killswitch power arguments: org.freedesktop.DBus.Error.InvalidArgs - Argument 0 is specified to be of type "uint32", but is actually of type "int32"" [Undecided,Confirmed] https://launchpad.net/bugs/138794
<soren> pitti: I've filed a MIR for kvm.. Do I need to do anything to get it looked at?
<seb128> pitti: you are welcome
<seb128> pitti: danke
<pitti> soren: if ubuntu-mir is sub'ed, that's enough
<soren> pitti: Cool.
<seb128> asac: no such warning no
<asac> hmm ... any idea if launchpad removes files for superseded version? e.g. trying: https://edge.launchpad.net/ubuntu/+source/hal/0.5.10-5~ubuntu3
<asac> is that a feature or a bug?
<asac> "ERROR 404: Not Found"
<soren> It's a bug which will be fixed with the next lp release, afaik.
<asac> when will that be? its essential for some kind of regression hunts :)
<pitti> asac: the files are still there
<pitti> asac: but the URL doesn't work
<tjaalton> oh ffs, libnss-db doesn't clean properly
<pitti> asac: hal is in bzr, too, you can get it from there if all else fails
<soren> asac: You can find the files on staging, afair.
<asac> ok ... is there any way that i could guess the proper urls?
<soren> asac: http://staging.launchpad.net should expose the correct URL's.
<soren> asac: Allegedly. It was discussed on #launchpad yesterday (or the day before).
<pitti> asac: oh, seems they are really gone now; hmm
<asac> lets hope that they are not physically gone
<soren> asac: I'm quite sure librarian still has them. You can ask in #launchpad for the right URL.
 * pitti purges firefox 2; yay
<soren> I'm looking at the Jeos image. It seems that the installer will offer to let you configure lvm regardless of whether or not lvm is actually available on the cd to be installed on the system. Should lvm perhaps be moved to minimal or required?
<Mithrandir> is the processing of PPA uploads down or stopped or something?
<Mithrandir> ah, no, there it was
<cjwatson> soren: lvm2 needs to be in the jeos seed, I think
<cjwatson> I actually thought I'd added it already
<cjwatson> soren: some installer features will attempt to dynamically install packages on the target system in order to support themselves, using apt-install
<cjwatson> you need to arrange for the packages in question to be seeded, just like they're in the ship seed
<pitti> mvo: ok, please go ahead and upload apt/edgy
<soren> cjwatson: I realise it'll install them if it's configured.  I just figured that since the installer will unconditionally offer to configure it, it should always be installed (and hence be in required or minimal).
<mvo> pitti: isn't this magic copy mechanism working on edgy? to copy it from -proposed to -updates?
<soren> Er... Always be *available* for isntallation, of course.
<pitti> mvo: check rmadison; as I said, there is *only* edgy release, no -proposed, -updates, -security
<pitti> mvo: TBH I don't know when or why it disappeared from -updates
<mvo> pitti: right, sorry I missed that earlier. that is indeed strange, as I have a accepted mail here even
<soren> cjwatson: Either that or the installer should be taught to not ask such questions if lvm is not available for installation?
<cjwatson> soren: being in required or minimal would have it always installed, not merely always available, which would be inappropriate
<soren> cjwatson: Ah, point.
<soren> cjwatson: Can you think of anything else the installer will offer to configure, but will not necessarily be available for installation?
<cjwatson> I think it would probably be impossible (with current infrastructure) to avoid offering the option at all if lvm2 isn't available; the only thing we can do is to try to install it and see if it failed, but we shouldn't try to install it until the user asks for it
<cjwatson> but we should certainly have better error handling in the event that it is not available
<cjwatson> partman-lvm could do that
<cjwatson> and lvmcfg
<cjwatson> yes, lots. grep for apt-install
<cjwatson> everything under "Filesystems" and "For language support in the installer" in ship, though that is not exclusive
<soren> I don't have all of the installer code checked out..
<cjwatson> Mac systems will apt-install mouseemu
<cjwatson> various others
<soren> That sounds like a good start.
<cjwatson> you probably won't care about much more than that
<soren> cjwatson: Great. Thanks.
<asac> bryce: when will we get 1.4.0.90 ?
<ogra> tjaalton, is tehre a way to set keymaps through sysfs in Xorg or so ? or am i forced to have hal available for that ?
<mvo> pitti_: I updated #172609 - I need approval for 0.81.2 first, the version in gutsy-proposed does not fix the bug unfortunately
<pitti_> mvo: looks ok
<mvo> great, thanks pitti_
<mvo> pitti_: if you haven't accepted update-manager 0.81.2 yet, please wait a sec
<mvo> pitti: if you haven't accepted update-manager 0.81.2 yet, please wait a sec
<pitti_> mvo: I didn't
<pitti_> mvo: (experimenting with an irssi proxy, thus two nicks ATM)
<mvo> pitti_: ok, I think there is another tweak needed, sorry - its a bit difficult to test without a ia64 machine :)
<tjaalton> asac_: we have that
<tjaalton> ogra: hmm, what are you trying to do?
<tjaalton> asac_: actually it's newer than that, from the 1.4-branch
<ogra> tjaalton, i somehow need to get the new X going in ltsp :) we use a script generated xorg.conf there
<asac_> tjaalton: hmm ... since when?
<ogra> i would like to switch the conf to be optional (to many special cases to not have something you can override configs with) and default to a configless setup
<asac_> tjaalton: ok there is a bunch of upgrades coming (incl. xserver) ... lets see after lunch
<mvo> pitti_: could you please reject 0.81.2 from gutsy-proposed ? I upload a new one now and I added instructions how to reproduce the bug and the fix on regular hardware
<tjaalton> asac_: we've been tracking the stable branch with debian for some time now. at least 2:1.4.1~git20071212-1ubuntu1 includes everything in 1.4.0.90
<tjaalton> ogra: oh right :)
<pitti_> mvo: there's nothign in gutsy-proposed
<tjaalton> ogra: it uses hal (if you enable it), so the same rules apply
<ogra> tjaalton, so i'd like a hal-less way of setting keymap and mouse options :)
<ogra> hal = to big for thin clients
<tjaalton> ogra: then you either patch the server or use a xorg.conf
<ogra> patch ? in what way ?
<ogra> i would expect hal to hook in to sysfs or so
<tjaalton> ogra: let me check
<soren> pitti: How does Feb 4th sounds as a (soft) deadline for submitting new packages? That leaves 10 days for NEW processing before FF.
<pitti> soren: sounds ok (although the current policy already accounts for processing the backlog)
<soren> I see.
<mvo> pitti_: ok, now there is 0.81.2 in gutsy-proposed, this time valid
<tjaalton> ogra: the devices don't have any options set by default, so I don't see how it could work without hal or xorg.conf
<Kmos> ogra: tuxtype needs sdlpango promoted to main.. =)
<ogra> Kmos, yup, you told me before :)
<ogra> tjaalton, ok, then i will keep the current structure
<Kmos> ogra: can you ask pitti to do it? i can't.. prevented from participate in ubuntu development
<ogra> yes, i saw that :/
<ogra> Kami will talk to pitti about it before release, dont worry
<Kmos> ok =) thx
<ogra> (i have some more pressing work atm, but e sure debs will be fixed by release )
<ogra> s/e/be/
<Kmos> :-)
<dholbach> MOTU Q&A session in 8 minutes in #ubuntu-classroom
<ln-> what exactly did the latest Dapper updates break?
<Hobbsee> ln-: what makes you think that the dapper updates are broken?
<ln-> trying to run the minimal sample of self-compiled wxGTK-2.8.6 gives an error like this: http://pastebin.ca/859857
<ln-> that did not happen earlier.
<Hobbsee> does that happen with the normal version of that?
<Hobbsee> ah, perhaps https://lists.ubuntu.com/archives/dapper-changes/2008-January/012606.html
<ln-> does the "normal", packaged version ship with the samples?
<Hobbsee> i have no idea
<ln-> apparently not.
 * Hobbsee does not run dapper, sorry, and ran kde around that time.
<snadge> i think i've got a theory about the gnome-settings-daemon startup error after a power cut
<snadge> its possibly because im using reiserfs
<snadge> which from what i've read.. is designed to corrupt data in a power loss situation by default
<ln-> maybe this is yet another reason to abandon Ubuntu as soon as possible and switch to CentOS on our computers.
<seb128> ln-: do you think that's an useful comment to do there?
<seb128> ln-: you will never have a distro which never has any issue but you can use whatever you want, that's not really revelant on this chan though
<Hobbsee> ln-: methinks centOS also took that update, so it would be worth checking to see if your self-compiled wxGTK-2.8.6 gives the error there too.
<seb128> hey Hobbsee ;-)
<_MMA_> seb128: Is there anything more I should add to bug 183199?
<ubotu> Launchpad bug 183199 in gnome-control-center "System sounds aren't being played in Hardy." [Undecided,New] https://launchpad.net/bugs/183199
<seb128> _MMA_: no idea
<seb128> _MMA_: I've enough work to be busy 30 hours a day basically at the moment so I didn't look at that yet
<_MMA_> Sure. np
<seb128> the login sounds work correctly on my hardy
<seb128> could be a pulseaudio issue
<ogra> here too (even in ltsp)
<seb128> I need to look at it
<_MMA_> Really odd as the same day I filed I did a Ubuntu/Ubuntu Studio install from the daily.
<Hobbsee> seb128: mine don't, but on the live cd, they'll play twice, around a minute in
<_MMA_> (doing another now)
<_MMA_> Yeah. Im using the Alt. disk.
<tkamppeter> piit, hi
<tkamppeter> pitti, hi
<tkamppeter> Anyone got build failures on IA64 and/or HPPA today?
<tkamppeter> This architectures are segfaulting on processing of .po files.
<tkamppeter> All other archs are OK.
<seb128> _MMA_: I've esound installed on this box though
<seb128> _MMA_: let me try without it
<tjaalton> ln-: those patches are from upstream and probably already applied on RHEL/Centos :)
<seb128> _MMA_: sounds work fine without using esound too
<_MMA_> seb128: Im downloading todays daily. Ill check it out.
<_MMA_> Though the install will probably fail with the lang packs being broken.
<seb128> _MMA_: do you have anything on the command line when trying to play a sound in the GNOME capplet?
<_MMA_> Ill have to wait to test. If the disk fails to install then Ill do a CLI install then grab ubuntu-desktop.
<ln-> tjaalton: well, that's possible.
<_MMA_> seb128: "GNOME capplet" Did you mean "applet" ie: the tab where you can preview the sounds?
<tjaalton> ln-: a workaround; put 'Option "MIT-SHM" "no"' in the Extensions -section
<tjaalton> of xorg.conff
<tjaalton> -f
<seb128> _MMA_: gnome-sound-properties, that's a capplet
<tjaalton> ln-:  or downgrade to the previous version
<Hobbsee> infinity: that was uploaded months ago.  i'm unsure why it's decided to attempt to build now
<Hobbsee> ln-: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/183969
<ubotu> Launchpad bug 183969 in xorg-server "xserver-xorg-core update breaks java apps" [Critical,Confirmed]
<Hobbsee> what is it with xorg's lack of testing or something, which means that security fixes break apps?
 * Hobbsee uploads kdepim
<ln-> Hobbsee, tjaalton: at least i'm happy to notice i'm not the only one suffering from the bug, and that it has been marked critical.
<cyberix> https://bugs.launchpad.net/ubuntu/+bug/184041
<ubotu> Launchpad bug 184041 in ubuntu "failure to interact with bug reporters" [Undecided,New]
<Hobbsee> cyberix: this is bugs marked as incomplete?
<seb128> jamiemcc_: hey
<seb128> jamiemcc_: is there a way to know what tracker is doing exactly? tracker-status say it's indexing but I would like to know what and how many things it still has on its list etc
<seb128> jamiemcc_: ups
<seb128> no, not ups
<cyberix> Hobbsee: Is there a status history?
<LucidFox> Could any archive admins please look at bug #184025?
<ubotu> Launchpad bug 184025 in mpeg4ip "Please move mpeg4ip to multiverse" [Undecided,New] https://launchpad.net/bugs/184025
<Hobbsee> cyberix: yeah
<cyberix> Hobbsee: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/85455/+activity
<ubotu> Launchpad bug 85455 in linux-restricted-modules-2.6.20 "D-Link DWA-547 wireless card doesn't work" [Wishlist,Confirmed]
<Hobbsee> cyberix: no idea who the guy is who triaged your bug incorrectly there.
<Hobbsee> Keybuk: has already had a go at him
<cyberix> Does everyone have rights to reject bug reports?
<LucidFox> cyberix> From a technical POV, anyone can set a bug to Invalid, and bug control members can set a bug to Won't Fix
<Keybuk> seb128: I tend to restart it with the debugging command-line flags and watch what it's doing
<seb128> Keybuk: right, would be nice if tracker-status would be verbose about that though
<Keybuk> LucidFox: I think it's anyone in ubuntu-dev, rather than anyone
<Hobbsee> Keybuk: to reject?  no
<Hobbsee> Keybuk: anyone can set a bug as invalid
<Hobbsee> in any project
<Keybuk> oh, ok :)
<Keybuk> shows how much I know
<Hobbsee> Keybuk: btw, you have another core dev app :)
<Hobbsee> Keybuk: or how long you've been in power for, either wya.
 * Hobbsee crash-tackle-hugs pitti
 * Hobbsee crash-tackle-hugs pitti into the middle of next week
<Hobbsee> damn enter key.
<geser> Hobbsee: now you also have problems with the enter key?
<Hobbsee> geser: yeah, but they're pebkac
<pitti> oh, what a nice welcome :) /me hugs Hobbsee back
<ScottK> pitti: About Bug 183570 - I had edited the bug, but forgot to leave a comment.  Sorry about that.  I'd appreciate it if you would have another go at it.
<ubotu> Launchpad bug 183570 in clamtk "Request sync clamtk 3.06-1 (Universe) from Debian Unstable (Main)" [Wishlist,Confirmed] https://launchpad.net/bugs/183570
<Hobbsee> pitti: i uploaded the hardy section of kdepim, btw
<pitti> ScottK: sure
<ScottK> Thanks
<pitti> Hobbsee: awesome, thanks
<ScottK> pitti: Also, on Bug 183661 - What sort of testing do you want?  The bug was an FTBFS bug and they both built?
<ubotu> Launchpad bug 183661 in libmail-box-perl "FTBFS in Gutsy/Feisty" [Medium,Fix committed] https://launchpad.net/bugs/183661
<pitti> ScottK: I didn't do it because you indicated some doubts whether it would work
<ScottK> Ah.
<pitti> ScottK: a confirmation that it still works, and isn't worse than the current gutsy version
<pitti> ScottK: (or feisty)
<ScottK> I tested clamtk.  It works.
<ScottK> OK.
<ScottK> pitti: For the libmail-box-perl one, since it was FTBFS before, isn't a package automatically better than none?
<LucidFox> pitti, I assume it was you who approved mpeg4ip? :)
<pitti> ScottK: it's not none, it's the last version that built
<ScottK> pitti: OK.  Got it.  Thanks.
<pitti> libmail-box-perl |    2.065-1 | gutsy/universe | all
<pitti> libmail-box-perl |    2.070-1 | gutsy/universe | source
<mjg59> Argh my liferea db has become corrupted.
<pitti> ScottK: IOW, gutsy has the feisty version
<pitti> LucidFox: right; was there still a problem with it?
<ScottK> Actually it's Edgy, but OK
<LucidFox> bug #184025
<ubotu> Launchpad bug 184025 in mpeg4ip "Please move mpeg4ip to multiverse" [Undecided,New] https://launchpad.net/bugs/184025
<ScottK> I'll see if I can figure a simple test.  The gutsy one installs fine.
<pitti> ScottK: chewmail is an rdependency and looks like it's reasonably easy to set up
<ScottK> pitti: Thanks.
<pitti> clamtk synced
<ScottK> pitti: Thanks.
<seb128> pitti: how is named the wiki page about MIR procedure?
<seb128> pitti: looking for MainInclusionReport on the wiki list a zillions of pages
<pitti> seb128: https://wiki.ubuntu.com/MainInclusionProcess
<seb128> thanks
<ogra> shouldnt the old queue page link it ?
<pitti> it has
<ogra> right
<pitti> UbuntuDevelopment should have a link as well
<ScottK> pitti: Speaking of which, are you planning on looking at MIRs soon?
<pitti> *sigh* I guess I have to; maybe doko can help me a bit, we got tons of requests this week
<Hobbsee> pitti: you can do the new queue instead, if you like
<pitti> I already reduced it from ~ 100 to ~ 10 today
<pitti> tjaalton: hm, your dpaper-proposed xorg-server upload doesn't work
<doko> pitti: sure, next week (had still vacation days this week)
<pitti> tjaalton: 10.8 is already in dapper-security, can you please bump the version and reupload/
<ScottK> pitti: I only ask because I expect the amavisd-new one will require some discussion and I'm anxious to get it started, but I understand there's tons of other stuff to do too.
<tjaalton> pitti: ok
<pitti> tjaalton: you  probably need to rebase your patch against the -security version
 * pitti updates the bug
<tjaalton> pitti: actually, since the security fix is broken I'll just wait for the right fix
<pitti> ugh, is it? in the sense of not plugging the hole, or breaking stuff?
<tjaalton> breaking stuff
<pitti> eww
<pitti> tjaalton: bug?
<pitti> if that's serious, we need to immediately disable the version and revert it
<tjaalton> https://launchpad.net/bugs/183969
<ubotu> Launchpad bug 183969 in xorg-server "xserver-xorg-core update breaks java apps" [Critical,Confirmed]
<tjaalton> doesn't affect amd64
 * pitti drops everything else
<tjaalton> pitti: sorry for not raising this up earlier :/
<tjaalton> upstream has been notified
<tjaalton> the MIT-SHM patch is the one that is buggy
 * ScottK suddenly decided not rebooting his dapper desktop for a while is a good idea.
<tjaalton> since disabling the extension is a workaround
<pitti> it affects all releases?
<tjaalton> seems like it
<pitti> tjaalton, bryce: can either of you revert the change in -security and upload a higher version to -proposed?
<tjaalton> bryce is asleep, I can do it
<tjaalton> dapper first?
<seb128> pitti: is bug #184050 what you need or do you want extra informations for those bugs or a wikipage or something?
<ubotu> Launchpad bug 184050 in seahorse "seahorse MIR request" [Undecided,New] https://launchpad.net/bugs/184050
<pitti> tjaalton: all the binaries? or is a subset enough?
<pitti> seb128: seahorse doesn't need one, it's ok
<tjaalton> pitti: well, -core is the one most have installed, and reverting just that seems to work
<tjaalton> s/most/everyone/
<seb128> pitti: we said we need bugs for things which have been promoted yesterday no?
<pitti> seb128: right, bugs, but not necessarily wiki pages
<seb128> pitti: ah ok, it was not clear, so bugs similar to this one are alright? just asking before continuing with the other ones
<pitti> tjaalton: we disable the faulty version on the mirrors now, so the order doesn't matter too much
<tjaalton> pitti: ok
<jdong> forum complaints are starting to surface regarding the X breakage too...
<pitti> tjaalton: I think it would suffice to take the -updates versions, bump their version, and reupload
<ln-> 15:16 < ln-> what exactly did the latest Dapper updates break?
<ln-> 15:16 < Hobbsee> ln-: what makes you think that the dapper updates are broken?
<Hobbsee> ?
<ln-> Hobbsee: nothing, just a kind of review of the timeline of this situation.
<jdong> timezones help with timelines ;-)
<ln-> GMT+2
 * Hobbsee clearly should read userland more often
<LucidFox> pitti, so what about moving mpeg4ip to multiverse? Sorry if I sound impatient.
<LucidFox> I'm just anticipating libmp4v2/faac builds unbroken at long last
<pitti> LucidFox: oh, it should have gone there? license seemed free to me
<LucidFox> it build-depends on multiverse
<pitti> LucidFox: done
<LucidFox> thanks!
<LucidFox> jdong> Rejoice :)
<jdong> pitti: yeah it's patent encumbered and all that fun stuff ;-)
<jdong> LucidFox: whoo!
<JungleDave> Did the recent xserver update get pulled? I'm getting a 403 from http://security.ubuntu.com/ubuntu/pool/main/x/xorg-server/xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8.1_i386.deb
<Pici> JungleDave: see: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/183969
<ubotu> Launchpad bug 183969 in xorg-server "xserver-xorg-core update breaks java apps" [Critical,In progress]
<Pici> "The faulty xserver-xorg-core packages have been disabled on security.u.c. We are in the process of reverting the change and providing updated packages."
<JungleDave> Thanks.. it also broke my app (which happens to be C++)
* cjwatson changed the topic of #ubuntu-devel to: Archive: OPEN | Hardy Alpha 3 released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | xorg-server security update blocked, fix in progress
<geser> pitti: please give-back: haskell-hgl haskell-edison haskell-fgl. thanks.
<dholbach> is the wiki flaky to somebody else too?
<soren> dholbach: Sometimes.
<_MMA_> dholbach: Yeah. I cant connect to wiki.ubuntu here.
<\sh> dholbach, yep
<dholbach> _MMA_: same here
<nxvl_work> why is the xorg update blocked that way? it crashes my whole update process
<nxvl_work> it's kind of annoying for non experienced users
<ScottK> nxvl_work: There really isn't another way.
<cjwatson> nxvl_work: it should be resolved soon
<cjwatson> nxvl_work: it's better than inexperienced users getting a broken update and not being able to start some applications
<nxvl_work> mmm
<nxvl_work> it's better not to upload broken SRU, but once done, it's done
<cjwatson> (it wasn't an SRU)
<cjwatson> yes, the broken update came from upstream and it also affects other distributions; at least Debian had the same regression
<geser> pitti: please give-back: haskell-openal. thanks.
<LjL> cheers on blocking the upgrade (and, i guess it takes what it takes to block it) :)
<pitti> geser: all kicked
<lool> doko: Recall the /usr/share/doc/* symlinks you mentionned as a good way to save space?
<pitti> lool: what about them?
<lool> doko: I got a RC against Gtk+ because it's not a strict dep; I don't want a strict dep because of arch: all / arch: any regularly out of sync and to ease upgrade; I've asked for relaxing the rule, see Debian #461440
<ubotu> Debian bug 461440 in libgtk2.0-0 "libgtk2.0-0: Must not use a symlink for /usr/share/doc/libgtk2.0-0" [Serious,Open] http://bugs.debian.org/461440
<lool> But this will be rejected because we need the proper copyright file version
<pitti> lool: oh, please don't use symlinks for entire directories
<lool> pitti: Even for files it wouldn't be enough
<lool> pitti: Why not?
<pitti> lool: please only symlink files (changelog.gz -> ../otherpackage/changelog.gz)
<doko> lool: if ensure that the copyright didn't change, I can't see why it's RC
<doko> s/if/if you/
<lool> doko: This requires a strict versionning
<pitti> lool: because dpkg has a *very* weird (but justifiable) way of hanlding symlinks to directories
<lool> doko: Anyway, giving some thoughts to it, I think it would be more efficient to compute these symlinks (or hardlinks?) before the creation of the image
<lool> pitti: You mean changing from a dir to symlink or vice versa
<pitti> lool: our cdbs in Ubuntu now symlinks identical doc/ files and does dependency checks
<lool> pitti: But that didn't happen
<pitti> lool: right
<\sh> doko, good to so you ... would you like to take a look at the gdc-4.1 merge? mom failes to merge it correctly and I don't have really a clue about the package..
<lool> pitti: The dir symlink was there since forever
<pitti> lool: just mentioning it, this approach shouldn't proliferate
<lool> pitti: I just unversionned the dep
<pitti> lool: oh, I see
<lool> pitti: CDBS does strict dependency checks or simple dependency presence check?
<cjwatson> lool: at squashfs creation time? remember that the squashfs contents are copied to the hard disk and that this will therefore infect installed systems; think carefully before you say that you want /usr/share/doc on systems installed from live CD to be constructed differently from those installed in other ways ...
<doko> \sh: please talk to arthur; IIRC the package should simply be synced
<pitti> lool: no version comparisons, just dependency
<lool> pitti: The bug here is that the dep needs to be at least >=source:version
<pitti> lool: right; I think I misunderstood the original issue that you had
<\sh> doko, ok :)
<lool> cjwatson: Yeah, I know, but I persist: if this optimization is useful for live CDs but not wanted in e.g. Debian for policy compliance, I think we should make it only for the live CD use, perhaps undoing it on install -- I don't claim I have a working implementation for this
<\sh> doko, btw..do you have arthurs nick?
<doko> arthur
<lool> cjwatson: it just sounds sane to think into doing the proposed optimization before the live CD build if it's not acceptable in binary packages
<\sh> doko, ok..that was easy ;)
<pitti> mvo_: can you please reupload apt/edgy with adding .1 to the version? soyuz hates me
<pitti> mvo_: i. e. it doesn't have apt_0.6.45ubuntu14.1 in the archive any more, but when I try to accept your upload it says that it's already accepted in edgy
<tkamppeter> hi pitti
<pitti> hi tkamppeter
<lool> cjwatson: Or perhaps we could sort file by checksums and help mksquashfs store them in the same place in the image when they do?
<lool> I don't know how squashfs works currently, so I'll shut up; just wanted doko and interested people know that changelogs symlinks are not welcome without a very strict dep
<tkamppeter> pitti, flphoto built correctly on most archs, only on IA64 and HPPA it FTBFS, with the processing of the I18n .po files segfaulting on one file, looks like a toolchain problem on the two build systems.
<cjwatson> perhaps not entirely by checksums (performance), but that does sound more viable than actually changing the resulting squashfs filesystem
<mvo_> pitti: meh, ok. I name it apt_0.6.45ubuntu14.2 - ok?
<pitti> mvo_: yes
<pitti> tkamppeter: don't worry about it too much for now
<_MMA_> seb128: Ok. Fresh alpha3 install on my desktop and laptop. I get no sound and no output in the terminal when I try to play the sounds on the "Sounds" tab of gnome-sound-properties. Nothing on login/out either. I do however get sound when I test on the "Devices" tab.
<_MMA_> I'll update and see what happens.
<cjwatson> oh, was *that* why my system was running like a drain when using vmware?
<cjwatson> tracker was indexing my vmware images ...
<_MMA_> hehe
<cjwatson> I mention this in case anyone else was trying to figure it out. :-)
<lool> cjwatson: (squashfs: Don't we have most checksums hints already?)
<mvo_> jdong: what do you think about a backport from the current hardy notification-daemon to gutsy? this fixes a problem with the notification color under dark schemes
<cjwatson> lool: it'll probably spot it so long as they're sufficiently close together in the image
<LaserJock> cjwatson: ahhh, that might explain why tracker was so obnoxious to me yesterday. I just put in a couple of vmware images
<lool> cjwatson: Sounds unlikely for package libfoo and foo if it's sorted by alphabetical order though
<cjwatson> lool: I don't know enough of the details, unfortunately
<mvo_> pitti: 0.6.45ubuntu14.2 should be waiting now
<LaserJock> are unseeded Main packages semi-automatically demoted?
<cjwatson> LaserJock: yes
<LaserJock> so no bug report required
<cjwatson> component-mismatches tracks that
<cjwatson> indeed not
<LaserJock> great
<\sh> doko, gpc-4.1 I think you applied all patches from ubuntu to your debian packages in _2.1-4.1.2-17, as far I can compare the changelog it looks like
<doko> \sh: gpc should just be synced
<pitti> mvo_: ok, will process; thanks! *hug*
<\sh> doko, thx...I'm testbuilding it right now...and request one
<\sh> hmm..upgrade dapper->hardy: openoffice.org-l10n-en-gb: Collision: openoffice.org-core (>= 2.0.3) but 1:2.3.1-3ubuntu2 should be installed
<\sh> the same for -l10-en-za
<emgent> hello there
<emgent> W: Errore nello scaricamento di http://security.ubuntu.com/ubuntu/pool/main/x/xorg-server/xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8.1_i386.deb
<emgent>   403 Forbidden
<emgent> please fix :P
<cjwatson> emgent: please see the topic
<emgent> ok thanks ehehe
<jamiemcc_> cjwatson: I will add *.vmdk *.vmd *.vmsd *.vmss to the default ignore file list in next version of tracker
<seb128> jamiemcc_: hey
<jamiemcc_> hi seb128
<cjwatson> jamiemcc_: thanks! I was actually just looking at the tracker source to try to find a blacklist of extensions, but I guess I was looking in the wrong place
<seb128> jamiemcc_: is there a way to know what tracker is doing exactly? tracker-status has no details on what is being indexed, how many items are still to index, etc
<jamiemcc_> cjwatson: you can blacklist in tracker-preferences
<jamiemcc_> seb128: the applet should tell you that
<cjwatson> jamiemcc_: vmem too, please
<seb128> jamiemcc_: the applet tooltip is not really useful ;-)
<jamiemcc_> cjwatson: yeah will do - I use vmware here
<cjwatson> I did indeed blacklist in the preferences
<cjwatson> (once I realised the problem)
<jamiemcc_> seb128: that will be fixed soon
<seb128> jamiemcc_: when right click, it's written indexing in progress and the files and email progress bar at 100%
<seb128> on left click I mean rather
<cjwatson> jamiemcc_: I think *.iso would be a good plan too
<jamiemcc_> cjwatson: yeah pls file a bug with full list if you think on any more - atm we balcklist mainly dev files like autofoo
<cjwatson> ok
<seb128> jamiemcc_: I'll open bugs I think so the issues are listed on launchpad
<jamiemcc_> seb128: ok thx
<_MMA_> cjwatson: Really? *.iso? Ive searched for 'em before. Seems handy for most to be able to search.
<seb128> jamiemcc_: another annoying one is the index merge bubbles, I got a lot of those
<jamiemcc_> seb128: yeah the plan is to autopause trackerd whenever the user moves mouse or presses a key by getting the applet to monitor x events - that way we can do away with thos messages
<cjwatson> _MMA_: hmm, I guess I want their names indexed but not their contents
<_MMA_> cjwatson: Yeah. Agreed.
<jamiemcc_> cjwatson: the problem is xdgmime sometimes mistakes binary blobs for video files
<seb128> jamiemcc_: still, is there any need to merge indexes every 15 seconds or to notify users about those in a bubble?
<jamiemcc_> seb128: no - it should only ever notify after initial index only
<jamiemcc_> will make sure thats the case
<seb128> thanks
<jamiemcc_> cjwatson: I will include extra logic to make sure xdgmime is not used on certain file patterns
<cjwatson> jamiemcc_: thanks
 * cjwatson wonders how you tell gtk to switch input methods
<seb128> cjwatson: right click in the text widget you are using and select the option there?
<seb128> cjwatson: or you mean the default one?
<seb128> cjwatson: gtkrc is likely the easiest to change the default
<cjwatson> seb128: I mean the default, programmatically, without restarting gtk
<cjwatson> seb128: context is that I want ubiquity and oem-config to be able to switch input methods when the language changes
<seb128> cjwatson: use gtk_rc_parse maybe?
<_MMA_> seb128: Ok. Clean alpha3 install then dist-upgraded. Same results. No sounds on login/out. This is what I saw back at gutsy's development. A Feisty->Gutsy install worked but a clean install doesnt.
<seb128> _MMA_: no clue about the issue, it works for me, I'll try to do a new install and look at it later
<seb128> _MMA_: maybe some pulseaudio package not installed by default or something
<_MMA_> Im gonna go from Feisty->Gutsy now and see if i can wrangle some help from crimsun later.
<cjwatson> seb128: argh worst interface ever. if I have to :)
<BenderUnit22> ls
<BenderUnit22> *blush* Sry.
<jdong> mvo: if you're confident with the backport, by all means feel free :) thanks
<mvo> jdong: what could possible go wrong :P ?
<mvo> jdong: thanks, I check out the debdiff again (I think its good, but I did my changes some days ago)
<pochu> seb128: bug 176892 and bug 177027 are metacity regressions which are affecting tracker-applet in a usability POV. Would be nice to get them fixed (and I think they are the same bug but someone undupped them)
<ubotu> Launchpad bug 176892 in tracker "Search box out of focus when tray icon clicked" [Low,Invalid] https://launchpad.net/bugs/176892
<ubotu> Launchpad bug 177027 in tracker "notification icon window has no obvious way to close " [Low,Invalid] https://launchpad.net/bugs/177027
<pochu> Hmm, I'll dup them again explaining why they are dups :)
<pochu> The good one is 176892, and 177027 is caused by it.
<seb128> pochu: would be nice to send the bug upstream on bugzilla if you have an account there ;-)
<pochu> seb128: to metacity right? I'm not sure I reassigned it well because nm-applet behaves correctly. But downgrading metacity fixed it...
<seb128> pochu: right
<pochu> Alright I'll forward it.
<Mez> was the xorg break really bad?
<pochu> Have to go. See you all
<Mez> (the published and pulled package?)
<Mez> or dare I not restart my PC
<pochu> Mez: downgrade it.
<Mez> pochu, wont get to till Monday
<ln-> wtf: http://launchpadlibrarian.net/11430070/Schermata%20aMue2.png
<ln-> not a screenshot of the error itself, but a screenshot of the error message pasted into launchpad. and this file is an attachment of that very bug report.
<ln-> is there something i don't understand?
<Pici> hah
<slangasek> gpocentek: are you planning to take care of the gnumeric 1.8.0 merge?  goffice 0.6 is already in hardy, and apparently gnumeric 1.8 is the version that goes with it
<[Gutsy]TuTUXG> after latest update i cannot login to gnome
<[Gutsy]TuTUXG> is this known?
<steveire> http://security.ubuntu.com/ubuntu/pool/main/x/xorg-server/xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8.1_i386.deb <<< This is forbidden for some reason (in todays update)
<mjg59> steveire: Yes, it's broken
<mjg59> Access will be provided again once it's fixed
<steveire> mjg59: Cool. Thanks
<gpocentek> slangasek: I'll take care of it tomorrow
<slangasek> gpocentek: ok, cheers :)
<jpatrick> !xbug > steveire
<ScottK> infinity: Thanks for fixing the released sbuild too.
<cvasilak> !xbug > cvasilak
<infinity> ScottK: NP.  I was sick of seeing the traffic on the buildd list, and fixing the bug turned out to be about as much effort as unsubscribing from it. ;)
<ScottK> Heh.
<desrt> W: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/x/xorg-server/xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8.1_i386.deb 403 Forbidden
<desrt> uh oh
<seb128> desrt: there was an issue in the update it has been blocked
<desrt> nod.
<desrt> that's why i say "uh oh" :p
<seb128> ah ;-)
<desrt> there needs to be an http status code for "for your own good" :p
<seb128> yeah
<desrt> or update manager needs to know what forbidden means
<seb128> every time they do that there is lot of confused users
<jpatrick> !xbug | desrt
<ubotu> desrt: The latest security updates unfortunately broke Java and wxWidgets applications. See https://launchpad.net/bugs/183969 for more information. The X.org package causing the problem has been pulled from the repositories, which is why you currently get a "403 Forbidden" error.
<desrt> fancy.
<desrt> who uses java and wx? :p
<keescook> desrt: no one who tests X updates, it seems.  none of the distros ran into the bug while doing testing.  :P
<desrt> keescook; =)
#ubuntu-devel 2008-01-19
<KillerKiwi2005> Whats the correct way for a deb to add a user to the fuse group??
<slangasek> "not"? :)  why do you need to do this?
<minghua> Shouldn't the primary user (created during installation) already be in fuse group anyway?
<KillerKiwi2005> The application needs fuse to work...
<Mez> how do I get a kernel config in the right place (saying that theres no config.mk)
<mgunes> are there plans to ship an svn snapshot of Network Manager 0.7 if 0.7 final isn't released in time for Hardy, or is the fallback plan to ship 0.6.5? I haven't found any relevant info in the nm-ifupdown-death-match blueprint.
<LaserJock> I'm guessing that might be determined at FeatureFreeze
<nixternal> boo
<articpenguin3800> why is ext3 default
<ToyKeeper> ... tradition, and because it's probably the most reliable and well-supported linux filesystem...
<ToyKeeper> With indexing enabled, it performs on par with xfs or reiser3 most of the time too.  :)
<articpenguin3800> well in my testing of the 4 filesystems reiserfs and xfs crapped out and ext3 insisted on doing fsck 5 times and jfs just started right up
<articpenguin3800> ext3 also fragments more than jfs and xfs
<ToyKeeper> I'm pretty fond of xfs.
<articpenguin3800> well with ext3 striving to be one of those safety filesystems it has since reached the point where it dosent have the speed to do what i need
<ToyKeeper> ... been using it since it was a new feature in IRIX, and it hasn't ever given me a problem.  :)
<LaserJock> articpenguin3800: you are welcome to use another filesystem :-)
<mgunes> LaserJock, thanks
<ToyKeeper> Heh, choice isn't exactly lacking in Linux.  :)
<articpenguin3800> do all filesystems slow down at 50% space usage?
 * ToyKeeper shuts down to pour wax all over his notebook
<LaserJock> articpenguin3800: I've never heard of that before
<articpenguin3800> well i have mostly tested ext3 and jfs on a 500GB partiton and JFS seems to complete operations faster than ext3. I find JFS does allocate files better too.
<articpenguin3800> bye!
<warp10> Good morning
<pwnguin> does sourceforge have a feature to view source by commits hiding somewhere?
<crimsun> pwnguin: viewvc does.
<pwnguin> i guess this depends on whether the archive is cvs or svn, but i'd like a whole commit concept
<\sh> doko, ping crystalspace...you wrote  Configure --without-java --disable-separate-debug-info, while --disable-separate-debug-info is configured correctly, the configure flag for --without-java is commented in...what's the truth? ,)
<pitti> keescook: btw, did you test it on amd64, or on i386, too? it doesn't seem to affect amd64
<geser> will debhelper 6 make it into hardy soon or should packages depending on it be changed to only need debhelper 5?
<Hobbsee> we have debhelper 6 now?
<minghua> Yes, since a few days ago.
 * Hobbsee looks for the changelog
<geser> Hobbsee: Debian has and the first packages start to build-depending on it
<Hobbsee> neat
<pitti> as long as it's fully backward compatible, I don't think that it is unreasonable to merge
<ion_> Whatâs new in debhelper 6? (I can just google it a bit later, but in case anyone feels like paraphrasing...)
<tostado> hi I'm installing feisty with FAI, and have console/font problems with german environment
<tostado> can someone help me out ?
<\sh> hint regarding tostados question: dpkg-reconfigure console-setup was already successful, but it looks like that he is missing some fonts or console font package somehow...
<\sh> re tostado ;)
<tostado> re \sh
<tostado> \sh: http://www.staz.be/wiki/FAI_Gutsy
<tostado> thats what i was looking for
<\sh> tostado, oh...yepp..that's working indeed
<tostado> \sh: we tried that and it didn't worked but we didn't spend much time in it - first we want to have a good feisty install and then we see...
<tostado> hmm.... nowbody have an idea how to get german environment on the console from scratch ?
<tostado> ok i try at #ubuntu
<jdong> can I poke an archive admin to clear binary NEW, particularly mpeg4ip?
<jdong> yeah I know it's the weekend :)
<\sh> infinity, ping gnubiff ... you exchanged libfam to libgamin during breezy cycle...debian upstream doesn't want to go with this change.. what would you propose for hardy? fam or gamin?
<mjg59> gamin
<\sh> mjg59, thx...
<Robot101> \sh: fam is loss
<\sh> Robot101, well, then I wonder why debian maintainer doesn't want to change
<Robot101> he's not qualified to do his job, he's just the first person who saw the package on freshmeat.net and filed an ITP? :P
<Robot101> or is that me being overly cynical... :)
<\sh> hehe
#ubuntu-devel 2008-01-20
<RAOF> Is anyone else having trouble booting without acpi=off after a recent update?
<BenderUnit22> cl
<BenderUnit22> Grr, sorry again.
<twb> Where can I find the NetworkManager people?  I'm trying to understand how to change network without resorting to a GUI.
<twb> #networkmanager appears to be empty.
<persia> twb: /usr/share/doc/network-manager/README.Debian may be helpful, but there doesn't seem to be much documentation, and this isn't the right forum, even if the other is empty.  You may have luck in #ubuntu, although it tends to be difficult on the weekends.
<twb> Thanks, I already tried both.
<twb> I'm pestering #debian now since I know they have NM, too.
<twb> s/have/hate/
<\sh> twb, you should deal with dbus
<\sh> twb, check /etc/dbus-1/even.d/*NetworkManager*
<twb> Yeah, but I've no idea how to forge messages on- hmm, looking...
<\sh> twb, learn dbus messaging ;)
<twb> I'd rather not if I could avoid it :-)
 * \sh goes to bed now
<twb> I only have /etc/dbus-1/system.d/NetworkManager.conf
<\sh> twb, dbus-1/event.d/ there are two daemons started..
<\sh> twb, tab-complete against dbus- and check google for more dbus and hal knowledge
<twb> Well, thanks
 * Hobbsee waves
<Mithrandir> iz Hobbsee
 * ion_ pulses
<Hobbsee> it iz!
 * Hobbsee stomps on Mithrandir's feet, before he levitates
<Mithrandir> Hobbsee: they're on top of my server, and you're not tall enough to stomp on top of that, so. :-P
 * Hobbsee can climb!  :P
<Mithrandir> pft
 * Mithrandir tickles Hobbsee 
 * Hobbsee bashes Mithrandir up
<torkel> Hey, kids, be nice to each other...
 * Hobbsee bashes torkel up too
<torkel> Hobbsee: go away from the computer now, and don't come back until you can behave...
<Hobbsee> hah
<theunixgeek> :)
<theunixgeek> Hi. I'm writing my own implementation of a command line file copy program, and I'm faced with the problem that the number of characters in a file should be set by the user in the third argument, but setting i = argv[3] doesn't really work. http://theunixgeek.pastebin.com/m26b0e8d6
<Seveas> theunixgeek, this is not a programming help channel
<theunixgeek> ok.
<rzr> http://www.vnunet.com/vnunet/news/2207369/microsoft-patents-employee
<andrea-bs> Hello! I want to know if bug #184603 can be a valid reason to ask the Stable Release Update for grep in gutsy
<ubotu> Launchpad bug 184603 in grep "grep -o wrong output" [Medium,Triaged] https://launchpad.net/bugs/184603
<gladier> hey guys - im packaging something up and get this message "dpkg-checkbuilddeps: error: control file must have at least one binary package part" along with "dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting."
<Chipzz> gladier: -> #ubuntu-motu
<Chipzz> andrea-bs: probably a whole lot of care would have to be taken there; grep is an Essential package
<andrea-bs> thank you Chipzz, what should I do with the bug?
<Chipzz> andrea-bs: I'm not an ubuntu developer, but... : if an updated grep would be broken, all hell would break loose; I would guess the -o option is not *that* important, and the chances of breaking other stuff may outweigh it
<Chipzz> but you should probably ask a real developer ;)
<andrea-bs> ok, thanks anyhow
<Chipzz> (otoh, the version in hardy isn't broken so chances of stuff breaking are smaller I guess)
<saispo> anyone use a bluetooth keyboard ?
#ubuntu-devel 2009-01-12
<bluefoxicy> [0x40f239] malloc(10)                            = 0x1959fe0
<bluefoxicy> [0x40661c] free(NULL)                            = <void>
<bluefoxicy> [0x40f239] malloc(2016)                          = 0x1958550
<bluefoxicy> is there any way to turn this into a source code line number?
<bluefoxicy> (first hex number is the instruction pointer at time of the call)
<RAOF> bluefoxicy: If you install the dbgsym packages for ls and such the backtrace at any point should include linenumbers, IIRC.
<bluefoxicy> RAOF:  that didn't  come from gdb
<bluefoxicy> I'm not sure how to script gdb...
<RAOF> Oh.  That'll be a strace, right?
<bluefoxicy> yeah
<bluefoxicy> ltrace but
<bluefoxicy> I want to extract every call to malloc(), free(), and realloc() from an application, timestamped
<PovAddict> hey
<PovAddict> did anyone see what I said about translations?
<PovAddict> that everything started showing in English since I upgraded the language packs and nobody seems to *care*?
<TheMuso> PovAddict: Where did you point this issue out, and have you filed a bug or checked if there have been any bugs filed about the issue?
<PovAddict> I pointed it out here and mentioned the ID of the bug I issued
<PovAddict> #316174
<PovAddict> er, filed
<PovAddict> whatever
<TheMuso> Ok as long as a bug is filed, it will be attended to.
<PovAddict> so annoying... does *everybody* here just use the desktop in English?
<Hobbsee> unlikely
 * Hobbsee blinks
<Hobbsee> PovAddict: it's less likely that people here still run hardy, fwiw.
<PovAddict> upgrading means learning a whole new desktop environment
<PovAddict> KDE3 -> KDE4
<Hobbsee> this is true
<Hobbsee> hm, interesting.
<Hobbsee> as a workaround, i'd suggest you install version 1:8.04+20081124
<PovAddict> strange thing with the -base packages
<PovAddict> a 20090105 version is listed but not shown as an upgrade
<PovAddict> what's the logic to decide if a package is upgradeable? :/
<Hobbsee> use a dist-upgrade on it
<Hobbsee> that one contains files, it appears
<PovAddict> aptitude dist-upgrade says there is nothing to do
<Hobbsee> strange.
<Hobbsee> PovAddict: oh, and it's in proposed, btw, so may not show on packages.ubuntu.com
<Hobbsee> (it hasn't been pushed to everyone, fortunately)
<PovAddict> hmm why did I get it? I have -proposed in my sources.list but it's set in... some way so that it's not used by default
<Hobbsee> set in... some way so that it's not used by default?
<PovAddict> they supposedly don't show unless I do aptitude -t hardy-proposed
 * Hobbsee shrugs, being relatively unfamiliar with teh internals of aptitude.  I usually lock things at dpkg level, so it works everywhere, if i want to do that
<PovAddict> it was done by editing /etc/apt/preferences
<PovAddict> I don't understand how it works though :)
<PovAddict> Package: *
<PovAddict> Pin: release a=hardy-proposed
<PovAddict> Pin-Priority: 400
<PovAddict> anyway, I just downgraded the four packages i had upgraded before
 * Hobbsee wonders if aptitude even follows apt's preferences file
<LaserJock> should
<PovAddict> well it has worked before :)
<PovAddict> I also have hardy-backports there, and I'm sure they don't show unless I "-t" ask for it
<PovAddict> aptitude -t hardy-backports shows two dozen upgradeable packages right now (that don't show otherwise)
<PovAddict> oops, I meant -proposed in that last message
<PovAddict> backports shows even more :)
<ghostcube> hi i have a question and i didnt get an answer it seems on 64 bit intrepid the /usr/lib/libGl.so link to the libGl.so.180.11 isnt set
<ghostcube> its set in the lib32
<ghostcube> should i add it manually
<TheMuso> ghostcube: didn't get an answer where?
<ghostcube> #ubuntu #kubuntu
<TheMuso> ghostcube: Considered checking whether a bug has been filed about this? If there isn't one, I suggest you file one.
<ghostcube> i looked and i didnt find anything useful
<TheMuso> ghostcube: Is this problem causing applications to malfunction/not function at all?
<ghostcube> i cant compile compiz it claims missing libGl
<ghostcube> so i think this could cause problems
<TheMuso> ghostcube: You need to install the development files for the nvidia libraries.
<TheMuso> sorry why did I get nvidia mixed up in all of this? :S
<ghostcube> hmm then it removes the libgl1-mesa-dev and the libgl1-common-dev
<TheMuso> ghostcube: is there any reason why you need to compile compiz?
<ghostcube> iam just supporting in channel so i need the newset versionmostly from git
<TheMuso> don't mind me and what I said rei nvidia.
<TheMuso> Ok, I suggest you run "sudo apt-get build-dep compiz" which will install everything you need.
<ghostcube> yeah but this wont fix the prob its just an missing symlink
<ghostcube> as it seems
<TheMuso> ghostcube: How do you know it won't fix it? Have you tried it?
<ghostcube> try what ? it worked fine i just tried to compile from git
<ghostcube> and i get the missing liGl error
<ghostcube> i need the git version of compiz the master not the apt-get source builds
<PovAddict> do you know what build-dep does?
<ghostcube> it cathces all dependencies for the build
<ghostcube> i dont want to stress i am just wondering if the symlink is  missing
<ghostcube> thats all :)
<TheMuso> ghostcube: No, its in a -dev package somewhere. I am not sure which one because I'd  need to check what package the file belongs to.
<ghostcube> i checked it with apt-file
<ghostcube> it belongs to libgl1-mesa-dev
<TheMuso> Its Debian/Ubuntu policy to keep those symbolic links in the development packages only, as they are not needed for normal use.
<ghostcube> and this is installed
<TheMuso> Ok.
<ghostcube> and if i want to install the nvidia-glx-180-dev  which contains the same file it will remove the libgl1-mesa-dev
<ghostcube> is this the problem maybe ?
<TheMuso> I don't know enough about those packages to comment.
<ghostcube> me too :|
<ghostcube> and it seems no one else in channels around iam asking since 4 hours now
<ghostcube> noo one has any idea
<ghostcube> nah 7 hours
<ghostcube> boah late
<dholbach> good morning
<ion_> That
<soren> Keybuk:
<soren> Whoops
<soren> 14:57 < Keybuk> soren: I'm reverse-thinking here
<soren> 14:57 < Keybuk> we should probably just copy of all of /etc/udev/rules.d into the initramfs
<soren> 14:58 < Keybuk> though that might break things since we don't copy hardly any of /lib/udev/rules.d
<soren> 14:59 < Keybuk> or
<soren> Keybuk: I don't understand that last line.
<soren> 14:59 < Keybuk> copy anything not in /lib/udev/rules.d
<soren> 14:59 < Keybuk> and copy anything in /lib/udev/rules.d *if* it has been copied into the initramfs
 * soren wonders if Keybuk is actually here at this hour
<dholbach> can we move imlib2 to universe?
<dholbach> to me it looks like all rdepends live in Universe
<slangasek> have you checked component-mismatches and/or germinate?
<dholbach> slangasek: erm, no
<slangasek> imlib2 doesn't show up on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt, which means there's something else in main that (build-)depends on it
<dholbach> hm
<slangasek> http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.jaunty/all shows that w3m build-depends on it
<dholbach> ah, good to know
<dholbach> thanks slangasek
<Hobbsee> anyone know where pitti is?
<directhex> Hobbsee, germany?
<slangasek> "elsewhere" this week :)
<Hobbsee> directhex: I knew that, but thanks :)
<directhex> Hobbsee, :p
<Hobbsee> slangasek: ah.  So, who does one get poked about for a broken hardy-proposed langpack update?
<slangasek> me
<seb128> Hobbsee: he's on holidays for the week
<Hobbsee> slangasek: consider yourself poked on https://bugs.launchpad.net/bugs/316174 then :)
<ubottu> Launchpad bug 316174 in language-pack-es "All translations gone" [Critical,Confirmed]
<slangasek> also ArneGoetje, who's the one that will have to fix it...
<Hobbsee> seb128: thank you
<cjwatson> PovAddict: with regard to language packs, the shrinkage in size is entirely expected; the way language packs are structured is that there's an -LL-base which contains most translations, and an -LL which contains some more translations as updates to that; this lets us push out frequent langpack updates with less mirror churn
<slangasek> Hobbsee: hrm, surely that's because they've been merged into language-pack-es-base, since that was the purpose of the langpack update?
<cjwatson> PovAddict: so what happened in -proposed was that the -LL-base packages were respun to save us CD space, which of course resulted in the -LL packages shrinking down to almost nothing
<Hobbsee> slangasek: ahhh, is that the point.  Right
<cjwatson> PovAddict: did you upgrade the -base packages as well?
<cjwatson> slangasek: from the bug, looks like an insufficiently-tight dependency, though
 * slangasek nods
<cjwatson> hmm
<cjwatson>  Package: language-pack-es
<cjwatson>  Depends: language-pack-es-base
<cjwatson> and
<cjwatson>  Package: language-pack-es-base
<slangasek> ArneGoetje: ^^ can you fix that so language-pack-$foo has a versioned dep on language-pack-$foo-base?
<cjwatson>  Depends: language-pack-es (>= 1:8.04+20090105), locales (>= 2.3.6)
<cjwatson>  Conflicts: language-pack-es (<< 1:8.04+20090105)
<cjwatson> but there's a long-standing dpkg bug/lack-of-feature to the effect that Conflicts B->A are not checked on upgrade of A
<slangasek> well, surely it's not even that
<cjwatson> and of course the old language-pack-es-base is still installed
<slangasek> right
<cjwatson> -base still seems to be around the expected kind of size
<cjwatson> so I don't think we've actually had major translations lossage
<Hobbsee> cjwatson: I think he said he couldn't update -base for some reason, so that would work
<cjwatson> Hobbsee: he said that it wasn't listed as an available upgrade, and it seemed that aptitude was doing something confusing with pinning
<Hobbsee> that was it, yes
<slangasek> cjwatson: actually, the -base packages have each grown by 300k or more
<slangasek> er, 200k for -en, 400k or more for pt/es
<slangasek> which makes sense in terms of post-release translations
<slangasek> but poses interesting problems for LTS point releases
<cjwatson> they have?
<cjwatson> -rw-r--r-- 1 lp_publish lp_publish 3094350 Jun 17  2008 ubuntu/pool/main/l/language-pack-es-base/language-pack-es-base_8.04+20080527.2_all.deb
<cjwatson> -rw-r--r-- 1 lp_publish lp_publish 3106094 Jan 10 12:04 ubuntu/pool/main/l/language-pack-es-base/language-pack-es-base_8.04+20090105_all.deb
<cjwatson> -gnome-es-base has grown about 40K AFAICS
<slangasek> cjwatson: well, I was comparing against 8.04.0
<slangasek> because there are packages from 8.04.1 that aren't in the main archive anymore, making it hard to do a full comparison, grmbl
<slangasek> (mutter, need to get something set up to record the .deb sizes at image build time)
<cjwatson> that's why there's a hardlink tree archive of .1 on cocoplum
<slangasek> yeah, but I have the .list files on antimony :)
<slangasek> I guess copying those to cocoplum would be the easier route, wouldn't it
<cjwatson> calc: ooo3 binaries accepted, enjoy :)
<directhex> cjwatson, OOo3 landed in main?
<lool> cjwatson: Just FYI I managed to bootstrap rpm with its autogen last Friday, thanks
<lool> (had to fix a couple of issues but at least it got the work done)
<cjwatson> directhex: yes
<cjwatson> lool: ok, cool
<lool> Grrr
<lool> blkid just fixed itself automagically I hate that
<lool> Aha /etc/blkid.tab and /etc/blkid.tab.old
<lool> Too bad I already destroyed evidence...
<soren> Umm... Where does compiz store its config these days? I change stuff in gconf, but it doesn't seem to take effect.
<soren> mvo: ^ ?
<lool> soren: I had the same issue; there's also an "ini" backend
<mvo> soren: it should be gconf, but sometimes it gets confused and starts using the ini interface. please use ccs and look at the backed settings there
<mvo> soren: lower left corner
<lool> soren: You can access settings in a backend independent way with the python bindings, but I found addressing individual settings extremely painful
<mvo> soren: I thought I had fixed this particular bug during intrepid development though :/
<lool> (just borke when I upgraded to jaunty for instance)
<soren> I forget... Button2 is the right or middle button?
<lool> mvo: I used to set my shortcuts with a script like this one http://people.ubuntu.com/~lool/set-shortcut-config but the way I address the compiz settings broke completely; it there a better way to address settings?
<lool> s/it/is
<soren> I'm having the most annoying issue with compiz or ccsm or something.
<soren> I don't have a middle button, and from Xfce I'm used to alt-rightmousebutton resizes windows. I want to make compiz do the same, but I get bitten by a whole stack of weirdness.
<soren> Alt-RightMouseButton brings up the window menu. I never need that, so I just disable it under General in ccsm.
 * lool finds it weird that blkid maintains his cache of block device's properties when we have udev and sysfs
<soren> When I disable the window menu, compiz seems to pretend that I'm holding down <Alt>.
<soren> !
<mvo> soren: uhh, let me try to reproduce
<soren> To click on things, I need to hold down alt. To drag a window, I need to *not* hold down alt.
<soren> mvo: Hang on, I'll reset all my compiz settings.
<mvo> lool: does the ccsm "export my settings" help you for your use-case?
<soren> I'll nuke ~/.config/compiz (which seems pretty empty anyway)
<soren> and to a gconftool-2 --recursive-unset (after grabbing a backup)
<mvo> soren: there is a "reset" button in ccsm as well
<mvo> (just fyi, your method will/should work too)
<soren> Let's just say that I don't trust ccsm very much at this point :)
<mvo> soren: you may want to stop compiz before the recursive unset, sometimes the config system tries to be clever :)
<soren> mvo: Right, I did it while running metacity.
<soren> Ok. Here goes.
<soren> I go to the "General" place in ccsm and disable the window menu.
<soren> In the "General" tab, third option from the top.
<soren> As soon as I do that, it's like my <Alt> key is inverted.
<soren> When I try to click on things, it thinks I want to move the window.
<soren> When I hold Alt down, I can click on things normally.
<soren> If I go to the "Move" plugin.
<soren> ...
<soren> It clearly says that the initiate button is Button1. No modifier.
<soren> That rates at least 5.6 on my weird-stuff-o-meter.
<soren> Anyhow, I add <Alt> there..
<soren> and my <Alt> button's sanity is restored.
<soren> I go to the resize plugin..
<soren> And tell it that I want the initiate button to be <Alt>Button3.
<soren> It then tells me that the window menu action already uses this combo (even though I disabled it).
<soren> I click "Disable Window Menu"
<soren> And my <Alt> button is b0rked again.
<soren> s/button/key/
<soren> I'll try setting the window menu thing to <Shift><Ctrl><Alt><Super>Button9 instead (I'm hoping that won't conflict with anything).
<lool> mvo: I guess I could use export/import settings; never tried it; will see what that gives, thanks
<soren> What the...
<soren> That changed all the modifiers for "Resize window" as well?!?
<soren> Madness
<soren> I give up.
<mvo> soren: let me try that here
<soren> I might be doing this all wrong. I just want Alt-RightMouseButton to resize windows.
<mvo> soren: I can reproduce that here, I have a look (and/or forward to upstream)
<lool> Does someone know what upstream bug tracker e2fsprogs uses?  It seems to be Debian's e2fsprogs source, but I'd like to confirm
<cjwatson> I don't know for sure, but I know that Ted follows both Debian's and Ubuntu's bug tracker to some degree; probably pays more attention to Debian's
<slangasek> my impression is that he tracks e2fsprogs bugs in LP rather closely
<slangasek> hmm.  the edubuntu pod now includes an edubuntu-desktop-kde seed that references an edubuntu-desktop-kde metapackage.
<cjwatson> http://ext4.wiki.kernel.org/index.php/Bugs but I'm not sure whether that's only for the kernel side
<cjwatson> lool: http://sourceforge.net/tracker/?atid=102406&group_id=2406&func=browse seems to exist too
<mvo> soren: as a workaround, please try "preferences" and select the "enable integreation into the desktop environement"
<cjwatson> (via e2fsprogs.sourceforge.net)
<mvo> soren: please let me know if that works for you (it seems to do the trick for me)
<lool> cjwatson: Yeah, I checked bugzilla.kernel.org and came to the main conclusion, and the main e2fsprogs site, and was completely confused
<lool> Ok; I'll just Also affect e2fsprogs and ping tso
<lool> slangasek: Thanks for the hint
<james_w> lool: hey, I see your name in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510673
<ubottu> Debian bug 510673 in libjack-dev "xine-lib: FTBFS: /bin/sed: can't read /usr/lib/libsamplerate.la: No such file or directory" [Serious,Closed]
<james_w> lool: there's a sponsorship request open to pull in the removal of the .la from Debian. Do you know why "bio2jack" is the only package that will break from that?
<slangasek> james_w: because bio2jack is the only reverse-dep which is also a shared lib shipping a .la?
<Laney> iain@intrepid:~/packaging/bio2jack/usr/lib$ grep dependency libbio2jack.la
<Laney> dependency_libs=' /usr/lib/libjack.la -lrt -lpthread -ldl /usr/lib/libsamplerate.la -lm'
<james_w> yeah, I came out with a huge list of packages when I tried, but I think I used the tools wrong
<james_w> I get "libbio2jack0-dev: /usr/lib/libbio2jack.la portaudio19-dev: /usr/lib/libportaudio.la portaudio19-dev: /usr/lib/libportaudiocpp.la libfluidsynth-dev: /usr/lib/libfluidsynth.la libecasound2.2-dev: /usr/lib/libecasound.la"
<slangasek> james_w: inspection of libportaudio.la seems to indicate that this lib doesn't depend on libsamplerate
<soren> mvo: That's already selected?
<soren> mvo: Sorry about the slow reply. compiz sent me to lunch.
<tseliot> seb128: I have just fixed a rather annoying bug in nautilus with a simple 3-lines patch. Can you have a look at it, please? http://bugzilla.gnome.org/show_bug.cgi?id=567479
<ubottu> Gnome bug 567479 in Tabs "Clicking on a different tab doesn't update the scrollbar" [Normal,Unconfirmed]
<seb128> tseliot: that's a duplicate of http://bugzilla.gnome.org/show_bug.cgi?id=542396
<ubottu> Gnome bug 542396 in Tabs "ScrollBar isn't showed when open a new tab(impossible to scrolling)" [Major,New]
<seb128> tseliot: could you add your patch to this one?
<tseliot> seb128: sure
<seb128> tseliot: I'll try to get upstream to review it
<seb128> thanks
<tseliot> seb128: ok, done
<seb128> tseliot: thanks
<tseliot> thank you
<james_w> and libiaxclient-dev with /usr/lib/libiaxclient.la
<asac> Riddell: any news on the knetworkmanager front? will we get a kde4 version?
<Riddell> asac: I'm hopeful but I believe it's not there yet
<asac> Riddell: damn. so how bad would another knetworkmanager breakage in alpha 3 be?
<asac> Riddell: i have the final 0.7 bits waiting for upload ... knetworkmanager probably will have issues though
<Riddell> asac: I guess we'll live with it, are they in the PPA to test?
<asac> Riddell: yes
<asac> ~network-manager
<asac> Riddell: let me know how bad it is .... my guess is a crash ;)
<lool> james_w: yes because its *.la files reference the dropped ones
<lool> Pff xine-lib is maintained in hg
<lool> james_w: It wasn't my recommendation to drop the *.la files; instead I recommended stripping the dependency_libs= line to be empty
<lool> james_w: It might affect a different set of packages in Ubuntu than in Debian though; it depends whether our packages shipping *.la files were built against other packages when these used to ship or stopped shipping *.la files
<asac> fta: pastebinit is broken in jaunty?
<james_w> lool: ah, ok
<asac> fta: seems to not honour my .pastebinit.xml anymore
<lool> james_w: It might affect more than libjack-*-dev's rdeps, but if it does then these packages were lacking a dep on libjack*-dev
<lool> So it should be enough to check whether libjack*-dev rdeps ship *.la files and whether these reference libjack*-dev's *.la files; in theory, this should be done on all arches
<james_w> lool: I have a list for i386, checking that rebuilds of them will be sufficient now.
<mvo> soren: (sorry for my late reply, I was at lunch :) - please unselect the DE environment integratio
<crusader05> ?
<soren> mvo: Ooh... Looks promising!
 * soren hugs mvo 
<soren> mvo: Awesome! It works.
<mvo> soren: thanks, I'm created a upstream bugreport and will add a (targeted for beta) ubuntu one too
<mvo> soren: thanks for brining this up :)
<soren> You bet.
<cjwatson> asac: I've just had a two-day saga of getting my 3G modem to work ... none of which was NetworkManager's fault. :-) As soon as I managed to teach the kernel and hal to detect it, NM Just Worked. Nice!
<ScottK> slangasek: I just updated  Bug #316262 - It should be removed.  I'd appreciate it if you'd have another look.
<cjwatson> somewhat infuriatingly it's twice as fast as my ADSL connection
<asac> cjwatson: yeah congrats ;). is that a new modem or did you need to adjust an existing hal entry?
<cjwatson> asac: newish modem, it's one of the hso family and needs nasty hacking
<asac> urgh
<asac> what was needed on kernel side?
<asac> cjwatson: ?
<cjwatson> asac: deactivating the stupid ZeroCD thing it comes with
<asac> heh
<asac> yeah
<cjwatson> sounds like you're familiar with it already :)
<asac> I think the plan is to fix the driver
<cjwatson> yes, Dan Williams already sent a patch to do most of that
<asac> there is one modem class that already has the fix in the driver
<asac> ah ok cool
<cjwatson> but it needed a bit further tweaking
<cjwatson> I'll send something upstream shortly
<cjwatson> shall I CC you?
<asac> sure, why not.
<siretart> asac: may I ping you about the sunbird/iceowl 0.9 uploads? ;)
<asac> siretart: yes ;)
<asac> feel free
<asac> siretart: i think https://code.edge.launchpad.net/~mozillateam/sunbird/ubuntu-0.x and the iceowl one are really ready for action
<asac> i think its now a matter of upload bandwidth here ;)
<siretart> ah, I see :-)
<asac> siretart: ok building sunbird sources and then will just push i guess
<asac> in case something is broken we probably can still fix it before release ;)
<asac> siretart: uploading
<siretart> cool! thanks!
<sabdfl> https://edge.launchpad.net/~ubuntu-dev/+polls
<james_w> can't we have both? :-)
<cjwatson> Keybuk: so you were talking about how git reset is missing from bzr ... the other way round, do you know how to do 'bzr revert <file>' in git? 'git reset --hard <file>' is what I'd expect but it refuses
<cjwatson> (i.e. forget about all changes in index and working tree, but only to certain file(s))
<Keybuk> git checkout -- <file>
<cjwatson> ah, of course
<cjwatson> thanks!
<Keybuk> you may need -f there
<cjwatson> yeah
<cjwatson> fatal: git checkout: updating paths is incompatible with switching branches/forcing
<cjwatson> maybe --
<cjwatson> ah, just without -f works
<cjwatson> obvious UIs 'r' us
<Keybuk> heh
<Keybuk> ooh, right, -f is when you've already git add'd it
<cjwatson> no, I actually need 'git checkout HEAD <file>', and it doesn't DTRT with new files
<Keybuk> it's obvious when you see things from git's pov
<cjwatson> I *had* already git add'd it
<Keybuk> bah
<Keybuk> git sucks ;)
<cjwatson> no argument from me
<Riddell> asac: knetworkmanager appears to work with NM 0.7 from the PPA
<asac> Riddell: thx
<Riddell> asac: KDE 4 applet still doesn't though alas
<cjwatson> Keybuk: is there a neater way, in hal, to say "match on the contents of this sysfs attribute" than writing a preprobe shell script to fish out the attribute and save it with hal-set-property?
<cjwatson> Keybuk: the IHV-written code I have here does the latter, but I notice that nothing in hal or hal-info seems to do anything much complicated with preprobe, which leads me to suspect that I might be on an inelegant track
<Keybuk> only in code
<Keybuk> you'd have to modify HAL's code to add new sysfs attributes
<cjwatson> is that preferred over adding a preprobe script, for something that's insanely device-specific?
<Keybuk> I guess
<cjwatson> maybe I'll just send a patch to hal-info with the preprobe script and see what David says
<cjwatson> less effort if it's a bit ambiguous :-)
<Keybuk> hal_util_set_string_from_file (d, "my.little.property", sysfs_path, "wibble")
<ArneGoetje> slangasek: about the versioned dependencies on the language-packs: I can try. Since the langpacks are generated by script, the script would need to be ammended to accept the dependent version number as argument...
<cjwatson> ArneGoetje: this surely is not a problem since language-pack-LL already has versioned Replaces on various other packages with the correct version numbers
<cjwatson> and therefore must have this information already
<directhex> cjwatson, you busy?
<cjwatson> directhex: sort of, why?
<cjwatson> more stack-full than busy if you see what I mean
<directhex> debian bug 480020. can you think of any major reason not to insist to novell that they apply the included patch immediately?
<ubottu> Debian bug 480020 in openssh-server "openssh-server: adjusted OOM killer is inherited by all child processes" [Normal,Closed] http://bugs.debian.org/480020
<ArneGoetje> cjwatson: but not for the -base packages, right?
<directhex> i'm having... problems... with servers at work and oom killer
<Keybuk> directhex: err
<Keybuk> it's correct that the OOM killer adjustment is inherited from parent to child
<Keybuk> (most such things are in UNIX)
<Keybuk> I guess for ssh, you don't want bash inheriting it?
<directhex> Keybuk, quite
<cjwatson> ArneGoetje: not as far as I can see but surely isn't a big problem since it's done for the delta packages; you can just follow the same approach
<cjwatson> directhex: IIRC there was some later problem as wewll
<cjwatson> well
<directhex> sodding linux
<directhex> where's my hurd tarball gone
<cjwatson> directhex: and I didn't even know that Novell had taken the *prior* patch I did to support tweaking the OOM killer in sshd at all
<cjwatson> Keybuk: in this context I agree with directhex that it's definitely wrong
<Keybuk> cjwatson: yeah, I've had the same problems with ssh with supervision
<Keybuk> "sshd is still running because someone once ran screen"
<cjwatson> directhex: does Novell set up sshd to run with OOM-killer disabled, then?
<cjwatson> directhex: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500121 claims to still have the problem, not debugged yet
<ubottu> Debian bug 500121 in openssh-server "openssh-server: Adjusted OOM killer is inherited by all child processes" [Normal,Open]
<directhex> cjwatson, no, they don't
<cjwatson> might be user error but as I say I don't know
<directhex> cjwatson, if a user uses lots of ram, then bye bye server
<cjwatson> oh, right, you're running into the *original* problem
<directhex> aye
<cjwatson> point them at the upstream bug I guess though I wouldn't blame anyone for not wanting to patch extra features into openssh
<directhex> sigh. i just want users who try and use too much ram to have their job killed, and the node ready for the next job. is that so much to ask for? :/
<directhex> i'll poke sgi. if novell aren't interested, sgi can always stick a modified rpm on their repo
<ArneGoetje> cjwatson: the current Replaces: line has (<< ${Source-Version}) in a skel template. I don't see how this can be applied to the Depends field, since the deltas get higer version numbers than the base package. The script would need to check, which version of the base packages is currently in the archive.
<ArneGoetje> cjwatson: or, when rebuilding the base packages, it would set it to ${Source-Version} too.
<cjwatson> ArneGoetje: oh, right, I see what you mean
<Keybuk> hmm
<Keybuk> every LP page for me is popping up that annoying "Some parts are insecure" dialog
<Keybuk> is it doing it for anyone else?
<tedg> Keybuk: No dialog, but I get a "broken lock" icon.
<cjwatson> ArneGoetje: seems to me that the most recent base package version could be saved in bzr somewhere
<cjwatson> and then substituted in with the LangpackMacros stuff
<ArneGoetje> cjwatson: I think I need to discuss this with pitti, what the most reasonable approach is.
<cjwatson> pitti is on holiday, I think
<cjwatson> yes, all week. We can't afford to wait a week to resolve a regression in a stable update
<cjwatson> (or at least a perceived one)
<cjwatson> and waiting a week will cause us to slip 8.04.2
<ArneGoetje> cjwatson: this calls for a quick and dirty hack I think...
<cjwatson> yeah, I was just having a look to see what would be easier
<cjwatson> easiest
<cjwatson> ArneGoetje: I'm thinking of something like http://paste.ubuntu.com/103950/ (untested)
<cjwatson> i.e. ram the dependency in with a spoon :-)
<ArneGoetje> cjwatson: ouch :)
<ArneGoetje> cjwatson: that's indeed quick and dirty
<cjwatson> obviously with the intention of something better being put in place when pitti gets back
<ArneGoetje> cjwatson: of course
<cjwatson> e.g. a maps/ file listing the current base versions for each release
<seb128> Keybuk: edge does but non-edge doesn't
<cjwatson> which would then have to be kept up to date
<cjwatson> asac: there's a claim in the ozerocdoff source as follows:
<cjwatson>   This changes the network interface of a Option WWAN-modem from the default
<cjwatson>   wired network category 802.03 into the new wwan categrory and changes the
<cjwatson>   serial control and application port from default category serial into
<cjwatson>   the new wwan, debug or gps category need for Network-Manager version 0.7.0
<ArneGoetje> cjwatson: that's one possibility, yes. Im thinking, as we have this information available in launchpad, if we could maybe pull it from there...
<cjwatson> asac: and it then goes and changes net.80203 to net.wwan across the board
<cjwatson> asac: however, by some kind of fluke these FDI rules don't fire for me at the moment, and the device works anyway. On further investigation I find no mention of net.wwan anywhere in NM
<cjwatson> asac: is ozerocdoff just on crack?
<asac> cjwatson: i think so
<asac> cjwatson: NM doesnt look at net.wwan
<cjwatson> ArneGoetje: that could be possible longer#-term as well, yes
<cjwatson> s/#//
<asac> it looks at "modem" capability ;) with V.250 command sets
<Joe_CoT> Question: How would I request that Asterisk be moved to main?
<asac> and for wired its net.80203 ... wifi net.80211?
<cjwatson> asac: this sets GSM-07.07 and GSM-07.05 in modem.command_sets and seems to work as a result
<cjwatson> Joe_CoT: https://wiki.ubuntu.com/MainInclusionProcess
<asac> cjwatson: yes. that helps NM to know whether its GSM or CDMA
<cjwatson> Joe_CoT: it will need developers willing and able to support it
<asac> and should be enough
<asac> hopefully with modemmanger NM will do auto detection of command-sets so we dont have to do that each and every modem
<Joe_CoT> cjwatson, ok, thanks. Is it too late to try to get this done for gutsy?
<Joe_CoT> Sorry, Jaunty
<cjwatson> Joe_CoT: not necessarily
<cjwatson> Joe_CoT: although don't bet the house on it :-)
<cjwatson> Joe_CoT: starting a discussion on ubuntu-devel would be a reasonable way to begin
<Joe_CoT> cjwatson, yeah, I saw that, but I can't post to ubuntu-devel
<cjwatson> sure you can, it just waits for moderation
<ArneGoetje> cjwatson: I applied your patch and will try to rebuild the langpacks now.
<cjwatson> ArneGoetje: thanks
<Joe_CoT> cjwatson, ok, I'll give that a go later. thanks
<Keybuk> seb128: yeah, lp people are looking into it now
<wasabi> random sort of offtopic and odd question that i'm curious about:   anybody have an ubuntu armel chroot running on a G1?
<Keybuk> it's the javascript library apparently
<asac> geser: libjdic-java still uses xul 1.8? any reason?
<geser> asac: I don't know
<apw> if you are modifying a packaged based on an upstream package, one which has a debian/patches/ modifier, should that also be used for handling complete new files
<persia> apw, Depends on the file, but often, yes.
<apw> this is a new file for a hooks collection
<persia> Exceptions would be when the file ought live in debian/ and get installed at install time (not used at build-time).
<Keybuk> slangasek: so, I hear you escaped your civic duty?
<apw> persia, this could be seen as that an additional file overlayed on the result
<persia> apw, Is this file used at build-time or install-time?
<persia> (also, #ubuntu-motu is frequently a more on-topic place for packaging questions)
<apw> its not needed for the build, an additional file only
<persia> Personally, I'd put that in debian/${file} rather than as a patch in debian/patches, and install it with dh_install.
<apw> yeah, and actually now you've said that i can see one here just the same, thanks for the pointers
<cjwatson> james_w,NCommander: I've had bug 289741 open in my browser for a while, and was thinking of just applying it regardless of powerpc testing. Would that be OK with you guys?
<ubottu> Launchpad bug 289741 in ichthux-meta "[intrepid] ichthux-meta does not build on pia, sparc and powerpc" [High,Confirmed] https://launchpad.net/bugs/289741
<cjwatson> (actually I'd apply the update.cfg bit and regenerate)
<james_w> cjwatson: I have no opinion on the matter
<persia> txwikinger is the regular maintainer of ichthux-meta, if that impacts any decision
<cjwatson> doesn't hurt
<cjwatson> I'll tweak his change slightly to match other *-meta packages
<ebroder> Does anyone know if there's some way to hook the update-manager for some site-specifc upgrade stuff?
<Keybuk> cjwatson: when you were playing with your modem, did you encounter modem-modeswitch?
<cjwatson> YM usb_modeswitch?
<mvo> ebroder: not easily currently, but if you let us know what your use-case is we can provide hooks
<Keybuk> cjwatson: no
<cjwatson> OK, I didn't see modem-modeswitch
<mvo> ebroder: you can already exchange the whole thing in a config option (if you want to provide your own)
<cjwatson> I found three other roughly equivalent hacky piles of rubbish
<ebroder> mvo: We have a site apt repository that's getting disabled during dist upgrades. It'd be nice if the updater could do s/hardy/intrepid/ or whatever instead of commenting out the repos
<ebroder> mvo: Or if there was a hook where we could do that
<cjwatson> some of which claimed to need random sleeps inserted in order to work; none of which I could get to actually work for me before I got bored
<mvo> ebroder: ok, how about a config entry in /etc/update-manager/release-upgrades - something like "DisableThirdPartyRepos=True" that you could then change on your clients?
<persia> mvo, How about a regex, so allow selective disablement?
<ebroder> mvo: And if that was set to False, then the third-party repo would have the same substitution applied as the primary repos? That would be awesome, actually
<mvo> ebroder: yes
<mvo> persia: KISS (but yeah, could be a regexp too)
<mvo> ebroder: ok, I can do that for jaunty I think
<ebroder> That'd be amazing. Thanks
<persia> mvo, good point.  Just thinking of use cases.
<mvo> ebroder: could you please file a bug about it and paste me the bugnumber here? so that I can target it for jaunty?
<ebroder> Will do
<Keybuk> cjwatson: see the package I just dropped into NEW
<cjwatson> Keybuk: do I really want to use this rather than the out-of-the-box thing I have now? :-)
<cjwatson> (BTW "modem-modeswitch" is an irrelevant googlewhack, so I don't think I could have encountered it)
<Keybuk> cjwatson: well, it would be nice if you can test it ;)
<Keybuk> since this is going to be the out-of-the-box thing eventually
<cjwatson> isn't it better to do it in the kernel?
<Keybuk> I think so, but others disagree
<cjwatson> Linus and the usb-storage maintainers apparently agree
<Keybuk> if you haven't the time, dont' worry ;)
<ebroder> mvo: it looks like there's already LP #147080. I'll update the description to match your idea
<ubottu> Launchpad bug 147080 in update-manager-core "do-release-upgrade should make disabling third party repositories optional" [Wishlist,New] https://launchpad.net/bugs/147080
<NCommander> cjwatson, no issue on my end, my PPC is quite dead ATM, so I haven't had an opportunity to test it.
<highvoltage> "UDS: done," is probably not required in the topic anymore?
<apw> cjwatson, is pm-utils one of yours ?  :)
<fargiolas> hi, recently I've been playing a bit on a friend's computer with another linux distribution. We were quite impressed by the difference in font rendering and hinting between ubuntu and the other one. I looked around and saw that ubuntu enables some patent encumbered code in libfreetype for subpixel rendering. Are freetype patches enought to get the same ubuntu fonts look? do I need other patches? libcairo? xft?
<fargiolas> e.g. I see libcairo has got a 04-lcd-filter-or-something patch, is that related to font hinting?
<cjwatson> apw: nope
<cjwatson> apw: you can check the changelog to see who tends to upload things; /usr/share/doc/pm-utils/changelog.Debian.gz
<apw> looks like it pitti but i believe he is away
<cjwatson> yeah
<apw> i'll have to get all the bits together here, tested etc, then find someone to hastle about looking them over.  thanks
<mvo> ebroder: I milestoned it - I also accidently declined it for jaunty but when I try to approve it again LP oopses. so best to just ignore the "declined for jaunty" line for now
<james_w> apw: the author is often around, and I believe he follows lp bugs for the package, so you could contact him
<ebroder> mvo: Haha. Ok, thanks a lot
<apw> is that Michael ?
<persia> apw, Generally, debian/copyright should help you identify upstream for any package (/usr/share/doc/${package}/copyright for installed packages)
<apw> the change here is likely ubuntu specific, so not sure whether upstream is our target
<cody-somerville> Hai, The new version of gnome-keyring breaks the shit out of Xubuntu and Mythbuntu. kthxbi.
<seb128> slangasek: new evolution and evolution-data-server versions have been uploaded as intrepid sru today, would be nice if you could have a look and accept those and copy pocket the source to jaunty too since pitti is not there this week and they fix several annoying issues (evolution crashing when editing and account for example)
<seb128> cody-somerville: there is already a bug open about that
<cody-somerville> seb128, I know... but in the effort to improve communication, I decided to share that here.
<seb128> not sure with who you want to communicate that but why not
 * cody-somerville hugs seb128.
<apw> is there a fools guide on how to make bzr branches in launchpad for something hosted in launchpad/bzr thing
<cjwatson> bzr get lp:~OWNER/PROJECT/BRANCH [this just mirrors the remote branch locally for later speed]; bzr get BRANCH NAME-OF-YOUR-MODIFICATIONS; cd NAME-OF-YOUR-MODIFICATIONS; hack hack hack; bzr commit; bzr push lp:~YOURLPNAME/PROJECT/NAME-OF-YOUR-MODIFICATIONS
<cjwatson> there's very likely something more coherent on help.launchpad.net
<apw> b
<apw> cjwatson, thanks ... thats helpful i am sure i can muddle though from there.  having git knowledge is a problem
<cjwatson> if you keep forgetting to 'bzr push', handy tip is to run 'bzr bind <remote branch URL>' at which point your commits will be committed automatically to the remote branch as well
<apw> is there any way to 'remember' the binding without it doing it all the time
<apw> so that bzr push works, but i don't need the lp: crapola on the end?
<james_w> "bzr push" will default to that location from now on
<apw> bzr: ERROR: Target directory lp:~apw/apport/suspend-resume already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.
<james_w> "bzr push --remember wherever" to override the default later if desired
<apw> and do i expect that the first time?
<james_w> no, that's not expected
<apw> bah, everything always breaks when i do it
<james_w> did you have an interrupted push before?
<apw> nope
<apw> i went into launchpad and made the branch in the web interface
<apw> and then tried to push into it, and it said that first time
<james_w> ah
<james_w> in that case it is expected
<james_w> add --use-existing-dir as suggested
<cjwatson> apw: alternatively, 'bzr bind' will be remembered
<cjwatson> though you'll still need to push the first time
<cjwatson> apw: for the record, you don't need to create the branch in the web interface
<cjwatson> you can just push to lp:~apw/foo/bar at will
<apw> oh ok, the web kinda implies you do with all its register buttons
<cjwatson> assuming that the project 'foo' exists (launchpad.net/foo)
 * apw pushes
<calc> slangasek: is there enough time left for me to respin OOo again before the alpha freeze?
<calc> slangasek: its a simple fix but will take building just ooo itself no langpacks to do it
<Keybuk> AAARGH!
<Keybuk> Vcs-Bzr: bzr+ssh://bazaar.launchpad.net/~ubuntu-mythtv/mythtv/mythtv-fixes
<Keybuk> What is the point of having a package in bzr if only a private team can commit to it ?!?!?!?!
<LaserJock> Keybuk: so you can make merge requests?
 * apw slaps bzr ... let me do a bzr diff in the middle of a commit dammit
<Keybuk> LaserJock: I can upload the package into the archive ;)
<LaserJock> Keybuk: well sure, but I think many people use Vcs-Bzr for people who can't upload
<Keybuk> then ubuntu-dev should be a member of that team
<Keybuk> or they should have two branches
<LaserJock> perhaps, but then ubuntu-dev gets spammed
<Keybuk> one ~ubuntu-dev representing what's in the archive
<superm1> Keybuk, we went through this before, then ubuntu-dev gets a lot of requests that spammed
<Keybuk> and another private one that anyone can commit to
<ogra> Keybuk, udev doesnt have rules for mtd devices ?
<Keybuk> ogra: should it?
<superm1> Keybuk, at least in that case -  a merge request is much more preferable than someone outside ~ubuntu-mythtv doing the upload.  we like to be very careful what patches get applied etc
<Keybuk> superm1: we don't have maintainership in Ubuntu
<ogra> well, i dont have any /dev/mtdblah but the kernel has builtin support for them and there should be one in the HW on my arm system
<ogra> though, no trace in dmesg
<Keybuk> ogra: that implies the kernel hasn't created one
<ogra> yeah
<Keybuk> you only need udev rules if you don't like the default kernel name
<ogra> i thought udev creates the devicenode in any case
<Keybuk> exactly
<superm1> Keybuk, yes,  but still people who regularly work on packages tend to prefer to be poked anyhow to know what's happening with (possibly) invasive patches though, no?
<Keybuk> superm1: yes
<ogra> but takes what the kernel offers if it has no rule ? ah
<Keybuk> but that's entirely different to "you can't commit/upload if you're not in our gang"
<superm1> Keybuk, i think it would be fine to poke someone on the team saying how's this look, they say good, you upload it and post a merge url for them to pull it into bzr
<superm1> but i gather that's still not the model you're striving for
<ogra> isnt that what we have the "propose branch for merging" feature in LP for ?
<Keybuk> ogra: no
<Keybuk> propose branch for merging is for the exact opposite
<Keybuk> in the model we're aiming for, it's so people who can't commit can propose their branch for merging by someone who can
<Keybuk> superm1: ok, let's use my change as an example then
<Keybuk> superm1: I've proposed it for review
<Keybuk> now take a look at it and decide whether it's good or not
<Keybuk> you're almost certainly going to have absolutely no idea, because the person who knows that it's a good change is *me*
<superm1> Keybuk, haha "it's already uploaded, so your call"
<superm1> so my question would be what are the implications of this on earlier releases?  We regularly backport using the same packaging.
<superm1> and given there is a "Breaks: udev (<< 136-1)", that would mean these backports will break with that change
<Keybuk> correct
<superm1> so already right there I would have not been happy with it, and preferred the change be done in a way that maintains backportability rather than immediately uploaded
<superm1> since this same branch is used for the weekly automated fixes builds
<Keybuk> you can't ship a rule that works with the udev in intrepid and the udev in jaunty
<Keybuk> the udev versions aren't compatible
<superm1> well you can ship two rules then, and query what environment you're running on during the build process
<Keybuk> you're welcome to try that ;)
<superm1> er well two rules in the source package, and put the right one in the binary package - that's what i meant
<Keybuk> you'd have to put the right preinst too, etc.
<Keybuk> that's up to you to figure out ;)
<Keybuk> my concern is making sure that it works in jaunty
<Keybuk> which it does now
<Keybuk> if you're backporting to earlier releases, that's your problem ;)
<superm1> right it's functional for jaunty, but exactly why it's better for the team to have control over their main bzr branch, so there is shielding from problems like this coming up that the person who uploaded may have not forseen
<Keybuk> I disagree entirely
<Keybuk> having packages gated by the team is the very thing in Debian we designed the Ubuntu archive to *avoid*
<Keybuk> superm1: btw
<Keybuk> I'd like to talk to you about that rule anyway
<Keybuk> since it gives root access to mythtv
<Keybuk> I suspect kees would like to talk to you about it too ;)
<superm1> Keybuk, yeah once the new firewire stack is put in place, it can go away thankfully
<Keybuk> it's invalid *now*
 * kees reads backlog
<superm1> Keybuk, if new pieces are in place already, then just a matter of someone verifying functionality hasn't change without the rule there
<Keybuk> no, I mean arguably right now, installing mythtv is a massive security risk
<Keybuk> in intrepid, assumedly, as well
<kees> f'ing firewire.
<superm1> i can see the argument there.  it's either functionality or security in this case until the new stack is complete.
<Keybuk> superm1: yes
<Keybuk> but users aren't warned about it ;)
<slangasek> Keybuk: my civic duty is fulfilled for the moment, yes
<Keybuk> slangasek: if they call you up, but then don't actually select you, can they call you up again later?
<slangasek> Keybuk: in this case, yes; if you actually serve on a jury then you're ineligible to serve again for the next 12 months, but otherwise you can be called up again any time at random
<slangasek> calc: yeah, we could squeeze in an OOo respin if there's need
<calc> slangasek: i found out that its broken on KDE with the openoffice.org-kde package installed and I know how to fix it
<calc> slangasek: I'll get a new upload done right after meeting with Rick
<calc> slangasek: should be done ~ 2hr from now
<calc> er considering it takes 1hr to upload from my house :-\
<fta> <asac> fta: seems to not honour my .pastebinit.xml anymore <= works for me (tm). which version are you using? mine?
<fta> asac, oh, 0.11 is in universe, maybe a bug i fixed for stgraber that is missing.
<fta> stgraber, ^^
<slangasek> calc: right, sounds good
<fta> asac, stgraber: i remember now, i fixed that after 0.11 was closed, but before it entered debian, so my fixes are not in. we need 0.12 or 0.11.1
<LaserJock> if I want to drop several binary packages from a source package should I upload a new source that doesn't build them first and then file a bug for removal or the other way around?
<Keybuk> the former
<Keybuk> no need to file a bug for removal either
<Keybuk> the archive admins will notice
<slangasek> siretart: hmm, was your upload of emacs-snapshot 1:20081013-1 a fake-sync?  AFAICS, the package was removed from Debian at version 1:20070302-1 and never restored
<apw> slangasek, i have a couple of changes targeted against packages which pitti seems to own and he is away, we were hoping to get those changes into jaunty alpha-3 and i am wondering what the right way forward is as he is away
<slangasek> apw: I'm not aware of any packages that pitti owns exclusively - what are you looking at?
<slangasek> (i.e., what packages)
<apw> apport and pm-utils
<calc> cjwatson: ping
<calc> anyone happen to know why launchpad-integration (at least the command line version) broke recently?
<calc> if you run launchpad-integration -b -P openoffice.org for example it comes up with page not found error
<james_w> calc: launchpad bug
<james_w> calc: reload after a few seconds, they are working on the fix
<calc> ok
<calc> rickspencer3: ^ apparently its a timing issue with launchpad itself
<rickspencer3> hmmm
<rickspencer3> yah
<rickspencer3> I just reloaded the page, and there it is
<calc> it takes ~ 5-10s to work
<slangasek> apw: ah; apport at least should be in bzr, I don't know whether pm-utils is currently
<apw> yep, i made a branch off apport and pushed up the changes there, pm-utils didn't claim to be so i did a traditional debdiff for that one
<slangasek> apw: right - at that point you can use the standard sponsorship process to get them in (https://wiki.ubuntu.com/SponsorshipProcess), and I'm happy to have you escalate to me directly once the bugs are in place that I can reference
<apw> slangasek, ok thanks ... process is always the hardest piece to get right without wasting loads of peoples time; those at the top of the tree whos time is valuable
<calc> slangasek: uploading now
<Keybuk> TheMuso: err, so I was looking at speechd-up briefly
<Keybuk> I think your udev rule is wrong ;)
<cody-somerville> lmao
<kirkland> emgent: hey there ... your ubuntu top uploaders page isn't active any more?
<Keybuk> bug #316511
<ubottu> Launchpad bug 316511 in speechd-up "udev rule is almost certainly wrong" [Undecided,New] https://launchpad.net/bugs/316511
<emgent> kirkland: i'm thinking to put it in ubuntustat
<emgent> anyway yeah is up
<emgent> but i should fix some issue first to re-put up it
<kirkland> emgent: URL?
<kirkland> emgent: the old url's from your blog are broken
<cjwatson> calc: yep?
<emgent> kirkland: http://thc.emgent.org/utu/
<calc> cjwatson: oh i was going to ask you about the launchpad-integration issue but james_w told me it was due to launchpad bug
<kirkland> emgent: thanks
<emgent> kirkland: np, cron working now to update
<slangasek> LaserJock: ping
<LaserJock> slangasek: uh oh, what'd I do now?
<slangasek> LaserJock: the edubuntu seeds seem to be in a funny state; the edubuntu-desktop-kde seed, for instance, references "edubuntu-desktop-kde"?
<slangasek> I was going to try to update edubuntu-meta for alpha-3, but it failed miserably
<cjwatson> calc: *nod* ok
<LaserJock> slangasek: what did you need to update? I'm working on an upload now
<cjwatson> slangasek: what's wrong with that?
<slangasek> LaserJock: I was just going to refresh the package for seed changes
<cjwatson> it's normal for metapackage seeds to contain the metapackage
<slangasek> cjwatson: to have a metapackage include itself?
<slangasek> oh, is it?
<cjwatson> look at ubuntu.jaunty/desktop
<cjwatson> germinate-update-metapackage knows to exclude it
<slangasek> ok
<LaserJock> well, I had an issue with it
<slangasek> then I just didn't follow through far enough :)
<LaserJock> for edubuntu-desktop it's fine
<cjwatson> I suspect you're running into stuff that's intentionally in universe
<LaserJock> but when I ran germinate on edubuntu-desktop-kde it wanted to include it
<LaserJock> I was checking that before I uploaded to make sure I didn't screw something up
<LaserJock> I've really reworked the seeds so it's possible I missed something
<cjwatson> what's the actual error message?
<LaserJock> it wasn't an error
<LaserJock> it just added edubuntu-desktop-kde to the lists
<LaserJock> at least I didn't think there was a message, I can run it again to check
<LaserJock> cjwatson: how does it know to exclude them?
<cjwatson> see metapackage_name in germinate-update-metapackage
<apw> slangasek, i pasted the patches and pointers into the bug (bug #316419) and subscribed the bug to ubuntu-main-sponsors.  will see whoall responds.  thanks for you help
<ubottu> Launchpad bug 316419 in pm-utils "Changes to support suspend/hibernate/resume testing" [Medium,In progress] https://launchpad.net/bugs/316419
<slangasek> apw: great, thanks!
<cjwatson> LaserJock: why did you rename the seeds?
<cjwatson> that was sort of unhelpful :P
<LaserJock> cjwatson: I know I know
<LaserJock> I'm just trying to make it clear to contributors
<cjwatson> well, that's what broke it :)
<LaserJock> as I'm adding in 4 new seeds and trying to get edubuntu-desktop-kde going
<cjwatson> if you want to keep it that way, you can override the metapackage name handling by putting "Task-Metapackage: edubuntu-desktop-kde" in edubuntu.jaunty/edubuntu-desktop-kde
<cjwatson> and similar
<ScriptRipper> who can help me here with some .deb packaging for a multitarget pkg (debian and ubuntu)?
<LaserJock> oh, I think I see
<cjwatson> ScriptRipper: #ubuntu-motu is for mentoring
<LaserJock> cjwatson: so it looks for <distro>-<seed> for the metapackage name
<LaserJock> I was wondering why changing it to the exact name of the metapackage would cause problems
<LaserJock> but it's taking it as edubuntu-edubuntu-desktop-kde
<cjwatson> because now it wants edubuntu-edubuntu-desktop-kde :-)
<cjwatson> I'm always happy to offer advice in advance of complex seed changes ;-)
<LaserJock> well, the reason I did that was because we can't have a "desktop" seed
<cjwatson> yeah, that's why I had desktop-addon with Task-Metapackage: edubuntu-desktop
<LaserJock> right
<LaserJock> but for various reasons "addon" doesn't have much context anymore
<cjwatson> sure
<LaserJock> ok, so i think perhaps "Task-Metapackage: edubuntu-desktop-kde" might be the way to go
<LaserJock> as I really would like to keep things clear if I can
<cjwatson> yeah, probably best
<LaserJock> slangasek: ok, edubuntu-meta uploaded and sorry for the mess
<slangasek> n/p :)
<Keybuk> my god
<Keybuk> what is yada?!
<Keybuk> this thing should be *illegal*
<seb128> slangasek: there? did you read what I said before about evolution?
<slangasek> seb128: hi, yes - will get it a bit later this afternoon
<slangasek> Keybuk: haha
<seb128> slangasek: ok thanks, I was just making sure you were around this week to know if I should do a jaunty upload or wait for it to be accepted and pocket copied
<slangasek> seb128: yep - I'm here all week :)
<LaserJock> Keybuk: autogenerated debian/rules doesn't sound fun?
<Keybuk> auto-generated debian/anything is just wrong
<LaserJock> slangasek: I've just uploaded edubuntu-addon-meta as well, which drops 4 binaries (edubuntu-addon-* metapackages). Once those binaries are removed from the archive kpercentage will drop from NBS
<slangasek> ok
<LaserJock> Keybuk: you don't like seeing changelog.in and control.in files laying around?
<LaserJock> :-)
<cjwatson> Keybuk: yeah, most of Debian figured that out in about 2000 but there are still a few weirdos :)
<LaserJock> slangasek: just sort of a FYI
<slangasek> Keybuk: c'mon, you know you've always wanted to build your debian packages from a spec file
<cjwatson> LaserJock: yada is the one that has debian/packages
<lifeless> slangasek: its like autoconf.in.in
<cjwatson> and generates everything from that
<LaserJock> cjwatson: *everything*?
<slangasek> LaserJock: spec file
<cjwatson> pretty much
 * pochu apt-get sources it
<slangasek> why use a filesystem to structure your data when you can use an arbitrary text file format?
<Keybuk> slangasek: if you want to build your packages from a spec file, just build your packages from a spec file!
<cjwatson> certainly including control rules changelog
<Keybuk> nothing says you have to use dpkg-buildpackage
<slangasek> Keybuk: the archive admins says
<Keybuk> it's perfectly valid to build a deb using just dpkg-source -b after laying it out
<Keybuk> slangasek: debian/rules:
<Keybuk> build:
<Keybuk>   rpm...
<Keybuk> binary:
<LaserJock> cjwatson: oh dear Lord, that's awful
<Keybuk>   rpm...
 * slangasek grins
<slangasek> wow, somehow I thought it was more common knowledge just how evil yada was
<Keybuk> yada feels like package rape
<cjwatson> Keybuk: that's certainly valid, though I'd be petitioning $WORLD for a new maintainer if anyone tried it :)
<Keybuk> heh
<LaserJock> slangasek: I've heard people grumble about it but never actually looked up what it did
<Keybuk> update-maintainer doesn't work with yada ;)
 * Keybuk considers a bug
<slangasek> a bug to remove yada
<slangasek> ?
<Keybuk> yes
<Keybuk> how many things use it?
<Keybuk> and of those, do we CARE about any of them? :p
<slangasek> only the things that dexter maintains
<slangasek> and none of those in main, the ones he maintained that were in main got repackaged sanely by StevenK
<Mithrandir> libnss-db, but I think that's repackaged now.
<slangasek> yes, StevenK repackaged that one
<Keybuk> there really is a random smattering of things, isn't there
<calc> fsck someone broke librdf0-dev
<calc> which caused my simple couple line fix to FTBFS since librdf0-dev is no longer installable :(
 * calc goes to beat on librdf0-dev
<Keybuk> does anything create the plugdev group anymore?
<slangasek> is it still in user-setup?
<Keybuk> ./debian/user-setup-udeb.templates:Default: adm cdrom dialout lpadmin plugdev sambashare
<Keybuk>   * Add back plugdev.  It's needed to make mounting easier for shell users.
<Keybuk> evan_: ?
<evan_> I believe that was at the request of pitti, though I don't recall his exact reasoning
<Keybuk> unless I'm mistaken, there's nothing on the system owned by plugdev now
<evand> I have no objections to that change being reverted.
<Keybuk> 'plugdev' has to stay for static mountpoints created by the installer.
<Keybuk> is the only other comment I can find
<Keybuk> hmm
<Keybuk> can't see anything in IRC logs?
<Keybuk> there's only 5 hours between the upload removing it and the upload putting it back
<Keybuk> *shrug*
<Keybuk> remove it again ;)
<Keybuk> see who complains
<Keybuk> it was probably true at the time that udev still used it for things
<calc> apparently someone completely broke libmysqlclient*-dev installation
<calc> looks like missing conflicts maybe, but not certain
 * calc is making a clean chroot to see what happens
<calc> libmysqlclient-dev tries to overwrite files in libmysqlclient15-dev at minimum
<cjwatson> gar
<cjwatson> no
<cjwatson> keep plugdev
<Joe_CoT> cjwatson, still waiting on that moderator to approve my Asterisk in Main post :(
<cjwatson> partman-basicfilesystems sets up FAT and NTFS filesystems in /etc/fstab with gid=46 which is plugdev
<cjwatson> Joe_CoT: typical moderation delay may exceed a day. I'm not going to try to do it now since it's 10:30pm local
<cjwatson> Keybuk: ^-
<directhex> cjwatson, where are you, geographically?
<TheMuso> directhex: The UK.
<directhex> TheMuso, well, yes, i knew THAT bit, not many countries are on UTC+0
<asac> fta: thanks for clarifying ;)
<Laney> directhex: can we expect you to come bug jamming?
<directhex> Laney, hm?
<Laney> http://fridge.ubuntu.com/node/1775
<cjwatson> directhex: Cambridge
<directhex> eek, tabland
<calc> asac: ping
<asac> calc: ?
<calc> asac: mysql-dfsg-5.1 was uploaded a few days ago and appears to have taken over the libmysqlclient-dev package from mysql-dfsg-5.0 can that be promoted to main?
<directhex> cjwatson, if these OOM_DISABLE sshd patches actually work, i suspect it won't just be our dept looking to apply beer liberally. i've got tomorrow to investigate it
<calc> asac: it appears someone forgot what doing that would cause... :-\
<calc> asac: not only that but libmysqlclient15-dev is now a dummy package (in main no less) that depends on libmysqlcient-dev which is in universe
<mathiaz> calc: right - there are some issues with mysql 5.1 uploaded to universe. For now the plan is to keep 5.0 in main and leave 5.1 in universe.
<Keybuk> cjwatson: why don't you just use "users" ?
<Keybuk> otherwise we have a very bizarrely named group
<Keybuk> "plugdev" = "access NTFS/FAT filesystems set up by the installer"
<asac> zul: whats the idea about mysql -dev packages?
<asac> zul: see a few lines above
<calc> mathiaz: er do you plan on fixing 5.0 RSN? It is blocking OpenOffice.org builds
<mathiaz> calc: a new version of mysql 5.1 should be uploaded to universe to fix the issue.
<calc> mathiaz: it looks like a new 5.0 release has to be made too since the libmysqlclient15-dev package is now a dummy package?
<fta> asac, you can use pastebinit from my ppa, i bumped it, it has all the fixes.
<cjwatson> Keybuk: because nothing actually adds individual users to 'users'
<asac> fta: yeah. will give it a try ;)
<cjwatson> if you want to talk about bizarrely named groups ...
<asac> thanks
<Keybuk> cjwatson: nothing should add users to plugdev anymore though
<cjwatson> I can't help it that the rug got pulled out from under me :P
<cjwatson> users isn't appropriate, I'd be happy with something that is
<Keybuk> heh
<asac> mathiaz: can you take care that the -dev pacakge mess gets resolved ;)?
<Keybuk> my concern is that people keep filing bugs referring to plugdev
<Keybuk> because we still create it
<Keybuk> even if the group was renamed, I'd be happy
<Keybuk> it would stop a torrent of wrong bugs
<cjwatson> yes, I have no intention of changing base-passwd because before I can do that I need to implement debconf support
<mathiaz> asac: yop
<asac> mathiaz: cool ... so i can go to sleep soon :)
<cjwatson> otherwise everyone who has ever installed Ubuntu will get a non-debconf prompt when upgrading
<Keybuk> cjwatson: I thought we had debconf support now?
<cjwatson> no.
 * Keybuk is sure we had this discussion last time ;)
<cjwatson> it's been on my to-do list since 2004
<cjwatson> it's actually quite complicated
<cjwatson> anyway, I only really care about something the first user can access
<cjwatson> since I'm not sure plugdev was any better than that
<Keybuk> admin?
<cjwatson> s'pose that might work
<cjwatson> removing the old group from people's systems is still going to be very hard
<Keybuk> I don't really care overly about removing the old group
<Keybuk> but people justify bugs with "this is a new install and the group was still created"
<cjwatson> is there a way to say "this filesystem should be mountable by users at the console"?
<Keybuk> not with /sbin/mount itself
<cjwatson> also, I have grave reservations about Ubuntu's list of global static users and groups ever diverging from Debian's
<cjwatson> there is only one namespace there and it ain't big
<cjwatson> a removal itself might not be a problem, but I don't want it to set a precedent
<Keybuk> since many of our core system pieces are quite different from Debian's, we're surely always going to differ on such things as groups?
<cjwatson> we never have in terms of the global static users and groups until now
<cjwatson> plugdev was added to Debian in response to Ubuntu's need, essentially
<cjwatson> and then used in various places in Debian I think
<cjwatson> global static users/groups are very, very rarely needed. so I don't think that assertion holds at all
<Keybuk> well, no
<Keybuk> we're trying to phase out all of the groups that a user might need to be a member of
<cjwatson> there have been been fewer than 50 ever
<cjwatson> (of each)
<Keybuk> and use other means to do that authentication
<cjwatson> right, but I'm not going to go removing global static groups as the wind changes, sorry. We still have operator for goodness' sake :)
<cjwatson> IME, (a) there is value in continuity, (b) knee-jerk removals result in the need for knee-jerk readditions later
<cjwatson> I would be happy if we can get to the point where we no longer need to add the first user to plugdev
<cjwatson> and can document it as obsolete in Ubuntu
<Keybuk> we've removed things like scanner already ;)
<Keybuk> well, since the installer is the thing creating plugdev
<Keybuk> and the thing putting the first user into plugdev
<cjwatson> scanner was not a global static group
<Keybuk> and apparently the only thing still using plugdev ...
<cjwatson> no, the installer is not the thing creating plugdev
<cjwatson> base-passwd is the thing creating plugdev
<Keybuk> that's kinda blocking your own argument on yourself
<cjwatson> give me a better solution. admin strikes me as a poor solution, design-wise, since it's root-equivalent by definition
<Keybuk> I can't do that without knowing *why* you set that gid= in /etc/fstab
<cjwatson> read the changelogs and the bug references therein?
<cjwatson> surely when removing a feature it is appropriate to research it!
<cjwatson> partman-basicfilesystems is the package in question
<cjwatson>   * Mount FAT and NTFS with umask=007,gid=46 (static group plugdev), so that
<cjwatson>     users can easily be given privileges to read/write mounted Windows
<cjwatson>     filesystems, and so that the first user can do so automatically (closes:
<cjwatson>     Malone #8048, #25071).
<ubottu> Launchpad bug 8048 in partman-basicfilesystems "Existing mounted vfat partition is not writeable for non-root users" [Medium,Fix released] https://launchpad.net/bugs/8048
<ubottu> Launchpad bug 25071 in partman-basicfilesystems "More reasonable defaults for ntfs mounts during installation" [High,Fix released] https://launchpad.net/bugs/25071
<Keybuk> that sounds like a wrong change though
<cjwatson> those bugs have fairly extensive discussion
<Keybuk> certainly abusing plugdev
<cjwatson> those bugs have fairly extensive discussion
<Keybuk> plugdev was intended as a group to allow the console user to access removable devices
<cjwatson> you can't possibly have had time to read it in the gap between my posting that and you saying that
<Keybuk> my machine is behaving very strangely and I can't open any windows or tab away from this one
<cjwatson> Martin Pitt, the inventor of plugdev IIRC, suggested it as an option
 * Keybuk wouldn't have done that
<Keybuk> it merges privileges
<Keybuk> if everything that wanted "the user that installed the system" to have access to things, we may as well just have a group for that
<Keybuk> not "oh, we happen to have this random other group we use for something else, we could just use that group"
<Keybuk> still
<Keybuk> I'm clearly not going to persuade you
<cjwatson> you're not going to persuade me that you get to give me grief about something that was extensively discussed among our best security-oriented developers at the time, and appeared to be the least bad solution available, no
<cjwatson> I am entirely happy to drop in a better solution; I just don't feel that I have seen one yet
<cjwatson> and in the meantime I do not feel that we should deliberately break things
<Keybuk> I would rename the group to "windows" or something
<Keybuk> because that way, it will stop people repeatedly filing bugs because they read about plugdev somewhere
<cjwatson> we can't rename it without addressing the debconf problem
<cjwatson> and frankly that will just lead to a different set of bugs
<cjwatson> (renaming it to "windows")
<Keybuk> yes, it will lead to a set of bugs where users actually describe the problem they're having
<Keybuk> ;)
<cjwatson> I'm sorry that you get hard bugs. Join the club :-P
<Keybuk> they're usually fun
<Keybuk> "blah is not in the plugdev group."  "Correct -> invalid"
<cjwatson> seems like an appropriate response :)
<Keybuk> actually, I have a fun one where a guy keeps un-wont-fixing his bug that his iPod isn't in group floppy ;)
<cjwatson> I could adjust the base-passwd documentation in Ubuntu so that you have something "authoritative" to point to
<cjwatson> and to deconfuse anyone who looks there
<Keybuk> the udev docs are quite clear
<Keybuk> people would just file bugs on base-passwd to say the docs are wrong ;)
<cjwatson> the udev docs are hardly the authoritative source for the semantics of global static groups
<cjwatson> I am entirely happy to reject base-passwd bugs without needing to propose breaking udev ;-)
<Keybuk> they're the authorative source for the groups given to things in /dev
<cjwatson> yes
<Keybuk> and quite clear that no user should ever be put into one of those groups
<Keybuk> anyway
<Keybuk> I'm going to reboot this thing
<Keybuk> it did the same thing yesterday, then the problem mysteriously went away overnight
<Keybuk> and now it's doing it again
<Keybuk> silly thing
<Keybuk> cjwatson: on further thought, it would probably be nice to have a document about the system static groups explaining what they're for, and what uses them
<cjwatson> Keybuk: /usr/share/doc/base-passwd/users-and-groups.* is such a document (accuracy due to changing winds notwithstanding; happy to update it)
<cjwatson> Keybuk: btw, sorry for being snappy above - have screaming baby here and it's all a bit fraught :(
<cjwatson> I do strongly believe in stepwise improvement as you know, but needn't have been sarky about it
#ubuntu-devel 2009-01-13
<TheMuso> yay, new pulse released.
 * TheMuso will prepare, but will wait till after the alpha.
<TheMuso> Before uploading.
<stgraber> fta: yeah, I'll likely release 0.11.1 soon with the bug fixes, then sync again once it reaches Debian
<Keybuk> cjwatson: maybe we should work through that file at the sprint
<Keybuk> many of its assumptions are wrong these days
<Keybuk> ie. you don't need to be a member of cdrom, audio, etc. to have access to those anymore
 * Keybuk amuses at Lennart
<Keybuk> What a choice.
<Keybuk> Uh? You can ship both if you wish and pass the decision what to use to
<Keybuk> the user. I mean, that is the usual way Debian solves problems like
<Keybuk> this, isn't it?
 * RAOF tries to guess context.  Hm... pulseaudio+libcanberra?
<Keybuk> pulseaudio
<Keybuk> it's GNOME Module Inclusion week
<RAOF> Ah, of course. But why would we ship two pulseaudios?
<directhex> RAOF, because the farce of linux sound servers isn't QUITE complete
<RAOF> Heh.
<directhex> RAOF, just you wait for three versions of aRts and seven of ESD!
<pochu_> RAOF: it's about the gnome-volume-control panel applet
<pochu_> it's been rewritten for PA, and the discussion was about dropping the GstMixer version
<RAOF> Ah.  Right.  Yeah, the new mixer looks like it's knocked some of the edges off pulseaudio integration.
<RAOF> Why doesn't the applet detect a running pulse instance and change behaviour appropriately?  I thought that was an obvious requirement of such an applet.
<pochu_> it's not an applet anymore. Now it's a tray icon
<pochu_> http://mail.gnome.org/archives/desktop-devel-list/2009-January/msg00211.html would be the one
 * pochu_ is off to bed, g'night everyone
<RAOF> Oh, right.  I didn't notice the notification-applet/panel applet distinction.  Urgh.
 * Keybuk is utterly baffled
<Keybuk> this package clearly uses dh_installudev
<Keybuk> but I cannot see where it calls it from :-/
<Keybuk> ah, "dh binary-arch"
<ebroder> Is it reasonable to assume that buildd chroots have a kernel installed?
<TheMuso> ebroder: not afaik.
<TheMuso> The most you would need kernel wise are kernel headers.
<TheMuso> c
<ebroder> Is there some way I can build-depend on linux-image-$(uname -r)?
<RAOF> Why do you need to?  It's probably wrong. :)
<ebroder> I have a site package I'm working on that build-depends on multipath-tools. multipath-tools' preinst runs modprobe, which tries to read from /lib/modules/$(uname -r)/, which I don't have
<RAOF> Oooh.  Awkward.
<ebroder> Hmm...it was apparently introduced in an Ubuntu change
<toresbe> Hey, I've got a question out of personal curiosity. I'm currently dist-upgrading into jaunty, and I get this text in some of my upgrades...
<toresbe> Setting up adduser (3.110ubuntu2) ...
<toresbe> Xlib:  extension "RANDR" missing on display ":0.0".
<toresbe> Xlib:  extension "RANDR" missing on display ":0.0".
<toresbe> I thought it odd that this operation loaded xlib.
<TheMuso> ebroder: What version of ubuntu?
<TheMuso> ebroder: That really should be protected with a check I guess.
<RAOF> toresbe: That's strange.  Why would adduser/preinst/postinst be calling anything X related?
<ebroder> TheMuso: I'm using the version in Hardy. I don't know if it's still around
<RAOF> Hah!  That's why.
<RAOF> toresbe: Do you happen to have set your debconf frontend to something X-y?
<TheMuso> ebroder: Ok, I am not sure if its changed since.
<ebroder> One sec...I'll look
<toresbe> RAOF: Ahhh. Well, I'm taking the "update-manager -d" route; I suppose it's done it for me. That explains it, of course.
<RAOF> toresbe: Entirely possibly; it would probably want to present debconf questions with the gnome interface.
<toresbe> It does indeed, IIRC.
<ebroder> TheMuso: Looks like it's gotten wrapped in a useful check
<toresbe> RAOF: I just had a hunch that it might be some accidental invocation that devs would be interested in, but that makes perfect sense.
 * toresbe sods off. 
<RAOF> Hm.  Any X guys in here, who would like to make xserver-xorg-video-nouveau actually installable for Alpha 3?
<yao_ziyuan> ubuntu should use deja vu 10 as default font
<yao_ziyuan> like kubuntu.
<yao_ziyuan> it's much clearer
<TheMuso> RAOF: How is it uninstallable?
<RAOF> TheMuso: It needs the kernel modules before it'll do anything.
<TheMuso> RAOF: ah
<RAOF> So it depends on the linux-nouveau-modules virtual package, which is provided by nouveau-kernel-source, which has been on crimsun's review list forever. He's a busy man, so I'm advertising more widely :)
<TheMuso> RAOF: I guess that needs DKMSing.
<RAOF> It is.
<RAOF> It's all ready to go, and sitting on revu awaiting ack.
<TheMuso> Oh ok.
<mathiaz> I've been trying to sort out the libmysqlclien15-dev issue in jaunty. The mysql-dfsg-5.1 upload produced a transitional package libmysqlclient15-dev which depends on the libmysqlclient-dev package from 5.1 (which is libmysql16).
<mathiaz> since MySQL 5.1 is in universe, this breaks builds in main that depends on libmysqlclient15-dev.
<mathiaz> so my plan is to upload a new mysql-5.1 src package that won't build libmysqlclient15-dev anymore
<mathiaz> and upload a nochange pkg of mysql-5.0 so that libmysqlclient15-dev is again available in main.
<mathiaz> does this seem correct ^^?
<mathiaz> and should I wait for mysql-5.1 to have built and been published before uploading mysql-5.0?
<ScottK> mathiaz: What -dev package will mysql 5.1 provide then?
<mathiaz> ScottK: libmysqlclient16-dev
<ScottK> OK.
<mathiaz> after the upload there should be two binary packages (libmysqlclient15-dev from 5.0 in main and libmysqlclient16-dev from 5.1 in universe) both providing libmysqlclient-dev
<ScottK> Ah.
<mathiaz> according to apt-cache rdepends there are only one package that depends on libmysqlclient-dev: libgmyth-dev
<ScottK> vorian: ^^^^
<persia> TheMuso, Is there a bzr branch for jaunty pulse?  I see one for intrepid pulse, but wanted to submit a change for jaunty (Recommends: gnome-audio | ubuntu-sounds).
<ScottK> mathiaz: amarok 2.0 also.
<mathiaz> ScottK: is that already in the jaunty archive?
<ScottK> And that one wants 5.1, so it ought to be changed to libmysqlclient16-dev
<ScottK> mathiaz: Yes.
<ScottK> Uploaded earlier today.
<vorian> ohmy
<ScottK> There's work to do to trim down how much of mysql it drags in, but it's there.
<ScottK> vorian did it.  That's why I dragged him over here.
<mathiaz> did it build?
<ScottK> Yep and has lots of happy users.
<TheMuso> persia: Yes. I am currently preparing 0.9.14
<mathiaz> oh I see - it's in universe
<ScottK> yes.
<TheMuso> persia: And shoudln't that be the other way around?
<ScottK> For now ...
<TheMuso> persia: I can drop the change in if you like, what package needs that recommends?
<ScottK> mathiaz: That's part of the reason to try and strip it down, to see if we can get it in Main without dragging all of 5.1 with it.
<TheMuso> persia: I won't be uploading before the alpha freeze anyway, since its a biggish change that may rock the boat a little too much this far out from the alpha freeze.
<persia> TheMuso, pulseaudio-module-x11 needs to Recommend: gnome-audio | ubuntu-sounds.  It currently only recommends gnome-audio.  ubuntu-sounds has a conflict on gnome-audio.  This breaks image builds for things that want both pulseaudio-module-x11 and ubuntu-sounds if universe is enabled.
<TheMuso> persia: Ok. I'll make that change locally now, and it will go into the next upload, straight after alpha.
<persia> Well, breaks Alpha for me, as I can't construct images.  Mind if just this gets pushed earlier?
<mathiaz> ScottK: ok. But first we need to fix the archive. For now ooo doesn't build because of that.
<ScottK> mathiaz: Absolutely.
<TheMuso> persia: Sure, I can do that.
<persia> TheMuso, Thank you.
<mathiaz> so by uploading 5.1 that doesn't provide a libmysqlclient15-dev package and then reuploading 5.0, we should get back a correct libmysqlclient15-dev package.
<mathiaz> Do I need to use an epoch in the mysql-5.0 upload?
<ScottK> You don't want to do that.
<ScottK> Then we'd always have a higher version than Debian.
<mathiaz> ScottK: right.
<persia> Ubuntu-local epochs should be avoided at nearly any cost.
<ScottK> You'll need to do some version~realllyversion crap.
<ScottK> Yep.
<mathiaz> ScottK: right.
<TheMuso> persia: Done./
<persia> TheMuso, Thanks again.
<mathiaz> so the current version for libmysqlclient15-dev is 5.1.30-2ubuntu1
<TheMuso> persia: np
<mathiaz> and I need to get it to 5.0.75
<ScottK> 5.1.30really5.0.75-0ubuntu1 or convince Debian to do an epoch.
<mathiaz> so I'd have to upload mysql-dsfg-5.0_5.1.30-2ubuntu2~really5.0.75-1ubuntu2?
<ScottK> Not quite.
<ScottK> mysql-dsfg-5.0_5.1.30really5.0.75-0ubuntu1 will do it, I think, but I'm also tired and it's been a long day.
 * ScottK asks persia or TheMuso to consider it.
<mathiaz> mysql-dfsg-5.0 is already at 5.0.75-1ubuntu1
<ScottK> 5.1.30really5.0.75-0ubuntu1 is higher than that.
<mathiaz> ScottK: hm right. version is hight than revision.
<ScottK> You need to get a libmysqlclient15-dev version higher than you have now.
<persia> mathiaz, dpkg --compare-versions is your guide to success.
<mathiaz> hm - other option: considering that libmysqlclient15-dev has only been at 5.1.30-2ubuntu1 for a few days, could an upload of mysql-5.0_5.0.75-1ubuntu2 be possible? or soyuz wouldn't allow it?
<ScottK> Soyuz is like an elephant.  It never forgets.
<persia> mathiaz, Soyuz doesn't matter: consider that users may have downloaded the newer version, or mirrors, etc.
<ScottK> With that, I'm off to bed.
<ScottK> Good luck getting it sorted mathiaz.  These things are never pleasant.
<mathiaz> persia: right - OTOH it's only in the development version.
<persia> mathiaz, You just need to select some version that is greater than 5.1.30 yet accurately describes the state.  Appending really${real-version} is the common way to do this.
<persia> mathiaz, Doesn't matter: do you really want to go and make sure *every* mirror of jaunty, public and private, didn't break?
<persia> (Actually, just mirrors of Packages: including local apt-caches worldwide)
<mathiaz> persia: hm - I see your point.
<persia> mathiaz, That the archive software protects you by making sure you upload a safely newer version is a precious feature :)
<ScottK> Since 5.0 will always be < 5.1, my suggestion is do a really version for now and then nicely ask Debian mysql maintainers if they'll do an epoch.
<persia> Anyway, I fully support 5.1.30really5.0.75-0ubuntu1 as your best option.
<mathiaz> persia: yes. That's the best option (and only option) it seems.
<mathiaz> ScottK: persia: thanks for your input.
<ScottK> mathiaz: You're welcome.  Note that you'd need 5.0 and 5.1 on the same epoch ....
<mathiaz> ScottK: they're two different *source* packages.
<ScottK> mathiaz: Yes, but you want the libmysqlclient-dev package in 5.1 to have a higher version than the one in the 5.0 package.
<ScottK> If 5.0 is epoch'ed and the 5.1 is not, then it'll be backwards.
 * ScottK really goes to bed.
<persia> mathiaz, Do raise this issue with Debian: Debian's 5.1.30-2 also provides libmysqlclient15-dev, and so Debian may have reason to epoch.  Alternately, there may be some other solution planned that makes more sense.
<mathiaz> persia: right - Debian 5.1.30 provides libmysqlclient15-dev as a transitional package.
<mathiaz> persia: in 5.1.30 libmysqlclient-dev is the pkg that ships the dev files.
<persia> mathiaz, Right, so the key is to determine the details for the transition plan in Debian, and develop a solution that works there.  Either with an epoch, or something else.  Then we can inherit it.
<mathiaz> persia: in 4.1 and 5.0 libmysqlclient-dev was just a virtual package
<persia> There's more flexibility in Debian, because epochs are (slightly) less painful.
<mathiaz> persia: ok - how does that play with the fact that we need to fix Ubuntu ASAP?
<persia> mathiaz, Well, it depends.  My experience with Debian maintainers is that the majority are happy to share details of a plan, if you're planing to execute it: saves labor.
<mathiaz> persia: should we wait on the Debian discussion before doing anything in Ubuntu or should we proceed with fixing Ubuntu before alpha3?
<persia> If the Maintainer is especially slow, then maybe it's worth something else, but I suspect the solution is already documented, and just needs someone to chase it.
<mathiaz> persia: hm. I think I'll send an email to the Debian maintainer - he is usually very responsive.
<persia> mathiaz, Personally, I'd suggest trying to catch the MySQL maintainers on OFTC, and asking if they have time now.  If not, then explain the *really* plan, and ask if that won't break too much as a quick-fix while offering to help with the bigger transition.
<persia> email works too :)
<mathiaz> persia: ok - well. It's too late here. We'll discuss this during tomorrow's server team meeting.
<mathiaz> persia: thanks for your help and have a nice day!
<persia> mathiaz, Sleep well.
<calc> there appears to be too many people in my neighborhood with wifi now after christmas, i had to switch channels because there was too much interference between my laptop and my ap 2 feet away
<calc> i can see at least 19 AP from my desk
<LaserJock> calc: that's quite a few
<calc> LaserJock: yea, i might have to switch to N if it gets any worse, heh
<LaserJock> calc: any of them open APs?
<calc> i hope the nm-applet can scroll for small displays it almost takes up my whole 1280x800
<calc> 3 out of 19 appear to be open
<tritium> Hey there, LaserJock.
<LaserJock> tritium: holy cow dude, how are you?
<tritium> LaserJock: great, thanks.  How are you?  Done with school?
<LaserJock> ... almost
<LaserJock> :(
<LaserJock> getting there
<tritium> Good!  Hang in there.
<LaserJock> trying to weather the economy a bit
<LaserJock> academic jobs are going in the toliet
<tritium> Yeah?
<LaserJock> yeah, my state is really bad
<LaserJock> thank goodness I want to leave :-)
<tritium> Best of luck to you!
<LaserJock> we're looking at least 25% budget cuts
<LaserJock> tritium: you still at Sandia?
<tritium> LaserJock: yes
<siretart> asac: the sunbird package seems to be broken. I've built it on intrepid. when I start it the very first time I get an 'BadWindow (invalid Window parameter)' error, and subsequent calls report an XUL error (unknown entitiy). :(
<tritium> LaserJock: it's good to see you again.  I haven't spent much time in -devel or -motu lately.  Give me a /query one of these days, and we'll catch up.
<LaserJock> tritium: for sure
<tritium> Good night!
<siretart> asac: it seems the old locale packages break sunbird 0.9. A the package needs a break. I'll file a bug
<asac> siretart: bad window is strange ... but well ;). please subscribe me. otherwise it can take a while ;)
<dholbach> good morning
<ArneGoetje> cjwatson: we only need the language-pack-LL packages rebuilt, right? So, I change the version number to 1:8.04+20090105.1 ?
<cjwatson> Keybuk: users-and-groups> yeah, I think that would be a good idea
<cjwatson> ArneGoetje: right, or 20090113 if that's easier
<liw> mvo, I'm trying to upgrade a VM from intrepid to jaunty, using "do-release-upgrade -d", it fails telling me I have held packages that it wants to upgrade
<liw> mvo, could it tell me what?
<liw> mvo, and what's the state in "dpkg --get-selections '*'" output I should look for? "hold" does not occur, but there's a bunch marked as "deinstall"
<mvo> liw: yes, could you please put the log (/var/log/dist-upgrade/main.log somewhere)?
<mvo> liw: I will add a better error message
<ogra> james_w, aww, classmate-tools shuld probably just be dropped from the archive :)
<ogra> (it reiles on functionallity only i810 can provide)
<james_w> ogra: I wasn't sure, so I thought I would remove the NBS item first
<liw> mvo, http://files.liw.fi/temp/jauntu-upgrade-main.log
<james_w> you did have an alternative on -vesa :-)
<ogra> yes, but thats not doing what it did anymore either
<liw> mvo, so next I need to figure out what to do to get the upgrade working... suggestions? or is it too early to use do-release-upgrade and apt-get dist-upgrade would work better?
<soren> liw: --get-selections only shows hold, if you've manually, explitly put the packages on hold.
<soren> dpkg might hold back packages for other reasons (versioned package relationships, for instance)
<ogra> james_w, the prob is that panning isnt supported at all anymore by the xserver so it doesnt matter which driver you use, the Virtual directive will always define a virtual desktop you cant pan over (classmate-tools was a panning mechanism)
 * soren boards a plane
<soren> brb
<asac> zul: can you take a look at bug 286119 ... someone said that there are no new samba packages in the PPA?
<ubottu> Launchpad bug 286119 in samba "firefox 3.0.3 crashes (no SIG) on most pages w images: 8.10beta AMD64" [Unknown,In progress] https://launchpad.net/bugs/286119
<james_w> ogra: are you going to file for removal then?
<ogra> yes
<james_w> cool, thanks
<asac> ArneGoetje: can you look at the last comment of bug 288529?
<ubottu> Launchpad bug 288529 in firefox-3.0 "firefox, nautilus, transmission crash when using gtk file dialog" [Medium,Confirmed] https://launchpad.net/bugs/288529
<asac> what do you think?
<mvo> liw: hm, it seems to be a issue with your language-pack, could you upload the apt.log too?
<mvo> liw: it should be possible to do upgrade with the tool, but it will refuse to upgrade if e.g. translations must be removed during the upgrade
<mvo> liw: its a savety net feature, but this particular problem should be sorted for alpha-3
<ogra> Keybuk, your rpm upload looks like it was wasted time ... ftbfs on all arches (i know lool is having a fixed version anyway that will go to debian though)
<liw> mvo, http://files.liw.fi/temp/jauntu-upgrade-apt.log
<mvo> liw: it seems like openoffice.org-voikko is the culprit, let me check further
<DexterLB> hello
<DexterLB> I have a few questions about becoming an ubuntero. Can I ask them here?
 * mvo vaguely remember that caused trouble the last time around too
<liw> Mirv, voikko mentioned :)
<DexterLB> I want to activate a PPA
<DexterLB> but to do that I must sign the code of conduct
<DexterLB> but does signing the code of conduct add any obligations I must follow?
<liw> DexterLB, above and beyong the obligation of behaving like a decent human being? not really, but please read it throughly
<mvo> liw: yep, openoffice.org-voikko conflicts with openoffice.org-core (>= 2.4.1)
<DexterLB> i read it three times
<mvo> liw: is Mirv upstream for this?
<liw> mvo, Mirv is involved with that package, not sure if he's upstream, too
<liw> mvo, so if I remove -voikko, it should work?
<mvo> liw: yes
<liw> mvo, trying that
<mvo> liw: if you could report a bug that would be most appreciated too (if removing voikko works)
<mvo> liw: thanks
<cjwatson> I doubt you could be sued for a violation of the code of conduct. It's there to remind people of a minimum standard of civilised behaviour, and to provide a basis for cancelling accounts if people persistently violate it.
<cjwatson> (essentially)
<liw> interesting, removing openoffice.org-voikko restarted gdm
<liw> possibly because language-support-fi was also removed?
<mvo> liw: I think that is a language-pack thing
<ogra> cool ... so you dont need to use the iniscript :)
<ogra> *init
<cjwatson> StevenK: I've turned ubuntu-umpc back on in cdimage/crontab, since it was disabled without an explanation; I'm guessing that was due to the libavcodec51-induced build failure?
<cjwatson> StevenK: if it was you and you meant to disable it, please leave a comment explaining why
<ogra> wasnt it renamed yet ?
<Mirv> liw/mvo: I'm the maintainer in Debian, but not upstream. Since lenny isn't out, I haven't started packaging the new version of openoffice.org-voikko supporting OOo 3.0.
<Mirv> if lenny takes much longer, I probably should
<mvo> Mirv: how much work do you expect it to be? has a lot changed?
<cjwatson> ogra: doesn't seem to have been
<ogra> ah, well, StevenK's call ... but it should ...
<DexterLB> tralalalalalala lalala lalala tralalalalalala lalala lalala
<DexterLB> oops
<DexterLB> sorry
<DexterLB> "typing randomly to help gpg generate my openpgp key"
<Mirv> mvo: not too much, all changes have already been discussed since it's in fedora already, it's just that it requires libvoikko 2.0 as well so that has to be updated too
<Mirv> some careful tinkering and testing is all that should be needed
<liw> speaking of renamings... I'm beginning to lean towards "computer janitor" as the new name for system-cleaner / cruft remover
<StevenK> cjwatson: It was disabled since I'm working towards UNR, and ubuntu-umpc is gone. I have changes ready, I'm dealing with it.
<StevenK> cjwatson: If you'd like to sanity check my changes on antimony, feel free.
<cjwatson> StevenK: oh, ok
<BUGabundo_work> liw -1 on that name
<cjwatson> StevenK: go ahead and comment it back out and leave a comment
<StevenK> Now that my machine has released the 1.2GB that WoW took up, I'll disable it.
<liw> BUGabundo_work, why?
<StevenK> cjwatson: Done.
<cjwatson> StevenK: thanks
<BUGabundo_work> liw "janitor" bahh
<BUGabundo_work> I know I know, if I don't like, I should provide a better one
<BUGabundo_work> but even when you emailed the list, I couldn't think of a better one!
<liw> I don't have any bad connotations from "janitor"
<BUGabundo_work> maybe a poll on brainstorm
<BUGabundo_work> or in #ubuntu would give us the view from a NEW user
<liw> hmm, network access to my VM which is upgrading to jaunty has dropped
<liw> that's not a good thing
<BUGabundo_work> liw I guess you gona need a sudo dpkg --configure -a
<liw> network-manager got upgraded (at least partially), I wonder if that's what killed the network
<BUGabundo_work> liw it could! shouldn't ... /me blames asac :)
<asac> liw: yeah libnm-util1 was stuck in bin new
<asac> liw: not sure what parts were upgraded for you though
<asac> jsut libnm-glib0?
<liw> asac, I can give you dpkg.log :)
<asac> liw: no need to ;)
<BUGabundo_work> asac: so I SHOUDNT upgrate today?
<liw> asac, libnm-util0, libnm-glib0
<asac> BUGabundo_work: wait a few more hours
 * BUGabundo_work wispers : to late!
<BUGabundo_work> I guess that's why I have to reboot blue thingys on my jaunty
<asac> liw: libnm-util0 isnt in new package afaik
<asac> liw: which version did you get?
 * BUGabundo_work checking
<liw> asac, your version numbers are huge... libnm-util0 0.7~~svn220081018t105859-0ubuntu1 0.7~~svn20081018t105859-0ubuntu2 says dpkg.log
<liw> assuming I copied them correclty by hand
<asac> liw: thats old ;)
<siretart> lintian errors are fun: E: iceowl-dev: missing-dependency-on-libc needed by ./usr/lib/iceowl/obscure-tool and 6 others
<asac> liw: nothing i uploaded recently
<BUGabundo_work> I have svn 200081018
<liw> bah, and now the screen went highly colorful and then completely black, and I can't do nothing
<liw> possibly something like gdm got restarted
<BUGabundo_work> but it seems my network broke too, while I was out!
<asac> BUGabundo_work: yeah. thats the old version. not sure why liw upgraded just now to that old version that is there since November ;)
<BUGabundo_work> I guess its time to reboot... TWO warnings about it, should make me take it a bit more serious
<asac> 0.7-0ubuntu1 takes another few hours as rdepends have to catchup
<BUGabundo_work> lets see how it turns after reboot!
<liw> asac, hmm, unattended-upgrades doesn't seem to have kept the machine up to date
<BUGabundo_work> thinky of format and install today!
<asac> strange
<liw> asac, which is probably why the old package got upgraded
<asac> yeah
<BUGabundo_work> got a disk to make FULL backup
<asac> liw: the package you got doesnt have any known regressions over the ubuntu1 one
<BUGabundo_work> brb
<liw> oh dear, I haven't configured unattended-upgrades correctly
<liw> I need to figure out a way to make sure all my VMs are configured the right way, wrt u-a and mta etc
<liw> er, while upgrading the VM to current intrepid, apt wants to upgrade evolution-data-server-common and remove ekiga, and some evolution packages
<cjwatson> argh, X EDID probing loop *again*
 * cjwatson gets ready to shut world down for reboot
 * lool fastens his seatbelt
<ogra> do you exepct turbulences ?
<lool> Well when cjwatson shuts down the world I expect some yeah
<lool> But I should actually losen my belt as it's lunch time &
<ogra> just wait for the stewardess :)
<BUGabundo_work> back
<tjaalton> can someone explain why the lpia builder doesn't pull linux-libc-dev even though libc6-dev depends on it?
<mvo> liw: did you file a bug about the vokkio issue with the upgrade?
<Behnam> Hello
<Behnam> I'm looking for a package that would enable the function " gdk_x_error " for gdb
<liw> mvo, no, that slipped my mind, I'll do that now
<mvo> thanks liw
<Behnam> I'm using Ubuntu 8.10 and using " GNU gdb 6.8-debian "
<liw> mvo, #316754, please reassign to openoffice.org-voikko if you think that's more sensible
<liw> mvo, in other news: the machine still has no network and gdm kills the console (no reaction to mouse, keyboard, ctrl-alt-fX; screen is black), so today does not seem to be a good day to ugprade at all
<mvo> thanks liw
<mvo> liw: upgrade> sounds like good timing for alpha-3 ;)
<apw> does anyone know how PPA's decide which architectures to submit your source uploads to?
<ion_> Doesnât it submit âArchitecture: allâ packages to all of them? :-)
<StevenK> apw: i386, amd64 and lpia are the 3 arches that PPAs build for.
<apw> and do they do that weather your source builds there or not?
<cjwatson> if you need to restrict it, put "Architecture: <list of architectures>" in debian/control rather than "Architecture: any"
<cjwatson> they might build but will at least fail quickly
<cjwatson> and you shouldn't need to worry
<ScottK> ion_: No.  Arch all means one package works for all archs, so it's just built on i386.
<ion_> scottk: Sorry, brainfart.
<apw> for something going later to the main repo i assume i need to care
<ScottK> ion_: No trouble.  The arch all/any thing is not entirely intuitive.
<cjwatson> apw: not really. if it fails to build on an architecture it wasn't meant to build on anyway, then no big deal
<cjwatson> apw: we do have an override file that fine-tunes this stuff, but if you get the Architecture: line right in your source package, then the only effect of that override file will be to stop you getting a failed-to-build mail
<Keybuk> it's a shame that the Architecture file doesn't actually stop the buildd from trying it in the first place ;)
<apw> yeah a strange thing indeed
<apw> fair enough as long as it breaking and i don't have to care, is the norm i can cope with that
<maxb> The bit that stops buildds trying in the first place is the Packages-arch-specific file
<Keybuk> I never understood why Daniel just copied that bit of Debian, and didn't set out to improve it
<maxb> Which bit?
<maxb> I think part of the problem is that not enough information is propagated into the .dsc files / Sources files
<ScottK> Well currently it's 'improved' in that if any binary in a source package is listed not to build built for an arch, then the entire source package is skipped, so no binaries are built, but I suspect that's not the kind of improved Keybuk was thinking about.
<maxb> That's a bug outright
<maxb> But they're going to fix it
<ScottK> maxb: When?
<maxb> Well, I say that based on positive noises being made in the bug I filed. Don't think its milestoned, but its clearly being thought about
<ScottK> maxb: Well it's a regression that's been sitting there almost a month.
<ebroder> Once the buildds build a package, does it still have to be manually approved before it goes into the archive?
<maxb> I think it depends on whether it's a new binary package name or not
<ScottK> ebroder: The first time for a new binary package, yes.  After that, no.
<cjwatson> yes, the original problem is certainly that the .dsc file doesn't give the necessary information to the buildd system
<liw> ebroder, if it is a new source or binary package, yes; otherwise no
<ebroder> What about backports?
<ScottK> ebroder: If it's new to that release, then the binary still goes through New.
<ebroder> The pyyaml backport for Hardy seems to have been sitting in NEW for several days now
<cjwatson> ebroder: aside from the NEW thing people mention, that's never been necessary in Ubuntu; it's necessary in Debian because the buildd admins need to sign packages
<ScottK> ebroder: That's not unusual.
<ebroder> *shrug* Ok
<cjwatson> for us, the buildds are on trusted systems in order that that isn't necessary
<cjwatson> I've accepted pyyaml now
<ebroder> Haha. Awesome - thanks :)
 * ScottK waves some pyyaml at ebroder (I maintain it in Debian/Ubuntu).
<maxb> Though if the debian buildd admin can't trust the buildd system, how can they reasonably sign the binaries?
<cjwatson> maxb: wrong way round
<cjwatson> and I mean the central buildd dispatch system, not the individual buildds
<cjwatson> buildds need to upload packages to the archive, which needs to have some way to trust that they actually came from a genuine buildd
<maxb> oh, right
<cjwatson> in Debian, that's done by the buildd admin (a Debian developer) signing the .changes file
<cjwatson> in Ubuntu, the buildds have a trusted path to the archive
<ArneGoetje> cjwatson: uploading new hardy langpacks
<cjwatson> great, thanks
 * liw has running jaunty VM (without graphics, though)
 * liw is happy
<BUGabundo_work> liw even on a native machine you wouldn't have 3D
<ArneGoetje> cjwatson: langpack upload finished.
<BUGabundo_work> is anyone from bug 202512 here?
<ubottu> Launchpad bug 202512 in partimage-ng "Make it possible to mount image files." [Undecided,New] https://launchpad.net/bugs/202512
 * apw wonders if any sponsors have a moment to look over something (pm-utils and apport changes) we wanted to get into alpha-3, on bug #316419
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/316419/+text)
<Keybuk> kirkland: though I would like to continue that conversation ;)
 * apw slaps ubottu
<BUGabundo_work> apw: it seems the bot is a bit slow
<kirkland> Keybuk: sure thing, now, or when you're less occupied?
<BUGabundo_work> or LP may be the cause
<Keybuk> now is fine
<apw> probabally the translations or something eating launchpad
<Keybuk> I'm not sure what your feeling is
<kirkland> Keybuk: sure
<Keybuk> but from my POV, I think we should
<Keybuk> where there's an LSB init header, make sure that it's correct for Ubuntu
<Keybuk> where there isn't an LSB init header, but we change the install priority anyway, add one and suggest Debian do the same?
<Keybuk> where there isn't an LSB init header, and we don't touch it, leave it and file a bug on Debian asking for one?
<kirkland> Keybuk: the first part I absolutely agree with ... if an LSB init header is there, it should be correct.  that's really annoying when that's out of step with reality
<Keybuk> the second one is based on update-rc.d actually processing init script headers now
<kirkland> Keybuk: remind me of the value of the LSB init header to you... this is what upstart processes for backward compat, right?
<Keybuk> not currently
<Keybuk> right now, Upstart just runs the old sysv-rc script
<Keybuk> *but* if we could process init script headers, things would be much better!
<Keybuk> we could have a simple shim that registers all init scripts with headers as Upstart jobs directly
<kirkland> Keybuk: okay, so looking forward, that would be valuable information for us
<Keybuk> (#2 I'm thinking where we change a script from defaults to something else - we could leave it as defaults, and add the LSB header, and update-rc.d does the right thing)
<Keybuk> yes
<kirkland> Keybuk: and why is it more valuable to have this in each script, and writing all that info to a simple database (flat file, or some such, one line per init script, multiple elements per line)
<kirkland> Keybuk: seems that would provide a cleaner "view" of your current system
<Keybuk> err?
<Keybuk> well, the reason it seems to be valuable to add the init headers is that they're an LSB standard and Debian appears to be embracing them
<kirkland> Keybuk: (note that I've never given this deep though until now)
<kirkland> Keybuk: ah, okay.  "standard".  that's fine, i won't argue with that
<kirkland> Keybuk: okay, could dh_installinit be enhanced to generate/update the header?
<Keybuk> that's an interesting question
<kirkland> Keybuk: what bothers me most is the duplication of information
<Keybuk> well
<kirkland> Keybuk: when you want to change one thing, having to remember to change it in multiple places
<Keybuk> the way it's supposed to work is that you *don't* give any arguments to dh_installinit
<Keybuk> instead you have the LSB header
<kirkland> Keybuk: that's mostly how they get out of sync, I would guess
<kirkland> Keybuk: righto
<Keybuk> if you don't give arguments, it will default to using the LSB header
<kirkland> Keybuk: that part makes sens
<Keybuk> so ideally no rules should give arguments to installinit, and instead they should all have headers
<Keybuk> that should be easy for Debian to accept
<kirkland> Keybuk: in what cases would we prefer provides args to dh_installint, versus editing the header properly
<kirkland> Keybuk: i like your last suggestion;  that would probably benefit from a lintian check
<Keybuk> I don't think there any situations where we should prefer arguments to dh_installinit
<kirkland> Keybuk: W: dh_installinit-should-not-have-arguments: You should update the init script header according to the LSB specification
<Keybuk> if there are arguments present, and we are changing them
<Keybuk> I think it would be better to give Debian a patch to add an LSB header matching their arguments - and take them away
<Keybuk> then patch the init script in Ubuntu to change the LSB header
<Keybuk> update-rc.d also now complains if the init script has no LSB header
<Keybuk> so a lintian double-whammy seems good to me ;)
<kirkland> that sounds good
<Keybuk> (some dh_installinit arguments like --name are ok)
<kirkland> Keybuk: sure, the biggie are the ordering numbers
<Keybuk> also, selfishly
<Keybuk> if LSB init script headers are nicely standard
<Keybuk> upstream will ship them
<Keybuk> likewise if Upstart jobs are nicely standard
<Keybuk> upstream will ship them
<Keybuk> so it makes our diff-to-upstream less ;)  we just remove Debian patches to things
<kirkland> Keybuk: right so the "standard" I'm going for with the status stuff would be *really* uniform, nice looking output to "service --status-all"
<Keybuk> I'm hoping we'll start to see that with udev now; Ubuntu, RedHat/Fedora, SuSE and Gentoo all now share a common /lib/udev/rules.d directory with no local changes
<kirkland> Keybuk: you can run that on an intrepid+ system, and see what services have status actions, and which don't
<Keybuk> so upstream projects should start shipping udev rules by default, installing to the correct machine, etc.
<kirkland> Keybuk: nice
<ion_> Neat
<Keybuk> of course, Debian refuses to join the club
<ion_> Hehe
<Keybuk> but that's ok, we just delete things from the Debian package - and fallback to upstream behaviour ;)
<Nicke> <x
<Nicke> oops
<Riddell> zul: mysql 5.1 contains libmysqlclient15-dev
<Riddell> zul: but mysql 5.0 also has that package
<Riddell> and 5.0 is the one in main
<zul> Riddell: yeah will be fixed today
<Riddell> thanks
<ScottK> Riddell: mathiaz and I discussed it last night.
<Riddell> I'm sure I double checked that when I approved the package
<ScottK> IIRC mysql-server or something similar is also a problem.
<mathiaz> Riddell: I'll upload mysql-dfsg-5.0_5.1.30really5.0.75
<mathiaz> Riddell: and mysql-dfsg-5.1 that doesn't build libmysqlclient15-dev.
<mathiaz> Riddell: we'll discuss it in today's ubuntu-server meeting.
<Riddell> mathiaz: why is the funny version needed?
<ScottK> mathiaz: I think mysql-server too.
<Riddell> oh, because the binary version is too large
<calc> mathiaz: why the weird version number for 5.0.75 its still 5.0.75 in the archive currently?
<mathiaz> Riddell: because currently libmysqlclient15-dev is at 5.1.30-2ubuntu1
<calc> oh i see
<Riddell> yeah
<mathiaz> Riddell: either we use *really* or an epoch.
<calc> yea the sooner that is fixed the better OOo still needs rebuilding in time for alpha3 :)
<Joe_CoT> So, does anyone feel like being really nice and going through ubuntu-devel's moderated posts? :)
<cjwatson> in progress
<Joe_CoT> thanks
<cjwatson> Joe_CoT: in future, please do not crosspost between -devel and -devel-discuss
<cjwatson> Joe_CoT: crossposting between moderated and unmoderated lists produces very confusing results
<cjwatson> particularly when those lists have similar purposes, save for the moderation bit
<Joe_CoT> ok, i'll keep it in mind
<arthur-> doko: there is a fix in Debian's glibc for BZ 9706, you maybe want to sync with it (it's any/local-nss-overflow.diff)
<Keybuk> kirkland: randomly, do you think it would be worth a lintian warning for installing udev rules into the wrong place?
<kirkland> Keybuk: not that I'm any authority on the matter, but I generally take lintian warnings pretty serious and find them helpful
<Keybuk> we don't seem to have any patches to lintian right now though?
<kirkland> Keybuk: right, i'd definitely that's best to push up through Debian
<kirkland> Keybuk: i mean, we could carry it, but should be working lintian checks back upstream
<Keybuk> the trouble is, Debian have a different policy
<ScottK> lintian has a pretty decent idea of if an upload is aimed at Debian or Ubuntu, so distro specific tests are quite possible
<Keybuk> how hard would it be to add an ubuntu-specific test that no package should ship a *.rules file under /etc/udev ?
<ScottK> I'd guess not very.
<Turl> hello, can you take a look at bug #285417?
<ubottu> Launchpad bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed] https://launchpad.net/bugs/285417
 * Keybuk can't see how it knows it's going for ubuntu
<ScottK> Keybuk: http://launchpadlibrarian.net/19797997/lintian_2.0.0_2.0.0ubuntu1.diff.gz touches where it checks for the bad distro name (which is where is knows)
<Keybuk> no
<Keybuk> that checks debian/changelog
<Keybuk> which means the lintian check would not happen for packages sync'd from Debian
<ScottK> It may be that I was off my  rocker then.
<Keybuk> this needs to happen for those too
<ScottK> Upon further reflection, I think I was thinking about something in debchange, not lintian.  Sorry for the bother.
<kirkland> Keybuk: it might be reasonable to modify Ubuntu's lintian to know that it's Ubuntu's lintian :-)
<kirkland> lintuntu
<ScottK> Currently there is no "Ubuntu's Lintian", which is a good thing.
<LaserJock> it's a good thing ... until it's not :-)
<Keybuk> scottK: but Ubuntu policy differs from Debian's
<ScottK> Keybuk: True, so it'd be useful to have lintian understand the differences and which distro was targetted.
<ScottK> The Debian Lintian maintainers, at least from the outside, seem open to Ubuntu specific requirements in the Debian package.
<ScottK> Doesn't mean we need two Lintians.
<cjwatson> send mail to debian-lint-maint@lists.debian.org - I'm quite sure they'd be happy to discuss it
<NCommander> doko, ping
<Notch-1> hi all
<Notch-1> i have a "little" problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/292159
<ubottu> Ubuntu bug 292159 in linux "MASTER update-initramfs is disabled since running on a live CD but it is running from a flash drive. " [Low,Triaged]
<cjwatson> well, that certainly ain't a linux bug
<cjwatson> oh, hm, well, the fact that it fails to configure is
<Notch-1> ?
<cjwatson> never mind me
<Notch-1> ah ok :D but if you have something to say i'Ã¬m sure can help...
<cjwatson> evand: should USB sticks permit update-initramfs or not?
<cjwatson> that's sort of separate from the fact that the kernel upgrade process fails with that stub in place
<evand> I think they should
<cjwatson> which is an interesting and somewhat difficult point, though
<cjwatson> because if you don't run update-initramfs, you haven't really completed the kernel upgrade, and arguably it *should* fail
<evand> indeed
<cjwatson> does anything further need to be done in order to get an upgraded USB stick to boot the new kernel, though?
<cjwatson> I mean, something would need to copy the kernel and initramfs out to the wrapper filesystem
<Notch-1> yes
<Notch-1> but that's not the problem, the problem is that the update fails, even if can successfully complete the update-initramfs...
<evand> Perhaps we could try to remount /cdrom rw and attempt to write out the new kernel, should we detect that we're running from a live CD?
<Notch-1> is that a problem? i would be very happy to copy by hand the kernel and the initrd...
<cjwatson> Notch-1: it's the problem because we need to fix that in order that we can make the update succeed with a good conscience
<cjwatson> Notch-1: I understand the bug report, I'm just thinking beyond the immediate problem
<NCommander> kees, ping?
<cjwatson> evand: I think it would have to be something like that
<cjwatson> pretty horrible, but
<cjwatson> evand: moved over to casper and assigned to you
<Notch-1> thank you for the explaination cjwatson, i'll take care of the file substitution issue if you help me convince the developer to take a look and fix the update problem :PP
<cjwatson> Notch-1: evand and I are the relevant developers :-P
<evand> cjwatson: thanks, I'll give it a shot tonight
<Notch-1> cjwatson: thanks a lot :D
<cjwatson> Notch-1: you might know to copy the kernel and initrd by hand, particularly after having it explained to you, but an arbitrary user wouldn't know this and would be rather surprised to find that their USB stick refused to boot after an update
<cjwatson> Notch-1: I think that's *worse* than an update failing
<cjwatson> so I don't want to "fix" the problem only to cause something worse
<Notch-1> yes yes, i was meaning that i'll take care of fix this part of the problem, if you solve the rest for me
<cjwatson> Notch-1: which part of the problem?
<Notch-1> the correct generation of the initrd ad the update failure
<cjwatson> Notch-1: I'm not sure why we would solve half the problem and leave the rest to users :)
<cjwatson> correct generation of the initrd is absolutely trivial to fix at the same time
<Notch-1> i'm not telling this :P
<cjwatson> indeed, it would be difficult to solve the real problem without fixing that
<cjwatson> thanks for your offer, but I think we should be able to take care of the whole thing
<Notch-1> jus trying to ease your work as i can
<cjwatson> evand: we should have a think about how update-initramfs should work on a live CD too
<evand> cjwatson: hrm, good point.  Noted.
<Notch-1> so another question, are you guys Matt Zimmerman, Tollef Fog Heen or marco amadori? just curiosity...
<cjwatson> evand: there's clearly no point in regenerating the initramfs there, but perhaps we should arrange for it not to fail updates in this way, since you're unlikely to be able to break live CD boot by means of an upgrade
<cjwatson> Notch-1: use the /whois command in your IRC client
<evand> right
<cjwatson> Notch-1: also, the X problem you noted in a comment on that bug has nothing to do with the original bug report, and I recommend that you file it separately
<Notch-1> you mean the repeated crashes?
<cjwatson> yes
<Notch-1> installing intrepid to hd ad upgrading it seems to work fine, i think it's already solved
<Notch-1> it crashed just every couple hours, or when i play a video with vlc :D
<Notch-1> only with livecd version it's very unstable...
<Notch-1> btw i'm using kopete on debian etch so whis does not work very well :P
<cjwatson> if you have an inadequate IRC client, you could use a better one - whois or equivalent is a pretty standard feature :-) It may be implemented in some other way, e.g. right-click and "user info" or something like that (I've never used kopete)
<calc> kopete is an IM client which probably isn't very well suited for IRC
<bluefoxicy> <@bast> utf8test is Ã¦ Ã¾ Ã¢ Ã§ Ã Â£ Ã¶ Âª Ã° Ãµ Â¡ Â¿ Ã© Ã å­ âº â¥ âª â° â½ â« â
<Notch-1> yes i'm just trying to switch to kubuntu to solve problems like this :D
<Notch-1> anyway i was asking who you are because i read somewere that the maintainers of live-initramfs package decided to "let casper project die" in order to use live-initramfs... what can you tell me about this?
<bluefoxicy>  âª --> â° <-- the heck is this? 2C1D? ... â½ â« â
<Notch-1> calc: yes it's very badly implemented, i read very hostile comment on the project page.. and the kde4 version does not jet support irc, they still have to port it...
<stdin> that's the hex representation of that character 0x2c1d
<bluefoxicy> yeah, but it doesn't show in xchat-gnome, utf8 broked.
<cjwatson> Notch-1: there was a period when casper was not very actively maintained in Ubuntu for various reasons; the people who dealt with casper in Debian had trouble getting through to us and therefore decided to fork
<ion_> Nah, you just donât have a font with the character.
<Notch-1> cjwatson: whis function IS implemented in my version of kopete, but simply works 1 out of 10 times :D
<cjwatson> Notch-1: we're getting back on top of things in Ubuntu now, and the casper project is most definitely not dead, but the live-initramfs fork has happened now and they are fairly determined to bad-mouth us
<cjwatson> (as far as I can tell)
<cjwatson> I would rather focus on improving casper than engage in a war of words
<Notch-1> sure :D
<Notch-1> i'm happy to ear this
<cjwatson> and frankly, I prefer casper as a name to the rather dry "live-initramfs" name :)
<Notch-1> so let's do this :D how can i help?
<cjwatson> submit patches for open bugs
<cjwatson> figure out where open bugs are actually due to some other package and not casper (this is common)
<cjwatson> improve debugging documentation
<cjwatson> figure out where we can correctly resynchronise casper with improvements made in live-initramfs
<Notch-1> i think i can only do the third, but what else do you need ?
<cjwatson> that's basically it
<cjwatson> oh, testing of new changes obviously although since it's used on Ubuntu live CDs we're doing OK on that
<cjwatson> but honestly, it's pretty hard work which is why it's taken a while
<Notch-1> testing it's my second name :D
<cjwatson> do please file clear, separated bug reports about separate issues, though
<cjwatson> conflating multiple problems into a single bug report just makes things harder
<NCommander> kees, when you get a chance: https://bugs.edge.launchpad.net/ubuntu/+source/shadow/+bug/316841
<Notch-1> sure
<ubottu> Ubuntu bug 316841 in shadow "Freescale MX series needs new ports added to securetty.linux" [Medium,Triaged]
<Notch-1> you think is this the case?
<cjwatson> is what the case?
<Notch-1> this bug
<cjwatson> your comment on it was certainly a different issue
<cjwatson> too many of those and it really does get rather hard to untangle
<Notch-1> can we split this bug to a more specific reports?
<cjwatson> you can file your comment separately.
<cjwatson> as I asked
<cjwatson> it probably belongs on X
<cjwatson> I mean https://bugs.launchpad.net/ubuntu/+source/casper/+bug/292159/comments/21, not the earlier one
<ubottu> Ubuntu bug 292159 in casper "MASTER update-initramfs is disabled since running on a live CD but it is running from a flash drive. " [High,Triaged]
<Notch-1> yes but as i told you i think this one was already solved... i have some crashes even with uptodate version, but it seems very different so...
<cjwatson> surely it is not solved if it is happening with a current live CD
<cjwatson> just because you can't reproduce it by installing the system in a different way doesn't mean it doesn't exist, does it?
<Notch-1> current livecd does not means NOTuptodate versions of all ?
<cjwatson> I mean http://cdimage.ubuntu.com/daily-live/current/jaunty-desktop-i386.iso
<Notch-1> ahhhhhhhh but i'm using intrepid :D
<Notch-1> i should try :P
<calc> cjwatson: sorry to interrupt but does the jaunty ext4 support defragging yet?
 * calc has noticed some severe performance issues on his systems due to fragmentation and may switch over to that if it is er 'reliable' in jaunty timeframe
<slangasek> oh geez, why have the ISOs gone OMGOversized the day of the milestone freeze?
<calc> 795MB for i386, but not oversized on amd64, seems a little strange
<cjwatson> calc: I don't think it has online defragmentation, but I was just dealing with integration and am not an expert in the filesystem itself
<calc> cjwatson: ok
<cjwatson> ext4.wiki.kernel.org is probably the place to look
<kees> NCommander: looking
<cjwatson> it seems to think that online defragmentation is planned for ext3 as well, FWIW
<cjwatson> http://marc.info/?l=linux-fsdevel&m=116160640814410&w=2
<cjwatson> hmm, that's from 2006
<kees> NCommander: do you think that patch is valid for Debian too?
<NCommander> kees, if Debian wants to support these boards, yes
<slangasek> calc: because something pulled java onto the i386 image.  Was it you? :-)
<calc> slangasek: uh i hope not
 * NCommander thought OOo3 was still FTBFS
<slangasek> java *and* fortran
<calc> slangasek: this was the cycle that OOo went from 2.4.1 to 3.0.1 though
<NCommander> That's impressive
<NCommander> I didn't even know fortan was in main
<slangasek> calc: this is a change just in the past 24h
<kees> NCommander: can you open a Debian bug report for it too?  I'll upload your debdiff now, but it'd be nice to get that into Debian if they want it.
<NCommander> kees, sure, although I don't expect it to move anytime soon
 * NCommander checks who debootstrap's maintainer in Debian is
<cjwatson> debian-boot inc. me
<cjwatson> what's the problem?
<NCommander> cjwatson, --foreign is fairly broken
<cjwatson> not something I've often looked at
<NCommander> cjwatson, two stage problem, 1. it doesn't set permissions correctly to allow boot into a foreign chroot
<NCommander> (init doesn't end up +x)
<NCommander> 2. the second stage script is completely broken
<cjwatson> can you give me a quick recipe to reproduce it, to save me time?
<calc> slangasek: is there a way to tell easily who pulled in java?
<calc> slangasek: i can make a chroot and test its not OOo but not sure how to easily do it otherwise
<Notch-1> excuse me http://cdimage.ubuntu.com/daily-live/current/jaunty-desktop-i386.iso is newer than the alpha 2 ?
<slangasek> erm.  surely the correct perms on init should be shipped in the .deb?  How does --foreign screw that up?
<cjwatson> Notch-1: yes, it's a daily build
<NCommander> cjwatson, debootstrap --foreign --arch i386 should work. You can't boot the resulting chroot, and chrooting into it, and trying to run the second stage script dies
<cjwatson> slangasek: that's what I was thinking ...
<slangasek> calc: I'm working through testing here
<calc> slangasek: since OOo is such a beast just eyeing its depends/recommends can be hard to figure out ;-)
<cjwatson> Notch-1: alpha 2 is possibly more likely to actually work; daily builds are largely untested and can break for arbitrary reasons at any time
<NCommander> slangasek, no idea, but I just know I don't get a bootable chroot, I'm looking more indepth at the problem now, since I need to make jaunty's userland be happy and smiling for ARM
<slangasek> calc: best test case is apt, a wedge, and a hammer
<cjwatson> $ sudo debootstrap --foreign --arch i386 jaunty ncommander-test http://riva/ubuntu
<cjwatson> $ ls -l ncommander-test/sbin/init
<cjwatson> -rwxr-xr-x 1 root root 104364 2008-09-30 00:52 ncommander-test/sbin/init
<NCommander> Strange
<slangasek> (i.e.: set up a chroot; reproduce the apt install line from the installer, confirming that it installs the stuff you don't want; specify a package to exclude by appending "$package-"; see what complains; iterate)
<NCommander> Maybe it was a umask issue here
<cjwatson> NCommander: noexec filesystem?
<NCommander> however, that chroot will be unbootable *has tried a few times to do so*
<slangasek> dpkg doesn't honor umask
<calc> slangasek: ok
<cjwatson> (though debootstrap is supposed to check for that)
<NCommander> cjwatson, eh, dunno, I'm investigating
<slangasek> and noexec doesn't prevent perms from being set, just prevents the files from being executed afterwards
<cjwatson> yes
<cjwatson> I'm happy to try to help but will need a better bug report :)
<Notch-1> cjwatson: thanks, so i'll try both...
<NCommander> cjwatson, can you try the second stage install script
 * NCommander would like to get a bug out of this conversation
<cjwatson> I can reproduce second-stage failure
<NCommander> cjwatson, chroot into the new chroot, then run debootstrap/debootstrap
<cjwatson> W: Failure trying to run: chroot / dpkg --force-depends --install
<NCommander> yeah
<cjwatson> you need to run /debootstrap/debootstrap --second-stage, for the record
<slangasek> calc: openoffice.org-calc Depends: lp-solve?
<NCommander> cjwatson, would be nice if that was documented somewhere ;-)
<NCommander> although the impression I got was you just run that script to finish the setup
<calc> slangasek: yes, but that doesn't appear to be pulling in java
<calc> slangasek: still looking for why java is getting pulled in
<slangasek> calc: no, but it's one of the things that's changed that's pulling in new deps
<cjwatson> was documented in the first web page I found when googling for "debootstrap foreign" ;-)
<mathiaz> slangasek: I've just uploaded two new versions of mysql-dfsg-{5.0,5.1} to fix the libmysqlclient15-dev package
<NCommander> :-P
<cjwatson> but yes, I'll document it
<NCommander> cjwatson, what that output you got from using --second-stage?
<cjwatson> NCommander: I quoted it above
<mathiaz> calc: that should fix the ooo build failure you mentionned today.
<calc> something in the OOo stack of depends seems to be pulling in the java but i can't find what
<calc> mathiaz: thanks
<mathiaz> calc: (or yesterday)
<NCommander> cjwatson, just noting, it generates the same error if you omit second-stage
<NCommander> cjwatson, does this mean I can file a bug now?
<cjwatson> NCommander: BTW, look at the manual page for --foreign and read it in context; I don't think it's *that* undocumented, but will clarify
<NCommander> fair enough
 * NCommander is still trying to figure out if there is a bug, or user error here
<cjwatson> NCommander: feel free to file one about the second stage not working, but the other problem should be separate if it's a bug at all
<slangasek> calc: -core also has a new dependency on librdf0, which pulls in a *lot* of recommends
<NCommander> cjwatson, i'll kick one into Debian, and then create an assiocated one in ubuntu since they have to be merged anyway
<kees> slangasek: oh, are we frozen?  can I upload NCommander's securetty patch, or should I wait until Thu?
<slangasek> calc: and also libmysqlclient15off and libpq5 as deps
<NCommander> kees, I didn't think we entered freeze yet.
<slangasek> kees: I'm not sure if we're frozen, or just vapor locked due to the CDs having suddenly exploded
<kees> hah
<calc> slangasek: librdf0 here pulls in 740KB of stuff?
<kees> slangasek: so... upload?
<slangasek> calc: and you think we had .7 MB to spare?
<slangasek> kees: what's this "securetty patch"?
<calc> gah i found the issue
<calc> slangasek: perhaps we should just remove OOo from the cd entirely its continuing to grow as time progresses and we have been at the limit on the cd for several years at least?
<calc> ure has a recommends on java2-runtime
<cjwatson> I don't think removing OOo from the CD is going to be acceptable either
<calc> java is very intertwined in OOo since Sun is upstream and it is just getting more that way as time goes on
<NCommander> calc, there has to be a way to sheer some fat off OOo
<calc> NCommander: yes fork it ;-)
<NCommander> I was thinking diet but ...
<NCommander> :-P
<slangasek> removing it from the CD is going to leave us with a liveCD that doesn't let you work on any documents unless you use google docs
<calc> NCommander: well we have in the past been making sure it doesn't actually install java but that breaks various bits of OOo and it seems to be increasing the amount it breaks as time goes on
<kees> slangasek: http://launchpadlibrarian.net/21172354/shadow.debdiff
<calc> slangasek: is there a way to tell how much just the java2-runtime takes on the cd?
<kees> NCommander: btw, you might want to change your DEBEMAIL to be your @ubuntu address.  :)
<calc> slangasek: also why doesn't think make the amd64 cd oversized as this isn't arch specific
<calc> s/think/this/
<slangasek> calc: because the amd64 livefs failed to build.
<calc> slangasek: oh ok so its just the old one listed under current?
<NCommander> kees, Actually, i was going to set it to my new @debian.org, since ATM, that's my more professional address aside from my work one
<NCommander> ;-)
 * NCommander is shot
<slangasek> calc: by looking at the CD which is 95MB oversized, I would guesstimate that 92MB of that is due to the java+fortran stuff being pulled in
<calc> slangasek: i can respin OOo again and bump the recommends down to a suggests if that is needed, or do you have a way to override it?
<slangasek> calc: it needs a respin
<calc> slangasek: ok will do
<calc> should be done in around 2hr
<slangasek> calc: ok.  which bits are you changing?  I want to have an idea of whether everything is getting dropped off that needs to be
<calc> i was going to make it so that java2-runtime is no longer recommended
<cjwatson> NCommander: if you haven't yet filed that debootstrap bug in Debian, please don't
<calc> but as i notice that mysql is still broken i can't even install the build-deps atm
<NCommander> I haven't
<cjwatson> NCommander: it's specific to the Ubuntu scripts
<NCommander> cjwatson, oops
<cjwatson> NCommander: so please file it in Ubuntu (or I could just fix it now ...)
<NCommander> cjwatson, the later is preferable ;-)
<slangasek> kees: pah, why does Freescale need its own serial port naming convention?
<slangasek> kees: but yes, ok to upload
<kees> slangasek: ask NCommander :)
<NCommander> slangasek, ask freescale
 * calc looks at the mysql build process
<slangasek> NCommander: freescale didn't submit the patch. :)
<cjwatson> it's due to r50373 changing scripts/debian/sid but not the Ubuntu ones
<NCommander> slangasek, freescale created the serial driver with the funky names
<calc> mysql takes ~ 4hr to build and hasn't even started on all buildds yet :\
<NCommander> cjwatson, I will investiage the --foreign doesn't generate bootable rootfs bugs
<NCommander> Although it might not be something that is fixable
<NCommander> s/not//g
<slangasek> calc: lp-solve -> libsuitesparse-3.1.0 is also what pulls in fortran, which we also don't have room for.  Can lp-solve be dropped to a suggests?
<calc> slangasek: ok i'll take a look
<calc> ah i can install the build-dep i just had to add universe to my chroot
<NCommander> kees, please tell me when shadow is uploaded so I can officially tick it off the TODO list
<kevku> what happened with kdebase-runtime 4:4.1.96-0ubuntu1 amd64? :(
<slangasek> calc: what about the possibility of filing bugs about the known ways OOo breaks without java, and sending out a call for help?  Is there a problem of upstream migrating existing functionality over to java, or is it mainly a problem of not cleanly separating the java bits?
<slangasek> kevku: nothing, except that it hasn't built yet?
<kees> NCommander: it's uploaded
<mathiaz> calc: if you enable universe in your chroots, you'll pull in libmysqlclient-dev from mysql-5.1 (which will be libmysqlclient16-dev)
<calc> slangasek: both and also extensions can use java but if a user tries to install one they won't necessarily know it uses java and it just won't work
<calc> mathiaz: yes but it will work well enough to generate a source package :)
<calc> mathiaz: actually iirc it currently (before the new build finishes) pulls in libmysqlclient15-dev -> libmysqlclient-dev -> libmysqlclient16-dev  or something like that
<mathiaz> calc: libmysqlclient15-dev -> libmysqlclient-dev
<mathiaz> calc: libmysqlclient16-dev doesn't exist for now.
<slangasek> calc: heh, there are OOo extensions?  I've never heard of those
<calc> slangasek: yea lots of them
<calc> slangasek: http://extensions.services.openoffice.org/
<calc> slangasek: so we probably need a standing comment in release notes for users to install the openoffice.org meta package if they intend to actually use it for more than basic tasks
<cjwatson> NCommander: --second-stage breakage fixed in debootstrap 1.0.10ubuntu2, just uploaded
<slangasek> calc: I don't think we should word it that way ("more than basic tasks"), but yes, I agree
<calc> slangasek: well i defer that to someone more adept at writing release notes :)
<calc> but yes basically lots of things will break in various weird ways with how much we have pared down OOo for the cd
<calc> now that we managed to squeeze math into the cd it helps resolve some of the more ugly issues of document corruption
<slangasek> well, I think the document corruption bug is still a bug in its own right that should be fixed
<slangasek> anyway - do bugs get filed in LP as we run into things that break in weird ways?
<calc> yea it probably should refuse to open the document if it doesn't know how to due to missing bits (at minimum if not also suggest what you need to open it)
<slangasek> even if we don't have the capacity to fix them, I think it's important to have them documented
<calc> yes
<slangasek> ok, good
<slangasek> hmm, the test case for the math document corruption bug shows OOo able to *open* the document fine without -math installed
<slangasek> it just corrupts it on save
<slangasek> ("just")
<calc> yea :(
 * NCommander hugs cjwatson 
 * calc does note that lpsolve was a depends not a recommends, so hopefully it doesn't just explode
<slangasek> calc: it's a new depends, though - why was it added?
 * calc hopes his repackaging of OOo for split build will help resolve some of these issues with too much on the cd
<calc> slangasek: it was an internal library copy before but with work on getting rid of those it became an external dependency
<calc> with the split build in jaunty+1 there will no longer be any internal copies or anything (afaik anyway)
<slangasek> hmm, I guess today was the first CD build that had OOo 3 available for inclusion, so the dependency could've been added for any number of reasons :)
<calc> heh yea
<slangasek> calc: but the internal library copy before didn't require libsuitesparse...?
<slangasek> or fortran
<calc> not quite sure how it worked before, maybe lp-solve's need of those things isn't as high as its dependency suggests, i don't know
<calc> slangasek: do any of the openoffice.org-help-* packages land on the cd?
<slangasek> calc: help-en-gb, help-en-us
<calc> they also pull in java
<slangasek> yuck
<calc> and aiui they don't work at all without java, i will have to ask someone to verify quickly
<slangasek> that's like, the opposite of help
<slangasek> fwiw, the package only Recommends: openoffice.org-java-common, doesn't Depend: on it
<calc> oh oops i misread it
<calc> i had heard something about them needing it but it must not be that important :)
<slangasek> still, the Recommends will be a problem in practice
<calc> hmm but we install recommends by default so heh
<calc> i suppose i can drop them down to suggests as well and see if anyone screams :)
<calc> ugh that also means i need to respin l10n as well
<calc> oh well :)
<calc> generating the sources now for upload
<slangasek> calc: thanks
<calc> slangasek: should be done uploading in around 75m
<slangasek> ok
<ScottK> slangasek: Are we frozen for Alpha 3 yet?
<slangasek> ScottK: please consider us slushy; the freeze announcement should go out within the hour
<ScottK> slangasek: I'll run it by you then ...
<ScottK> slangasek: We've discovered there is some abi breakage in the libplasma3 that we uploaded with KDE 4.2 RC1 yesterday that make at least some packages that use it crashy if not rebuilt.
<slangasek> doh
<ScottK> slangasek: With the exception of compiz, all the stuff in Main is done.  I'd like to do a no change compiz upload.
<slangasek> yeah, go for it
<ScottK> OK.
<ScottK> slangasek: Done.  That was pretty high on the list of packages I figured I'd never upload.
<slangasek> heh :-)
<pochu> ScottK: but now you're TIA! :P Luckily for you it will be touched again before next round of merges ;)
<cjwatson> YM TIL?
 * pochu is no longer TIA for Eclipse. thanks asac! :P
<pochu> err, yes
<ScottK> Interestingly enough, I can't push my changes to the bzr repo because I'm not a compiz packager.
<cjwatson> slangasek: (I just uploaded a merge of vim to hopefully fix that messy diversions upgrade bug, BTW)
<slangasek> ok
<ScottK> RAOF or MacSlow: I just did a no change compiz upload.  I'd appreciate it if one of you would update debian/changelog in bzr (I can't).
<RAOF> Ah, it's compiz team owned.
<Amaranth> so...is xulrunner broken right now?
<ScottK> RAOF: Yes and I'm not on that team.  LP seems to think you are.
<RAOF> I am, yes.  I'll merge your update in there.
<ScottK> RAOF: Thanks.
<slangasek> er, who changed the channel mode?
<slangasek> cjwatson, Hobbsee, Mithrandir, Keybuk: could someone mark 'freeze' in the topic, please? (And possibly change the channel mode back)
<ion_> A few days ago, someone kept spamming the topic. Thatâs probably when the +t was set.
* slangasek changed the topic of #ubuntu-devel to: UDS: done, Archive: frozen for alpha-3, 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
<cjwatson> I think we can live without the +t for a while
<Nafallo> \o/
<tilgovi> I'd like to help test jaunty, but I only have one laptop at my disposal. Anyone have thoughts on how stable jaunty would be on my machine? My guess is that I'd be fine, given I have intel graphics and no strange components to speak of
<tilgovi> basically...is jaunty unusable at this point, or should I view it as a "probably works, but at your own risk"
<ScottK> tilgovi: Even if it works right now, there's no guarantee it wouldn't be horribly broken tomorrow.
<tilgovi> ScottK, yeah...I suppose that's true.
<ScottK> If you aren't prepared to deal with that, don't install it on real hardware.
<tilgovi> heh
 * ScottK is not kidding.
<tilgovi> I might very well be prepared to deal with that. I'll have to think about it more though.
<ScottK> Think VM in the mean time.
<tilgovi> Alright, thought about it more. Not going on my production box yet.
<tilgovi> I think it's getting to be about time I got another hard drive for all the vms I always want to play with.
<calc> crap my uploads failed :(
<calc> i should not have done them simultaneously it timed out my router :\
<superm1> slangasek, i just uploaded an xfce4-session that otherwise would have prevented an alpha3 for xubuntu and mythbuntu.  hope it's okay since i just saw the archive freeze  notice 10 min ago on /t as i was uploading..
<superm1> cody-somerville, ^
<james_w> Keybuk: is it possible to make autoreconf work when using just autoconf and libtool, and not automake?
<Keybuk> james_w: it should
<james_w> Keybuk: you have to have an aclocal.m4, otherwise it tries to run aclocal. Is that reasonable?
<james_w> There appears to be a clash between not using automake, and having custom macros in .m4 files.
<james_w> if I install automake and let it run aclocal, then it doesn't gather the extra macros, because I don't have a Makefile.am for it to take ACLOCAL_AMFLAGS from.
<james_w> so autoreconf calls autoconf with no -I, so it ignores the extra macros, and it all falls to pieces from there
<kees> why is there yahooapis.com JS in the LP html?
<ion_> Why not? YUI is neat.
<kees> because I like my JS coming from single domains.  :)
<kees> ion_: ah, ha.  bug 316509
<ubottu> Launchpad bug 316509 in launchpad-foundations "Mixed-security warning on edge" [High,In progress] https://launchpad.net/bugs/316509
<ion_> LP could always use a local copy of YUI, but i donât mind sites using it from the origin.
<RainCT> cjwatson, kees: so, who of you should I vote? ;P
<Turl> hello
<Keybuk> james_w: sure, aclocal is part of automake ;)
<Turl> may you see https://bugs.launchpad.net/bugs/285417 ? There are debdiffs to fix the packages, so it should be an easy task
<ubottu> Ubuntu bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed]
<cjwatson> RainCT: me! or him!
<cjwatson> HTH
<RainCT> hehe
<james_w> Keybuk: ok, so I create an aclocal.m4 containing all the things I need by hand, but how do I get the libtool stuff in without hardcoding the path to libtool's m4?
<Keybuk> james_w: include lines?
<Keybuk> usual way to make aclocal is m4 directory, copy things in, and put include lines in aclocal.m4
<james_w> m4_include([m4/libtool.m4])
<james_w> etc?
<Keybuk> james_w: yeah
<Keybuk> (aclocal should really move to autoconf)
<james_w> k, thanks Keybuk, I'll give it a go
<kees> RainCT: I promise to bring even more crazy compiler flags to Ubuntu.  but... I'd do that anyway.  :)
<RainCT> \o/
* cody-somerville changed the topic of #ubuntu-devel to: Archive: frozen for alpha-3, MoM running | Be sure to vote in Tech Board Nomination Ballot! | 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
<TheMuso> bryce: re alsamixer -c0, I am either going to write a wrapper script to force that when pulseaudio is running, or change something in the alsamixer code, probably the former, since its less painless.
<bryce> TheMuso: ok
<bryce> TheMuso: yeah, I had kind of a painful upgrade experience this morning until I ran across using the -c0 flag
<bryce> TheMuso: on the plus side I cleaned up a bunch of dupe/related bug reports on sound problems with this hardware
<TheMuso> bryce: I saw, I am going to see if there is already a git commit upstream for your hardware. If not, I'll push your patch upstream and push it to the kernel guys.
<bryce> excellent, thanks
<MacSlow> ScottK, I can't ... I don't have upload-rights
 * MacSlow is not a MOTU
<ScottK> MacSlow: You do for that bzr branch, but RAOF already took care of it.
<slangasek> superm1: ack, fixes for showstoppers are implicitly ok :)
<TheMuso> bryce: Am I right in guessing that the patch you attached to 210865 is for more than one chipset? If so, I wonder if better names should be used, rather than 82801H.
<geubank4> 4777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777uiiiiiiiiiiiiiiiiii
<TheMuso> geubank4: Stuck keyboard?
<slangasek> I'd guess 'cat'
<geubank4> Darn cat
<MacSlow> ScottK, ah ok ... sorry just came back from capoeira
<ScottK> MacSlow: No trouble.
<bryce> TheMuso: I can't confirm that but suspect it may be the case
<TheMuso> Ok.
<bryce> TheMuso: one thing to check is if 0x8227 covers more than just 82801H, that those other chips are valid having the mitac quirk applied for them
<TheMuso> bryce: Right.
<TheMuso> bryce: Well there is no reference to 0x8227 in the hda code, so...
<bryce> I *suspect* it to be the case in reading through other 82801* bug reports, but in too many cases the bug reports lacked necessary info/troubleshooting to be certain
<TheMuso> However, I need to check another branch to be 100% sure of that.
<wasabi> hmm. ebox was supported
<wasabi> i thought ^
<bryce> TheMuso: one thing is you could talk with ogasawara or one of the other kernel team people who have weekly concalls with Intel to give some feedback on this issue
<ScottK> wasabi: #ubuntu-server for ebox.
<TheMuso> bryce: ok, but its not an intel codec, its realtek, so one would think they should have this covered...
<TheMuso> but anyway, I'll see what I can do with what we have now.
<bryce> cool
 * calc bbl grabbing early dinner
<laprice> I was trying to look up info on building packages but http://ubuntuforums.org/ is 404
<laprice> is there a standard reference doc?
<vorian> laprice: https://wiki.ubuntu.com/PackagingGuide
<laprice> Grazie
<vorian> no problemo
<Narugawa> good night peolpe
<Narugawa> do u know if the alpha 3 release at night or day the 15 ?
<NCommander> doko, I need your assistance with an ICE once your available.
<jdstrand> soren: fyi-- with my latest commit to ufw, it won't interfere with libvirt (or anything else)
<jdstrand> soren: it'll be in ufw 0.26
<soren> jdstrand: Ooh! Neat!
<jdstrand> soren: though it took me awhile, I did promise I wouldn't forget you :)
<soren> You did indeed. I'm looking forward to see how you did it :)
<jdstrand> soren: actually, I just make sure that I only touch ufw chains. It's long been a beef of slangasek's that it flushes the built-in chains. It was surprisingly tricky to get right, but it all seems to be working now :)
<slangasek> \o/ :)
<jdstrand> :)
<soren> jdstrand: Yeah, I know it was tricky. I secretly took a stab at it long ago, failed horribly and chose not to tell anyone about it :)
<StevenK> ... until now
<jdstrand> heh :)
<soren> It never took place.
 * soren does the jedi hand waving trick frantically
 * soren notes that it doesn't look very cool, calm, and jedi-like when done frantically
<jdstrand> haha
#ubuntu-devel 2009-01-14
<Riddell> kees: that dosemu diff is really not minimal
<kees> Riddell: no?
<kees> or is that the one with build cruft?
<Riddell> kees: yep
<kees> Riddell: I'm open to suggestions on how to avoid the cruft.  seems to show up in my debdiff any time I debuild -S it
<LaserJock> kees: filterdiff?
<kees> LaserJock: oh, sure, I can manually do it.  :)
<kees> but it does represent what's going to happen when it builds
<LaserJock> kees: does that matter so much?
<LaserJock> what kind of cruft is it?
<kees> LaserJock: autoconf joy
<kees> Riddell: what would you like me to do?
<Riddell> kees: if it's unavoidable I can just look through it
<LaserJock> kees: so like config.guess, config.sub?
<RAOF> Hm.  Where was that network-manager + WPA-enterprise bug...
<slangasek> kees: you're on MIR team now?  Could you take on bug #315403?  looks like cup has been dep-wait on jflex since November
<ubottu> Launchpad bug 315403 in jflex "MIR for jflex" [Undecided,New] https://launchpad.net/bugs/315403
<kees> slangasek: I am, but I'm totally underwater at the moment with security work
<slangasek> ok
<slangasek> lool: how about you?  Any cycles for MIR work? ^^
 * slangasek wonders if jflex should replace jlex as a dep of libxsltc-java
<RAOF> Woah.  That's got to be the longest bug with a reasonable signal/noise ration on launchpad.
<kees> Riddell: thanks
<calc> aren't programs that need to save supposed to stop shutdown from happening until you deal with them?
<calc> istr this used to happen but now it doesn't for me anymore
<calc> i got a bug about OOo not stopping shutdown to save and tested on a vm and it doesn't work even for Gedit for me
<slangasek> calc: GNOME upstream broke the use of the standard session protcol
<slangasek> calc: so that really ought to be assigned to gnome-session; dunno if a bug is already open
<calc> slangasek: ah ok
<slangasek> cf. http://np237.livejournal.com/22014.html
<calc> slangasek: thanks for the link
 * slangasek oohs, noticing that rss-glx is the only thing on the CD using libmagick10 and wondering if he can reclaim 2.4MB by rebuilding it against libmagickcore
<slangasek> calc: ooo/amd64 ftbfs?
<slangasek> ah, because of libmysqlclient still
<slangasek> calc: n/m
 * slangasek schedules a retry, since everything seems to be in order now
<slangasek> hah, nice; libmagick10 has been split into 'libmagickcore1' and 'libmagickwand1', which... depend on each other.
<StevenK> Yes.
<slangasek> StevenK: dare I ask why?
<slangasek> I knew they were split - why is there a circular dependency?
<StevenK> slangasek: Because the Maintainer needs his crack pipe taken away ...
<slangasek> well, ok.  It's ImageMagick, so that's par for the course.
<slangasek> see also: epochs
<StevenK> slangasek: I've been closing my eyes and saying "Lalala" about libmagick10 in NBS since it requires a bunch of source changes and there's a lovely argument going on in the BTS about it ...
<slangasek> StevenK: right - I'm going to do rss-glx though, because libmagickcore1+libmagickwand1 is 2.1MB smaller than libmagick10 :)
<StevenK> Heh
<StevenK> I've been hoping the mess resolves itself, but if it gets much later I'm going to JFDI
<slangasek> they must have built it without --enable-inline-fibonnaci-array
<TheMuso> cd
<slangasek> is the argument in the BTS converging on sanity?
<TheMuso> woops wrong tab
<StevenK> It wasn't, last I read.
<calc> slangasek: yea i just rescheduled armel as well
<StevenK> slangasek: I last read the bug in the BTS about a month ago, mind you
<slangasek> StevenK: can you nudge it in that direction? :)
<StevenK> slangasek: I was staying out of it :-P
 * StevenK points to his "Slightly innocent by-stander" hat
 * slangasek crosses out "by-stander" and writes in "downstream victim" :)
<StevenK> Haha
<RAOF> TheMuso: You know how the recent pulseaudio uploads fixed my stutter on HDAs-Intel?  It seems they've transferred them to my USB speakers :(
<lifeless> lol
<TheMuso> RAOF: That sucks.
<RAOF> At least now it correlates with CPU load.
<RAOF> Not heavy CPU load, mind.  Just any cpu load.
<TheMuso> RAOF: Try alsa-driver 1.0.18 final, if its gone, then its a driver fix we can probably pull to work it out.
<TheMuso> Right.
 * TheMuso read an interesting tidbit this morning, USB2 is only half-duplex.
<RAOF> What's the m-a package for alsa-driver?
<TheMuso> RAOF: alsa-source afaik.
<RAOF> Mmmm, build-stutter.
<LaserJock> can you use sudo to restrict what people can run for stuff that's not for root?
<RAOF> Hm.  alsa-source fails to build somewhere.  That's going to be fun for someone not me.
<TheMuso> RAOF: Ah ok, will chase that up.
<lifeless> r
<lifeless> RAOF: how did you go with mono?
<RAOF> lifeless: I am, as yet, unable to make it segfault when I'm looking at it.
<lifeless> RAOF: ha!
<lifeless> RAOF: running under gdb fixes it ?
<RAOF> It does indeed.  Well, running the mono commands that the postinst would run under gdb doesn't segfault, at least.
<lifeless> RAOF: I will bet that running under valgrind would find it on your machine :P
<RAOF> I suppose that if I wanted to be 100% thorough I'd upload a new mono that wraps all executions of mono in gdb, and then build-depend on that new version.
 * RAOF wonders if NCommander feels like some more mono pain, with added debug difficulty.
<NCommander> AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
<NCommander> (no)
<RAOF> But this is one that I've only been able to reproduce on the PPA buildds, where we have no access!  What could be more fun than debugging that?
 * NCommander turns on the Soyuz light
<RAOF> TheMuso: No joy on the alsa-driver 1.0.18 front.  If it's any better, it's not much better.
<RAOF> Hm.  What's the easiest way to get a Debian Experimental VM happening in virt-manager?
<TheMuso> RAOF: Right, so its probably userspace... again.
<superm1> slangasek, i think someone abducted the mythbuntu builds from cdimages.ubuntu.com... there's no ISOs anymore for yesterday or the day before: http://cdimages.ubuntu.com/mythbuntu/daily-live/
<slangasek> anything interesting in livefs build logs?
<superm1> well there were ISOs before for at least the 12th
<slangasek> hmm
<superm1> well wait, no i had an 11th downloaded, so i dont know there was for the 12th
<superm1> i'll look at livefs build logs
<slangasek> it's not a livefs build problem, though there was a livefs build failure on amd64
<superm1> (i would have expected that the old one was used anyhow though if later ones were failing)
<slangasek> W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/jaunty/main/b
<slangasek> inary-i386/Packages.bz2  Hash Sum mismatch
<slangasek> it's that darn mirroring locking bug
<superm1> so likely would affect xubuntu and what not too
<slangasek> yes, it's an intermittent thing
<dholbach> good morning
 * slangasek waves
<ion_> Hola
<superm1> why did the ISO from the 11th get purged tho if the ones on the 12th and 13th weren't actually made?
<slangasek> the script isn't so intelligent that it checks for successful builds before kicking off stale images
<slangasek> superm1: there's a 14 now, though :)
<superm1> slangasek, well it's unfortunately broke unless it included the xfce4-session build that just finished 7 minutes ago... same for xubuntu.  for some reason it looks like the build was scored really low and didn't build for 8 hours
<slangasek> mm
<slangasek> well, I was just doing an ISO build anyway, to test that this would work - the livefs still needs rebuilt
<superm1> slangasek, yeah i dont think it's even finished the publisher run yet: https://launchpad.net/ubuntu/+source/xfce4-session/4.4.3-0ubuntu2
<slangasek> did you happen to take a peek at the amd64 livefs build failure I alluded to?  Anything that needs doing there, or should that sort itself out?
<superm1> let me take a look
<superm1> hm, very bzr. "                     Depends: update-manager but it is not going to be installed" what would prevent "update-manager" of all things?
<superm1> i suspect it should sort itself out, but if it doesnt i can prepare an amd64 chroot sometime tomorrow
<liw> hrmph, unable to install hardy this morning, results in grub saying "Error 18"
<liw> oh, hm, http://wiki.linuxquestions.org/wiki/GRUB#Error_18
<sladen> liw: you needs a /boot somewhere "near" to the start of the disk (<2GB IIRC)
<sladen> well, 8GB, according to that URL
<liw> sladen, yeah, but I keep being weirded out that a modern motherboard's bios needs that still
<sladen> liw: using some low-level ext hackery it would be possible to force certain files below a magic threshold, but I (probably like you) thought it was "fixed" by now
<RAOF> Amaranth: bluesmoke?
<Amaranth> RAOF: magic blue smoke
<Amaranth> RAOF: Your computer makes it when you compile mono too many times
<RAOF> Heh.
 * RAOF 's box made it without compiling mono _at all_.
<ashvala> Hello
<ashvala> [ 52.630275] SDA:<4>Driver 'sr' needs updating - please use bus_type methods HELP!
<ashvala> please help
<slangasek> calc: the fortran stuff cleaned up nicely; the java stuff is still there even on i386 - is that because -l10n hasn't built yet?
<voox> is it fairly safe to update from a fresh install with alpha 2?
<DktrKranz> bryce: thanks for devscripts! I'll file a wishlist bug in Debian too later this evening. Regarding its merge, I could look at it in the next few days.
<lool> slangasek: Reviewed jflex; found a bunch of small issues which can easily be resolved, but I don't think we should block main promotion on them
<liw> what's the status of radeon support with free drivers? my RV630 does not seem to work in intrepid, but perhaps jaunty has new goodies?
<savvas> Qt will use lgpl: http://www.eweek.com/c/a/Linux-and-Open-Source/Nokia-to-Offer-Qt-Under-LGPL-Licensing/
<Keybuk> cjwatson: do we have anything that tries to populate /dev anymore?
<Keybuk> (other than makedev itself)
 * ogra just wanted to note there are some postinsts that run makedev :)
<asac> james_w: i saw that you took over the firebug branch with what comes from debian at some point.
<Keybuk> yeah, they'll fail now ;)
<Keybuk> (in Debian too)
<james_w> asac: yeah
<ogra> i saw that (on arm though)
<asac> james_w: and changed the binary package name from firebug to iceweasel?
<james_w> asac: nope
<Keybuk> ogra: I'm wondering whether we should drop makedev
<ogra> how is that supposed to work now ?
<ogra> calling some udev specific command ?
<Keybuk> ogra: the device will already exist ?
<ogra> or does it just rely on the kernel creating these devices
<asac> james_w: did you try to contact jared first? (who was the original maintainer)
<Keybuk> there aren't any devices for which the kernel won't create it first
<ogra> ah
<james_w> asac: it was a merge from Debian as the Ubuntu package was really out of date, modifications were made from Debian's package to make it work with firefox etc.
<james_w> asac: no, I didn't. There was an old upgrade bug open on the package.
<ogra> well, people will complain if they dont have makedev anymore ...
<asac> james_w: you could have pinged us ;)
<asac> ok
<james_w> asac: I didn't feel I needed to.
<Keybuk> ogra: will they?
<ogra> but thats the only drawback i see ... i.e. if you have scripts that use it to create any special devices
<Keybuk> makedev is already a no-op with a warning if you try and run it
<cjwatson> Keybuk: I don't think so
<ogra> oh, and i was talking about mknod :) ignore me :)
<cjwatson> I was under the impression that postinsts that run makedev generally had conditionals
<asac> james_w: you know that an extension team existed ;)
<ogra> i saw a lot of makedev calls building the last arm rootfs tree
<ogra> but they usually only warn
<james_w> asac: yes, and I updated the branches from the debdiffs that were supplied.
<cjwatson> NCommander: bug 316841: don't we need to update finish-install too to set up an upstart job for the serial console?
<ubottu> Launchpad bug 316841 in shadow "Freescale MX series needs new ports added to securetty.linux" [Medium,Fix released] https://launchpad.net/bugs/316841
<Keybuk> cjwatson: we end up with a fairly random set of stuff in the "real" /dev
<Keybuk> many of which have the wrong names, permissions, etc.
<Keybuk> it would be nicer if that just had the most basic devices like console, null, etc. only
<asac> james_w: in general all is fine .. i just think that you changed the orig tarball layout to something that cannot be patched without patchsystem
<asac> which is somewhat bad ;) ... but now its done, so whatever ;)
<cjwatson> debootstrap might populate it a bit, though I thought it had stopped doing that
<Keybuk> cjwatson: the makedev postinst itself populates it
<james_w> asac: ah, ok, sorry about that.
<Keybuk> and there are packages that call makedev if they don't think udev is running
<Keybuk> which means it ends up partially populated when installing
<james_w> asac: you should probably create a README.Source that you can reference from these packages that explains this stuff.
<asac> james_w: we will bring mozilla-devscripts to debian soon ... then firebug guy can use med-xpi-unpack and med-xpi-pack to do that
<asac> e.g. creating a good orig
<cjwatson> Keybuk: a udev /dev should be bind-mounted during installation though
<asac> firebug guy/debian guy/
<Keybuk> cjwatson: is it?
<cjwatson> we do mount --bind /dev /target/dev
<asac> james_w: yeah true ... i just didnt expect someone to go and merge from debian to a previously independent branch ... my wrong
<cjwatson> I can't swear that that's present at all possible points but I certainly thought it ought to be
<Keybuk> damn, I shall have to figure this bug out harder then ;)
<cjwatson> you could add something to makedev.postinst to check for the udevdb
<Keybuk> there's something in MAKEDEV itself that does that already
<asac> james_w: but lets move on ;)
<cjwatson> oh yes
<Keybuk> you can't MAKEDEV over the top of udev
<cjwatson> do we need to install the makedev package by default any more?
<Keybuk> cjwatson: support for making devices other than in /dev ?
<Keybuk> (it's a bit of a long stretch)
<Keybuk> a few things depend on it
<cjwatson> hmm, udev is probably not installed in buildd chroots
<cjwatson> historically that has been Painful
<asac> james_w: btw, the work you did is much appreciated ;) (in case it sounded different)
<Keybuk> why would something need to call makedev during package builds?
<Keybuk> that's not even possible surely? :p
<cjwatson> it wouldn't, but the buildd chroots probably need at least a few devices present
<cjwatson> I don't know if they bind-mount /dev
<Keybuk> interesting question
<james_w> asac: no problem. I realise that you are trying to do something a bit different and I don't want to make it harder than it has to be for you.
<cjwatson> it's nice for debootstrapped chroots to have some useful devices out of the box too
<Keybuk> yeah, I was thinking of just going for a more minimal default /dev
<Keybuk> without some of the more exotic devices
<Keybuk> bryce: around?  (re: sane-backends)
<asac> james_w: in fact i dont try to do things different. just wasnt sure (and still nto 100% sure) what to do with debian merges for pre-existing branches
<cjwatson> Keybuk: debootstrap appears to do 'MAKEDEV std ptmx fd' and put the result in /dev
<cjwatson> which IIRC is not an entirely crazy set
<Keybuk> right
<Keybuk> that's a pretty reasonable core set
 * Keybuk tries to remember why he doesn't just call MAKEDEV to populate /lib/udev/devices
<cjwatson> so I think that means makedev may be unnecessary in the required seed
<cjwatson> it's explicitly seeded there right now
<Keybuk> enough base things depend on it that it'll stay in the seed
<Keybuk> but we could probably unseed it and see how long it takes to go away
<cjwatson> yeah, that's what I meant
 * Keybuk likes discussing changing fundamental things in the middle of an alpha freeze <g>
<cjwatson> germinate seems to think that it should at least drop out to standard
<cjwatson> which would mean debootstrap would stop installing it
<Keybuk> cjwatson: *nods*
<Keybuk> a few things seem to hold it in standard
<cjwatson> fuse-utils
 * Keybuk looks at ogra ;-)
<cjwatson> should be easy to address
<ogra> hmm, havent touched it for a whil ... i'll look
<ogra> *while
<ogra> i think that comes from the odd debian postinst scrits we dont use ...
<ogra> *scripts
<ogra> ogra@osiris:~/Devel/packages/fuse-2.7.4$ grep makedev debian/*.post*
<ogra> debian/fuse-utils.postinst:  	# Call makedev and fix perms
<ogra> well, that indeed justifies a dependency ... omg ! its mentioned in the comments !!!
 * ogra drops :)
<asac> james_w: any ideas how i could publish a failed bzr merge? just forcefully committing and requiring developers to uncommit to work on it?
<ogra> Keybuk, fix uploaded
<asac> james_w: will bzr resolve FILE forcefully resolve a conflict?
<james_w> asac: can they not just the merge for themselves?
<asac> james_w: but how to publish the "work task" ?
<asac> james_w: that would require a separate channel like mailing list etc.
<james_w> launchpad merge request?
<asac> james_w: yeah. that could be used, but is a bit of a launchpad specific problem to the general problem. but good enough i guess (just have to figure out the xml api i guess)
<asac> s/specific problem/specific solution/ ;)
<james_w> the API doesn't quite allow you to create merge requests yet I believe
<asac> hmm ... that would be a blocker then ;)
<james_w> I agree a way of storing a conflicted tree with pending merges might be quite useful
<james_w> but force committing it isn't the answer
<asac> yeah. thats why i asked ;)
<asac> james_w: if i uncommit, i can still refer to that revision right?
<siretart> why is there no linux-image-debug-2.6.27-9-generic on security.ubuntu.com? `apt-cache madison linux-image-debug-2.6.27-9-generic` claims it to be produced from the source package linux_2.6.27-9.19, but it does not seem to be published at all!
<james_w> asac: yeah, by revid
<asac> james_w: but i guess that hidden revision isnt pushed?
<james_w> asac: correct
<asac> couldnt a similar mechanism be used to publish such broken merge requests?
<asac> james_w: ?
<james_w> what mechanism?
<asac> james_w: to have a revid that represents the broken merge
<james_w> not really, as a pending merge/conflicts are working tree things, not revisions
<asac> james_w: yes, but if uncommit a merge, isnt the merged tree still reachable through the "hidden" revid?
<asac> but well, i better stop talking about things i dont know any details ;)
<james_w> yes, you are right
<asac> james_w: about the former or the latter ... or both?
<asac> :-P
<james_w> but it's equally as accessible, more visible, and easier to refer to in the place that you merged from
<james_w> heh :-)
<james_w> the former
<cjwatson> ogra: it wasn't just the comments, note that makedev's executable is in upper case :-P
<ogra> argh
<cjwatson> but that code path is never executed if udev is active anyway
<cjwatson> I'm not sure what would happen if you installed fuse-utils in a buildd chroot, though
<cjwatson> we could just make the postinst succeed anyway
<cjwatson> lamont`: ah, excellent timing. Do buildd chroots bind-mount /dev from the base (presumably udev)?
<ogra> just an || true ?
 * ogra would rather comment that line out completely though
<lamont`> cjwatson: buidld chroots have proc and dev/pts from the parent
<cjwatson> can they have /dev?
<cjwatson> or is there a good reason not to?
<asac> james_w: 317111
<james_w> thanks
<superm1> slangasek, it looks like the livefs for mythbuntu still have the old xfce4-session for today.  xubuntu's is good I believe ( cody-somerville can you confirm? ), could you poke it to do one more build?
<cody-somerville> superm1, charlie-tca confirms livecd starts fine today
<cody-somerville> As for mythbuntu, I don't have access to distro build infrastructure (I'm in OEM Services). slangasek, cjwatson, or evand should be able to help you get you your livefs rebuilt.
<superm1> thanks
<cody-somerville> superm1, Have you looked to see if maybe your livefs build failed?
<BUGabundo_work> cjwatson: ping
<superm1> cody-somerville, yeah the last one passed: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/mythbuntu/20090114/ .  I think it was just an inconvenient time that it was cronned before things were published
<BUGabundo_work> cjwatson: yesterday daily jaunty installer won't accept a swap + / ext4
<BUGabundo_work> plus gparted on the livecd doesn't support et4
<BUGabundo_work> *ext4
<cody-somerville> BUGabundo_work, are you running Windows at the moment?
<BUGabundo_work> yes from another PC
<BUGabundo_work> took almorning backing up disk to external driver
<BUGabundo_work> uses usbcreator to make a pendrive
<BUGabundo_work> and now am stuck with the install!
<cjwatson> BUGabundo_work: the gparted bug for ext4 is still open
<BUGabundo_work> reporting both bugs on LP
<cjwatson> do not report that one again
<BUGabundo_work> ok I'll subs to it then
<BUGabundo_work> won't!
<BUGabundo_work> about the installer cjwatson?
<BUGabundo_work> 8GiBs swap + / ext4 is replaced by / ext3 + /Home ext3
<BUGabundo_work> very strange
<cjwatson> BUGabundo_work: do you mean that you did guided partitioning?
<BUGabundo_work> manual
<BUGabundo_work> does the guided handle ext4?
<cjwatson> no
<BUGabundo_work> there you go
<cjwatson> so you must have created /home by hand. Do you mean that it did not recognise the existing ext4 partition as being ext4?
<BUGabundo_work> old partitions were ext3. one / + one /home plus one swap
<BUGabundo_work> I deleted them via installer (which means they are still intact)
<cjwatson> BUGabundo_work: so I do not understand your bug. First you say that the old partition was ext4, now you say that it was ext3
<BUGabundo_work> and "tried" to create new ones
<cjwatson> can you please be more precise?
<BUGabundo_work> no no no
<BUGabundo_work> old was ext3
<BUGabundo_work> and xfs
<BUGabundo_work> new schema with deleted old partitions is meant to be 8gibs /swap + / ext4
<cjwatson> BUGabundo_work: please file a bug stating precisely what you did, step by step
<BUGabundo_work> but the installer replaces that with 8g / ext3 and /home ext3
<BUGabundo_work> no swap, no ext4
<cjwatson> BUGabundo_work: concentrate on making it possible for me to follow the same steps and reproduce the problem
<BUGabundo_work> sure
<BUGabundo_work> brb
<cjwatson> that's deeply improbable
<cjwatson> the installer never creates /home by default
<BUGabundo_work> do you have the bug id for gparted?
<BUGabundo_work> I know! its strange
<cjwatson> no, but it shouldn't take you long to look it up
<BUGabundo_work> I can show you via webcam
<BUGabundo_work> do you want that ?
<cjwatson> BUGabundo_work: is this the alternate installer or the desktop installer
<cjwatson> no, I would rather not have a video
<BUGabundo_work> humm tried first from the quick installer at livecd boot
<BUGabundo_work> then from Full desktop live
<cjwatson> so the desktop installer
<BUGabundo_work> will reboot, and report the bug, step by step
<cjwatson> BUGabundo_work: please attach /var/log/syslog, /var/log/partman, and /var/log/installer/debug *after* reproducing the bug but *before* rebooting
<BUGabundo_work> I don't know how you guys call the installer that doesn't boot into desktop
<BUGabundo_work> okay
<cjwatson> it's the same installer
<BUGabundo_work> okay
<BUGabundo_work> good to know
<BUGabundo_work> cjwatson: I'm still making a webcam cast of the procedure
<BUGabundo_work> in case you want to watch it later
<BUGabundo_work> http://bambuser.com/node/68590
<cjwatson> usually logs are actually more helpful to me, but thank you
<cjwatson> once in a blue moon I guess a video would be handy
<BUGabundo_work> no prob
<BUGabundo_work> ok just reproduced it!
<BUGabundo_work> getting logs to a bug
<BUGabundo_work> cjwatson: what package?
<cjwatson> BUGabundo_work: ubiquity
<cjwatson> (it's probably not really there but that's a good starting point)
<BUGabundo_work> cjwatson: bug 317124
<ubottu> Error: Launchpad bug 317124 could not be found
<BUGabundo_work> uploading logs now
<cjwatson> thanks
<BUGabundo_work> cjwatson: logs sent
<BUGabundo_work> bug 317124
<ubottu> Launchpad bug 317124 in ubiquity "jaunty installer fails to accept manual ext4 schema" [Undecided,New] https://launchpad.net/bugs/317124
<BUGabundo_work> ping me for any extra test or info
<cjwatson> BUGabundo_work: OK, I'm working on something else right now but will get to this next
<BUGabundo_work> thanks
<BUGabundo_work> if it gets fixed today, maybe I can still test it again
<BUGabundo_work> and get a fresh install
<BUGabundo_work> finally
<BUGabundo_work> 10GiBs for / is full
<BUGabundo_work> cjwatson: are you kamion on LP?
<cjwatson> BUGabundo_work: yes
<calc> slangasek: yes that would be because of the ooo-l10n afaik
<cjwatson> BUGabundo_work: ok, turns out it's nothing to do with ext4 and is a bug that's been fixed in a more recent version of ubiquity
<cjwatson> BUGabundo_work: I'd appreciate it if you didn't assign bugs to me in future
<cjwatson> my manager gets to do that :)
<robbiew> cjwatson: ;)
<cjwatson> I must backport that gparted patch though, a lot of people have been asking for it
<BUGabundo_work> cjwatson: sorry
<Keybuk> not for the first time I wish that dpkg had a command line option to tell you what deps were missing
<liw> dpkg -i foo.deb; apt-get -f install # this more or less works as a workaround (Keybuk surely knows this, but others might not have realized)
<ogra> Keybuk, ther is that apt thing :)
<mvo_> gdebi is also a handy tool for this
<Keybuk> liw: that's not quite what I meant
<Keybuk> apt attempts to fix it given the known archives
<Keybuk> (dpkg --configure -a gives similar output, but also tries to fix things)
<Keybuk> all I want to know is what's wrong
<liw> Keybuk, ok
<liw> apt-get has --no-act, though
<mvo_> Keybuk: is gdebi what you want then? it will also look at the known archive but will tell you about stuff it can not find
<Keybuk> dunno
<Keybuk> it's more the versions
<Keybuk> I've installed a bunch of jaunty packages on intrepid
<Keybuk> want to know what I need to upgrade
<ion_> liw: dpkg --unpack foo; apt-get -f install rather.
<joaopinto> Keybuk, the fix attempt from apt-get -f install will show you the problems ....
<joaopinto> bue like mvo explained, gdebi will do that on a preventive manner
<slangasek> lool: jflex> cheers - do we need to look at getting jlex demoted as well?
<slangasek> ogra: hrm, was this fuse upload really warranted during a milestone freeze?
<ogra> slangasek, err, i thought we are suposed to upload to have it in the queue
<ogra> slangasek, its not urgently needed in the images
<slangasek> superm1: yes, mythbuntu livefs respinning now
<superm1> slangasek, great thanks
<slangasek> ogra: we haven't been using a queue for alpha milestones for 3 release cycles...
<ogra> meh, sorry then
<ogra> it wont do any harm though
<mvo_> slangasek: I have a pending update-manager upload that helps nvidia users, is it ok to still upload ?
<slangasek> mvo_: bug #?
<mvo_> slangasek: bug #308410
<ubottu> Launchpad bug 308410 in nvidia-graphics-drivers-180 "Latest Xorg removes nvidia driver ... conflicting xserver-xorg-video-4" [Medium,Confirmed] https://launchpad.net/bugs/308410
<mvo_> slangasek: the "fix" for now is to auto transition the users from nvidia to nv in the xorg conf
<slangasek> mvo_: I probably won't respin all the images for the fix (xubuntu/ubuntustudio are already built, and that's clearly an upgrade-only fix so not entirely relevant to milestone ISOs), but yeah, go ahead with uploading
<mvo_> thanks slangasek, will do after the meeting (I want to review the debdiff again and run a test just to be sure that I don't do breakage)
<seb128> slangasek: hi, could you accept the evolution-exchange intrepid sru? the evolution update broken for exchange users and that one should fix the issue
<slangasek> seb128: yes, shortly - in a meeting now
<seb128> slangasek: ok thanks
 * calc apologizes for interupting the meeting i didn't see what channel my name highlighted in due to irssi screen limitation issues
<cjwatson> ogasawara: why does bug 34190 show up in the "other" section of http://qa.ubuntu.com/reports/ogasawara/jaunty-buglist.html? It has the qa-jaunty-foundations tag and should go in the Foundations section
<ubottu> Launchpad bug 34190 in debian-installer "live cd "boot methods" out of date" [Medium,Triaged] https://launchpad.net/bugs/34190
<ogasawara> cjwatson: hrm, I'll investigate
<ogasawara> cjwatson: you may also want to use http://qa.ubuntu.com/reports/ogasawara/qa-jaunty-buglist.html instead.  Should be the same list, just has a LP look and feel with sortable columns
<cody-somerville> mvo_, I'm having trouble with bug #310137. My merge FTBFS because it says the libc6 version is too high although in the newsfile for valgrind, apparently this version added specific support for 2.8. Is it safe to patch it to let it compile with 2.8 or do I have to regenerate the configure file stuff or something? :P
<ubottu> Launchpad bug 310137 in valgrind "Merge valgrind 3.3.1-3 from Debian unstable (main)" [Medium,In progress] https://launchpad.net/bugs/310137
<cjwatson> ogasawara: thanks
 * lamont` finally gets annoyed enough at cups to file bug 317153
<ubottu> Launchpad bug 317153 in cups "state belongs in /var, not /etc" [Undecided,New] https://launchpad.net/bugs/317153
<mvo_> cody-somerville: if it works with 2.8 I would say patch it and forward the patch to upstream (might be a oversight or something by upstream)
<lool> slangasek: I don't know anything about jlex; if you think it's not needed in main, then I trust you!
<cody-somerville> mvo_, k
<slangasek> lool: well, the description of jflex is "a reimplementation of jlex"
<slangasek> lool: so I guess it would be nice to not have two of them in main
<cjwatson> ogasawara: the intention is that simply tagging a bug gets it onto that list, isn't it?
<lool> slangasek: Good point
<ogasawara> cjwatson: yup
 * cjwatson has no problem with jlex being demoted (as the Debian maintainer, although the mists of time have swallowed up why I decided to maintain it)
<slangasek> cjwatson: are you in a position to migrate libxsltc-java to jflex?  I haven't looked into what that entails, so far was just asking the question
<cjwatson> I'm not sure I could do a good job, but I suppose I can try
<cjwatson> I haven't looked at jlex non-trivially in years
<cjwatson> slangasek: jflex can handle the .lex file there OK, but I wouldn't even know where to start with testing whether there are any regressions; the generated scanner looks completely different
<slangasek> hmm, fun
<slangasek> well, we can try it out post-A3 then maybe
<cjwatson> I think somebody should ask upstream
<slangasek> jflex upstream?
<cjwatson> xalan upstream
<slangasek> ok
<LaserJock> cjwatson: do you know if the supported seed in edubuntu actually used?
<sahko> hi, does anyone maybe know the result of the discussion regarding cdrtools inclusion in ubuntu as mentioned here: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-August/000472.html ?
<sahko> i asked on the forum too but didnt get an answer so far. sorry if this is outside the purpose of this channel. didnt know where else to ask
<cjwatson> LaserJock: supported seeds are necessary for germinate to behave properly
<TheMuso> sahko: Afaik its still ongoing.
<cjwatson> LaserJock: it puts build-dependencies in their
<cjwatson> there (argh!)
<cjwatson> sahko: was mentioned in the minutes of yesterday's TB meeting, posted to ubuntu-devel. As TheMuso says, still ongoing.
<sahko> TheMuso: so discussion has started. from a;; sodes
<sahko> all sides*
<sahko> schilling too..
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027182.html
<LaserJock> cjwatson: ah, right. so is supported automatically generated at all? I'm looking at Edubuntu's and it doesn't seem right
<cjwatson> LaserJock: it's probably wrong, but is not very important
<cjwatson> looks like an old copy of Ubuntu's with some bits added
<LaserJock> yeah
<cjwatson> I wouldn't worry about it too much ...
<cjwatson> it used to be used for DVDs
<LaserJock> but will that prevent demotion?
<cjwatson> yes
<sahko> cjwatson: thanks. good luck with this to whoever participates. hope cdrtools get included in future versions. the fork is unusable
<LaserJock> cjwatson: ok, another quick question related to the DVD if you don't mind, how is the package list then determined?
<bryce> Keybuk: yep?
<Keybuk> bryce: you appear to have not included the changes I made in my last upload
<Keybuk> just the changelog entry
<bryce> hm, not by intention, let me doublecheck
<sahko> bye
<slangasek> calc: OOo-core still depends on librdf0?
<slangasek> calc: that's 2MB for librdf0, librasqal1, libraptor1, libmysqlclient15off, libpq5, mysql-common
<bryce> Keybuk: weird.  ok I'll look into it
<Keybuk> np :)
<slangasek> calc: actually, adding in the rdf recommends, that costs us 7MB total... I guess I'll look at whether those recommends can be reasonably demoted
<cjwatson> LaserJock: we haven't built Edubuntu DVDs for some time, so "it isn't"
<cjwatson> LaserJock: for Ubuntu and Kubuntu, we use a separate "dvd" seed nowadays
<LaserJock> cjwatson: right, but I thought you could install edubuntu-desktop for instance from the Ubuntu DVD
<bryce> Keybuk: heh
<bryce> Keybuk: looks like we both did our uploads at the same time
<LaserJock> I haven't personally used the DVD so I don't know for sure
<cjwatson> LaserJock: that works by the stupid hack of explicitly seeding the 'edubuntu-desktop' metapackage in ubuntu.jaunty/dvd
<cjwatson> see the comment above that seed entry
<cjwatson> and feel free to sync that up if necessary
<LaserJock> yeah, I see it
<LaserJock> and I need to sync that up since I'm dropping the edubuntu-addon bits
<LaserJock> cjwatson: ok, thanks, that helped
<calc> slangasek: yes and it actually Depends on lpsolve so it will probably break calc for alpha3 but i can see about getting suitesparse broken up into another package for alpha4 so calc won't be broken in it
<cjwatson> rickspencer3: do you know if anyone is going to look at bug 288494? it looks like it's missed alpha 3 now
<ubottu> Launchpad bug 288494 in totem "the youtube code needs to be updated" [Low,Confirmed] https://launchpad.net/bugs/288494
<cjwatson> rickspencer3: err, sorry, not alpha 3, I meant to say Ubuntu 8.04.2
<slangasek> calc: oh, correcting myself, the {redland,raptor}-utils recommends have only a minor impact on disk space.  librdf0 itself pulls in 6MB of deps.  What do we need that for?
<calc> slangasek: redland (librdf) is used to support ODF 1.2 metadata
<calc> it doesn't appear to be something that could easily be left out
<slangasek> argh
<calc> slangasek: rene seems to think reverting to internal would work well enough for now, but may need to switch back to external later (probably when we do split build for jaunty+1)
<calc> slangasek: would you like me to reroll it with internal redland and reverting the java change and have you drop help from the cd?
<slangasek> what do you mean, "reverting the java change"?
<slangasek> oh, re-adding it to help
<calc> slangasek: the issue you discussed with rene about help really needing java so help should just be dropped from the cd
<calc> yes
<slangasek> dropping help from the CD means either getting ArneGoetje to reroll language-support-translations-en, or dropping language-support-en from the CD
<calc> ah hmm
<calc> ArneGoetje: ping ? :)
<cjwatson> dropping language-support-en from the CD will have installer consequences
<calc> yea dropping it isn't really an option
<slangasek> what sort of consequences?
<cjwatson> it will tell everyone that they have incomplete language suport
<cjwatson> support
<cjwatson> and will prompt them during d-i installations to say that language-support packages are unavailable on the CD
<cjwatson> _Description: Download language support?
<cjwatson>  The installation CD does not contain full support for your language. Do you
<cjwatson>  want to download the required packages from the Internet now? This includes
<cjwatson>  spell-checking, dictionaries, and translations for various applications.
<cjwatson>  .
<cjwatson>  If you do not want to download this now, you may start the Language
<cjwatson>  Selector after installation to install complete support for your language.
<slangasek> hmm, right
<slangasek> cjwatson: what do you think about rerolling language-support-translations-en to not install OOo-help-en-*?
<slangasek> each .deb is ~6MB, dunno how much that'll buy us on the liveCD
<cjwatson> it's a plausible option
<bryce> Keybuk: uploaded.  Sorry bout that, looks like you put in your change right before I posted the merge.  Good timing.
<cjwatson> it could be rerolled by hand without the langpack-o-matic infrastructure if you're in a rush, as long as langpack-o-matic gets synced up afterwards
<slangasek> right
<slangasek> so if we do drop those deps, what will be the right component to pull in the help later for users?
<calc> do we even have a mechanism to do that?
<slangasek> that's the question
<calc> if there is adding all of OOo as an option to show the user would be extremely helpful ;-)
<cody-somerville> mvo, I just noticed that jaunty now has glibc 6.9
<cody-somerville> er...
<cody-somerville> 2.9
<slangasek> calc: that's not the kind of mechanism I had in mind; I was more thinking of a way to have the localization pulled in *when* you install the OOo metapackage
<calc> ah
 * calc thinks the other would be helpful also in other cases of abused Recommends demotion to fit stuff onto CD, etc :-\ Recommends used to mean more than just what we think you should have that also happens to fit on the CD
<slangasek> if I make this change, English will be the *only* language for which users don't automatically get OOo help files; and if you reupload -l10n, users of all the other languages get to download the 90MB of java as part of the language support download
 * calc still isn't quite sure what the ooo split build will do wrt CD space issues, fun for Jaunty+1 I'm sure
<slangasek> "split build" meaning what?
<calc> for one we will no longer have any internal libraries, at least afaict
<slangasek> well, so far using external libraries hasn't been an improvement
<calc> slangasek: splitting the monolithic source into the relevant modules and building without any internal copies of 3rd party libraries, etc
<slangasek> since librdf0 for some reason has to pull in libmysqlclient and libpq5 :P
<calc> so there will be a writer source, ure source, etc
<cjwatson> i.e. "modular OOo" (to go with modular X)
<calc> i'm targeting 3.1/3.2 for the switch depending on how the meeting goes at Sun next month
<slangasek> and how modular will it really be, given things like "your documents will be corrupted if you don't have -math installed"?
<moh_bana> hello, is it true that there's a free ver. of the broadcom drivers?  i've been trying to install this crap for ages with no luck
<calc> slangasek: once we get to that point I am hoping upstream will consider those type things to be real bugs
<calc> slangasek: currently they expect OOo to be installed, and as its monolithic all of it to be
<slangasek> sigh
<slangasek> splitting mysql/postgres off of librdf0 would probably also take care of the problem
<slangasek> the current size problem, that is
<slangasek> we still have the help package problem
<calc> well help as it stands doesn't install java now but also means the search doesn't work
<slangasek> yeah.
<calc> we could punt that decision to later i suppose
<slangasek> I'm trying to decide whether I want to mangle redland on the fly here, or wait for another round of OOo build
<slangasek> s
<slangasek> calc: <sigh> I think we're better off with rebuilding OOo to use internal redland, for now
<calc> slangasek: ok
<calc> i think that should be fine for this release cycle and then we'll have to see what OOo does in general when it becomes modular
<calc> i should have builds of that going by late march i think with 3.1
<slangasek> I'm going to file a bug with dajobe about wanting to be able to split off the mysql/postgres storage stuff
<calc> ok
<calc> slangasek: i'm going to eat lunch quick and then get the new upload done
<calc> slangasek: so just the redland change for a3?
<slangasek> yes, just the redland change please
<calc> ok
<calc> bbia 15m or so
<slangasek> (also means that we don't have to wait for both OOo and OOo-l10n to build)
<cody-somerville> mvo, Are you familiar with the Debian maintainers of valgrind? Do they plan to upload the new 3.4.0 version to enable support for glibc 2.9?
<SimoneB> is there a channel about app development in ubuntu? (or, to make it short, is there a genetic algorithm package in the ubuntu's repositories?)
<zorglu_> q. what is the default --prefix for ./configure on ubuntu ?
<Pici> !info python-genetic | SimoneB
<ubottu> python-genetic (source: genetic): genetic algorithms in Python. In component main, is optional. Version 0.1.1b-7 (intrepid), package size 21 kB, installed size 184 kB
<SimoneB> ahum, right. I hoped in a C version, but i'll take a look at that, thanks
<Pici> SimoneB: I just searched for 'genetic' in the repos. apt-cache search genetic  spits out a whole bunch of matches
<SimoneB> Pici: why did it have just 2 results when i did it? python-genetic and cl-rsm-genetic-alg (a lisp version)
<Pici> SimoneB: aptitude search, or apt-cache? aptitude only looks in package names by default
<SimoneB> Pici: ahhh! I did aptitude search, infacts. thanks.
<calc> back, working on ooo3 redland issue now
 * calc needs to run a test build to make sure disabling redland doesn't cause other build issues
<BUGabundo1> cjwatson: those the fix of bug 310083 fix the problem I reported today?
<ubottu> Launchpad bug 310083 in ubiquity "ubiquity crashed with KeyError in partman_edit_dialog()" [High,Fix released] https://launchpad.net/bugs/310083
<BUGabundo1> evand: ping
<evand> BUGabundo1: pong
<evand> BUGabundo1: can you rephrase your question, I do not understand what you're asking
<evand> the bug should be fixed in ubiquity 1.11.3
<evand> be sure to check you're using the correct version by running ubiquity --version
<BUGabundo1> evand: the bug that you marked as dupe of 310083
<BUGabundo1> today I tried to use yesterday live cd
<evand> that wont have the fix
<BUGabundo1> but ubiquity would change my partition schema
<evand> only today's CD does
<BUGabundo1> but marked it as a dupe, and I don't see a fix or mention for it in the bug
<BUGabundo1> I'll download tomorros (or tonight) daily build and test again!
<evand> it's a different symptom, but it's the same bug
<BUGabundo1> okay
<BUGabundo1> 'cause I never saw any crash!
<mvo> cody-somerville: I'm not familiar with the debian mantainer, sorry
<ScottK> LaserJock: Do we have any other Jabber servers in Main?
<LaserJock> ScottK: we might but I think ejabberd is the preferred one
<LaserJock> from what I've seen around the net it's one of the most common
<Nafallo> written in erlang ;-)
<LaserJock> looks like we have jabberd and ejabberd :-)
<ScottK> LaserJock: I think that's the first question.  If we have another one and we should have ejabberd instead, then I suspect it's a relatively easy sell.
 * LaserJock suddenly thinks he knows what the "e" might be fore
<ScottK> OK.  Well I guess then the question is can ejabberd replace jabberd ...
<ScottK> ;-)
<LaserJock> ScottK: what do you mean?
<LaserJock> why does it need to replace it?
<Nafallo> LaserJock: don't forget jabberd2 ;-)
<ScottK> So you aren't increasing the amount of stuff in Main.
<LaserJock> ScottK: there isn't a jabber server in Main
<afflux> what's jabberd? Can find only jabber and jabberd2, both in universe
<ScottK> OK.  I misunderstood then.
<BUGabundo1> I use ejabberd
<BUGabundo1> its quite good!
<hwilde> can someone explain how ext4 achieves the promised performance increases?
<BUGabundo1> much easier to setup then jabberd2
<Nafallo> ScottK: well, ejabberd would drag erlang along with it. not sure what kees have to say about that one ;-)
<afflux> I hate erlang, so I use jabberd2 :P
<LaserJock> afflux: jabberd is the daemon of jabber
<afflux> LaserJock: ah, thought you were talking about pkgnames
<BUGabundo1> afflux: I don't care what's under the wood. I just need it to work
<ScottK> Dunno.
<afflux> BUGabundo1: mine didn't, so I tried debugging, and that somehow just didn't work out.
<BUGabundo1> its working right now!
<BUGabundo1> from hardy up to jaunty!
<Nafallo> sql-backends for ejabberd seems to require unpackaged modules at the moment :-P
<BUGabundo1> I have one account f XMPP on my own laptop!
<Nafallo> I'm going to switch towards jabberd2 fwiw
<BUGabundo1> afflux: I said it *is* easier. I didn't say it was easy! took me 2 days to get it running as I wanted
<LaserJock> well, I don't know that we *have* to have ejabberd, it's just sort of the defacto one I think
<ScottK> LaserJock: It might be useful to discuss with Server Team.
<afflux> yep, it's quite common afaik
<BUGabundo1> there goes pidgin. but I'm back
<BUGabundo1> what did I loose?
<LaserJock> ScottK: in particular I'm not sure about bringing grep-dctrl into Main and lksctp-tools seems interesting as well
<LaserJock> so jabberd2 would pull in udns, gsasl, and libntlm
<kees> Nafallo: I don't have time to learn erlang at the moment.  ;)
<LaserJock> anybody up for some erlang?! :-)
<calc> is there a way to search for private bugs on a package that you can see?
 * calc wants to make sure that all the ones that should be public are marked that way already
<Nafallo> kees: that's about what I hoped you'd say :-)
<kees> calc: beg bdmurray to run magic queues for you?
<calc> kees: heh ok
<calc> i can just look through the list, i was talking about bugs that are marked private that I can see that shouldn't be marked that way
<calc> i didn't know if there was some way to search for them via launchpad search page
<superm1> can someone with appropriate rights let through mdomsch's post to ubuntu-devel ML?
<slytherin> does anyone know why has launchpad eaten squid-common in jaunty? squid is not upgradable (from intrepid version) in current state.
<Mithrandir> squid-common | 2.7.STABLE3-1ubuntu2 |        jaunty | all
<Mithrandir> it should be there.
<Mithrandir> hm, same version as intrepid.  Sure it's not just no longer built?
<Mithrandir> slytherin: ah, it FTBFS on i386
<slytherin> Mithrandir: I am not using i386, I am on powerpc. If you see launchpad page there is no squid-common binary, only squid and squid-cgi. But the build log for powerpc shows all binaries were built.
<TheMuso> slytherin: i386 builds arch all packages.
<Mithrandir> slytherin: -common is built on i386, and it's arch: all
<slytherin> ahh, didn't pay attention to that. my fault.
<Mithrandir> search for "Error 1" in http://launchpadlibrarian.net/21134518/buildlog_ubuntu-jaunty-i386.squid_2.7.STABLE3-2ubuntu1_FAILEDTOBUILD.txt.gz
<sconklin> bryce: ping
<bryce> sconklin: yes?
<bryce> sconklin: in general, it is better to just ask your question rather than pinging, since then you get your response sooner (and it interrupts the pingee only one time)
<sconklin> ok right. I'll ask it here again then.
<bryce> actually if it's X, come on in to #ubuntu-x
<bryce> then if I don't know, maybe one of the other guys there can chime in
<sconklin> I can't reproduce it now. It happened twice in a row, now won't fail
<bryce> mm
<sconklin> sorry for the fire drill
<bryce> sometimes those can be intermittent issues, you'll probably see it again
<bryce> I can give you a bit more advice if I at least know the driver and/or gfx chipset
<sconklin> once it's installed I'll get that and save it, and next time I'll just file a bug and save all the chatter
<bryce> okay cool
<sconklin> thanks!
<bryce> fwiw, for this class of problem there are registry dumping tools (at least, for -intel and -ati) which can be useful for troubleshooting
<bryce> also, if you have a digital camera, these kind of issues do well to be photographed
<bryce> the upstream guys can recognize different kinds of bugs based on the style of corruption seen on the screen sometimes
<bryce> heya Rocket2DMn
<Rocket2DMn> hey bryce
<bryce> sconklin: btw also check your /var/log/Xorg.0.log.old after rebooting for errors, and/or look in /var/log/gdm/ if the file from the previous boot contains any errors.
<sconklin> bryce: this was during an install from cd
<bryce> running ubuntu-bug will automatically capture most of this stuff
<bryce> ah yes rebooting from that won't help :-)
<sconklin> I realized that (I think) both times it failed it had been powered down, but warm started the times it succeeded. I'll have more chances to test again during the next few days
<Rocket2DMn> bryce, ive been pretty busy recently and will be for a bit, but im still keeping my eye out for X bugs
<bryce> Rocket2DMn: cool.  I got inspired a bit after our last chat and went through all the fully triaged segfaults, and fixed several of them :-)
<bryce> sconklin: ah that's a good observation.  It's not unusual for these corruption issues to be correlated to hibernate or suspend, so a correlation with warm-vs-cold boot wouldn't surprise me
<bryce> sconklin: DRI being enabled vs. disabled tends to also correlate to some of these
<bryce> so that's worth testing too
<sconklin> bryce: ok, thanks
<Rocket2DMn> bryce, sweet, progress!
<calc> ok the build worked so i will be uploading new OOo now
<slangasek> calc: ok, thanks
<slangasek> calc: btw, for the help stuff (post-A3), what do you think of the possibility of using the bundled lucene, and then help searching is covered by the "for the full suite, you need openoffice.org metapackage and java" warning?
<cjwatson> calc: private-ness is apparently not something you can search on (bug 66206) but you could do it, albeit more slowly, with the Launchpad API
<ubottu> Launchpad bug 66206 in malone "No advanced search option to search by bug privacy" [Undecided,Confirmed] https://launchpad.net/bugs/66206
<cjwatson> superm1: err, while I've approved it, it's totally inapplicable to Ubuntu - we don't use that man implementation
<cjwatson> I'll follow up on the list
<superm1> cjwatson, okay, i didn't see the contents of it yet myself.  mdomsch wasn't on the list and just asked if i could ping someone about letting it through
<calc> cjwatson: ok thanks, if i notice any while going through my bugs i will just work on them as i see them
<calc> slangasek: hmm yea that would probably work out ok, i can make that change before i upload if you want
<calc> slangasek: i was cleaning the tree and was just about to upload now
<bryce> superm1: btw when you get a chance could you doublecheck what I've written for -nvidia status on https://wiki.ubuntu.com/X/Drivers ?
<slangasek> calc: no need to change that before this upload, I don't want to wait on OOo-l10n anyway
<calc> ok np
<RAOF> Hm.  nouveau is still a bit wrong there.
<RAOF> nouveau should support everything the nvidia-glx-* supports, barring possibly really new cards.
<RAOF> Also, the kernel modules are still in NEW :)
<maxb> "nvidia-glx-177 (180.22 - Needs IgnoreABI)" <-- copy/pasto
 * RAOF waits for bryce to finish updating that wiki.
<maxb> About the vdpau stuff... what happens to the package naming when the next major version comes out?
<calc> who do i talk to about an 8.04.2 upload to fix my remaining targeted bugs?
<maxb> Perhaps they need to be providing/conflicting a common metapackage?
<calc> to verify its ok to do the upload ;-)
<bryce> RAOF: ok done, go ahead and edit if you'd like, I can wait :-)
<bryce> maxb: good catch, that should be 177.82
<bryce> maxb: there is a separate libvdpau-glx-180 package; is that what you mean?
<maxb> The thing is, that the files contained by the libvdpau  / libvdpau-dev packages are not named in version specific (or even nvidia-specific) ways, so won't some conflicts be needed somewhere?
<bryce> maxb: I don't think they conflict with anything at this point, but would imagine the packaging can be updated if/when that occurs
<bryce> maxb: but perhaps I don't understand...  superm1 can speak more definitively on this since he set it up
<RAOF> maxb: You're thinking of incompatible ABI changes, right?  sonames and ABI and symbols, oh my!
<maxb> Not specifically - I'm just thinking of how things can be arranged such that future versions don't have to list all the previous versions explicitly
<RAOF> Hm.  I should mention that nouveau will only be installable once nouveau-kernel-source gets out of NEW.
<RAOF> Why would they?  They'd just have a higher version string?
<maxb> But, the major number is embedded in the package name: nvidia-180-libvdpau
<maxb> For example, the nvidia-glx-NNN all provide and conflict nvidia-glx (though they then do explicitly list all the other versions in Replaces, so that doesn't completely allow them to be ignorant of what other versions are out there)
<RAOF> Oh, right.  Yeah.
<RAOF> I see what you mean now.  I was set off track by the mention of libvdpau / libvdpau dev.
<maxb> Sorry, I was prematurely abbreviating :-)
<directhex> :o
<directhex> you know what they say about premature optimization
<calc> slangasek: done uploading now :)
<slangasek> cheers
<m3ga> hi all, does anyone know anything about how the ocaml and haskell tools and libraries are snapshotted from debian to go into an ubuntu release?
<soren> Hm... My Xorg is eating up all of the one core on my laptop. I imagein this is due to some application flooding it with updates or whatnot. How can I see which application  is causing this?
<laprice> in trying to build a package, all of the files named *.ex are ignored right?
<laprice> I just need to create the plain versions and that will
<laprice> cause them to be built into the final package?
<ScottK> m3ga: I know 'not usually in an order that leads them to work', but not much more than that.
#ubuntu-devel 2009-01-15
<m3ga> ScottK: thats my problem :-) i've seen breakage in both ocaml and haskell libs.
<ScottK> What we need is someone who can tell us what needs to be done and in what order since none of use really know about those things.
<ScottK> If someone can do the analysis, we can probably make it happen.
<m3ga> i think what it needs more than anything is process; testing that the complete set o libs does work.
<m3ga> ScottK: does ubuntu  pull from debian testing or from debian unstable?
<ScottK> m3ga: This discussion if probably better on #ubuntu-motu since the packages are all in Universe.
<ScottK> m3ga: Mostly unstable.
<m3ga> ScottK: just joined -motu
<ScottK> OK.
<maxb> laprice: Correct, .ex just means "example" - though those files, even when renamed are not really "built into the package" so much as "used to build the package". Please direct similar future questions to #ubuntu-motu, which is a more on-topic forum for guidance on learning packaging.
<laprice> sorry, i didn't realize this was not the correct channel.
<TheMuso> slangasek: When you get a minute, I think we will need studio disks rebuilt, due to include the fixed apt-setup package. One of our testers ran into bug 316618.
<ubottu> Launchpad bug 316618 in apt-setup "jaunty alternate cd media change error" [High,Fix released] https://launchpad.net/bugs/316618
<TheMuso> slangasek: Thanks in advance.
<slangasek> heh, just making that comment on #ubuntu-tsting
<slangasek> or on #ubuntu-testing, rather
<TheMuso> he ok.
<TheMuso> s/eh/heh/
<cjwatson> superm1: (addressed Matt Domsch's mail now)
<calc> cjwatson: who is in charge of reviewing SRUs currently?
<calc> ah i found the group :)
<maxb> (roughly) how many days should I wait for ubuntu-devel@ moderation before seeking a kindly moderator here to expedite matters?
<superm1> maxb, eventually nvidia with have an open libvdpau library and those packages that were provided right now will go away.  they're named the way they're named right now in case that doesn't happen by the time nvidia-185-graphics-drivers is out
<superm1> nvidia didn't really provide a time frame for when libvdpau will be open
<superm1> bryce,^ if you are interested too
<maxb> So, if 185 shows up in the meantime, it will just need to conflict with 180 explicitly? And if additional versions, then the conflicts lines just grow longer, and hopefully nvidia gets around to doing it properly before it gets silly?
<superm1> maxb, exactly
<maxb> gg, makes sense
<superm1> once libvdpau is open it will be installed by default likely too since ffmpeg will likely be linking to it..
<ArneGoetje> calc: pong
<calc> ArneGoetje: heh nevermind slangasek and I worked out what he wanted to do for alpha 3, he had been thinking about rerolling langpacks but decided against it
<superm1> bryce, i updated one bit on there, but otherwise looks right
<bryce> superm1: great thanks
<ArneGoetje> calc: is there anything we need to change in the language-support packages for oo.o3?
<calc> ArneGoetje: i don't think so
<calc> i just found out the main drive in my computer is subject to sudden death at ~ 3mo of use
 * calc is going to back all his data up onto an external drive asap
<LaserJock> calc: 3 months?
<calc> yea the lovely Seagate 7200.11 1TB drives
<LaserJock> geeze, and 1TB too :(
<calc> http://forums.seagate.com/stx/board/message?board.id=ata_drives&thread.id=3668&view=by_date_ascending&page=1
<LaserJock> calc: too many OO.o builds? :-)
<calc> the 1.5TB had the problem which was revealed over a month ago and apparently they now know the 1TB are affected too but no solution yet
<ArneGoetje> calc: I avoid to buy Seagate and WD for exactly that reason. Too much bad experience.
<ArneGoetje> calc: the last WD I bought failed after 2 weeks. :(
<LaserJock> go Maxtor! ;-)
<superm1> um didn't seagate buy maxtor?
<superm1> eg http://www.seagate.com/maxtor/ existing
<LaserJock> ah
<LaserJock> well, there you go
<kees> craaap.  I've got 2 of those drives.
<ArneGoetje> I've never had problems with Hitachi
<RAOF> Hm.  Alpha-3 freeze means shephearding f-spot and tomboy through the gnome-sharp2 transition so I can get the new version of smuxi is... unlikely :)
<cjwatson> didn't hitachi make the notorious deskstar (aka deathstar)?
 * kees is currently backing up everything to is handy 1TB usb drive....
<ArneGoetje> cjwatson: that was IBM (before taken over by Hitachi), yes. But despite the name, I've never had any problems with them... maybe I was just lucky... ;)
<cjwatson> it's amazing how half the web forum posts I read castigate Ubuntu for doing nothing but changing the desktop background, and the other half complain about how we haven't changed the theme much for several releases
<ArneGoetje> but since my last encounter with WD (which costed me 20000 NT$ to get the data recovered by a profesional data rescue company, I have invested in a hardware raid 5 solution. :)
<cjwatson> (obviously both missing the point rather substantially)
 * kees needs eSATA.  usb is slow
<RAOF> Urgh.  The new volume control notification applet is really annoying.
<cjwatson> the way it's horizontal and semi-offscreen?
<RAOF> No, that's the new panel applet.
<RAOF> That's also more than moderately annoying.
<slangasek> RAOF: are the gnome-sharp2 bits in place in the archive?  we didn't have gnome-desktop-sharp2 yet, last I was looking at that
<RAOF> I'm talking about the notification icon that only pops up when something's playing a stream.
<RAOF> Meaning that it's impossible to change the volume before something starts playing, and the volume icon is always in a different spot.  Score!
<RAOF> slangasek: Looks all done to me.
<RAOF> https://edge.launchpad.net/ubuntu/+source/gnome-desktop-sharp2/2.20.1-2ubuntu7/+build/831357
<RAOF> Urgh, wrong page.
<slangasek> RAOF: ooh, ok.  Well, maybe we can transition f-spot and tomboy if we desperately need more CD space for alpha-3. :)
<slangasek> RAOF: you've confirmed that they build ok now against the new versions?
<RAOF> No, not tomboy or f-spot.
<RAOF> Did it for banshee, because that was something I could fix ;)
<slangasek> heh
<RAOF> I'll do it for the others now if you like
<slangasek> it would be useful to have that done so that we can transition them at the best opportunity
<RAOF> I'll check & attach debdiffs to the transition bug, I guess.
<slangasek> RAOF: awesome, thanks
<calc> backing up 1TB over USB is going to be slowww
<calc> should take ~ 14hr or so i guess
 * RAOF should get >=4GB of ram on his next purchase.  Building things on a tmpfs is just too nice.
<calc> RAOF: i'm thinking of buying another 4GB for my system to bring it up to 8GB (max for my chipset)
<RAOF> Well, that's not gone well.  Apparently no package in the archive contains gnome-panel-sharp-2.24.pc
<slangasek> RAOF: ah, that's what I meant earlier wrt gnome-desktop-sharp2
<slangasek> we need gd#2 2.24
<RAOF> Why did the -0ubunt1 build succeed then?
<slangasek> of which?
<RAOF> Of tomboy.
<RAOF> The upstream version doesn't seem to have changed.
<slangasek> because it was built against the older gnome-sharp2 that still had gnome-panel-sharp, I think
<slangasek> er, no; maybe it was that tomboy had code that, *if* it detected g# 2.24 or better at build time, it requires this new .pc
<slangasek> anyway, if gd#2 isn't updated yet, that's definitely the first step
<RAOF> Ah, yes.  There it is, conditional on gnome-sharp being >= 2.23.99
<RAOF> Right.  New gd#2.24!
 * RAOF goes and checks pkg-cli-libs
<RAOF> Ah, so no quick joy there.
<RAOF> And you made the last, unuploaded checkin to svn.  Score.
<ebroder> Any core devs willing to sponsor uploads into {hardy,intrepid}-proposed for LP #216761?
<ubottu> Launchpad bug 216761 in xen-3.3 "errors in xendomains init script" [Undecided,Confirmed] https://launchpad.net/bugs/216761
<ScottK> ebroder: We're in the middle of a freeze for Alpha 3, so no.
<ScottK> Unless it fixes something critical for Alpha 3
<ebroder> ScottK: It's not Jaunty - it's for Hardy and Intrepid
<ScottK> Oh.
<ScottK> ebroder: Since pitti asked bryce to sponsor it, I think I'll let him do it.  Otherwise you might ask zul.
<ebroder> Ok. Did bryce actually get that request? He wasn't subbed to the bug
<ScottK> Dunno, but I just highlighted him.
<ScottK> It's late here, but I imagine he'll get it eventually.
<ebroder> Ok, thanks
<nixternal> bryce: http://paste.ubuntu.com/105046/
<nixternal> there are a few of us witnessing this right now with kde4 in jaunty...any ideas?
<slangasek> calc: um, that's disturbing, OOo finished both i386 and amd64 in < 6h?
<pwnguin> slangasek: maybe database didn't build or something
<slangasek> calc: huh, but 2ubuntu3 took the same time, so I guess things got faster in 3.0?
<slangasek> or maybe the buildds got an upgrade and I hadn't noticed until now :)
<bryce> nixternal: weird, never seen that
<bryce> actually...
<bryce> exaCopyDirty sounds familiar
<nixternal> bryce: ya, we noticed that tonight, however it seems to not be the root of our issue actually...there are one of two things going on that are kde4 related..but I thought I would pass that by you
<det> When I upload a new package to that replaces an older one (the name of the package changed, what can I do to ensure that an aptitude upgrade will upgrade the package), I tried putting "Replaces: X" in the control file, but it isnt working.
<slangasek> you would want to create a "dummy" package under the old name to ensure upgrading
<slangasek> but why did the package name change?
<det> It is in a PPA, and the old maintainer gave it a confusing name.
<slangasek> ok
<slangasek> creating a dummy package is the only way to ensure an upgrade
<det> ok, thanks
<det> I think I have another solution, actually.
<det> There is 1 metal package that people install to bring in all the packages, so I just added a conflict on the old package in the meta package
<det> meta*
<det> and changed the depend on the new package
<slangasek> right, if you have a top-level package whose name will stay the same, that's a better solution :)
<det> Btw, what is the best way to ensure that a hardy package has an lesser version number than an intrepid package
<det> Is there any kind of established naming scheme ?
<det> Right now I am using "XXX-0ubuntu1~ppa2" for intrepid and "XXX-0ubuntu1~ppa1" for hardy
<det> It would be nice to number then independently somehow
<det> XXX-0ubuntu1~ppaX and XXX-0ubuntu2~ppaX maybe ?
<RAOF> I tend to use foo-0~intrepid~ppa1, foo-0~hardy~ppa1, etc.
<det> RAOF, does that only work because I > H ?
<slangasek> yes
<slangasek> I would lean towards foo-0~ppa1~{hardy,intrepid} or foo-0~ppa1{hardy,intrepid}or foo-0~ppa1.8.{04,10}; that way the release it's built for is the least significant part of the version
<det> btw, how do "-" and "~" differ ?
<slangasek> ~ sorts earlier than anything, including end-of-string
<slangasek> - has a special meaning, in that the last occurence of it in a version number is taken to be the delimiter between the upstream version and the Debian revision
<RAOF> slangasek: But that won't sort below official backports?
<det> btw, why use "-0", I was told to use "-0ubuntu1", but I dont understand the rational for either
<slangasek> RAOF: well, true; I wasn't worrying about those
<slangasek> det: if Debian hasn't packaged that upstream version yet, we use "-0" so that our versions sort earlier than an eventual "-1"
<slangasek> in theory the Debian maintainer could release a -1 version that includes all of our changes, and we want to ensure we'll be able to sync that version from Debian
<det> Ok, thanks
<det> why the 1 on the end then ?
<Mithrandir> det: because we might want to update the packaging or add patches later too
<Mithrandir> so it might be 0ubuntu2, 0ubuntu3 and so on
<det> XXX-0~0hardy~ppaX and XXX-0~1intrepid~ppaX, does that seem like a reasonable scheme ?
<det> basically, RA0F's scheme, except prepend a number to the codename
<LaserJock> why would you do that?
<det> seems like a bad idea to depend on the sort order of the codename
<LaserJock> that's why the codenames sort
<Mithrandir> better use the release version, then.
<det> for now :-)
<det> they cant do that forever
<det> and they didnt always sort in the past
<LaserJock> since breezy
<det> release version is a good idea, thanks
<det> XXX-0~8.04~ppaX and XXX-0~8.10~ppaX it is
<Amaranth> guaranteed to work until the year 3000
<det> Anyways, after Zany Zebra, this sorting system breaks down
<det> and I dont like to use things that are fundamentally broken
<det> and not until year 3000
<StevenK> Amaranth: Further, since we only minus 2000
<det> we are on j very soon, so 16 letters left, aka 8 years
<Amaranth> StevenK: I guess if you want 100.4 :P
<det> Thanks for the help guys
<Amaranth> err, that'd be 2100
 * StevenK laughs
<Amaranth> so, good until then
<Amaranth> might need a new scheme if it makes it that long
<det>   spring: Depends: spring-lobby which is a virtual package.
<det> argh
<det> I made the metal package conflict with the old package, and depend on the virtual package that the new package provides
<det> but aptitude is complaining
<det> meta*
<det> $ apt-cache show springlobby | grep Provides
<det> Provides: spring-lobby
<det> $ apt-cache show spring | grep Depends
<det> Depends: spring-engine, spring-lobby, spring-installer, ca-installer
<det> Am I doing something that is not allowed ?
<dholbach> good morning
<ion_> Howdy
<siretart> could you please give us your opinion on the jack issue? my last update to the mailing list was on monday, but the issue is open since mid december
<siretart> -ECHAN, sorry
<LaserJock> siretart: is that JACK in Main?
<siretart> LaserJock: no. I currently don't see jack suitable for main
<siretart> but that's just my personal humble opinion
<LaserJock> darn
<LaserJock> all the music apps that would be nice to include in Edubuntu require JACK
<LaserJock> however we are working on some Universe metapackages that would make it less of an issue I think
<asac> siretart: what happened to the glorious iceowl/experimental upload ;)?
<siretart> asac: ah, on my harddisk, not uploaded yet. just a sec
<siretart> LaserJock: do you know someone actively working on jack in ubuntu?
<LaserJock> siretart: there was discussion for Intrepid with Ubuntu Studio folks
<LaserJock> siretart: I think bigon perhaps was looking at it
<bigon> LaserJock: at jack?
<Baby> LaserJock: ping!
<LaserJock> bigon: maybe my memory is failing me, it's almost 2am :-)
<LaserJock> Baby: yeah?
<Baby> LaserJock: are you looking at KDE4 as a foundation for an educational desktop for kids? (ref: http://laserjock.wordpress.com/2009/01/13/why-we-need-edubuntu-to-succeed/ )
<bigon> LaserJock: I dont remember I've work on jack
<siretart> asac: uploaded
<LaserJock> bigon: hmm, were you looking at freebob?
<asac> siretart: thanks
<LaserJock> Baby: Edubuntu is currently "adding on" to both Gnome and KDE4, however I'm currently interested in what KDE4 can offer
<LaserJock> Baby: maybe pop over to #edubuntu and we can chat about what Debian's doing
<Baby> I'm very interested in KDE4 as a foundation for a desktop targeted at kids (Debian Jr project). I've just talked to Aaron about it, even though it doesn't have direct educational purposes, I think it would be good to collaborate
<Baby> yup :)
<cjwatson> det: you mentioned using Replaces earlier; it doesn't mean quite how you described it, and you should probably read the policy manual carefully because this is an area where people often get confused
<cjwatson> det: A Replaces: B on its own actually just means that A contains some files also contained by B (so B here is usually "foo (<< some-version)")
<det> I went the dummy package route
<det> A Replaces B; A Conflicts with B; New dummy package of B that depends on A
<cjwatson> for a single package with no complicating dependencies from elsewhere, Conflicts+Replaces+Provides should do it; the Provides may not always be necessary
<cjwatson> slangasek is right that there are cases that can only be solved by a dummy package, though - apt doesn't always work it out
<cjwatson> (Conflicts+Replaces means something completely different from Replaces alone)
<mdz> mvo: have you seen bug 312092?  It seems to break upgrades from intrepid to jaunty
<ubottu> Launchpad bug 312092 in update-manager "Failed to update to jaunty via update-manager " [High,Triaged] https://launchpad.net/bugs/312092
<mvo> mdz: checking it now, thanks - I think its a side-effect of new code that tries to ensure that if one component is enabled it should be used consistently (in -updates and -security as well) - looks like partner somehow entered this
<mdz> mvo: yes, that's what the log messages seem to indicate
<mdz> mvo: I have a system ready to upgrade to jaunty if you want a tester
<mvo> mdz: thanks, I will ping you when its fixed
<slangasek> tkamppeter: milestone freeze is still in effect, please don't upload new upstream versions of packages that are on the CDs right now
<jakon> A regression has been found in acpi-support released yesterday: apm of desktop disks is set to 128 instead of 254
<jakon> -> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/59695/+text)
<jakon> The regression is in acpi-support (0.109-0hardy1)
<cjwatson> jakon: have you suspended and resumed?
<cjwatson> slangasek: ^-
<jakon> This has nothing to do with that i guess
<jakon> There are two bugs in the scripts
<jakon> They don't handle the case of on_ac_power returning 255.
<slangasek> hmm
<jakon> I attached two patches that should fix this to the bug tracker (last 2 comments)
<slangasek> the second is a patch to the resume script; I see the bug, but how does that change anything on a non-laptop system?
<slangasek> or do you mean for it to be applied to all four copies of the script?
<jakon> Oh yes
<jakon> The script in resume.d is irrelevant (the whole folder is)
<slangasek> not entirely
<slangasek> it just isn't used by default
<jakon> ;) ok
<slangasek> sigh; there's nothing about acpi-support that doesn't make me weep
<tkamppeter> slanagsek, sorry, but changes are small, as we already had Foomatic 4.0 development snapshots in Intrepid. So all these packages are only bug fixes (for the last bugs fixed before Foomatic 4.0 official release).
<slangasek> tkamppeter: doesn't matter, they're not supposed to be uploaded during the freeze.
<slangasek> cjwatson: acpi-support 0.109-0hardy2 uploaded to hardy-proposed, please review
<cjwatson> slangasek: will do, can you mail the TB (CC me) as per standard procedure for regressions?
<slangasek> yes
<cjwatson> accepted
<slangasek> gar, bug #59695 is way too unwieldly
<cjwatson> tkamppeter: the reason not to upload these things despite the small changes is that they can cause other builds to be delayed, which causes a problem for the release manager getting things out on time especially when he's already been up for too many hours
<ubottu> Launchpad bug 59695 in dell "High frequency of load/unload cycles on some hard disks may shorten lifetime" [Low,Confirmed] https://launchpad.net/bugs/59695
<slangasek> I'm getting repeated timeouts :(
<Hobbsee> slangasek: try edge.launchpad.net
<Hobbsee> hrm.  it's falling over on that too, it seems.
<slangasek> I got it to load at last, so I'm good now
<cjwatson> if Ralph and Jakob confirm the fix, and somebody on a laptop confirms that it doesn't regress for them, I think we can push this on through to -updates
<cjwatson> do we need to block downloads of 0.109-0hardy1 and 0.114-0intrepid1?
<slangasek> jakon: can you test the 0.109-0hardy2 package once it's built and available in hardy-proposed?
<slangasek> cjwatson: the impact of the regression is to cause decreased drive performance on systems with acpi-support installed and without batteries; I'm not sure the user-facing disruption of blocking the downloads is warranted
<jakon> Yes, can test that
<cjwatson> it's only decreased performance, not damage?
<jakon> I guess
<cjwatson> I don't know, I was asking
<slangasek> cjwatson: until we roll out the new update, affected systems will have a greater rate of increase in load cycle count as well
<jakon> There won't be any immediate damage
<slangasek> but nothing that should be damaging if we're rolling out a new update shortly
<pochu> could a core-dev please approve the Intrepid task in bug 295490? TIA.
<ubottu> Launchpad bug 295490 in liferea "Liferea doesn't start with "Aborted" error." [Medium,Fix released] https://launchpad.net/bugs/295490
<jakon> I don't know if there are (old? strange?)disk that will hang when set to apm 128
<slangasek> jakon: well, I don't think we should take precipitous action based only on speculation that some drives might fail under standard conditions
<jakon> There is certainly no need to act precipitately, but this should be fixed sometime soon.
<jakon> The "hanging" ide led reported in launchpad frightened me a little
<slangasek> yes, working as fast as I can to get it fixed
<cjwatson> slangasek: I just noticed that I declared "layers" to be the Name in archive-reorg and that you objected to it on the grounds that they weren't layered. Can I convince you on the grounds that they're partially layered? :-)
<slangasek> haha
<slangasek> I don't think you can cnvince me, but you can make the declaration anyway and I'll live with it
<cjwatson> (I figured I'd just take the blame)
<cjwatson> actually I was sort of also thinking of them as something that a user could layer onto their minimal system
<cjwatson> but mostly as "oh my god we have spent hours on this name"
<Hobbsee> snowflakes!  :P
<cjwatson> I'm noticing an amazing similarity between this IRC log and the log of the one coinciding with that UDS session that I happen to have open ...
<cjwatson> oops
<jakon> Just a note for testing acpi-support: I don't have desktop pc, i faked one by replacing on_ac_power with a "exit 255" shell script. But that should do i think.
<slangasek> cjwatson: 0intrepid2 accepted
<slangasek> cjwatson: er, no it wasn't
 * slangasek reads the whole subject line
<slangasek> cjwatson: ok, there - /now/ 0intrepid2 is in unapproved
<cjwatson> slangasek: accepted
<slangasek> thanks
<maxb> How long should I wait for ubuntu-devel@ moderation before it becomes reasonable to ask on IRC for a kindly moderator to expedite matters?
<emgent> mvo: ping
<Riddell> calc: I see the openoffice source has patches for KDE 4, have you tried them?
<mvo> emgent: pong
<jakon> slangasek: acpi-support 0.109-0hardy2 looks good, just tested it
<slangasek> jakon: great, thanks.  Could you follow up to the bug report as well?
<jakon> Will as soon as launchpad is up again
<jakon> Ok, that is now.
<jakon> Commented in launchpad
<jakon> slangasek: Do you plan to use the pm-utils script i posted? ( http://launchpadlibrarian.net/21210580/95hdparm-apm ) Because it also contains this bug. If yes, i will update it.
<slangasek> jakon: hadn't looked at it in detail yet
<calc> Riddell: yes they don't work
<calc> Riddell: i'm going to be talking to some people to see about why soon
<calc> Riddell: i used them in the previous build from a few weeks ago and got lots of bug reports about it not working at all
<Riddell> calc: a shame, do you know who was working on them?
<calc> Riddell: i think Kendy of Novell
<calc> but i haven't pinged him about the KDE issue yet
<calc> Riddell: just asked him but i am not sure if he is online right now
<jakon> quit("Bye")
<jakon> Whatever.
<calc> Riddell: kendy says it is pretty much completely broken and he hasn't had time to work on it
<lool> siretart: Do you have any commit on upstream xine-lib?  I'd love it if you could merge the two "%s" additions upstream
<Riddell> calc: a shame that
<calc> Riddell: it will work better with kde3 support than it does in alpha3, aiui the file picker is missing currently
<calc> Riddell: but it won't have full kde4 integration unfortunately :(
<calc> Riddell: gio support doesn't work right either but it is being worked on luckily
<rtg> superm1: wrt bug #317270, can you clarify which kernel version? I assume its Jaunty.
<ubottu> Launchpad bug 317270 in linux "Dell Studio XPS 16 touchpad doesn't return from resume" [Undecided,New] https://launchpad.net/bugs/317270
<superm1> rtg, yes that was with jaunty
<rtg> superm1: thanks
<mib_uo1mgbbs> hi
<mib_uo1mgbbs> anyone familiar with ext4? may I use ext4 as logical drive?
<cjwatson> mib_uo1mgbbs: ext4 is independent of whether you're using primary or logical partitions (so "yes")
<mib_uo1mgbbs> the funny thing is while i'm installing xubuntu 9.04, I choose ext4 as logical drive cos my primary drive is winxp, the partioner dunno for what reason is showing ext3
<mib_uo1mgbbs> can anyone enlighten me?
<calc> ugh my laptop just died i think
<maxb> mib_uo1mgbbs: ext4 can be misinterpreted as ext3 by things which don't know about ext4 properly
<LaserJock> calc: hard drive?
<calc> LaserJock: no it just went black showed a bunch of blue crap on the screen then didn't respond, its rebooting ok though
<calc> LaserJock: i'm still working on backing up my desktop though
<mib_uo1mgbbs> is there a way I can confirm wheteher I'm currently using ext4 or not?
<calc> mib_uo1mgbbs: mount?
<mib_uo1mgbbs> i need to restart my computer to boot xubuntu
<cjwatson> mib_uo1mgbbs: there was a known partitioner bug that may have caused that kind of symptom; make sure you're running an absolutely current daily build
<cjwatson> maxb: really shouldn't be relevant in the installer, I believe I've caught everything
<cjwatson> mib_uo1mgbbs: if you're encountering this with a current daily build, please don't ... reboot
<cjwatson> bah in excelsis
<calc> i think the fuse ntfs support is a bit buggy, my drive claimed to be full when i used around half of it
<calc> so i reformatted it as ext3
<calc> well didn't really claim to be full but refused to allow me to write any more to it in any case
<cody-somerville> calc, that could be due to an error causing it to remount as ro
<calc> got a bunch of cp: cannot create regular file "foo" Operation not supported messages
<calc> hmm maybe it remounted during the middle of the copy, not certain
<calc> it copied about 390GB of 500 to do when it showed those
<cjwatson> EOPNOTSUPP is rather unusual and does *not* mean "disk full"
<cjwatson> ntfs-3g appears to return it basically when it gets garbage requests
<calc> hmm ok
<calc> it did that for cp and mkdir, etc
<cjwatson> Ng: I'm trying to work out what's happening in this bug of yours - it seems that there may be multiple problems
<cjwatson> Ng: can you tell me what you did at the ignore/cancel prompt?
<siretart> lool: err, how comes that the translations are THAT broken?
<Ng> cjwatson: I tried both, neither took me to any kind of disk selection thing, they'd just bounce me to the menu (I assumed that Ignore was thinking I just had a strange disk and I'd fix it up with partman, but partman clearly didn't want to run)
<Notch-1> anybody knows what means "unexpectedly too meny pseudo-links" from aufs? i'm using kubuntu intrepid in live mode with persistence file (with both -7 and -9 kernel)
<siretart> lool: and does this also happens with the translations provided by upstream?
<cjwatson> siretart: separate bug we're investigating
<cjwatson> nevertheless it is still a xine bug (and probably a security flaw)
<cjwatson> gettext and gcc provide facilities to test for this, which for some reason didn't manage to fire in this case
<cjwatson> gcc handles it under -Wformat-security
<siretart> users can override the paths gettext uses?
<cjwatson> translations should not be considered fully trusted anyway; show me a maintainer who reads every line of every translation they merge
<mvo> mdz: a fixed upgrader is now availabe (for the bug you mentioned earlier
<Ng> cjwatson: I think my suggestion would be that if partman fails to run and there are other disks in the system, offer to choose one, or maybe add that as a third option in Ignore/Cancel
<siretart> sure. I'm just wondering about the severity of the issue. and if that would warrant updating released versions of xine-lib
<cjwatson> Ng: Ignore should do just that
<lool> siretart: I don't think so
<Ng> hrm
<cjwatson> it doesn't need a third option which basically just means Ignore
<lool> siretart: No
<Ng> cjwatson: perhaps it's something special about the disks being under /dev/cciss/ that confuses it?
<cjwatson> Ng: I doubt it
<cjwatson> siretart: I was under the impression that TEXTDOMAINDIR overrode such things
<cjwatson> though I have not checked; but in any case I don't think that's relevant
<Ng> cjwatson: hmm, ok. well I've pulled the unused card out of the machine so I could actually install it, so we do have the card floating about and could probably drop it into similar hardware to reproduce it again
<cjwatson> Ng: I expect there are multiple bugs here really, I'm just trying to break it down
<mdz> mvo: I will test, thanks
<cjwatson> Ng: in particular there seems to be a bug in partman's error handling, which is why I asked what you selected
<cjwatson> I may have introduced that recently
<cjwatson> Ng: after that, partman will have been completely buggered which probably explains the later problems
<Ng> ah :)
<Notch-1> also, casper seem to boot only if i unplug & replug the pendrive first, otherwise i got dropped to a shell... i'm at 4th trial...
<Notch-1> what is casper-snapshot for? i'm reading the man page but still i don't understand :P
<Notch-1> it's used to enable the home persistence? or i can simply put a home-rw named empty image to the pendrive and boot?
<siretart> lool: 19:18:30 < _ds_> ISTM that the second half of the patch is broken anyway: looks like the wrong xine_log is patched.
<siretart> lool: perhaps you could join #xine/oftc and discuss it directly with darren?
<Ng> cjwatson: huh, looks like the next machine on my list has the same hardware. Is there anything I can do RightNow to provide more information? otherwise I need to yank that card too ;)
<lool> siretart: sure
<rtg> kirkland: after selecting the encrypted home option, I'm curious why I still have a .Private ecryptfs mount. Is this expected behavior?
<kirkland> rtg: that's where your encrypted data goes
<kirkland> rtg: /home/rtg/.Private gets mounted on /home/rtg
<rtg> kirkland: What does encrypted home mean? I thought it would supersede .Private
<kirkland> rtg: yes
<kirkland> rtg: ALL of /home/rtg will be mounted on /home/rtg/.Private
<kirkland> rtg: we just need a place to put your encrypted data
<kirkland> rtg: and that place is /home/rtg/.Private (for lack of a better place to put it)
<rtg> kirkland: that makes my head hurt. how can I mount on a directory that is within the filesystem being mounted?
<kirkland> rtg: easily.  by just doing it.
<rtg> ugh.
<kirkland> rtg: where would you prefer this data?
<kirkland> rtg: alternatively, we could mount /home/rtg on top of /home/rtg
<rtg> kirkland: no preference, I'm just confused.
<kirkland> rtg: but i found that even more confusing
<rtg> perhaps my understanding of file name spaces is insufficient.
<kirkland> rtg: sorry, am i being to terse?
<kirkland> too terse?
<kirkland> rtg: when your encrypted home is unmounted
<kirkland> rtg: your home data is unvailable
<rtg> kirkland: speaking of file names, in what state is Halcrow's filename encryption patch?
<kirkland> rtg: your unmount /home/rtg dir is perm'd 500
<kirkland> rtg: so you can't write anything inadvertantly there
<kirkland> rtg: you have a couple of symlinks in that dir
<rtg> kirkland: ok, I'll ssh as root and mess with it.
<kirkland> rtg: pointing to your .ecryptfs meta data
<rtg> yeah, in /var/lib
<kirkland> rtg: and a README.txt telling you that your home data is not mounted
<kirkland> rtg: when you do mount your encrypted home dir
<kirkland> rtg: the stuff in /var/lib/ecryptfs/rtg is used to basically do:
<kirkland> rtg: mount -t ecryptfs /home/rtg/.Private /home/rtg
<kirkland> rtg: and then all of your data is decrypted through that mountpoint for you
<kirkland> rtg: and .Private is masked from your view
<kirkland> rtg: which keeps you from farting around inside of there
<rtg> its the mount abstraction that I found confusing. I didn't know you could do that.
<kirkland> rtg: yup yup
<rtg> cool. how about file name encryption?
<Ng> cjwatson: probably unnecessary, but just to confirm, the hardware boots fine post-install if I put the empty controller card back in
<kirkland> rtg: i'm pinging tyhicks
<cjwatson> Ng: yeah, I'm sure it's just parted. I'm probably not going to do anything more withit until tomorrow though, sorry
<kirkland> rtg: it's been the salting of filenames that has given them trouble
<Notch-1> excuse me, the .Private dir is really mounted on /home/userhome ?? i tried the encripted home only in ubuntu studio but it seem simply to mount the encrypted dir in /home/userhome/.Private, what i'm missing?
<cjwatson> *with it
<kirkland> rtg: i'll send tyler an email, and cc you on it, asking for status, and the possibility/difficulty of us carrying it
<Ng> cjwatson: that's fine. I may well come back here tomorrow anyway. I'm not done and it's reassuring to be here in person for random acts of madness ;)
<kirkland> rtg: <tyhicks> kirkland: I got an email saying they were removed from morton's tree and placed in linus' tree
<rtg> Notch-1: don't confuse the Intrepid Private option with Jaunty encrypted home. they look quite similar. Hence the previous discussion.
<rtg> kirkland: no shit, I'll go look.
<kirkland> rtg: this is without salts
<kirkland> rtg: so this is more like "filename obsfucation"
<rtg> kirkland: so, encrypted but crackable 'cause all filenames use the same key?
<Notch-1> ah ok thanks, so jaunty has the entire home encrypted while intrepid use only the .Private dir, right?
<rtg> Notch-1: correct
<Notch-1> thanks
<Notch-1> excuse me, another flash question: to enable loop-aes i can simply use module-assistant?
<rtg> Notch-1: I believe you can choose to _not_ encrypt home, then install ecryptfs-utils later on in order to encrypt just .Private.
<rtg> kirkland: true? ^^
<calc> interesting it appears sparc wanted to build OOo this time
<Notch-1> nono, i prefere entire home encrypted, thanks :P
<rtg> Notch-1: well, that has performance implications of you're a developer.
<rtg> s/of/if/
<Notch-1> you mean with entire home encrypted or with loop-aes module?
<rtg> Notch-1: entire home
<Notch-1> oh sure, it's not a big deal for me...
<kirkland> rtg: that's absolutely true
<kirkland> rtg: encrypting just Private will still be supported
<kirkland> rtg: useful for auto-login systems, for instance
<rtg> kirkland: you'd just about have to for the dist-upgrade case.
<kirkland> rtg: where you want to automatically login, but not mount up your documents until you need them
<kirkland> rtg: i'm going to *try* and get a live migration script working
<kirkland> rtg: i have it written down on paper; not implemented it
<kirkland> rtg: will probably hack on it on the plane over to Munich
<rtg> speaking of which, we should finalize our plans a bit. phone call next week?
<Nafallo> kirkland: hehe. running screen-profiles on my laptop :-)
<Nafallo> kirkland: works a lot better since last time I tried.
<LaserJock> hmm, CD size must really be tight if we're dumping tracker off for the moment :-)
<Keybuk> LaserJock: not really, since it's not even enabled by default
<rtg> kirkland: I backported all of the relevant patches to fs/ecryptfs since v2.6.28. Next I'll see if it actually works. Some file name encryption is better then none.
<kirkland> rtg: cool, thanks.  keep me posted
<kirkland> rtg: also, if you publish a test kernel, i'll gladly try it in a kvm
<rtg> kirkland: gimme a bit, its just about done building
<rtg> kirkland: I'll send an email later. I'm gonna go catch some rays. its the first sun we've had in a couple of weeks.
<kirkland> rtg: sounds fine by me
<rtg> kirkland: watch in http://people.ubuntu.com/~rtg/2.6.28-4.11-ecryptfs. the debs are copying, but I haven't tested them. I'll check back in a few hours.
<kirkland> rtg: cheers
<calc> looks like Seagate might be announcing the 7200.11 problem tomorrow
<calc> as of today their tech support still denies there is anything wrong with the drives
<calc> if anyone here has a seagate 7200.11 be careful with it as it sounds like the problem may affect the entire line-up
<BUGabundo> sebner: ping
<BUGabundo> just updated bug 308985
<ubottu> Launchpad bug 308985 in seahorse "seahorse segfault when adding remote server ssh key" [Medium,Invalid] https://launchpad.net/bugs/308985
<calc> slangasek: ping
<DktrKranz> BUGabundo, he's won't be online too often, he's in army right now. He will probably on IRC during weekends, though.
<BUGabundo> maybe I got the wrong nick?
<BUGabundo> looing for sebastien
<BUGabundo> humm seb something!
<calc> BUGabundo: its late for seb128 so he may be asleep
<BUGabundo> I guess sebner was the 1st and only catch of my auto complete DktrKranz
<BUGabundo> thanks calc
<BUGabundo> I'll wait for the bug mail
<DktrKranz> BUGabundo, heh :)
 * BUGabundo blames autocomplete
<Keybuk> take *that* lsb_release
<BUGabundo> Keybuk: !cat /etc/lsb-release | head -n 2
<BUGabundo> DISTRIB_ID=Ubuntu
<BUGabundo> DISTRIB_RELEASE=9.04
<Keybuk> holy crap
<Keybuk> that one little change reduces the boot speed by 6-8s alone!
<Keybuk> 54s seems to be the right cut-off point here
<Keybuk> 71s in intrepid
<Keybuk> so that's 17s faster now ;)
<Keybuk> rtg: \o/
<slangasek> calc: pong
<BUGabundo> Keybuk: here are mine http://fileland.bugabundo.net/fotos/Linux/bootchart
<BUGabundo> let me upload the lastest there
<calc> slangasek: the disks are still oversized?
<BUGabundo> calc: daily are... the alpha3 shouldn't be
<BUGabundo> let me check
<slangasek> calc: desktop CDs are a little oversized.  We spent the night applying some questionable liposuction techniques, they should be down to size here in the next few hours
<BUGabundo> calc: http://cdimage.ubuntu.com/releases/jaunty/ A3 still isn't out
<calc> slangasek: ah ok
<calc> BUGabundo: yes i know, i was wondering if he needed any more changes for OOo :)
<BUGabundo> ahh
<BUGabundo> calc: we are getting new packages daily now of OOo from the PPA?
<calc> BUGabundo: i think i helped reduce it by ~ 90MB ;-)
<BUGabundo> not bad
<calc> BUGabundo: no not daily, i was doing them as i updated for jaunty but it became too much work this week, but i should put a new version in ppa for rc2
<calc> BUGabundo: iow its far from automated daily ;-)
<BUGabundo> calc: I ask because I've been getting packages for the last 3 days
<BUGabundo> how is in charge of synaptic?
<BUGabundo> or better yet the quick search?
<primes2h> ogra: Are you here?
<primes2h> ogra: Hello for first...
<ogra> primes2h, i was about to cal it a day, wahts up ?
<primes2h> ogra: :-) There is a patch that needs to be uploaded in Hardy. bug #211710
<ubottu> Launchpad bug 211710 in xaos "Wrong characters codification in Xaos translation - broken UTF support" [Undecided,Confirmed] https://launchpad.net/bugs/211710
<primes2h> you commented it  some time ago...
<primes2h> Tormod provided a patch for Hardy and he tested it.
<ogra> primes2h, oh, right, that somehow drowned in my huge todo list
<primes2h> I just subscribed ubuntu-sru but it needs to be uploaded in main, so I asked you...
<ogra> i'*ll take care for it (not tonight anymore, but i'll care, promised :) )
<james_w> does anyone know if we will have python-central for jaunty?
<primes2h> ogra: Thank you very much, do it when you want... :-)
<james_w> the new python-central, sorry. 0.6.8?
<ogra> thabks for the head up ... i really forgot about it
<primes2h> ogra: Don't worry, I can understand you, I usually have a lot of things in my mind and sometimes I face this kind of problem too ;-)
<ogra> :)
<calc> is there a way to tell cp not to follow mounts?
<Mithrandir> -x ?
<calc> ah i just searched for the wrong thing, thanks! :)
<Keybuk> calc: though that doesn't work on bind mounts, for obvious reasons
<kees> hrm, usplash bouncer hangs during input
<kirkland> cjwatson: lookey there .... a member of ~rosetta-admins for 3 hours now :-)  i wonder if I can talk you into reviewing the po/pot i submitted for screen-profiles :-P
<cjwatson> I'm only there for emergency work
<kirkland> cjwatson: (not urgent at all)
<kirkland> cjwatson: gotcha, no worries
<kirkland> cjwatson: happened to catch your name, and tenure, figured i'd pick on the rookie
<cjwatson> yeah, I'm not a regular member, as it were, or you'd be justified
<cjwatson> (actually I may not even need my access, will see)
<Skiessi> can I ask here for a package to be upgraded?
<Skiessi> bristol is a bit out-of-date
<directhex> Skiessi, if it's not in Main then here's not the place to ask
<Skiessi> okay
<kees> Keybuk: so, the new udev doesn't respect the old saved interface names?
<Keybuk> it should do
<kees> Keybuk: ah! hm. it moved my eth0 to eth5 because the kernel driver name changed.
<kees> er, no...
<kees> wtf happened.
<Keybuk> pastebin < 70-persistent-net.rules
<kees> I will, need to get the net back up on that machine
<kees> where is ifrename go?
<kees> s/is/did/
<Keybuk> it went away
<Keybuk> to the darkest, blackest pit from whence yada came
<Keybuk> (if it had a command-line "rename this interface to this" mode, it might have stayed around - but it was expressly written as a boot time thing with conffile, so we dropped it in favour of udev renaming)
<kees> I liked having it around.  means I can't set device names without rebooting.  :(
<slangasek> kees, jdstrand: how do you feel about dropping openssl-blacklist as an ssl-cert dep in jaunty?
<kees> slangasek: makes me sad, but I leave it to cjwatson's discretion
<jdstrand> slangasek: IIRC openssh-blacklist was already downgraded to Suggests?
<cjwatson> openssh-blacklist going away made me sad too
<cjwatson> but I think we had no choice
<slangasek> kees: well, the only thing ssl-cert uses it for is checking the integrity of the local snakeoil key, yes?
<jdstrand> slangasek: yes
<kees> Keybuk: http://pastebin.osuosl.org/23327
<kees> slangasek: oh! I misread.  ssh/ssl
<kees> slangasek: is it a CD space issue?
<cjwatson> Keybuk: I thought it did have such a command-line mode. I must be misremembering
<kees> Keybuk: note eth0 vs eth5
<jdstrand> heh.. openssl-blacklist is pretty big
<slangasek> jdstrand, kees: so anybody who hasn't been ignoring security updates in 8.04 for 9 months, or has upgraded to intrepid, already has the fix; the only case not covered is "people who never install security updates and are going to jump straight to 10.04 LTS"
<slangasek> kees: yes, CD space
<kees> Keybuk: it did have a "rename this interface to this" mode.  that's what I used it fore.
<slangasek> Keybuk: I wonder where I'm expected to have seen these parport errors in intrepid :)
<kees> slangasek: right, which was the logic with the ssh blacklist too.  seems like it follows to move it to suggests for ssl too.  jdstand?
<slangasek> well, if we drop it below a depends, the ssl-cert postinst can't use it anymore
<kees> Keybuk: though I did have to run it with -c /dev/null or something
<slangasek> so we might as well drop it out completely; other packages that use ssl certs still depend on it, e.g. openvpn
<jdstrand> slangasek, kees: I'm ok with it
 * slangasek pounces
<kees> Keybuk: yeah,  ifrename -c /dev/null -i OLDif -n NEWif
<kees> Keybuk: anyway, that doesn't matter so much atm.  do you have any idea what caused the problem with my net rule?
<slangasek> kees, jdstrand, cjwatson: should we maybe leave a debconf note in place, so that if the user *was* still upgrading from an old version of ssl-cert, they at least get a warning?
<jdstrand> slangasek: seems a long shot that no updates were made in those two years, but it would probably be best
<cjwatson> slangasek: if it's straightforward to detect the situation without the blacklist, yes
<jdstrand> slangasek: actually-- isn't an upgrade required before doing a do-release-upgrade?
<slangasek> cjwatson: yeah, that code is already there, I just have to drop the one extra 'if' before displaying the debconf question
<slangasek> jdstrand: sure.  There are still users that bypass do-release-upgrade, though.
 * jdstrand nods
<Nafallo> o/
 * Nafallo hides and ponders if he should looking at why he isn't using it :-P
<slangasek> yes, you should ;)
 * Nafallo grabs code
 * ogra prefers update-manager
<Nafallo> ogra: I don't use x on servers I'm afraid ;-)
<ogra> pffft
#ubuntu-devel 2009-01-16
<kees> james_w: when you're fixing FTBFS (wiipdf, vobcopy) can you send the patches to Debian too?
<james_w> kees: done
<james_w> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511971 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511978 for those two, the others are all filed too
<ubottu> Debian bug 511971 in wiipdf "Should check return code from system() calls" [Normal,Open]
<kees> james_w: cool!  :)
<kees> james_w: normally I include something like  (debug bug #...)  in the changelog so it can be checked during a merge
<james_w> yeah, but I prefer not to have to wait for a round trip with the Debian BTS
<james_w> thought that does seem to be a lot quicker recently
<slangasek> kees, jdstrand: is there an Ubuntu security 'overview' page I can link to from this debconf message?
<slangasek> something that tells the user how bad they are for not installing security updates on a regular basis? :)
<kees> slangasek: hrm
<slangasek> ubuntu.com/usn isn't it; I don't find anything under help.ubuntu.com that looks good
<slangasek> if there isn't one, we can certainly punt for now
<kees> punt, then.  I can't find anything either
 * kees adds it to his todo list
<billisnice> where is ubuntu 9.04 alpha 3?
<Hobbsee> gone.
<Hobbsee> it hasn't been released yet
<billisnice> i thought it was due out today?
<billisnice> the 15
<pochu> billisnice: delays happen sometimes :) it will be announced to the appropriate mailing list when it's available
<Hobbsee> as far as i know, it's still being tested, and will be released today or tomorrow
<pochu> which is ubuntu-devel-announce
<billisnice> will ext4 be in this release?
<Hobbsee> by default?
<billisnice> by default
<billisnice> better yet, are there instruction for installing linux 2.26.28 with ext4 on 8.94?
<billisnice> 8.10
<Hobbsee> i'm sure #ubuntu+1 can help you with questions of that nature, and I don't believe it's by default
<slangasek> no.  Why is ext3 insufficient?
<slangasek> using ext4 on 8.10 would certainly be an unsupported configuration
<billisnice> 8.10 is slow on my old compaq, i though ext4 would speed it up
<slangasek> it almost certainly won't
<billisnice> no speed difference?
<slangasek> not in any meaningful sense
<billisnice> ok
<billisnice> i wish it were faster
<billisnice> Arch Linux is so much faster on my old machine, but i like ubuntu
<slangasek> there are a lot of factors that may be contributing to that; the filesystem is not likely to be a major factor though, ext3 is already a very good filesystem and it's hard to go very far up from there for general desktop use
<RAOF> Hm.  There don't appear to be alpha-3-candidiate desktop images for testing. Are there likely to be some soon, or shall I just test alternate instead :)
<dholbach> good morning
<det> morning
<tritium> kirkland: screen-profiles looks useful not only for server machines with no graphical desktops, but also for mythbuntu boxes with overscan issues, where it's often hard to see the top panel, and hence easy to miss update-manager notifications, etc.
<tritium> Very nice!
<dholbach> kees, seb128: did you have a look at huats' check-symbols script? :)
<seb128> dholbach: no
<seb128> dholbach: I've no real interest to it to be honest
<seb128> I like my version better and use that one ;-)
<huats> seb128: no real interest in my stuffs ... thanks seb128 :P
<dholbach> seb128: because your version has french messages?
<seb128> dholbach: no, because I don't use pbuilder and I'm not interested to something which wants build and install things
<dholbach> seb128: he changed the tool to not require that
<seb128> the version I'm using compare the build directory to the system version
<seb128> dholbach: right, to work on deb thoughs, which still means downloading the current version deb
<seb128> where I do use the installed version ;-)
<seb128> anyway I will have a look but I had other things on my todolist for this week
<huats> seb128: sure :)
<mvo> seb128: is your version public ;) ?
<seb128> mvo: no, it's too much of quickly written code to be published on the web ;-)
<mvo> :)
 * mvo hugs seb
 * mvo hugs seb128
 * seb128 hugs mvo
<mvo> dholbach: that would be a good topic for the developer week, library packaging 101
<dholbach> mvo: the schedule is full already, but if you'd do it the next time, that'd be awesome :)
<dholbach> seb128: freedom hater! :)
<dholbach> you're saying that for years already
<seb128> lol
<dholbach> I had to write my own script
<dholbach> !!!
<seb128> I think I gave you my version
<seb128> it just doesn't work for you pbuilder lovers ;-)
<seb128> since pbuilder clean the build directory after build and give you debs and my version uses the build directory
<dholbach> it was written in French!
<Mithrandir> dholbach: French is the new Chinese
<seb128> which everybody knows is the universal language ;-)
 * dholbach hugs seb128
 * seb128 hugs dholbach
<dholbach> Mithrandir: eh?
<Mithrandir> indeed.
<liw> I wanted to switch to reprepro for updating my local mirror, but it seems to want to create Release.gpg itself, so that's a bummer
<Keybuk> 6
<Mithrandir> liw: I think you can tell it not to
<liw> Mithrandir, you can tell it to not sign it, but I can't figure out a way to get it to just use the one from Debian or Ubuntu
<liw> debmirror is OK with me, though, it just occasionally barfs
<directhex> Mithrandir, french would be the new chinese if the people who were meant to be spreading it weren't on strike
<pochu> anybody from Valencia on the channel? :)
<dholbach> pochu: tried #ubuntu-es too? :)
<pochu> good idea :)
<Keybuk> it seems mean to say this, but compared to Fedora and OpenSUSE, our installer is a bit ugly
<lool> It seems it's fun day today
<lool> cupsd: ../sysdeps/posix/getaddrinfo.c:1457: rfc3484_sort: Assertion `src->results[i].native == -1 || src->results[i].native == a1_native' failed.
<RAOF> Universe is meant to be enabled by default, right?
<Mithrandir> Keybuk: compared to RHEL, it's wonderful.
<lool> Of course I need to print something right now
<persia> RAOF, Ought be.
<RAOF> Ok.  So, it isn't on the amd64 livecd.
<persia> It's enabled by default in the installed system, but not on the livecd.
<lool> Why don't I get an apport crash?  It's an abort and I get a core file
<Keybuk> lool: development release?
<lool> Keybuk: Yes, and apport enabeld
<lool> and EDS wants all my CPU now *sigh* someone let me do my work
<lachlan__> Hello.  Where do you do your automount, is that in one of the gnome packages, HAL, or somewhere of its own?
<Keybuk> lachlan__: of plugged in devices?  a number of different packages are all involced
<lachlan__> Ok.  But if I remove GNOME, can I put something in there to speak to HAL and do the automounting, or is there something else?
<Keybuk> yes, KDE has a similar architecture, for example
<lachlan__> Ok, thanks, that's what I was hoping :)
<RAOF> Hm.  Where should "Universe not enabled on amd64 livecd" be filed?
<StevenK> RAOF: I can recall a similar bug already filed on livecd-rootfs
<RAOF> Yup, just found it, thanks.
<persia> Should that be a bug?
 * persia thought it was intentional, to reduce download size, etc. in the temporary system
<ogra> it should be enabled in the final sources.list, not during build of the livefs
<ogra> livecd-rootfs switches over in the end
<RAOF> Hm.  Ubiquity's being a bit of a problem child.
<kirkland> tritium: thanks!
<Notch-1> i'm in live usb persistent mode (kubuntu intrepid), and i can't disable autologin, why? after reboot it is enabled again...
<cpufreak> w 23
<ion_> benc: compcache 0.5 has been released. It would be nice to get it into jauntyâs kernel.
<jcastro> I have post UDS announcements in the -devel and -devel-announce queue if someone can approve those sometime today that would be swell.
<LordMetroid> Where can I leave suggestions?
<LordMetroid> I am thinking it would be useful if rm or overwriting files in general would move them to the gnome-trash, don't know if it is such a good idea though so I would like some feedback...
<Pici> !brainstorm | LordMetroid
<ubottu> LordMetroid: Post your ideas for ubuntu at http://brainstorm.ubuntu.com and vote for the ones you like!
<LordMetroid> Thank you pici
<cjwatson> jcastro: hmm, I noticed that you'd used the wrong date just after approving the -devel-announce message
<cjwatson> "which took place from 8-12 April"
<cjwatson> jcastro: want to correct the -devel one?
<evand> jcastro: devel approved
<jdstrand> cjwatson: hi! I'd like to test preseeding with a new ufw package before uploading. I know about mini.iso and I know about preseed files. what I'm not sure about is how to specify multiple mirrors in the preseed file (ie, the main one, and one with my new ufw package). Is this possible? Can you point me to a url for docs on how to do it?
<cjwatson> jdstrand: yeah, search for "apt-setup/local" in the installation guide
<jdstrand> cjwatson: thanks!
<cjwatson> jdstrand: beware that there are some ordering issues in how the system is installed
<savvas> does anyone know if there are plans for /etc/security/time.conf to have a folder as well? /etc/security/time.conf.d/ ?
<cjwatson> jdstrand: the bulk of stuff installed by tasksel is done without honouring apt-setup/local*/*, I think - you'd be best off arranging for an absolutely minimal installation, and then using pkgsel/include to get ufw
<savvas> *for pam time module
<cjwatson> savvas: in general, we only do that when it is necessary for packages to drop in extra files. Users should just edit that file directly
<jdstrand> cjwatson: excellent. thanks :)
<cjwatson> jdstrand: hmm, this may be a bit tricky since ufw is in standard
<jdstrand> tasksel tasksel/first multiselect ubuntu-minimal?
<jcastro> cjwatson: yikes, april, I don't know what I'm thinking
<jdstrand> that was what I was going to try...
<cjwatson> jdstrand: no, that won't work
<cjwatson> jdstrand: try: 'tasksel tasksel/skip-tasks string standard'
<savvas> cjwatson: I need it for timekpr, a 'computer nanny' sort-of, to limit computer usage - but /etc/security/time.conf belogs to a package, isn't that breaking a policy?
<cjwatson> and then 'd-i pkgsel/include string ufw'
<cjwatson> savvas: yes, it would be. You'll need to file a bug on pam requesting support
<savvas> ok thanks :)
<cjwatson> and there might be some other way you can achieve the same effect
<jdstrand> cjwatson: I current have 'tasksel tasksel/first multiselect ubuntu-standard', should I leave that and use what you just recommended with it?
<cjwatson> after all, time.conf is the configuration for a specific pam module
<cjwatson> jdstrand: you can take that out permanently since it isn't needed
<jdstrand> ok, cool
<cjwatson> (and is the wrong name anyway, the task name is just 'standard')
<cjwatson> standard is installed by default; in this case, you need to turn that off so that it gets installed from your local repository
<jdstrand> (I'm looking at a preseed file from hardy, so it likely needs other changes)
<jdstrand> cjwatson: gotcha :)
<savvas> cjwatson: I'm currently using debian/postinst and debian/postrm to make it work with /etc/security/timekpr.conf, but it would be easier if there was such a folder to drop in my package-related time.conf - maybe I should file a bug directly upstream ?
<cjwatson> savvas: file a bug with Ubuntu pam to start with
<savvas> ok
<savvas> will do
<savvas> thanks for the help :)
<gpled> is their any chance the power update script would put my second monitor is sleep mode?
<Keybuk> mvo: around? need some help with python-apt
<mvo> Keybuk: yes
<Keybuk> mvo: I'm trying to map from a binary package name to a source package name
<Keybuk> and can't seem to figure out how ;)
<Keybuk> I've been reading the extensive documentation for literally seconds!
<gpled> i lost one of my 4 monitors after the last update
<gpled> second monitor on first card
<Keybuk> gpled: have you tried looking under things on your desk?
<gpled> is their a way i can check if it is being forced to sleep mode?
<cjwatson> gpled: I would never put anything much past acpi-support, but I would doubt that the update was responsible
<cjwatson> all it did was hdparm
<gpled> the monitor works, until xorg kicks end
<gpled> then it goes black
<gpled> if i shutdown, or reboot, it comes back to life after x is done
<mvo> Keybuk: import apt; apt.Cache()["upstart"].sourcePackageName
<mvo> Keybuk: it that sufficient ?
<Keybuk> aha!
<Keybuk> I had the cache object from apt_pkg.somethingorother, and that didn't have any properties
<cjwatson> python-apt has two layers, one of which looks like apt's C++ layer and one of which looks like Python
<ScottK> python-ogre?
<cjwatson> for most purposes nowadays you really want the stuff from the apt module, even if it does raise a FutureWarning ;-)
<ScottK> What with the layers and all.
<mvo> Keybuk: the apt_pkg interface is a bit low-level, I would recommend not using it unless there is stuff in it that is not available via the "apt" interface
<mvo> Keybuk: there is even good documentation available for all this these days: http://people.debian.org/~jak/python-apt-doc/
<mvo> cjwatson: *cough* I need to remove that stupid^Wover-cautious warning
<Riddell> salut mathiaz, able to accept my post to ubuntu-server mailing list?
<mathiaz> Riddell: yop - I'll get to it in a moment
<LordMetroid> !packages
<ubottu> You can browse and search for Ubuntu packages using !Synaptic, !Adept, "apt-cache search <keywords or regex>", the "apt:/" URL in KDE, or online at http://packages.ubuntu.com - Ubuntu has about 20000 packages available, so please *search* for an official package before installing things in awkward ways!
* You're now known as ubuntulog
<tjaalton> hmm, are we ever going to have a real lib64 dir and leave lib for 32bit stuff?
<tjaalton> there are proprietary apps which assume that
<srid> I'm just curious if folks are working on automated testing, or have they dropped it already? https://launchpad.net/ubuntu/+spec/automated-testing
<srid> I'd be interested in contributing to it as I am working on similar efforts at my job
<ogra> tjaalton, did you see the fix for evtouch ?
<tjaalton> ogra: yes, thanks :)
<james_w> srid: #ubuntu-testing may be a good place to discuss it
<ogra> should work for other input drivers as well
<jdstrand> cjwatson: fyi-- your suggestions for ufw preseed testing are working wonderfully. thanks again! :)
<cjwatson> jdstrand: excellent
<tjaalton> ogra: yeah, there are quite a few which ftbfs, but no one uses them..
<maxb> tjaalton: Was having /usr/lib pointing at libs for a non-default ABI ever considered? It seems bit strange.
<ScottK> srid: I think #ubuntu-qa is where to discuss automated testing.
<ScottK> Or testing....
<tjaalton> maxb: no idea
<tjaalton> I'm just a bit surprised that for instance Bakbone lists Ubuntu as supported for both 32 and 64bit client/server (and Debian too), where it fails to install on 64bit..
<tjaalton> since it assumes lib64 is for 64bit, and lib for 32bit libs -> fail
<maxb> Oh, I misread your earlier question as querying the state of an ongoing debate.
<tjaalton> maxb: it was, I don't know what the status is
<tjaalton> maxb: wait, what debate?-)
<maxb> The concept that /usr/lib would contain 32-bit stuff on an amd64 system seems pretty bizarre to me. I've never seen anyone suggest it before, so I'm wondering if there's some mail thread somewhere that I've missed, or if it was before I started following the lists
<tjaalton> that's what the rpm world is doing
<tjaalton> and what LSB assumes
<tjaalton> we have the lib64 symlink pointing to lib..
<maxb> Yikes.
<maxb> How odd.
<tjaalton> inherited from debian
<maxb> No, I mean the rpm and LSB behaviour is odd
<tjaalton> ok, what do you suggest?-)
<maxb> I don't pay much attention to either, but it surprises me that they would do something different to what the FHS says
<tjaalton> and what does it say
<tjaalton> ?
<tjaalton> see for instance http://lists.debian.org/debian-amd64/2004/07/msg00039.html
<maxb> FHS says /lib<qualifier> and suggests that /lib would be a symlink to one of them (the platform default, I'd hope)
<tjaalton> what would that help?
<tjaalton> then you'd have lib, lib32 and lib64 on a 64bit system
<tjaalton> and lib, lib32 on 32bit
<cjwatson> what the rpm world is doing> I'm not sure switching to become incompatible with the Debian world is obviously better
<tjaalton> cjwatson: I understand, that's why I'm not suggesting to do the move, but asking if someone would know if there are any plans in the debian world to do something about it
<cjwatson> as far as I'm aware, the Debian world thinks that the rpm world is wrong in this and should be fixed
<tjaalton> heh
<cjwatson> are there any plans in the rpm world to do something about it?
<tjaalton> not that I know of
<srid> hmm, #ubuntu-qa has no members
<srid> ScottK: ^^
 * ScottK misremembered then.  Sorry
<ScottK> #ubuntu-testing then
<cjwatson> I bet there are proprietary applications expecting the Debian-style approach too
<Strassen_lecker_> hi
<Strassen_lecker_> german?
<Strassen_lecker_> deutsch?
<tjaalton> cjwatson: well, AIUI LSB says that lib64 and lib should be separate, so if the vendors assume that things will break in debian & derivatives
<cjwatson> that's as may be, but it's essentially impossible to change in Debian systems without a total rebuild of everything (completely breaking mirrors, etc.) and so is very unlikely to happen; so the LSB would be better served by figuring out a way to support both (e.g. with clever personality hacks) rather than standardising something which isn't standard
<tjaalton> "isn't standard" meaning what's out there and not what's in LSB? :)
<tjaalton> I realize it would be a huge effort, therefore I'll just contact Bakbone support and ask for an explanation :)
<maxb> I'm left utterly bemused on what train of thoughts led to the LSB deciding that on amd64 systems, /usr/lib should *not* contain libraries of the default ABI
<tjaalton> maxb: what default ABI?
<cjwatson> tjaalton: yes, I mean reality not what's written down
<maxb> The, uh, one after which the platform is named? :-)
<cjwatson> tjaalton: default ABI, i.e. what your main userspace is
<cjwatson> I'm entirely with maxb on this
<cjwatson> it isn't necessary in general since the linker can say (at least in theory, I forget whether it really does this but it clearly could) "oh, it's a 32-bit application, I'd better look in that library path over there instead"
<cjwatson> you might have to run it under linux32
<walters> except that application installers need to know where to put things
<cjwatson> the lsb is not short of query tools
<cjwatson> they could easily have created one that asks
<cjwatson> and of course lsb applications should not be installing into /usr/lib anyway
<tjaalton> sorry, was on the phone
<walters> eh, the whole issue sucks and i can understand debian not adopting multilib; what i think would be crazy though is adopting multilib, but reversing the naming from the multilib everyone else uses
<tjaalton> ok I get the ABI issue now..
<cjwatson> except that adopting what everyone else uses would mean a rebuild of world and an ABI event
<cjwatson> and that third-party applications should really *not* need to depend on the system library path
<cjwatson> the LSB should be nominating a safe subset of practices rather than a wishlist
<walters> cjwatson: yeah, ABI break is a problem...i guess the only other option is incompatibility forever
<cjwatson> being different is not necessarily being incompatibl
<cjwatson> e
<cjwatson> there is no intrinsic reason why having a different default library path is actually an incompatibility, with properly written applications
<cjwatson> (yes, I know there are lots of little glitches, but those are system bugs rather than intrinsic incompatibilities, IMO)
<walters> cjwatson: the problem is that this knowledge does end up in a variety of tools; years ago I had to untangle gstreamer which does some caching of its plugin .so files, it had to be made aware of multilib
<cjwatson> right, that was the sort of "little glitch" I was referring to; those are things the system can and should fix, though, and are not in principle things the LSB ought to have to worry about
<cjwatson> i.e. a more productive LSB approach would have been to cause those sorts of problems to result in LSB test failures
<cjwatson> but not otherwise mandate particular paths
<walters> anyways, back to working on code and pretending flash doesn't exist
<tjaalton> thanks for the conversation :)
<tjaalton> I understand the issue a whole lot better now
<ogra> oh, you were cornered by the colin mafia :)
<tjaalton> more like the 2&4 year old mafia
<tjaalton> and got distracted
<tjaalton> (the kids..)
<albuntu> hello to all
<albuntu> sorry if i am wrong here but i wanted to ask how to edit the gnome panel from terminal
<Pici> albuntu: you'd need to modify the gconf keys that control that data by using gconftool.  I dont know the paths for those keys off the top of my head.
<albuntu> Pici: thanks :) gconf can be used via terminal right ? because i dont want the gui one
<albuntu> i know i have to look for the xml files
<albuntu> and i am trying to find them
<ScottK> #ubuntu for help.
<albuntu> ScottK: ok thanks. i tried there but i got no answer and thought to try here. sorry
<simira> albuntu: I believe there's also #ubuntu-help
<albuntu> simira: it takes to ubuntu
<albuntu> i know it :)
<simira> ok
<albuntu> thank you :)
<calc> ok so seagate put out the KB article now acknowleding the drives are defective
<calc> waiting on hold to get a firmware update now
<Nafallo> calc: which drives?
<directhex> 1.5tb ones are known dodgy
<directhex> dunno if calc means thosed
<Nafallo> ah. good I bought WD instead then :-)
<Nafallo> there was someone in -server saying he had just bought 4 of those... he might be interested in the news :-)
<directhex> afaik it's fixed in a new firmware
<directhex> but still
<directhex> i'll stick with samsung tyvm
<Nafallo> :-)
<directhex> http://www.engadget.com/2009/01/16/seagate-barracuda-7200-11-drives-said-to-be-failing-at-an-alarmi/
<Nafallo> ouch. all 7200.11... that's more than 1.5TB
<calc> Nafallo: http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207931
<calc> they finally put the KB article back up a bit ago
<calc> it affects all seagate 11th generation drives including maxtor apparently
<Nafallo> wow
<calc> it looks like it might not affect the 1.5TB drive so maybe they fixed the issue earlier and hoped not to worry about it for the smaller capacities
<calc> it affects from the list 1tb, 750gb, 640gb, 500gb, 320gb, 250gb, 160gb drives
<directhex> <directhex> i'll stick with samsung tyvm
<calc> i'll let you know how it goes once i get through the phone queue, however long that takes
<calc> directhex: samsung spinpoint f1?
<calc> directhex: aiui they have some problem as well, but i don't have one so didn't look into that much
<directhex> calc, generally. been using them since the old p80 series appeared
<Nafallo> WD Green for me :-)
<calc> apparently the hitachi are good as well now that IBM isn't involved anymore ;-)
<directhex> i like samsung. they do what seagate were famous for - quiet, low-noise
<tritium> Nafallo: nice, quietest and lowest power-consumption drives you can buy.  :)
<directhex> and cool-running
<Nafallo> tritium: yea. part of why I wanted them so badly :-)
<calc> i think i'll get a 2-3tb drive at the end of the year
<directhex> heat matters in confined spaces
<calc> plenty of room to build OOo then ;-)
<tritium> Nafallo: I'm putting the new WD Green 1TB in my next HTPC build.
<directhex> deathstars are still hotter than the surface of the sun after a couple of minutes
<Nafallo> tritium: putted my two into a small enclosure using hardware raid1 :-)
<calc> i tried building one of those Shuttle sff systems a few years ago and it was very easy to overheat drives in that, ended up returning the system
<tritium> Nafallo: sweet!
<Nafallo> well.. "small"
<Nafallo> http://www.edge10.com/digital_storage.php <-- DAS200
 * tritium drools
<directhex> calc, wifey has a shuttle, with a spinpoint ni it - no overheating issues ;)
<calc> directhex: i think the newer ones are a bit bigger as well to help alleviate the heat issues
<calc> directhex: the one i got was an i865G based system
<directhex> calc, this one's p31 based, but uses the ancient g2 chassis
<directhex> g5 IS bigger
<calc> directhex: of course i was also trying to overheat the drive to make sure it wouldn't fail on me when doing dev work
<calc> directhex: i ran a couple full disk reads on it and monitored the heat ;-)
<directhex> the real hot spot, literally, is the geforce 8800 - since the pcie slot is on the outside of the mobo, the card has about 5mm next to it until it's got the outside of the chassis... no airflow...
<calc> 27m and going for hold queue
<calc> their 800 number was actually busy earlier when i tried calling
<sbeattie> calc: really? I've had a few different 2 hd shuttles that have been rock solid -- but they're all servers so I've never added video cards to cook my disks with.
<calc> sbeattie: the i865G i had was integrated graphics and still got too hot, but that was around 4 years ago now i think
<mattias_> hi um... where can i get started in regards of learning to write a program for ubuntu?
<sbeattie> calc: I have an i845g that I've had running since before then, with the disks in software raid 1.
<calc> so the fix isn't actually done yet they thought they had fixed it and announced the issue then found out the bug wasn't fully fixed yet (i suppose) and will be sending it via email to everyone once its done
<calc> doh
<slangasek> kirkland: is bug #309541 still a going concern in alpha-3?  The bug is still only marked 'fix committed' for Linux
<ubottu> Launchpad bug 309541 in linux "Jaunty Alpha 2 Installation: encrypted home directory broken" [Critical,Fix committed] https://launchpad.net/bugs/309541
<superm1> are we still frozen for a3 or is /t just not updated yet?
<directhex> oh, minor note: if your gdm default session changes (e.g. to 'mythbuntu'), guest sessions don't work
<slangasek> superm1: feel free to consider us unfrozen, the milestone will be published shortly
<superm1> slangasek, great thanks
<tedg> Why is there PPA builds in queue if there are idle machines (instances)?  https://launchpad.net/+builds
<slangasek> that page claims they aren't in queue :)
<tedg> slangasek: Heh, well the aren't now.   I think it's a cron thing, they get moved in at a specific interval.
<TheMuso> bryce_: The mitac audio patch you put together is now upstream. Will be pulling it and a few others to pass onto the kernel team next week.
<bryce_> TheMuso: awesome
* slangasek changed the topic of #ubuntu-devel to: Archive: open, MoM running, alpha-3: released | Be sure to vote in Tech Board Nomination Ballot! | 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
#ubuntu-devel 2009-01-17
<tkamppeter> Anyone of the TB or in some other format permitted to grant me upload rights for a package into main? I have upload rights for all printing packages into main, but it did not work for cupsddk and I would like to get it corrected. Thanks.
<cjwatson> tkamppeter: I suggest mailing technical-board@lists.ubuntu.com - they probably won't be around at this time
<cjwatson> nobody else has the authority to do that
<cjwatson> (I can confirm that you don't have upload access to cupsddk)
<tkamppeter> cjwatson: , thanks.
<benh> hoy
<benh> is ports. down ?
<benh> ie, temporary breakage or something more permanent ?
<wgrant> benh: It wouldn't be anything permanent. I suspect it's just down and as it's a weekend nobody has noticed yet...
<benh> ok
<SingAlong> Hi all!
<SingAlong> I'm trying to compile a lib gives me Xrender.h errors. Says Xrender.h isnt found. But I verified the location I specified and the file is present. Has anyone got such errors?
<sukiminna_> seems like there is nobody here..
<sukiminna_> :(
<SingAlong> sukiminna: ?
<SingAlong> yeah I think I'll go back to #ubuntu
<RAOF> SingAlong: That doesn't sound like a question about the development of ubuntu, so is likely to be off-topic.
<SingAlong> RAOF: sorry!
<RAOF> SingAlong: Plus, the minimum useful information would include a pastebin link containing the full terminal output of whatever's not working.
<karthik_> hey anyone please help how to create a new workspace
<Mithrandir> karthik_: this channel is not for support, please ask in #ubuntu.
<iulian> karthik_: Please join #ubuntu for user support.
<karthik_> Mithrandir: i asked as a programmers view
<karthik_> i want it to create using a c prog
<iulian> karthik_: And still this is not the right channel to ask.
<iulian> karthik_: See /topic.
<karthik_> iulian: ok could you please tell where to ask
<iulian> karthik_: I've no idea, sorry.  You can try google.
<karthik_> iulian: as workspace is related to development of desktop related thing.. are there channels for desktop development?
<Mithrandir> karthik_: assuming you are on gnome, see http://live.gnome.org/GnomeIrcChannels ?
<karthik_> ok
<lool> Err "import common" /usr/share/pyshared/common.py in ubuntu-dev-tools
<jpds> lool: I thought I moved that to /usr/share/ubuntu-dev-tools.
<lool> jpds: I only updated yesterday
 * lool updates
<lool> jpds: I created credentials with manage-credentials (which should IMO be lp-manage-credentials), but requestsync still breaks
<jpds> lool: I just saw the bug report.
<lool> jpds: It's not that bug
<lool> The bug I filed is when I didn't have any credentials
<lool> But it still doesn't work after creating them
<lool> jpds: It seems I'm up-to-date WRT ubunt-dev-tools
<lool> I have 0.55 which seems to be the newest
<lool> jpds: Oh I think I'm really stupid
<lool> lalala
<lool> I should read man pages til the end
<lool> jpds: Are you aware of the permissions being work readable by default?
<jpds> lool: Oh, yeah. You need a token with 'ubuntu-dev-tools' as the name. And yes, that's fixed in Bazaar.
<lool> jpds: Ok; thanks
<jpds> lool: OK; improved error message to show what token name is needed.
<lool> jpds: Thanks :)
<DktrKranz> lool, intrepid-proposed upload of language-pack-gnome-{de,it}-base make packages conflicting with language-pack-gnome-{de,it} (see bug 317934). Is it fine for you to manually adjust depenencies on correct language-pack-gnome-{de,it} versions available in intrepid-updates?
<ubottu> Launchpad bug 317934 in language-pack-gnome-it-base "Broken dependencies in language-pack-gnome-it-base" [Undecided,New] https://launchpad.net/bugs/317934
<lool> DktrKranz: Thanks a lot for the pointer
<lool> slangasek, cjwatson: what's your preference for fixing this?  Changing the deps for the -base SRUs, or also SRU-ing the non -base langpacks?
<lool> I would rather do the former
<lool> Updated bugs
<jpds> lool: u-d-t 0.56 uploaded.
<cjwatson> lool: adjust the deps for -base, I think
<DktrKranz> lool, I just noticed language-pack-gnome-{de,it}-base have Conflicts/Replaces field which do use of (<< ${Source-Version}), so they need mangling too.
<cjwatson> isn't that what lool basically already said?
<cjwatson> the only reason I'm at all uncomfortable with mangling -base is that the mangling is going to be messy at the source level
<cjwatson> although I suppose you could just hardcode the versions for now
<ogra> hmm, is it me or has ports.u.c a problem ?
<lool> jpds: Thanks; however I think you mixed the issue I reported on IRC with the one I reported in LP: I still think it's a bug to require lp credentials by default, at least it's inconsistent with having a --lp flag
<lool> jpds: Albeit not my preference, I wouldn't mind a requirement to use LP for this tool
<lool> Just not the situation where it's needed while it seems it's not ;)
<jpds> lool: Hmm, no credentials found, and skip LP bug check?
<lool> jpds: Yes
<jpds> lool: OK, I can do that.
<lool> Thanks a lot
<lool> Erf language-pack-gnome-$l-base Replaces itself; I guess it's due to some common template and simplifications
<jpds> lool: Commited to bzr.
<fbond> Hi.  NetworkManager failed to add a route to the gateway and a default route.  I'm at a hotel.  How can I quickly grab enough info for someone to debug (I'll upload to launchpad)?
<fbond> (Windows machines work correctly.)
<fbond> (NM reported the gateway correctly when I clicked "Connection Information".)
<directhex> fbond, i've occasionally had strangely windows-only wifi. what driver are you using?
<fbond> directhex: b43.  It works after I added the routes correctly.
<fbond> directhex: Although the captive portal seemed to be a little confused by me.
<lool> cjwatson, slangasek: Pushed -it and -de base langpacks again (intrepid2); I've test installed these in a new intrepid virtual machine from my ppa (after reproducing the installation issue with -proposed)
<lool> (and these are in unapproved)
<ramvi> How do I customize the UNR iso?There's no casper directory like here: https://help.ubuntu.com/community/LiveCDCustomization
<spod-> hi does anybody know if there is a gdb package with thread debugging enabled?
<spod-> or do i have to compile it myself?
<hyperair> spod-: http://pastebin.com/d103e4f97 <-- see, gdb has threading support by default
<i-pink> hi i have a problem in the time applet (gnome)
<i-pink> i think is bug
<i-pink> look a this screensot http://www1.speedyshare.com/data/488896368/14740217/4014211/Screenshot-1.png
<cjwatson> please use the bug tracking system: https://bugs.launchpad.net/ubuntu - bug reports on IRC are usually lost
<i-pink> how to that?
<i-pink> you can help me with this?
<cjwatson> no
<cjwatson> this is a development channel; please go elsewhere for support, e.g. #ubuntu
<i-pink> ok :S
<cjwatson> lool: language-pack-gnome-{de,it}-base accepted, thanks
<i-pink> is for the development
<tvakah> is there any particular reason that ubuntu's shipping php with magic quotes on by default?
<ScottK> tvakah: I'd ask in #ubuntu-server
<tvakah> ScottK: ehh I see there's been a bug since march about it, and it's still not been addressed in jaunty, oh well
<ScottK> tvakah: I'm just saying you're more likely to get an answer there.
 * ScottK has no idea about php.
 * calc still looking for bugs not already fixed to put on his pet bugs list, heh
<calc> lots of bugs fixed for 3.0 :)
<savvas> tvakah: they're off by default I think
<savvas> http://us.php.net/manual/en/security.magicquotes.php
<tvakah> savvas: negative, I just got bit by it, spent many hours trying to find out why my code wasn't working until I finally went "d'oh"
<tvakah> latest php5 from jaunty
<tvakah> freshly reinstalled due to doing the jaunty upgrade ( I reintalled from scratch )
<tvakah> which is why it bit me since I'd turned them off long ago in intrepid
<savvas> what's the bug report number?
<savvas> I think someone should report this to the ubuntu-hardened team
<savvas> just found a discussion about it: https://lists.ubuntu.com/archives/ubuntu-hardened/2008-September/000416.html
<savvas> tvakah: what's the bug report number?
<tvakah> savvas: #204479
<tvakah> it's a "wishlist" importance for some reason
<savvas> bug #204479
<ubottu> Launchpad bug 204479 in php5 "PHP should be shipped with magic_quotes_gpc = Off in php.ini" [Wishlist,Triaged] https://launchpad.net/bugs/204479
<savvas> the patch comes directly from debian
<savvas> debian/patches/029-php.ini_paranoid.patch
<savvas> tvakah: I'll try report this to debian first, we'll see if they'll fix it :)
<tvakah> savvas: heh you're saying a patch called "paranoid" turns it _on_?
<tvakah> seems a tad messed up
<savvas> yep
<savvas> tvakah: hold a sec, it's a bit messy with all those patches, let me read it once more :)
<savvas> tvakah: I can't do this, the package is just too big for my knowledge :(
<tvakah> ahh, well at this rate may as well wait for php6 then since the "feature" is finally being put down
<cjwatson> I've linked the PHP bug to the corresponding Debian bug
<cjwatson> "Although I agree that magic_quotes_* suck (and IMHO they should not even
<cjwatson> exist) I don't know how good it will make (besides most likely breaking lots
<cjwatson> of poorly designed scripts) as long as upstream provide a php.ini with _gpg =
<cjwatson> on.
<cjwatson> "
<tvakah> cjwatson: actually most php projects of size have automatic checks to disable magic quotes if the server has them on
<cjwatson> I know nothing about PHP and want to know less
<savvas> tvakah: actually php 5.3.0 :)
<cjwatson> just quoting the Debian bug
<tvakah> it more affects individual developers such as myself who start a simple standalone script assuming a sane setup ;)
<savvas> they'll deprecate it in that version as well
<cjwatson> actually, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512037 has more helpful discussion
<ubottu> Debian bug 512037 in php5-cgi "php5-cgi: magic_quotes_gpc = On" [Important,Open]
<savvas> so that's why I couldn't find it :P
<cjwatson> anyway, looks like the reason Debian and Ubuntu both ship it that way is (ultimately) that: that's the upstream default too; some of the Debian maintainers are reluctant to change it right before the release of Lenny; and Ubuntu is just following along here
<tvakah> *nod* just got done reading that too, ahh well, not a world stopping thing by far, just caused a raised eyebrow here and a bit of face+palming ;)
<cjwatson> PHP isn't something we put a lot of direct maintenance effort into beyond necessary adjustments for Ubuntu's structure and other related packages, I think
<cjwatson> certainly it seems extremely probable that both Debian and Ubuntu would follow the upstream change in php6
<tvakah> heh fortunately there's no choice in v6, they're finally axing the bugger
<savvas> hm.. cjwatson's right, php.ini-recommended is the one that has magic_quotes "off" heh
<tvakah> see it's this thing where by it causes all incoming strings ( like post, get , and cookie variables ) to have _al_ quotes have a literal "\" prepended so as to make them escaped for easy use inside say a sql insert statement
<tvakah> that's what's magic about it, it lets lesser programmers write sql statements... with disasterous magic sideeffects
<cjwatson> oh, yeah, I've heard enough about it to know it's entirely braindead
<cjwatson> classic case of why it's important to have clearly defined quoting rules that you violate at your peril
<tvakah> and if you don't work in php every day and just incidentally try to write a php script to "Get something done", you'll end up not noticing it at first until it bites you ;)
<directhex> when i see NCommander doing things, i can't help but think of the electric six song "dance commander"
<NCommander> Get up, get up, get up AND DANCE!
<LaserJock> anybody happen to know what the difference between gitpkg and git-buildpackage is?
#ubuntu-devel 2009-01-18
<LaserJock> calc: around? OO.o seems to freeze when I try to save files. Known thing?
<calc> TheMuso: ping
<calc> TheMuso: bug 298494 pablo mentioned 9.04 works with the OOo ppa but 8.10 won't for the sound issue, it sounds to me like its an issue with the sound stack if really true
<ubottu> Launchpad bug 298494 in openoffice.org "OpenOffice.org Impress: Faltering embedded sound in PPS files" [Undecided,Confirmed] https://launchpad.net/bugs/298494
<calc> TheMuso: my sound is hosed in general though so its hard for me to test
 * calc might should switch to 9.04 soon himself assuming the sound support is that much better ;-)
<TheMuso> calc: How is your sound hosed?
<TheMuso> calc: and I am subscribed to the bug so I will have a look on Monday.
<calc> TheMuso: i just hear popping and clicking sounds
<calc> TheMuso: i think it is probably a kernel issue but not completely certain, i haven't spent the time to look into it closely
<calc> TheMuso: actually i may just need to log out and back in the test sound buttons fail even
 * calc will have to look at it later
<TheMuso> calc: ok
 * calc notes that OOo 3.0 seems to fix a lot of bugs users have been reporting :)
<calc> its making it a bit hard to find pet bugs ;-)
<pwnguin> calc: if you want a pet bug
<pwnguin> calc: the presenter mode feature in oo.org 3.0 is broke
<pwnguin> calc: http://wiki.services.openoffice.org/wiki/Presenter_Screen
<KingWilliam> Is there any way a java programmer can contribute to ubuntu???
<KingWilliam> Not much activity here?
<Nafallo> !weekend
<ubottu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<KingWilliam> lol, ok then
<fabio_mm> :)
<fabio_mm> I've got the same question
<KingWilliam> really?
<KingWilliam> Also a java developer?
<fabio_mm> but I'm a C \ c++ programmer
<KingWilliam> ah ok
<fabio_mm> I'm not so good with java
<fabio_mm> :)
<KingWilliam> c++ is often used in ubuntu isn't it?
<fabio_mm> I think
<KingWilliam> I'm not good witg c++ :P
<fabio_mm> but I'm a noob in this channel
<KingWilliam> I know the basics of C++ but no more :P
<fabio_mm> :)
<KingWilliam> lol, me too mate
<KingWilliam> Have you used ubuntu for a long time?
<fabio_mm> I've lunch... see you soon!
<KingWilliam> ciao
<fabio_mm> about 3 years
<tseliot> you can either try to fix bugs in projects which use your languages of choice or start new projects (e.g. by looking at the requests in the ubuntu brainstorm)
<tseliot> C++ is used in most KDE apps and GTKmm apps (e.g. Abiword)
<tseliot> eclipse, netbeans, etc. are written in Java
<tseliot> even small patches can help
<tseliot> asac: about this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/315889
<ubottu> Launchpad bug 315889 in xserver-xorg-video-ati "EXA has severe performance impact on ATI R580 (X1900)" [Medium,Triaged]
<tseliot> asac: does it help if you kill both gnome-settings-daemon and gnome-power-manager?
<tseliot> I'm wondering if you're experiencing a different bug now
<petski> I've subscribed ubuntu-sru for a certain bug (#276603) in launchpad. According to the procedure, I have to upload my package into -proposed, but I'm not allowed to. Is this mandatory? Does anyone know the average response time for ubuntu-sru?
<pochu> petski: subscribe ubuntu-main-sponsors, they'll upload the package to -proposed for you.
<pochu> the average response is usually less than a few days, IME
<petski> thanks pochu
<t0m> Hello, I was wondering if anyone could help me track something down in the printing system.
<t0m> I am looking for what triggers ubuntu to install a new printer when it detects one
<t0m> is it udev, hal, cups or something different?
<asac> tseliot: let me try
<tseliot> ok
<asac> tseliot: unfortuntely it didnt changed performance ... i just dont have any theme anymore
<tseliot> asac: does the mouse cursor moves by itself?
<tseliot> s/moves/move
<directhex> yay, /me has nvidia 180
<asac> tseliot: no ... only if i move the mouse
<asac> tseliot: what do you suspect?
<tseliot> asac: ok, I thought it was another bug which I've just fixed: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/307306
<ubottu> Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress]
<tseliot> it's a bug in both g-s-d and g-p-m
<asac> tseliot: prob is that Xaa is responsive ... only EXA acts so bad
<tseliot> ok
<asac> which is why i filed against driver in first place
<tseliot> but it was fixed at a certain point
<tseliot> a kernel change perhaps
<asac> tseliot: well. it first appeared when we switched to latest xorg ... which switches from Xaa to EXA for ati by default
<asac> could be kernel
<asac> or xorg driver
<tseliot> if performance is so terrible we could write a patch to use Xaa by default; bryce should know what's happening with exa
<asac> tseliot: right ... thats what i suggested in the bug. i just would like to first get an upstream opinion before we patch EXA for this card out
<tseliot> wise decision
<tjaalton> tseliot: the default is XAA, it was patched to use EXA
<tseliot> tjaalton: ah, I thought they had switched to EXA already
<tjaalton> only intel has
<tseliot> it would only be a matter of removing one patch then
<tseliot> even better
<tjaalton> better to upstream it and fix the bug :)
<asac> tseliot: also its not really that everything is really slow. for instance, scrolling in firefox seems even to be faster. however, gnome-terminal is unusable and other apps as well. maybe i should keep using it to get a better idea which operation actually slows down like this.
<asac> gibber is really slow scrolling (maybe transparency?)
<asac> gwibber
 * asac restarts gnome-settings-daemon :)
<tjaalton> asac: do you have an account on bugs.fd.o?
<asac> most likely. if not i wil create one ;)
<tjaalton> asac: cool, so please file a bug against xorg/ati and link to the lp bug :)
<tseliot> tjaalton: won't upstream switch to UXA or whatever it's called?
<tjaalton> upstream is responsive, and knows what to debug
<tjaalton> tseliot: UXA is intel specific, and what they are experimenting with it will be merged back to EXA
<tseliot> ah, ok, so it will still be EXA
 * sukiminna says is anybody here..?
<spitfire_> In ubuntu intrepid, gksu "window" is transparent. How did it change since hardy, and what do I need to have it in hh?
<spitfire_> Is it compiz plugin?
<spitfire_> or murrine rgba?
<Amaranth> spitfire_:That's all gksu
<spitfire_> Amaranth: I've backported gksu, nothing changed...
<spitfire_> It looks like this: https://wiki.ubuntu.com/DesktopTeam/Specs/SpitAndPolish
<spitfire_> so I thought there is something more.
<spitfire_> Amaranth: are you sure?
<Amaranth> spitfire_: Yes, did you backport libgksu as well?
<spitfire_> Amaranth: libgksu?
<spitfire_> ok
<spitfire_> I'll try
<Amaranth> That's the library where I made the original "give gksu more bling" changes, I suppose that's where they would have made further changes as well
<spitfire_> Amaranth: thanks;)
<spitfire_> Amaranth: same applies to gnome-session's logout-dialog?
<Amaranth> yeah
<spitfire_> what package do I need to rebuild?
<spitfire_> gnome-session?
<spitfire_> Amaranth: ^^
<spitfire_> ?
<Amaranth> I can never remember if that's in gnome-session or gnome-panel
<Amaranth> Either way backporting it is going to be somewhat painful
<spitfire_> Amaranth: why?
<spitfire_> I already have intrepid's glib/cairo/pango/gtk+
<Amaranth> gnome-panel has other dependencies, gnome-session was a rewrite that works completely differently
<spitfire_> oh.
<spitfire_> I see
<spitfire_> looks like I'm gonna backport gnome 2.24:P
<Amaranth> also the dialog you see on the wiki isn't even there in jaunty
<spitfire_> Amaranth: I know.
<spitfire_> Only gksu is.
<spitfire_> Amaranth: how do i change shutdown dialog in intrpid to this: http://people.ubuntu.com/~mmueller/spit-and-polish/small_logout-mockup.png
<spitfire_> ?
<spitfire_> Is it switchble somewhere via GConf?
<Amaranth> no, that's the default ubuntu shutdown dialog
<spitfire_> Amaranth: so I can't change it?
<spitfire_> Cause I like the one in hardy (one on the picture)
<Amaranth> err, I kind of skipped intrepid, maybe I'm missing something here
<Amaranth> the translucent one is the default in intrepid, no?
<spitfire_> Amaranth: I can't use intrepid on my laptop because of intel video driver implementation
<spitfire_> It's incomplete.
<spitfire_> And Intrepid has that incomplete implementaton.
<spitfire_> It looks like jaunty will be no better:/
<spitfire_> Amaranth: gksu works;)
<spitfire_> Thanks
<alex-weej> anyone know any major bugs about S3 suspend not working in 9.04?
<alex-weej> i've never managed to make it wake up
<jharr> I need help with some parts of a debootstrap environment. Is there a better channel for that?
<maxb> jharr: I think #ubuntu-motu is the standard "learning how to do ubuntu packaging tasks" channel
<dthommas> Hello Friends ... I want to make a linux installer CD with my custom kernel build . Can somebody help me out  onto this ? I dont know how to make it .
<cjwatson> jharr: what parts?
<CaptainMorgan> howdy... is there any chance we could put a rush on Amarok 2 being placed into the repos? for some reason, it's a real biatch to install from source... cheers
 * Nafallo wonders why we have a user administration tool where we can't disable users...
<jpds> Nafallo++.
<afflux> is anyone able to use apport to submit crash reports in jaunty? Several people, including myself, have issues with "<urlopen error The write operation timed out>". see bug 314212.
<ubottu> Launchpad bug 314212 in apport "Apport unable to report crash - urlopen error timed out" [Undecided,Confirmed] https://launchpad.net/bugs/314212
<RAOF> /join #ubuntu-x,#nouveau,#gnome-do
<directhex> INNER JOIN?
<RAOF> Empathy's IRC support is non-standard :/
<directhex> use smuxi!
<RAOF> Finish the gnome-desktop-sharp2 transition, and I totally will.
<RAOF> Well, I'm also just testing stuff.
<directhex> slomo made more changes to that today
<RAOF> Yeah, I noticed.
<directhex> which is apprently still not correct, according to meebey
<RAOF> Syncing the new version will mean that Tomboy will build again!
<RAOF> Oh.  Well, the new upstream version _still_ means that tomboy will build again.
#ubuntu-devel 2010-01-18
<funkyHat> Is it necessary for apt to run "Updating fontconfig cache for /usr/share/fonts/..." so many times during installation of fonts? Or would it be possible/preferable to have that queued up until the end, like some other things are?
<ScottK> That would take someone implementing a dpkg trigger for it.
<Laney> which is not necessarily a hard task with file triggers
<ScottK> Just takes someone to do it.
<Laney> someone... who cares about such a problem...
 * Laney peers at funkyHat 
<ScottK> Laney: Exactly.
<funkyHat> Problem is I've now installed all the fonts in the world, so I won't have anything to test it with â¡(
<funkyHat> ;P
<Laney> we have chroots for this ;)
<funkyHat> I knew that excuse wouldn't work!
 * sebner throws a virtual machine at funkyHat 
 * funkyHat puts it on the pile in the corner
<funkyHat> Looking at the dpkg triggers page it looks like every font package is going to need changing to use triggers
<ScottK> Probably a change best coordinated through the Debian fonts packaging team
<ScottK> (I don't recall its exact name)
<funkyHat> Yeah
<funkyHat> Was going to say probably best if this is dealt with with Debian's packages
<ScottK> Someone should probably go talk to them about it.
 * ScottK wonders who might be a candidate?
<RAOF> If there's a dh_font or somesuch it'd probably only take a change to fontconfig + a rebuild for all the font packages.
<funkyHat> ScottK: I'm having a look through their mailing lists to see if it's already been discussed
<ScottK> Excellent
<funkyHat> Yep, fixed in fontconfig 2.8.0-2 it seems â¡)
<ScottK> Looks like fontconfig is in serious need of a merge from Debian.
<funkyHat> ScottK: bug 490326
<ubottu> Launchpad bug 490326 in fontconfig "Please merge fontconfig 2.8.0-2 from Debian testing (main)" [Wishlist,In progress] https://launchpad.net/bugs/490326
<funkyHat> It's been "in progress" for 5 days
<ScottK> The package was last merged during Intrepid development, so it wouldn't suprise me if it was complex.
<funkyHat> Oh but there's a bzr branch uploaded, perhaps waiting for review?
<Some_Person> Can anyone tell me if the package ``human-theme'' conflicts with ``gtk2-engines-ubuntulooks'' in lucid?
<Some_Person> Is anyone here?
<xnox> yes
<Some_Person> I want to know why nobody has fixed an easy as heck bug involving human-theme and gtk2-engines-ubuntulooks
<Some_Person> It's been around since Intrepid's release
<xnox> I did actually quish a comple of human-theme bugs
<Some_Person> https://bugs.launchpad.net/ubuntu/+source/ubuntulooks/+bug/285417
<ubottu> Ubuntu bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed]
<xnox> but it's no longer default
<xnox> we use humanity now
<Some_Person> I fixed the bug myself for karmic in my PPA and could easily do the same for lucid
<Some_Person> Yes, but some themes still use ubuntulooks, and when you try to install that engine, human-theme has to go for no good reason
<Some_Person> For example, blubuntu in the repos
<Some_Person> I'm puzzled as to why this hasn't been fixed
<xnox> Looks valid to me
<ScottK> Then you haven't looked at the mountain of bugs open Launchpad and done a realistic assemement of the priority of problems like this.
<xnox> My guess there was a lot of shouting in the bug report
<Some_Person> I understand that, but shouldn't older ones be tackled first? Especially trivial ones like this one where the fix is extremely easy?
<xnox> my suggestion would be to branch lp:ubuntu/packages both of them
<xnox> commit your fixes and push it back to lp:~user/ubuntu/ludic/package/my-fixes
<ScottK> Some_Person: If you have the fix, you could attach a debdiff to the bug and subscribe the relevant sponsorship team to the bug.
<xnox> and then seek sponsors from the sponsors team
<ScottK> Either way works
<Some_Person> I have the fix for karmic and I can almost certainly make one for lucid too
<xnox> And the reason why it wasn't fixed is because it's no longer in the default install and this really doesn't cut it for the Strable Release Update
<xnox> you can still installing by removing those packages ;-)
<Some_Person> Yes, but it makes no sense to have to needlessly remove human-theme
<xnox> do a fix against lucid attach it to the bug, _explain_ nicely in one or two sentences what this fix is about and subscribe ~ubuntu-universe-sponsors
<xnox> works for me ;-) I get either a quick comment from sponsor what's wrong, or I get email from LaunchPad saying it got uploaded ;-)
<Some_Person> One question, when I make the debdiff, should the Maintainer field in the control file be me or what?
<ScottK> Some_Person: What's there now?
<Some_Person> the original one that's in karmic ("Sebastien Bacher <seb128@canonical.com>")
<Some_Person> actually, sorry, i'm wrong
<Some_Person> my name is actually in there
<xnox> Some_Person: keep the maintainer name the same
<Some_Person> ok, i'll change it back then
<xnox> just add "[ Your Name ]" in debian/changelog
<xnox> and then underneath your changes
<xnox> and don't forget to bump release version
<xnox> eg. dch -i
<Some_Person> Is what I did here OK? https://bugs.launchpad.net/ubuntu/+source/ubuntulooks/+bug/285417
<ubottu> Ubuntu bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed]
<Some_Person> last post
<Some_Person> (actually, the same debdiff should work for lucid too)
<ScottK> The debdiff in the bug should be for lucid
<xnox> Some_Person: Wah =)
<xnox> now that one is quite ugly
<xnox> no need to move the folder
<xnox> and no need to patch configure
<xnox> just use appropriate *.install files and configure options to define new package-name prefix
<Some_Person> I moved the folder to keep Human-ubuntulooks as a separate theme (just in case anyone wants it, though it shouldn't be necessary). And patching configure makes it look for the stuff in the renamed folder
<Some_Person> Anyway, what's the chance that a fix for this will be implemented in lucid?
<ScottK> Assuming you have a good patch, pretty good.
<Some_Person> Well, it works for me in Karmic (that's what my PPA uses)
<Some_Person> do i need to change the bug's status or anything?
<xnox> subscribe ~ubuntu-universe-sponsors team
<xnox> don't change statur
<Some_Person> ok
<Some_Person> thanks
<xnox> your welcome
<xnox> attached debdiff & branch to fix bug #285417 with two lines. Note fixes upgrade Hardy -> Lucid
<ubottu> Launchpad bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed] https://launchpad.net/bugs/285417
<xnox> please sponsor =)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/508930
<ubottu> Ubuntu bug 508930 in samba "CIFS mount is offline every x minutes/seconds" [Undecided,New]
<dupondje> can somebody give it a look ? :)
<dholbach> good morning
<pitti> Good morning
<dholbach> hey pitti
<pitti> slangasek: ubuntuone spec responsibility> hm, their team lead? it wasn't an integration spec, but an upstream development one
<pitti> asac: I mailed you about the missing ude-2d spec
<pitti> hey dholbach, had a nice weekend?
<slangasek> pitti: oh - then should the spec not have been accepted for Lucid, maybe?
<dholbach> pitti: I did, although it involved a lot of recovery from a long night out :)
<pitti> slangasek: good question; I suppose they still want to align to the lucid development cycle, but it should perhaps not be an ubuntu spec
<dholbach> pitti: how was yours?
<pitti> dholbach: great, we went skiing again, and I caught up sleep from last week's sprint :)
<pitti> dholbach: went DJing again?
<dholbach> pitti: no, I was out in a bar with my brother and sister and a couple of friends, I guess we should have stopped after the first bar :)
<dholbach> pitti: but more DJing is definitely on the agenda for 2010
<dholbach> pitti: ahh... the Paris sprint... did you get a lot of stuff done?
<pitti> dholbach: yes, went quite well; we packaged new netbook stuff, built a demo CD, and got some boot speed work done; but a major point was transferring our knowledge to didrocks
<dholbach> nice!
<didrocks> good morning
<dupondje> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/508930
<dupondje> can somebody give it a look ? :)
<ubottu> Ubuntu bug 508930 in samba "CIFS mount is offline every x minutes/seconds" [Undecided,New]
<pitti> slangasek: would you mind if I enable all the dailies again?
<pitti> slangasek: i. e. is there a particular reason not to?
<asac> ok
<asac> pitti: cool. nw we see fore3ign in the chart ;) ... nice.
<pitti> asac: I sent details about that to the platform list yesterday
<asac> yep. checking mails ;)
<apw> pitti, my burndown charts have jumped (in the new system) and i seem to have a bunch of duplicates ... aware?
<pitti> apw: jiboumans just reported the same (duplicates)
<apw> happend about 3 days back i'd say
<pitti> apw: the jumps are partially due to the dupes (will fix) and due to adding back WIs from persons which are not in your team, but hare WIs assigned for your team
<pitti> apw: hm, I only committed the latter change yesterday
<pitti> but that affects all history (it just changes the queries, not the data collection)
<mvo> cjwatson: if you don't mind I will do the uploads for bug #505887 today (busybox and sysvinit)
<ubottu> Launchpad bug 505887 in sysvinit "Provide static-sh alias name and ship busybox-static by default" [Undecided,New] https://launchpad.net/bugs/505887
<apw> pitti, ahh, ok then timing means nothing
<pitti> apw: i. e. for the "don't ignore foreign WIs" the jump should have happened from day 1 in the charts
<pitti> (the light-red/light-green parts)
<apw> http://macaroni.ubuntu.com/~pitti/workitems/canonical-kernel-team.html
<apw> if you look at mine, its just the last four days
<pitti> apw: does anything in 'status by spec' look unreasonable?
<pitti> done/postponed didn't change, just todo (team)
<pitti> apw: might just be the duplicate queries, though
<pitti> apw: let's check this out again once I fixed that
<pitti> currently I'm still working on improvements for jiboumans
<jiboumans> pitti++ and don't be afraid to tell me to do some of this stuff :)
<pitti> I just radically simplified the parsing of the blueprint HTML and made it much easier to maintain/debug
<tseliot> pitti, slangasek: is there a way to edit this page? I only need to replace "sudoÂ nvidia-config" with "sudoÂ nvidia-xconfig"
<pitti> jiboumans: if you could port your "expected progress/color coding" to the new branch, I'd appreciate
<tseliot> http://www.ubuntu.com/testing/lucid/alpha2#Known%20issues
<pitti> tseliot: needs to be done by a webmaster; newz2000 is my usual contact point
<tseliot> pitti: ok, thanks
<pitti> jiboumans: ok, just pushed the changes for this TODO:
<pitti> - pull spec info: definition, drafter, approver, wiki link, milestone target
<pitti> jiboumans: I added automatic DB migration code, so in the 1203 UTC run the DB should get migrated, and should pick up all the extra spec info
<jiboumans> pitti++ awesome. i'll check it then and i'll happily port the code
<apw> pitti, soz got bit by a suspend bug
<pitti> apw: soz?
<apw> pitti, soz == short sorry
<pitti> ah
<pitti> jiboumans: so the extended json and expected progress are on your plate now, right? is there any other addition you want me to work on?
<jiboumans> pitti: ehm, don't have our full conversation in my head right now. if all the stuff's in the db, the JSON stuff's straight forward
<pitti> jiboumans: I need to do some bug fixing now (for the duplication), and finish the cleanups, but wanted to check with you wheter there's something left for me from our email exchange
<jiboumans> and we'll hold off the 2 graphs/extended tables to see if the current solution works
<pitti> jiboumans: right, json is by and large just adding what you want; it's a simple "build a dict of stuff you want to see"
<pitti> jiboumans: *nod*
<pitti> jiboumans: I did the "extended spec tables" (drafter/definition/wiki link/etc.)
<jiboumans> ah, the arbitrary meta: stuff
<jiboumans> that's one for CFT right now i think
<jiboumans> perhaps a nice sprint hackathon :)
<jiboumans> pitti: on that list would also be a community-tracker; specs accepted for lucid but not driven by a canonical employee
<pitti> jiboumans: I see; they appear on all-*.html, but you want noteam*.html?
<jiboumans> pitti: they do? i don't see them.. perhaps we're not talking about the same thing.. i mean specs like: https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-asterisk-integration
<pitti> jiboumans: right; they ought to be on all.html (and things like all-lucid-alpha-2.html)
<pitti> (they are)
<jiboumans> pitti: ah, right.. can you match them to the team by using /server-lucid|lucid-server/ and have them show up in the usual reports too? server-alpha3, beta-1, etc?
<pitti> I don't have spec name patterns right now
<pitti> so this would be a thing for the todo list
<pitti> jiboumans: would you mind filing a bug about it, so that we can keep these requests in lp?
<jiboumans> pitti: no problem at all
<jiboumans> pitti: done with #509094
<tseliot> YokoZar: can we talk about bug #506435 and bug #506437?
<ubottu> Launchpad bug 506435 in ia32-libs "ia32-libs should install libGL.so* in /usr/lib32/mesa" [Medium,Triaged] https://launchpad.net/bugs/506435
<ubottu> Launchpad bug 506437 in ia32-libs "ia32-libs should be updated with the libraries from Mesa 7.7" [Medium,Triaged] https://launchpad.net/bugs/506437
<YokoZar> tseliot: What about theM?
<tseliot> YokoZar: shall I take care of those bugs?
<YokoZar> I'm not completely sure what the plan is for ia32-libs at the moment (how it's being phased out, or even if that's still happening in Lucid)
<tseliot> pitti: ^^
<pitti> no idea about ia32-libs, I'm afraid
<tseliot> YokoZar: I guess its removal was postponed (as multiarch support for dpkg was postponed too)
<YokoZar> slangasek might know
<tseliot> ok
<tseliot> YokoZar: ok, so if the package remains, I'll fix those bugs. Deal?
<YokoZar> but yeah, the long and short of it is: if multiarch dpkg is gonna happen in some form, updating ia32-libs to do anything other than remove packages should be the last thing you do (instead making proper multiarch packages would be a better use of time)
<tseliot> yes, of course
<YokoZar> but if it's not gonna happen in Lucid, then we're stuck doing the same thing as in Karmic and will need to kludge ia32-libs further.  So that includes putting things in the right directories ;)
 * tseliot nods
<tjaalton> it's not happening for lucid
<YokoZar> Is it happening in Debian?
<tjaalton> no
<tjaalton> not yet anyway
<tseliot> ok, I guess I'll have to mess with the fetch-and-build script and hope that things go well, then
<dupondje> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/508930 => could somebody get a look @ this? Its annoying issue
<ubottu> Ubuntu bug 508930 in samba "CIFS mount is offline every x minutes/seconds" [Undecided,New]
<cjwatson> mvo: I'm OK with that busybox patch (except you seem to have a stray .pc/.version in the patch); please go ahead
<d1b> hi i have a question.
<d1b> firefox on ubuntu has been modified. i am trying to determine why  https://student1.mq.edu.au doesn't work. i have checked all certs in /etc/ssl/ and i find none with an expiry date of 2004. the cert should be valid but it is being flagged as not.
<d1b> on normal firefox it is valid and is shown as signed with the verisgn level 3 cert.
<d1b> i am not sure this is correct place to raise this issue.
<babbio> i need to compile a vanilla kernel on ubuntu....how to do that?
<babbio> some docs??? thanku
<d1b> babbio: this is not #ubuntu
<babbio> this is ubuntu-devel....and i'm taling of kernel compiling....so i thought this the correct place
<babbio> sorry
<d1b> https://help.ubuntu.com/community/Kernel/Compile
<d1b> babbio: essentially make a config then make-kpkg clean && make-kpkg --initrd kernel_image iirc.
<babbio> i already read that documentation....but does not talk about vanilla kernels
<d1b> babbio: see what i just said.
<d1b> insert make oldconfig infront probably.
<babbio> ok thank u
<mvo> cjwatson: thanks, I fix that and upload
<cjwatson> mvo: I'd been hoping to work out if there's anything that can be done about the fact that busybox Conflicts: busybox-static
<cjwatson> mvo: it might be wise to change live-initramfs' dependency to allow either
<mvo> cjwatson: I can change live-initramfs in that way too
<pitti> apw, jiboumans: dupes in WI tracker fixed
<jiboumans> pitti++
<pitti> yay for too complex SQL queries :/
<pitti> slangasek: I enabled the CD cronjobs again; I suppose it was just an oversight
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, it is about bug #369850
<ubottu> Launchpad bug 369850 in linux "Cannot set up parallel port printer on Ubuntu 9.04 or 9.10" [High,Confirmed] https://launchpad.net/bugs/369850
<tkamppeter> people complain that with recent Ubuntu versions they cannot use parallel printers and in the bug report it is told that loading the parport_pc kernel module solves the problem.
<tkamppeter> Semms that the presence of a parallel port or plugging a printer to it does not auto-load the module.
<tkamppeter> pitti, should the startup script of CUPS load this module? Or do need the udev rules for the parallel port get a correction (load parport_pc in addition)?
<pitti> tkamppeter: which udev rule do you mean? if that can be fixed, it'd be much much better than loading it in the init script
<pitti> (this should really only be done after a large discussion)
<tkamppeter> pitti, I do not know which udev rule, but what loads the modules lp, parport, and ppdev (they are all loaded on my laptop which does not have a parallel port)?
<pitti> tkamppeter: cups' init script already loads lp and ppdev
<pitti> and ppdev depends on parport
<tkamppeter> pitti, so then CUPS' init script should also load parport_pc. How could that get overlooked?
<pitti> I don't know, I don't have a parport printer (or a port, for that matter)
<pitti> anyway, cups' init script _should_ not modprobe anything at all
<pitti> it means that all the parport code gets loaded for everyone, even on machines where you don't need it
<pitti> tkamppeter: perhaps in the past parport_pc was a dependency of lp or ppdev?
<ion> lp is also in the default /etc/modules for some reason.
<pitti> ion: the reason is that it cannot be autodetected by the kernel right now
<tkamppeter> pitti, from the bug report we know that parport_pc is needed, and so parport_pc should be loaded by the same mechanism which loads also the other parallel port kernel modules.
<tkamppeter> So perhaps we should load them all via /etc/modules, but then we have the same problem as with CUPS, the modules get also loaded on machines without parport.
<pitti> tkamppeter: I'd first ask for an udev dump to check whether we can load it in an udev rule
<pitti> depending on whether the system has a parallel port in the first place
<pitti> then we can also drop the other modprobes in cups
<tkamppeter> pitti, can you ask on bug 369850? Or tell me exactly which command the user should execute? He should execute it once wioth printer turned on and once with printer turned off.
<ubottu> Launchpad bug 369850 in linux "Cannot set up parallel port printer on Ubuntu 9.04 or 9.10" [High,Confirmed] https://launchpad.net/bugs/369850
<pitti> tkamppeter: will do
<cody-somerville> pitti, The developer of xfce4-power-manager mentioned to me that he doesn't want to merge in his devicekit branch and do a release because he heard that they're planning to rename devicekit. Have you heard anything about this?
<pitti> cody-somerville: devicekit-power will be renamed to upower at some point
<pitti> cody-somerville: but the migration to that is a simple sed
<chrisccoulson> pitti - have you seen hughsie's recent e-mail to desktop-devel?
<pitti> chrisccoulson: no, I'm not on that list
<chrisccoulson> "I'm intending to keep the devkit-power-gobject library API and ABI stable at least for a few months, and ship a new library side-by-side to allow applications to port during their development cycle, and not to cause pain to the distros."
<chrisccoulson> so, he's planning to rename the D-Bus interface, but keep the library API stable for a little while
<chrisccoulson> so, it will only break applications that use the D-Bus interface directly
<pitti> right
<pitti> but hopefully that won't be too many
<pitti> chrisccoulson: ah, actually I did get it; apparently CC'ed to devkit-devel@
<chrisccoulson> pitti - ah, yeah, he sent it to devkit-devel and not desktop-devel
<chrisccoulson> i forgot that i'm subscribed to the former
<d1b> re my question before, please ignore it. while the behaviour of firefox in ubuntu differs from normal firefox, the site provided incorrect CA information.
<tkamppeter> pitti, OK, thanks.
<cody-somerville> chrisccoulson, pitti: xfce4-power-manager does use the dbus interface. Aliov also says " Richard told me that the daemon, even moving it to upower, will bit change a lot, i'm just waiting if this is the case, then xfpm's devkit-power is almost ready.".
<cody-somerville> chrisccoulson, pitti: How are other folks mitigating this issue?
<pitti> cody-somerville: like g-p-m? they'll just be updated along, I figure
<cjwatson> zul: at some point could you please set packages you upload to have their Maintainer as ubuntu-devel-discuss@lists.ubuntu.com rather than ubuntu-devel@lists.ubuntu.com?  The effect of the latter is that ubuntu-reviews gets a mail in its moderation queue every time you upload something
<zul> cjwatson: sure
<apw> pitti, something is sick with the current lucid.db ...
<apw> sqlite> select count(*) from work_items where milestone='milestone';
<apw> 324
<pitti> eww
<pitti> apw: I'll look into it, thanks
<pitti> apw: I still have a backup from this morning (with the old format 1), which doesn't have this problem
<apw> pitti, dunno if its relevant but when i tried to use the db with older code it was whining about ambigious milestone
<pitti> apw: fun, since it's a foreign key to milestones, and "milestone" is not in milestones
<pitti> apw: the ambiguity was fixed in r100 and r102, do you have those?
<apw> yeah do now, just wondered if there was a connection, sounds like not
<siretart`> someone with live-cd wisdom might want to take a look at crimsun's last comment in bug #203158. isn't the plan to remove libsdl from the live cd completly?
<ubottu> Launchpad bug 203158 in pulseaudio "libsdl1.2debian-pulseaudio must be installed as default by libsdl1.2debian" [Undecided,Invalid] https://launchpad.net/bugs/203158
<alkisg> siretart`: how did you confirm that -all was indeed using pulseaudio?
<alkisg> I tried with a remote thin client, and I didn't get any sound with libsdl1.2debian-all, unless I set that env var.
<alkisg> I did that test the day I posted the reply, I don't know if anything has changed since.
<crimsun> siretart`: removing sdl would mean removing theora, too
<siretart`> crimsun: oh, I see
<siretart`> alkisg: I installed it, started kobodl and confirmed it is named by name in the pulseaudio mixer.
<pitti> apw: 'milestone' problem tracked down and fixed; I added an assertion now that the value is a valid one; thanks for spotting!
 * pitti resets the DB to the good state from this morning
<apw> pitti, yay!
<siretart`> pitti: it seems lool is not around, do you have some minutes to press the magic buttons to finish the libvdpau MIR? that's bug #506788
<ubottu> Launchpad bug 506788 in libvdpau "[MIR] libvdpau" [High,In progress] https://launchpad.net/bugs/506788
<pitti> siretart`: I don't see vdpau on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<pitti> uh, it's currently in multiverse
<siretart`> err, I am absolutely sure that I've seen it this morning...
<pitti> anyway, promoting
 * siretart` hugs pitti
<pitti> you're welcome
<siretart`> this will enable ffmpeg to build and start a (small) transition
<siretart`> no worries, just a shlibs bump
<geser> seb128: just curious, did you got any feedback from soyuz people what caused the OOPS when you tried syncing libxcb on friday?
<seb128> no
<seb128> or I did read the backlog and they didn't highligh me, let me check
<didrocks> ScottK: apparently, you forgot to use the ~ubuntu-core-dev branch for cdbs for your last commit
<ScottK> didrocks: No doubt.
<didrocks> ScottK: I'll merge it first and then add my changes
<ScottK> OK.
<ScottK> Sorry about that.
<didrocks> ScottK: no pb :)
<siretart`> uh, I need to be identified to join #ubuntu-motu? what's up there?
<ScottK> siretart`: It's a defense mechanism against all the spam attacks going on.
<siretart`> oh, I see
<Burn> hello, I've got problems with my ATI 5750 and Ubuntu Linux 64bit, my screen turns grey after 5 to 10 minutes while I'm running the official 9.12 drivers
<Burn> has somebody seen the same behavior?
<ScottK> Burn: You probably want #ubuntu+1
<Burn> ScottK: ok, will take a look there
<Burn> ScottK: in fact no, it should work on Karmic
<ScottK> If you're running Karmic, then #ubuntu
<Burn> hmm, ok
<Burn> thx
<sladen> mdeslaur: traditionally Debian/Ubuntu security notices have given a one-sentence or one-paragraph to covering what the software with the security issue does.
<sladen> mdeslaur: both of today's USNs for pidgin and libthai just dived straight into the security issue without providing the high-level context
<mdeslaur> sladen: Debian does that. Ubuntu has never done that. It's something we're looking to improve soon.
<sladen> mdeslaur: would it to be possible to to return to including a short summary "libthai is..."
<mdeslaur> sladen: yes, we already have plans for that. See: https://wiki.ubuntu.com/SecurityTeam/Specifications/USNSpec and https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-usn-format
<kees> sladen: you're saying that USN-885-1 and USN-887-1 have a different layout?
<sladen> mdeslaur: reading back to earlier USNs (http://www.ubuntu.com/usn/), I might (politely) agree to disagree;  eg. "...xpdf, a viewer for PDF files".
<kees> sladen: ubuntu has never had the software summary (but we plan to)
<sladen> mdeslaur: it's certainly not as consistent as Debian, I'll agree with that
<mdeslaur> sladen: which USN are you looking at that has that info?
<sladen> kees: "never" is a very strong word, just disproved above(?)
<kees> sladen: where?
<sladen> http://www.ubuntu.com/usn/usn-2-1
<kees> sladen: heh, well, alright.  "Since 2005, Ubuntu has never..."  ;)
<kees> but anyway, we've got plans to make a distinct section that only describes the software, separate from vulnerability descriptions.
<sladen> kees: I mainly noticed on this occasion, because I went  "wtf is libthai?"
<kees> heh.  :)
<sladen> fwiw, http://www.ubuntu.com/usn/usn-72-1  "The package "perl-suid" provides a wrapper around perl which allows to use setuid-root perl scripts"
<maco> wow that seems like a rather unnecessary description
<sladen> maco: ...perhaps, but if the inclusive introductary language (with a high-level description) helps to get a security update applied where it might be ignored, then it's a result
<sladen> kees mdeslaur: thanks for the confirmation that it's "in the works"
<kees> sladen: "no USN written by me, jdstrand, or mdeslaur ...."  :)  while it shows my name on that one, it's just because I rebuilt the USN history.  I think these early USNs were still being written "freehand" by pitti, and there was no templating system in place yet.
 * kees nods
<mdeslaur> thanks for your comment sladen, it's much appreciated
<barry> ScottK: did you see this: https://code.edge.launchpad.net/~barry/ubuntu/lucid/distribute/sync-to-sid/+merge/17425
<ScottK> barry: I did not. Looking
<ScottK> barry: The trick is that as a sponsor, I need to see the diff from the current Debian package and the packaging diffs from the current Ubuntu package.  I'm not sure how to do that.
<barry> me neither :/  maybe using some combination of commands that you outlined in your recent udd message?
<barry> ScottK: i could try to generate though
<ScottK> Not sure.  Probably.  Am busy with $WORK at the moment, but if merge proposals are going to be useful pages for merges from Debian, I think it needs to be available.
<barry> good point,  that means the auto-generated diff isn't enough.  okay, let me see what i can do.  go back to $WORK :)
<cjwatson> ScottK: since you need to check out the Ubuntu branch anyway, you can use the bzr diff --old command in https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
<cjwatson> you'd just do 'bzr merge lp:~barry/ubuntu/lucid/distribute/sync-to-sid' instead of merge-package
<ScottK> cjwatson: True.  It'd be nice to see the diffs on the merge proposal as a lot of them that's all it needs to send them back for more work.
<barry> or approve them <wink>
<barry> cjwatson, ScottK that's essentially what i did.  i merged lp:debian/sid/distribute and lp:ubuntu/lucid/distribute locally, then did the bzr diff --old commands and pastebin'd them.  those are linked in mp comments
<ScottK> Ah.
 * ScottK looks again
<ScottK> barry: Why did you add python2.5-dev to the build-depends?
<barry> ScottK: which diff are you looking at?  i didn't think i did
<barry> ScottK: ah, diff against sid
<ScottK> Yes
<barry> ScottK: i guess that's coming from the ubuntu package. it wasn't a change i made explicitly
<ScottK> Since Python 2.5 isn't a supported Python in Lucid, I'm reasonably certain we don't need it.
<barry> i should remove that then
<ScottK> It looks like there are a few other places that have extra 2.5's in them
<ScottK> Specifically pyvers in debian/rules
<barry> ScottK: i guess i should remove the "PYVERS := 2.4 2.5" line?
<lool> jdstrand: Re: FORWARD rules for vms/libvirt in ufw -- actually libvirt already manages to add its rules for the dnsmasq virbr0 already
<lool> So at least that seems to work out of the box; probably not for other networks though
<ScottK> barry: Yes.
<barry> ScottK: k, will do
<slangasek> pitti: CD cronjobs> yes, sorry
<RainCT> Argh. Can some archive admin please reject espeak-gui?
<sebner> RainCT: ho ho ho. ~ppa1 :P
<RainCT> sebner: Yeah. Why isn't there an autoreject for anything containing "~ppa"? :(
<geser> file a bug
<sebner> RainCT: because ~ppa is for PPAs and people should be aware of that :P
<sebner> huhu geser :)
<barry> ScottK: i'm looking at the distribute package and i can't see where debian/python-distribute.debhelper.log or debian/python-distribute.substvars are even needed.  the latter is referenced in rules, but commented out.  is there something i'm missing or can i just rm those files?
<ScottK> barry: The debhelper logs are autogenerated cruft and can be ignored/removed.
<ScottK> Same thing with substvars.
<ScottK> I'd leave them though to miminze the diff.
<barry> ScottK: okay.  i'll revert the changes to the .substvars file to reduce diff clutter
<fagan> Anyone free to talk about hardy to lucid upgrades?
<fagan> Its nothing bad trust me :)
<fagan> Ah ill talk about it tomorrow
<fagan> brb restarting
#ubuntu-devel 2010-01-19
<yofel> pitti: hi, can you upload a new version of the apport bash-completion to apport-bzr? My r16 has support for all apport commands in /usr/bin now
<jdstrand> lool: yes, that is what I meant the other way-- ufw doesn't flush the builtins by default, so applications that add rules in the manner that libvirt does will work out of the box. if you would prefer to have ufw manage the builtin chains, you can do that with MANAGE_BUILTINS in /etc/default/ufw
<jdstrand> s/other way/other day/
<maxb> debchange has been mismerged breaking the --distributor option (again)
<maxb> :-/
<maxb> If there's a sponsor around, could you eyeball https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/509441 and tell me whether you'd want anything more in the bug before you considered it reviewable?
<ubottu> Ubuntu bug 509441 in devscripts "dch --distributor broken in lucid due to bad merge from Debian" [Undecided,New]
<chrisccoulson> whats happening with the buildd's? i've just had a weird build failure, and I just checked the last few minutes and it seems that everyone's uploads are failing in the same way
<chrisccoulson> http://launchpadlibrarian.net/38063194/buildlog_ubuntu-lucid-i386.gnome-power-manager_2.29.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<RAOF> Being discussed in #launchpad; looks like it's fixed.
<chrisccoulson> RAOF - thanks
<RAOF> And that pkgbinarymangler was the culprit.
<chrisccoulson> i guess i'll just leave my upload for tonight
<stgraber> chrisccoulson: it should work just fine now
<chrisccoulson> stgraber - thanks, i'll retry that shortly
<hyperair> are the buildds broken?
<RAOF> They have been.  I think they're meant to be fixed now, though.
<hyperair> i see.
<hyperair> then maybe someone should retry g-p-m's build
<stgraber> hyperair: clicked a few links on LP, will start building in a few minutes
<hyperair> stgraber: thanks.
<wolter> Hi, I come to speak on behalf of the Ubuntu Manual Project. We wanted to know if there were any solid plans for the Software Center
<dholbach> good morning
<pitti> good morning
<pitti> yofel: bash-completion> pulled, thank you!
<pitti> argh
<pitti> anyone doing syncs right now?
<pitti> ah, I don't think I actually touched them; flush-backports just looks very strange
<tkamppeter> pitti, hi
<pitti> tkamppeter: guten Morgen
<tkamppeter> pitti, about bug 369850, you wanted to ask the user to check udev for his parallel port and printer.
<ubottu> Launchpad bug 369850 in linux "Cannot set up parallel port printer on Ubuntu 9.04 or 9.10" [High,Confirmed] https://launchpad.net/bugs/369850
<pitti> tkamppeter: still on my list
<tkamppeter> pitti, OK
<ttx> pitti: could you reset the burndown line on http://macaroni.ubuntu.com/~pitti/workitems/canonical-server-lucid-alpha-3.html to Jan 17 (or later) ?
<pitti> ttx: sure, I could; however, do you have two minutes to find out how to do it yourself? (teach a man to fish and all that)
<ttx> pitti: I'm all ears :)
<pitti> ttx: bzr get lp:launchpad-work-items-tracker
<ttx> done
<pitti> ttx: I added you to ~work-items-tracker-hackers, so that you can commit
<pitti> ttx: edit config/lucid.cfg
<pitti> ttx: and add an entry to trend_start
<pitti> something like
<pitti>   ('canonical-server', 'lucid-alpha-3'): 123
<pitti> then commit/push the change, and the next cronjob will pick it up
<pitti> oh, please append the trailing comma
<ttx> I suppose 123 is day of year ?
<pitti> ttx: no, the number of work items that the trend line starts on
<ttx> ah, right
<ttx> so you don't reset on a day
<ttx> pitti: the starting day is hardcoded somewhere ?
<pitti> ttx: it's the beginning of the cycle
<pitti> ttx: in theory we could change it to start from the previous milestone
<pitti> but then you couldn't plan ahead
<ttx> pitti: ok, so I need to extrapolate a little.
<pitti> however
<pitti> ttx: how about this:
<pitti> we change the trend line start for milestone m not to start on opening release, but on the end of m-1
<pitti> that should give better defaults
<ttx> pitti: yes, that sounds better
<pitti> ttx: but anyway, just commit your change now; we can drop those again once we have a more clever trend line start
<maxb> If there's a sponsor around, could you eyeball https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/509441 and tell me whether you'd want anything more in the bug before you considered it reviewable?
<ubottu> Ubuntu bug 509441 in devscripts "dch --distributor broken in lucid due to bad merge from Debian" [Medium,Fix released]
<pitti> tkamppeter: bug 369850 already has all the udev logs, and it's assigned to a kernel engineer; so I think we can just let it sit there for now
<ubottu> Launchpad bug 369850 in linux "Cannot set up parallel port printer on Ubuntu 9.04 or 9.10" [High,Confirmed] https://launchpad.net/bugs/369850
<RAOF> seb128: I was looking at the gnome-shell FTBFS in lucid, and I've got a branch up that fixes it, but I'd like to discuss it because I'm not sure whether it should be fixed there or in gjs.
<seb128> RAOF, do you set LD_LIBRARY_PATH or proload libmozjs?
<seb128> oload -> eload
<RAOF> Neither; I dropped the linkage against libmozjs.
<RAOF> But LD_LIBRARY_PATH works, yes.
<seb128> does your change makes "gjs" work?
<seb128> ie calling the gjs interpreter
<RAOF> It doesn't change gjs, only gnome-shell - it drops the extra dep by passing --as-needed to the linker.
<RAOF> But I think there should be a better fix in gjs, yes.
<RAOF> Possibly - it looks like gjs-consuming apps don't actually need a mozjs linkage, so the pkg-config files should'nt add that dep.
<seb128> does gnome-shell run correctly?
<seb128> because as said gjs doesn't run
<RAOF> Yes.
<seb128> so I expect you will still get issues if gjs is not fixed correctly
<RAOF> With what package does gjs not run?
<seb128> run "gjs"
<seb128> it's from the gjs binary
<RAOF> BAH!  Stupid locally installed apps.
<seb128> I don't really get the issue
<seb128> ldd lists libmozjs twice
<RAOF> Three times, for libgnome-shell.so.
<seb128> one which is a not found and one which is a correct one
<seb128> I think I tried to ldd gjs-gi.so or something
<seb128> but still there is a bug somewhere
<seb128> but the same version works on karmic
<RAOF> It's because libgnome-shell is explicitly linked against libmozjs & libgjs-gi, libgjs-gi is explicitly linked against libmozjs and libgjs, and libgjs is explicitly linked against libmozjs with a correct RPATH
<seb128> so I'm a bit puzzled by the issue
<seb128> how come it worked in karmic?
<RAOF> Now, I shrug my shoulders.
<RAOF> Were we building against libmozjs-dev?
<seb128> no
<seb128> using xulrunner-dev
<seb128> could be that gjs was buggy in karmic too
<seb128> but we had LD_LIBRARY_PATH hacks in gnome-shell
<RAOF> That would make it work.
<seb128> I think I dropped them thinking debian was solving that in some other way
<seb128> but they don't, they use their libmozjs binary
<RAOF> Yeah, by declaring libmozjs a system-library.
<seb128> which is a lib I think
<RAOF> Yeah; Debian've stuck an soname on it and called it charlie.
<dholbach> mdke, sabdfl: if you should be around...  #ubuntu-meeting ? :)
<seb128> not sure what is better between the karmic library path change or your as-needed
<seb128> asac claims libmozjs is not ready to be shipped this way
<seb128> ie as a system library
<RAOF> Upstream were talking about aggressively breaking api, yes.
<seb128> since upstream doesn't assure stability, etc
<RAOF> Well, as long as as-needed doesn't break anything it's got a pleasant side effect of fixing a bunch of dpkg-shlibdeps warnings.
<seb128> right, feel free to upload
<RAOF> But I think a real solution would be to ensure that the gjs pkg-config files don't pull in libmozjs, and ensure that libgjs-gi has the right rpath set.
<RAOF> But investigating that can be a job for tomorrow.
<cemc> anybody care to take a look at this? bug #96850 (last comment). thanks.
<ubottu> Launchpad bug 96850 in rrdtool "[apport] perl crashed with SIGSEGV in rrd_test_error()" [Medium,Fix released] https://launchpad.net/bugs/96850
<seb128> RAOF, thanks for working on those
<RAOF> seb128: No problem.  Now, if nouveau would just fix their 3d so that gnome-shell didn't have serious glitches on this laptop... ;)
<ScottK> pitti: Would you please have a look at accepting quassel for karmic-proposed.  jdong already approved the SRU (Bug #509287), but I didn't feel I should accept it since it's my upload.
<ubottu> Launchpad bug 509287 in quassel "[Needs Update] Quassel (Ignorelist adding ctcp ignore)" [High,In progress] https://launchpad.net/bugs/509287
<pitti> ScottK: right, I saw the bug mail; done
<ScottK> pitti: Thanks.
<tkamppeter> pitti, OK. I overlooked this. I am simply subscribed and get the notifications. I think that I have delegated it to the kernel. And it seems that it is really the kernel and not udev according to Scott Remnant.
<tkamppeter> pitti, I got a patch with fixes memory hogging by pdftopdf today from upstream, I will apply it to CUPS. After that we could do an SRU for Karmic to fix 3 problems.
<cjwatson> soren: erk, what's with the new dependency on grub in python-vm-builder?  I thought I removed the dependency on grub being installed on the host some time ago.
<cjwatson> lool: ^- oh, it was your change
<cjwatson> lool: upstream r348 was supposed to remove this requirement
<tkamppeter> pitti, CUPS updated to include pdftopdf memory hog fix. Can you upload it? Thanks/
<lool> cjwatson: I wanted to look into this today; I remembered a hard requirement on grub1, and saw what I recalled when grepping vm-builder, but apparently I missed the grub2 bits
<lool> let me revert that then
<soren> lool: The grub2 bits are not there. cjwatson just fixed things so that having grub in the guest sufficed.
<soren> (rather than on the host)
<lool> Great; that's actually what I wanted to do as well
<lool> I pointed people requesting a port to grub2 to the bug proposing to use the guest's bootloader instead
<cjwatson> I already produced a branch for grub2
<cjwatson> hmm, though maybe I never finished it
<cjwatson> apparently not.  running it in the chroot should be enough though.
<lool> That's great, that was the next thing I wanted to do
<lool> cjwatson: There's a branch for ext4 support which will turn itself on only if the target is >= karmic
<lool> cjwatson: perhaps you want to do the same thing for grub1 versus 2
<cjwatson> lool: http://paste.ubuntu.com/358992/ is my WIP if you want to pick it up; I don't have time at the moment
<cjwatson> I think I shelved it because it was blocked on a grub-install bug processing the --grub-probe option, but that's now fixed
<soren> seb128: You do this boot time testing thing all the time, right? Could I pursuade you to see how installing irqbalance affects boot speed?
<seb128> soren, I do regular ones, sure I will try that this afternoon and let you know
<soren> seb128: Fantastic, thank you.
<lool> cjwatson: reported bug + attached your patch in 509609; thanks
<cjwatson> lool: cheers
<seb128> soren, is irqbalance supposed to be running after boot?
<seb128> it's enabled by default apparently in the etc config
<seb128> but not in the processes list
<soren> seb128: That's expected.
<soren> seb128: On single cpu systems (even multi-core), it will only run for a short while.
<soren> seb128: Like 10 seconds or so.
<seb128> soren, ok, I found it on the chart
<seb128> soren, it has no visible activity there
<seb128> seems to not make any difference
<seb128> that's on the mini config
<seb128> ie atom cpu
<bluefox_> is there a reason ubuntu doesn't package songbird?
<soren> seb128: No difference at all? Neither positive nor negative?
<soren> seb128: I guess if it made any difference, it's too little to be reliably measured.
<seb128> soren, right, charts change in a 0.5 seconds margin between boots
<seb128> soren, it's not significant enough to tell there
<soren> seb128: Ok, that's good enough for me. Thanks very much!
<seb128> you're welcome
<soren> zul: You're driving the irqbalance-by-default thing, right?
<soren> zul: If so, see the last 20-ish lines of scrollback ^^
<zul> soren: yep reading cool!
<zul> ill reply to the mailing list today
 * zul goes back to fixing a broken server
<Riddell> superm1: is dell-recovery ment to be a native package?
<cjwatson> james_w: do you know if there's a workaround for bug 499651?
<ubottu> Launchpad bug 499651 in bzr-builddeb "[merge-package] ERROR: exceptions.ValueError: Cannot have multiple roots." [Undecided,New] https://launchpad.net/bugs/499651
<geser> cjwatson: I had once a similar case and it was because the Ubuntu packaging and Debian packaging were done independent (we didn't have synced/merged the Debian package once)
<didrocks> I have a new documentation package for a library that export some files like that: /usr/share/gtk-doc/html/libdbusmodel/index.html. I have no strong opinion if I should call the package libdbusmodel0-doc or libdbusmodel-doc (including serie or not). Any thought?
<geser> does the -dev package contain the soversion?
<didrocks> geser: no, it doesn't
<geser> then I'd prefer libdbusmodel-doc as I don't see why you might need two different -doc versions installed and yet only the most recent -dev package
<didrocks> geser: I agree
<didrocks> geser: thanks :)
<cjwatson> geser: but these are both automatic imports
<ogra> pitti, you only enabled the autobuilds yesterday again, right ?
<pitti> ogra: correct
<ogra> thanks
 * ogra wonders why the livefs log for tonight didnt get mirrored
<seb128> doko, you tried to upload pyorbit to karmic
<ogra> i see it on the live build machine for armel, but not on people.c.c
<seb128> doko, you're summary of ubuntu change doesn't mention the dbg either
<seb128> doko, is that wanted?
<doko> seb128: ahh, will fix it
<seb128> doko, thanks
<seb128> doko, right, it seems you dropped the -dbg in that upload
<seb128> not sure if that's what you confirmed or just the wrong upload target
<ogra> cjwatson, could it be that the log mirroring script that writes to http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ uses rookery as a machine name ? (seems the logs dont get mirrored since the move)
<seb128> slangasek, somebody didn't flush syncs, is that you?
<cjwatson> ogra: what do you mean "uses rookery as a machine name"?
<ogra> cjwatson, as target for the copying ...
<cjwatson> ogra: it's a pull script
<ogra> oh, ok
<ogra> then i guess its just fallout of the mmove and the mentioned cron issues
<cjwatson> ogra: I'll look into it
<ogra> thanks
<SeaOrifice> can someone help me in compiling a driver module for an ethernet card ???
<seb128> doko, is the new glibc known to be buggy with valgrind?
<seb128> I get zillion of errors
<seb128> ==5869==    at 0x4A5679F: __strlen_sse2 (strlen.S:106)
<seb128> example
<seb128> ==5869== Invalid read of size 8
<seb128> ==5869==    at 0x4A5679F: __strlen_sse2 (strlen.S:106)
<seb128> ==5869==    by 0x43A1FBC: gtk_widget_class_path (gtkwidget.c:9934)
<seb128>  
<seb128> on anything I try to run
<doko> I'd rather say that the old valgrind doesn't work with it
<seb128> do you plan to upgrade valgrind?
<doko> not this week
<apw> pitti, i thought we had an older db for the new burndown charts on macaroni?  i seem to have four tall bars now
<seb128> ok :-(
<seb128> doko, is there any workaround that I could use to be able to use valgrind?
<seb128> I need it to debug some crasher
<doko> I didn't look yet. maybe take a look at a new valgrind yourself for now?
<seb128> doko, I can try, thanks
<Laibsch> lool: I'd like to talk with you about MIR for kasumi (bug 424238)  Do you have some time?
<ubottu> Launchpad bug 424238 in kasumi "[MIR] kasumi" [Undecided,Incomplete] https://launchpad.net/bugs/424238
<lool> Laibsch: Sure
<lool> Laibsch: Just ask here
<pitti> apw: four tarballs?
<Laibsch> lool: OK
<Laibsch> Here we go
<pitti> apw: I still keep a v1 db around from yesterday, if you mean that
<apw> pitti, hehe no, i mean i still have that jump in the data
<pitti> apw: right
<pitti> apw: didn't see my ping from this morning?
<pitti> apw: that was a genuine data loss, due to a brain fart of mine, sorry
<apw> pitti, ahh missed it, having lots of irc issues
<apw> oh so i really do have 130 odd tasks?
<pitti> apw: I'll adjust the trend line start accordingly
<apw> pitti, in other news, i see we are flattening inprogress and todo to todo in the db, i'd like to stop doing that
<Laibsch> lool: I've made a new upload to mentors.debian.net: http://mentors.debian.net/debian/pool/main/k/kasumi/kasumi_2.5-0.dsc (don't worry about the -0 version number, that is not meant for release).  Changes are documented at http://git.debian.org/?p=collab-maint/kasumi.git
<pitti> apw: right, the current task count is correct
<apw> so that my tables can differentiate, and before i make the _completions zap inprogress to todo i wondered if you wanted that too
<pitti> apw: I added some debugging to that yesterday, to compare total #wi from by-assignee and by-spec, and they all match now (I fixed the duplicate bug)
<Laibsch> lool: the things that may still need to be done were listed in the bug tracker (last comment).  It would be nice if you let took a look and let me know about the current state of affairs from your perspective.
<apw> pitti, yeeks
<Laibsch> s/let//
<lool> If I debdiff the current kasumi against your updated one, the debian/changelog doesn't list the changes you did
<pitti> apw: I don't need an "in progress" state for my purposes, but if you do, feel free to hack it in
<Laibsch> lool: no, that will be done once I release
<Laibsch> git-buildpackage
<Laibsch> it's better not to commit changes to the changelog until release
<Laibsch> lool: take a look at the commits in git
<lool> Laibsch: You can update the changelog before each upload to mentors though
<lool> git-dch is clever enough to check when the debian/changelog was last updated
<Laibsch> alright
<Laibsch> that aside
<Laibsch> It's not meant to be released that way
<Laibsch> same with -0
<apw> pitti, so are we officially no longer updating the old data now?
<pitti> apw: you mean the one on piware?
<lool> Laibsch: was the patch sent upstrean
<lool> *upstream
<apw> yeah ... trying to work out where we are at
<pitti> apw: the "entire cycle" cronjobs are still running; cjwatson asked me to, for having consistent WI counts
<pitti> apw: I don't have cronjobs for alpha-3 on piware.de
<Laibsch> lool: no, not that I know.  Is that a requirement for MIR?  The list was already long enough :-D
<apw> so i should be swapping and working with the new ones
<Laibsch> lool: Remember, I'm trying to help you guys
<pitti> apw: ideally yes; I'm fine with having the trend line adjusted accordingly; that's what desktop and mobile are doing now
<lool> Laibsch: The MIR is about evaluating the pain / risks of having a package in main
<Laibsch> This all started because I pushed back stuff for scim-anthy from Ubuntu so you could sync instead of merge
<apw> pitti, am i correct in thinking you cannot generate a .png trivially?  it seems we cannot insert .svg into wiki land
<Laibsch> lool: balance that with the risk of contantly needing to merge a package that is already in main
<lool> Laibsch: I will list all issues I find the packaging and ask whether it's properly maintained; some small issues are fine, it's not like this patch is complex for instance, but it's normal that I check the quality of the maintenance
<Laibsch> lool: because that is the alternative.
<Laibsch> lool: sure
<Laibsch> I'm just also trying to make you understand my position
<lool> Laibsch: I don't really get it; are you maintaining this in Debian as well?
<Laibsch> I'm not benefiting from a MIR for kasumi
<Laibsch> it's only more work
<Laibsch> lool: sure
<Laibsch> both packages
<Laibsch> I saw they were not properly maintained
<lool> Laibsch: Whatever issue I find is useful to resolve in both distros then
<Laibsch> and asked Ikuya if he wanted help
<Laibsch> yes, absolutely
<lool> Laibsch: I'm not trying to create more work for you; I'm scanning the whole package and saying "I found this and that blahblah"
<Laibsch> lool: I'm grateful for that
<lool> Laibsch: Great; let's attack the actual issues and see what's left we can't easily resolve?
<apw> pitti, do what do you need from me to work out the original burndown, i assum we just set the start number back at the original date to what it is now
<Laibsch> but we should differentiate between "look at X when you have time" and "you need to fix Y before MIR can be granted"
<lool> Laibsch: I see you use the upstream man page now, but you kept a xsltproc build-dep; is it really needed now?
<Laibsch> lool: sounds like a plan
<lool> (grepping for xsltproc in the source returns nothing)
<Laibsch> that predates my time so I need to check
<lool> Laibsch: I will absolutely let you know which ones are blocking issues and which aren't; sometimes there are many small issues and I'll say: fix some of these
<lool> Laibsch: It doens't predate your time, but it's a commit by Ikuya
<Laibsch> well, that's the thing.  There already was a list, and now there are new things.  So, I'm afraid it will never end.  At which point I would tend to more pressing issues and let somebody else resolve it.
<Laibsch> It predates my "kasumi" time
<Laibsch> or at least I think
<lool> Laibsch: you did some commits in the git repo before that change
<lool> Laibsch: ee4923ddb5ac9db4af8f003a202f4836b06a6437 is the commit
<lool> You did 618b24b15438b34361ba648838d9649acd39fb1d just before
<pitti> apw: .png> pychart can do it, but not on macaroni, since that doesn't have ghostscript
<lool> Laibsch: I would love if you could file an upstream bug on the usage of AM_PATH_GTK_2_0() that's really old stuff
<apw> pitti, for now it'll have to be a link to the chart
<pitti> apw: if it's important, we could do an RT and ask for it
<Laibsch> I see.  Those commits were made when we actually met in Kobe
<apw> pitti, makes the pages less intuitive, not the end of the world
<lool> Laibsch: Do you have a build log of your kasumi 2.5 tree somewhere?
<lool> (On Ubuntu)
<Laibsch> no
<Laibsch> sorry
<Laibsch> It was a local pbuilder build
<Laibsch> There's still some errors about "uselessly linking against $blah"
<pitti> apw: btw, feel free to adjust the trend line start yourself (it's in config/lucid.cfg, there are existing examples)
<lool> Laibsch: BTW the original MIR review had the blocking stuff listed: So I'd love if you could work on copyright and rules to fix at least the licensing, pot and configure .PHONY issues.
<lool> Laibsch: Your list is pretty much complete and looks good
<lool> Laibsch: (comment #6 in the MIR)
<apw> pitti, when is trend_start value in time?
<lool> Laibsch: I don't understand the settings menu bit
<jdstrand> stefanlsd: hi! where is the code for http://people.ubuntu.com/~stefanlsd/synclist.html?
<pitti> apw: it's the #WIs that the trend line starts at
<apw> but 'when'
<apw> at the first column in the charts?  or at some specific date
<pitti> apw: ah; lucid start
<pitti> apw: right, at the first column
<Laibsch> lool: https://bugs.launchpad.net/ubuntu/+source/kasumi/+bug/424238/comments/6 is essentially what I understand is what's left of the original request.  And I'm sorry but my skills don't seem to be adequate to fix any of them.  So, somebody else will have to do that (or heavy coaching, I can't spend days on fixing this).
<ubottu> Ubuntu bug 424238 in kasumi "[MIR] kasumi" [Undecided,Incomplete]
<pitti> apw: we could let the alpha-3 chart start at the end of alpha-2; but then we couldn't plan ahead so easily
<apw> pitti, so first column of the current data, not as at 1 november sort of thing
<Laibsch> lool: settings menu relates to your earlier comment "do we really want to add a new entry in the settings menu that late in the cycle and for a very specific app which most people dont need to configure?"  Don't ask me, I understand all the stuff you wrote ;-)
<lool> Laibsch: updated 403189
<lool> Laibsch: So who from the kasumi maintainers has the skills to fix the remaining issues?
<Laibsch> to be honest, I'm not sure ;-)
<lool> Hmm
<Laibsch> skill level in Japan doesn't always match that in Europe or the US
<lool> Laibsch: Who's your sponsor?
<Laibsch> But that goes for the programming itself as well ;-)
<lool> This is going to be a handicap for me http://kasumi.sourceforge.jp/index.php?%A5%D0%A5%B0%CA%F3%B9%F0
<Laibsch> I have several sponsors, depending on package and work load of the sponsor
<lool> Laibsch: I guess you do speak Japanese?
<Laibsch> lool: yes
<Laibsch> It's a patchwork of skills needed to get Japanese stuff in shape
<lool> Laibsch: I could help locally to address some of these issues, but I can't directly work with upstream if their web pages are in Japanese (starting with I don't know which button to push)
<soren> Oh.
<Laibsch> sure
<soren> UDW is /next/ week.
<Laibsch> I'm glad to help
 * soren stops preparing for his session "tonight"
 * soren facepalms
<lool> Laibsch: I see the warnings at http://lintian.debian.org/maintainer/ikuya@oooug.jp.html#kasumi were mostly fixed -- great
<lool> Laibsch: So overall I think this made nice progress but we need to get the updated source in Debian and finish some of the remaining technical bits; I'm happy to assist there
<lool> Laibsch: Concerning sponsoring, I'm technically a DD but given the nature of the applications, I would highly prefer if you could find someone who uses or can at least test the app
<Laibsch> But as I said, I will need some help in the more technically involved issues.  I'm not a computer programmer and I know close to nothing about build systems.  But that usually doesn't keep me from maintaining packages or writing recipes in openembedded.org.  I find that most people that do know about build systems don't bother about packaging them properly according to Debian standards.
<Laibsch> I know two DDs in Japan that I can ask
<Laibsch> This is a simple app, though
<Laibsch> It's basically a dictionary front-end
<Laibsch> lool: given the remaining list, I'll need more coaching, preferably in the form of patches ;-)
<lool> Laibsch: Ack; as said, I can help there
<lool> Laibsch: I'm putting this down in the MIR
<Laibsch> "drop obsolete AM_GTK macro" doesn't really give me concrete enough hints
<Laibsch> cool
<lool> Laibsch: Could you push your 2.5 to some PPA?
<Laibsch> sure
<Laibsch> lool: https://launchpad.net/~r0lf/+archive/hardy should arrive in a minute or two, depending on LP load
 * Laibsch hopes it builds in hardy
<lool> Laibsch: Building on lucid would be good
<Laibsch> I will copy later
<lool> To clarify: I'm interested in a lucid build log
<pitti> apw: correct, it's always the first bar; no date (sorry for lag, I'm on a hideous network connection right now)
<Laibsch> lool: I uploaded it there because that is the only target I have in ~/.dput.cf with a fixed Ubuntu release.  Otherwise I get errors of "unstable is not a known release" or "UNRELEASED is not a known release".  Saves me from changing debian/changelog all the time.
<Laibsch> lool: I'll copy it once it arrives
<lool> Laibsch: You can add checks of target release to your dput.cf
<jdstrand> kees, mdeslaur: do you guys happen to know where the code is for http://people.ubuntu.com/~stefanlsd/synclist.html? I'd like to check it in somewhere in our tools
<jdstrand> (I asked stefanlsd earlier, but he doesn't seem to be around atm)
<kees> jdstrand: sorry, I don't.
<mdeslaur> jdstrand: nope, sorry
<jdstrand> np
 * jdstrand tries to be patient
<lool> Laibsch: So I unpacked the 2.5 source package, and I could ./configure&& make distcheck (got a tarball in the end) which is good
<lool> Laibsch: Would you mind pointing me at the upstream Vcs for kasumi?
<Laibsch> cvs -z3 -d:pserver:anonymous@cvs.sourceforge.jp:/cvsroot/kasumi co kasumi2
<Laibsch> cvs -d:pserver:anonymous@cvs.sourceforge.jp:/cvsroot/kasumi login
<Laibsch> lool: http://sourceforge.jp/cvs/view/kasumi/kasumi2/
<lool> thanks
<Laibsch> lool: https://launchpad.net/~r0lf/+archive/ppa/+sourcepub/935159/+listing-archive-extra
<Laibsch> https://launchpad.net/~r0lf/+archive/ppa/+build/1454487
<apw> pitti, i have a couple of blueprints with wither ubuntu-10.04 or ubuntu-10.04-beta-1 as milestones and the spec entries in the table do not seem to have the milestone
<apw> https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-lucid-bugs-with-patches
<apw> the milestones do appear in the list correctly
<apw> pitti, ahh we need a '.' in the match
<apw> pitti, got an incantion i can apply to collect to test it? (/query it perhaps)
<superm1> Riddell, it is meant to be yes.  It's developed for ubuntu
<Riddell> superm1: groovy, I'll accept
<superm1> thanks
<kees> asac: can you look at bug 507744 to be added to the work you're doing for the next firefox package?
<ubottu> Launchpad bug 507744 in xulrunner-1.9.1 "build with PIE to gain remaining ASLR support" [Medium,In progress] https://launchpad.net/bugs/507744
<masquitos> anybode here?
<mdeslaur> chrisccoulson, seb128: fyi, I've added some apport hooks to the gnome-screensaver bzr
<chrisccoulson> mdeslaur - thanks
<chrisccoulson> mdeslaur - i'm going to do an upload later with a couple more changes in
<mdeslaur> chrisccoulson: cool, thanks
<smoser> slangasek, in Keybuk's absense, maybe you can verify.  I think that upstart used to read '--verbose' and '--debug' off the kernel command line, and documentation implies that it does, but i'm virtually certain it is not doing so now.
<akgraner> robbiew, ping got a sec?
<micahg> Laibsch: meeting in #ubuntu-bugs
<Laibsch> micahg: Ah, thanks for reminding
<jdstrand> james_w: perhaps a dumb question-- once I follow https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging and then commit the changes, will the source get built automatically or do I need to upload like normal?
<jdstrand> james_w: hi btw :)
<hwilde> in udev 60-persistent-storage.rules where does it get $env{ID_FS_UUID_ENC}    ?
<cjwatson> jdstrand: you still need to upload; building directly from branches is being worked on but isn't ready yet (and will take a while, I expect)
<jdstrand> cjwatson: cool, thanks
<pitti> hwilde: from blkid
<pitti> hwilde: in particular, from this rule: KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
<jdstrand> james_w, cjwatson: tbh, this is the first time I've used bzr merge-package. It was a simple merge, but the process was very nice. :)
<xteejx> Hi guys, I'm having problems with qemulator, as are a few others, I understand that the Ubuntu Development Team are the maintainers? I wanted to ask if there is any chance we can get the latest unstable svn version, as the stable hasn't been updated for a few years?
<ttx> pitti: when does the workitem code refresh ? I committed the trendsline reset this morning and it still doesn't appear on the graph...
<pitti> ttx: I got a "branch is diverged" cron error mail, so you won't see your change in the current charts; I'll fix it up this evening, when I'm back at a computer where I can ssh to macaroni
<xteejx> specifically, the problem with bug 382521 - it's unusable
<pitti> ttx: in principle, it pulls hourly
<ttx> pitti: ok cool, thanks
<ubottu> Launchpad bug 382521 in qemulator "[lucid] qemulator.py crashed with TypeError in on_treeviewBootimages_cursor_changed()" [Undecided,New] https://launchpad.net/bugs/382521
<directhex> moo
<xteejx> Do any of the maintainers for qemulator (Ubuntu Development Team) have any idea if there is a chance of getting the latest version into Ubuntu, as I believe it may then be usable.
<xteejx> ref bug 382521 as described above :)
<ubottu> Launchpad bug 382521 in qemulator "[lucid] qemulator.py crashed with TypeError in on_treeviewBootimages_cursor_changed()" [Undecided,New] https://launchpad.net/bugs/382521
<kees> Riddell: so, I'm looking at virtuoso-opensource.
<kees> Riddell: it builds a daemon that listens on 0.0.0.0 :(
<lamont> kees: and no option to force it to an IP other than 0.0.0.0?
<kees> actually, I take it back, the default ini does the config
<lamont> heh.  ini
<kees> Riddell: so, how is this intended to work?
<kees> Riddell: what generates the .ini that it loads?
<Riddell> kees: nepomuk semantic desktop does, it always sets DisableTcpSocket=1
<kees> ah! okay.
<kees> Riddell: what do you think of shipping the server in /usr/lib/virtuoso-opensource instead of /usr/bin ?
<Riddell> kees: that would probably need some patches somewhere but should be fine
<kees> hm.
<Riddell> kees: yeah it's just libsoprano that needs patching, I see where it needs done so not hard I think
<kees> I think it would just be cleaner that way, since virtuoso-t doesn't run out of the box (it needs the .ini) so putting it in /usr/bin seems odd
<Riddell> I agree
<pitti> apw: http://macaroni.ubuntu.com/~pitti/workitems/canonical-kernel-team.html
<pitti> apw: there, adjusted trend line
<apw> pitti, cool except we are the wrong side of it
<pitti> how do you mean?
<kees> Riddell: it should be using system zlib instead of its internal copy, too.
<kees> Riddell: I'm trying to figure out what libsrc/Wi/bif_files.c is for, though.  it seems to have a specific function to run commands
<Riddell> kees: yeah I couldn't see an obvious way to make it do that
<kees> Riddell: really? it's in the configure.in I thought
<Riddell> of course it's possible I missed something obvious
<kees> ./configure  --without-internal-zlib   if its docs are to be believed
<Riddell> oh, duh
<kees> maybe it needs further tweaking to get the right includes, but I haven't actually tried it.
<jjardon> Maybe of your interest: udev-browser: http://0pointer.de/blog/projects/udev-browse.html
<macli>  /close
<seb128> ev: hey
<ev> seb128: hi
<seb128> ev: thanks for the pygtk patch, did you send it upstream, I don't find the bug...
<ev> seb128: I mentioned it in the changelog: https://bugzilla.gnome.org/show_bug.cgi?id=607453
<ubottu> Gnome bug 607453 in gtk "Support for GtkSpinner" [Enhancement,Resolved: notabug]
<seb128> ev: oh right, I overlooked that, I'm use to have the info in the patch description ;-)
<seb128> ev: thanks
<ev> ah, apologies
<seb128> nothing to apology about, sorry for overlooking it in the changelog
<xaxez> http://pastebin.com/m116119d1 any idea????
<spy6> hi there
<spy6> i'm affected by #469985 ... is there a backport of mountall for karmic available?
<spy6> or any other solution to get karmic running in a domU with olter kernel?
<spy6> older even
<xnox> bug #469985
<ubottu> Launchpad bug 469985 in mountall "mountall loops on pipe2() while mounting /sys/kernel/debug when running on Xen" [High,Fix released] https://launchpad.net/bugs/469985
<Laibsch> lool: ping, are you there?
<spy6> xnox: the fix is just for lucid, not for karmic
<james_w> cjwatson: I do not I am afraid
<xnox> spy6: i just wanted to see what the bug was =) cause I issues with mountall and thought that that was the bug I'm having
<spy6> xnox: ah ...k
 * xnox is not developer yet =)
<alkisg> Could anyone help in an edubuntu-devel problem? Trying to create a fat client chroot: (1) chroot /opt/ltsp/i386 (2) debootstrap && apt-get install edubuntu-desktop (3) exit the chroot (4) umount /opt/ltsp/i386/proc ==> PROBLEM: in use.
<alkisg> I tried lsof and fuser and ls /proc/*/exe to see the process that uses $chroot/proc, nothing. Then I logged off, stopped gdm, stopped any service I could think of, and tried umount again. STILL in use.
<alkisg> How can that be happening?
<alkisg> BTW, the same method with ubuntu-desktop, instead of edubuntu-desktop, doesn't give this problem.
<slangasek> smoser: I think at one point Keybnz had a mistaken belief that kernel commandline options would be passed to init directly, but later discovered they aren't; if he's implemented any handling of /proc/cmdline, I haven't heard of it
<smoser> slangasek, never mind the above. it appears that i just didn't know how args are passed to init. apparently 'init=' is given, kernel invokes init with args from there out.
<smoser> if '--debug' is on the kernel command line, it *does* get through to whatever program is 'init'
<slangasek> oh, ok
<smoser> any options specified like 'a=b' (having an '=' in them) are not passed. and if there is an init= arg on the cmdline, then any tokens before that will not be passed.
<smoser> this is experimentation data only.
<slangasek> oh, ok
<slangasek> zul: er, why did you take the samba change from karmic-proposed for bug #462169?
<ubottu> Launchpad bug 462169 in samba "nmbd dies on startup when network interfaces are not up yet" [High,Fix released] https://launchpad.net/bugs/462169
<zul> slangasek: yeah
<slangasek> zul: I asked *why* :)
<zul> slangasek: better than nothing im working on the upstart conversion as we speak
<slangasek> no, not better than nothing
<slangasek> see my last comment on the bug
<zul> slangasek: k ill revert it
<slangasek> can you reproduce the original problem?
<zul> no i had once on a alpha testing
<slangasek> ok
<zul> and i think smoser did as well
<slangasek> if it's no longer reproducible, the upstartification is much simpler; I already have the upstart jobs here, I just need to tune the start condition for nmbd
<zul> oh? can i see them?
<slangasek> sure, sec
<smoser> i did see dead nmbd in alpha2 testing, and logged it in the iso tracker
<zul> slangasek: im just curious to see if im on the right track for my own education
<slangasek> zul: http://paste.ubuntu.com/359214/, http://paste.ubuntu.com/359215/
<slangasek> smoser: ok, how do I reproduce that?
<slangasek> smoser: I have been entirely unable to trigger an nmbd failure in current lucid, no matter how I mangle my configs and network interfaces
<smoser> wow. i just did out of the box. in a kvm.
<smoser> hold on
<slangasek> zul: oh, that version of the smbd job is broken; it needs to be 'exec smbd -F' and no 'expect daemon', somehow whatever smbd does on start to daemonize confuses upstart and it loses track of the process
<smoser> i just walked through http://testcases.qa.ubuntu.com/Install/ServerWhole#Samba%20server and the suggested 'pgrep' showed no nmbd
<slangasek> smoser: if you're going to reproduce it, please set 'log level = 3' in /etc/samba/smb.conf first
<zul> slangasek: yeah I had that in my testing as well
 * zul goes get ready for a hockey game
<smoser> slangasek, so if you did a clean install of alpha2 and nmbd does not die for you?
<slangasek> smoser: I haven't done a clean install of alpha2; don't have the spare hardware, but at best it's racy anyway
<slangasek> what I don't understand is why I still can't get nmbd to fail when I hard-kill lo
<smoser> slangasek, well, i dont have spare hardware either, but i do have kvm :) and thats where i see it fail, so might aid in the racy-ness
<slangasek> yeah, I don't have any spare hardware that'll run KVM
<slangasek> :-P
<smoser> slangasek, i'll offer a trade.  i will reproduce 462169 for you if you will look at bug 509841
<ubottu> Launchpad bug 509841 in upstart "system fails to boot without ramdisk" [Undecided,New] https://launchpad.net/bugs/509841
<smoser> I've attached differences in '--debug' console output .  At very least, please read the attached http://launchpadlibrarian.net/38103669/only.combined.txt and see if anything jumps out at you.
<Laibsch> ping lool
<seb128> cjwatson, pitti, Riddell, james_w, slangasek: did any of you started doing syncs yesterday?
<james_w> seb128: I did it last Sunday night
<seb128> there is quite some item not flushed in the sync dir
<slangasek> seb128: it may have been james_w; the rest of us were already discussing on #ubuntu-release and none of us confessed :)
<seb128> I'm trying to figure who did that
<slangasek> I thought Riddell said he was flushing them
<slangasek> like, an hour ago
<seb128> he didn't apparently
<slangasek> Riddell: ^^ ?
<seb128> I'm waiting on that to try a soyuz bug ;-)
<seb128> bah gtk-sharp guys
<james_w> yes, that could well have been me. I may have lost network while doing the flush, sorry for not using screen
<seb128> james_w, no problem, can it be flushed now? ;-)
<james_w> I don't see why not
<seb128> ok thanks
<seb128> doing that now
<james_w> what does soyuz do for interrupted flushes?
<seb128> I just didn't want to get in conflict with other people work
<james_w> is it going to reject a bunch of them?
<james_w> I'm not doing anything currently, so you won't conflict with me
<seb128> I don't know but it's not going to accept things twice
<slangasek> james_w: yes, a stopped and restarted flush will give rejects
<seb128> directhex, the debian gtk-sharp changes suck
<seb128> james_w, can you flush the queue then? ;-) I don't want to be responsive for other people rejected item in the queue :-p
<james_w> heh
<seb128> directhex, do you have some sort of transition plan to make sure to fix things the .pc binary broke before lucid?
<seb128> binary *move* broke
<ccheney> doko: the thumb arm patch doesn't apply for 3.2.0 should it be just a small modification to fix it, or should i upload it without that patch so you can look at what it needs for 3.2?
<ccheney> doko: looks pretty simple for me to just update the patch if that is likely to be enough to make it work
<RAOF> seb128: I'm not directhex, but that's mostly fixed in Sid already.  I think the transition plan was âpull the fixed stuff from testing after it migratesâ.
<seb128> I got 2 ftbfs today already
<seb128> that starts annoying me
<seb128> we can't let the archive broken until we might sync from testing things which migrated
<ccheney> doko: actually solenv/inc/unxlngr.mk looks significantly different from the 3.1.1 version
<ccheney> doko: should i just change CDEFAULTOPT=-Os to CDEFAULTOPT=-O2 ?
<RAOF> It might be time to upload from pkg-cli-apps/pkg-cli-libs VCS again to speed things up.
<sebner> RAOF: hola, do you know if docky is supposed to be stable?
<RAOF> sebner: Which one?  The one in current gnome-do releases, or the new split out one in lp:docky?
<slangasek> seb128: "sync from testing" is a default policy only, anything that it's appropriate to sync from unstable can be synced in the usual way
<sebner> RAOF: latter
<seb128> slangasek, right, it's just annoying that we got things broken and no transition plan or somebody looking at it
<seb128> slangasek, they moved the .pc to a new binary which means all build-depends are broken
<slangasek> heh, ok
<seb128> I ran into 2 broken case today
<seb128> dunno how many of those are still around
<RAOF> sebner: It's not sufficiently feature-complete for a release, but it's moderately workable?
<slangasek> smoser: looking at 509841
<sebner> RAOF: kk, I'm using it since some days and it generally works well but it lags heavily from time to time (Xserver goes to 100%) so I'm wondering if that's the fault of docky, xserver, compiz or nvidia driver
<slangasek> smoser: in the ramdisk case, what starts your network interfaces?  (I see no mention of them in the log)
<slangasek> smoser: I'd also like a tarball of /etc/init from this system
<smoser> yeah, thats wierd. there is *no* changes
<RAOF> sebner: That's a strange interaction with the nvidia driver; start docky with the --nvidia to activate a work-around.
<smoser> between the ramdisk and non-ramdisk systems. oh, i suppose its possible that *nothing* starts the interface in the ramdisk case.
<smoser> i can provide tarball of /etc/init, but you can download it at a waste of meer 200+M (download the UEC image).
<slangasek> smoser: ok - which image is it?
<sebner> RAOF: cool! thanks for the hint :)
<smoser> http://uec-images.ubuntu.com/lucid/20100118/
<smoser> i used amd64, but thats not relevant as far as i can tell.
<Laney> seb128: There is not "no transition plan", we are trying to get enough done in Debian so that we can sync it
<slangasek> smoser: ack, downloading
<seb128> Laney, doesn't seem a good way to deal with a transition :-(
<directhex> seb128, if you don't mind syncing from sid, then things are mostly done
<smoser> that tarball contains everything to reproduce.  the ramdisk inside it is what i used, command line to kvm is in the bug....
<seb128> directhex, what about ubuntu?
<seb128> directhex, I ran into launchpad integration and indicator being broken today
<seb128> directhex, did somebody try to figure what needs to be changed, what will come from debian, what is ubuntu specific?
<sebner> RAOF: just wondering that this "bug" only appear after using docky for some hours
<RAOF> sebner: Or after resume-from-suspend, apparently.  It's got something to do with long-lived graphics buffers.
<directhex> seb128, i wasn't aware there *were* ubuntu-specific things, they seem to be missing from the multidistrotools page we've been lookign at
<sebner> RAOF: ah, understood :) /me never uses resume anyways :)
<seb128> directhex, I'm pondering making the old binary depends on the new one
<sebner> RAOF: btw, any roadmap for it?
<smoser> slangasek, i just attached all of /etc. figuring it might be useful for /etc/fstab or /etc/network/interfaces.
<RAOF> sebner: For docky?  Not really; we've been trying to push DBO to work out the release-blocking bugs, but he's busy elsewhere and doesn't want it released before some nebulous stuff has happened.
<seb128> directhex, grep-dctrl says there is 28 sources to update
<seb128> that's for libgtk2.0-cil only though
<sebner> RAOF: heh. Are there already some major differences betweend g-d docky and split out docky?
<RAOF> sebner: Yes; they're quite different now.
<sebner> RAOF: so I'm fine with the new one?
<RAOF> sebner: Yes
<RAOF> seb128: Have you seen the pkg-mono transition tracking page? http://wiki.debian.org/Teams/DebianMonoGroup/Mono-devTransition
<sebner> RAOF: great! thanks for you time :)
<seb128> no I didn't
<directhex> seb128, i count about gtk# 60 rdeps, with about half done in sid, so that sounds about right
<seb128> I will look to that in a minute, need to restart
<seb128> brb
<Laney> that page isn't so helpful in tracking apps sadly
<seb128> re
<seb128> directhex, RAOF: ok thanks
<seb128> seems to not be so many before lucid
<seb128> would have nice to have an email on the lists about the transition though
<seb128> to not surprised maintainers who get build failure after trivial changes
<directhex> the hope was to get it all finished before it begame an issue
<directhex> too many Closes:
<seb128> well you overlooked ubuntu specific sources there
<seb128> those will need get automagically changed
<seb128> need -> not
<Laney> I guess the MDT page builds its index from sid
<Laney> would be better if it took the union
<directhex> i should upload some NMUs
<seb128> let me know if you need some syncs
<slangasek> smoser: in the initramfs case, what's mounted on /tmp after the boot finishes?
<directhex> sebner, bareftp seems okay to me, do you remember what the last blocker was?
<chrisccoulson> jdstrand - when you did the recent transmission security update, you pushed your bzr branch without bzr add'ing the actual patch
<chrisccoulson> i got a bit confused there ;)
<sebner> directhex: FTBFS because gnome-keyring-sharp was not found by configure. I added a patch for it. If it builds it's ready for uploading. But really, ask meebey. Not my cup of tea anymore
<jdstrand> chrisccoulson: oops
<chrisccoulson> heh, no worries
<jdstrand> I'll commit it
<slangasek> smoser: ?
<chrisccoulson> jdstrand - no worries about committing it
<chrisccoulson> i've just pushed the update for beta 5 to bzr now, and the patch is merged upstream
<jdstrand> chrisccoulson: ok-- sorry about that
<sebner> directhex: The patch name in the changelog is false though (shame on me)
<directhex> sebner, never mind. uploaded
<cjwatson> jdstrand: can we safely copy horde3 from jaunty-security from jaunty-updates?  The changelog history diverges, but from a quick glance it looks as though the divergence is not interesting, as the diverging entries are just fakesync comments?
<cjwatson> from jaunty-security TO jaunty-updates
<jdstrand> cjwatson: yeah, I meant to do that earlier but forgot
<sebner> directhex: heh, also though I don't care anymore take my thanks
<cjwatson> jdstrand: I'll let you go ahead, then :)
<jdstrand> k :)
<jdstrand> done
<nixternal> congrats cjwatson, persia, soren, geser, stgraber, and cody-somerville \o/
 * sebner copy&paste nixternal : congrats cjwatson, persia, soren, geser, stgraber, and cody-somerville \o/
<nixternal> hehe :)
<stgraber> thanks
<cjwatson> cheers, looking forward to serving with you
<nixternal> dang, was hoping you said "serving you", cuz I could really use a cold beer right about now :)
<stgraber> nixternal: is your fridge that far away ? ;)
<nixternal> it is seriously 3 feet in front of me, but 6 inches of that is a wall :)
<sebner> nixternal: so it seems I'm not the only one thinking about cjwatson being butler? :P
<nixternal> ouch :)
<soren> nixternal: Thanks and same to you.
<directhex> ?
<soren> http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_ea7519273c82ed12
<cody-somerville> moo
<geser> sebner: thanks
<wolter> Hi, can anybody advice me on how to get my notify-osd volume control back?
<wolter> Everything else works fine
<slangasek> wolter: "back"?
<wolter> slangasek, i removed pulseaudio once and with it, the notify-osd volume control stopped working
<wolter> instead, the traditional gnome one took the job
<slangasek> why did you remove pulseaudio?
<smoser> slangasek, i can try mountall --debug. in fact, i had tried that, but did not get any of mountall's output to console.
<smoser> almost as if it wasn't taking.  I'll try again though. Where would you expect mountall output to go ?
<wolter> slangasek, because I was (am) having problems with my microphone
<wolter> but now I have pulseaudio back installed
<slangasek> smoser: ok - what about the contents of /proc/mounts in the case of a successful boot?
<smoser> you want to see them , i can put them there.
<slangasek> smoser: yes, please
<slangasek> smoser: mountall output> try adding 'console output' to the upstart job as well (as a separate line, not as part of the script)
<slangasek> wolter: so when you say "notify-osd volume control", you're talking about the on-screen display that shows when the volume has been changed with a hotkey?
<smoser> slangasek, the job has 'console output' : http://paste.ubuntu.com/359300/
<slangasek> smoser: heh, ok
#ubuntu-devel 2010-01-20
<smoser> i'll try again, but i swear before i added '--debug' and it just didn't do anything.
<smoser> hm.. for the record, i added '--verbose', not '--debug' . '--help' output mentions --verbose, not --debug.
<wolter> slangasek, yes
<slangasek> smoser: I honestly don't remember; I've always captured to a logfile in /dev for easier post-boot analysis, but that doesn't work here if you can't get to a shell :)
<smoser> --debug has no effect to the console.
<slangasek> smoser: bah.  Maybe try > /dev/console 2>&1 ?
<smoser> at least "grep -v 'init:'" rips out just about everything. nothing really looks like mountall output
<smoser> well, it *should* get to the console.  other tasks do, i know that. but i guess other tasks don't run so early.
<slangasek> wolter: well, AFAIK that should entirely be handled by gnome-settings-daemon, with no pulseaudio involvement
<slangasek> wolter: what's the hardware?  It's not a thinkpad, is it?
<wolter> no
<wolter> its a dell xps m1530 with sigmatel sound card
<slangasek> wolter: ok, no idea then, sorry
<wolter> but it used to work, so that should not matter
<wolter> ok, attempt appreciated anyway, thanks
<slangasek> wolter: it matters because on the thinkpad, it "worked" wrong in earlier versions
<smoser> scratch that. retrying. hodl on
<slangasek> but that definitely doesn't apply to Dells
<wolter> ok
<smoser> slangasek, http://paste.ubuntu.com/359307/
<smoser> that is '--debug' output to mountall, and it does get to the console. user error previously.
<smoser> it seems to think it can't mount /
<smoser> ok. so i found the issue. or at least a fix/workaround.
<slangasek> oh?
<smoser> slangasek, /etc/fstab has '/dev/sda1' as root, but /dev/sda is actually root.
<smoser> kernel cmdline has the correct value, and / does obviously get mounted
<smoser> but mountall sits around waiting for a / that is never going to be
<slangasek> ah
<smoser> i think it doesn't make sense to wait for the device of /
<slangasek> IIRC it waits for it in order to fsck it?
<smoser> although that doesn't explain why it works with the initramdisk
<slangasek> yeah, I don't know
<smoser> that does make sense, to fsck, but better to listen to what is already mounted than to /etc/fstab, which can only ever be wrong.
<smoser> at least if, between fstab and the kernel, if one is wrong, its not fstab
<slangasek> smoser: right, well, please post this analysis to the bug and we'll consult Keybnz when he's available :)
<smoser> k
<smoser> slangasek, you agree that this is probably 'mountall' and not 'upstart' ?
<cjwatson> didrocks,superm1: please use lp:~ubuntu-core-dev/user-setup/ubuntu rather than lp:ubuntu/user-setup
<slangasek> smoser: yes, it's clearly a mountall issue
<cjwatson> didrocks,superm1: those may become identical in future, but for now lp:~ubuntu-core-dev/user-setup/ubuntu is the correct branch
<cjwatson> didrocks: sorry, you can ignore the above - it's just superm1 getting it wrong :)
<smoser> slangasek, thanks for your help.  what do you want me to do for your smb bug?
<slangasek> smoser: set log level = 3, reproduce it, and send me /var/log/samba/log.nmbd :)
<cjwatson> superm1: I've fixed up the history, though I'd rather not have to do so again as the process is a bit tedious and manual
<slangasek> smoser: oh, bear in mind that you need samba 2:3.4.3-2ubuntu1 or earlier to reproduce this; 2:3.4.3-2ubuntu2 includes the /etc/network/if-up.d script that will mask the problem
<smoser> well i saw i with alpha2. i'll just use that unless it is otherwise not acceptable.
<slangasek> yah, that's good
<smoser> is that ok?
<smoser> k
<micahg> Riddell: thanks for pushing that zf backport, but I wonder if we should push 1.9.7 instead
<Riddell> micahg: that's a question for the backports team, I only do what they approve
<micahg> heh, ok, ScottK ^^^
<Riddell> speaking of which, ScottK, jdong: how come nobody has complained about these not being processed for up to 6 months?
<ScottK> Riddell: I've been busy ...
<superm1> cjwatson, i'm sorry.  i'm so confused with different projects using lp:ubuntu/blah and others lp:~ubuntu-core-dev/blah/blah+
<StevenK> superm1: Some of them should be equal
<superm1> StevenK, see that's just the problem : *some of them*
<superm1> and i'm not sure which ones those are
<StevenK> superm1: It's a transistional period, what can you do?
<superm1> complain :)
<StevenK> superm1: I'd suggest asking james_w about the above
<StevenK> superm1: Can I upload mythtv? :-)
<superm1> StevenK, our branches are just as much a mess :)
<StevenK> superm1: No-change rebuild for jack ...
<superm1> StevenK, actually we've got changes queued up, i'll upload them tonight
<StevenK> superm1: Right, well, I've just kicked libjack0.100.0-0 out of the archive, so I may have broken myth, but NBS wasn't picking it up and complaining
<superm1> StevenK, okay.  i'll see what happens.  if it fails to build i'll just disable jack for now.  i dont know a single user that uses jack tbh.
<StevenK> superm1: I removed the shared library, the -dev package was removed days ago, and your Build-Depends are already fine
<slangasek> ArneGoetje: can you roll some new langpack -base packages for hardy (8.04.4)?  i386 alternate has grown, and I think re-compacting language-pack-es-base should be enough to fix this
<slangasek> ArneGoetje: (though just in case it isn't, I would certainly suggest doing all the ones that are on the CD...)
<cjwatson> superm1: honouring the Vcs-Bzr field in debian/control when it's set to something useful and Ubuntuish will get you out of trouble most of the time.
<cjwatson> superm1: (BTW I've already asked james_w to move the lp:ubuntu/... links over for this case, a while back)
<ArneGoetje> slangasek: yes, I'm working on it.
<slangasek> ArneGoetje: ok, thanks :)
<slangasek> ArneGoetje: when do you think that will be done?  (so I can schedule CD testing accordingly)
<ArneGoetje> slangasek: I will start a build now and see if it runs through. Since the langpack-o-matic code has moved to another server, there are still some dependency problems when generating the mozilla translations of the langpacks, So, need to test if it's fixed now. But I hope to have at least the packages, which go on the CD ready within 10 hours
<slangasek> ok
<Keybnz> cjwatson: hey, dunno if you know, but the 19 install failed
<cjwatson> Keybnz: nope, any clues as to what went wrong?
<Keybnz> http://zelda.netsplit.com/~daily/daily-installer/20100119-max/debug
<Keybnz> (the rookery rsync apparently doesn't work anymore)
<slangasek> Keybnz: hi, quick question while you're about - the plymouth in initramfs is a temporary workaround until the gdm/plymouth starting race can be fixed, right?
<Keybnz> slangasek: got it in one
<slangasek> ok
<slangasek> do you have an idea yet of how to fix that race? would you like me to work on it?
<Keybnz> gdm starts before plymouth ends the world ;)
<slangasek> yep
<Keybnz> start plymouthd very early, separate job to show splash
<Keybnz> so if X is up, it's a no-op
<Keybnz> might need some work to make sure you don't get console messages, etc.
<slangasek> ok
<Keybnz> (since gdm deactivates plymouth when it starts and re-shows it later)
<slangasek> I'm keen to see it resolved because I'd like to avoid having to put pango in everyone's initramfs in the interim ;)
<Keybnz> yeah it's top of my things to do at the sprint
<slangasek> alrighty
<Keybnz> slangasek: feel free to give it a shot
<slangasek> Keybnz: ok, cheers
<cjwatson> Keybnz: rookery> people.canonical.com changed host, it's now "lillypilly" (silly name ...)
<cjwatson> Keybnz: could you make the syslog there world-readable?  I get 403 Forbidden
<cjwatson> Keybnz: it might be what superm1 just fixed though
<cjwatson>   * Fix automatic login on situations where custom.conf didn't exist
<cjwatson>     already on the target.
<cjwatson> yeah, looks about right
<cjwatson> I'll make sure we do a ubiquity upload tomorrow
<StevenK> cjwatson: d-i and the surrounds are free of the -9 kernel, so I can kick it out of the archive?
<StevenK> I've checked, just want to make sure.
<cjwatson> StevenK: yes
<ScottK> StevenK: Even on powerpc?
<ScottK> Last I looked, d-i wasn't building there.
<smoser> slangasek, log files for recreate attached. if you want anything else let me know. i'll keep the vm around for a bit.
<cjwatson> ScottK: if memory serves, it didn't build with -9 either
<ScottK> Ah, may be.
<StevenK> It's because the kernel is too big
<StevenK> I think
<cjwatson> I've not been bored enough to investigate
<ScottK> StevenK: I think that's right.  I looked at it enough to conclude I'm really confused by d-i and will leave it alone.
<Keybnz> cjwatson: yeah the problem is that IS haven't copied over the special permission for the rsync
<Keybnz> will fix the perms
<Keybnz> unfortunately daily installs/bootcharts are down until someone manually reboots the boxes :(
<Keybnz> ok, I want bzr reflog now
<slangasek> smoser: thanks - that's with a stock smb.conf?
<dholbach> good morning
<ajmitch> morning dholbach
<dholbach> hey ajmitch
<doko_> ccheney: yes, please still use -O2 for the arm build
<pitti> Good morning
<slangasek> morning
<abogani> Hi All, I found on our wiki instructions for add new package into Ubuntu. Where can I find instructions for request to removing package from Ubuntu? In my case the simualvr package is buggy, never used and no more developed simulator for AVR. It presence in our archive can let our users think that is a good software and let they disappointed when discover that it is a very bad software. What is the right thing to do?
<pitti> ttx: FYI, the missing trend line start update was a problem in my cronjob; fixed last night, so they should be good now
<jussi01> abogani: you need to file a bug - instructions are on this page: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive
<abogani> jussi01: Yeah the missing URL! Thanks Jussy!
 * jussi01 hugs abogani and reminds him that his name is spelt Jussi :D
<ttx> pitti: yes, it's perfect now, thanks
<doko_> pitti: when should we start planning which library versions to demote for lucid (boost, db4.x, readline5, ..., ???)
<abogani> jussi01: It isn't the first time, also... Apologize for this I'll try to write your name well. :-(
<pitti> doko_: hm, to me it seems this is the kind of work for between beta-1 and beta-2; WDYT?
<doko_> pitti: hmm, maybe a bit late? should we try to propose versions which we do want to keep/target for lucid now/next week?
<pitti> we can make a list of duplicates, sure
<pitti> it just seems less intrusive than the typical alpha-2/3 targets, and we're still syncing from debian right now
<smb> Anybody with a spare current Lucid machine, who could help me to verify something?
<doko_> ok, I'll start a wiki page later this week
<seb128> smb, spare like ready to break?
<smb> seb128, Sort of yes, but recoverably (thought maybe in a scary way)
<seb128> ok, I will pass on this one, sorry but I've a busy schedule for today
<seb128> I can do quick testing but I need my box ;-)
<smb> In general, after adding the following to /etc/fstab: "LABEL=NotHere /mnt ext3 defaults,user,relatime 0 0", then on reboot my installation hung. But with sysrq-i (kill all tasks) I get dropped down to a maintenance shell where I can remove the bad entry from the fstab and the system boots again.
<smb> This entry did not cause problems until some recent update. It seems mountall gets into trouble now.
<slangasek> smb: by design
<slangasek> smb: based on negative feedback in karmic, Keybnz has made mountall block waiting for all local filesystems listed in /etc/fstab before declaring the filesystem "mounted"
<smb> Though this is a drastic change in behavior.
<smb> Those entries were in my case related to USB sticks which I wanted to get mounted with different options, when I plug them in.
<slangasek> then you should probably have them marked 'noauto' in /etc/fstab, I think
<slangasek> or perhaps 'nobootwait'
<slangasek> asynchronous booting is a drastic change in behavior /in general/; we have to pick /some/ policy for handling cases like this, and there's no policy that will make everyone happy
<smb> slangasek, Likely and maybe we should add a note to the release notes (if not already there). As updates can suffer from that surprise
<slangasek> (I thought the policy in karmic was reasonable, but apparently plenty of users did not, and were vocal about it)
<slangasek> smb: certainly - could you file a bug on the ubuntu-release-notes project about this?
<smb> slangasek, Yes, will do
<pitti> smb, apw: FYI, I just binary-NEWed the lucid kernel
<smb> pitti, Thanks, I'll relay to apw when he gets in
<apw> pitti, thanks
<dholbach> pitti: heya.... czajkowski said there were a bunch of action items missing on the burndown charts... do you know what happened?
<dholbach> czajkowski: which spec was it?
<pitti> dholbach: I need more details, I'm afraid; what's missing?
<czajkowski> It's not the specs so much it's the work items missing from assigness and also the -women blueprint I think is missing
<czajkowski> http://macaroni.ubuntu.com/~pitti/workitems/canonical-community.html
<czajkowski> going by this page
<czajkowski> and I know there is a blueprint on -women
<dholbach> czajkowski: do you have an example of a spec that generally shows up but your work items are missing?
<czajkowski> dholbach: Loco council is one example then
<dholbach> czajkowski: do you have the link to the spec?
<pitti> czajkowski: is the missing blueprint assigned to someone not in ~canonical-community?
<czajkowski> blueprint is up but I'm not down under asignees neither is pope
<dholbach> pitti: ah, it doesn't show community members?
<czajkowski> dholbach: https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-loco-council-plans
<dholbach> czajkowski: on that spec there's just one action item for you and that turns up at least on all-ubuntu-10.04.html
<czajkowski> dholbach: :(
<czajkowski> wait that's right
<pitti> dholbach: it shows community WI assignees, but not specs which aren't assigned to a member of the reports' team
<apw> TheMuso, hey ... abuot?
<geser> could an archive admin try syncing "libxcb" again? I need a fresh OOPS for bigjools to look why it fails
<pitti> can do
<pitti> geser: sync-source worked; I'll try to flush it
<seb128> geser, sorry I meant to do that yesterday but somebody started on syncs and didn't flush the queue and I didn't want to mess with things before that was sorted
<seb128> pitti, it's flush which oops
<pitti> 2010-01-20 10:02:05 ERROR   Exception while processing upload /home/lp_queue/sync-queue/incoming/pitti-20100120-100158 (OOPS-1481FTPMASTER1)
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1481FTPMASTER1
<geser> pitti: thanks
<smb> slangasek, I really would love to file a bug, but launchpad is not in the right mood for that
<ArneGoetje> slangasek: upload the hardy langpacks directly to the archive, or go via PPA and -proposed?
<ArneGoetje> slangasek: or split the upload? langpacks on the cd to archive, the rest via PPA and -proposed?
<slangasek> ArneGoetje: I don't see any reason not to go directly to the archive?
<seb128> geser, I've synced libxcb, the issue is due to the new line in the binary list in the .changes
<seb128> I workarounded the .changes for the sync
<seb128> pitti, ^
<pitti> ah, good
<geser> seb128: that explains why e.g. mono didn't autosync too, it has also a newline in the Binary: field
<geser> directhex, Laney : ^^ that's the reason why mono doesn't autosync
<seb128> geser, right, I already workaround mono in the past due to such issue
<smoser> slangasek, stock smb.conf (other than adding 'log level = 3' to global section.
<seb128> geser, https://bugs.launchpad.net/soyuz/+bug/435316
<Laney> is there a soyuz bug for this?
<ubottu> Ubuntu bug 435316 in soyuz "new lines in the changes file Binary: field triggers a parsing error" [Medium,Fix released]
<Laney> well anticipated
<Laney> :)
<seb128> ;-)
<seb128> do you need mono to be synced?
<seb128> I can do that now...
<Laney> I think that requires more discussion
<Laney> do you need any help with your ftbfs?
<Laney> I feel bad that we didn't consider ubuntu-local packages
<seb128> Laney, no that's ok, the build-depends list has 28 items I guess those will be fixed over time
<seb128> I will do a check around beta time to make sure we transitionned those
<seb128> not a priority for now
<Laney> the ones in Debian we will take care of, but ones that aren't might not get picked up by us
<seb128> ok, no worry
<seb128> let's wait for you to deal with the debian one
<tseliot> slangasek: do you think I should do an "LDCONFIG_NOTRIGGER=y ldconfig" (in a postinst script) or export and unset that variable? I'm having problems with buildds.
<seb128> then I will run another query to check what is remaining
<cjwatson> james_w: could you please have a look at the dpkg failure?  I'm pretty certain that the problem is that get_native_part is failing to handle the case of a .tar.bz2 native package
<tseliot> or cjwatson ^^
<cjwatson> tseliot: err.  surely we should fix ldconfig if it's breaking?
<cjwatson> tseliot: or are you saying you've found a case where calling ldconfig earlier matters?
<tseliot> cjwatson: yes, exactly: http://launchpadlibrarian.net/38095009/buildlog_ubuntu-lucid-i386.octave-ad_1.0.6-3_FAILEDTOBUILD.txt.gz
<cjwatson> tseliot: can you explain why it matters in this case but not others?
<tseliot> otherwise octave won't find libGL.so.1 from mesa
<cjwatson> is it because you're changing /etc/ld.so.conf.d/ and need to update ld.so.cache?
<tseliot> cjwatson: I guess octave doesn't use libGL.so in /usr/lib/ but relies on ldconfig at build time
<cjwatson> that explanation doesn't convince me at all, but the one I just suggested might ;-)
<tseliot> cjwatson: yes, that too, of course
<cjwatson> tseliot: I think LDCONFIG_NOTRIGGER=y is OK, then, but please leave a comment that it's due to the /etc/ld.so.conf.d/ change
<cjwatson> I see there's a comment "explicit ldconfig due to alternatives" there already, so just make that clearer
<tseliot> cjwatson: do you mean "LDCONFIG_NOTRIGGER=y ldconfig" ?
<cjwatson> yes
<tseliot> ok
<tseliot> and yes of course I'll add a comment so that my change makes sense to others
<geser> cjwatson: the problem on the buildds is that e.g. the postinst of octave3.2 runs one of its binaries (which is linked against libGL.so.1) but as the ldconfig got delayed ld doesn't find the library yet
<issimedia> Hi guys! :) Anyone here has experience with unixODBC development? These guys don't have a channel...
<dpm> mdeslaur, we've noticed that there is a translation template for hamster-applet on the Karmic translations import queue on LP -> https://translations.edge.launchpad.net/ubuntu/karmic/+source/hamster-applet/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot . Normally only translations for packages in main end up in the queue, but hamster-applet is in universe. Any idea how that could have happened?
<dpm> (note that this is not a problem for the translations team, we'll just block the template, I'm just curious to how this could happen)
<issimedia> I have a really strange problem with different behaviours between v2 and v3 instruction sets
<cjwatson> geser: right, the question I wanted to get resolved is that normally ldconfig is just building a cache and it doesn't matter whether it's run early or not.  I've already worked out with tseliot why it matters here.
 * tseliot nods
<tseliot> cjwatson: hopefully this explanation will be enough: http://pastebin.ubuntu.com/359506/
<cjwatson> tseliot: probably overkill :), but yes
<tseliot> heh
<cjwatson> I'd just have said that ldconfig needs to be run immediately when changing ld.so.conf.d
<tseliot> cjwatson: ok, I'll be less verbose then
<tseliot> +  # ldconfig needs to be run immediately as we're changing /etc/ld.so.conf.d/ with
<tseliot> +  # alternatives.
<tseliot> this should better
<cjwatson> yeah
<cjwatson> thanks
<tseliot> thanks for your help
<ArneGoetje> slangasek: ok, uploading...
<ockham> hi, can someone help me with this error http://pastebin.com/d275a5d95
<ockham> i'm experiencing when trying to build iulib-0.4 using pbuilder?
<mdeslaur> dpm: no, I have no idea how that happened. That's odd.
<dpm> mdeslaur, thanks for coming back to me. No worries, I'll ask at #launchpad
<ockham> sry for nagging, but as i can't see any communication going on here (only logon/offs): is there anybody at all?
<cjwatson> ockham: the huge pile of joins and quits was due to problems between some of the IRC servers on the network.
<ockham> okay, glad there's someone. soo... can anyone help me out with this:http://pastebin.com/d275a5d95
<mathiaz> mvo: squid-deb-proxy package: nice!
<mvo> mathiaz: yeah :) if your squid kung fu is good, double check the config
<ogra> is that a replacement for approx7apt-proxy and the like ?
<ogra> *approx/apt-proxy
<mvo> not really a replacement, more a alternative implementation based on squid
<mathiaz> mvo: would it make sense to provide a squid-core package - so that you don't pull in a complete squid configuration?
<mvo> but yeah, that is the goal
<mvo> mathiaz: yes
<ScottK> doko_: re your earlier comment about library demotions: For boost, we should be ready to have 1.38 out of the archive shortly and 1.39 is already gone.  There should be nothing to decide about demotions for boost.
<doko_> ScottK: the question would be 1.40 or 1.41
<ScottK> doko_: Certainly.  I think we should align to whatever Debian is using for default in Squeeze.  I wrote the boost maintainers and asked their plans, but did not hear back.
 * ScottK is hoping they don't plan another transition
<qense> james_w: I lost track of what bug 422536 should be. There are loads and loads of people randomly changing the status and assignee. You assigned yourself to the bug report, do you know what to it should be?
<ubottu> Launchpad bug 422536 in kerneloops "EDAC amd64: WARNING: ECC is NOT currently enabled by the BIOS. Module will NOT be loaded." [High,Confirmed] https://launchpad.net/bugs/422536
<qense> I think there were almost ten different people with 0 or 5 karma that messed with the report
<lamont> powerpc buildds going offline for a while
<jjardon> Hello, anjuta can't be installed in lucid due a package conflict with devhelp, should I fille a bug about this?
<fagan> jjardon: has it been wrong for a while?
<fagan> Or was it an update?
<fagan> you may have installed it before the dependencies were updated
<jjardon> fagan, the problem is that anjuta 2.28 depends on devhelp 0.23, but devhelp 2.28 is the version available in lucid. The proper solution would be update the anjuta packages
<jjardon> or change the actual anjuta 2.28 packages to depend on devhelp 2.28
<fagan> jjardon: looking at lucid changes anjuta hasnt been upgraded this month so id file a bug
<cjwatson> probably just needs a simple rebuild.
<cjwatson> libdevhelp changed its abi
<fagan> ah
<jjardon> indeed, devhelp 2.28 should be packaged for karmic, as It's an official GNOME 2.28 application; don't know if this is possible now
<barry> ScottK: just a quick ping that i pushed a new rev to the distribute merge proposal.  no rush of course
<ScottK> barry: I haven't had any time to look at it.
<ScottK> It's on my list though ....
<barry> ScottK: no worries.  i just wanted to make sure you weren't waiting for more information from me.  thanks!
<ScottK> Nope.
<barry> cool
<jjardon> cjwatson, should I file a bug about this?
<slangasek> ogasawara: when you have a chance, could you point the weather report at hardy for 8.04.4?
<ogasawara> slangasek: sure
<milanbv> slangasek: ping
<smoser> slangasek, would you consider upstart or mountall dependency on CONFIG_DEVTMPFS a bug (bug 510130) ? or is that simply a requirement for lucid kernels.
<ubottu> Launchpad bug 510130 in linux-ec2 "ec2 instance fails to boot if registered without ramdisk" [High,New] https://launchpad.net/bugs/510130
<cjwatson> jjardon: it's not my field, but filing a bug for an uninstallable package is certainly reasonable, if there isn't already one filed.
<jjardon> cjwatson, ok, done: https://bugs.launchpad.net/ubuntu/+source/anjuta/+bug/508444
<ubottu> Ubuntu bug 508444 in anjuta "Sync anjuta 2:2.28.1.0-1 (universe) from Debian testing (main)" [Undecided,In progress]
<cjwatson> jdstrand: is it a good idea to attempt to backport changes for bug 379329 to Karmic?  We elected not to do so in Debian, and the version in Karmic already has the bits that I considered safe to backport (see the changelog for 1:5.1p1-5)
<ubottu> Launchpad bug 379329 in openssh "CVE-2008-5161: OpenSSH CBC plaintext recovery" [Low,Confirmed] https://launchpad.net/bugs/379329
<cjwatson> jdstrand: intrepid could probably do with an update for that backport
<jdstrand> cjwatson: well, the deal with that is that it has a CVE assigned to it, but it kept showing up on the server teams lists and they would talk about it each week, so I had to do something witht he bug to get it off their list
<jdstrand> cjwatson: what I told them is that it is on our list, but we don't have plans to update it any time soon
<jdstrand> cjwatson: my feeling is to not update it, but I haven't looked at it closely enough (and neither has anyone from the security team) to say for sure "yes" or "no" on whether to backport it or not
<cjwatson> jdstrand: fair enough.  well, you have my take on it now ...
<jdstrand> cjwatson: so, is karmic not affected any more?
<jdstrand> cjwatson: I realize exploiting this is very difficult to exploit (which is why we haven't been jumping all over it)
<jdstrand> that was not the best sentence...
<cjwatson> jdstrand: it's mitigated
<jdstrand> cjwatson: via the Ciphers?
<milanbv> kirkland: around?
 * jdstrand is reading the changelog now
<cjwatson> jdstrand: no, I wasn't convinced about changing that in 5.1 (I forget exactly why)
<jdstrand> cjwatson: if you say it is mitigated in karmic, I'll make a note in our CVE database and in the bug
<jdstrand> cjwatson: I was unaware of the mitigation
<cjwatson> jdstrand: the packet_disconnect on padding error change reduces the probability of attack to 2^-18, and note that this attack is destructive - if you try it on somebody and it fails, it breaks the connection anyway
 * jdstrand nods
<jdstrand> cool, thanks
<cjwatson> jdstrand: so you'd have to have somebody have their ssh connection broken O(2^18) times and not complain much about it
<jdstrand> heh
<cjwatson> at least, such is my understanding
<jdstrand> ah, so jaunty also has the mitigation, good
<jdstrand> 1:5.1p1-5 has packet_disconnect(), and jaunty has 1:5.1p1-5ubuntu1
<jdstrand> cjwatson: I'm not superkeen on updating intrepid-- it was quite hard to exploit to begin with, aiui
<cjwatson> I don't recall what the original probability was
<jdstrand> cjwatson: though I'm noting it in the CVE/bug
<jdstrand> cjwatson: http://www.openssh.com/txt/cbc.adv says 2^-14
<jdstrand> but "though we suspect this
<jdstrand> underestimates the work required by a practical attack."
<didrocks> jjardon: I've update anjuta to last release. Just wait for the buildd to build it. It launches correctly now locally.
<jjardon> didrocks, great! thank you very much
<didrocks> jjardon: y/w ;)
<jdstrand> cjwatson: I say for now we plan on fixing it in Intrepid with the next security update
<jdstrand> cjwatson: well, by 'fixing' I mean backporting that patch
<jdstrand> (of course)
<jdstrand> cjwatson: does that seem reasonable to you?
<jdstrand> well, the 2^-14 was for the 14 bits of plaintext
<cjwatson> jdstrand: sounds reasonable, yes
<zul> piti: ping is there a way to ask a question in apport hook if the gtk/kde interface is not installed
<jjardon> didrocks, I'm seeing https://launchpad.net/ubuntu/lucid/+source/anjuta and current anjuta doesnt depend on libgnome, libgnomeui, libgnomecanvas, libglade, libgnomeprint or libgnomevfs
<didrocks> jjardon: I've just adjusted deps from diff in configure.in between previous version we got and that one. Can you opened a bug and assign it to me so that I'll look at the configure.in carefully (I mean, not diff, but from scratch again) in case someone miss it in a previous upload
<jjardon> didrocks, ok, will do
<didrocks> jjardon: thx :)
<pitti> zul: hi (spelling "pitti" with two t helps :) )
<jjardon> we are working hard to remove deprecated libraries for 2.30: Gnome packages don't depend on libgnome, libgnomeui, libglade, libgnomecanvas (only evolution), libgnomevfs, libgnomeprint
<pitti> zul: the hooks are completely agnostic about the UI
<pitti> zul: if you run ubuntu-bug without $DISPLAY or without -{gtk,kde} installed, it will use the CLI based frontend
<pitti> zul: and show questions/read answers from the console
<pitti> zul: do "DISPLAY= ubuntu-bug storage" to see how it works
<zul> pitti: sorry about that great thanks for answering my question
<pitti> zul: np, I just missed your question for a while
<zul> pitti: thats ok i cant spell
<didrocks> jjardon: I know, I don't saw it when making my diff in configure.in. I guess that was done before but didn't noticed by the uploader. That's why reviewing all deps from scratch won't hurt anyone :)
<jjardon> didrocks, no worry, I'll check the configure.ac and report any issue. Thank you again for the update :)
<ogasawara> slangasek: I created a separate 8.04.4 weather report - http://qa.ubuntu.com/reports/ogasawara/weatherreport-8.04.4.html
<didrocks> jjardon: you're welcome, just open the bug as a reminder for me (I won't have the time to do it tonight)
<jjardon> Do somebody if there is a problem whith http://people.canonical.com/~scott/daily-bootcharts/ ? ( It's not updated since 13 Jan)
<ScottK> jjardon: Known issue.  Being worked on.
<jjardon> ScottK, ok :) BTW, maybe helps to Desktop boot up removing some deprecated libraries: libgnomecanvas or libgnome, for example
 * ScottK doesn't have any of those libraries on boot.
<cody-somerville> Have libraries installed that don't get used at boot aren't going to slow down boot.
<pitti> jjardon: Keybnz is on the other side of the planet right now, so I guess it won't be fixed this week
<lamont> who is the current debian-installer victim^wguru?
<jjardon> cody-somerville, the problem is that there are a lot of packafes that already don't depend on libgnome, but the package is still not update in Ubuntu: try apt-get remove libgnome2-0
<superm1> pitti, wasn't the problem just caused by user-setup not working properly though?  new media spins with the new ubiquity/user-setup should be it?
<cody-somerville> jjardon, Thats not going to affect boot speed unless those programs are run as a part of the boot sequence.
<jjardon> gnome-panel and gdm, for example?
<cjwatson> lamont: #ubuntu-installer
<lamont> ta
<kirkland> milanbv: am now
<cjwatson> jjardon: run-time dependencies are calculated automatically.  Anything that depends on libgnome2-0 almost certainly actually links against it.  (The situation for build-dependencies is different.)
<pitti> superm1: ah, I haven't booted the current desktop dailies; just tried UNE today
<milanbv> kirkland: hi!
<ccheney> doko_: ok will update the arm patch and upload 3.2.0~rc3 today
<milanbv> I was wondering about the issues that appear when changing password for a user with ecryptfs
<jjardon> cjwatson, we have to wait to packages get updated to latest versions, then. For example; libgnomeui was removed from gnome-panel in 2.29.5
<milanbv> because from users-admin an admin is allowed to change the password without providing the old one to PAM, which breaks everything
<jjardon> If someone interested of the actual status, take a look here: http://www.gnome.org/~fpeters/299.html
<cjwatson> jjardon: yes, the desktop team does this routinely
<cjwatson> fear not, we have people well on top of GNOME
<kirkland> milanbv: hmm, right
<kirkland> milanbv: that's been around for a while
<milanbv> yeah
<kirkland> milanbv: perhaps we should warn the admin if they're doing so
<kirkland> milanbv: that they may be breaking the user's encrypted home setup
<milanbv> I'm currently working so that you change your own password, you have to provdie the old one
<milanbv> sure
<cjwatson> jjardon: see e.g. http://people.canonical.com/~seb128/versions.html
<jjardon> cjwatson, :) yeah, I suppossed that you already know
<kirkland> milanbv: wait, huh?
<cjwatson> we appear to have gnome-panel 2.29.5 already, for instance
<kirkland> milanbv: changing your own password works fine
<milanbv> but do you think there could be a kind of dialog that could run on the user's session if ecryptfs detects that the password no longer corresponds to the one you need?
<cjwatson> 2.29.5.1, rather
<milanbv> kirkland: it works fine when using the hack which runs gnome-about-me ATM - I'd like to make this cleaner
<kirkland> milanbv: yes, that's the recommended way to change your password
<kirkland> milanbv: or by using 'passwd'
<milanbv> agreed
<milanbv> what about that kind of dialog?
<kirkland> milanbv: it's sort of out of my hands
<kirkland> milanbv: you'd need to convince one of our desktop or foundations guys to fix that
<kirkland> milanbv: i hate it too, fwiw
<milanbv> hmm
<milanbv> kirkland: another question: do you think it's possible to do something for people who may have changed their password by force, and who use encrypted *home*?
<milanbv> i.e. when you can't mount the home dir
<kirkland> milanbv: sure, it's easy to fix from the command line
<kirkland> milanbv: they just need to run ecryptfs-rewrap-passphrase
<milanbv> :-)
<kirkland> milanbv: supplying their old, and new passphrase
<milanbv> I mean: automatically form GDM
<kirkland> milanbv: and then everything works again
<seb128> jjardon, we follow GNOME closely on updates and we have no extra lib use easy to clean
<kirkland> milanbv: again, i have nothing to do with anything above a command line
<milanbv> OK
<seb128> jjardon, all the libgnome* libbonobo* need to stay there this cycle
<kirkland> milanbv: your best bet to to talk to someone like pitti or seb128
<milanbv> and are there plans to put the passphrase in the gnome-keyring for Private dirs?
<kirkland> milanbv: there have been many requests to improve the graphical integration of ecryptfs
<milanbv> that would help changing passwords
<kirkland> milanbv: unfortunately, i'm not tasked to do that
<milanbv> sad - I'll see that we the desktop team
<kirkland> milanbv: gnome-keyring == graphics, again, i can't really work on that
<milanbv> anyway, I'm planning to add an option to encrypt home dirs when creating an user in users-admin
<superm1> pitti, well even today's current desktop dailies don't have it.  either needs a respin to pickup ubiquity 2.1.12 or wait till tomorrow
<jjardon> seb128, only tomboy depends on libgnome, there is no 2.30 gnome package that depends on libgnome (only bindings)
<kirkland> milanbv: that would be great
<milanbv> quite easy actually now that I've changed our protocol
<seb128> jjardon, we stay on evo 2.28 for lucid
<milanbv> (much easier than that password mess ;-) )
<seb128> jjardon, 2.30 has way too many changes for a lts
<kirkland> milanbv:  Lucid Alpha 2 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 http://wiki.ubuntu.com/HelpingWithBugs
<kirkland> milanbv: whoa, sorry
<kirkland> milanbv: https://blueprints.edge.launchpad.net/~kirkland
<jjardon> seb128, aps, didn't know that
<kirkland> milanbv: let me try that copy-n-paste one more time
<kirkland> milanbv: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-ecryptfs-desktop-ui
<milanbv> nice!
<seb128> jjardon, you are welcome to hang on #ubuntu-desktop for desktop question btw
<milanbv> I can see your agenda is full :-)
<kirkland> milanbv: that's a blueprint that collects ideas about what needs to be fixed in the GUI for ecryptfs
<seb128> jjardon, or if you are interested in desktop work being done there
<kirkland> milanbv: i recommend that you read that, and edit the whiteboard, adding the integration features you think are still missing
<milanbv> is mrooney working on this?
<kirkland> milanbv: not actively, that i know of
<kirkland> milanbv: he's been around it, from time to time, though
<kirkland> milanbv: you might poke him, see if he's working on it actively, and offer to help, if you like
<jcastro> mdeslaur: If I'm an upstream and I want to communicate with Ubuntu on security-type things you send me to which wiki page?
<kirkland> milanbv: you should also poke pitti
<milanbv> not sure I'll be able to help in that regard
<kirkland> milanbv: i think pitti was in favor of this work; he just didn't have any people to dedicate to this
<milanbv> I'd just like to know what way I should choose
<kirkland> milanbv: my hands are currently full doing ubuntu cloud work, and i have not much time for ecryptfs, and certainly not the desktop aspects of it
<kirkland> milanbv: i need to run now, thanks for the feedback, patches would be welcome ;-)
<milanbv> sure, I can understand that
<milanbv> I'm quite busy too, actually :-)
<milanbv> the encrypt home option is all I can do
<tjaalton> there's a problem in the new sssd package where some deps have been trimmed from the libs, causing undefined symbols in some components
<mdeslaur> jcastro: https://wiki.ubuntu.com/SecurityTeam/Contacts
<tjaalton> but is it done on purpose by the default behaviour or what
<jcastro> thanks!
<mdeslaur> np
<tjaalton> so I get this http://pastebin.ubuntu.com/359674/
<tjaalton> instead of this http://sssd.pastebin.com/d4f2806e3
<cjwatson> kirkland: bug 414986 - what crept back in, exactly?  open-iscsi-utils still seems to be a separate package with the expected contents
<ubottu> Launchpad bug 414986 in open-iscsi "open-iscsi causes FTBFS for anything that Build-Depends on it" [High,In progress] https://launchpad.net/bugs/414986
<cjwatson> kirkland: and failures from ln are still ignored
<tkamppeter> pitti, hi
<tkamppeter> pitti, can you close http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550575? It is fixed by my new cpdftocps filter which I have introduced in 1.4.2-1 on Nov 17, 2009.
<ubottu> Debian bug 550575 in cups-bsd "cups-bsd: lpr ignores non-duplex setting in printer configuration and command line options" [Important,Open]
<doko_> ccheney: did you verify that it did build?
<ccheney> doko_: yea just did the build with the modified patch
<ccheney> doko_: it worked on amd64 at least
<ccheney> doko_: after looking at what changed closer it looks like the patch i made was the correct change in any case
<doko_> ccheney: yes, but not on arm
<ccheney> doko_: it seems they factored out part of the makefile into a generic makefile and i checked both for the Os vs O2 part
<ccheney> doko_: it might not work even with the change that is true, rene completely disabled arm support for Debian but he didn't have this patch so not sure if this was the only issue he had
<doko_> ccheney: I did check that it will fail. please wait with the upload
 * ccheney isn't even really supposed to be messing with OOo, still have a huge backlog of work to do on firefox :-\
<ccheney> doko_: the O2 still fails?
<doko_> thumb fails
<ccheney> doko_: ok
 * ccheney will commit the new patch to ooo-build and wait to upload then
<ccheney> ok pushed the change to master
<slangasek> ogasawara: thanks; is it possible to point the weather report at hardy-proposed, in addition to hardy-updates?
<slangasek> smoser: CONFIG_DEVTMPFS> dunno, would have to defer to Keybuk
<slangasek> milanbv: pong
<ogasawara> slangasek: yup, was going to ask that as I noticed the iso diff's were a little off
<milanbv> slangasek: yeah, it was about PAM and changing passwords
<milanbv> basically, and user is not allowed to change passwords for other users, even when providing their old password
<milanbv> which means admins are forced to break encrypted home dirs if they want to change password for their users
<smoser> can someone able please send my message onto -devel mailing list
<smoser> https://lists.ubuntu.com/mailman/confirm/ubuntu-devel/fa61297872ac220b04d71ba0899e336257f2c3ae
<milanbv> so I'm not sure what we can do about it - maybe nothing...
<smoser> and if they can at the same time whitelist me, that'd be nice
<smoser> i promise not to send any messages about acai
<smoser> whoops. i realize that link was just for me. never mind all.
<geser> was there some general hickup on the buildds recently? as I see some build logs where dpkg failed at unpacking the downloaded deb, e.g. http://launchpadlibrarian.net/38062888/buildlog_ubuntu-lucid-i386.mono-addins_0.4-6_FAILEDTOBUILD.txt.gz
<slangasek> milanbv: well, that's not a PAM issue; it's an application-level decision not to allow changing passwords for other users
<milanbv> sure, that's why I'm wondering about users-admin
<ccheney> doko_: so you tested on arm with rc2 plus updated thumb patch?
<ccheney> doko_: because with rc2 the thumb patch wasn't applied by default
<slangasek> milanbv: and the encrypted home dirs shouldn't end up broken, it should only mean the user has to type two passwords...
<milanbv> would there be a way to force PAM to accept the old password, even when root calls pam_chauthtok()?
<slangasek> milanbv: doesn't users-admin just call the 'passwd' command?
<doko_> ccheney: yes, which is a mistake
<milanbv> ATM no
<milanbv> in a few days, yes
<slangasek> how does users-admin interface with PAM?
<milanbv> but that doesn't solve the case of *other* users
<milanbv> in Karmic, passwords are changed using chpasswd via the backends
<slangasek> ah
<milanbv> and for current user, via gnome-about-me
<ccheney> doko_: so its failing in a different manner in the same area when using O2 then I guess?
<milanbv> slangasek: what I would be interested in is a way for the privileged backends to give PAM the old password when we have it
<doko_> ccheney: I'm currently test building, the build didn"t finish yet
<slangasek> milanbv: pam_ecryptfs should always prompt for it when it doesn't have it; that's a per-module decision
<milanbv> that way, admins would be able to change passwords for other users, e.g. asking them their old password (home context)
<milanbv> you mean that pam_chauthtok() will always ask for it?
<ccheney> doko_: ok no problem
<slangasek> milanbv: pam_chauthtok doesn't ask for anything, the individual modules do all the prompting
<ccheney> doko_: i committed my updates to ooo-build and ubuntu bzr
<slangasek> so pam_ecryptfs has the opportunity to insist on getting a copy of the old password
<milanbv> hmm, so that would be a good solution - always provide PAM with the password, except if admins don't want to provide it
<slangasek> oh, are you not passing the prompts through to the user?
<slangasek> PAM isn't designed for non-interactive use; if you have a UI, you ought to be passing the prompts through
<milanbv> yeah, but there's D-Bus in between ;-)
<milanbv> pretty complex
 * slangasek shrugs. :)
<milanbv> that's really messy
<milanbv> but AFAIK you can make PAM work non-interactively
<milanbv> I've code for that
<slangasek> you can use PAM non-interactively and pretend it works :P
<milanbv> why wouldn't it work?
<milanbv> as long as I have everything it may need?
<slangasek> PAM is not designed for non-interactive use, and if you use it that way you're going to have to apply a heuristic to the text prompt from the PAM module to figure out if it's asking for an old or new password
<milanbv> have a look at the madness at http://git.gnome.org/browse/gnome-control-center/tree/capplets/about-me/gnome-about-me-password.c
<milanbv> just to make passwd work from a GUI :-p
<slangasek> (and you'll have to make sure PAM is called with LC_MESSAGES=C, because modules can localize their user prompts...)
<milanbv> that's not better
<milanbv> localize? they only pass me PAM_ECHO_ON/OFF()
<slangasek> er
<slangasek> no, there's a text string accompanying that
<slangasek> :)
<milanbv> maybe that's why it doesn't work
<milanbv> the examples I found are maybe too simple
<milanbv> so what do you think?
<milanbv> I need to change passwords on the privileged side because I'm not allowed to do so as a normal user
<milanbv> so I need D-Bus, thus no interactive conversation...
<slangasek> I think if you want this to work reliably instead of repeatedly hunting corner cases, you want to make sure you can pass the text of the PAM prompts through to the user
<milanbv> but that wouldn't be ideal either
<milanbv> what do you want to do in a GUI with PAM prompts?
<slangasek> have the user answer them?
<milanbv> we don't want strange questions with custom entries...
<milanbv> we need a defined set of entries all visible at once
<slangasek> PAM isn't guaranteed to give you that
<milanbv> and then send to PAM what we have - we can't provide more than old and new password, anyway
<milanbv> hey, we're only supporting standard schemes, obviously
<milanbv> people can't expect a password management dialog will handle their strange setup
<slangasek> as I said, if you prompt for the old and new passwords up front, you have to use a heuristic on the text string to figure out which one to give in response to which prompt
<slangasek> why shouldn't they expect that?
<chrisccoulson> milanbv - have you had a look at what the gnome-screensaver lock dialog does with the text from PAM?
<chrisccoulson> it has some bits in for handling various prompts
<milanbv> could be interesting
<milanbv> is that different from gnome-about-me?
<chrisccoulson> milanbv - i'm not familiar with how gnome-about-me works
<chrisccoulson> but i vaguely know how gnome-screensaver works
<chrisccoulson> also, the GDM greeter will probably contain similar logic too
<chrisccoulson> although i haven't checked that
 * milanbv is looking at that file
<milanbv> doesn't seem really nicer than toying with passwd directly
<slangasek> milanbv: ecryptfs is precisely one of these "strange setups" - I can't even guarantee you which password PAM will prompt for *first* (old vs. new) in that case
<milanbv> PAM is eveil
<milanbv> evil
<milanbv> if that's such a mess, I guess I'm going to keep the changes to the minimum
<milanbv> i.e. only use passwd for current user
<milanbv> and use chpasswd on the backends for others
<milanbv> but that's not perfect
<milanbv> > msg != NULL && g_str_has_prefix (msg, _("Password:")
<chrisccoulson> milanbv - i don't know what the answer is, i'm afraid ;)
<milanbv> what a joke we need such tricks :-)
<milanbv> so even in your dreams there isn't an optimal solution?
<milanbv> the fallback we have is that gnome-keyring should be able to ask for old and new password when it detects that it cannot decrypt the login keyring anymore...
<slangasek> milanbv: the optimal solution *is to pass PAM's questions through to the user*...
<milanbv> but that's mad from a UI design POV
<milanbv> no UI does that!
<milanbv> imagine a series of entries created on the fly, with obscure questions we can't even predict
<slangasek> "no UI" - like GDM, or gnome-screensaver?
<milanbv> they don't change passwords...
<slangasek> GDM will
<milanbv> only one entry
<slangasek> (or should)
<milanbv> it will?
<milanbv> have people thought about this already?
<slangasek> "only one entry" - nope, GDM has to be able to handle two-factor auth
<milanbv> when does that happen?
<slangasek> what do you mean?
<milanbv> what's the second factor? :-)
<slangasek> whatever the admin has configured?
<milanbv> like the name of his dog? :-p
<mathiaz> slangasek: hi - if a pakcage shows up on the " Source and binary demotions to universe " in component-mismatches.txt, is there anything else that needs to be done to demote it to universe?
<slangasek> mathiaz: nope, it'll get processed by an archive admin at some point
<mathiaz> slangasek: great - thanks.
<slangasek> milanbv: you can see GDM's (thorough) PAM support in daemon/gdm-session-worker.c
<milanbv> thanks - I'm currently reading the GUI part
<milanbv> I'd like to see how all this is handled over D-BUs
<milanbv> anyway, that's not something that will happen in users-admin, because the whole model of the gnome-system-tools is based on one bug D-Bus method called "set"
<slangasek> for d-bus, I guess the server needs to generate a unique ID to attach to the message
<milanbv> everything else is not supported, and is a pain to implement :-)
<slangasek> hmm
<milanbv> that would be a nice task for the new accounts-dialog that mclasen started
<milanbv> hmm, I see how this works now
<milanbv> directly transmitting questions to the GUI
<chrisccoulson> milanbv - i was just going to ask you if you had seen mclasen's work
<milanbv> that's not perfect since we can't e.g. tell the user the confirmation is not correct in real time - need to wait for PAM to fail
<milanbv> chrisccoulson: yeah
<milanbv> actually I've already got in touch with him
<milanbv> I think users-admin is virtually dead
<milanbv> I'm quite happy with the improvements I could bring in, but the general model is not very flexible for what we need
<milanbv> (PAM is an example)
<chrisccoulson> the new tool looks quite nice. it would be good to put some effort in there i think, and make sure it doesn't have all the issues we have currently
<milanbv> yeah, for Lucid+1 I guess I'll switch to it
<milanbv> but many common issues with users-admin are now fixed
<milanbv> it's just that error reporting is still zero :-p
<milanbv> anyway it was nice to see the problems we currently have with liboobs/users-admin
<milanbv> that will help designing a tool that suits our needs
<barry> anybody here with deep python-gobject and/or gdb-fu that might want to look into bug 503727 with me?
<ubottu> Launchpad bug 503727 in computer-janitor "computer-janitor-gtk crashed with KeyError in create_column()" [High,Triaged] https://launchpad.net/bugs/503727
<mathiaz> slangasek: hi - is there a reason by xubuntu.lucid/ has a server-ship seed?
<cjwatson> mathiaz: because it was branched from ubuntu long long ago
<mathiaz> cjwatson: ok - I'm looking at demoting elinks
<mathiaz> cjwatson: and the xubuntu.lucid server-ship still has elinks in them
<mathiaz> cjwatson: should I delete elinks from there as well?
<cjwatson> mathiaz: probably
<mathiaz> cjwatson: should I completely remove the server-ship seed for xubuntu.lucid?
<cjwatson> if you like
#ubuntu-devel 2010-01-21
<xnox> Hello anyone familiar with Edubuntu seed inclusion process?
<xnox> I want to get 3 packages into it =)
<ockham> hi, is anybody experiencing this: http://pastebin.com/d275a5d95 when trying to package something user pbuilder?
<cjwatson> ockham: looks like you've broken /bin/sh in your chroot.  Make it a symlink to dash
<cjwatson> (or maybe dash doesn't handle downgrades properly, I don't know for sure)
<cjwatson> "unable to execute installed post-installation script: No such file or directory" means in this case that it can't find the #! interpreter, which is /bin/sh here
<cjwatson> for /var/lib/dpkg/info/dash.postinst
<ockham> cjwatson: thanks for the hints. this should actually be a pretty clean lucid pbuilder chroot, so i'm a bit afraid of having to tweak it manually
<ockham> is there any way to cleanly re-create the chroot?
<crimsun> it looks like dash's prerm is kinda "oops".
<xnox> where was the announcment of the Developer Memberhip Board voting results send?
<micahg> xnox: u-d-a and it was posted on teh fridge
<xnox> micahg: aha thanks =) stragily I'm not subscribed to u-d-a....
<xnox> Anyhow when is the next meeting?
<xnox> the helpful 15UTC every two weeks is quite vague.... =)
<micahg> feb 2
<xnox> Ok thanks
<micahg> xnox: if you're ever wondering when the meetings are, check the fridge calendat
<micahg> *calendar
<xnox> Ok I will in the feature. Thank you
<maxb> james_w: What's happened to all the debian branches for source package subversion? They are apparently deleted from launchpad?!
<xnox> In the new merges page
<xnox> there is bugs column with bugs assigned
<xnox> how do i edit it? or link bugs there?
<ScottK> The script looks up merge/sync bugs on Launchpad automatically.
<xnox> Kk cool =)
<xnox> so it will pick mine up next time it scans ;-)
<dholbach> good morning
<xnox> dholbach: 0/
<dholbach> hi xnox
<xnox> =) hope your having nice morning ;-)
<dholbach> yeah... it will be even better when I've had my first cup of coffee :-)
<dholbach> thanks xnox :)
 * xnox is a bit too far to make dholbach coffee
<dholbach> no worries :)
<xnox> dholbach: thank you for ACKed on my syncs ;-) \0/
<dholbach> :-)
<MFen> are there any subtle changes in cdbs between jaunty and karmic?
<MFen> a python-distutils.mk package i was able to build while running jaunty, will not build in karmic
<MFen> it doesn't even attempt to run setup.py
<MFen> my rules file: http://paste.pocoo.org/show/167874/
<MFen> it builds a package, which contains nothing except the entries in debian/dirs plus copyright, changelog.
<pitti> Good morning
<tseliot> pitti: any ideas as to what causes this error? dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Error parsing subject struct
<pitti> tseliot: yes, in fact I do
<pitti> tseliot: weird, I fixed that in early lucid already
<tseliot> what is it?
<tseliot> I'm still getting it here
<pitti> a missing parameter in the self.polkit.CheckAuthorization() call
<pitti> the karmic version didn't supply start-time
<pitti> but it's required with lucid's policykit
<tseliot> oh, so I guess I'll have to fix screen-resolution-extra
<pitti> tseliot: http://bazaar.launchpad.net/%7Ejockey-hackers/jockey/trunk/revision/583
<pitti> tseliot: ah; right
<pitti> I thought it was from jockey
<pitti> tseliot: above patch should pretty much work for s-r-e, too
<tseliot> pitti: ok, thanks a lot
<MFen> figured it out. it didn't like that my package was named -dev
<geser> has someone any idea what happen there? http://launchpadlibrarian.net/38059356/buildlog_ubuntu-lucid-sparc.ncmpc_0.16-1_FAILEDTOBUILD.txt.gz
<geser> I've seen this in several FTBFS build logs from 18 Jan and 19 Jan
<mvo> ev: hi, did anything change in recent ubiquity (between alpha-2 and now) that could explain why mat_t sees bug #510033 and I don't see it?
<ubottu> Launchpad bug 510033 in ubiquity "It's not possible to install mp3 codecs on a fresh install" [Medium,In progress] https://launchpad.net/bugs/510033
<mvo> ev: it looks like for him no apt-get update was run in-target during the install, but for me that worked fine (with a daily)
 * ev digs
<mvo> ev: there was a similar issue in karmic when on a fresh install universe package lists were not available, this is why even wrote a small patch :/
<mat_t> mvo: I can test it with daily if that helps
<mvo> mat_t: that would be nice. I will still add code to gnome-codec-install for the case when the system is installed without network and later gets connectivity
<mat_t> mvo: yes, definitely
<mat_t> mvo: thanks a lot for looking at it!
<seb128> mvo, could be that he was not online during install?
<mat_t> seb128: yes, I wasn't
<ev> that would do it then
<mvo> mat_t: oh? you wrote "Note: the same error occurs regardless of whether internet connection is established or not"
<mat_t> mvo: yes, but I did not account for the installation process
<mvo> aha, ok
<mvo> ev: sorry for the noise then
<mat_t> I only referred to what happened post-installation
<ev> no worries
<mvo> that explains it
<mat_t> :)
<mat_t> mvo: so will your patch cater for this scenario?
<mvo> yes
<mat_t> mvo: brilliant
<ttx> seb128: should bug 508297 rather be considered a gtk+2.0 regression ? Should I open a gtk task ?
<ubottu> Launchpad bug 508297 in xchat "[lucid] channels do not change color anymore" [High,Confirmed] https://launchpad.net/bugs/508297
 * xnox has sent application to become Ubuntu Contributing Developer
<seb128> ttx, reassign to gtk rather than opening a new task
<ttx> seb128: done
<mvo> ev: what is the issue with Ensure that Jockey's apt-cache is up-to-date after install ? (just curious)
<ev> If you're referring to the switch of blueprints, it only becomes an issue when we have a jockey page in ubiquity.  The issue itself is that the jockey backend caches apt-cache lookups, so if you run apt-get update (via "update this installer", for example) while the backend is running, and you get to the jockey page, it wont be using the updated apt cache.
<ev> it's not a major deal, as the backend goes away after 10 minutes
<ev> mvo: ^
<mvo> ev: aha, thanks. I was just curious if its some limitation in python-apt or apt
<ev> nope :)
<lamont> I wonder... if I drop a karmic libc6 on a hardy system (well, chroot), do things blow up?
<directhex> very likely
<slangasek> ttx, kirkland: do you recall what the issue was in hardy that caused all instances of scsi-modules-$version-di in the archive to be pulled into the server CD, and is that resolved in post-hardy versions?
<slangasek> (it's prompting me to do some needful NBS pruning of kernel binaries in hardy-{proposed,updates,security} which we don't have an automatic way of taking care of - but it would be good if we didn't have to worry about this before lucid point releases)
<ttx> slangasek: that doesn't ring any bell
<slangasek> ok
<lamont> directhex: that was kind of my thinking
<lamont> I may just do intrepid/jaunty vms as interim steps in my search for the bug
<directhex> lamont, i had enough explosions with sid libc on non-sid debian to not trust it
<ttx> slangasek: we should now be able to get rid of cglib2.1, btw
<slangasek> lamont: I'm not aware of any specific reasons it would explode
<lamont> directhex: ah - very good data point, ta
<slangasek> ttx: woohoo! :)
<ttx> slangasek: eucalyptus now build/runs from libcglib-java
<ttx> (2.2)
<lamont> slangasek: coolness.
<slangasek> lamont: I may just be exposing my own ignorance, though :)
<ttx> slangasek: there are a few universe packages that still depend on libcglib2.1-java but libcglib-java provides it.
<ttx> slangasek: let me know if there is anything more I should do on that subject
<lamont> slangasek: you're the one who encourages boy scouts to throw gasoline on the fire, aren't you?
<directhex> on debian it's usually locales that go to poop when you update libc... but ubuntu's locales are handled differently
<ttx> not sure how automatic those removals are
<slangasek> ttx: semi-automatic
<ttx> Question about main: when a source package gets promoted into main, do all the resulting binaries also end up in main ? Or do they each need to be pulled by something ? i.e. can a main source package have main and universe binaries ?
<slangasek> yes, a main source package can have both main and universe binaries
<ttx> slangasek: ok, cool.
<lamont> and if you find a universe source with main packages, then you have found a bug.  or warty.
<ttx> lamont: heh
<ScottK> That can still happen if a binary starts being provided by a different source.
<lamont> 'twas one of those lolwut? moments
<ScottK> It happened for a bit recently with the switch to distribute from python-setuptools source.
<slangasek> ScottK: that should show up on components-mismatches, though?  Or was this "old package forgot to say that it no longer owned it"?
<barry> mvo: ping
<tseliot> cjwatson: currently we don't pass the vga= parameter to vga16fb, right? Any ideas as to how bug #509328 can be fixed without this parameter?
<ubottu> Launchpad bug 509328 in nvidia-graphics-drivers "Lucid Alpha2: Plymouth does not work with the current nvidia driver" [Medium,Confirmed] https://launchpad.net/bugs/509328
<cjwatson> tseliot: that's correct, because using vesafb breaks suspend/resume
<cjwatson> tseliot: I believe the plan of record is to fall back to vga16fb, not vesafb
<tseliot> cjwatson: right but currently vga16fb doesn't seem to allow plymouth to work. Is there some parameter we can pass vga16fb?
 * tseliot wasn't suggesting that we use vesafb
<slangasek> pass it to do what?
<cjwatson> tseliot: that I don't know, Keybuk probably would
<tseliot> cjwatson: ok, I'll send him an emai. Thanks
<cjwatson> I assume that plymouth explicitly rejects it or something at the moment, since vga16fb should present a framebuffer much like anything else
<cjwatson> or that we aren't arranging for vga16fb to be loaded if nothing better is available
<tseliot> ok
<slangasek> from bug #506717 and an examination of the initramfs scripts, I believe vga16fb should be getting loaded correctly in the initramfs
<ubottu> Launchpad bug 506717 in plymouth "[Lucid] plymouth does not display when using nvidia drivers" [High,New] https://launchpad.net/bugs/506717
<slangasek> i.e., the affected users have it loaded /after/ boot, and the only thing that loads it is the alias, so it should load just as well from the initramfs
<tseliot> right
<xnox> Check out http://bzr.debian.org/bzr/users/xnox-guest/merges/
<xnox> =)
<xnox> It's a webpage =)
<xnox> Revamped new merges page
<xnox> a little bit =)
<xnox> http://bzr.debian.org/bzr/users/xnox-guest/merges/index.html
<smoser> kees, you have a minute? i've a questoin about ssh known hosts format
<kees> smoser: hello!  I'm here now, going through IRC backlogs.  :)
<smoser> kees, i bothered jdstrand , he answered. i was somewhat worried that in my known hosts file the 3rd field always started with same 28 chars or so
<smoser> it appears to be key header, which always base64 encodes the same, so not an issue (at least i dont think so)
<Laibsch> lool: ping.  Do you have a minute?
<kees> smoser: ah-ha, yes. that's correct (key header)
<smoser> i was afraid i was getting little or no randomness in key generation
<lool> Laibsch: Depends how long the minute  ;)
<ccheney> doko: did the build work?
<doko> ccheney: the build takes about 40h ...
<ccheney> doko: oh so won't be done until tomorrow i suppose?
<ccheney> doko: was the problem in the past it failed to build or the resulting binaries just failed to work? if failed to build it sounds like it still going is a good sign :)
<Laibsch> lool: ping.  I sent you one more question.  If you another minute...
<MacSlow> bryce_, pitti, seb128: today's updates removed xserver-xorg-video-intel on an intel-GPU based system... any idea why?
<hunger> Is there a way to speed up key processing of plymoth in lucid? Entering the passphrase for my disks is really annoying now.
<mathiaz> slangasek: hi - re bug 507778
<ubottu> Launchpad bug 507778 in acpid "Please merge acpid (1:2.0.0-1) from Debian testing" [Undecided,New] https://launchpad.net/bugs/507778
<mathiaz> slangasek: does it make sense to pull 2.0.0 in lucid LTS?
<slangasek> mathiaz: I haven't looked at what's different in 2.0.0
<slangasek> mathiaz: though I do know there are some changes in the Debian package that will need to be gone over carefully in a merge
<mathiaz> slangasek: the debian changelog entry says: New Upstream version from new source tree that already incorporates the
<mathiaz> slangasek: netlink patch..
<mathiaz> slangasek: I'm not sure how stable is this *new* tree with regards to LTS
<mathiaz> slangasek: AFAICT there isn't any major packaging change - kacpimon is a new binary package that has been added
<slangasek> yes, I don't know either
<mathiaz> kees: jdstrand: mdeslaur: what's your opinion on bug 510732?
<ubottu> Launchpad bug 510732 in openssh "OpenSSH server sshd_config PermitRootLogin -> NO" [Wishlist,Incomplete] https://launchpad.net/bugs/510732
<kees> mathiaz: we defer to cjwatson.  I would support the change, though.
<mathiaz> kees: could you add a comment to the bug?
<kees> cjwatson: so, what do you think about this ^^ ?  It's been a long-standing request, and I kind of like it.
<kees> mathiaz: what do you think of it?
<jdstrand> mathiaz: I'm with kees. I too like it, but realize it cuts down on usability
<kees> mathiaz: the logic has been that rootlogin isn't possible by default because there is no root password.
<mathiaz> kees: yes - that was my first answer
<jdstrand> people argue that if they enable the root account, they want to use it
<mathiaz> jdstrand: and it's true that the choice to be made is between usability and multiple layer of security
<kees> right
<jdstrand> that said, it is something I typically change on machines I administer (and if I can get away with it, AllowUsers)
 * kees â¥ AllowUsers
<jdstrand> (not suggesting we try to do anything with AllowUsers)
<jdstrand> *totally*
<kees> so, here's a thought...
<kees> we have an implicit possible with gdm to disallow the root user to log in, even if they have a password set.
<kees> perhaps we should duplicate this with SSH?
<mathiaz> kees: an implicit possible with gdm to disallow the root user?
<jdstrand> interesting thought, though there is a similar discussion with sudo and gksudo
<mathiaz> kees: what do you mean by that?
<kees> mathiaz: oh, er, total typo.  s/possible/policy/
<ScottK> Aren't there system risks with running Gnome/KDE as root?
<jdstrand> it is interesting in this case that the gui app is more restrictive
<kees> ScottK: yes, very much
 * ScottK wouldn't see blocking root login as primarily a security issue
<ScottK> It's a this won't work issue
<kees> ScottK: right, that's why gdm blocks root.
<mathiaz> kees: right. there seem to be a policy mismatch here
 * slangasek runs GNOME as gdm
<jdstrand> it is a known account which makes it particularly easy to brute force (and everyone wants it)
<mathiaz> kees: that being said, openssh is not installed by default on desktops
<kees> but I'm saying that it might make sense to carry that logic to SSH
<ScottK> So it's tangential to the security issue
<kees> slangasek: so did I briefly :)
<mathiaz> kees: what the reason for disabling root login in gdm?
<jdstrand> ScottK: I don't think it is tangential
<mathiaz> kees: it seems that the target users are different here
<ScottK> There's no system reliabilty reason to avoid ssh as root.
<jdstrand> ScottK: if you have an enabled root account *and* allow root passwords (also the default), then it makes it possible to brute force
<mathiaz> kees: gdm policy is to disallow end users to shoot themselves in the foot
<kees> mathiaz: AIUI, lots of system files can get trashed.  gnome/kde don't support it, etc.
<ScottK> jdstrand: Certainly, but that's not why gdm doesn't allow root loging
<ScottK> login
<mathiaz> kees: are users installing openssh more literate?
<jdstrand> ScottK: oh, I thought we were talking about ssh still
<mathiaz> kees: ie they know more about the root account
<mathiaz> kees: and when they enable the root account they know what they're doing?
<kees> mathiaz: I would say a greater percentage of people installing openssh-server understand the root account
<jdstrand> running the whole X/Gnome stack is a lot of code that wasn't really written with running as root in mind
<kees> mathiaz: and I don't think that people enabling the root account know what they're doing always, which is why I think there's value in making the SSH default be tighter
<jdstrand> again, I'm for it, but defer to cjwatson
<mathiaz> kees: the other argument for defaulting PermitRootLogin to no is that's what upstream recommends in their documentation
<mathiaz> (even though the default is yes)
<kees> mathiaz: yeah, agreed.  mostly we would need to convince cjwatson.  :)
<ScottK> Sounds like upstream should change then
<kees> mathiaz: http://cheezburger.com/View.aspx?aid=3094191616
<mathiaz> kees: lol
<mathiaz> kees: that's *very* helpful in taking a good decision :)
<kees> mathiaz: yeah, I've been using that site for diagrams a lot lately, super easy
<mathiaz> kees: the whole question is actually about the *size* of the different circles
<mathiaz> kees: if blue > brown, then default PermitRootLogin to yes
<mathiaz> kees: if blue < brown, then default PermitRootLogin to no
<kees> mathiaz: exactly.
<kees> mathiaz: actually, maybe not.
<mathiaz> kees: AFAICT the *current* representation relies on the number of letters in the circle label
<kees> PermitRootLogin to no protects the dark green area.
<mathiaz> kees: minus the blue area
<kees> mathiaz: yup.  comment posted to the bug detailing this logic.
<mathiaz> kees: awesome!
<mathiaz> kees: jdstrand: thanks for taking the time to look at this
<kees> mathiaz: sure, no problem.  it's come up before, but the brute-forcing attempts have been getting stronger lately, so it's valuable to revisit it.
<kirkland> slangasek: i don't recall that at all, sorry
<jdstrand> mathiaz: np! :)
<xteejx> NCommander: Hi, I was told by charlie-tca that you were the best person to speak to about helping to build packages for the Ubuntu PS3 port (PowerPC)
<xteejx> I want to contribute
<jonathan_> Wow this is busy
<lool> Laibsch: It's ok, don't ask to ask, just leave me your questions and I should get to them
<Laibsch> lool: I don't ask to ask, but I was under the impression that a ping here grabs your attention while simply writing to you in an ongoing chat doesn't
<Laibsch> just wanted to make sure our discussion isn't lost in the void
<statik> hey, anyone available to sponsor a merge? I filed the proposal about 4 days ago. I'm not in any particular hurry, just don't want it to rot: https://code.edge.launchpad.net/~statik/ubuntu/lucid/protobuf/merge-bug502654/+merge/17571
<lool> Laibsch: it's actually exactly the same, except I get two red channels instead of one  :-)
<Laibsch> lool: OK, thanks
<ScottK> statik: At this point in the cycle, that's not so long.
<statik> ScottK: i can only imagine. i'm buried in work myself and i don't have to deal with sponsoring :)
<lamont> where does sound-juicer get track names from?  (and more to the point, when it decides that the musicbrains answer is available, how do I tell it "no, that's wrong"?
<lamont> and yeah, echan and all that
<ion> siretart: Debian seems to have fix for the gst-plugins-bad0.10 FTBFS.
<TheMuso> lamont: musicbrainz for one
<TheMuso> lamont: And very likely cddb/freedb.
<lamont> TheMuso: well, it's telling me that musicbrains doesnt have it, so I expect "not that"
<lamont> more to the point, sometimes it's getting it very right, other times wildly wrong - for the same CD set...
<lamont> ergo, I want a way to influence it's voting...
<TheMuso> lamont: heh right.
 * TheMuso has found that the shell script abcde is the most flexible method of ripping for his needs.
<lamont> does it get track info?
<lamont> actually, is there any way to have that data encoded on the CD? or is it all magic lookups based on hashes?
<TheMuso> lamont: Yes it gets track info, I think it may have some support for musicbrainz, but it mostly uses freedb. Note that there is no GUI for abcde.
<TheMuso> lamont: I don't think this can retrieve cd-text.
<lamont> ok
<lamont> thanks
<chrisccoulson> is there any reason why fuse-utils provides a /sbin/mount.fuse helper but no umount.fuse helper?
<cjwatson> kees: convince upstream.  I'm not going to deviate from them
<cjwatson> kees: and frankly, I'm fed up with having the discussion every ten minutes
<cjwatson> (this isn't getting at you, but at the people who won't read)
<ockham> hi, is there any easy way to rename a manpage when installing it using debian/<package>.manpages?
#ubuntu-devel 2010-01-22
<cody-somerville> ockham, no
<emgent> cjwatson: ping
<slangasek> kenvandine: is empathy bzr in an uploadable state?  (Just committed a change there, would like to get it to the archive)
<kenvandine> slangasek, it is
<slangasek> kenvandine: thanks, will upload :)
<kenvandine> np
<xnox> Outstanding merges pages got a small overhaul =)
<fabrice_sp> barry: would it make sense to merge system-config-lvm and if yes, are  you taking care of it, or may I work on it?
<siretart> ion: \o/
<ion> \âº/
<superm1> slangasek, re bug 496765, is the eventual intention that plymouthd won't even be in the initrd but instead just an upstart job that gets started after the initrd is done?
<ubottu> Launchpad bug 496765 in plymouth "plymouth ask-for-password doesn't display --prompt argument" [High,Fix committed] https://launchpad.net/bugs/496765
<slangasek> superm1: yes; there are some practical hang-ups preventing us from doing that right now (plymouth and gdm will race)
<superm1> slangasek, what about the time it takes for casper though in the initrd right now?
<slangasek> hmm?
<superm1> that's a long time to be spinning some text on the screen
<slangasek> if you mean 'plymouth should be in the initramfs for liveCDs', casper can drop in an initramfs-tools config snippet to ask for plymouth to be included
<superm1> Ok
<slangasek> (in theory - I haven't looked at whether this is the right thing for casper to do)
<superm1> well then the question I guess is; should it be though?  maybe it's worth investigating moving the tasks casper do out of the initramfs and into the livefs itself
<slangasek> that's what I was immediately wondering, yes :)
<slangasek> but I'm not really familiar enough w/ casper to answer this myself
<dholbach> good morning
<dholbach> when are we going to have the next auto-sync run? I'm waiting on a new tex-common :)
<dholbach> for bug 509981
<ubottu> Launchpad bug 509981 in texlive-base "Please sync texlive-base 2009-7 (main) from Debian testing (main)." [Wishlist,In progress] https://launchpad.net/bugs/509981
<tseliot> slangasek: just FYI in the man page of update-alternatives there's an example with alternatives with a different number of slave links
<slangasek> tseliot: well, ok :)
<tseliot> slangasek: I didn't remember where I saw it when I mentioned it to you and of course it was the man page. My memory...
<tseliot> ;)
<lool> superm1: FYI performance of casper is abysmal on armel, and JamieBennett is looking into improving that for armel and as a result for everybody; often, the scripts are simply way too heavy and were never optimized
<lool> superm1: See e.g. bug #357690
<ubottu> Launchpad bug 357690 in casper "casper very slow on armel+imx51" [Medium,Triaged] https://launchpad.net/bugs/357690
<ogra> lool, pfft, everybody blames casper ... its debconf ;)
<cjwatson> emgent: yes?
<cjwatson> ogra: no it's not
<ogra> i thought its template.dat being loaded by debconf
<cjwatson> ogra: casper doesn't need to start up debconf a zillion times.  I've already been working with Jamie on this
<cjwatson> if it started it up just once, it would be loads faster
<ogra> yeah, indeed
<hdon> hi all. a recent karmic update seems to have blown away my swap? i chose an encrypted home filesystem when i installed, and when this update arrived i think karmic did the sensible thing and tried to offer me encrypted swap as well, but that blew away the UUID for my swap partition, making the /etc/fstab settings useless. this caused *seriously weird stability problems* even though i never actually came close to even 25% RAM usage.
<hdon> disabling swap altogether has fixed the stability issues
<seb128> james_w, slangasek, pitti, cjwatson, Riddell: is somebody doing syncs?
<pitti> not me
<seb128> the queue has some items
<cjwatson> me
<seb128> cjwatson, can you sync-source.py -b cassidy -S unstable telepathy-glib while you are there?
<cjwatson> I was attempting an autosync, it seems to have fallen over
<cjwatson> seb128: one moment - is there an associated bug?
<seb128> cjwatson, no, IRC ping only
<cjwatson> ok
<seb128> cjwatson, I can do that later though
<cjwatson> I'll do it in a moment
<hdon> how is a partition's UUID determined?
<cjwatson> partitions don't have UUIDs, filesystems have UUIDs
<cjwatson> they're randomly generated when the filesystem is created
<hdon> good to know. what about swap, then?
<cjwatson> same
<cjwatson> hdon: karmic *update*, or an installation over the top of a previous installation?
<hdon> just a routine software update, like several before it
<cjwatson> that is seriously weir
<cjwatson> d
<seb128> cjwatson, thanks
<cjwatson> hdon: do you have any idea specifically which packages were updated?
<hdon> but this is a relatively new system (just got it from system76 about 10 days ago) so i didn't get much time to familiarize myself with things prior to the updates
<hdon> cjwatson, any way to find out? i know the kernel and video drivers were updated, but that's all fine as long as i disable swap
<cjwatson> hdon: should be possible to dredge it out of /var/log/dpkg.log
 * hdon looks
<cjwatson> seb128: done
<seb128> cjwatson, thank you
<hdon> i'm guessing cryptsetup is the package. it looks like it was installed alongside the other updates. i never deliberately picked this package out with any apt tools myself.
<hdon> 2010-01-15 10:37:20 status installed cryptsetup 2:1.0.6+20090405.svn49-1ubuntu7.2
<cjwatson> slangasek: ^-
<cjwatson> hdon: looks quite plausible, please file a bug
 * hdon launchpads
<cjwatson> I don't see a trivial fix, I expect it requires some thought
<cjwatson> we certainly can't just casually mkswap over the top of things without care though
<hdon> ;)
<hdon> i keep getting kicked to https://help.ubuntu.com/community/ReportingBugs :\
<hdon> i guess i'm supposed to read it
<xteejx> Hey guys, when will the fix for bug 511014 be available in the repos?
<ubottu> Launchpad bug 511014 in wine1.2 "package wine1.2 1.1.36-0ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 10" [High,Fix released] https://launchpad.net/bugs/511014
<chrisccoulson> xteejx: when it's built and published
<chrisccoulson> it was only uploaded 35 minutes ago
<xteejx> chriscoulson: Oh ok, I didn't know how long it takes, no worries :) Thank you
<pitti> slangasek, crimsun: is bug 490634 still an issue in current lucid? I thought Intel HDA power management was disabled by default again?
<ubottu> Launchpad bug 490634 in alsa-driver "popping sound with HDA power_save=10 in Lucid" [Medium,Triaged] https://launchpad.net/bugs/490634
<davidc_> mvo: can I ask you a quick question please? :)
<mvo> davidc_: yes
<davidc_> woo!
<davidc_> you know those debconf screens on some packages when doing apt-get install packagename
<davidc_> is there a way to skip them by passing some arguments to the apt-get install command?
<davidc_> say if you install apt-get install dbpackage and it pops you a debconf screen asking for a host
<davidc_> what I'd like to do is have an bash script to automate the install and do something like apt-get install dbpackage --host=xxx
<davidc_> or whatever the actual param from the package is which I can easily find
<mvo> davidc_: you can use "DEBIAN_FRONTEND=noninteractive" in the environment
<davidc_> But can I automate them? let me google up noninteractive first :P
<mvo> yes, pre-seeding should too, but I don't have a example ATM
<cjwatson> debconf-set-selections is the program you want
<davidc_> ah nice one, tahnks
<cjwatson> you can find the relevant keys (at least) by running through a test installation with DEBCONF_DEBUG=developer set
<davidc_> well it's our own package but our sysadmin is on holidays :D
<davidc_> so was wondering if I could try to get this running on my personal test servers
<davidc_> finding the names of the arguments isn't a prob
<lool> cjwatson: Not sure you're Cc:ed on the vmbuilder grub2 bug (509609); FYi I'm hitting a segfault, so I intend to try again with a noopt nostrip build of grub2
<cjwatson> I'm probably CCed but bugmail is a bit argh
<lool> cjwatson: Actually I didn't see you in the Cc:s
<cjwatson> am now
<cjwatson> lool: would be good to try with --verbose
<lool> Ok; thanks
<cjwatson> lool: actually --verbose --verbose
<cjwatson>   if (verbosity > 1)
<cjwatson>     grub_env_set ("debug", "all");
<lool> Ack; I remember this from the debug session I did on my RAID10 issue
<lool> cjwatson: BTW a RAID10 install with 3 disks out of 4 (partially degraded) works fine as expected
<lool> But you can not boot with 2 disks out of 4 either
 * lool broke 4 hard disks out of 6 in the last 2 weeks
<cjwatson> right, I haven't got round to getting that grub bug fixed yet
<hdon> lool, how are you breaking HDDs so fast?
<ogra> hdon, he wants them to grow bigger, so he waters them ;)
 * hdon giggles
<chrisccoulson> does watering them not work then? ;)
<ogra> /dev/sda6: clean, 146107/2321984 files, 951738/9277521 blocks (check deferred; on battery)
<ogra> does anyone know where the check for being on battery is performed here ? is that e2fsck itself ?
<soren> ogra: Yes.
<ogra> thanks
<soren> e2fsck/unix.c[is_on_batt]
<ogra> trying to find out why it always thinks its on battery on armel systems
<ogra> these boards dont even have a battery :P
<soren> It looks at /proc/apm and /proc/acpi/ac_adapter/*/state
<ogra> yeah
<ogra> no ACPI on arm machines :)
<ogra> but /proc/apm ...
<zul> pitti: can you approve the MIR for python-openid, nagios-nrpe, and pastescript please? thanks
<lool> hdon: Sad stories   :-(
<pitti> zul: they are already approved
<zul> k
<pitti> ah, they are on component-mismatches now
 * pitti promotes
<pitti> zul: pastescript is not on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt yet
<zul> pitti: k ill have a look
<zul> pitti: how often does the script run?
<pitti> zul: every hour, after the publisher run
<zul> pitti: ok thanks
<zul> can you promote nagios-nrpe-server as well?
<pitti> zul: I promoted all binaries from those sources
<zul> pitti: thanks!
<sgallagh> tjaalton: Just released SSSD 1.0.3, which includes the fix for the linker bug you found.
<tjaalton> sgallagh: great, thanks
<sgallagh> tjaalton: No, thank you for catching that.
<tjaalton> sgallagh: no problem. now if just SASL worked with AD ;)
<sgallagh> tjaalton: Right now, I think we only support GSSAPI for SASL
<tjaalton> sgallagh: yeah but AD expects an UPN and barfs at SPN's. it's the same with rpc.gssd from nfs-utils, but I'm about to fix that
<sgallagh> Ah, gotcha
<sgallagh> Patches welcome :)
<tjaalton> sure, I need to look at it..
<tjaalton> could be that given the time constraints I don't have time to fix sssd anytime soon, but use winbind or something in the meantime
<tjaalton> or, certs with sssd instead of gssapi
<jdstrand> cjwatson: how often is lp:debian/... updated? I wanted to do a libvirt merge and debian/squeeze and debian/sid are very out of date
<jdstrand> cjwatson: hi btw! :)
<StevenK> jdstrand: james_w would be the person to ask ?
<jdstrand> StevenK: right, I noticed he wasn't around atm, and thought cjwatson might know...
<jdstrand> cjwatson: if you don't know off-hand, no worries
<geser> jdstrand: the import probably failed, check if it listed on http://package-import.ubuntu.com/
 * jdstrand checks
<cjwatson> jdstrand: -> james_w
<cjwatson> I don't know the answer
<cjwatson> jdstrand: if in doubt, you can file a bug on the 'udd' project
<jdstrand> cjwatson: k, thanks
<jdstrand> geser: yeah, it traced back
<ockham> hi, i'm a newbie with a rather trivial question: what do i have to specify in debian/rules if the actual sources (including autotools files and everything) are in a subdirectory of a package?
<ScottK> ockham: Basic packaging questions are better asked in #ubuntu-motu
<ockham> ok, i'll ask there
<cyberix> good day
<cyberix> I've been thinking about trying to get miredo into Lucid+1
<cyberix> Installing the package by default would make IPv6 work for Ubuntu users
<cyberix> the package is currently pointing to a server run by its developer
<cyberix> and I doubt it would be pollite to have _all_ Ubuntu users use his server
<cyberix> Can I somehow discus this with someone running stuff at ubuntu.com or canonical.com?
<cyberix> I understood the traffic should not be too heavy
<cjwatson> you can ask #canonical-sysadmin
<cyberix> thanks
<BenC> bdmurray: Hey, would you know how to setup apparmor rules to give a program that's not running as root the ability to seteuid(0)?
<bdmurray> BenC: No kees or smb would know better.
<bdmurray> er sbeattie
<BenC> kees: any ideas?
<smb> bdmurray, BenC Or at that time of day jjohansen
<pitti> BenC: hey
<BenC> I forgot jj is on
<pitti> BenC: I don't think that's possible
<BenC> pitti: hey :)
<pitti> apparmor can only restrict privs, not increase them
<kees> BenC: \o/ hey man, good to see you.  :)
<pitti> (which is a feature IMHO)
<BenC> pitti: ah, that sucks...I need an apache2 module to be able to seteuid(0) temporarily :(
<pitti> oh, that's a .so, isn't it?
<kees> pitti: technically, that's not true; it can grant capabilities.
<pitti> kees: oh?
<BenC> there's a hackish blinkcap kernel module that allows you to do it via LSM, so I suspect apparmor could do it
<pitti> seems my knowledge is outdated by a few years then, sorry
<pitti> bah
<kees> pitti: "capability foo," allows, and "set capability foo," elevates.
<BenC> kees: hey back :)
<kees> BenC: yeah, unfortunately I don't think AA has a way to elevate uid.  jjohansen any thoughts?
<jjohansen> yep
<jjohansen> you can do it with pam_apparmor
<kees> BenC: can you write a setuid helper or something?
<BenC> doesn't seteuid have a capability associated with it?
<pitti> kees: so you could just grant CAP_SETUID?
<BenC> setuid I guess would be fine too
<jjohansen> but not at the setuid barrier currently
<jjohansen> kees, BenC: just double checking what do you mean by elevate uid?
<maxb> Does anyone know why the bzr branches at https://code.launchpad.net/debian/+source/subversion have been deleted?
<kees> BenC: oh right, I always forget about CAP_SETUID
<BenC> jjohansen: I have an apache2 module that I want to allow to seteuid(0) temporarily without running apache2 as root
<jjohansen> kees: if you mean elevate uid to have a capability, yes and no
<BenC> or setuid(), either way works I guess
<jjohansen> BenC: apparmor setting of capabilities will raise none root users cap
<kees> BenC: just a module will be tricky without a full mod-apparmor changehat configuration.
<jjohansen> BenC: but it won't overcome any DAC checks for uid hard coded in the kernel
<BenC> I thought the whole purpose of caps was to allow non-root programs to use root related syscalls and such :)
<kees> jjohansen: can't it grant CAP_SETUID and then the module calls setuid(0); *stuff* setuid(getuid()); ?
<jjohansen> kees: yes
<BenC> basically the module currently exec's sudo and runs a script, and I want to move that into the module for stability and cleanliness
<BenC> jjohansen, kees: that's exactly what I want
<kees> BenC: the trouble is that AA confines processes, not libraries.
<BenC> kees: not a problem to me...I realize that while elevated as uid 0, the whole process and whatever libs are loaded also get privs, but it's a risk I'm willing to take
<kees> so to get this to work with apache, you'd need a full mod-apparmor configuration (which isn't hard, it's just bigger than a "simple" change)
<kees> BenC: is this under Karmic, I hope?
<BenC> kees: hardy
<kees> hrm
<kees> under Karmic the changehat stuff for mod-apparmor is well tested.  hardy, less so.  and I suspect you don't want to just run all of apparmor with CAP_SETUID.
<BenC> it's basically running mount (on arbitrary mount points, so fstab is not involved) and calling dm_* functions
<jdstrand> kees: I have only barely been following this, but I use change_hat on hardy
<jdstrand> kees: though not for raising privs
<kees> BenC: if you want to go the changehat route, read through the instructions here: http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/annotate/head%3A/profiles/apparmor.d/usr.lib.apache2.mpm-prefork.apache2
<BenC> kees: thanks
<kees> BenC: based on what you're saying, it sounds like using sudo or a wrapper would be much saner, though.
<BenC> kees: I want to avoid exec though, since it's killing performance to do that for every request at the rate I'm getting them
<kees> BenC: I'm terrified that you have such a high volume of calls to mount/dm_* and the exec is the bottleneck.  :)
<kees> BenC: you could write the wrapper to do the mount() calls directly instead of re-execing to "mount" the utility
<BenC> kees: it's not mounting everytime, but I need root to check the dm state (dm-crypt, lvm, mount)
<kees> cool
<dantti> cjwatson: hi! Did you have time to work on that DBus thing for debconf?
 * sebner is wondering who the fsck/filesystem guy is in here :)
<cjwatson> dantti: unfortunately not, a hugely time-consuming project intervened
 * cjwatson puts it on our sprint agenda for the first week of Feb, in order that it might actually happen :)
<JFo> apologies pitti, I am having a bad day
<pitti> JFo: no worries, no harm done; it just didn't quite look fitting into the current conversation :)
<JFo> heh, it wasn't :)
<dantti> cjwatson: hmm, I'd like to help if let me to, do you remember my proposals?
<dantti> cjwatson: do you prefer to talk about that in Feb?
<cjwatson> I'll have a lot more state in my head about it if we talk about it in Feb
<cjwatson> so that might be more sensible; sorry again for the annoying delay
<dantti> cjwatson: np, thanks, good luck with your stuff :)
<kees> known issue?
<kees>   docbook-utils: Depends: jadetex but it is not going to be installed
<persia> kees: I can't reproduce with lucid amd64 : where do you see that?
<kees> persia: http://launchpadlibrarian.net/38274976/buildlog_ubuntu-lucid-i386.wine1.2_1.1.36-0ubuntu3_FAILEDTOBUILD.txt.gz
<kees> and my lucid chroots
<jjardon> join #ubuntu-desktop
<persia> Hrm.  My chroots must be out of date.  I can install for all of i386, amd64, and powerpc.
<kees> aptitude says tex-common is broken
<kees> but... it hasn't changed in lucid
<persia> kees: New upload of tex-common just under 6 hours ago.
<kees> persia: ah, that must be it.
<kees> persia:
<kees> Conflicts: tetex-base (<< 2007), texlive-common (<< 2009)
<kees> texlive-base | 2007.dfsg.2-4ubuntu1 | lucid/main
<persia> That would be it, and my apt-caches may well be > 6 hours old.
<cjwatson> it was a sync pass, maybe check for build failures
<kees> cjwatson: the problem is that tex-common requires a newer texlive-base that hasn't been merged.
<persia> There's some tex stuff listed in NEW as well, which may have an impact.
<cjwatson> right, lack of merge is entirely plausible
<cjwatson> I'll process NEW
<kees> and... *drumroll* I touched it last!
<cjwatson> I've flushed all the TeX stuff from NEW
<superm1> lool, something else to consider is moving scripts that are specific to any remix/derivative into a package that only gets seeded when you are building an image for that derivative
<superm1> i already moved a lot of the mythbuntu stuff out
<kees> cjwatson: can you sync texlive-base from testing?  that's the root problem afaict.  I'll have a LP bug # shortly.
<cjwatson> no need for a bug if that's all it is
<cjwatson> well
<kees> well, requestsync already ran...
<cjwatson> actually, yeah, a bug would be good
<kees> cjwatson: oh, it's there already, heh: 509981
<cjwatson> kees: you should poke bhavi for failing to contact you before doing that work
<cjwatson> I've spoken to him before about this
<kees> cjwatson: okay, I'll drop him a line.
<cjwatson> and what's that nonsense set of dups?
<cjwatson> meh, upgrade bugs
<kees> cjwatson: thanks for the sync
<slangasek> pitti: 490634> it's still an "issue" in that we shouldn't have pops when setting it; but we can probably drop the release target (done)
<JFo> slangasek, sorry bout my blurb of useless info during the release meeting today
<slangasek> JFo: no worries :)
<JFo> :)
<slangasek> it was one of the more coherent interruptions we've seen ;)
<JFo> hahaha
<zul> slangasek: i was wondering if you are any closer to upstarting samba yet?
<slangasek> zul: I'm not closer yet to understanding why nmbd was failing to start, and I need to resolve that before we know which way the upstart job should be written.  I'll work on it today - though first up is "why does plymouth fail for everyone not using intel"
<zul> ah i see priorities ;)
<ScottK> slangasek: Because they don't love Software Freedom enough.
<JFo> heh
<slangasek> ScottK: I mean the plymouth bug, not the industry bug :)
<slangasek> cjwatson: the only issue I can see with bug #511137 (hdon's cryptsetup issue from last night) is that something left a bogus unencrypted swap line in /etc/fstab when configuring crypted swap.  What installer component is responsible for configuring crypted swap when enabling crypted homedirs?
<ubottu> Launchpad bug 511137 in cryptsetup "[karmic] unstable system after updates to cryptsetup" [Undecided,Incomplete] https://launchpad.net/bugs/511137
<kees> can an archive admin process the NEW queue for texlive-2009-7?  it's holding up some builds.
<geser> texlive-base? yes please
<kees> yeah
<jdstrand> slangasek, cjwatson: I've got texlive
<slangasek> jdstrand: ok, cheers
<sistpoty> slangasek: from ubuntu+1: <wm_> im running lucid, i did an apt-get update last night, shut machine down, i come in today and try to boot machine and its stuck at "Starting init crypto disks" .  what am i doing wrong ?
<sistpoty> slangasek: might be related?
<slangasek> sistpoty: not at all related to the above conversation
<sistpoty> sorry, just figured that I didn't read karmic until now :(
<mathiaz> kees: hi!
<hdon> slangasek, that's my assessment, too.
<mathiaz> kees: is there a reference to the Ubuntu policy that states: no open ports on default installations?
<jcastro> mathiaz: https://wiki.ubuntu.com/SecurityTeam/Policies
<jcastro> I just happened to be on that page!
<mathiaz> jcastro: thanks!
<hdon> lol, funny someone named "castro" telling us the governing policy about what ports we can have open ;)
<jcastro> ubuntu libre!
<kees> mathiaz: sorry, was in code.  jcastro got you sorted out though.  :)
<geser> kees: is a merge of texlive-extra needed now too to unbrake texlive in lucid?
<niktaris> hi, where can I find syslinux theme of the ubuntu .iso ?
<kees> geser: hrm, yeah, looks like it.  whee
<geser> kees: how big is your internet connection?
<geser> from the Ubuntu changelog the merge looks easy but the package is big: around 500 MB source
<kees> geser: oowchy
<kees> geser: I will attempt a merge from the canonical datacenter, one sec
<cjwatson> slangasek: err, not entirely sure.  might be user-setup?
<cjwatson> slangasek: this is an "I get code dumps from kirkland" kind of thing
<cjwatson> niktaris: I suspect you're looking for gfxboot-theme-ubuntu
<niktaris> cjwatson, yes found it and trying to apply it to debian :-)
<mathiaz> slangasek: hi
<mathiaz> slangasek: with upstart jobs, is /etc/default/service still recommended for a service configuration?
<mathiaz> slangasek: or is it now better to modify the upstart job directly?
<geser> kees: thanks for the texlive-extra merge
<geser> wow, LP produced a 108.3 MiB diff
<elmo> it can produce hundreds of GB diffs in the right cirumstances (hi udev!) :-p
<kees> heh
<fagan> elmo: why are the diffs so large?
<fagan> Oh and dont the launchpad guys hate when the they take up lots of space?
<jpds> 'disk is cheap'
<fagan> then why do we only get 1gb per ppa?
<fagan> :)
<StevenK> Because disk *isn't* cheap
<fagan> Well I suppose 1tb is 50 pounds so its not so bad
<StevenK> Say, you want to scale to 10,000 PPAs. At 1GB per, that's 10,000GB with all PPAs using all their space, or 10TB
<StevenK> Now price 10TB with server class drives using SCSI
<elmo> fagan: because of a bug in debdiff, I was kidding
<elmo> but I'm very glad we've gotten into a 'disk is cheap'
<elmo> excuse me while I go and throw myself off the roof
<cody-somerville> lmao
<fagan> hah
<geser> kees: texlive should be (hopefully) unbroken now. Ideally an archive admin could remove texlive-base-bin from the NBS side to be on the safe side
<geser> texlive-binaries provide texlive-base-bin and the most dependencies are unversioned (jadetex uses a versioned one -> bug #511399)
<ubottu> Launchpad bug 511399 in jadetex "Update versioned build-dependency from texlive-base-bin to texlive-binaries" [Undecided,New] https://launchpad.net/bugs/511399
<geser> I don't know if the buildds will pickup the right package: texlive-base-bin is real but uninstallable, while texlive-binaries is installable but only provides texlive-base-bin
<kees> geser: whee
<mathiaz> kees: would you say that apparmor profiles are safer than chroots for daemons?
<mathiaz> kees: ex: is it safer to run bind9 under an apparmor profile or chrooting them?
<mathiaz> kees: or to put it another way: should daemons that usually run chrooted be migrated to apparmor profiles?
<kees> mathiaz: hrm
<kees> mathiaz: I don't think I can make a blanket statement
<kees> mathiaz: daemons running as non-root in a chroot are pretty well isolated.
<kees> mathiaz: I would prefer apparmor profiles for daemons that run as root
<kees> mathiaz: using a profile is great, but I'm not sure if it makes sense to carry a delta.
<kees> mathiaz: note that it can do both.  :)
<kees> i.e. write a profile for the chroot'd service.
<mathiaz> kees: right - I'm writting my UDW session about server packages (ie daemons)
<mathiaz> kees: and one of the topic is apparmor profiles
 * kees nods
<mathiaz> kees: I just wanted to compare them to chroot
<mathiaz> kees: as chroot is often seens a way to secure daemons
<kees> chroot is more system agnostic, but I think apparmor is stronger
<kees> but they're not mutually exclusive.
<mathiaz> kees: would it be fair to say that AppArmor profiles provide an alternative to chroots?
<mathiaz> kees: *for* daemons
<jdstrand> mathiaz: apparmor and chroots are different
<jdstrand> like kees said, you can chroot *and* apparmor
<kees> it's an alternative, yeah, but since they're not mutually exclusive, there's no reason to stop chroot'ing or stop using a profile
<mathiaz> jdstrand: agreed
<jdstrand> apparmor allows for confining capabilites and networking
<jdstrand> you don't get that in a chroot
<kees> if you have a daemon without either, I would do a profile.
<jdstrand> the biggest benefit is that you don't have to maintain a chroot with apparmor
<jdstrand> we did bind9 and mysql because though they could be configured to use them, they were not in packaging
<jdstrand> postfix on the other hand, there is no compelling reason to write a profile for it
<jdstrand> if a package already has a working chroot setup, I'd say look elsewhere rather than migrate
<jdstrand> packaging an apparmor profile can also be considerably easier than a chroot
<lamont> jdstrand: if I didn't have an ugly history of installed base, I expect bind would wind up chrooted, or at least !root
<lamont> but since it drops all privs early on, I'm not too terribly ashamed that it starts as root
<jdstrand> sure
<StevenK> Bind is also fairly easy to chroot
<lamont> StevenK: in a fresh install yes.  automatically doing it in an upgrade? not so much
<StevenK> lamont: Well, yes :-)
<lamont> esp since the admins out there like to roll their own world in total violation of FHS
 * lamont looks askance of milli
<jdstrand> of course, that is a problem for profiling, but easier to fix
<lamont> hrm. was that my outloud voice?
#ubuntu-devel 2010-01-23
<slangasek> mathiaz: for new stuff, definitely preferred to modify the job directly; for existing stuff, I've tried to respect the existing configs when converting
<mathiaz> slangasek: great thanks
<mathiaz> slangasek: I'm writting my UDW session about server packages
<mathiaz> slangasek: and plan a topic about upstart jobs
<slangasek> ah :)
<mathiaz> slangasek: do you have specific ideas about upstart features useful for daemons?
<mathiaz> slangasek: I already have: supervision
<mathiaz> slangasek: support for forking daemons
<mathiaz> slangasek: examples of running daemons in foreground
<slangasek> I was intending to put together a talk about authoring upstart jobs for UDW, but I didn't see a call for sessions this time around (just an announcement of when it was that implied the slots were already filled)
<slangasek> mathiaz: automatically cascading restarts?
<mathiaz> slangasek: oh nice
<mathiaz> slangasek: examples?
<slangasek> (service portmap restart -> restarts portmap, gssd, statd)
<slangasek> not sure that's actually /needed/ for either of those services, but in practice it will happen :)
<mathiaz> slangasek: is this already available in lucid?
<slangasek> yes
<slangasek> and in karmic
<mathiaz> slangasek: do you have example of an upstart job that starts a process that forks
<mathiaz> slangasek: IIRC there is the fork keyword available
<mathiaz> slangasek: or expect fork - something like that
<slangasek> mathiaz: many do... ssh, portmap, atd, et al
<ion> Upstartâs fork-following code is quite fragile currently. The next-gen Upstart will have a proper implementation that should handle any situation well.
<slangasek> really?  that's not a caveat Keybnz has mentioned :)
<mathiaz> slangasek: any other ideas about Upstart feature relevant for managing daemons?
<ion> He has mentioned it repeatedly.
<slangasek> mathiaz: built in support for oom handling?
<slangasek> ion: to you, apparently, but not anywhere that I've picked up on it...
<slangasek> mathiaz: +nicing +limits
<mathiaz> slangasek: hmmm - any examples of this use?
<slangasek> mathiaz: ssh in lucid; for the other two I don't have live examples, just init(5)
<ion> If the jobâs main command consistently does a fork or a double fork and you tell Upstart about it with the expect stanza, things will work.
<slangasek> ion: oh, fragile in that you have to tell upstart what to look for, sure
<ion> If the main command is a shell script that runs stuff and then execs the main daemon *that forks*, thatâs likely to break the current implementation.
<mathiaz> slangasek: great - thanks for the input!
<slangasek> ion: right, that was one of the points for my theoretical UDW talk, under the heading "how to write an upstart job that you have to reboot to fix" :)
<mathiaz> slangasek: I also noticed that there wasn't a reload command
<ion> If the shell script does a fork-and-exec for an external command, the code will shit itself. :-)
<mathiaz> slangasek: hm - sorry
<mathiaz> slangasek: a force-reload command
<ion> The proper implementation in Upstart 0.10 or whatever itâll be called will handle that, too.
<mathiaz> slangasek: as mentionned in the Debian policy
<slangasek> mathiaz: Debian policy describes the behavior of init scripts in /etc/init.d; the upstart-job shim implements force-reload
<slangasek> (though I'm not sure the 'reload' command is the right backend for that, maybe we have a bug there)
<mathiaz> slangasek: is there a way to specify in the upstart job the command to be used for reload?
<mathiaz> slangasek: ie send SIGUSR2 to the process for example?
<slangasek> no
<LLStarks> okay. can somebody tell me why reinstalling packages doesn't actually reinstall files?
<LLStarks> if i reinstall the pulseaudio package after rm'ing the /etc/pulse directory, i expect it to be restored.
<LLStarks> i shouldn't have to purge and then install
<RAOF> LLStarks: /etc/pulse/ contains conffiles (as defined by dpkg), and dpkg makes sure that your changes to conffiles are preserved across installs.
<LLStarks> how do i override?
<RAOF> Well, you've found one way; purging will remove dpkg's memory of your conf file changes.
<LLStarks> well, that can break and uninstall other packages
<LLStarks> is there a more direct way?
<RAOF> dpkg --purge --force-depends should purge just the package you're interested in, leaving everything else installed (but broken).  I think.
<RAOF> Then installing again will reconfigure everything.
<geser> IIRC there are some options to dpkg to force reinstall of missing /etc/ files
<geser> LLStarks: try "dpkg --force-confmiss $the.deb"
<LLStarks> thanks.
<persia> slangasek: IF you're still interested in a UDW slot, you can have mine, as I'm just reprising a talk I've given lots of times (and I suspect all would be better served by a good understanding of upstart vs. me blathering about stacktraces again)
<slangasek> persia: when is your slot?  I haven't done any prep work yet
<persia> Friday
 * persia digs up the exact time
<persia> 29th January 20:00 UTC.  It's 5:00 saturday local for me, so I really won't miss it :)
<hyperair> is it possible to create nfs shares without requiring root access?
<hyperair> if it was, then i could possibly expand nautilus-share's scope to include NFS support.
<geser> what's the solution for the python and linking with ssl issue?
<ScottK> What's the issue?
<geser> I'm trying to merge vim and got the problem that linking with python failed because of -lssl not being there
<geser> I remember that some other builds had similar issues in the past too
<geser> ScottK: looks like vim pulls in the value from LOCALMODLIBS from /usr/lib/python2.6/config/Makefile and -lssl is listed there
<_Groo_> hi/2 all
<ScottK> geser: Oh.  No idea on that one.
<_Groo_> you guys are updating to rc2 as i can see, gonna have to update my kde multimedia pulseaudio as soon as you upload the new multimedia to lucid
<ion> hi/2 looks like an Erlang function reference.
<_Groo_> ion: actually its an os/2 old warrior reference
<_Groo_> ScottK: is rc2 be up 100% today (also with kdebindings for the first time? oO
<ScottK> _Groo_: I know it's building now.  I didn't help with the packaging this time around, so I don't know about kdebindings.
 * _Groo_ cross is fingers
<_Groo_> ScottK: but the complete package will be uploaded today?
<ScottK> _Groo_: It's all uploaded now.  In the process of building.
<_Groo_> ScottK: sorry i mean published :) do you have a url i could see fo check for building progress?
<ScottK> _Groo_: For kdebindings?
<ScottK> There isn't one url for all of KDE.
<_Groo_> ScottK: no, i mean, are you using a ppa to test or something like that? i wanna check what packages are built and published already
<ScottK> _Groo_: For Lucid, it's in the Ubuntu archive.
<_Groo_> ScottK: link pls?
<ScottK> _Groo_: There isn't one for all of KDE.  You should probably ask in #kubuntu-devel for someone who was involved in packaging it.
<_Groo_> ScottK: OMG i forgot that konversation removed that tab lol.. you are right
<qense> What is the difference between Python packages in /usr/share/pyshared/ and those in /usr/share/?
<ScottK> Generally the ones in /usr/share/pyshared are designed to (properly) support more than one Python version on a system.
#ubuntu-devel 2010-01-24
<persia> slangasek: So, did you want the 29th 20:00 slot?  If not, I need to prep for it :)
<ScottK> slangasek: texlive-latex-base is currently uninstallable due to depending on luatex.  luatex is a depends now.  It looks to me like it's either a MIR for luatex (at a glance I think all it's depends/rdepends are in Main) or rip all the luatex stuff out of texlive-latex-base.  I'd rather keep it so we can sync Tex stuff from Debian.  What do you think?
<derknecht> i have a encrypted ubuntu 9.10 installed, and had problems with grub2, i am now using grub1 (from my gentoo installation)  and want to know how the kernel line in menu.lst should look like for booting a encrypted root file system (installed with alternate cd). Thanks a lot.
<persia> derknecht: You might get more support in #ubuntu : this isn't a support channel, and it's a weekend, when lots of people don't pay attention to this channel.
<derknecht> persia: k, thanks
<persia> derknecht: Good luck.
<derknecht> persia: solved :D
<persia> Excellent!
<LLStarks> hi, if i have a grievance about a dev decision regarding lucid, do i put it here or in ubuntu+1?
<ion> Either, if you want nothing to happen. If you want someone to notice it, file a bug report or a blueprint, depending on the type of your wish.
<persia> bug report is generally better for something described as a grievance (unless it is of the class of "Why isn't there a pony on the CD?".
<LLStarks> it's about the new bottom-tabbed nautilus
<LLStarks> it sucks
<persia> But for "Why did my pony get taken away?", a bug report is definitely better.
<persia> That's "Why did my pony get replaced by an aardvark?", and also better as a bug.
<LLStarks> it is so annoying that i want to e-punch the person that signed off on it
<LLStarks> also, i'm unsure of the proper mailing list
<persia> Run `ubuntu-bug nautilus` on a system experiencing it.
<geser> I got hit by this "feature" too on the first time: I opened several tabs till I noticed that they're at the bottom now
<persia> Bugs written from the viewpoint of "How usability can be improved by restoring previous behaviour" without e-punches tend to get the best treatment.
<LLStarks> don't these sort of bugs have an omnipresence that every developer and their dog should already know about?
<LLStarks> or are devs so foolish as to not see the repercussions of their enhancements?
<persia> As you've seen, a developer has been hit with that bug.  Doesn't mean anyone filed it, or that anyone is working on reverting it.
<persia> More than anything, these things need discussion.
<LLStarks> as  far as i heard, the people that decided said the decision was closed.
<LLStarks> and was an upstream thing
<persia> Ah, if that's documented in an upstream bug, then, yeah, Ubuntu is likely to follow that.
<persia> Your best bet is to continue the discussion upstream.
<geser> LLStarks: gnome bug #606027
<ubottu> Gnome bug 606027 in Tabs "Tabs should be displayed at the top" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=606027
<LLStarks> thanks.
<sebner> persia: that's not a bug that's a decision upstream made (I hope it'll be reverted though)
<persia> sebner: A "bug" is how we describe anything that represents an atomic change to software.
<persia> It's not like a crash, but I stand by my opinion that a bug tracker is the best place to discuss it.
<sebner> persia: Sure, but wondering if you can declare something upstream decided as "bug"
<persia> Why not, if I disagree.
<persia> Doesn't mean they have to fix it :)
<sebner> persia: It's always a question of how much influence the users have and how stubborn upstream is
<persia> And the quality and strength of arguments for each viewpoint.
<hyperair> if we're not reverting that stupid commit, i'm going to be maintaining a custom build of nautilus.
<hyperair> and if more of this stupidity continues happening, i might just end up in gentoo Â¬_Â¬
<sebner> persia: haha, speaking of strength and quality ... "Too much stuff is already up there so let's put it down to the bottom" ..
<persia> sebner: If you have a stronger argument (for either viewpoint), please add it to that bug.
<sebner> persia: My opinion is already covered by the present comments and I think they are pretty valid
<persia> There you go then :)
<hyperair> persia: so what happens when we all have very nice and valid comments, but upstream continues to be stubborn?
<hyperair> s/comments/arguments against tabs-at-bottom/
<sebner> hyperair: accept it, change distro, custom nautilus build :P
<Ng> what does changing distro have to do with what gnome upstream is doing?
<hyperair> >_>
<persia> hyperair: If upstream will not change, there are three choices: 1) fork, 2) make a distro-level change 3) make a personal change.
<sebner> Ng: Kubuntu ;)
<persia> I don't think it's worth changing distros just because you want to apply some patch.
<hyperair> Ng: i'm just saying, if more stupidity comes from multiple different apps, and i end up maintaining custom builds of several different apps, i might as well go gentoo where i have to compile every damn thing anyway.
<sebner> persia: I didn't say anything about being worth it, it's just an option
<Ng> hyperair: sounds like a lot of effort just to move a tab bar ;)
<hyperair> Ng: well, GNOME upstream has been rather stupid lately.
<hyperair> Ng: you never know what they're going to do next.
<hyperair> oh by the way, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/509079
<ubottu> Ubuntu bug 509079 in nautilus "nautilus has tabs on bottom" [Low,Triaged]
<hyperair> we've got an ubuntu bug as well.
<jcastro> you could probably maintain your own patchset like the nautilus-elementary folks do
<ScottK> On the off chance there's an archive admin with shell access around .... https://launchpad.net/ubuntu/lucid/armel/luatex/0.50.0-1 still needs promotion to Mail.
<ScottK> Mail/Main
<gavintlgold> can someone explain to me what "sudo apt-get remove programname{p}" does? I'm not talking about apt-get remove in general but adding the {p} to the end of the name.
<gavintlgold> I'm assuming it removes instances of the app installed via the "make install" command after compiling. is this assumption correct?
<owen1> my dell uses Elantech touchpad and I can't configure it. i contacted dell and they refered me to cananical. i didn't hear back from canonical.  who is the maintainer of elantech driver?
<owen1> someone told me EEEpc also has it and it's possible to configure it.
<owen1> can you guys direct me toward a solution?
<owen1> here is a link to someone how wrote a driver -  http://arjan.opmeer.net/elantech/
<owen1> it's noo complex for me to understand it though.
<RAOF> gavintlgold: No, that's not correct.
<RAOF> gavintlgold: There's no way (in general) to remove instances of an app installed via âmake installâ, and it's outside the scope of the package manager.
<RAOF> gavintlgold: What {p} means is âpurgeâ which, in addition to removing the package, also removes the (system wide) config files - ie: stuff in /etc.
<owen1> how to find a maintainer of a touchpad driver?
<soreau> Hey I was wondering, where are the settings stored that gnome-window-properties sets?
<soreau> I assume somewhere in ~/.gconf, but which key?
<soreau> Trying to figure out how to change the titlebar doubleclick action without gnome-window-properties
#ubuntu-devel 2011-01-17
<RoAkSoAx> howdy all! I was wondering if anyone has any word about the LAFile removal as per http://wiki.debian.org/ReleaseGoals/LAFileRemoval
<micahg> RoAkSoAx: http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries
<RoAkSoAx> micahg: cool, thanks for pointing that out !!
<micahg> RoAkSoAx: if you're wondering when something was implemented you can see it here: /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
<RoAkSoAx> micahg: k thanks ;)
<ShapeShifter499> hi
<ShapeShifter499> YokoZar you there?  I need to ask you something..
<SpamapS> slangasek: interesting.. I wonder if that is intended.. that a missing env var does not match the empty string.
<SpamapS> slangasek: I think it might be worth ammending man 5 init to state that clearly
<SpamapS> slangasek: ok I see the op order problem too. doh. BTW, why doesn't the restart command work on portmap? seems like it just runs the pre-stop then does nothing
<slangasek> SpamapS: ah, restarting *portmap* worked... it's that statd wouldn't restart as intended when portmap starts up again
<slangasek> SpamapS: my fixes are all committed and pending in the main bzr branches now
<SpamapS> slangasek: so I think it would be worthwhile to file a bug against upstart to improve the explanation of environment variables in the start on and env portions.
<SpamapS> slangasek: do you see where running 'restart portmap' fails to actually restart portmap?
<slangasek> it doesn't fail to restart portmap, afaik?
<slangasek> it just fails to restart statd afterwards, which it's meant to
<slangasek> bug against upstart> agreed, please do :)
<SpamapS> http://paste.ubuntu.com/554975/
<slangasek> oh, I see
<slangasek> yes, confirmed here
<slangasek> no idea why
 * slangasek pokes a bit more
<SpamapS> http://paste.ubuntu.com/554976/
<SpamapS> there's the info level log from init
<slangasek> yep
<SpamapS> never gets the killed state
<slangasek> I think that needs reporting as an upstart bug
<SpamapS> yeah I'm looking at restart_action right now in trunk
<SpamapS> I think it just toggles, waits for a change, then toggles again, rather than waiting for stopped
<slangasek> portmap seems to be the only job I have on my system with a pre-stop command that one would likely restart, so I guess this escaped notice that way
<slangasek> fortunately the portmap maintainer scripts use stop + start instead
<SpamapS> score 1 for serendipity
<slangasek> also fortunately, we can't use the 'restart' command directly in maintainer scripts in general, because it doesn't DTRT regarding policy's definition of sensible behavior of not-yet-running jobs :)
<SpamapS> oh right I recall reading that thread on a bug report
<SpamapS> so does invoke-rc.d restart do stop/start ?
<slangasek> yes
<SpamapS> I wonder if this proves nasty upstream if we should change 'service' too
<slangasek> er... more precisely, it's /lib/init/upstart-job that does this; and I wonder if I'm just reading it wrong on a Sunday night, but this doesn't look terribly correct to me
<slangasek> oh, no, it's correct.  but it doesn't do stop/start :)
<slangasek> so this upstart bug *does* affect use of invoke-rc.d
<SpamapS> right, so the way restart happens it does job_change_goal(stop);job_change_goal(start);  ... running the pre-start causes upstart to return from job_change_goal
<slangasek> hee
<SpamapS> yeah the logic in job_change_state makes it spin until the job's state == the next desired state, not the exact (stop/waiting) state
<SpamapS> so actually its only by mistake that we even end up sending KILL to the process
<SpamapS> since the state progression is pre-stop->killed->waiting
<SpamapS> well killed->post-stop->waiting
<SpamapS> but pre-stop and post-stop are optional so I wonder if post-stop screws this up too
<slangasek> in happier news, I've just submitted a patch to Debian bug #577040
<ubottu> Debian bug 577040 in debhelper "dh_installinit: don't force upstart when both .init and .upstart exist." [Wishlist,Open] http://bugs.debian.org/577040
<slangasek> so that's one bit of the new policy done...
<SpamapS> hooray, maybe I can get the mongodb maintainer to accept our upstart script then. :)
<SpamapS> only affects pre-stop
<slangasek> preferably not until we also get lsb-base and lintian converted over. :)
<slangasek> (and the policy change accepted!)
<SpamapS> its what every kid hacking away on his slink box in 1999 dreamed of.. enacting policy change :)
<SpamapS> wow I had to check on it, but my guess at 1999 being when I installed slink appears to be accurate.
<slangasek> heh
<SpamapS> It was a happy, happy day. Followed by even more happiness when potato arrived. :)
<ebroder> slangasek: is there a link to the new policy i could see?
<slangasek> ebroder: Debian bug #591791
<ubottu> Debian bug 591791 in debian-policy "extend init.d policy to permit upstart jobs and describe their use" [Wishlist,Open] http://bugs.debian.org/591791
<ebroder> cool, thanks
<SpamapS> slangasek: fyi, opened bug 703800 against upstart
<ubottu> Launchpad bug 703800 in upstart (Ubuntu) "restart command fails to restart main process when pre-stop stanza exists" [Undecided,New] https://launchpad.net/bugs/703800
<slangasek> SpamapS: \o/
<SpamapS> I bet this also affects if something starts on / stops on stopping portmap
<SpamapS> hmm no .. just pre-stop interesting
<SpamapS> hmm.. looks like its specifically the way pre-stop is run...
<SpamapS> yes.. looks like if we're running a pre-stop it changes the goal to 'respawn' instead of leaving it at stop.
 * SpamapS tumbles further down the rabbit hole
<SpamapS> aha! and respawn from state pre stop changes teh goal back to start instead of stop which seems to be the intention
<dholbach> good morning
<ebroder> happy belated birthday, dholbach
<dholbach> thanks a lot ebroder!
<pitti> Good morning
<ev> @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: ev
<ev> morning, pitti
<amitk> ev: is it a known bug that the natty live-cds for mac (http://cdimage.ubuntu.com/daily-live/20110112/) don't show text in the installer
<amitk> ?
<amitk> ev: on macbook pros, that is
<ev> can you elaborate on what you mean by "don't show text"?
<ev> are you talking about isolinux or ubiquity or what?
<amitk> ev: This is a live cd image. The dialog boxes for the installer (ubiquity) are blank. Moving the mouse around shows that there are active areas and pressing enter seems to move to the next dialog. But I can't see any text in the boxes.
<ev> is this just in ubiquity or any GTK application?
<amitk> ev: Nothing on the desktop either
<amitk> can't see the ubuntu menus, icons, etc.
<ev> hm
<ev> Does a non-gtk application work? Say, xterm?
 * amitk starts downloading an iso not 'optimised' for macs
<amitk> ev: it is a bit hard to start apps when I can't see anything on the screen, just window borders and empty dialog boxes
<ev> amitk: you could always ctrl-alt-f2; DISPLAY=:0 xterm
<didrocks> good morning
<mvo> good morning didrocks
 * dholbach hugs ev
<didrocks> hey mvo! how was your travel back?
<mvo> didrocks: not too bad, I managed to find some sleep in the plane but had a hard time waking up this morning
<mvo> didrocks: and yours?
<didrocks> mvo: I switch my seat with a pregnant woman who wanted to be next to the toilets. Unfortunatly, my two new neighbours were moving a lot and I couldn't manage to sleep. So hard to wake up as well this morning :)
<christhecoolboy> hey all :)
<cjwatson> ari-tczew: perl> I don't care
<ari-tczew> cjwatson: ok. btw. system-tools-backends is ready.
<christhecoolboy> I have an idea for a program that would come part of ubuntu
<ari-tczew> christhecoolboy: do you want to write a new program or want to pack existing program?
<christhecoolboy> ari-tczew, to use an exsisting program/resource to create a new thing
<christhecoolboy> I could explain more if you want :)P
<christhecoolboy> *:)
<cjwatson> ari-tczew: yes, I saw the e-mail already
<christhecoolboy> hmm... Silence :(
<ari-tczew> christhecoolboy: I'd like to encourage you to contribute to Ubuntu development instead creating new project :)
<christhecoolboy> But its part of ubuntu
<christhecoolboy> to come as part of the OS
<christhecoolboy> ari-tczew^^
<ari-tczew> christhecoolboy: fixing bugs and packaging is also paty of the OS
<amitk> ev: I can see 'text' on non-gtk apps. I was able to launch xterm and get a shell
<christhecoolboy> my idea is a bigt one?
<ari-tczew> christhecoolboy: which idea?
<christhecoolboy> a program to be part of ubuntu
<christhecoolboy> so what I am doing is contributing to Ubuntu Development
<christhecoolboy> as it would be part of the OS
<christhecoolboy> and it could also possibily give the opportunity for ubuntu to be open to a new market
<ari-tczew> christhecoolboy: being a developer is very important part of the OS
<Laney> christhecoolboy: There's a channel for app developers: #ubuntu-app-devel :-)
<christhecoolboy> I was told to come here
<christhecoolboy> so I did, Laney
<Laney> by someone in that channel?
<christhecoolboy> by someone in #ayatana
<cjwatson> that was inappropriate of them, I'm afraid
<Laney> Well, it depends exactly what you want to do, but if you are proposing to develop a new application then the channel I suggested is the correct venue to discuss it.
<christhecoolboy> Laney,  but it uses an exsisting resource from ubuntu
<didrocks> christhecoolboy: evilish asked you to post on the ubuntu-devel-discuss mailing list, not to discuss on the #ubuntu-devel channel, isn't it? (or was it before I joined)
<christhecoolboy> there wasnt an email where he showed me
<cjwatson> we know, but if everyone who wanted to discuss building applications on Ubuntu came here, then we wouldn't have anywhere to discuss things that are already in Ubuntu
<christhecoolboy> so I entered here
<christhecoolboy> and it was before you were in
<christhecoolboy> njpatel
<ari-tczew> christhecoolboy: do you have an idea of program, though?
<christhecoolboy> yes
<ari-tczew> christhecoolboy:  what is it?
<Laney> ari-tczew: please, in the other channel
<christhecoolboy> ari-tczew,  a gaming platform called "Ubuntu Games Center" that uses unity to create a XBOX 360 style looks and allows for achievements, leaderboards and people to create their own games
<ari-tczew> sorry Laney
<Laney> np
<evilvish> didrocks: evilvish  , not evilish  ;p
<didrocks> evilvish: yeah, I noted that after :-)
<evilvish> just saying , not evilish , but fully evil :p
<ev> amitk: perhaps file a bug against gtk+2.0 or pango?
<christhecoolboy> ari-tczew, I say my idea
<christhecoolboy> and I dont get any responce? :(
<evilvish> !patience > christhecoolboy
<ubottu> christhecoolboy, please see my private message
<cjwatson> once you have developed your application, it might be appropriate to discuss its integration here
<christhecoolboy> cjwatson, but then that destroys the whole idea?
<cjwatson> I don't see why
<christhecoolboy> since I need to spread the word around and try and get help from some people
<christhecoolboy> or suggestions
<cjwatson> you can do that elsewhere, I'm sure
<cjwatson> this isn't a good place for it
<christhecoolboy> I was told to come here
<cjwatson> I know
<cjwatson> I'm sorry that you were given mistaken advice
<christhecoolboy> because "if its gonna be intergrated in to the os, #ubuntu-devel is the place to go, they develop stuff for ubuntu"
<cjwatson> the thing is that thousands of people are trying to develop one thing or another for Ubuntu; this is the central coordination channel, not a place for them all to try to gather support.  It would get pretty impractical
<christhecoolboy> ok, where do I go to try and get help or suggestions?
<cjwatson> mailing lists, blog about it, people already suggested #ubuntu-app-devel, etc. ...
<christhecoolboy> I dont wanna spread the word
<christhecoolboy> until I know I can get some help
<christhecoolboy> I cant do a whole project by myself
<christhecoolboy> I have only just started
<christhecoolboy> so I was told to "ask around"
<cjwatson> well, it's IRC, it's asynchronous, you shouldn't expect anything immediately anyway
<christhecoolboy> ok, someone told me to go to #ayatana because it involved unity, then they said to go to #ubuntu-desktop  because they maintain what goes in to ubuntu, then #ubuntu-devel, because they make and Intergrate much of Ubuntu, now #ubuntu-app-devel . where next?
<christhecoolboy> Sadly, thats 8 or so hours that just went in a endless loop
<cjwatson> you'll likely have to get something interesting-enough started before people really get interested, I expect
<christhecoolboy> but I need people to help
<christhecoolboy> since I cant do it all by myself
<cjwatson> mostly, people don't really jump in until there's something started
<cjwatson> otherwise they would have started it themselves :)
<christhecoolboy> I need the support
<christhecoolboy> I want some people who can help me code but work with me...
<cjwatson> the best way to attract such people is to have an interesting skeleton of a project that they can then send patches for
<christhecoolboy> I cant build the skeleton
<christhecoolboy> cause I dont know code
<cjwatson> most such people won't come to something without even a skeleton; they already have lots of things to do
<christhecoolboy> thats why I want someone to help me learn :(
<didrocks> christhecoolboy: looking at http://irclogs.ubuntu.com/2011/01/17/%23ayatana.html, njpatel told you first to go to #ubuntu-desktop, but then, he told you that "it might actually make more sense to email ubuntu-devel list, so people can think and respond". So his advice it correct, please consider it
<cjwatson> I think you may have to learn to program first, then
<cjwatson> which is rather more general than Ubuntu
<christhecoolboy> didrocks, I did that
<christhecoolboy> but I couldnt find an email on that link
<christhecoolboy> so I came here
<cjwatson> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
<evilvish> christhecoolboy: i gave you the link with the email id
<ari-tczew> cjwatson: a lot of developers keep the entry about Vcs-Bzr in debian/changelog. even dholbach and robert_ancell.
<didrocks> christhecoolboy: "11:34:09        evilvish | christhecoolboy: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss"
<cjwatson> however, better would be:
<cjwatson> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
<cjwatson> ari-tczew: nevertheless, it should be removed
<cjwatson> we should keep debian/changelog concise and useful
<dholbach> ari-tczew, ?
<dholbach> ari-tczew, I didn't do a merge myself for a long long time
<christhecoolboy> patel gave me: https://wiki.ubuntu.com/UbuntuDevelopment#Communication
<christhecoolboy> and that said about the IRC
<christhecoolboy> but I couldnt find an email address
<cjwatson> christhecoolboy: you've now been given an appropriate link several times
<christhecoolboy> yes, but I cant send the email until I have something set up
<ari-tczew> dholbach: I mean that you didn't have objections about this one in d/changelog.
<cjwatson> then the reality of the situation is that you'll probably need to learn to program enough to get something started, I'm afraid
<christhecoolboy> I'm not sure even what it would be coded in
<cjwatson> ari-tczew: I could just remove it myself of course, but I don't like editing things in other people's names
<ari-tczew> cjwatson: I'll send fix in 5 minutes.
<cjwatson> thank you
<dholbach> hey janimo
<janimo> hey dholbach
 * ogra_ jawns
<ari-tczew> cjwatson: reuploaded
<ricotz> Laney, hi, do you know bhavi, he grabbed the docky sync a few hours ago and still isn't finished?
<Laney> ricotz: his nickname is cdbs
<Laney> (I think)
<dholbach> Laney, cdbs is Bilal Akhtar
<Laney> oh ok, then I don't know, try the launchpad profile
<dholbach> Bhavani is usually bhavi
<Laney> someone changed their nick :P
<ricotz> hmm, havent seen him around here
<ricotz> i also want him to look at the libgcrypt11 merge
<ricotz> dholbach, when is he around usually?
<ari-tczew> bhavi on IRC is coolbhavi
<ari-tczew> but he doesn't use #ubuntu-devel, rather #ubuntu-motu
<ricotz> ari-tczew, ok, thanks
<ari-tczew> ricotz: what's the problem?
<dholbach> ricotz, Bhavani lives in India, but I don't know his usual in-IRC pattern
<ricotz> dholbach, alright
<ricotz> ari-tczew, the docky sync i mentioned above
<dholbach> ricotz, coolbhavi is in #ubuntu-motu now
<ari-tczew> ricotz: uploaded and built fine. https://launchpad.net/ubuntu/+source/docky/2.0.10-1
<ricotz> https://bugs.launchpad.net/ubuntu/+source/docky/+bug/703803
<ubottu> Ubuntu bug 703803 in docky (Ubuntu) "Sync docky 2.0.11-1 (universe) from Debian experimental (main)" [Wishlist,In progress]
<ricotz> dholbach, tx
<dholbach> anytime
<elif> Hi, I would like to use my own ftp server as repository for installation using preseed, what do I need to do to create my ``own mirror'' (without every .deb packages, just the ones I need) ?
<tjaalton> zul, slangasek: fix for bug 558793 pending, includes a debdiff with the patches backported. ok to upload to lucid-proposed?
<ubottu> Launchpad bug 558793 in samba (Ubuntu) "net ads dns register fails in 2008 R2 domain" [Medium,Triaged] https://launchpad.net/bugs/558793
<dmart> cjwatson: do you have a moment to answer a quick grub question?
<cjwatson> sure
<dmart> cjwatson: I have a maverick machine set up with a encrypted rootfs (using the alternate installer)
<dmart> cjwatson: What's the correct way to get into the grub boot menu on such a setup?
<cjwatson> does it just boot without showing the menu at the moment?
<dmart> cjwatson: Escape doesn't work ... currently pressing Ctrl+Alt+Delete from the rootfs password prompt is the only reliable way I see, but that looks unintentional (?)
<dmart> cjwatson: ^ yes
<cjwatson> hold shift
<dmart> cjwatson: aha, I tried Ctrl
<dmart> cjwatson: this seems different for every version of grub, but more likely that's just down to configurability + my inexperience ...
 * ogra grumbles about the archive still being out of sync for armel
 * dmart tries
<cjwatson> dmart: it changed from GRUB Legacy to GRUB 2; it hasn't otherwise changed
<dmart> cjwatson: looks like Shift works for me -- thanks
<cjwatson> dmart: this is because the PC BIOS architecture doesn't allow instantaneously checking whether Escape is pressed
<dmart> cjwatson: ^ maybe that's what confused me
<cjwatson> anyone know how to debug GNU linker scripts?  I have a build failure due to an ASSERT((foo == bar)) failing - it would be nice to have a way to ask it to print the values it believes foo and bar hold
<christhecoolboy> what is #ubuntu-women
<christhecoolboy> I wanna help ubuntu in some way
<christhecoolboy> and I read about "mentoring"
<ogra> christhecoolboy, why dont you ask in #ubuntu-women about #ubuntu-women ?
<christhecoolboy> I did
<christhecoolboy> I got no responce
<christhecoolboy> its like a ghost town lol
<ghostcube> o.O
<ogra> and what made you think it is appropriate to ask here instead of waiting for an answer ?
<christhecoolboy> cause I wanna know that I am not doing something that I shouldnt be
<ghostcube> i think ubuntu-woemon explains itself or?
<ghostcube> *women either
<christhecoolboy> ogra, ^^^
<ogra> christhecoolboy, this channel here isnt for support
<akshatj> christhecoolboy: this is the development channel, your action is considered spammy here
<christhecoolboy> where do I go?
<christhecoolboy> to chat with people
<akshatj> !offtopic > christhecoolboy
<ubottu> christhecoolboy, please see my private message
<aalex_laptop> hi
<aalex_laptop> What is the easiest way to package for two or more distroseries? I use git-buildpackage and CDBS.
<aalex_laptop> Do I need to use a different debian/changelog file for each distroseries?
<aalex_laptop> (lucid, maverick, natty)
<cjwatson> yes, you do
<aalex_laptop> Oh! sorry I was wrong. I can use the same control file.
<cjwatson> indeed (generally) - you just need a different version and upload target in debian/changelog
<aalex_laptop> cjwatson, should I use a whole different changelog file, or just add one entry in the changelog everytime I want to upload it
<cjwatson> just add an entry each time
<aalex_laptop> ok
<cjwatson> the value of a changelog is rather diminished if you keep emptying it :)
<aalex_laptop> yep
<aalex_laptop> And sometimes I might want to use different version of -dev libs in the control file... I might need many different control files.
<aalex_laptop> cjwatson, and then I should add ~maverick to the version of my package?
<aalex_laptop> let say 2.1.6~maverick ?
<cjwatson> that would be one approach which would work, yes
<bdrung> pitti: around?
<cjwatson> needing different versions of development libraries for different releases is rare.  that's usually a function of the source code you're uploading, not a function of where you're uploading it to.
<pitti> bdrung: hello; I am, just not very IRC-attentive today, as I'm on a sprint this week
<bdrung> pitti: i am waiting for your response to bug #701282
<ubottu> Launchpad bug 701282 in mpd (Ubuntu Maverick) "MPD lacks Mp3/LAME support in Ubuntu 10.10" [Medium,Triaged] https://launchpad.net/bugs/701282
<bdrung> the feature vs bug discussion
<pitti> bdrung: ah, so I guess the "sin" was to allow that other SRU you were referring to
<pitti> bdrung: as I said, it's not covered by the policy, but if you are sure that enabling this won't/can't cause regressions for other functionality and formats, I'm not too concerned about it
<bdrung> pitti: enabling one format shouldn't cause any regression (but i can't swear)
<RoAkSoAx>  /win 5
<bdrung> pitti: Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
<pitti> RoAkSoAx:  /lose 10
<pitti> bdrung: right, but it's not "obvious" that e. g. the new plugin won't cover formats which previously were handled by other formats, etc.
<pitti> bdrung: it's not very likely, but we should test it properly
<bdrung> pitti: backporting instead of a sru would pull a newer version.
<bdrung> pitti: for testing it we have -proposed
<pitti> ok
<RoAkSoAx> pitti: lol xD
<om26er> ev, are you available?
<ev> om26er: indeed I am
<om26er> ev, i have a branch for empathy but it seems there have been another upload to natty for empathy so letme merge with trunk and I'll be back
<ev> okay
<om26er> ev, https://code.launchpad.net/~om26er/ubuntu/natty/empathy/empathy-fix-666288-2/+merge/46485
<aalex_laptop> cjwatson, 2.6.1-1~maverick ?
<cjwatson> aalex_laptop: sorry?
<aalex_laptop> cjwatson, oh sorry. Would that be a good version name for a package for Maverick?  (that's only for a PPA)
<cjwatson> that's a reasonable version number for a backport of a package whose main branch has version number 2.6.1-1
<aalex_laptop> main branch?
<cjwatson> though I'd use ...~maverick1 personally, or maybe ...~ubuntu10.10.1
<cjwatson> natty, at the moment
<micahg> for PPAs I usually do ~distro~ppa1 to not interfere with official backports
<aalex_laptop> ok, so it would be better to use 2.6.1~maverick1
<cjwatson> you should look up what the different components of version numbers mean and work from that
<aalex_laptop> any wiki page about that?
<cjwatson> the Debian policy manual
<cjwatson> (not a wiki)
<aalex_laptop> well, there are tilde in the Debian policy?
<micahg> aalex_laptop: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-controlfields.html#s-f-Version
<micahg> oops
<cjwatson> the tilde is a version number element defined by Debian policy, yes.
<cjwatson> it has a specific meaning which you can look up.
<micahg> here's the link to Debian: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
<cjwatson> doesn't really matter which you look at in this case
<ogra> on a sidenote there is also a package for local installation of the docs :)
<om26er> jdstrand, hey! was the upload to maverick-proposed rejected for this branch https://code.launchpad.net/~om26er/ubuntu/maverick/rhythmbox/rhythmbox-bugfixes-maverick/+merge/43558 there doesn't seem to be anything in Unapproved queue for maverick
<ari-tczew> cjwatson: python-django from unstable is FTBFS.
<ari-tczew> jdstrand: ^^
<ebroder> amitk: could you subscribe me to any bugs you file about that blank dialog thing (i'm broder on lp)? i've seen it once before on a maverick+fglrx machine, but couldn't reproduce it anywhere else so didn't spend too much time worrying about it
<quadrispro> doko, I'm working on bug #704027
<ubottu> Launchpad bug 704027 in gavl (Ubuntu) "gavl 1.2.0-1 FTBFS on armel" [Medium,Confirmed] https://launchpad.net/bugs/704027
<quadrispro> doko, does PPAs provide builds for armel?
<quadrispro> s/does/do/
<quadrispro> mmh maybe I've found the answer
<aalex_laptop> Hmm, since I upgraded to maverick (not a fresh install), do I need to add "natty" in the list of possible version for pbuilder somewhere?
<aalex_laptop> $ sudo DIST=natty pbuilder create >>> Unknown distribution: natty
<tumbleweed> aalex_laptop: Your pbuilderrc
<aalex_laptop> tumbleweed, ah! thanks. Long time I hadn't modified that
<amitk> ebroder: sure, I haven't filed a bug yet since I can't file from the affected macbook (since I can't see anything on the screen). ubuntu-bug --save pango.log pango isn't being very helpful. Any idea what info I should collect for pango/gtk+2.0 bugs?
<ev> @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:
<ebroder> amitk: not really. the machine i ran into this on was running a primarily non-gtk environment, so it wasn't that important to get fixed
<aalex_laptop> tumbleweed, setting up pbuilder for natty failed: http://paste.debian.net/104878/
<tumbleweed> aalex_laptop: that paste excludes the actual error :)
<slangasek> tjaalton: should be fixed for natty before SRUing to lucid, at least
<dholbach> Straw Poll: what would you think about making the patch pilot schedule a public Google Calendar instead of the wiki? It'd be a bit more work for me to set it up, but it could send out reminders
<nigelb> +1
<ogra> +++++++ 11111 one one !!!
<seb128> hey dholbach, how are you?
<dholbach> seb128, good - how are you?
<seb128> rather fine as well thanks
<seb128> gcalendar -> seems a nice idea, would be easier to handle than the wiki
<dholbach> it's more clicking for me and not just one wiki update, but I can see the advantages
<aalex_laptop> tumbleweed, W: Couldn't download package procps ?
<tumbleweed> aalex_laptop: out of sync mirror?
<aalex_laptop> tumbleweed, sudo DIST=natty pbuilder update ?
<tumbleweed> aalex_laptop: no, edit your pbuilderrc to point to another mirror, until your one is behaving again
<aalex_laptop> tumbleweed, I am not sure to know how to do that. Here is my .pbuilderrc (on maverick) http://paste.debian.net/104884/
<dholbach> can somebody give me a good example of a clean packaging for a project using cmake?
<aalex_laptop> mirrors.kernel.org is my current mirror
<aalex_laptop> I could use the mirror I use usually - it's going to be faster anyways
<aalex_laptop> ok
<cjwatson> dholbach: there's a dh buildsystem for cmake - does debhelper rules.tiny not work?
<ari-tczew> dholbach: clementine
<dholbach> cjwatson, I don't know - I was just trying to help out somebody who asked for help with it
<cjwatson> you'd need Build-Depends: debhelper (>= 7.3.0)
<cjwatson> personally I'd use rules.tiny and only add things if that didn't work. :)
<dholbach> thanks cjwatson
<dholbach> thanks ari-tczew
<tumbleweed> aalex_laptop: hmm, mirrors.kernel.org is normally pretty good, and doesn't look out of sync
<aalex_laptop> hmm
<aalex_laptop> tumbleweed, it worked with ubuntu.mirrors.iweb.ca - though I had to edit the file to remove the /ubuntu/ suffix
<aalex_laptop> weird
<tumbleweed> aah, whoops, I was looking at the EU cluster
<dholbach> seb128, ogra: got the mail?
<seb128> dholbach, yes
<dholbach> thanks
<ogra> yup
<seb128> dholbach, thanks ;-)!
<ogra> awesome !
<apw> are we aware that nm-applet is core-dumping on suspend/resume ?
<smoser> james_w`, is it possible to manually kick lp:ubuntu/lucid-proposed/cloud-init to get updated ?
<james_w`> smoser, we're investigating an operational issue currently which is preventing any imports
<smoser> james_w`, ok.  thats fine. so is "bother james_w because he surely has nothing else to do" the correct way to deal with this ?
<james_w`> smoser, you can file a bug on the 'udd' project
<smoser> ok.
<smoser> do you want me to do that now ? or just in the fugure
<james_w`> smoser, please file a bug, I don't want to forget your package when we fix the issue
<smoser> am i right that the thing that ends up getting auto-imported is lp:ubuntu/lucid-proposed/<src_package> rather than lp:ubuntu/lucid-updates/<src_package>
<smoser> is that right ?
<smoser> or, maybe both are supposed to be eventually.
<apw> cjwatson, any idea where i might find someone with avahi smarts ... seems its gotten worse to the point its not working at all now (in natty)
<smoser> james_w`, bug 704079
<ubottu> Launchpad bug 704079 in Ubuntu Distributed Development "cloud-init ubuntu/lucid-proposed branch not updated" [Undecided,New] https://launchpad.net/bugs/704079
<james_w`> smoser, thanks
<smoser> see question above
<james_w`> smoser, it will import to wherever the packages end up
<james_w`> smoser, so if the package is just in -proposed then it will only go there
<james_w`> if the package is in -updates too then it will go in both branches
<smoser> ok. thats what i woudl have thought, but i thought i'd seen other places with no -updates, but a -proposed even though package got through
<smoser> if i see such things i'll open bugs in the future.
<cjwatson> apw: not sure, in my head it's a desktop thing
<cjwatson> mbiebl maybe
<apw> cjwatson, thanks ... i guess i'll try and debug it then
<tjaalton> slangasek: ok. and further testing shows that it's not 100% fixed after all :/
<tjaalton> doesn't complain anymore, but the reverse isn't updated (and still complains on domain join)
<lamont> so how in the &*%)*%*&^(B  do I force X to override the cursor grab that it randomly gives to some unsuspecting window?
<cjwatson> kenvandine,tedg: can you explain why libindicator2 Breaks: libindicator1?  This is ... unusual for a shared library SONAME bump
<tedg> cjwatson, Yes, it was so that we wouldn't get a partial upgrade.  So that unity and the indicators would all upgrade at once.
<cjwatson> tedg: the Breaks should have been from unity to libindicator1 then, surely
<cjwatson> that would make apt's life easier
<tedg> cjwatson, Then we would have to version all the indicators.  i.e. have a indicator-session1 and indicator-session2 so they could be installed at the same time.
<cjwatson> hmm.  how horrible.
<cjwatson> well, if natty hadn't been left uninstallable by this for days, I might not have got round to asking annoying questions like this ... ;-)
<tedg> Heh, you can rest assured that wasn't on purpose :)
<cjwatson> is there a timeline for that getting fixed?
<tedg> I think it is now, no?
<cjwatson> ah, maybe so, I'd been expecting that to involve a unity-place-applications upload
<cjwatson> ok, let's see if tomorrow's live CD builds manage to refrain from sending me lots of mail ...
<tedg> I think it should.  I don't think that unity-place-applications is needed right now, though users of Maverick may still have it installed.
<RAOF> Hm.  Black-screen instead of plymouth âenter your encryption passphraseâ is not a happy failure mode.
<andreserl> pitti: where you interested in the polling from /dev/input for PowerNap right?
<apw> RAOF, at least your disk isn't mounted
<RAOF> apw: True.
<apw> RAOF, is that one helped by gfxpayload=text etc ?
<RAOF> Yes, I think it is.
<apw> well that we are interested in
<apw> RAOF, if you could confirm that we'd be grateful
<apw> can you figure out what mode it is selecting ?
<apw> cirtianly get a buggy filed for it if so
 * apw wonders if you have the same issue as marjo
<apw> #GRUB_GFXMODE=640x480
<apw> setting that to like 800x600 might help as a diagnostic tool
<RAOF> It appears to be selecting the correct mode, just entirely blank.  Switching to a different VT doesn't appear to modeswitch, and appears to be in the right thingy.
<apw> hrm, yuo have VTs with real text (small font) on them ?
<RAOF> Interestingly, the grub *menu* is displayed.  Apparently it's not trying to select my broken 1440x900x32 VBE mode.
<RAOF> Yes, I do.
<RAOF> Real honest to goodness 1440x900 VTs.
<apw> then that isn't a graphics issue i'd say
<RAOF> Yeah, it's probably plymouth.
<apw> oh when you go back to the VT-7 is there something thhere?
<apw> OH poop
<RAOF> Yup, text.
<apw> so yeah if plymouth exits before you answer cause of the mode switch
<apw> you might never see the prompt on either side
<apw> hrm, not ideal!
<RAOF> One could say that!
<apw> that is likely a degenerate case of plymouth not coping with the mode switch, which cjwatson is working on
<apw> i would try the =text thingy, but i suspect cause of plymouth you won't be any better off
<apw> booting without splash might let you at least get to the prompt for password
<RAOF> Yeah, it does.
<apw> so ... i think that confirms its another (worse outcome case) of the "plymouth tends to die when the mode switch occurs" bug
<apw> master watson i think was working on that
<RAOF> Then I got to find out that the partitioner of the alternate CD (and *only* the partitioner) doesn't respect the keymap you set at the start.  Trying to reverse-map my passphrase from qwertyâdvorak was fun!
<RAOF> Yeah, =text doesn't appear to help.
 * cjwatson cannot imagine why only the partitioner would have keymap trouble
<RAOF> Neither can I; I'll file a bug, which apport should be able to grab the relevant logs for?
<cjwatson> RAOF: goodness knows whether it'll be able to figure out how to file a bug against partman-crypto
<cjwatson> RAOF: you could try against debian-installer, and it should make some kind of reasonable attempt then
<RAOF> I'll do so.
<RAOF> cjwatson: If apport doesn't have any idea, the logs in /var/log/installer are the relevant goodies, right?
<cjwatson> yeah
<cjwatson> syslog and partma
<cjwatson> n
<cjwatson> the others are normally boring
<ari-tczew> cjwatson: thanks for sponsoring system-tools-backends
<cjwatson> np
<RAOF> apw: Hm.  Actually my boot problem was that plymouth hadn't been correctly installed by the installer; now that it is, I actually have a prompt.
<cjwatson> that's odd too
<cjwatson> in what way was it incorrectly installed?
<RAOF> I think the archive the installer was based on was broken; it failed to install a bunch of packages due to dependency conflicts.\
<RAOF> Plymouth must have been a victim of that.
<cjwatson> did it report failure at the time?
<RAOF> Yes.
#ubuntu-devel 2011-01-18
 * ebroder grumbles
<ebroder> has dbus, like, forgotten how to support eavesdropping at some point?
<ebroder> oh, no. my match expression to dbus-monitor was just wrong
<ebroder> hmm...i just saw a zombie process parented to init that wasn't getting reaped. that seems unexpected, no?
<ebroder> (i'm not sure yet whether i can reproduce it)
<happygilmoregent> hey room
<happygilmoregent> anyone a developer for ubuntu?
<micahg> happygilmoregent: indeed
<happygilmoregent> why didd you chhoose to start in runlevel 2?
 * micahg didn't choose it :)
<happygilmoregent> what do you mean?
<happygilmoregent> why does ubuntu start in runlevel two?
<RAOF> Because runlevels are, roughly speaking, an entirely obsolete legacy idiom?
<kees> happygilmoregent: that's a default ubuntu inherited from debian
<happygilmoregent> ok i run gentoo and it does graphical login in runlevel 5
<ebroder> different distributions interpret the different runlevels differently
<ebroder> debian doesn't distinguish between graphical and non-graphical boots by changing runlevels
<ebroder> so ubuntu doesn't either
<jon8> Hey guys, i completely understand that this is developer's channel but many people in #ubuntu can provide me with a solid answer.
<jon8> Is there anything other than, https://lists.ubuntu.com/mailman/listinfo/maverick-changes -- that can provide a person with some sort of interface as to when new packages come out and why? Almost like an RSS Feed of sorts if you think about it.
<mase_wk> jon8: you mean other than just using apt it's self ?
<jon8> yes
<ebroder> jon8: googling for [natty-changes rss] gets me http://ubuntuforums.org/showthread.php?t=1596437
<jon8> i do sudo apt-get update/upgrade atleast once a day
<jon8> sorry, i should of speficied maverick
<mase_wk> jon8: what are you trying to achieve?
<ebroder> jon8: i'd encourage you to look at the link i just sent and make the obvious modification
<jon8> yah :P
<jon8> mase_wk nothing specific really.. just a way to keep up with updates eaiser and to see whats being made available
<jon8> was just a general question at the end of it tbh.. and no one in #ubuntu really had an answer when i asked earlier today
<jon8> but http://feeds.ubuntu-nl.org/MaverickChanges is pretty much exactly what i was looking for, thank you.
<jon8> I'll take off now as I dont belong here :)
<jon8> Thanks for the awesome OS you guys work so hard on!
<dholbach> good morning
<pitti> Good morning
<pitti> andreserl: I am; but why are you polling it? shouldn't select() work just fine on this?
<ebroder> Oh man. I bet the CD space reclamation session at UDS-O will be fun
<apw> if i pull a bzr branch for a package and it only contains the debian directory, is there a magic incantion to instantiate the source i should be aware of, or am i on my own
<TeTeT> apw: try ./debian/rules get-current-source
<pitti> apw: uusally "bzr bd-do" or "bzr bd -S" or "bzr bd -- -b", depending on what you want to do
<pitti> apw: the second/third build source/binaries, the first throws you into a shell with the upacked source, lets you hack on it, and if you exit with 0, it copies back the changes to debian/ to the original tree
<pitti> apw: that's from bzr-builddeb
<TeTeT> pitti: nice, never knew about bd-do
<apw> pitti i want to apply a patch to the package, so i guess i want the former
<pitti> TeTeT, apw: documentation (shocking!): https://wiki.ubuntu.com/DesktopTeam/Bzr
<TeTeT> he he
<pitti> apw: yes, there you can try it out, and if it works, exit 0
<apw> pitti, thanks will give it a bash
<pitti> apw: bd is actually quite clever with that; if the orig.tar.gz is not there already, it first tries apt-get source, then debian/watch, then uscan, and finally get-orig-source
<pitti> i. e. if there is any automatic way to get the source at all, it should get it
<apw> pitti, ahh yes, it has a watch cool
<apw> can someone tell me how to unlink a bzr branch which is in 'svn mode' and trying to push my changes on commit?
<pitti> apw: try "bzr unbind"?
 * ogra sighs, webkit still uninstallable ?
<pitti> ogra: today's CDs finaly built, so it should work now
<ogra> pitti, not for arm
 * ogra wonders why he  doesnt get any biold failure mails for x86 anymore
<apw> pitti, thats the ticket, thanks
<ogra> oh, because i only get mails for ubuntu-netbook ...
<apw> so i have found a bug in avahi, triggered by kernel changes to fix a bug, now i've pushed that change to the avahi upstream, would we normally apply things like that in ubuntu as well?
<apw> given it has to get released by them, then picked up by debian, and then sync'd to ubuntu
<apw> (the fix to the kernel won't hit ubuntu for a few days yet)
<sladen> apw: is it a OMG critical/data loss/unbootable machines/BIOS bricker?
<apw> sladen, it prevents avahi working in such a way that remote logins no longer seem to work
<sladen> apw: main thing is to ensure that it's tracked, so you can keep tabs on its progress via upstream and Debian and knowingly know when it actually hits the distro kernal packagse
<sladen> apw: what type of remote logins?  10.04 LTS server SSH logins?
<apw> sladen, i mean ssh logins, the issue only affects natty at the moment
<sladen> apw: does it have a reasonable workaround, eg. typing an IP address in directly?
<apw> sladen, nope, no work around that i've found other than shutting down avahi on the machine itself
<apw> sladen, ie none that helps if you are remote
<sladen> apw: what's the bug number?
<cjwatson> it's not unreasonable to backport a change to Ubuntu ahead of the usual trickle-down, if it's needed
<apw> bug #704372
<ubottu> Launchpad bug 704372 in avahi (Ubuntu) "avahi-daemon hangs 'starting up' with v2.6.38 based kernels" [Undecided,New] https://launchpad.net/bugs/704372
<apw> sladen, as i say, its something that won't hit until i upload the first 2.6.38 based kernel, but thats not likely to be more than a week out
<Laney> yeah, avahi isn't currently in sync anyway
<Laney> I wouldn't say it's a big deal to backport the patch
<apw> i am only seeing it because my dogfood is extremly warm
<Laney> you might consider making Debian aware though if it's going to affect them
<ogra> Riddell, around ?
<apw> Laney, good point, will mention it over there ->
<sladen> apw: is there scope to upload the avahi package first and set the appropriate Depends:/Breaks: ?
<sladen> apw: which should hopefully mean that regardless of how warm or creative people's dogfood is they can never actually manage to get themselves into a corner
<cjwatson> relationships against kernel packages never work very well due to the constantly shifting package names
<apw> sladen, cirtainly there isn't any difficulty waiting till the avahi changes are in the archive
<apw> cjwatson, indeed ...
<apw> for now i will wait and see how quick upstream reacts to the report
<apw> i have the changes for ubuntu in a branch on that bug, should we need to apply it locally first
<sladen> apw: I'd defer to cjwatson for the best solution.  My personal hunch would be to send it upstream (which you've done), wait a couple of days and if it gets to the stage of knowing that the kernel upload needs to be done, apply the avahi fix to natty (which you've got in the branch) and after that has cleared, then upload the kernel update
<apw> sladen, sounds like a reasonable plan to me
<sladen> apw: the bigger stress is knowing that if the kernel gets backported to 10.04/10.10 to upload avahi to those first too (if those versions are similiarly afflicted)
<apw> sladen, oh crap, good point, lts backports ... bah
<apw> will add that to the checklist
<apw> wh
<apw> which i will go and invent
<lifeless> pitti: hi
<lifeless> pitti: looks like some retracer service is still using edge
<amitk> how often is the NEW queue processed?
<cjwatson> amitk: a few times a week to varying depths
<andreserl> pitti: howdy!! To tell you the truth I didn't write the Monitor, someone contribute it. However, I simplified/integrated it with PowerNap. I'll make it available in a bit for you to take a look at it
<pitti> lifeless: hi; yes, that's possible, I don't update them that often
<micahg> pitti: good morning, I was wondering, should I worry about changing from a native to a non-native package for an SRU if it's more appropriate?
<pitti> micahg: I wouldn't do it; it shouldn't help to fix a real problem for the user, and might just cause confusion
<micahg> pitti: ok, I'll fix it in natty though, I need to update the thunderbird translations for the lucid point release
<pitti> micahg: that sounds good, thank you
<andreserl> pitti: http://bazaar.launchpad.net/~andreserl/powernap/monitors/view/head:/powernap/monitors/InputMonitor.py
<pitti> andreserl: ah, that looks fine
<andreserl> pitti: awesome them. Should be integrating them completely with PowerNap within this week
<mdeslaur> Is a broken messaging indicator a known issue? Ie: I click on it and nothing happens? (other indicators work)
<Tanguy> Hello.
<mdeslaur> tedg: ^
<Tanguy> I am a Debian Maintainer, and I am planning to maintain the package libasyncns on Debian, which has been quite abandonned the last years.
<Tanguy> I have just seen that it has been updated in Ubuntu.
<Tanguy> The Maintainer fields names âUbuntu Developersâ.
<Tanguy> Is there something I should do to coordinate with them to maintain it in Debian?
<ogra> Tanguy, if y package was eitrher manually merged or touched in any other way in ubuntu, the maintainer field is rewritten
<ogra> best is to check the changelog in ubuntu
<Tanguy> ogra: This is what I did.
<Tanguy> Ubuntu currently has a fork of the Debian package.
<bdmurray> doko_: bug 504198 seems to have regressed for me
<ogra> a fork ?
<ubottu> Launchpad bug 504198 in eglibc (Ubuntu Lucid) "locale support broken on upgrade to latest eglibc" [Critical,Fix released] https://launchpad.net/bugs/504198
<Laney> If there are no changes in Ubuntu that aren't in Debian (or if they can be dropped) then the package can be synced
<ogra> right
<tedg> mdeslaur, If you're talking about anything with webkit, probably.  It seems like everything is segfaulting for me right now (liferea/gwibber/etc)
<Tanguy> ogra: Well, I mean, it has been modified, that makes it a kind of forked development.
<ogra> we usually dont fork packages
<cjwatson> "branch" :)
<ogra> there might be ubuntu patches on top indeed
<mdeslaur> tedg: the menu just doesn't draw at all, nothing
<Tanguy> Well, this patch is: update from oooold version 0.3 to the last version 0.8.
<ogra> yeah, branch + ubuntu patches is possible, the core should still be debian
<ogra> awww, thats indeed a big patch
<Tanguy> It is not maintained as a patch.
<tedg> mdeslaur, Uhm, that's odd.  Do you have any menus?  Sometimes they end up getting stacked behind the desktop.
<Tanguy> This is why I am speaking of a fork.
<cjwatson> if a new version of the package in Debian can be shown to be a superset of what we currently have in Ubuntu, then it's fairly straightforward for us to go back to just copying the package from Debian verbatim
<cjwatson> fork/branch terminology notwithstanding
<Tanguy> Yes, sure, this is what I would like to see. :-)
<cjwatson> https://wiki.ubuntu.com/SyncRequestProcess
<ogra> yeah, just make 0.8 available in debian
<mdeslaur> tedg: this is with classic desktop. Indicator sound and the network manager indicators are working fine
<Tanguy> cjwatson: Does that fact that the package has been forked affect the sync process?
<cjwatson> Tanguy: it just means that somebody has to assess whether any of the Ubuntu changes are still needed; not otherwise
<mdeslaur> tedg: the message indicator, when clicked, draws the decorations around the icon as if it's displaying the menu, but no menu gets drawn underneath
<cjwatson> Tanguy: oh, since it's a new upstream in Ubuntu, the .orig.tar.gz will need to match between Debian and Ubuntu
<Tanguy> It will. :-)
<cjwatson> hopefully it's just a copy of the upstream tarball, but I haven't checked
<ogra> if it will, its likely very trivial
<Tanguy> (unless it has been repacked in Ubuntu, but it hsould not be the case)
<tedg> mdeslaur, Hmm.  Classic desktop ==  Legacy old-crufty-stick-in-the-mud-developer interface?  ;)
<cjwatson> judging from the modification timestamps, it hasn't
<tedg> mdeslaur, Is the indicator-messages-service running?
<mdeslaur> tedg: classic desktop = waiting for unity workspace support to not suck
 * cjwatson just loves being pejoratively labelled ...
<cjwatson> (tedg)
<mdeslaur> tedg: yes, it's running
<Tanguy> So, when I update the package in Debian, I should file a bug report asking for a sync, right?
<cjwatson> Tanguy: yep
<Tanguy> Thanks.
<cjwatson> for best results, use 'requestsync --lp libasyncns natty'
<cjwatson> (ubuntu-dev-tools)
<cjwatson> that writes the bug report in a form such that our automated tools can pick it up easily
<mdeslaur> tedg: I'll switch to unity in a few minutes, to see if it's working there
<tedg> mdeslaur, Hmm, yeah.  I'm not sure what's up then.  You can try Unity, but it really shouldn't be different...
<tedg> mdeslaur, Basically, for the menus, the same code runs.
<mdeslaur> weird
 * mdeslaur -> log out, log in
<mdeslaur> tedg: all menus are broken in unity
<tedg> mdeslaur, you can try to see if you get a menu with this: /usr/lib/libdbusmenu/dbusmenu-dumper -d com.canonical.indicator.messages -o /com/canonical/indicator/messages/menu
<tedg> mdeslaur, Uhg
<mdeslaur> tedg: I don't seem to have dbusmenu-dumper
<hallyn> oh, yeah - and 'unity --reset' is no longer  an option bc unity disappeared
<tedg> mdeslaur, http://apt.ubuntu.com/p/libdbusmenu-tools
<mdeslaur> tedg: http://paste.ubuntu.com/555436/
<tedg> mdeslaur, Uhm... that seems completely reasonable...
<mdeslaur> tedg: hmm...clicking on the unity launcher makes it disappear
<mdeslaur> tedg: and when I click the desktop again, it comes back
<didrocks> mdeslaur: sounds like a stacking issue, does it still react when you click on it (when disappeared)?
<mdeslaur> didrocks: I made it disappear like 10 times in a row, and then the top panel disappeared, reappeared and now the launcher is behaving properly
<didrocks> mdeslaur: probably the stacking then
<mdeslaur> oh! and I now have menus!
<mdeslaur> oh, except menus are drawing underneath all the other windows
<mdeslaur> didrocks: yeah, stacking issue :(
<didrocks> mdeslaur: known issue then :(
 * mdeslaur goes back to the old-crufty-stick-in-the-mud-developer interface
<tedg> mdeslaur, heh ;)
<Riddell> cjwatson: I trained up didrocks in archive admin tasks last week, can you add him to ~ubuntu-archive?
<cjwatson> Riddell: excellent!  done, please file an RT for the shell access bit.  is he going to take an archive day, or do any particular tasks?
<didrocks> cjwatson: Riddell: thanks! on the archive day, I'll do random stuff first (still a little busy with unity this cycle), but I plan to take an archive day next cycle
 * cjwatson nods
<kklimonda> jdstrand: any idea why would python-django fail on buildds out of the blue? It still builds in maverick ppa, and it did build before maverick release. Build-Depending on locales-all | locale-pack-en-base seems to be the only way to do what I want, dropping it would only introduce another delta.
<kklimonda> (some tests are expecting unicode locales to be set, and they fail otherwise)
<cjwatson> you could generate the locale at build time instead
<cjwatson> (localedef)
<cjwatson> see e.g. lintian's postinst
<kklimonda> cjwatson: where were you when I was asking people for advice? :)
<cjwatson> I know you wouldn't want to do it in the postinst, but the command-line invocation would be about the same
<cjwatson> heh
<kklimonda> cjwatson: thanks for the idea, I'll check lintian and see if that helps
<nigelb> 7
<nigelb> gah, sorry
<pitti> bryceh, RAOF: FYI, xorg-edgers holding up well for three days already, including about 10 suspend/resume cycles (I basically didn't reboot again after the upgrade on Sunday)
<bryceh> pitti, excellent
<bryceh> pitti, yeah it's been running solidly on my netbook as well
<bryceh> pitti, there's still some bits and pieces needing attention that have turned up, but I expect we're on schedule to see it in main within a week or so
<SpamapS> anybody else have a problem on natty where gdm doesn't work on bootup? I have to switch to tty1 and restart it.
<SpamapS> I get a blank screen and I'm clearly in X (have to do ctrl-alt-f1)
<SpamapS> seems like maybe plymouth doesn't deactivate properly or something
<cjwatson> SpamapS: does anything in https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard ring a bell?
<cjwatson> try each of the two workarounds in the top section, preferably individually (those go in /etc/default/grub, and run update-grub after each)
<SpamapS> cjwatson: will try them out shortly, thanks. :)
<bjf> just installed Alpha 1, then a dist-upgrade, then a reboot and am sitting at a purple screen, can't switch to tty1
<davmor2> bjf: is it just dark purple?
<davmor2> bjf: as in it isn't the desktop background?
<bjf> davidm, correct, it should be the screen with the logo and the dots under it
<davmor2> bjf: does your caps lock key flash?
<bjf> davidm, yes, flashing right now
<davmor2> bjf: If so welcome to the wonderful world of kernel panic
<davmor2> bjf: for some reason that isn't easily reproducible on my system I get it,  just power off give it a few seconds and switch back on, you'll be greeted by the grub screen select the top entry and away you go
<bjf> davmor2, if i hold the left shift to get into grub, i get screen corruption (after powering down and back up)
<bjf> davmor2, ie. the grub menu is corrupted (visually)
<davmor2> bjf: you should need to press any key it should just go to it after a kernel panic
<cjwatson> bjf: when it's corrupted, move the cursor down/up so that it doesn't time out
<cjwatson> bjf: then press c
<cjwatson> bjf: then type 'terminal_output console' and press enter.  does that get you a prompt?
<cjwatson> (yes, you have to type this blind)
<bjf> cjwatson, grub>
<cjwatson> bjf: type 'videoinfo' - what does it say the EDID preferred mode is?  (should be near the end)
<bjf> cjwatson, dont see it, "Adapter 'VGA Video Driver': No info available"
<cjwatson> try 'set pager=1' before 'videoinfo', and page through the output
<bjf> cjwatson, my bad, EDID version: 1.3 Preferred mode: 1440x900
<cjwatson> thinkpad?
<bjf> cjwatson, thinkpad x301
<cjwatson> you have the sixth entry under Problems in https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard
<cjwatson> workaround:
<cjwatson> set gfxmode=1440x900
<cjwatson> er, sorry
<cjwatson> set gfxmode=1440x900x16
<cjwatson> terminal_output gfxterm
<cjwatson> background_color 44,0,30
<cjwatson> then press escape and you'll be back in the menu
<cjwatson> then try booting
<bjf> cjwatson, thanks, will give it a go
<cjwatson> this is a BIOS bug - the X VESA driver suffers from it in pretty much exactly the same way (according to RAOF's tests).  I'm hoping to think of a workaround that doesn't suck
<cjwatson> you can make the above sticky by editing /etc/default/grub and putting 'GRUB_GFXMODE=1440x900x16' there, then 'sudo update-grub'
<bjf> cjwatson, worked so far
<bjf> cjwatson, however now it looks like i'm still getting a kernel panic, cursor in upper left of screen and flashing capslk key
<cjwatson> OK, try the above but with 'set linux_gfx_mode=text' as well
<bjf> cjwatson, will do
<cjwatson> we didn't see the kernel panic on the laptops with this problem that we tested at the sprint
<cjwatson> apw: ^- FWIW, this may be straying into your domain
<davmor2> cjwatson: I've had them with this amilo-li-2727 on and off but not predictably but only on restarts
<apw> cjwatson, /me reads
<cjwatson> davmor2: only on restarts as opposed to ...?
<davmor2> cjwatson: I don't get it if I halt the system, and power on from cold,  only on restarts
<cjwatson> davmor2: and you're seeing specifically the display corruption when trying to display the grub menu?
<davmor2> no I don't get that bit nice clear grub screen
<cjwatson> (the distinction between grub and the kernel and X is vitally important here)
<davmor2> I just get the kernel panic
<apw> bjf, so does it boot ok without with linux_gfxmode=text and without splash on the kernle command line ?
<cjwatson> davmor2: have you seen it since upgrading to linux 2.6.37-8.20?
<cjwatson> (linux_gfxmode doesn't exist FWIW)
<bjf> apw, no, same result
<apw> hrmphf
<bjf> indeed
<davmor2> cjwatson: I'm currently on 2.6.37-12-generic
<cjwatson> linux_gfx_mode=text + no quiet + no splash should at least get you a text panic ...
<apw> bjf what changed to get you here ?  upgrade to natty
<cjwatson> actually, rather than 'set linux_gfx_mode=text', it might be worth going into the grub menu editor (same screen as where you remove quiet and splash) and changing 'set gfxpayload=$linux_gfx_mode' to 'set gfxpayload=text'
<bjf> apw, yes, I re-installed natty this a.m. (alpha 1) and then did a dist-upgrade to get caught up, that gave me this result
<cjwatson> just in case I got my logic wrong there
<bjf> cjwatson, apw, did as last suggest and same result
<cjwatson> could you repeat exactly what you did just so that we're on the same page?
<cjwatson> this is so much harder when not in front of the box
<bjf> cjwatson, ok, one sec
<ogra> WTF
 * ogra curses
<bjf> cjwatson, apw: hold shift key to get to grub
<bjf> cjwatson, apw: move arrow keys to not get timeout
<bjf> cjwatson, apw: pressed "c" to get into a command mode
<bjf> cjwatson, apw: typed "terminal_output console"
<bjf> cjwatson, apw: typed "set gfxmode=1440x900x16"
<bjf> cjwatson, apw: typed "terminal_output gfxterm"
<bjf> cjwatson, apw: typed "background_color 44,0,30"
<bjf> cjwatson, apw: typed "Esc" to get back to the grub menu
<bjf> cjwatson, apw: typed "e" to get to the editor
<bjf> cjwatson, apw: replaced "$linux_gfx_mode" with "text"    (no dbl-quotes)
<bjf> cjwatson, apw: removed "quiet splash"
<bjf> cjwatson, apw: pressed "F10" to boot
<ogra> so ubuntu-netbook is installable in my chroot ... but antimony still chokes on libwebkitgtk
<cjwatson> ogra: make sure you don't have universe/multiverse on
<ogra> i dont get that
<ogra> cjwatson, in my chroot ? i dont
<ogra> its newly bootstrapped
<cjwatson> dunno then, but I bet it's not antimony choking, surely a livefs buildd instead
<cjwatson> bjf: that looks plausible then.  do you get a text panic now?
<ogra> both then
<bjf> cjwatson, no, still cursor in upper left of screen, capslk flashing
<cjwatson> ogra: and did you try ubuntu-netbook^ (the task) rather than ubuntu-netbook (the metapackage)?
<davmor2> cjwatson, bjf: would it be worth trying to boot into rescue mode that'll give you text output and maybe the panic?
<ogra> cjwatson, ah, no, i didnt
 * ogra tries
<cjwatson> ogra: it fails in chdist for me
<ogra> yeah, task fails
<bjf> davmor2, that's where i'm heading right now
<ogra> phew
<cjwatson> davmor2: recovery mode is pretty much equivalent to removing 'quiet splash', which he's already done
<ogra> i thought i'd go insane ... indeed PEBCAK
<cjwatson> the only other difference is that it doesn't save the default entry
<cjwatson> bjf: oh, you might try removing vt.handoff=7 from the kernel command line
<cjwatson> (which, come to think of it, is another difference in recovery mode)
<bjf> cjwatson, recovery mode worked better, have text which shows the panic now
<cjwatson> bjf: so just to make sure, try normal mode but remove quiet splash and vt.handoff=7
<bjf> cjwatson, will do
<cjwatson> apw: I guess this is more or less on your turf now
<ogra> ah !
<ogra> rhythmbox pulls in the old webkit
<pitti> ogra: hm, I thought I uploaded a rebuild for that
<ogra> yeha, i see an upload
<ogra> ftbfs on arm
<ogra> error: Dbusmenu-Glib-0.2 not found in specified Vala API directories or GObject-Introspection GIR directories
<ogra> hmpf
<seb128> ogra, it needs to be updated for the new libdbusmenu
<ogra> seb128, yep
<seb128> ogra, seems the other archs built before the new libdbusmenu so they were ok
<seb128> ogra, I can fix that tomorrow I planned to upload the new rb as well
<andreserl> Can anyone from foundations take a look at bug #525287
<ubottu> Launchpad bug 525287 in lvm2 (Ubuntu) "Add support for corosync based clusters in clvm" [High,Confirmed] https://launchpad.net/bugs/525287
<ogra> seb128, yeah, fine, i wont put work into it then
<seb128> ogra, ok
<hallyn> cmagina: hey, if you get a chance (since I know you've tested it :) could you comment that you've verified bug 686832 and bug 660597 ?
<ubottu> Launchpad bug 686832 in multipath-tools (Ubuntu) "multipath-tools-boot, root mount failed - Device or resource busy" [High,Fix released] https://launchpad.net/bugs/686832
<ubottu> Bug 660597 on http://launchpad.net/bugs/660597 is private
<cmagina> hallyn: will do
<hallyn> cmagina: thanks
<stgraber> tumbleweed: ping
<stgraber> tumbleweed: I'm working on uploading suspended-sentence, I'll put the right version number in there but I'm wondering if you have any issue with me dropping the two first changelog entries
<stgraber> tumbleweed: so the first changelog entry for what will hit extra.u.c will match the first upload
<janimo> is there a specific team/individual taking care of banshee? If so is 1.9.2 planned soon?
<micahg> hyperair: ^^
<micahg> hmm, already in Debian experimental
 * micahg guesses hyperair can't help with that anymroe
<micahg> *anymore
<micahg> janimo: it's on the Desktop Team's list of packages to update now, you might want to ask in #ubuntu-desktop if it's urgent
<hyperair> micahg: oi
<janimo> micahg, thanks, not urgent, just good to know, as it may affect an armel bug
<hyperair> who said i'm not working on it?
<hyperair> i'm waiting on banshee-community-extensions
<micahg> hyperair: I meant about getting it merged into Ubuntu :), unless you got PPU already for it
<hyperair> there's this dude who has a suspicious jamendo icon there i'm not sure comes from where
<hyperair> micahg: it is in the PPA.
<hyperair> micahg: AND i will be getting it merged into ubuntu. i just don't want to break banshee-community-extensions.
<hyperair> micahg: so whoever touches banshee... better not mess it up, or his/her head will roll.
<micahg> hyperair: ok, just noticed it's in main now
<hyperair> we have package sets now
<hyperair> being in the debian-cli team i retain upload access to banshee
<hyperair> now that that's clarified, let me get back to my book
<micahg> hyperair: ah, ok, cool, didn't realize it was in there :)
<hyperair> lisbeth salander is â¥
<micahg> janimo: so hyperair's the one :)
<micahg> package sets, FTW!
<tumbleweed> stgraber: fine with me
<SpamapS> jelmer: w000t ty for the paramiko update! :)
<jelmer> SpamapS: please thank StevenK for sponsoring :-)
<SpamapS> StevenK: thanks for sponsoring the paramiko upload! :)
<StevenK> SpamapS: :-)
<superm1> pitti, would you mind doing another release of jockey before the next alpha?  i'd like to be able to test with some of the modaliased-driver package things as the media starts to stabilize again
<lifeless> bdrung: ping (bug 704657)
<ubottu> Launchpad bug 704657 in ubuntu-dev-tools (Ubuntu) "edge service root is deprecated" [Undecided,New] https://launchpad.net/bugs/704657
<bdrung> lifeless: merge proposals are welcome
<tumbleweed> lifeless, bdrung: I noticed that a while back, but knew the new launchpadlib was about to land, it will probably mean manage-credentials is no longer needed
<maxb> How long is the ubuntu-backporters review queue these days? (>20 days seems quite a lot)
<ebroder> maxb: it's pretty long, and the amount of backlog unfortunately tends to make working on it discouraging
<maxb> How long is considered an acceptable demonstration of patience before trying to hunt people down on IRC? :-)
 * micahg thought there was a helper script now and it was built in to AA duties
<ebroder> micahg: yes, but that's only once backporters have approved it
<maxb> Hmm, https://bugs.launchpad.net/~ubuntu-backporters/+subscribedbugs is "only" 27 entries
<micahg> ebroder: oh, he means the actual approval
<maxb> That's not as dire as it could be
<ebroder> maxb: that's only bugs that ~u-b are explicitly subscribed to, i think. you want to look at https://bugs.launchpad.net/lucid-backports/+bugs and similar
<ebroder> maxb: if you haven't already, you can make your request more appealing to review by making sure that you've tested that the packages build, install, and run
<maxb> done that :-)
<maxb> and listed the reverse-depends too
 * ebroder sighs
<ebroder> fine, you've got my attention. i can at least look at it and tell you what additional checking i think would need to be done
<ebroder> (note: i'm not currently a backporter, but i do a lot of backports)
<lifeless> tumbleweed: its trivial to fix - s/edge/production
<lifeless> bdrung: a mp seems overkill when you can just do the replace and commit directly.
<tumbleweed> lifeless: indeed
<maxb> bug 695108 is the one I'm interested in
<ubottu> Launchpad bug 695108 in lucid-backports "Backport pristine-tar 1.11ubuntu1" [Undecided,New] https://launchpad.net/bugs/695108
<ebroder> maxb: should this be an sru instead of a backport?
<ebroder> we don't usually backport to fix bugs - we backport to add features
<maxb> It's a "bring in the latest upstream, which is better" rather than a "targetted application of specific bugfixes"
<maxb> That seems more backport than SRU territory to me
<micahg> ebroder: a backport to maverick is required for an upgrade path as well, right?
<ebroder> yes, it would be
<micahg> ebroder: I agree with you, this seems more SRU material since the version in the archive is broke
<micahg> maxb: a backport helps UDD, but not other people without backports enabled
<bdrung> lifeless: then just push the change to the ubuntu-dev-tools branch. it's owned by ubuntu-dev
<maxb> micahg: A SRU requires a minimal patch. I don't think it's in anyone's interests to take the time to prepare one for this package
<lifeless> bdrung: maybe I'm looking at the wrong place; whats the lp url for the branch ?
<bdrung> lifeless: lp:~ubuntu-dev/ubuntu-dev-tools/trunk
<maxb> The pristine-tar in the archive for lucid does break on a small proportion of the tarballs of packages in the archive, it's true. But the target audience that needs it to work is small indeed.
<maxb> james_w`: around?
<james_w`> hi maxb
<maxb> james_w`: Hi. We're discussing whether pristine-tar can be backported to lucid, or whether it gets bumped from the backports process on the grounds of being a bugfix that ought to be SRUed
<lifeless> bdrung: pushed
<james_w`> maxb, my hunch is that it would be bumped from the SRU process due to it being too instrusive
<maxb> That was what I was thinking. I hope it doesn't fall down a crack between the backports and SRU processes and be lost forever :-/
<ebroder> maxb, james_w`: you should probably get ScottK or one of the other backporters to weigh in - his opinion is official; mine is not
<james_w`> the change that fixed it is: "zgz now includes a trimmed down copy of the compressor from bzip2 0.9.5d."
<james_w`> sounds quite intrusive
<maxb> I think that can be sold as a "feature"
<ebroder> maxb: look, if you can just point me at any new feature that was added to pristine-tar... :-P
<maxb> "Include a copy of the compressor from bzip2 0.9.5d"
<andreserl> jml: howdy!! So, do you have any ideas on how to do what you proposed for testdrive?
<jml> andreserl: some
<jml> andreserl: I'd copy code from lp:start-hacking, and muck around a bit, basically
<andreserl> jml:righ but I mean, how could we pass information to a VM to launch the specific application
<andreserl> btw.. is there anyone from foundations around that can take a look at bug #525287
<ubottu> Launchpad bug 525287 in lvm2 (Ubuntu) "Add support for corosync based clusters in clvm" [High,Confirmed] https://launchpad.net/bugs/525287
<james_w`> andreserl, cloud-init!
<andreserl> james_w`: yes that's what I was thinking too :)
<andreserl> smoser: would it be possible to use cloud-init with uec images that run in testdrive?
<james_w`> desktop images?
<andreserl> james_w`: yes, desktop images
<andreserl> james_w`: testdrive already supports launching UEC server images
#ubuntu-devel 2011-01-19
<ipatrol> Why, exactly, did they change from that warm brown theme after karmic?
<smoser> andreserl, yes, possible.
<smoser> andreserl, when it boots, you get a grub console at which you can interupt it and select a different entry. then provide that entry with a "seed" (url where to find its user-data and meta-data) files.
<smoser> but it is manual to stop that boot process. you could recreate the floppy and replace the one bundled with one of your own.
<andreserl> smoser: so to make it automatic, I'd need to create a custom floppy then. thanks for the info
<smoser> yeah. or modify the image (mount loopback)
<smoser> but you can create the custom floppy without root
<andreserl> smoser: I think that the easiest would be to provide a floppy for my case. I'll ping you when I get to that point :)
<smoser> andreserl, the floppy is made by http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/mk-nocloud-bootdisk
<smoser> just hack the first menu entry with a 'seedfrom' location like: https://help.ubuntu.com/community/UEC/Images
<andreserl> smoser: awesome!! thanks!
<ScottK> maxb: We can talk backports if ubuntu-sru says no to it, but they should get first crack at it.
<maxb> ScottK: Hrm. Very well. I just don't see how "skip several upstream versions forward" can be SRUable
<ignarps> can anyone comment what may be holding up bug #683640 this effects more then the listed application
<ubottu> Launchpad bug 683640 in lsb (Ubuntu) "status_of_proc is returning incorrect error code" [Undecided,New] https://launchpad.net/bugs/683640
<didrocks> good morning
<pitti> Good morning
<pitti> superm1: we can also just merge from trunk and upload that, sure
<freeflying> pitti: would you mind give me the bzr repo for language-support-input-xx? thanks
<pitti> freeflying: these are autogenerated by lp:langpack-o-matic
<pitti> there is no bzr for the actual langpacks
<freeflying> pitti: noted, thanks
<apw> @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: apw
<soren> How certain are we that UDS-O will be in Budapest May 9th - 13th?
<nigelb> soren: hrm, depends on how much you trust whoever announced it last time (jono?)
<soren> nigelb: I forget who it was. Robbie gave us the dates a long time ago. Maybe in Brussels.
<soren> nigelb: ...and then we got the dates again along with a location in Orlando.
<nigelb> soren: Yeah, I remember robbie's mail.  I'm guessing your question has to do with tickets?
<nigelb> (early booking?)
<soren> nigelb: Yup.
<soren> nigelb: And planning other events.
<janimo> Laney, do you know why haskell-utf8-string is not in the archives starting with 10.10 ?
<nigelb> soren: hrm, best person to confirm with would be randa, I believe she deals with the events
<soren> What, still?
<soren> Hm..
<soren> janimo: it was removed after Karmic.
<soren> janimo: https://launchpad.net/ubuntu/+source/haskell-utf8-string/+publishinghistory says it's because it's now provided by ghc6.
<nigelb> soren: *cough* entirely guesswork and you can't quote me etc ;)
<janimo> soren, thanks for the links
<soren> janimo: If you expand the entry where it's deleted, you can see the reason stated by the archive admin.
<soren> janimo: Sure thing.
<soren> janimo: And welcome back, by the way :)
<janimo> soren, thanks :) . LP apparently has lots of useful info behind those small-typed links
<nigelb> soren: Hey, just asked randa.  She says its confirmed 100% May 9th - 13th :)
<soren> nigelb: Awesome. Thanks.
<nigelb> soren: :)
<soren> nigelb: Oh, did she also confirm that it would be in Budapest? :)
<nigelb> soren: yup
<soren> nigelb: Lovely. Thanks!
<nigelb> soren: :D
<djszapi> What is the execution order amonst upstart config jobs ? I would like to know which is the first job run because I would liket o start an auditd daemon during the boot asap.
 * ogra glares at his bug mailbox ... how did over 100 bugs pile up over night ?
<ogra> grmbl ... maverick to natty really doesnt give me a nice upgrade experience
<ogra> first i had to answer the kbd selection for (felt) 59 times ... now the pae kernel cant install
<seb128> doko_, hey, did you sent your evince bug fix to upstream? could you include the bug references in the patches so it makes tracking easier?
<doko_> seb128: no, just forwarded to Debian. what do you with bug references?
<doko_> seb128: btw, evince still ftbfs, gir-scanner issue?
<seb128> doko_, https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines
<seb128> doko_, including the debian or upstream bug reference in the patch makes easier for other people to figure if the patch has been forwarded and where
<seb128> doko_, right, it still fail to build it seems, not sure why though
<ari-tczew> JamesPage: any news on bug 682216 ?
<ubottu> Launchpad bug 682216 in jython (Ubuntu) "Merge jython 2.5.1-2 (main) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/682216
<seb128> doko_, the debian guys are asking if you will forward your patch upstream as well since that"s an upstream issue
<JamesPage> ari-tczew: looking now but think its still pending MIR approval for dependencies...
<ari-tczew> :(
<JamesPage> ari-tczew: OK - now I remember
<doko_> seb128: wouldn't mind if you could do that
<seb128> doko_, ok, can do
<doko_> thanks
<seb128> yw
<JamesPage> ari-tczew: this merge is dependent on a later version of antlr3 - however the newer version of antlr3 switched build system from ant->maven
<JamesPage> ari-tczew: which currently means it blocked as antlr3 is in main
<JamesPage> ari-tczew: and maven is not....
<JamesPage> ari-tczew: the main inclusion approval list is 75 new packages universe -> main
<ari-tczew> JamesPage: too big job
<JamesPage> ari-tczew: yep - considering the capacity the MIR team has I don't think this is achievable
<ari-tczew> JamesPage: well, jython won't merged then
<JamesPage> ari-tczew: :-( not great I know
<JamesPage> ari-tczew: I intend on taking a blueprint to the next UDS about moving the Maven toolchain to main
<ari-tczew> JamesPage: aha
<JamesPage> ari-tczew: which should help unblock some of this stuff (most new Java projects are maven based)
<ari-tczew> JamesPage: then would be nice move maven to main
<JamesPage> ari-tczew: agreed
<doko_> seb128: btw, a lot of the gnome-* related reports in http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=no-add-needed;users=peter.fritzsche@gmx.de seem to be addressed, but not closed in debian
<om26er> apw, hi! could you review and sponsor this branch for a SRU https://code.launchpad.net/~om26er/ubuntu/maverick/empathy/empathy-fix-666288/+merge/45740
<seb128> doko_, do you mean that they are fixed bug nobody closed the bugs or that they have patches but nobody uploaded those?
<doko_> seb128: the former, didn't check the latter
<seb128> ok
<apw> om26er, well the merge request looks good to my eye, patches look identicle to what went into natty, not sure i have the ability to actually merge it however
<om26er> apw, they are same
<apw> om26er, thanks for the confirmation, am finding out what happens now
<apw> om26er, ok that looks sane to me, so i have approved the merge will look for someone to actually upload
<apw> om26er, ok thats going to be looked at shortly, thank you!
<om26er> apw, thank you ;)
<ogra> Riddell, any trace of that new qt upstream release ? (/me really wants to upgrade his arm stuff to natty but that wont work without NEON runtime detection)
<Riddell> ogra: there hasn't been a new upstream release, I can ask if one is likely to be coming.  you could search git for the neon detection feature to patch in if needed
<ogra> Riddell, well, i think its a quite intrusive change, i'll rather wait for a new upstream for that
<Riddell> ogra: my usual upstream contact isn't online, I'll ping him when he's around
<ogra> thanks, i would love to test unity-2d on arm
<apw> @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:
<soren> Is there an existing tool that will tell me which packages I have installed that are not from the Ubuntu repository?
<seb128> soren, check with mvo byt synaptic has a category for those iirc
<seb128> not sure how it does the checking or if there is a command line equivalent though
<soren> seb128: Cool, thanks.
<soren> seb128: Do you happen to know where mvo is?
<didrocks> soren: I think he's at the cross-distro installer meeting
<seb128> soren, what didrocks said
<soren> Ta
<seb128> where installer is package installer not ubiquity installer
<soren> Oooh. Gotcha.
<soren> seb128, didrocks: Thanks.
<seb128> yw
<cjwatson> pitti: could you have a look at debian-installer in lucid-proposed?
<cjwatson> it's a bit bigger than the usual regular update
<pitti> cjwatson: hi! sure
<pitti> ERROR: queue does not have a debdiff
<pitti> meh
 * pitti reviews manually
<pitti> cjwatson: oh, we'll produce a new CD image for the maverick backport?
<cjwatson> the plan's recorded in bug 607657
<ubottu> Launchpad bug 607657 in debian-installer (Ubuntu Lucid) "Lucid point release installer must support LTS backported Kernels" [High,In progress] https://launchpad.net/bugs/607657
<cjwatson> it'll be PXE-boot images plus DVDs
<cjwatson> I have a debian-cd patch ready to add these images to the DVDs
<pitti> ah, understood, thanks
<andreserl> can anyone please take a look to bug #525287
<ubottu> Launchpad bug 525287 in lvm2 (Ubuntu) "Add support for corosync based clusters in clvm" [High,Confirmed] https://launchpad.net/bugs/525287
<cjwatson> pitti: thanks
<kklimonda> hey, could someone take a look at proposed changes to the transmission license and comment on their compatibility with dfsg: http://pastebin.com/ZCQf9KWm ?
<Warlock072> hey guys
<cjwatson> kklimonda: requiring the name to be changed is fine (DFSG#4), but I'm not sure whether the rest of it is essentially an extension to the name-change requirement or is separate (in particular surely any package of Transmission is a derived work of Transmission, so in practice wouldn't this mean it'd have to be iceweasel-ified?).  I would recommend asking debian-legal
<Warlock072> note sure if anyone here can help me
<Warlock072> ive got ubuntu lucid server showing high cpu usuage on this command ksoftirqd
<Warlock072> anyone know what ksoftirqd is?
<apw> Warlock072, that sounds kernelly to me ... i'd suggest you bring that up on #ubuntu-kernel
<Warlock072> google gives me alot of various explanations
<Warlock072> thanks will ask there
<apw> Warlock072, it is a kernel thread which handles interupts which are long running, which cannot occur in interrupt context; firmly part of the kernel
<Warlock072> thanks
<sconklin> @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: sconklin
<Warlock072> the makes ait more sense
<kklimonda> cjwatson: getting a consent from the Transmission devs to create a "derived work" (package) would not be enough, because we can't give the same consent to, for example, distributions that are based on Ubuntu?
<Warlock072> makes sense i mean
<Warlock072> thanks
<cjwatson> kklimonda: indeed
<cjwatson> kklimonda: I'm not really an expert in DFSG analysis, though
<kklimonda> cjwatson: ok, I'll send the proposed changes to the debian-legal and see what they say about it.
<cjwatson> pitti: linux/lucid-proposed looks releasable to me, since the only unverified bugs are the tracking bugs - does that seem right?
<pitti> cjwatson: right, we need the feedback from QA and cert for this now
<cjwatson> oh, they verify the tracking bug separately then?
<pitti> cjwatson: yes, they run the regression tests on it (QA), and the certification tests (cert)
<cody-somerville> dear kernel team, please blacklist dell-laptop module, kthxbi. :-)
<nigelb> gah, bilal isn't around :(
<apw> cody-somerville, !?!
<bdmurray> doko_: I've run into bug 504198 again on a Lucid system
<ubottu> Launchpad bug 504198 in eglibc (Ubuntu) "locale support broken on upgrade to latest eglibc" [Critical,In progress] https://launchpad.net/bugs/504198
<doko_> bdmurray: I don't understand why ... I prepared updates for maverick and natty
<doko_> bdmurray: does running the local-purge manually fix it?
<bdmurray> doko_: hmm well the workaround (locale-gen --purge) didn't work either
<pitti> barry: I got c-j ported to pygi, see https://code.launchpad.net/~pitti/computer-janitor/pygi/+merge/46779
<\sh> NCommander: congrats :)
<directhex> congrats?
<barry> pitti: rock!  think we should switch to that for natty?
<barry> pitti: i'm going to grab some lunch, but i'll review and test the branch later today.  this is really great
<pitti> barry: I think yes; losing the right-click popup menu isn't that bad really, and I made it cope gracefully
<pitti> barry: I looked into gtk, but it's really not possible to make gtk_menu_popup() introspectable
<pitti> as there is no well-defined scope for the callback if you pass one
<pitti> popup_for_device() has, because it has an explicit GDestroyNotify
<barry> pitti: does that mean, you can't tell where the click occurred?
<pitti> no, because of menu_poup() (see above and the debian changelog)
<barry> pitti: ah, okay.  i'll take a look at the code and changelog and ping you if i have questions
<\sh> doko_: any fix for the -z syms unknown gcc 4.6 bugger? (remove "-z foo"?)
<RoAkSoAx> cjwatson: howdy!! if you have the time could you please take a look to bug #525287
<ubottu> Launchpad bug 525287 in lvm2 (Ubuntu) "Add support for corosync based clusters in clvm" [High,Confirmed] https://launchpad.net/bugs/525287
<pitti> barry: the MP has instructions how to test it (needs a newer pygobject)
<pitti> barry: sprint is making great progress, btw :) fixing bugs by the dozens, and getting to know the pygi folks
<ari-tczew> cjwatson: could you check whether binary package libmtdev1-udeb is necessary for us in Ubuntu? I'm merging source mtdev, but Debian has dropped this binary.
<barry> pitti: that is *very* good news.  i'd love to get a braindump when you're back from the sprint, re: feasibility of the transition we talked about
 * barry -> lunch
<pitti> barry: I'll do a long blog post after the week
<superm1> pitti, sure that works.  would you like me to do that?
<cjwatson> RoAkSoAx: sorry, I have critical-path 10.04.2 things to do at the moment, so probably won't have time
<cjwatson> perhaps somebody else on the sponsors list can do it
<ari-tczew> RoAkSoAx: I saw dholbach has sponsored something some minutes ago, maybe he could :)
<RoAkSoAx> cjwatson: no worries then, I was just wondering if someone from foundations could take a look at it before getting it sponsored, given that zul himself doesn't wanna touch lvm2 :)
<cjwatson> ari-tczew: we're after Debian import freeze - is there a good reason to do a difficult merge?
<RoAkSoAx> ari-tczew: thanks for the info but I'd like someone from foundations team to review it given that we don't wanna break lvm2 :)
<ari-tczew> cjwatson: Debian has new usptream release, would be nice to get it.
<cjwatson> ari-tczew: in any case, yes, we need to keep libmtdev1-udeb - xserver-xorg-input-evdev-udeb indirectly depends on it
<cjwatson> (in Ubuntu)
<ari-tczew> cjwatson: ok, then I'm keeping
<cjwatson> Debian generally doesn't introduce new udebs except when needed by their own dependencies, since they have a release management overhead
<cjwatson> so if their X udebs don't include utouch integration then they wouldn't have included this one
<apw> cjwatson, did i see you'd fixed marjos issue grub side ?
<cjwatson> apw: not yet uploaded, but yes
<cjwatson> I haven't had a chance to reboot since committing that
<ari-tczew> ah, right - my boot logo has been fixed!
<ari-tczew> today I noticed
<ari-tczew> nice
<apw> cjwatson, i am trying to raise intel experts to help debug the other half
<cjwatson> that was pitti
<cjwatson> apw: cool
 * SpamapS rejoices as his lucid eglibc build appears to be finishing
<cody-somerville> apw, LP #701259
<ubottu> Launchpad bug 701259 in linux (Ubuntu) "dell-laptop module hard blocks wifi on Dell Vostro 1520" [Undecided,New] https://launchpad.net/bugs/701259
<apw> cody-somerville, you would think that dell might keep dell-laptop module working for their kit mightn't you
<cody-somerville> apw, It was actually written by Red Hat (Matthew Garret specifically).
<apw> cody-somerville, you'd think they'd care for and love it none the less (dell)
<smoser> pitti, or sru team, can i get someone to let euca2ools (https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=) into -proposed ?
 * jdong ponders if bug 704674 is a security vulnerability....
<ubottu> Launchpad bug 704674 in mumble (Ubuntu Maverick) "mumble-server creates world readable config file" [High,Triaged] https://launchpad.net/bugs/704674
<SpamapS> doko_: ok I have eglibc built and tested .. can you copy your upstart changes to p.c.c/~doko/tmp too?
<micahg> could someone please give me bug tasks on bug 705028 (core-dev or QA)
<ubottu> Launchpad bug 705028 in thunderbird-locales (Ubuntu) "Update Thunderbird translations to 3.1.7" [Undecided,New] https://launchpad.net/bugs/705028
<jdong> kees: would you like to give an opinion on bug 704674? I'm not sure whether it's appropriate to SRU it or treat it as a security vuln
<ubottu> Launchpad bug 704674 in mumble (Ubuntu Maverick) "mumble-server creates world readable config file" [High,Triaged] https://launchpad.net/bugs/704674
<kenvandine> doko_, did you ever get a chance to look at bug 688732
<ubottu> Launchpad bug 688732 in pywebkitgtk (Ubuntu) "package no longer has WebView attribute after transition to python 2.7" [High,Triaged] https://launchpad.net/bugs/688732
<seb128> barry, ^ or maybe you?
<kenvandine> it only happens on upgrade, not install
<seb128> barry, doko: the bug is collecting duplicates, not sure what's going on but if someone who understand python packaging has a clue that would be welcome
<ari-tczew> are we going to get perl 5.12 and openssl 1.0 in Ubuntu 11.10 ?
<seb128> seems leftovers on upgrade or something
<kenvandine> seb128, no, it actually gets put there on upgrade
<SpamapS> ari-tczew: assuming squeeze releases by then, I'd say yes. Otherwise, tough to get too far out of sync w/ debian on those pieces.
<kenvandine> we first saw it when py2.7 was first added
<seb128> kenvandine, ok, weird, I didn't get that issue
<ari-tczew> SpamapS: I can imagine bilion rebuilds and transitions.
<kenvandine> well, i think it might be limited to people that upgraded at a certain time
<kenvandine> during the transition/dual install
<micahg> squeeze release is tentatively 1st week of Feb
<SpamapS> micahg: I did see that the RC bug list has gotten rather small
<SpamapS> tho I'm pretty sure there's a bug in squeeze's libdbi
<kenvandine> seb128, i seem to recall not hitting that problem when i upgraded my VMs either... but my laptop that gets updated daily did
<superm1> apw, a bunch of patches got dropped when it was rebased to upstream.  mjg59 didn't like some of them and didn't accept them
<superm1> it was his view that they should be fixed in the BIOS, which wasn't going to happen after the platforms launched.
<apw> superm1, a problem indeed
<kees> jdong: security would be fine for that. it's pretty minor, so I wouldn't cry if it was done as an SRU too.
<superm1> keng-yu has hit the same problem with some recent patches that he wanted to submit that mjg59 won't take on the same basis
<jdong> kees: okay. I think I'll recommend that it be done as a security update then.
<kees> jdong: cool by me. once there are tested debdiffs, we can publish it
<apw> superm1, a difficulty indeed, i can see both sides, having inviolate bios after releaase does make the world a hard place
<debfx> jdong: I wonder if it would be a good idea to add a NEWS.Debian file saying that one should check the permissions of mumble-server.ini
<jdong> debfx: my experience honestly is that 90% of sysadmins don't go around chasing those obscure files in /usr/share/doc... The permissions should be automatically corrected during the update, and a USN should go out about it so admins know that SQL passwords coudl've been read by local users
<debfx> jdong: well apt-listchanges displays NEWS files if it's installed :)
<jdong> do people tend to do that?
 * jdong exposes himself as a shamefully incompetent sysadm
<debfx> no idea
<debfx> anyway I'll prepare new debdiffs targeting *-security
<jam> dendrobates: ping, I was told you might know something about lp:~sleepsonthefloor
<RoAkSoAx> what kernel version is gonna be in natty?
<hallyn> oh neat, maximizing a terminal in unity now gets rid of the side bar
<SpamapS> doko_: tested libc6 change and upstart change on lucid, works perfectly
<Daviey> sconklin, Are you still piloting?
<sconklin> Daviey: yes, how can I help?
<Daviey> yippee!
<sconklin> disclaimer: I am a kernel type, so not all that skilled with things like bzr
<Daviey> sconklin, https://code.launchpad.net/~davewalker/ubuntu/natty/ocfs2-tools/bug_363877/+merge/46807
<barry> rickspencer3: ping
<sconklin> Daviey: I'm sorry but I don't even know what to do with that
<SpamapS> doko_: strike that, there's still a race
<SpamapS> doko_: will comment in the bug
<Daviey> sconklin, Okay, no problem - thanks anyway.
<SpamapS> doko_: basically we need telinit u to wait for init to actually restart itself.
<barry> rickspencer3: what's the detail with the daily-journal package? is that in natty?
<sconklin> I'm sorry, I feel like I've done some false advertising
<Daviey> sconklin, heh, don't feel bad.  What is the aspect of it that makes you run for the hills?
<sconklin> I don't know what that is, or how to do whatever is required. It looks like maybe a request to merge something, but I don't use bzr and wouldn't know how to do it
<Daviey> sconklin, It's essentially a posh debdiff.
<Daviey> 'merge' in the sense of upload.. slight miss use of terminology. ho hum
<Daviey> sconklin, dholbach is doing some docs on all this aiui... might be useful in the future.
<Daviey> Thanks for your time anyway.
<sconklin> np
<barry> rickspencer3: nm
<jam> dendrobates: just another quick ping
<Darxus> Is there an irc channel specific to testing natty?  In virtualbox 4, the installer keeps hanging around "Preparing to install Ubuntu", both with the version from the maverick repos, and the maverick version from the virtualbox site.
<Pici> Darxus: #ubuntu+1
<charlie-tca> Darxus: yes, it is #ubuntu+1
<Darxus> Huh, I had just determined it was #ubuntu-testing from https://wiki.ubuntu.com/Testing
<Darxus> Thanks.
<lifeless> soren: ping
 * lifeless is hopeful
<soren> lifeless: Wazzip?
<soren> wazzup, even.
<lifeless> hey
<soren> o/
<lifeless> so we're seeing 11K ssh connections from an openstack daemon or something
<lifeless> #launchpad-dev perhaps
<soren> Awesome.
<soren> Sure.
<vladsharp> how long do ppa signing keys take to generate?
<vladsharp> is it normal for the key to have an id on the web page but actually not be available on the ubuntu keyserver?
<doko_> SpamapS: no rush on this, just wanted to try to get the fix before the sru release
<SpamapS> doko_: there's another libc6 update?
<SpamapS> :(
<doko_> SpamapS: no just the str* fix which I did include
<SpamapS> doko_: every time we update upstart or libc6 without doing this particular update, we are risking more rootfs corruptions. :(
<Laney> janimo: cheers for the haskell rebuilds (have you seen the installability graphs?)
<andreoli> hi, I am trying to read PPA stats through a "ppastats.py" script found here: http://www.webupd8.org/2010/12/launchpad-finally-gets-ppa-usage-stats.html . I only get zeroes. Are the PPA stats active?
<Laney> andreoli: PPA questions should be in #launchpad
<andreoli> thx sorry
<Laney> np
<janimo> Laney, np. I did not initially intend to do all of them - had no idea there's an actual graph, just started from a few FTBFS apps. But luvkily caught on early that there are dependencies
<Laney> http://orangesquash.org.uk/~laney/haskell-installability/i386.png if you want to do some more
<janimo> Laney, if you have apointer to the graph I can look at it, it can still help
<Laney> :-)
<janimo> Laney, but at least I have a script for creating the updted packages, so was not all drudgework
<janimo> Laney, I mostly went depth first until the deps were ghc6 internal only, and uploaded those, and then the next layer and so on
<Laney> yeah, that's how you use the graph
<Laney> start at the root and work outwards until it is all green
<janimo> Laney, one issue I ran into is haskeline ntot building becasue of utf8-string . It should be part of ghc6 - that isa why the standalone pkg was removed after lucid - but the setup script does not find it
<janimo> Laney, all of these need to be rebuild after a new GHC build??!
<janimo> sounds interesting :)
<Laney> janimo: hmm, yes I don't see that package
<Laney> will investigate
<Laney> and yeah sometimes the amount of rebuilds is large, luckily it's mostly automatable though
<janimo> Laney, does it need a rebuild after each build of ghc6 or only if the ghc version changes?
<Laney> if the ABI changes
<janimo> so those magic numbers are digests of the ABI?
<Laney> right
<janimo> ok, good to know it is not randomly generated ID on each rebuild :D
<Laney> it's the best way we found to track the unstable ABI
<janimo> Laney, similar to what the kernel does for modules I guess
<Laney> I suspect the kernel has a rather better ABI guarantee ;)
<Laney> but yes, that idea
<doko_> mterry: can't decide on twm, I'm biased
<RoAkSoAx> Anyone experiencing issues similar to "E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/h/heartbeat/libheartbeat2_3.0.4-1ubuntu1_amd64.deb: Size mismatch"  in pbuilders?
<mterry> doko_, :)  ah, I assigned because looked like you had been involved in the discussion.  biased?  did you work on it, or you just want it?
<micahg> RoAkSoAx: did you try updating again?
<doko_> mterry: I just want it because of the excessive dependencies on metacity
<doko_> mterry: but I don't know if kees would agree to maintain an extra window manager in main
<Laney> janimo: looks like GHC indeed stopped providing utf8-string, so we should bring that (source) package back
<Laney> FYI, if you want to do that. Otherwise I'll get to it soon, probably at the weekend.
<Laney> I can commit to Debian if you want too.
<mterry> doko_, well reassign if ya like  :)
<RoAkSoAx> micahg: like 10 times
<RoAkSoAx> micahg: I guess it is just the archive server that pbuilder is using or something
<janimo> Laney, ok IIRC I saw today on Debian Haskell archives that they were not sure about dropping that
<janimo> But they did apparently
<Laney> do you know in which thread?
<janimo> there was een talk of maybe needing to bring it back because of haskeline :)
<Laney> oh, at the time it was the right thing to do
<Laney> but it looks like GHC itself has stopped supplying the library
<janimo> Laney , no bu tI htink you posted in it too, I just googled today but cannot remember
<janimo> so ghc6 picked it up for a release then dropped it again?
<sconklin> @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:
<Laney> something like that
<bigon> hey, does anybody know the status of uefi boot ?
<ari-tczew> unfortunately, sponsors queue is not good this year... not good patch pilots
<ebroder> ari-tczew: i think it just hasn't yet recovered from the combined effects of the holidays and the rally
<ari-tczew> ebroder: do you mean holidays which has been ended 1rd ?
<ari-tczew> 3rd*
<micahg> ari-tczew: it's still doing much better than last year and what ebrober said
<micahg> ari-tczew: the patch pilots were at a developer sprint last week
<micahg> but I think they were still sponsoring
<micahg> http://reports.qa.ubuntu.com/reports/sponsoring-stats/ shows lots of work done
<ebroder> yeah, and if you look at the graphs, it's only been climbing since Christmas Eve
<ari-tczew> anyway, I wish that sponsors queue will be clean until Feature Freeze
<ebroder> we're still *well* below where we were after UDS
<ebroder> i'd argue that the system is working, it maybe just needs a bit more time to catch up
 * ari-tczew is guessing why this one is not yet uploaded: https://code.launchpad.net/~clint-fewbar/ubuntu/karmic/mysql-dfsg-5.1/mysql-sru-343870/+merge/42667
<bryceh> ari-tczew, are you participating in patch pilots?
<ari-tczew> bryceh: I guess, a little bit yes
<ari-tczew> bryceh: why you ask?
<bryceh> a lot of the items in the queue right now are syncs (which don't need sponsoring) or stray (non-Ubuntu) tasks
<bryceh> the real number of actionable items in the sponsor queue is pretty low
<micahg> bryceh: syncs need to be test built and ack'd, so that's sponsoring still :)
<ari-tczew> bryceh: syncs are 20,6% of all
#ubuntu-devel 2011-01-20
<achiang> kirkland: you around?
<kirkland> achiang: howdy man
<kirkland> achiang: wassup?
<kirkland> achiang: wanna meet me in Aspen in a couple of weeks?  :-P
<kirkland> achiang: i have a saturday/sunday on the slopes coming up in a few weeks :-)
<achiang> kirkland: ooh
<achiang> kirkland: what weekend? i'm actually skiing silverton over president's day
<achiang> kirkland: i have a relatively fresh maverick install, just installed virt-manager, and trying to create a VM, running into: http://pastebin.ubuntu.com/556023/
<kirkland> achiang: hmm, interesting
<kirkland> achiang: what does 'id' say about your user
<kirkland> achiang: i'm interested in what groups its a member of
<kirkland> achiang: specifically, you should be in the kvm and libvirtd groups
<kirkland> achiang: the packaging should have added that for you
<achiang> kirkland: i'm in libvirtd, but not kvm
<kirkland> achiang: but if not, sudo usermod -a -G kvm $USER
<kirkland> achiang: but if not, sudo usermod -a -G libvirtd $USER
<kirkland> achiang: then you'll need to logout of all sessions and log back in (or just reboot)
<kirkland> achiang: that's the most common mistake i've seen
<achiang> ok, back in a jiffy
<achiang> kirkland: but the packaging didn't add it
<achiang> kirkland: should be easily recreatable
<achiang> back in a sec
<kirkland> achiang: right, well, the packaging adds libvirtd, maybe/maybenot kvm
<kirkland> achiang: k
<soren> You don't need to be in the kvm group.
<kirkland> achiang: right, as soren is about to tell you, the kvm thing is now handled automagically by PolicyKit
<soren> Um. No :)
<soren> If you use the systemwide libvirt daemon (which you do if you're a member of libvirtd), you don't need to be a member of kvm.
<soren> Besides, I think the time is ripe for chmod 666 /dev/kvm. It doesn't give you any privileges anymore that are worth containing.
<achiang> back
<achiang> trying again
<achiang> and just read scrollback. :)
<achiang> kirkland: soren: hm, adding myself to kvm group and restarting seemed to help on one machine
<kirkland> achiang: rock
<achiang> on another machine, i went into advanced options, deleted the console device, and it too could start
<achiang> (without being in kvm)
<achiang> so... is this a bug i should file?
<kirkland> achiang: okay, glad to hear you're sorted out
<kirkland> achiang: i'm not sure I understand the situation clearly enough to say so
<kirkland> achiang: to be on the safe side, i'd say "yes"
<achiang> kirkland: ok. i'll try and see if i can reproduce it
<kirkland> achiang: mdeslaur maintains virt-manager for the most part
<kirkland> achiang: cool, thanks.
<soren> achiang: You basically need to be a member of either libvirtd or kvm. libvirtd is cooler, because it lets you fiddle with networking.
<soren> ...but to just run virtual machines, either works.
<achiang> kirkland: ok, i'll just file it against virt-manager, but won't assign it to anyone
<kirkland> achiang: as for skiing, i'm out there the weekend of Feb 5/6
<achiang> kirkland: another weird thing, i thought i had qemu-kvm installed, but when trying to create a machine, it says kvm is not installed
<kirkland> achiang: ah, well, then, that'll make it hard to run vm's :-)
<achiang> http://pastebin.ubuntu.com/556025/
<ebroder> soren: uh, doesn't /dev/kvm basically get you the ability to muck with the whole kvm subsystem, or did that change? i don't like the idea of giving random users access to that without the admin opting in
<ebroder> just like i don't want /dev/fuse to be 666
<ebroder> err...wait...when did /dev/fuse become 666?
<psusi> so what's a guy gotta do to get the whole natty archive rebuilt? ;)
<ebroder> (or is it safe for /dev/fuse to be 666 because fusermount has finer controls?)
<psusi> now that this gcc bug has been fixed...
<dholbach> good morning
<didrocks> good morning
<Tm_T> K'day
<soren> ebroder: What's so interesting about the kvm subsystem that you want to limit access to it?
<davmor2> morning dholbach
<dholbach> hey davmor2
<soren> ebroder: I can't consume any more resources through it than you could otherwise do just with malloc or a tight loop. It's not like there's a limited supply of /dev/kvm or anything. Nor can you screw up other people's VM's. There's really no reason to limit access to it.
<soren> ebroder: Once upon a time, having access to /dev/kvm meant you could lock memory pages in RAM. So a malicious user could create a VM with as much memory as the host, and you were DOS'ed.
<soren> ebroder: Nowadays, KVM memory can be paged out, so it's no different from just malloc(<size of host ram>).
<ebroder> soren: i'm more concerned about security issues. i basically trust unix file permissions. not sure whether i want to trust kvm any more than i have to
<soren> ebroder: I'm not sure what you mean?
<ebroder> in a nutshell, principle of least privilege
<soren> ebroder: The memory of a virtual machine is as easy or difficult to get to as the memory of any other process.
<ebroder> you're missing my point. i'm not concerned about the security of the guests. i'm concerned about the security of the host
<soren> so am I. And I don't believe /dev/kvm exposes anything that compromises the host's security.
<ebroder> you're assuming kvm is bug-free
<soren> Not really.
<soren> ..but the other 99.99% of the kernel isn't either.
<soren> Yet we don't limit people's access to open sockets, for instance.
<ebroder> sure, but it's all about minimizing the attack surface
<soren> We could.
<soren> but we don't. Because it's silly.
<ebroder> and we are starting to patch out autoloading of obscure protocols and stuff
<soren> a) kvm is not obscure
<soren> b) there are bugs in non-obscure parts of the kernel, too
<soren> I just don't subscribe to the idea of amputating my system to the point of uselessness in the name of security.
<soren> I think this is a symptom of "oh, wow, there's a device node for this stuff! Let's limit access to it!"
<ebroder> uselessness? it's not useless to reduce my attack surface by a whole subsystem when i personally run all of my vms managed by the system libvirtd
<soren> I understand that we've worked around these limitations for kvm. I know. I did it.
<ebroder> limitation? i'm not doing that because i think i have to
<soren> Well, whatever you want to call it.
<soren> We've worked around the fact that access to /dev/kvm has historically been restricted.
<soren> If kvm had been implemented by way of a syscall interface, noone would have thought of trying to impose artificial limitations on access to it.
<soren> (syscalls other than ioctl, that is)
<soren> Anyway, this is going nowhere.
<soren> and fast.
<dholbach> query Sarvatt
<doko_> siretart: please could you have a look at the xine-lib build failure? http://launchpadlibrarian.net/61920076/buildlog_ubuntu-natty-i386.xine-lib_1.1.19-2ubuntu2_FAILEDTOBUILD.txt.gz
<wolfpack> I am getting error while trying to "branch" in bazzar .Error is "bzr: ERROR: exceptions.NotImplemented Error: should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented ".Can anyone provide help on this??
<pitti> Good morning
<didrocks> hey pitti
<pitti> bonjour didrocks, comment vas-tu?
<didrocks> pitti: Ã§a va bien, merci, et toi? :)
<pitti> tres bien, merci!
<JoshTriplett> I just ran into something rather odd.  By way of Mozilla's "Game On" gallery page, I found a game which seems to copy a pile of content from the Ubuntu homepage and dummy it out, either due to copying parts of Ubuntu's page as a template or perhaps trying to get Google juice for random search terms.  Who might I go about reporting that to?
<JoshTriplett> Specifically: https://gaming.mozillalabs.com/games/ led to https://gaming.mozillalabs.com/games/118/the-humanity-project which points at http://farsides.com/ ; check out the links in the green box at the bottom.
<geser> JoshTriplett: contact webmaster@canonical.com (if nobody else gives you a better advice)
<JoshTriplett> geser: Fair enough.
<JoshTriplett> geser: Thanks.
<JoshTriplett> geser: Mailed.
<dpm> hi chrisccoulson, thanks for merging danilo's po2xpi branch. Do you think you could now look at automatically uploading the xpi's with every package upload, as we discussed? The easiest way I can think of is simply fetching them from http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0b9/linux-i686/xpi/, and I guess it shouldn't be too different to what you are already doing for getting the translations for the Thunderbird locale packages
<persia> Could that be semi-automatic, rather than automatic?  It seems like it could go very wrong or be very awkward in the case of a tiny SRU patch, or similar.
<nobuto> !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
<nobuto> ubuntu-docs 10.10.4 which was SRUed as Bug #677998 also contains unrelated changes, http://launchpadlibrarian.net/60441147/ubuntu-docs_10.10.3_10.10.4.diff.gz
<ubottu> Launchpad bug 677998 in ubuntu-docs (Ubuntu Maverick) "openldap-server instructions have a small bug" [Undecided,Fix released] https://launchpad.net/bugs/677998
<nobuto> This causes regression Bug #690248 which shows using 11.04 in spite of using 10.10
<ubottu> Launchpad bug 690248 in ubuntu-docs (Ubuntu Maverick) "In Maverick 'About Ubuntu' displays Natty info" [High,Triaged] https://launchpad.net/bugs/690248
<Riddell> didrocks: we're blocking on bug 702026
<ubottu> Launchpad bug 702026 in dcmtk (Ubuntu) "[MIR] dcmtk" [Undecided,New] https://launchpad.net/bugs/702026
<didrocks> Riddell: I'll process it before EOD
<ogra> seb128, poke ... where is that rhythmbox upload you talked about ? do i need to unseed it to get images ?
<seb128> ogra, it's coming today, I ran into other issues yesterday and didn't get it done
<pitti> ugh, seems that today's CDs grew by 70 MB, due to LibO?
<ogra> seb128, k
<ogra> pitti, switch to arm :) we still have space
<pitti> the language pack rebuild saved 50 MB
<pitti> and LibO added 130
<pitti> ah, it now pulls in Java
<pitti> openoffice.org-common (17.0 MB)
<pitti> libreoffice-common (36.6 MB)
<pitti> ah, the langpack rebuild saved 8.5, sorry
<debfx> Riddell: could you please reject mumble from lucid and maverick-proposed, it will be handled by a security upload
 * ogra sighs about 160 bugs in his bugmail
<ogra> bah
<ogra> and most of them seem to be expired installer bugs ... i wonder if thats ok
<Riddell> debfx: ok
<pitti> ogra: those are the best kind, no action necessary :)
<ogra> pitti, i really doubt that, they were all marked incomplete by a script from some random guy while we were in florida
<ogra> i'm sure cjwatson would have liked to keep some of them open
<elif> Hi cjwatson , I would like to know if its possible to package partman.udeb inside initrd so I don't have to setup a mirror with my modified partman udeb, thks in advance ?
<elif> right now to test partman with modifications I need to setup a mirror, because my installation method is only by network (netboot).
<dpm> hi ev, may I ask you to export translations from LP and add them to ubiquity before A2? This way everyone can start testing them.
<ev> dpm: sure thing
<dpm> ev, awesome, thanks
<\sh> guys, did anyone saw this on lucid in the past few weeks: cron[4326]: segfault at 7f77c036a970 ip 00007f77c036a970 sp 00007fff81bd5bb8 error 4 in libnss_files-2.11.1.so[7f77e768b000+c000] ?
<htorque> hello everyone! i need some help (not support) figuring out if this is some bug with plymouth worth filing:
<htorque> http://img.xrmb2.net/images/787502.png - note the big gap after ureadahead finished, plymouth-debug.log: http://paste.ubuntu.com/556129/
<htorque> this is a tailored 2.6.38-rc1 with no swap and apparmor disabled (, i get similar boot times with ubuntu's kernel
<apw> htorque, does that graph say that plymouth is in an uninterruptible sleep ?
<htorque> apw, the plymouthd bar it's slightly red, so that should mean it
<htorque> i'll be off for an hour, i'll check irclogs, so if you need me to do something, go ahead :-)
<apw> htorgue, not seeing that on my system here, am seeing other issues but not that long gap, i suspect plymouthd is printing the dots hense the blips
<apw> the pause is likely something else
<dholbach> do we have any idea how to fix bug 688732?
<ubottu> Launchpad bug 688732 in pywebkitgtk (Ubuntu) "package no longer has WebView attribute after transition to python 2.7" [High,Triaged] https://launchpad.net/bugs/688732
<cjwatson> elif: I'm not going to change the initrds we ship to do that, if that's what you mean.  there's documentation in the d-i build system for how to add packages to it if you want to do it locally.
<elif> cjwatson: I meant locally (my installation). I didn't find the docs you mentioned, could you point me ?
<elif> cjwatson: its d-i docs ?
<cjwatson> build/README in the debian-installer source package
<cjwatson> easiest way is to list the names of udebs you want to include in build/pkg-lists/local
<elif> cjwatson: thank you.
<tumbleweed> dholbach: no idea where that file came from. Submitter's system was installed with 10.10, which used python-support for pywebkitgtk, it still does. That location is a python-central/dh_python2 location.
<tumbleweed> dholbach: aah, 1.1.8-1 looks like the culprit
<phenom> Any one here?
<pitti> !ask | phenom
<ubottu> phenom: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<phenom> Not a question
<phenom> Wubi installer is broke
<phenom> Spits pyrun.exe says "no disk"
<phenom> and then says Can not downloan metalink, and therefor the ISO
<phenom> And dies
<phenom> I assume it runs on win 7
<apw> are you asking if it runs on win7 or saying you are running on something other than win7 (and assume it works on win7)
<phenom> I'm saying, I tried to run it on win7 and it gives me those errors
<phenom> and dies
<phenom> it spits the pyrun.exe says "no disk" error about 15 or so times
<phenom> and then continues through the installer, after I input the password if spits it can not download the metafile and therefor can not download the iso
<cjwatson> which version?
<phenom> rev 190
<phenom> the one from http://www.ubuntu.com/desktop/get-ubuntu/windows-installer
<cjwatson> ev: ^- can you look at that?
<ev> cjwatson: yup
<ev> phenom: can you pastebin %TEMP%/wubi-10.04.1-rev190.log
<didrocks> kees: hey, if you can do a security review on https://bugs.launchpad.net/ubuntu/+source/dcmtk/+bug/702026, that will be nice :)
<ubottu> Ubuntu bug 702026 in dcmtk (Ubuntu) "[MIR] dcmtk" [Undecided,Incomplete]
<phenom> ev, pm
<ev> phenom: thanks, I'll have a look after lunch
<phenom> Sure, thanks
<ari-tczew> didrocks: #ubuntu-hardened is good place for that question :)
<didrocks> ari-tczew: I just ask for a security check on a MIR process, that can take some days, so I'm not sure I'll stay in #ubuntu-hardened there I think I hilighted the right person about it and it's done :)
<htorque> apw: thanks for the feedback. i will keep an eye on it with mainline and ubuntu kernels once they are out - maybe it's just a misconfigured kernel on my end.
<apw> htorque, ubuntu kernels will be a while as 32 don't boot on my test boxes
<htorque> apw, yeah, i had to revert that commit about relocatable kernels you mentioned (it was not enough to just disable that option)
<apw> i had to do that indeed, which worked for 64 bit, but my 32 bit box is failing to enable the timer
<apw> and exploding
<smoser> @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: smoser
 * dholbach hugs smoser
<cjwatson> pitti: FYI, I'm wrestling with my last couple of bugs for the lucid SRU freeze ... expect uploads over the next hour or two
<cjwatson> trying to make USB stick upgrades not suck
<pitti> ack
<ari-tczew> smoser: have you got upload access for main?
<smoser> no
<kklimonda> what's the process for dealing with regression-proposed bugs?
<smoser> otherwise i would sponsor your changes. (i guess you're looking for sponsor for 705294)
<kklimonda> good afternoon btw.
<ari-tczew> hello kklimonda
<ari-tczew> smoser: nope, I'm looking for sponsor for main
<kklimonda> (the process after marking sru bug as verification-failed, and the new one as regression-proposed, and nominating it for release)
<ari-tczew> smoser: then you're weak patch pilot if you don't have upload access for main
<smoser> i agree i'm a weak patch pilot
<kklimonda> ari-tczew: you were also a patch pilot other day
<smoser> i go through the sponsor list and see if i can make job easier for others.
<ari-tczew> kklimonda: yes
<smoser> bug 705294
<ubottu> Launchpad bug 705294 in openmotif (Ubuntu) "[FTBFS] Source openmotif 2.3.3-5 Natty" [Undecided,In progress] https://launchpad.net/bugs/705294
<ari-tczew> smoser: what is wrong with above? ^^
<smoser> ari-tczew, nothing. i just assumed thats what you had a fix for and were asking for a sponsor of.
<ari-tczew> smoser: I still understand.
<ari-tczew> don't understand *
<ari-tczew> I'm sponsoring 2 bugs for udienz right now.
<smoser> never mind then. i was confused.
<ari-tczew> I'm looking for main sponsorship for 2 things which I reviewed.
<smoser> ah.
<ari-tczew> https://code.launchpad.net/~barry/ubuntu/maverick/computer-janitor/bug-665740/+merge/46039
<ari-tczew> https://code.launchpad.net/~om26er/ubuntu/maverick/nautilus/nautilus-fix-630512-maverick/+merge/45048
<ari-tczew> https://code.launchpad.net/~clint-fewbar/ubuntu/karmic/mysql-dfsg-5.1/mysql-sru-343870/+merge/42667
<ari-tczew> update, 3 things
<ari-tczew> and I don't understand why patch pilots didn't find main sponsor for these patches
<pitti> doko_: do you know about the "pystack" gdb feature?
<Chipzz> ari-tczew: well, for one, the "fix" for https://code.launchpad.net/~barry/ubuntu/maverick/computer-janitor/bug-665740/+merge/46039 looks OBVIOUSLY incorrect
<Chipzz> you should fix the python-dbus package instead of working around a bug in it
<barry> Chipzz: perhaps, but would that have too much impact for an sru?
<ari-tczew> Chipzz: hehehe, you're looking for hole in the whole
<ari-tczew> the subject is a response for core-dev
 * Chipzz looks at his screen and tries to decipher what ari-tczew is saying
<Chipzz> no offence meant, but your English is quite poor
<ari-tczew> Chipzz: nobody is perfect, maybe you?
<Chipzz> barry: there's the question of what you should fix in an SRU in the first place; ignoring wether that bug is a candidate or not, fact is you should try to keep the changes minimal, which among other things means trying not the fix the same issue in different ways; and since you most likely want to fix the issue in the development release too, and you want to do it the proper way there, I think the best thing to do would be to fix it in python-dbus
<Chipzz> ari-tczew: sigh :p
<Chipzz> ari-tczew: I was looking at your sentence for 10 seconds, trying to understand it. then I looked again. and then I gave up trying to figure it out
<soren> I'm not sure why python-dbus should depend on dbus?
<barry> btw, python-dbus depends on libdbus-1-3
<barry> which makes sense, but i think soren has a point
<barry> and libdbus-1-3 recommends dbus
<Chipzz> I don't see why computer-janitor should depend on dbus actually
<soren> Now that is a different matter. I don't know.
<barry> Chipzz: because the core functionality is in a dbus service (in >=maverick)
<asac> csurbhi: hey ... quick question. mkfs.btrfs has no -U option. are uuids not supported for btrfs?
<Chipzz> barry: errr, I'm just making a wild guess here, but how about "No Scott"? :p
<Chipzz> barry: you don't have every pygtk application depending on libgtk now, do you?
<barry> Chipzz: now you're not making sense :)
<Chipzz> barry: if your app talks to dbus via python-dbus, then the dependency is on python-dbus, not dbus
<cjwatson> c-j also ships its own dbus service; it isn't merely a client
<barry> Chipzz: i think it's a different case.  libgtk is a library but dbus is a service
<Chipzz> cjwatson: then it's a matter of how the dbus service interfaces with dbus, isn't it?
<cjwatson> at least some other packages that ship dbus system-services depend on dbus directly (e.g. consolekit)
<cjwatson> there is clearly precedent
<cjwatson> system-tools-backends
<cjwatson> avahi-daemon, network-manager
<cjwatson> etc.
<Chipzz> barry: imo they're both bindings, which is why the 2 cases should be treated the same
<barry> Chipzz: i think the analogy would be to libdbus though, not dbus
<cjwatson> depending on dbus directly seems correct to me.  it's relying on the dbus daemon directly and the dependency should be direct.
<cjwatson> I'm happy to sponsor that SRU as written
<cjwatson> (and will do so shortly
<cjwatson> )
<barry> cjwatson: thanks.  Chipzz and ari-tczew thanks also for the feedback. :)
<Chipzz> cjwatson: if you think it's correct, I'll stop arguing about it, but it still looks wrong to me
<ari-tczew> Chipzz:  :) :) :)
<Chipzz> but I have to go offline anyway
<cjwatson> I think it's correct and that your analogy is faulty given the specifics of this package, yes
<soren> Chipzz: They're not both bindings.
<soren> Chipzz: dbus is the daemon.
<cjwatson> if you were talking about libdbus, the analogy would be sound
<cjwatson> but that's not (only) what's at issue here
<Chipzz> cjwatson: my reasoning is that the dependency chain should likely be app -> python-dbus -> libdbus -> dbus
<cjwatson> that reasoning is faulty, because this application uses dbus in ways other than via python-dbus
<Chipzz> since it makes little sense to have an app linked against dbus (be it client or service) without having dbus available
<cjwatson> specifically by shipping a dbus system-service
<Chipzz> anyway gtg
<pitti> Chipzz: think of optional plugins
<pitti> Chipzz: e. g. bzr-gtk annouces commits over session dbus, but it's only a bonus feature; so bzr-gtk would certainly depend on python-dbus (to not crash), but not on dbus (since it works without)
<soren> You can also use libdbus without the dbus daemon.
<soren> upstart does, for instance.
<cjwatson> right, and in any case inserting an extra dependency further down the stack has *more* risk of regressions, not less, so I'd argue it'd be less appropriate for an SRU even if it were correct (which I don't think it is)
<pitti> *nod*
<barry> cjwatson: right, that was my thinking too
<doko_> mvo: ping http://launchpadlibrarian.net/61917866/buildlog_ubuntu-natty-i386.update-manager_1%3A0.145.10_MANUALDEPWAIT.txt.gz
<doko_> siretart: ping
<barry> so, here's an unrelated, but general question.  i've seen this a few times with packages i'm doing test builds with (latest example: python-webkit).  i branch the source from ubuntu:python-webkit, then bzr bd -S (or debuild -S).  dpkg-source exits w/status 255 because "Version number suggests Ubuntu changes, but Maintainer does not have Ubuntu address".  this is true, but what's the right way to handle this for local builds?  i've just
<barry> been running update-maintainer before doing a local build, but why hasn't that already been done for a -XubuntuY version?
<doko_> pitti: libreoffice-common: is this still true with the -2ubuntu2 version?
<cjwatson> probably because the last person who changed it in Ubuntu doesn't have @ubuntu.com in their DEBEMAIL so dpkg-source didn't error out on that
<cjwatson> for quick local builds, I usually do DEBEMAIL=something@else debuild ...
<cjwatson> (I might mean debuild -eDEBEMAIL=something@else ..., I forget)
<pitti> doko_: seems to be the same size as ubuntu1, according to https://launchpad.net/ubuntu/+source/libreoffice/1:3.3.0~rc3-2ubuntu2/+buildjob/2183350
<barry> cjwatson: ah, i didn't realize dpkg-source looks at DEBEMAIL (not obvious from manpage afaict).  thanks
<cjwatson> it was a hack to try to get people to DTRT in their uploads without impeding *too* many people's local builds when people get it wrong
 * barry loves social change by technological hack :)
<Laney> DEBEMAIL= debuild works, yeah
<barry> yep, wfm, thanks!
<Laney> it at least means that most uploaders remember, even if the contributor does not
<cjwatson> my other dodgy hack along those lines is that I occasionally do debuild -ePATH=$HOME/fake-debconfpo:$PATH -S
<cjwatson> where $HOME/fake-debconfpo is a directory containing only a symlink from debconf-updatepo to /bin/true
<soren> Heh.
<cjwatson> this is helpful in cases where packages call debconf-updatepo on build and I don't want them to (e.g. because I'm building for lucid on natty and gettext's default header has changed)
<cjwatson> just about anything can be worked around if you try hard enough ...
<JamesPage> zul, daviey, kirkland: who's picking up bugs for cobbler now its in archive?
<zul> JamesPage: server team is already subscribed to the bugs so I guess all of us
<kirkland> JamesPage: all of us :-)
 * kirkland knuckle bumps zul 
<JamesPage> :-)
<doko_> pitti: I see, -common has the images_*.zip for all styles, see bug #696527
<ubottu> Launchpad bug 696527 in libreoffice (Ubuntu Natty) "LibreOffice - Human icons theme disabled, patch needs an update" [High,Confirmed] https://launchpad.net/bugs/696527
<pitti> doko_: aah, thanks
<pitti> doko_: so I guess we'll need to keep that around for now, and just drop the -writer recommends for JDK?
<cjwatson> pitti: casper and grub2 uploads in {lucid,maverick}-proposed, fixing sabdfl bugs ;-)
<cjwatson> csurbhi: did you get anywhere with that milestoned util-linux bug?
<csurbhi> cjwatson, i am still working on the installer btrfs thing
<csurbhi> i will get at the bug soon and shall try to do it before Sat
<doko_> pitti: yes, I'll do that.
<pitti> doko_: danke sher
<doko_> how urgent is this?
<cjwatson> csurbhi: oh - as I said in yesterday's meeting, the lucid SRU freeze (for 10.04.2) is today
<pitti> doko_: by alpha-2, I think (since currently we have a 62 MB oversizedness which we can't fix by langpack dropping)
<cjwatson> should I find somebody else to look at it?
<pitti> doko_: alternatively we can just unseed it for a2, and put it back later
<csurbhi> cjwatson, i am not sure i will be able to finish by eod
<csurbhi> but i can try it
<cjwatson> ok, thanks
<csurbhi> ok
<csurbhi> since there is a patch to the bug already
<cjwatson> let me know if somebody in a more western timezone needs to pick it up
<pitti> cjwatson: (talking to folks at the hackfest ATM, will look at it in a bit)
<csurbhi> cjwatson, no let me first try doing it
<csurbhi> i will get back in an hour or two
<csurbhi> if i think i cant
<cjwatson> ok
<doko_> pitti: ok, this seems to be doable. I'd like to avoid dropping -writer
<cjwatson> pitti: np, thanks
<doko_> pitti: just want to wait for the armel builds
<pitti> sounds good
<kees> didrocks: if you haven't already, please assign ubuntu-security to the mir, and I'll pick it up when I start work this morning :)
<didrocks> kees: excellent, will do, thanks:)
<doko_> Riddell: could you have a look at the telepathy-qt4 build failure?
<Riddell> doko_: I'll add it to my todo list
<achiang> kirkland: hi, can i bug you again?
<kirkland> achiang: sure, hit me
<achiang> kirkland: just wondering why i'm seeing this: http://chizang.net/alex/tmp/Screenshot.png
<achiang> kirkland: and i do have kvm module loaded...
<kirkland> achiang: natty?
<kirkland> achiang: what is the output of 'kvm-ok' ?
<achiang> maverick
<kirkland> achiang: ^
<achiang> kirkland: ah. says i don't have it enabled in BIOS
<achiang> kirkland: so i'll go do that
<achiang> thanks
<hallyn> when exactly does <package>.postinst get called?  I assume it's after 'binary_arch: install' from debian/rules?
<cjwatson> hallyn: well after - when the user calls dpkg --configure (perhaps via dpkg -i, perhaps via apt-get, etc.)
<cjwatson> so on a completely different machine from that running debian/rules in most cases
<hallyn> oh.   hm.
<hallyn> so if files are being installed which should belong to a new groupname, if that groupname is created in the .postinst, is that good enough?  I was thinking the system would refuse to create files owned by nonexisted group
<kirkland> achiang: yup
<cjwatson> hallyn: if the files are being created at run-time (e.g. in the postinst, or when the program is run), then the postinst is good enough
<cjwatson> (and Depends: adduser)
<cjwatson> hallyn: if you're shipping these files in the .deb, then you need to run adduser in the preinst, and Pre-Depends: adduser
<achiang> kirkland: hm, BIOS claims that VT-D and VT-X are turned on, yet kvm-ok disagrees
<cjwatson> hallyn: http://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
<achiang> kirkland: is there a better channel we could debug this in? seems a little OT for here
<hallyn> cjwatson: thanks, that was my guess, except i had no idea about Pre-Depends
<kirkland> achiang: either here, or #ubuntu-server, or #ubuntu-cloud;  i'm in all of these, it's okay in any of them, IMHO
<pitti> cjwatson: ok, lucid SRU queue empty; need one reupload from Micah (mailed him), rest looked o
<pitti> k
<achiang> kirkland: how about #ubuntu-virt?
<kirkland> hallyn: is this for kvm?
<pitti> good night everyone!
<cjwatson> pitti: yay, thank you
<kirkland> achiang: #ubuntu-virt -> #ubuntu-cloud
<achiang> ah
<cjwatson> pitti: I'll do a CD build pass tomorrow
<pitti> cjwatson: we have a hackfest group dinner now, so I'm afraid you or slangasek need to handle the other stragglers today
<pitti> cjwatson: cool, thanks
<kklimonda> what's the process for dealing with regression-proposed bugs?
<kklimonda> (the process after marking sru bug as verification-failed, and the new one as regression-proposed, and nominating it for release)
<pitti> kklimonda: by default, the previous uploader should upload a fix
<pitti> if it's a serious regression, we can also remove a package from proposed
<kklimonda> pitti: ok, thanks
<kklimonda> pitti: I bump the version, add a new changelog entry and create source package in a way that displays both changelog entries in the changes file?
<pitti> kklimonda: right, using debuild -vVersionInUpdates
 * pitti needs to run now
<hallyn> kirkland: yeah
<hallyn> kirkland: this is why on first-ever qemu installs, /dev/kvm is owned by root :)  on second attempt, when we ask them to re-try it works fine :)
<hallyn> (someone complained last week about the same thing, right?)
<kirkland> hallyn: i've seen recent complaints;  is this something that got dropped in the last merge?
<kirkland> hallyn: as i don't think we've seen this before that
<hallyn> that's the weird thing, i don't think this ahs changed.  at least i don't remember playing with it.  but let me check the maverick sources
<hallyn> you know, for all the compalints ppl have about compiz, one great thing about it is that vnc doesn't insist on redrawing every time i put a window over it or switch viewports
<SpamapS> :)
<hallyn> kirkland: hell - have you restarted the machine since installing kvm?
<kirkland> hallyn: nope
<hallyn> hah, THAT's it
<SpamapS> cool.. they're going to film a movie on my street on Saturday
<kirkland> hallyn: ?  really
<hallyn> it's a udev rule, so next time it'll work jsut fine.
<kirkland> hallyn: hmm, do we need to trigger a reload or something postinst?
<hallyn> i'm just moving group creation to preinst
<kirkland> hallyn: because "reboot your machine after installing kvm" is kinda silly
<hallyn> :)
<SpamapS> not cool ... I have to move my car off the street by 8am
<hallyn> SpamapS: you shouldn't have a car, polluter
 * hallyn njoys making CA jokes
<SpamapS> No I don't pollute.. I only use 91 octane.. its clean right? ;)
 * hallyn pulls on the brakes before heading into dangerous political territory
<hallyn> instead i'll comment on the tiny 'bottomless' cup they gave me today
<hallyn> bright side, coffee doesn't have tiem to get cold
<hallyn> hm, i installed nmh (and also tried mailutils-mh), but scan is not being installed.  anyone familiar with this?  (on natty)
<smoser> @pilot-out
<udevbot> Error: "pilot-out" is not a valid command.
<smoser> @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> oh, i see
<ogra> wohoo
 * ogra hugs seb128 
<ogra> thanks for RB
 * ogra prays that it builds now
<seb128> ogra, you're welcome
<kees> slangasek: you mentioned Keybuk might have thought about global environment vars in upstart?
<slangasek> kees: yes, it's something I recall discussing with him in the past
<slangasek> I believe he thought about it harder than I did :)
<slangasek> though we did talk about the role of pam in upstart and I believe we agreed that its role is "none"
<slangasek> at least for the presently supported job types
<bcurtiswx_> "src/Makefile.am: object `empathy-accounts-dialog.$(OBJEXT)' created both with libtool and without"  What does this build error mean?
<kees> slangasek: right, I too view PAM and upstart and disjoint
<kees> s/and/as/
<kees> slangasek: but did anything come of his hard thinking, do you know?
 * kees wants to set MALLOC_PERTURB_=85 just to see what happens...
<slangasek> kees: nope, you'd need to check with him
<slangasek> or with James
<bryceh> kees, do you know of any recent kernel plumbing-layer changes that would have made apport start collecting xserver crashes once again?
<kees> jhunt: do you know anything about possible way to set global env vars in upstart?
<bryceh> (I'm pleased to see them, but the retracer is not handling them properly yet)
<kees> bryceh: nope, but when it stopped, it was a mystery too, so maybe something changed with the toolchain.
<kirkland> does anyone else running natty have a sustained load of pretty much exactly 1.00 at idle?  (note that I have 4 CPUs...)
<cjwatson> slangasek: does that need to change when upstart starts supervising user sessions?
<cjwatson> (lp:~canonical-scott/upstart/session-support)
<SpamapS> kees: I've looked into it. upstart only copies things from the job's  env stanzas and its own special vars (UPSTART_EVENTS, JOB, etc).
<SpamapS> kees: and things from the event
<slangasek> cjwatson: I imagine so
<slangasek> cjwatson: what does it mean to "supervise" a user session?  will upstart be handling the authentication?
<kees> kirkland: your load came from that kernel thread (ps auwwx | grep " D ")
<kirkland> kees: right
<kirkland> kees: root       667  0.0  0.0      0     0 ?        D    Jan19   0:07 [ips-monitor]
<kirkland> kernel guys: what is "ips_monitor" ?
<directhex> tkamppeter, is there a better way to add a missing PPD to upstream openprinting other than "bug you about it"? I can't find a thing on the linuxfoundation-based site
<kees> lsmod | grep ips  ?
<cjwatson> slangasek: no idea, I know about the branch's existence but haven't really looked at its contents
<SpamapS> slangasek: btw, is there anything you need from me on the statd/portmap SRU? I don't mind doing the backporting work.
<cjwatson> I don't *think* it does auth - I think it's more about partitioning off chrooted and user jobs so that they can't interact with system jobs
<tkamppeter> directhex, no. There is a page to add a printer, but not to upload a PPD. What PPD is that?
<directhex> tkamppeter, two more kyocera ppds which, helpfully, aren't in their main ppd bundle
<slangasek> SpamapS: the SRUs have been uploaded, please validate them? :)
<SpamapS> slangasek: oh I didn't see that!
<directhex> tkamppeter, bottom of http://www.kyoceramita.co.uk/index/products/download_centre.false.driver.FSC2126MFP._.EN.html
 * SpamapS is about 2 hours behind on email.. 
<ebroder> slangasek, cjwatson: my understanding was that "user sessions" was just about letting users have a ~/.upstart with jobs that could only run as them. i don't think they run under a PAM session or anything currently, though it seems like they probably should
<ebroder> (that's what i remember seeing on the branch, anyway)
<tkamppeter> directhex, is this one PPD (for yopur printer) or a series of PPDs?
<directhex> tkamppeter, it's two ppds for two near-identical multifunction devices (only difference is the fax, and i don't think the ppd supports that anyway)
<directhex> tkamppeter, seems they've been localized, so 6 pairs of PPDs for the FS-C2026MFP and FS-C2126MFP - where the only difference between the two is the product names in the PPD
<directhex> -*Duplex None/Ninguno: "statusdict begin false setduplexmode false settumble end"
<directhex> +*Duplex None/None: "statusdict begin false setduplexmode false settumble end"
<slangasek> ebroder: so integration with pam there buys you: - kerberos/afs credentials for the job; - honoring of pam_limits; - incompatibility with pam_ck_connector
<kees> SpamapS: is there any movement towards having a place for global env vars too?
<SpamapS> kees: I've not discussed or heard anything about it. I was looking to see how we could take advantage of the kernel passing its cmdline to init in the env.
<kees> ah-ha
<SpamapS> kees: it would make perfect sense for it to end up in /etc/init.conf though
<kees> SpamapS: are there plans for such a file?
<SpamapS> it exists now
<SpamapS> and must be 0 bytes
<SpamapS> or rather, it can exist now
<SpamapS> kees: so just have to parse the env stanza from there, and have upstart add that to things it copies into a new instances' environment.
 * SpamapS just abused the apostrophe .. poor apostrophe
<kees> "must be 0 bytes" ?
<SpamapS> kees: yeah, it parses the file, but there are no allowed stanzas
<kees> hahah best config file evar
<SpamapS> might be possible to put comments in it. I'm parroting jhunt's statement that it must be empty there.
<SpamapS> "you can configure it any way you like, as long as you leave it blank"
<SpamapS> (paraphrased) -- Henry Ford
<bcurtiswx_> if i wanted to check to see if a builder reaches a certain part of code, is there a code I can cause it to pause with an echo statement ?
<directhex> tkamppeter, you know, there seem to be lots of models like this. i wonder if they have a unified ppd tarball anywhere
<ebroder> slangasek: PAM integration couldn't get you credentials because it doesn't have access to any. that's only any good if you're running through the password stack
<cjwatson> bcurtiswx_: 'echo foo; sleep 3600' or whatever?
<cjwatson> why pause?  is this for a local build?
<bcurtiswx_> cjwatson, http://paste.ubuntu.com/556278/ is my fail
<slangasek> ebroder: I'm presuming that the job is being spawned from within a user login session, so the creds are already available in the environment and just need to be copied/preserved for use
<bcurtiswx_> so i went to empathy-chat-window.c and a patch adds "#include empathy-indicator-manager.h" so it _should_ see it
<bcurtiswx_> cjwatson, ^^
<bcurtiswx_> im just trying to debug, see if it enters a ifdef with the header definitions
<cjwatson> bcurtiswx_: you want gcc -E -dD
<cjwatson> bcurtiswx_: that's not a missing #ifdef, though, that's an incorrect link line
<sveinse> How I can start the pulseaudio daemon when not in X on maverick? I need sound, but the system is not running X, however I fail to start the PA daemon
<bcurtiswx_> cjwatson, where is this done.. im using pbuilder
<cjwatson> bcurtiswx_: any symbol used by empathy-chat-window.o must be placed *after* empathy-chat-window.o on the link line ('gcc -g -O2 -g -O2 -Wl,-Bsymbolic-functions -o empathy-chat ...')
<sveinse> someone knows where and how PA is started during X11 user login?
<cjwatson> pbuilder is irrelevant
<sbeattie> bcurtiswx_: something wants to link against libgtk-x11-3.0; however -ltk-x11-2.0
<sbeattie> is being linked against.
<cjwatson> well, there's that too, but that isn't the cause of the errors after it
<bcurtiswx_> hmm, this is where i'd be lost.  https://code.launchpad.net/~bcurtiswx/ubuntu/natty/empathy/empathy-2.91.5 is where i've pushed the patches.. i think you'd want to see debian/patches/20_libindicate.patch
<bcurtiswx_> cjwatson, ^^ or where would I look to fix this
<cjwatson> I imagine you need to add empathy-indicator.c to empathy_chat_SOURCES in src/Makefile.am (or something along those lines)
<cjwatson> you need to link the objects you're using
<cjwatson> (empathy-indicator-manager.c too)
<bcurtiswx_> cjwatson, i have done that.. then I have to keep adding a whole bunch of .c and .h files to the chat_SOURCES
<cjwatson> then you probably forgot to rerun automake
<cjwatson> automake generates src/Makefile.in from src/Makefile.am
<bcurtiswx_> cjwatson, oh, where would I  make it do that then?
<cjwatson> get #ubuntu-desktop to help you integrate that into the package, they do this all the time and have their own patterns
<cjwatson> mind you /usr/share/cdbs/1/rules/autoreconf.mk is supposed to do that
<cjwatson> god knows, I can't stand cdbs :)
<bcurtiswx_> i've been working on and off with seb128 and kenvandine
<bcurtiswx_> actually..
<bcurtiswx_> so somehow I have to get it to rerun automake after the patches are added
<cjwatson> the way your package is set up, it should be doing that automatically already
<bcurtiswx_> i'll ask in -desktop
<cjwatson> anyway, if it were me, I would be very carefully looking through the build log to see if autoreconf is being run; then I would compare the failing gcc line printed in the build log with what's in src/Makefile.am and src/Makefile.in
<cjwatson> and probably src/Makefile for good measure
<cjwatson> if those three files don't match I'd go looking for problems in the generation code somewhere
<nxvl> juliank: ping
<tkamppeter> directhex, I must look into Kyocera's PPDs. If they do not have a unified tarball, I do not see any possibility to get the PPDs being added to distros or made auto-downloadable via OpenPrinting.
<cjwatson> if they match, then I'd run the gcc line by hand with variations until it works, and then reintegrate those variations back into the patch to src/Makefile.am
<cjwatson> debug it iteratively and be scientific about it
<directhex> tkamppeter, it looks horribly manual right now. i mean, the PPDs are all properly licensed and redistributable, but who wants to go to every device's drivers page to grab a single ppd?
<directhex> tkamppeter, there seem to be humans on their UK twitter account, i'll see if anyone responds
<juliank> nxvl: pong
<nxvl> juliank: i added some more info to Bug #704595, and i was wondering if you can give me some guidance to fix it, cause i have no experience with apt's code
<ubottu> Launchpad bug 704595 in apt (Ubuntu) "Python-apt shows emply origins object" [Undecided,Confirmed] https://launchpad.net/bugs/704595
<juliank> bcurtiswx_: autoreconf should run after patches were applied, as dpkg applies the patches, and then debian/rules is run
<bcurtiswx_> juliank, cjwatson, autoreconf does run
<juliank> nxvl: I have no idea why apt fails
<nxvl> juliank: mvo told me a while ago that was an auth issue, with the keyring and such, as it seems it's looking for a keyring inside the chroot, instead of the system chroot
<nxvl> juliank: therefor failing
<bcurtiswx_> juliank, cjwatson: as seen here http://paste.ubuntu.com/556287/
<juliank> nxvl: It also doesn't work when copying the keyring
<nxvl> juliank: oh, didn't tried that, have you?
<juliank> bcurtiswx_: Looks correct to me.
<ScottK> doko_ or barry: Any thoughts on http://launchpadlibrarian.net/62538907/buildlog_ubuntu-natty-i386.python3-defaults_3.2~rc1-1_FAILEDTOBUILD.txt.gz - It didn't fail when I test built it.
<superm1> manjo, since you're doing testing on the SDP again with uefi, were you planning on testing both CD and USB installs this go around for natty?
<manjo> superm1, yes
<manjo> superm1, both works with this fix: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/702707
<ubottu> Ubuntu bug 702707 in grub2 (Ubuntu) "grub-install fails to run due to missing grub_mkdevicemap" [High,Fix released]
<cjwatson> oh good, that fixed the other bug you reported then?
<cjwatson> ah, you duped it
<bdmurray> cjwatson: were you going to look at bug 701954?
<ubottu> Launchpad bug 701954 in console-setup (Ubuntu Natty) "initramfs hook fails with ".: 17: Can't open /etc/default/keyboard" when /etc/default/keyboard doesn't exists for some reason" [High,Triaged] https://launchpad.net/bugs/701954
<ScottK> doko_ and barry: Try to install python3 on natty ....
<cjwatson> bdmurray: that's what I get for not testing my fixes.  fixing properly
<cjwatson> wow, damn, that's a lot of dups, sorry for not being caught up on bugmail
<m_conley> cjwatson:  ping
<cjwatson> m_conley: hi
<cjwatson> (best to just say what you want up-front)
<highvoltage> the ubuntu website says on http://www.ubuntu.com/project "Ubuntu is made for sharing. Use it, modify it, improve it, share it. Anywhere, any time and with any number of people all over the world. No licence required."
<m_conley> cjwatson:  cool.  I'm trying to get Natty Alpha 1 up on VirtualBox4, and I keep running into this message during install, and then hanging:  http://i.imgur.com/K4AJ4.png  .  This happens regardless of whether or not I choose to install updates during install.  Any ideas or suggestions?
<highvoltage> is it just me or is the "no licence required" part a bit icky?
<cjwatson> m_conley: dunno, would need to see the log file it mentions
<m_conley> cool, I'll try to fetch that...
<cjwatson> it might be that a daily build would work better
<cjwatson> the way the archive works, it's sometimes possible for changes after a milestone to break the milestone, unfortunately
<m_conley> I started with daily builds, but I was having an even harder time getting those ones up on VirtualBox
<mjr> highvoltage, I'm not sure if it's icky, but it's technically incorrect ;)
<m_conley> with even more brutal errors (scary OS numbers and stuff on boot, then hang)
<cjwatson> "no licence required for use" would be correct
<cjwatson> well, no further licence
<cjwatson> or something
<cjwatson> I know what it means but it could use some wording that's similarly concise and friendly but actually true
<highvoltage> ore even "no license costs" would be better imho
<cjwatson> m_conley: generally it's useful to give the exact error messages :-)
<m_conley> cjwatson:  I understand.  Give me a few minutes, and I'll supply it.
<cjwatson> the scary OS numbers might happen to be ones I can help with
<m_conley> cjwatson:  gotcha.
<cjwatson> (btw, about to finish for the evening; mail is good though ...)
<m_conley> cjwatson@canonical?
<cjwatson> or else hang around and I'll reply to messages when I'm back
<cjwatson> yeah
<m_conley> k
<m_conley> cjwatson:  I have your numbers
<m_conley> cjwatson:  1 min
<m_conley> cjwatson:
<m_conley> http://imgur.com/nZH7b
<m_conley> this occurs on boot.
<cjwatson> ok, you need to talk to kernel folks about that
<cjwatson> probably
<m_conley> cjwatson:  which kernel folks would you suggest?
<cjwatson> I don't know their internal structure - start with #ubuntu-kernel
<m_conley> cjwatson:  will do.  Thanks for you help, and good evening!
<cjwatson> I imagine they'll need more information than that, but will be better placed than I to suggest how to get it
<cjwatson> (I always use kvm, for starters ...)
<highvoltage> I had that too with i386, but not amd64, I'd guess that the kernel team will probably be aware of that by now
<highvoltage> (under kvm)
<m_conley> highvoltage:  oh, nice - maybe I'll try the 64.  Thanks.
<superm1> manjo, ah great to hear :)
<manjo> superm1, any news from your bios team regarding uefi issues on clients ?
<ebroder> slangasek: oh, interesting. that would imply much tighter env integration between upstart and the user's session than currently exists, but would be kind of cool
<ScottK> doko_ and barry: I filed Bug #705619
<ubottu> Launchpad bug 705619 in python3.2 (Ubuntu Natty) "Regression with Python 3.2 RC1 makes Python3 uninstallable" [High,Confirmed] https://launchpad.net/bugs/705619
<SpamapS> cjwatson: in discussing this with jhunt, we agreed that we'd like to get your input on this merge proposal which restores upstart's re-exec code: https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/restore-re-exec-code/+merge/45295
<SpamapS> cjwatson: in bug #672177 keybuk agreed this is "the right thing to do"
<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
<cr3> who's the upstart maintainer these days?
<SpamapS> jhunt
<SpamapS> tho keybuk will still tend to it on some level I hope :)
<barry> ScottK: thanks, i'll take a look at that
<ScottK> barry: Thanks.
<seb128> does order of .c files in makefile.am makes a difference?
<seb128> like
<seb128> empathy_chat_SOURCES =
<seb128> 	empathy-chat.c \
<seb128> 	empathy-indicator-manager.c
<seb128> does it matter if the empathy-chat.c is at the end or not?
<seb128> well the list does end with a 	$(NULL)
<seb128> trying to debug bcurtiswx_'s issue
<seb128> he gets
<seb128> am_empathy_chat_OBJECTS = empathy-about-dialog.$(OBJEXT) \
<seb128>         empathy-chat-manager.$(OBJEXT) empathy-chat-window.$(OBJEXT) \
<seb128>         empathy-invite-participant-dialog.$(OBJEXT) \
<seb128>         empathy-chat.$(OBJEXT) empathy-indicator-manager.$(OBJEXT) \
<seb128>         empathy-indicator.$(OBJEXT)
<seb128> but the build line stops the object list at empathy-invite-participant-dialog.o
<seb128> on http://paste.ubuntu.com/556278/
<seb128> well to empathy-chat.o rather
<ari-tczew> cjwatson: what do you think, shall we wait for lilo 23 in Debian?
<janimo> seb128, the object file that contains the missing symbol should be after the object file that uses it
<seb128> janimo, well that's coming from a empathy_chat_SOURCES definition
<janimo> I think it is due to the new linking flag, gold style
<seb128> so the source files order determine the objects order which needs to be right?
<janimo> being more restricitve
<janimo> yes
<janimo> maybe upstream did not test with our flags or with gold linker?
<seb128> janimo, it's a distro patch a contributor tries to get build on a new version
<seb128> they did change their makefiles though
<seb128> it was not clear that the order of the sources was important for the build
<seb128> thanks
<janimo> seb128, you're welcome. Actually the order of object files is important for the linker, and that is a search and replace of the source file list in the makefile
<Riddell> TheMuso: how used is at-spi compared to at-spi2?
<TheMuso> Riddell: at-spi long term is being deprecated.
<TheMuso> Riddell: however atm at-spi performs a little better than at-spi2, which will likely be solved in coming months.
<TheMuso> Riddell: I am hoping at-spi2 can be used for natty, working with upstrea to fix a few show stoppers atm.
<Riddell> TheMuso: could you read over this quickly when you have a moment?  jono wanted a report https://wiki.kubuntu.org/QtAccessibility
<TheMuso> Riddell: Sure.
<TheMuso> Riddell: Looks good.
<Riddell> great, thanks TheMuso
<TheMuso> np
<jono> Riddell, TheMuso thanks for your work on this, much appreciated
<TheMuso> jono: np
#ubuntu-devel 2011-01-21
<SpamapS> hrm.. libapache2-mod-wsgi is still python 2.6 only.. rebuild needed?
<ebroder> SpamapS: it is? packages.u.c lists both a mod_wsgi.so-2.6 and a mod_wsgi.so-2.7
<SpamapS> oh .. sorry my bad.. its just that if you install it you pull in 2.6
<SpamapS> with the symlink pinted at -2.7
<SpamapS> pointed even :-P
<TheMuso> c
<SpamapS> the letter you can swim in
<RAOF> Ok, rather than trying to figure this out myself, time to be lazy: How do I get libtool to accept libdrm-nouveau1a as the SONAME for a library?
<jono> anyone know how to file a bug in ubuntu-bug?
<jono> it seems 'ubuntu-bug ubuntu-bug' doesn't work :-)
<TheMuso> jono: you want ubuntu-bug apport
<TheMuso> since apport has ubuntu-bug
<jono> cool
<jono> thanks TheMuso!
<TheMuso> np
<TheMuso> But yes, giving ubuntu-bug an executable and have it work out the package for you would be a nice to have.
<RAOF> I thought that actually worked already?  man ubuntu-bug suggests it shouldn.
<ebroder> RAOF: i bet it works if you give it a full path to an execuable
<ebroder> *executable
<RAOF> That might be it, yes.
<ebroder> (note that ubuntu-bug appears to just dispatch between apport-{cli,gtk,kde}
<ebroder> )
<RAOF> How do I get libtool to accept libdrm_nouveau.so.1a as the SONAME for a library?
<hyperair> say, what are the backports procedures these days?
<micahg> hyperair: file a bug against the foo-backports project, test build, install, and run
<hyperair> micahg: and how fast to those requests actually get through?
<hyperair> iirc backports were a pretty slow process
<hyperair> with an overly huge queue and overwhelmed folk handling it
<micahg> hyperair: well, I haven't seen much recently, but there was a blueprint to improve things, I think the backporters are looking for people to help :)
<hyperair> i'd like to help :)
<hyperair> now where do i go to poke people about this..
<micahg> hyperair: ok, talk to ScottK
<hyperair> ScottK: so how do i help with backports?
<micahg> hyperair: there's this to get you started: https://help.ubuntu.com/community/UbuntuBackports#How%20to%20Help
<hyperair> ooh thanks
<hyperair> micahg: hmm, it looks like ubuntu developers are allows to upload to -backports.
<hyperair> this does speed things up
<micahg> hyperair: yes, but one is not supposed to unless it's been approved and is not a straight backport
<hyperair> micahg: approved by who?
<micahg> hyperair: ubuntu-backporters
<hyperair> micahg: you mean it isn't blocked by a backporting queue similar to -proposed?
<micahg> hyperair: it is, but the process isn't to just upload like proposed
 * hyperair groans
<micahg> in most cases, an automated backport should be used
<hyperair> alright
<micahg> hyperair: what are you trying to backport?
<hyperair> micahg: nothing at the moment, i was just trying to evaluate how much effort it would take to backport some of my packages
<micahg> hyperair: so leaf packages are easier than libraries or packages that require newer versions of libraries as all the rdepends need to be tested
<hyperair> yeah, i'm aware of that
<dholbach> good morning
<dholbach> pitti, heya - do we have any idea where the click/focus problem in natty comes from? was that the gtk update?
<\sh> moins
<\sh> can someone tell me, why we don't have any package (src/bin) of live-initramfs in maverick?
<alkisg> Hi, a dbus upgrade has come to Lucid, and bug #552404 breaks its installation in chroots (e.g. LTSP).
<ubottu> Launchpad bug 552404 in dbus (Ubuntu) "dbus fails to be configured in chroots" [Undecided,New] https://launchpad.net/bugs/552404
<pitti> Good morning
<pitti> dholbach: "the click/focus problem"? Seems to work well here
<dholbach> pitti, did you update and restart your session and use unity?
<alkisg> Working around the bug is not trivial, it requires editing dbus.postinst to add a "|| true" to a dbus-send command. Is it possible to send another dbus update to Lucid with that "|| true" added?
<zyga> pitti, click on titlebar but focus goes behind that window issue?
<dholbach> I have funny problems where my clicks don't do anything at all
<pitti> zyga: hm, maybe that doesn't happen with focus-follows-mouse
<zyga> pitti, probably not, I don't like that setting, anyway - different issue
<zyga> it still happens ~3 times a day for me
<tkamppeter_> pitti, hi
<pitti> hey tkamppeter_
<seb128> @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: seb128
 * dholbach hugs seb128
<pitti> seb128: happy piloting!
<seb128> pitti, hey, thanks
<tkamppeter> pitti, I have seen that you are heavily working on s-c-p. Are you planning that this should go into Natty?
<\sh> pitti: any clue why we don't have any version of live-initramfs in maverick?
<\sh> live-initramfs as source pkg or as binary pkg of live-boot in this case
<ogra> is bzr branch lp:<something> refusing connections for anyone else ?
 * ogra wonders if he missed a bzr downtime announcement
<cjwatson> it's refusing here too
<ara> yes, it is down for me as well, but I can't remember a scheduled down time
<ogra> IS is inspecting
 * soren upgrades to natty
<soren> Wow. It wants to download 1763M.
<cjwatson> SpamapS,jhunt: so I think I agree that we should include that restore-re-exec-code branch for 10.04.2, although I haven't read the code yet
<cjwatson> SpamapS,jhunt: when you change umountroot, remember that you'll need a suitable Breaks on upstart, or some other handling to avoid the situation where umountroot is waiting for a re-exec that will never happen because upstart is too old
<cjwatson> SpamapS,jhunt: I dropped one comment into the mp
<elif> cjwatson: just to get a startup on howto build d-i for ubuntu, I mean create a .iso with the debian installer taled for ubuntu (rebranding, extra-features) is there a easy tutorial or somehow ?
<cjwatson> elif: not AFAIK
<cjwatson> doko_: I don't understand why bug 686263 is assigned to canonical-foundations; most of us can't do anything about it, since what it needs is MIR review?
<ubottu> Launchpad bug 686263 in wsgi-intercept (Ubuntu Natty) "MIR needed (dependency of python-lazr.restfulclient)" [High,Confirmed] https://launchpad.net/bugs/686263
<Chipzz> pitti: hrrrm good example
<Chipzz> I was trying to come up with an example where you would need libdbus but not dbus itself
<tkamppeter> pitti, around?
<pitti> tkamppeter: presumably not (just back from lunch)
<pitti> tkamppeter: it'll still take a while to port stuff over, and it won't (easily) work with GTK2
<sladen> cjwatson: that /etc/default/keyboard default brought up the textual debconf dialgoue again
<cjwatson> yeah I know
<cjwatson> I'm just about to try to whack that properly
<tkamppeter> pitti, so it is better that I package 1.2.6 for now, to get up-to-date with the stable series s-c-p (and go 1.2.7+ if it comes before FF)_?
<pitti> tkamppeter: yes, I think so
<pitti> tkamppeter: I don't think that the gi stuff will land in 1.3, given that the version number already looks like "1.3 beta" (1.2.96)
<pitti> tkamppeter: so we might switch to 1.3 eventually
<pitti> tkamppeter: I'll send the current patch to Tim, and then we can discuss how to proceed
<alkisg> >:o
<tkamppeter> pitti, OK, so I wait for Tim's answer to you with the next package of s-c-p, but generally I will stay with 1.2.x or perhaps 1.3.x.
<tkamppeter> pittim another problem is how s-c-p and jockey access the internet to download drivers via OpenPrinting. It does not support proxies. Can you fix that?
<soren> ARGH. NATTY STOLE MY CAPS LOCK AND LEFT IT ON.
<pitti> tkamppeter: I saw the email; I think urllib2 supports proxies
<directhex> tkamppeter, i'm expecting a phone call from kyocera uk at some point today about providing a monolithic "all ppds" download for openprinting purposes
<pitti> tkamppeter: I'll look into it, but not today
<pitti> tkamppeter: I'm still on the GNOME hackfest
<dholbach> soren, IZ GTK BOOG!
<dholbach> SCNR
<soren> SCNR?
<dholbach> daniel@miyazaki:~$ wtf SCNR
<dholbach> SCNR: sorry, could not resist
<dholbach> daniel@miyazaki:~$
<Chipzz> pitti: it does, but it doesn't support fetching https through proxies (if that would be relevant)
<tkamppeter> pitti, OK, next week would be OK for that.
<smb> pitti, Heya, I think we need to enable the same work-around in the power-management scripts in userspace (not sure it was a disable or rip out) we had  in Lucid for Maverick and even Natty. see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539467
<ubottu> Ubuntu bug 539467 in pm-utils-powersave-policy (Ubuntu Natty) "SATA link power management causes disk errors and corruption" [High,New]
<smb> pitti, Unfortunately there still seem to be some combinations of controller and disks around that get corrupted when sata alpm is enabled
<soren> dholbach: Any hints for a fix?
<dholbach> soren, no, sorry - I was just joking around
<soren> dholbach: Ah. Now I don't love you anymore.
<dholbach> soren, that was quick - who did you leave me for?
<soren> SOMEONE WHO CAN GIVE ME BACK CONTROL OVER MY CAPS LOCK KEY. :)
<soren> dholbach: Sorry, I'm slow today. I see what you mean now :)
<soren> dholbach: I didn't get it fixed until just now. My "no love" commen was written with my shift key held down :)
<dholbach> :)
<cjwatson> soren: edit /etc/default/keyboard; also edit /etc/default/console-setup; take the four commented-out XKB* lines at the end of /etc/default/console-setup, and replace the four XKB* lines in /etc/default/keyboard with those (uncommenting them in the process)
<ari-tczew> seb128: could you sponsor it? https://code.launchpad.net/~om26er/ubuntu/maverick/nautilus/nautilus-fix-630512-maverick/+merge/45048
<soren> cjwatson: Cool. Is that read at boot time or do I need to do something in particular to make it take effect?
<cjwatson> soren: it's read at boot; you can use setxkbmap to fix things up in X
<ari-tczew> seb128: please sponsor also https://code.launchpad.net/~om26er/ubuntu/maverick/empathy/empathy-fix-666288/+merge/45740
<soren> cjwatson: Ah, right. Awesome, thanks.
<directhex> tkamppeter, guy i spoke to from kyocera uk will try to convince central control at KM europe in germany to provide an "all ppds" download for easy use by openprinting
<ScottK> hyperair: The information micahg gave you was good.
<ScottK> hyperair: If there are backport requests that you think are ready for approval, please feel free to ping me with the bug number.
<hallyn> are we supposed to be in a natty alpha2 freeze right now?
<cjwatson> no
<hallyn> aweseome
<cjwatson> we're nearly two weeks away from alpha 2 yet
<hallyn> woudl you mind taking a look at https://code.launchpad.net/~serge-hallyn/ubuntu/natty/qemu-kvm/qemu-kvm-kvmgrp/+merge/46993 ?
<cjwatson> buried in plymouth right now - can you send me mail?
<hallyn> yup, thanks
<amitk> ebroder: bug 705912 filed against pango and subscribed you as requested
<ubottu> Launchpad bug 705912 in pango1.0 (Ubuntu) "No text displayed on live desktop on macbook pro" [Undecided,New] https://launchpad.net/bugs/705912
<amitk> ev: ^^^ you don't think this is an installer bug, right?
<ev> amitk: correct
<anwar> hi guys .. i have a simple question
<Proto> Hi guys. Quick question. How do you free memory that was allocated using the function readline from the gnu readline library? Thanks
<cjwatson> Proto: free ()
<cjwatson> Proto: the man page says it's allocated with malloc (), and the inverse of that is free ()
<Proto> well I user free() but dmalloc tool that I am using reports that there is a memory leak. I only had two lines in my code. the readline and the free.
<Proto> *used
<anwar> i'm a web developer and i work on windows environment..  and i want to develop on ubuntu .. where do i have to start ? there are alot of resources in the wiki page and it's a bit confusing for me because i'm a regular user to ubuntu .. can u tell me where to start ?
<Chipzz> anwar: pls ask in #ubuntu, your question is not appropriate for this channel
<micahg> anwar: you could also try #ubuntu-server
<anwar> thank u guyz .. sorry
<Chipzz> micahg: hrrrrm not really
<cjwatson> Proto: I'd suggest using valgrind and getting it to report the exact location of the leak
<Chipzz> micahg: (at least I think so)
<micahg> Chipzz: the apps needed for web dev on ubuntu are server apps :)
<cjwatson> sometimes libraries allocate themselves a bit of persistent state on initialisation or something, which isn't generally worth worrying about
<Chipzz> micahg: yes, but there's a difference between "I haven't bothered to read a 'how do I set up apache' tutorial" and "I have apache all set up, but this module doesn't work"/"there's a bug in this server package"
<micahg> Chipzz: indeed, but #ubuntu-server is also ubuntu-server-support :)
<Chipzz> micahg: yes, but even in support you can try to start somewhere yourself, like reading tutorials, before asking ;)
<Proto> cjwatson: thanks. I'll look it up.
<sladen> .wub
<bcurtiswx> ping bazaar.launchpad.net is failing here.. anyone else confirm?
<dholbach> bcurtiswx, http://identi.ca/launchpadstatus
 * bcurtiswx adds that to his identica
<bcurtiswx> thx dholbach
<dholbach> de nada
<hyperair> ScottK: alright, will do
<apw> pitti, it seems code hosting is in a heap.  that seems to be stopping the work-items stuff updating as it starts with a bzr pull ... should i disable that bit for the time being
<poolie> apw, http://blog.launchpad.net/general/code-hosting-offline
 * apw screams at OSD ... let my X server show me things while you are lost and confused and waiting to display poolies message
<apw> poolie, thanks
<cjwatson> doko: any progress on bug 684703?  the last comment on the bug is ScottK asking you for how to provide the information you requested; did you discuss that outside the bug?
<ubottu> Launchpad bug 684703 in gcc-4.5 (Ubuntu Natty) "Generated symbols different on different archs with gcc-4.5" [High,New] https://launchpad.net/bugs/684703
<ScottK> cjwatson: No discussion outside the bug that I recall (if there was, I need a refresh).
<SpamapS> cjwatson: ack, re upstart/sysvinit/etc. changes
<cjwatson> ScottK: ok, logged that in the bug with a ping
<doko> cjwatson, ScottK: are these non-virtual thunks referred to in other libs?
<SpamapS> cjwatson: re adding a breaks.. I was going to have it time out after 5 seconds of waiting.
<ScottK> doko: No.
<SpamapS> cjwatson: though probably good to have both isn't it?
<doko> sorry, s/libs/binaries/
<ScottK> They are non-virtual thunk.
<cjwatson> SpamapS: sounds plausible
<doko> ScottK: then why add these to the symbols files at all?
<ScottK> doko: It's what dpkg-gensymbols generates.
<ScottK> c++filt _ZThn16_N11KDcrawIface12RExpanderBoxD0Ev
<ScottK> non-virtual thunk to KDcrawIface::RExpanderBox::~RExpanderBox()
<ScottK> That's in libkdcraw9.symbols
<doko> ScottK: well, maybe ask buxy why he wants these mentioned in the symbols files?
<SpamapS> cjwatson: so, upstart should have    Breaks: libc6 ( << $version_that_disables_telinit_u ) ..
<ScottK> doko: They weren't different on different archs before.  Why now?
<SpamapS> cjwatson: and sysvinit would need Breaks: upstart ( << $version_that_adds_re-exec )
<buxy> I don't "pick" symbols, I take everything that's exported.
<ScottK> doko: I'm not a build system expert, but right now I have to test build that package on all archs to get a package that builds.  That's not supportable.
<ScottK> doko: See buxy's reply ^^^^
<cjwatson> SpamapS: right
<cjwatson> I think
<SpamapS> cjwatson: that should just help apt decide the order to configure things, right?
<cjwatson> yeah, it's not foolproof here
<cjwatson> well, though the libc6 telinit u is at configuration time
<SpamapS> postinst specifically
<cjwatson> that's the bulk of configuration :)
<doko> ScottK, buxy: well, symbols files shouldn't be used unreflected for C++ libs. Debian #605833 is another (unrelated) case
<cjwatson> I'm more hoping that it will prevent some of the more basic partial upgrade mistakes
<ubottu> Debian bug 605833 in gpsd "symbols file lists symbols from qt libs" [Important,Open] http://bugs.debian.org/605833
<buxy> doko: true, but MoDaX has done such work there that it gets more common...
<doko> buxy: which work?
<SpamapS> cjwatson: right, I think at some point we have to accept that if you install the new upstart and somehow force the old postinst to run.. you have broken your system, not dpkg/apt/ubuntu devs.
<buxy> doko: the possibility to map symbols by their demangled name
<SpamapS> I'd say with a Breaks: line, that shold be sufficient, but I am certainly not an authority on how breaks works in the real world.. only how its worded. :p
<buxy> and other similar stuff
<cjwatson> SpamapS: in practice the thing I care about is that if you say 'apt-get install sysvinit' it'll upgrade upstart and libc6 tooo
<cjwatson> *too
<cjwatson> Conflicts is likely far too invasive
<doko> ScottK, buxy: so if we agree that these thunks don't belong the interface, then maybe make them optional by default?
<SpamapS> cjwatson: I'll test for that scenario right now.. :)
 * SpamapS thinks it would be wise to always have a libc6 tree with the build step completed lying around.
<buxy> doko: I have no idea whether they belong to the interface or not, and I don't think that I want to have lots of special-cases in dpkg-gensymbols, in particular when these are difficult to identify (I don't want to always run c++filt)
<buxy> I rather suggest that the affected package uses the (c++) tag to match this symbol in arch-neutral way
<doko> buxy: well, these "special cases" are defined. http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
<bcurtiswx> cjwatson, remember the empathy build issues from yesterday?
<cjwatson> bcurtiswx: yes
<bcurtiswx> cjwatson, i have a new error i'd like to share with you and get some advice on
<cjwatson> best share it with somebody else
<cjwatson> I'm in a meeting and about to finish for the week after that
<bcurtiswx> cjwatson, OK ignore email then
<cjwatson> desktop people would be better
<bcurtiswx> seb mentioned to talk to you if I could
<bcurtiswx> i appreciate your time tho, have a good rest of day and weekend
<cjwatson> oh, any particular reason?
<cjwatson> I mean, I know the autotools, but lots of people do :)
<bcurtiswx> cjwatson, src/Makefile.am: object `empathy-accounts-dialog.$(OBJEXT)' created both with libtool and without
<bcurtiswx> seems one of the binaries added to empathy_chat_SOURCES causes autoreconf to complain
<cjwatson> there's a section on that in 'info automake'
<bcurtiswx> ok
 * bcurtiswx looks
<cjwatson> http://www.gnu.org/software/automake/manual/automake.html#Libtool-Issues
<cjwatson> explains it better than I can
<SpamapS> I notice that upstart was uploaded to lucid-proposed as an SRU back in August with the version 0.6.5-7 instead of 0.6.5-6.1  ...
<SpamapS> should this SRU be -8 or -7.1 ?
<ScottK> doko: I don't know enough to have an opinion of if they should be optional by default.  I just know it's a lot more effort to maintain symbols files if they vary per arch.
<cjwatson> either is fine - it just needs to not clash with maverick, and maverick went from 0.6.5-6 to 0.6.6-1
<cjwatson> SpamapS: ^-
<cjwatson> see https://launchpad.net/ubuntu/+source/upstart/+publishinghistory
<cjwatson> if it were me, I would follow the pattern and use -8
<seb128> bcurtiswx, just built with --no-as-needed for now
<doko> ScottK: sure, but you have to live with it
<seb128> bcurtiswx, it will be easier
<SpamapS> less confusing then to use -8 :)
<ScottK> doko: Why?  I didn't have to live with it with gcc4.4.
<SpamapS> cjwatson: ty
<seb128> seems weird that to add new files to _source we need to list all the other files it uses to land in that issue
<bcurtiswx> seb128, the info cjwatson gave says to add a empathy_chat_CFLAGS=$(AM_CFLAGS) i will try that
<doko> ScottK: because types of parameters are mangled too
<cjwatson> you've always had to list everything you use in _SOURCES, unless there's an internal library or something
<doko> seb128: what has something missing in _SOURCES to do with the linker flag?
<ScottK> doko: I'll add this discussion to the bug then.
<seb128> cjwatson, ok, we have a new file from a distro patch, I though that we used to include only that one
<seb128> not that one and all the files this source is using
<seb128> in the right order
<cjwatson> ordering may be new, but I doubt the rest is
<cjwatson> the linker has never magically found symbols for you
<seb128> doko, the initial issue was it complains about non found symbols
<seb128> ok, not sure why bcurtiswx gets that error then after adding the sources in order
<zyga> mpt, hi, do you have a moment?
<mpt> zyga, yep
<doko> seb128: is there a report open? imo, there should be for every case, where we use a workaround
<seb128> bcurtiswx, I will try to debug that the day I've a config with the GNOME3 ppa to do test builds
<zyga> mpt, what do you think of an idea to put "rate this application" or "go to software center" in the help menu of applications linked with launchpadintegration?
<seb128> doko, no, it's for a ppa with unstable version, not for natty
<doko> ok
<seb128> which is what makes debugging hard, nobody but bcurtiswx has the packages installed to build it
<bcurtiswx> seb128, i can share my .pbuilderrc as I have it working with GNOME3 PPA whenever you want.. that way its as "simple" as pbuilder-dist
<seb128> bcurtiswx, I know how to set up a pbuilder or a vm thanks, I just don't have the bandwith to do a full GNOME install in a pbuilder right now
<bcurtiswx> seb128, i figured you knew how to pbuilder/VM :P just offered my rc file
<seb128> or rather it would slow down my internet enough and I'm using it for other things I work on
<bcurtiswx> well good news so far, is it didn't fail at autoreconf
<mpt> zyga, "Rate This Application" in an application's Help menu is plausible (though it isn't really anything to do with help), but that has nothing to do with whether the application is in the Ubuntu archive, and therefore I don't think it belongs in launchpad-integration. (I think launchpad-integration should die in a fire, but that's irrelevant for that reason.)
<zyga> mpt, technical bits are not interesting to me, I just wonder how you'd think we can encourage (or if we should in the first place) users to rate applications
<zyga> mpt, or allow them to install additional content
<mpt> zyga, so, "Rate This Application" in the "Help" menu I'm ok with
<mpt> avoiding the technical bits :-)
<zyga> mpt, what kind of UI would you like there?
<mpt> zyga, opening USC to the application's screen and automatically opening the review dialog, I guess
<zyga> mpt, a dedicated rate window or direct hop to the software center?
<mpt> hm
<mpt> maybe it wouldn't be necessary to open the main USC window
<zyga> mpt, I'm not familiar with that part, does the user need to be signed in to write comments? (think about the very-first-time-to-rate-anything)
<mpt> zyga, yes they do. So going through <https://wiki.ubuntu.com/SoftwareCenter/RatingsAndReviews#reviews-reviewing> from the beginning.
<zyga> mpt, great, that's the window I was thinking of
<SpamapS> doko: are you working on the eglibc SRU to lucid btw? I did test it yesterday and it works well.
<zyga> mpt, now to technical bits, who should I talk to?
<doko> SpamapS: just that what I did prepare on p.c.c  or should the change about the restart issue backed out?
<mpt> zyga, mvo or tremolux to start with, to add a command line or d-bus signal or something for "please start the review process for X"
<mpt> to USC
<SpamapS> doko: the one you had on p.c.c needs to go in before the upstart change.
<SpamapS> doko: or at least, simultaneously now that I've added a breaks << that version
<SpamapS> doko: the change to postinst to disable telinit u on upgrade is vital.
<doko> SpamapS: are you ok with the eglibc upload during the freeze?
<doko> cjwatson: ^^^
<cjwatson> yes, per mail (were you cced on that?)
<cjwatson> marjo has acked it
<cjwatson> well, wait, what else is in the eglibc upload?
 * SpamapS hears the ominous change in the music
<cjwatson> mostly I just realised I didn't quite know what all I was acking
<SpamapS>   * Fix issue #12077, __strncmp_ssse3 can segfault when it over-reads
<SpamapS>     its buffer.  LP: #702190.
<Tribaal> Hi folk, I'm trying to get uic to generate an implementation for my header file, but can't. I'm using "uic -impl myheader.h" and expect output to stdout (as the manpage suggests), but uic complains by giving me the usage text...
<cjwatson> doko,SpamapS: bug 702190 is OK if you can provide a test case so that the QA team have some hope of validating it
<ubottu> Launchpad bug 702190 in eglibc (Ubuntu Lucid) "__strncmp_ssse3 can segfault when it over-reads its buffer" [Undecided,In progress] https://launchpad.net/bugs/702190
<zyga> mpt, thanks
<doko> cjwatson: a test was added in the fix, so a rebuild on this hardware should show it
<cjwatson> can we guarantee building on the appropriate hardware?
<doko> no
<cjwatson> perhaps the test can be extracted such that QA can run it externally
<doko> ok, will do
<SpamapS> doko: let me know if you need anything.
<seb128> barry, doko, do you think you could review bug #695005 (sponsoring request)?
<ubottu> Launchpad bug 695005 in python-numpy (Ubuntu) "Merge python-numpy 1.5.1 (main) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/695005
<seb128> doko, especially since you had some concerns about it and the update seems non trivial
<seb128> hum
<seb128> so gdm has a deluser call in its postrm, which fails when gdm is running...
<seb128> is there a standard way to deal with those issues?
<seb128> seem quite some users try to uninstall gdm from a session started by gdm and report bugs
<seb128> well apport report bugs because the postrm fails
<ScottK> lamont: Can haz postfix 2.8 for Natty?
<SpamapS> http://gyp.blogs.balabit.com/2011/01/using-upstart-in-a-chroot/
<SpamapS> wow
 * SpamapS thinks upstart-dummy needs to be packaged and maybe even integrated with schroot/sbuild... :-D
<cjwatson> SpamapS:
<cjwatson> https://code.launchpad.net/~canonical-scott/upstart/session-support
<cjwatson> so "not planned to be fixed soon" is mistaken
<Lopi> ogra: ping
<SpamapS> cjwatson: as excited as I am for that bit of news, I doubt it will be backportable to lucid, and I have to wonder how we'll use it from a lucid chroot -> a newer upstart .. do we need to shim in a session-aware initctl?
<cjwatson> dunno, I imagine a dummy thing is a reasonable stopgap for such environments
<cjwatson> that problem will go away eventually
<slangasek> bdrung: I wonder why libkibi needs a -dbg package in the archive
<bdrung> slangasek: because libkibi in ubuntu is identical with the version for debian and IIRC debian does not have ddebs
<slangasek> it does not, but why does this library need a -dbg package in Debian either?
<slangasek> it seems to have few moving parts :)
<bdrung> slangasek: to help debugging problems in the library. every program has at least one bug (or is outdated). ;)
<slangasek> bdrung: yes, but -dbg libraries come with a cost to mirrors; I would hope the Debian ftp team would not accept such a -dbg package (but experience suggests to me they probably will)
<micahg> I have a question about versioning for an SRU, I have xubuntu-docs at 9.10.1 in karmic and lucid, I'm about to upload to lucid, I was going to use 9.10.1+really10.04.1, but then karmic will be left with a version that can't be updated, I was originally going to use 9.10.1.10.04.1, but that looked ugly, any ideas?
<doko> cjwatson: are you ok with upstrart changes from SpamapS ?
<SpamapS> micahg: wouldn't it be updatable as  9.10.1+really10.04.1.1 ?
<micahg> SpamapS: which?
<SpamapS> micahg: you said it wouldn't be updatable with the +really10.04.1 tag .. but you could of course add things onto that.
<micahg> SpamapS: no, I mean to update karmic, I'd have to do 9.10.1+really09.10.1
<cjwatson> doko: the last version I saw was fine
<doko> ok
<cjwatson> doko: assuming that the libc6 version matches, which I haven't checked
<micahg> cjwatson: any ideas about my versioning conundrum?
<cjwatson> micahg: mm, you don't have a lot of room since maverick and natty are still on 9.10.x (!)
<micahg> right :)
<cjwatson> I think you're stuck with inventing something ugly that gives you enough space
<micahg> cjwatson: the package has no depends, so maybe I should just bump to 10.04.1, updates are planned for maverick and natty later, but the changes in maverick even were not version specific
<micahg> and the relavent changes were included in this update for lucid
<cjwatson> you could update natty, then maverick, then lucid, then karmic
<cjwatson> so that everyone's comfortable that version increase will be preserved
<cjwatson> I'd be nervous of bumping lucid beyond maverick's version; it's all too easy to forget to clean up later
<micahg> so I guess 9.10.1.10.04.1 so that there's room to update karmic and it's pre-maverick
<micahg> cjwatson: thanks
<doko> cjwatson, SpamapS: eglibc and upstart uploaded
<doko> SpamapS: same game for maverick?
<SpamapS> cjwatson: oo, I just saw that your plymouth change to listen for upstart events came through. Very cool. :)
<SpamapS> doko: yes I'll push that one momentarily
<doko> plymouth ftbfs
<cjwatson> doko: fixed a moment ago in ubuntu12
<cjwatson> SpamapS: hope it works :)
<cjwatson> doko: thanks, I'll review them a bit later this evening
<cjwatson> SpamapS: it becomes fairly obvious that there hasn't been a terribly consistent policy on upstart job descriptions, mind you
<cjwatson> we may have to revise some of them, or revise the bridge code
<cjwatson> anyway, out for a bit
<SpamapS> doko: do you happen to know the maverick eglibc version you'll be uploading?
<doko> SpamapS: http://people.canonical.com/~doko/tmp/  2.12.1-0ubuntu10.2
<SpamapS> doko: cool, will start a test build now
<anwar> where can i find projects to contribute ? using Python ?
<bcurtiswx> where would I search to see if XSendEvent is deprecated ?
<bcurtiswx> and what to replace it with
<bcurtiswx> im looking at http://paste.ubuntu.com/556660/
<janimo_> bcurtiswx, what suggests that it is deprecated
<janimo_> ?
<bcurtiswx> janimo_, nothing.. just a guess
<bcurtiswx> http://mail.gnome.org/archives/desktop-devel-list/2010-September/msg00025.html im looking there at an XSendEvent
<janimo_> there XSendEvent is not replaced by something else
<slangasek> james_w: whoo, habemus ramÄs!  Is that you fixing things so the udd branches work again? :)
<james_w> slangasek, never!
<slangasek> oh, well, /someone/ just fixed the import of the gourmet package :)
<jelmer> slangasek: jam should be the target of your gratitude :-)
<slangasek> jam: thank you :)
<jam> slangasek: happy to
<manjo> superm1, https://wiki.ubuntu.com/Kernel/Testing/UbuntuUEFI
<ebroder> wow. somebody put a lot of work into the sponsor queue today. kudos to whoever it was
#ubuntu-devel 2011-01-22
<AbsintheSyringe> for anyone who's involved with themes, I would be most grateful for answering this question: https://answers.launchpad.net/ubuntu/+source/light-themes/+question/142268
<cromblight> how far are we from making ubuntu gives us a sandwhich using motherboard?
<nysosym> hi there
<ari-tczew> if any core-dev has a time, would be nice to review bug 701182 and bug 701182
<ubottu> Launchpad bug 701182 in nut (Ubuntu) "Merge nut 2.4.3-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/701182
<ari-tczew> err, second bug 695005
<ubottu> Launchpad bug 695005 in python-numpy (Ubuntu) "Merge python-numpy 1.5.1 (main) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/695005
#ubuntu-devel 2011-01-23
<bcurtiswx_> if i want to find out a package that a program like icon-naming-utils belongs to.. whats the command?
<micahg> bcurtiswx_: apt-file search
<bcurtiswx_> micahg, muchas gracias
<micahg> bcurtiswx_: de nada
<bcurtiswx_> i keep forgetting that..
<karyo> I'm trying to organize a Natty testing team in my LoCo. I'd like them to install daily builds/alpha versions once a week and do some testing, but I dont know what to ask them to test. Would executing and finishing the default "System Testing" application suffice?
<ari-tczew> karyo: weekly testing ubuntu developent? ... I'm not sure what do you except
<karyo> What I expect? Well as a LoCo(Korean community btw), mainly translation issues
<bcurtiswx_> micahg, checking for gtk-update-icon-cache... no i did the apt-file search and it comes from libgtk3.0.. so i added it as dep and still doesn't wanna see it... you know anything i may be doing wrong?
<micahg> bcurtiswx_: what's the error?
<bcurtiswx> note: no battery indicator in natty
<bcurtiswx> micahg, checking for gtk-update-icon-cache... no | configure: error: Could not find gtk-update-icon-cache
<bcurtiswx> micahg, an apt-file search shows its in libgtk3.0-0
<micahg> bcurtiswx: you probably need the dev package for the pkg-config file
<bcurtiswx> micahg, i add that to deps and it still fails
<bcurtiswx> micahg, thought I tried it with -dev.. i will again one sec
<micahg> bcurtiswx: you can also check config.log for a more detailed explanation of what's missing
<bcurtiswx> micahg, not the -dev and is there a way for pbuilder to give a more verbose log? (im using that)
<micahg> bcurtiswx: there's an option not to purge after build, but I usually use a chroot when stuff like this happens
<bcurtiswx> micahg, even if im using maverick?
<bcurtiswx> to pbuilde rin natty
<bcurtiswx> pbuilder in*
<micahg> bcurtiswx: yes, I have one set up
<elafroshinobi> Hi, I'm trying to capture the string that the which command prints  out from inside a c program. Is there another way to call shell commands from c and capture the output of the command? Thanks
<broder> elafroshinobi: it's very difficult to do correctly, but you could check out http://libpipeline.nongnu.org/
 * broder is reminded that he wanted to file backports bugs for libpipeline
<cromblight> does ubuntu make sandwhiches? are we planning for it
<micahg> obligatory xkcd reference: http://xkcd.com/149/
<elafroshinobi> broder: thanks :)
* broder 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:
<broder> i'm assuming seb128 isn't still piloting
<cromblight> i don't mean to frighten you all. but 6 white owls just appeared out of no where in the sky and they flew in all different direction
<cromblight> it was as if they were all let out at once
<cromblight> these were big owls. and so i ran into my house before the solar beam could target me
<micahg> cromblight: I think this is inappropriate in here, you might want #ubuntu-offtopic
<cromblight> no you are impolite and voluntarily have a stick shoved your up ass so they others like you can be told to be silent on a fucking chat room social PUBLIC NETWORK PLACE. grow the fuck up.
<evilvish> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<cromblight> you don't even read anything
<cromblight> yeah call the ops you chicekn shit
<cromblight> i seen it all
<cromblight> you need to face these owls
<cromblight> cromblight>	i don't mean to frighten you all. but 6 white owls just appeared out of no where in the sky and they flew in all different direction
<cromblight> the ops aren't coming.
<cromblight> see the owls are taking over
<cromblight> in broad daylight this happened
<cromblight> now will u listen
<cromblight> !enter | evilvish
<ubottu> evilvish: Please try to keep your questions/responses on one line - don't use the "Enter" key as punctuation!
<cromblight> !enter | ubottu
<ubottu> cromblight: Please try to keep your questions/responses on one line - don't use the "Enter" key as punctuation!
<cromblight> i am in love withmyself
<cromblight> so beautiful is i
<cromblight> although my dreams are always bad
<cromblight> cuz i am alone
<cromblight> :(
<sabdfl> gosh
<sabdfl> i hope he's alright
<micahg> sabdfl: was I wrong to redirect to -offtopic?
<sabdfl> not at all
<sabdfl> battery out - can't discuss further - but no
<evilvish> micahg: actually he/she seems to have been looking for attention.. offtopic would have been the best place ;)
<evilvish> too bad dint get kicked, which might have made them happier..
<AnAnt> Hello, can someone help me with this FTBFS: http://launchpadlibrarian.net/62644475/buildlog_ubuntu-natty-powerpc.verilator_3.810-1_FAILEDTOBUILD.txt.gz
<AnAnt> I am getting the same FTBFS on Debian sparc
<AnAnt> doko__: ^
<AnAnt> I compared the amd64 & powerpc buildlogs for natty, I found that they differ in the binutils revision used
<AnAnt> binutils 2.21-4ubuntu1 in other archs (with successful build), while 2.21-3ubuntu1 on powerpc (also I see that binutils 2.21-4ubuntu1 failed to build on powerpc)
<cromblight> puuurrrr fect
<_rene_> what was the address of your debian community contact guy again?
<_rene_> please /query me for the answer, thanks
<karim__> hi
<karim__> I fail to create a udev rule. can someone help me out ?
<karim__> http://pastebin.com/GFdE3Y7s
#ubuntu-devel 2012-01-16
<pitti> Good morning
<alkisg> Hi, I'm upstream for an app in universe + in debian. My app is translated in launchpad. When is my translations deadline? DebianImportFreeze? NonLanguagePackTranslationDeadline?
<slangasek> alkisg: NonLanguagePackTranslationDeadline is the deadline by which translations should be finished, but if you're planning to incorporate those translations into a new upstream release, you need to be mindful of the feature freeze
<slangasek> and having a no-new-features upstream release that meets the freeze criteria *available* is no guarantee that anyone will have a chance to upload it in time
<alkisg> slangasek: thank you, so, without me doing any new upstream releases, new language translations can still be added after feature freeze, right?
<slangasek> they can, sure
<alkisg> (the app is new so it's only been translated to 7 languages so far, and I want to send a call for translators)
<alkisg> Thanks!
<slangasek> apw: heh - I think I'll remove the lpia-linux-restricted-modules source from the archive now
<dholbach> good morning
<SpamapS> dholbach: buenos dias
<dholbach> hey SpamapS
<\sh> dholbach: happy birthday :)
<dholbach> thanks \sh :)
<nigelb> ooh
<nigelb> HAPPY BIRTHDAY dholbach!
<dholbach> thanks :)
<dholbach> can new packages also be synced with the syncpackage now?
<seb128> dholbach, hey, how are you?
<dholbach> hey seb128
<seb128> dholbach, guess they could but you will hit NEW, it might be easier for archive admins to sync and new
<seb128> dholbach, if that's custom uploads it's harder to make sure the version was synced from debian and not a custom uploads with a -1 I guess?
<seb128> though I'm not sure
<dholbach> seb128, for other syncs I got an email, for NEW packages I didn't
<seb128> I would tend to want to review stuff others uploaded where I'm fine directly NEWing archive syncs
<dholbach> but the 2 newest entries on https://launchpad.net/ubuntu/precise/+queue are the ones I synced
<seb128> dholbach, right, make sense
<seb128> new sources go to the new queue
<dholbach> I just asked because I didn't get an email :)
<seb128> dholbach, oh ok
<seb128> well imho we should still discuss if new sources should be synced this way, it might make NEWing harder
<seb128> but I might be overlooking an easy way to confirm that those are actual syncs to discard versions screwups (i.e somebody who uploads a source to ubuntu using -1 by error, those should be reviewed, where we usually don't review stuff from Debian)
<dholbach> hm
<cjwatson> seb128: it doesn't make NEWing harder - you can tell that they're actual syncs because queue says "X-" in the type column for them, and they're annotated in some way in the web UI too
<cjwatson> IMO there's no reason why people shouldn't sync new packages with syncpackage
<cjwatson> usually I check with rmadison that it matches the version in Debian but that's about t
<cjwatson> *it
<seb128> cjwatson, ok, works for me, I was unsure if it was easy to say what was synced from debian
<cjwatson> oh, and in fact the web UI even says that it's synced from Debian
<cjwatson> look at https://launchpad.net/ubuntu/precise/+queue and use the expanders on the top two entries
<seb128> "Sync from Primary Archive for Debian GNU/Linux", indeed
<seb128> nice
<cjwatson> if anything it's easier to process NEW sources this way :)
<seb128> ;-)
<jamespage> iamfuzz: around? wanted to discuss reverting groovy back to 1.8.x series
<danger89> Hi
<danger89> We developed your own deb & ppa for Ubuntu
<danger89> namely Bumblebee
<astraljava> cjwatson: Hiya, I'm about to start working on the Studio live-dvd. I noticed you had a word with Scott about it, but since he's awfully busy, I thought I could test the wind beneath my wings. :)
<danger89> however the user still needs to manually add there own username to the bumblebee group. This is because the installation runs at root. Has anyone any idea how to fix the installer to add the current user automatic to the bumblebee group?
<Lekensteyn> in addition to what danger89 has said, we're granting write permissions to a socket for a specific group to give a sense of security
<stokachu> danger89, Lekensteyn : you  may get a better response in #ubuntu-app-devel
<danger89> stokachu: ok thanks
<stokachu> danger89, no problem
<apw> a dist-upgrade wants to remove gdm-guest-session, is that right or wrong
<dholbach> apw, gdm-guest-session is safe to go - I don't have it installed either and it's removed from the archive
<apw> dholbach, thanks ... /me hits return
<pitti> cking: hey Colin, how are you?
<cking> pitti, doing fine thanks!
<pitti> cking: FYI I stacked most of the rest of pm-utils cleanup in debian git now, we'll do an upload soon
<pitti> cking: there's one remaining thing
<cking> ..what's that?
<pitti> cking: the sata_alpm hook is currently disabled by default
<pitti> cking: seems our bug reports are from 2009, and your recent crowd sourcing looked promising
<pitti> cking: I'm interested in whether there were recent kernel developments which might make this safe(r) to enable by default?
<cking> pitti, well, I'm not 100% sure it is safe, so let's keep it disabled for now
<pitti> it WFM, but I have an X201 which is generally well supported
<pitti> I never had a problem in 2009 either, so I'm a bad test case
<pitti> cking: ack
<cking> pitti, I'm going to construct a USB live image that can do read tests on H/W so we can identify hardware where it fails w/o killing users data
<cking> but I suspect this is a longer term test for P+1 now
<cking> pitti, thanks for sorting out the pm-utils changes for me, much appreciated :-)
<pitti> no worries :)
<diwic> is it possible to upgrade from 11.04 to 12.04? I'm running "update-manager -d" but only 11.10 comes up.
<pitti> diwic: you need to upgrade through 11.10 first indeed; although it should work (sudo apt-get dist-upgrade), it hasn't really been tested
<diwic> pitti, well, since it hasn't been tested, I figured it would be an interesting test case to file bug against
<pitti> diwic: indeed; it won't be officially supported, but most of what breaks should also affect lucid->precise
<diwic> pitti, hmm, ok, but if nobody is going to care about the possible bugs anyway it would be stupid to throw oneself in there
<pitti> diwic: no, I meant that anything you run into will most likely be a real bug for upgrades from lucid
<pitti> so it actually does sound useful
<pitti> if apt-get dist-upgrade proposes to remove half of your desktop, you should not start it, though :)
<cjwatson> astraljava: OK; maybe if you sketch out how you think the seeds ought to look in a branch, perhaps using the Edubuntu seeds as a general reference, and I can look over it?
<cjwatson> astraljava: do you have a clear specification of how you want the resulting image to behave in terms of what should be available in a live session and what should be available after installation?
<diwic> pitti, hmm, I guess that isn't enough: "sudo apt-get dist-upgrade" or "sudo apt-get -t precise dist-upgrade" just says the system is updated
<pitti> diwic: you need to change /etc/apt/sources.list from "natty" to "precise" first, sorry
<diwic> pitti, ah, assumed something like that
<diwic> hmm, looks not too unsafe (44 to remove)
<pitti> diwic: paste?
<astraljava> cjwatson: We're in the early stages so far, but as you suggested, I will start to go over the Edubuntu seed now. Is it okay if I ping you again when I have it in some coherent form?
<diwic> pitti, too late
<diwic> It's not an installation I care that dearly about anyway
<astraljava> cjwatson: I'm not sure about the behavior, I'll talk to Scott about it, I guess.
<diwic> some indicators and some python related stuff
<pitti> diwic: these might be genuine cleanup indeed; there's a rather large GTK3/GIR transition involved
<diwic> pitti, yeah I thought so too
<cjwatson> astraljava: sure ... it's just probably more efficient if you have slightly more specific questions, since giving you complete directions might more or less amount to doing the work :-)
<cjwatson> astraljava: definitely having a clear spec of what packages are present in live vs. installed system will be useful, though
<astraljava> cjwatson: Yeah I understand that. :) I was just needing a direction, really. But you've given me that, so I'll go with that now.
<cjwatson> astraljava: (they're bound to be different in some way; for example the installer itself should not be present in the installed system)
<astraljava> cjwatson: Good point. Ok, I'll compile such a list as well. Thanks for now!
<cking> pitti, should I report apps that wakeup frequently to the ubuntu power consumption project even if I'm not sure if wakeups are a feature and not a bug of the software?
<pitti> cking: I think reporting can't hurt, we can analyze it on the bug report then and set as invalid if appropriate
<cking> pitti, ack
<pitti> cking: btw, I added u-p-c tags to your recent bugs, to have them all under one roof
<cking> ok - I will remember to tag them appropriately in future
<pitti> cking: s/tag/add affected project/
<pitti> cking: right, I meant to say "tasks", not "tags", duh
<cking> ah, OK :-)
<pitti> https://bugs.launchpad.net/ubuntu-power-consumption/+bugs
<cking> pitti, I added 917156 to that list :-(
 * cking notes its like whack-a-mole
<pitti> cking: ah, we don't even install that by default any more
<pitti> but it's an issue of course
<cjwatson> barry: well, first run of python3 porting seems pretty successful - I think I have a functional python3-germinate now
<cjwatson> barry: not that that was anywhere on your list ;-)
<cjwatson> (easier to start with something I maintain for practice purposes, though)
<barry> cjwatson: nice!  btw, i'm going through your email now, though about to take a lunch break.  thanks for the feedback.  one of the tricky bits (and why there was some asymmetry b/w the py2 and py3 versions) was that for py3, we can install the debug .so's right next to the production .so's, whereas for py2 we can't
<barry> cjwatson: the branch head probably had more churn in it than necessary, so apologies for that.
<cjwatson> barry: ok - if I've got any of the layout wrong, I'm guessing it might be easier to fix it with the approach I took, anyway :)
<barry> cjwatson: :)
<ScottK> barry: ping re python-dbus recomments python-gobject.  This pulls python-gobject and a stack of other things into the Kubuntu seeds that aren't otherwise needed.  Do you think it could be dropped?
<ScottK> ... recommeds ...
<ScottK> Sigh.  Can't type today.  Anyway ...
<jtaylor> doko_: can you remove the argparse provide from python-defaults, it breaks builds bug 916188
<ubottu> Launchpad bug 916188 in python-defaults (Ubuntu) "argparse provide breaks builds" [High,New] https://launchpad.net/bugs/916188
<tumbleweed> can a moderator please let my ubuntu-devel-announce mail through
<achiang> does anyone know why precise libqt4 is built without phonon? (just curious)
<debfx> achiang: phonon is built from its own source package
<achiang> debfx: ah, thx
<broder> lifeless: i'm confused about your closure of bug #612391. were you talking about re-targeting merge proposals? because i suspect that will only exacerbate one of the other major issues with SRU MPs, which is that you can't open a MP against foo-proposed when that package hasn't already been SRU'd
<ubottu> Launchpad bug 612391 in Launchpad itself "Cannot change status for merge proposals that target a released series" [High,Invalid] https://launchpad.net/bugs/612391
<broder> (possibly also if the SRU has already been moved into -updates - i'm not sure)
<lifeless> broder: it looks to me like there are no code changes in LP needed for that specific bug; there are other bugs in the area, that is true.
<lifeless> broder: the -proposed thing having no branches seems like an operational issue as much as anything else - sure, we could do something fancy and have fake branches, but really the udd importer could instantiate sru branches matching the release, shortly after the release.
<broder> ah, i see. you're suggesting a script to go and mangle the MPs that runs as the branch importer or something?
<haraldj> Hello, any SRU members online?
<haraldj> I'm currently facing requests for package upgrades in stable Ubuntu releases...
<lifeless> broder: handwave, yes :)
<broder> lifeless: ok. i guess the importer is considered to be a separate project from lp itself? i'll go open a new bugtask so we don't lose the bug
<lifeless> broder: you could add a task if you like; 'udd' is the project
<lifeless> broder: lp is a bit drowned in bugs atm; I'm trying to make sure that the bugs are a) really code bugs (or at a pinch operational things which someone in the LP team needs to look at) and b) not dups, not stale etc
 * broder nods
<tumbleweed> haraldj: generally minimal patches are preferred for SRUs, excepting patckages which maintain stable releases and have recevied "micro release exceptions" in Ubuntu
<haraldj> Well that may be a problem...
<haraldj> tumbleweed: the package in Hardy is really old...
<tumbleweed> hardy is really old, that's to be expected :)
<tumbleweed> we really don't want to cause regressions in SRUs. Usually new versions are backported only when the package is totally broken
<haraldj> tumbleweed: Ok that's true but the problem is that even Debian Lenny has a younger version - and this version is even deprecated by upstream
<haraldj> Absolutely understandable
<haraldj> I do work on the Debian package since 22 months and released two weeks ago a security update
 * tumbleweed isn't on the SRU or security team, so I can't give you their views
<haraldj> clear but there are currently 4 open CVEs for Hardy and at least 2 other bugs (more or less critical)
<haraldj> Maybe anybody of the release or security team is online?
 * tumbleweed is on the release team
<haraldj> Sorry meant the SRU
<haraldj> I'm somewhat concerned about the state of the package... as openswan is a security package there needs to be taken extra care of it
<tumbleweed> security team have an IRC channel (#ubuntu-security, IIRC) and also see bugs marked as security issues. Otherwise just lurk until someone turns up :)
<haraldj> Hmmm well I would prefer to talk to one member of SRU and one of security at the same time so we could find the best solution for the issues of security and usability
<tumbleweed> seems pretty head here now. Maybe in the (UTC) morning...
<haraldj> Ok will try tomorrow morning then :-)
<haraldj> Wish you a nice evening/good night and thanks for your help
<tumbleweed> np
<haraldj> :-) bye
#ubuntu-devel 2012-01-17
<cjwatson> tumbleweed: u-d-a> done
<Tucks> Hello? :O
<haraldj> Hello anybody from the SRU and the security team already online?
<micahg> haraldj: what's your question?
<haraldj> no question, rather a discussion about how to handle security/functionality bugs in package openswan
<haraldj> For Hardy there are 4 open security issues (at least according to diff of the Ubuntu/Debian changelogs)
<micahg> haraldj: security fixes need to be cherry-picked, see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation (we could probably fakesync for natty)
<tumbleweed> cjwatson: ta
<haraldj> micahg: Well it's not only security but also functionality: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/227294
<ubottu> Ubuntu bug 227294 in openswan (Ubuntu) "defaultroute with PPP does not work" [Undecided,Confirmed]
<micahg> haraldj: if there are bugs, they can be SRUd, if you want new functionality, you'll want to look at backports
<haraldj> Ãhm sorry I guess you misunderstood me: I'm the Debian uploader ;-)
<haraldj> And after tackling most of the Debian bugs I'm now trying to catch up with the Ubuntu ones
<micahg> haraldj: so, both SRUs and security updates need to be minimal fixes, full backports are possible with testing of the backport and its rdepends
<haraldj> micahg: Sure same in Debian the question remains what issues the SRU and security team deem important enough/vs non-invasive to get into
<haraldj> micahg: There are for example many calls for fixes for KLIPS which may not be too easy...
<haraldj> micahg: I think it would make most sense to present a list (to be made by me) to the people responsible for this decision which details which fixes are missing in each release
<haraldj> micahg: But who exactly are these people?
<ScottK> haraldj: Fortunately for you, micahg is one of the members of the Ubuntu security team.
<haraldj> ScottK: Well I already thought this when reading his comments ;-)
<micahg> haraldj: so, for the security fixes, you can discuss with mdeslaur in #ubuntu-hardened after 14:00 UTC, not sure if the SRU people are around, but basically, if it's a small patch and testable, it's probably ok to SRU
 * SpamapS is an SRU person
<haraldj> micahg: Ok, I will try to come up with a list of fixes needed and will try to test it
<micahg> haraldj: well, the fixes will need to be tested after they're uploaded as well, but it's always nice to know if they work beforehand :)
<micahg> haraldj: and the security team loves help :)
<haraldj> micahg: Well I can only give it small tests as I do not really use Ubuntu but I will try my best
<micahg> haraldj: well, I meant that there's a test case that someone can test the fix
<haraldj> micahg: Yes I know I've already worked with Moritz Muehlenhoff from Debian security team ;-)
<SpamapS> haraldj: typically with the SRU process, you'd want to keep it to one fix at a time, or a group of small related fixes at one time. Otherwise it can be difficult to verify all of the bug fixes, which is required to pass into -updates
<haraldj> SpamapS: Well for Hardy there are 4 open security issues (if counted right) and two other issues
<SpamapS> haraldj: and for hardy, we'd only do High priority fixes.. things that cause data loss or completely broken software.
<micahg> haraldj: I'd suggest going for the security issues first, then SRUing the bug fixes afterwards (security issues go in right away after testing, SRUs require 7 days)
<SpamapS> haraldj: yeah, security is micahg's realm. :)
<SpamapS> haraldj: and I'd agree with micahg.. get them into security first.
<haraldj> SpamapS: could you please take a look at https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/227294 and https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/228274?
<ubottu> Ubuntu bug 227294 in openswan (Ubuntu) "defaultroute with PPP does not work" [Undecided,Confirmed]
<ubottu> Ubuntu bug 228274 in openswan (Ubuntu) "openswan creates "rundir" and "subsysdir"" [Undecided,Confirmed]
<haraldj> SpamapS: If they are not suitable please close them with won't fix
<SpamapS> haraldj: are these things fixed in later upstream versions?
<haraldj> SpamapS: Yes
<haraldj> SpamapS: Lucid has a new version which should fix these issues
<haraldj> SpamapS: So if they are won't fix please close them (I already applied for ubuntu-bugcontrol for openswan to better care for the package)
<SpamapS> haraldj: not much info there. Are there workarounds for these bugs?
<SpamapS> haraldj: well they're technically already "closed" as Fix Released (I'm marking them as such). At this point it would be a task only against hardy..
<haraldj> haraldj: No not as far as I know - the rundir/subsysdir are just missing $ signs
<haraldj> sorry meant SpamapS ;-)
<micahg> https://bugs.gentoo.org/show_bug.cgi?id=193824#c0
<ubottu> bugs.gentoo.org bug 193824 in Applications "net-misc/openswan-2.4.9 creates errant directories "rundir", "subsysdir"" [Normal,Resolved: fixed]
<haraldj> SpamapS: for the ppp bug I will need to take a look at the fix
<SpamapS> haraldj: so the rundir/subsysdir .. the software is totally broken for... most, or all, or just some users?
<SpamapS> haraldj: let me dig out your bugcontrol app so I can +1 it.. :)
<haraldj> SpamapS: the rundir/subsysdir is merely an annoyance I guess
<micahg> re bug control app> it doesn't look like it's been moderated yet
<haraldj> As long as the dirs already exit
<SpamapS> haraldj: ok so thats not a good candidate for a hardy SRU. The other one though, that looks more difficult to work around
<haraldj> SpamapS: Well then I think just close the rundir/subsysdir :-)
<SpamapS> haraldj: I'll mark it as Won't Fix in Hardy, with a priority of Medium. The other seems High priority, so a patched package would certainly be accepted.
<haraldj> SpamapS: Ok the fix for ppp is a two-liner
<dholbach> good morning
<SpamapS> haraldj: though, if the test case is clear and the patch fo rthe rundir thing is only 2 lines also.. I wouldn't mind it being fixed as well.
<micahg> SpamapS: well, cleanup will require a maintainer script fix, the simple SRU would be not to create the dirs anymore
<haraldj> SpamapS: Well for the rundir issue I would take the Gentoo patch, for the ppp issue I would take the Debian patch
<SpamapS> micahg: a maintainer script that searches the entire filesystem for rundir/subsysdir.. that doesn't seem doable.
<haraldj> micahg: Well the dirs would be created but the right way ;-)
<haraldj> SpamapS: +1
<micahg> haraldj: right, sorry :)
<haraldj> SpamapS: would be far to dangerous, think about a package placing a rundir in eg /opt...
<SpamapS> micahg: we could have it echo "Sorry we messed with your home dir"
<SpamapS> no we're not going to cleanup the mistakes of the past.. ;)
<SpamapS> not in that case anyway
<haraldj> SpamapS: was an upstream mistake ;-)
<SpamapS> Ok, I think I understand the two issues, and both patches are very simple and straightforward...
<haraldj> micahg: But we could do a find and tell the user we found them...
<haraldj> micahg: They may check and remove if necessary
<SpamapS> I would suggest addressing the 4 security issues first, then attaching a debdiff or a merge proposal to one of the other two bugs with uploads for hardy-proposed
<micahg> haraldj: I don't think we'd take a maintainer script to do that as an SRU, but IANA SRU team member
<SpamapS> haraldj: to be clear, since the fix and test case are so simple, both are acceptible for SRU.
<SpamapS> micahg: no, we wouldn't. :)
<haraldj> SpamapS: Ok :-) so I will talk with the security guy concerning the patches and then later talk again with you about hardy-proposed, is that ok for you?
<SpamapS> haraldj: yeah. I'd suggest actually attaching the debdiff and subscribing ubuntu-sponsors to the bug.. this will allow somebody to get to it quicker, and helps keep the line clear between SRU team members and -proposed uploaders (more eyeballs.. etc. etc.)
<SpamapS> haraldj: but by all means, ping me about it
<haraldj> haraldj: Ok I will do :-)
<micahg> haraldj: so, for the security patches, for natty, you can just fix in squeeze and sync, precise, fix in sid and sync, the other releases will need debdiffs
<haraldj> Sorry mistyped again ;-)
<haraldj> micahg: precise is ok
<SpamapS> haraldj: btw, did you email ubuntu-bugcontrol@lists.launchpad.net ? not seeing your email there
<micahg> SpamapS: that list is moderated for non-subscribers
<haraldj> micahg: 2.6.37 there is uptodate
<haraldj> micahg: squeeze-security has a fixed version, doing the sync may be up to the ones who can do ;-)
<micahg> haraldj: yeah, just mention to mdeslaur and he can take care of that
<haraldj> micahg: ok
<haraldj> SpamapS: another issue: does Ubuntu want to have KLIPS support from openswan?
<SpamapS> haraldj: Ubuntu wants everything Debian has to offer.. well.. except insserv. ;)
<haraldj> SpamapS: *ggg*
<haraldj> SpamapS: Well KLIPS support would mean greater patches, I'm not sure this would be acceptable, maybe if there is a need for it there should rather be backports
<SpamapS> haraldj: Oh kernel patches or openswan patches?
<haraldj> Ops alioth is down...
<SpamapS> we're not going to take kernel patches that aren't upstream
<haraldj> SpamapS: In case of Hardy it would be a patch to patch the patch for the kernel ;-)
<micahg> also, new functionality isn't allowed in SRUs
<SpamapS> we'd like for hardy users to be at least migrated to lucid by now.. so probably no.
<haraldj> micahg: Well the functionality isn't new - KLIPS is an alternative IPSec Stack for the kernel which needs to be apadted to compile with newer kernel versions
<haraldj> SpamapS: Ok no problem for me :-)
<SpamapS> I mean hardy servers will still get critical updates for 2 more years. But, its time to start planning for the hardy->lucid->precise double upgrade in August if you have hardy boxes. :)
<micahg> SpamapS: hardy has a little over 15 months of support left
<SpamapS> well not 2 more years.. about 21 more months.
<haraldj> SpamapS: I think https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/253041 is then a candidate for won't fix
<SpamapS> 15?
<ubottu> Ubuntu bug 253041 in openswan (Ubuntu) "KLIPS module not included with openswan" [Undecided,Confirmed]
<SpamapS> oh right, 12+3
<SpamapS> was doing 24-3 :-P
<SpamapS> oi.. its 2012 isn't it? :-P
<haraldj> SpamapS: :-) well I do not have any hardy boxes
 * SpamapS screams AHHHGGGHH we're all gonna die in Homer's voice
<haraldj> SpamapS: Doh
<haraldj> SpamapS: so I would think close the above bug if there is no need for KLIPS in Hardy anymore
<micahg> does lucid+ have KLIPS already?
<haraldj> micahg: Not sure what kernel version has lucid?
<StevenK> 2.6.32
<SpamapS> sounds like a Fix Released
<haraldj> SpamapS: not sure
 * haraldj works through Debian and upstream gut
<haraldj> git
<SpamapS> well 11.10 has 3.0.0
<haraldj> SpamapS: openswan 2.6.37 runs on my netbook with 3.2.0-rc7 so no problem with KLIPS here
<micahg> so that should at least be Fix Released (precise)
<SpamapS> indright, 3.2.0 is precise
<haraldj> micahg: Yes
<SpamapS> haraldj: closed as Fix Released
<haraldj> upstream openswan 2.6.24 contains a commit which fixes KLIPS for kernel 2.6.32
<haraldj> SpamapS: which one did you close?
<SpamapS> haraldj: KLIPS support
<SpamapS> haraldj: btw, thanks very much for tending the bugs.
<haraldj> SpamapS: There are 4 or so bugs open for KLIPS support :-) for almost every Release one I guess
<haraldj> SpamapS: Well I try my best
<SpamapS> haraldj: ahh, if its all just the same request (please add KLIPS) then just mark them all as duplicates
<SpamapS> haraldj: or if you can't mark as dupe, then list the #'s and I'll do that
<haraldj> SpamapS: I'm not sure this makes sense this way because the fixes are incremental
<haraldj> SpamapS: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 is a similar matter - https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/253041 did talk about the module not included, https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 did talk about the module not compilable
<ubottu> Ubuntu bug 246713 in openswan (Ubuntu) "openswan-modules-source pkg does not compile with m-a" [Undecided,Confirmed]
<ubottu> Ubuntu bug 253041 in openswan (Ubuntu) "KLIPS module not included with openswan" [Undecided,Fix released]
<haraldj> SpamapS: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/253041 says the module is not included -> correct there is only the source for it
<ubottu> Ubuntu bug 253041 in openswan (Ubuntu) "KLIPS module not included with openswan" [Undecided,Fix released]
<haraldj> SpamapS: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 says it is not compileable -> correct, this is fixed with a patch of me which can be found in Debian Lenny security version
<ubottu> Ubuntu bug 246713 in openswan (Ubuntu) "openswan-modules-source pkg does not compile with m-a" [Undecided,Confirmed]
<haraldj> SpamapS: So I guess https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 could be close to
<ubottu> Ubuntu bug 246713 in openswan (Ubuntu) "openswan-modules-source pkg does not compile with m-a" [Undecided,Confirmed]
<haraldj> Ups sorry must do some work now ;-)
<robert461> hello any one to chat ? ;-)
<tjaalton> still a huge backlog on ppa-builders? 11h as suggested by lp..
<tjaalton> was the same last week
<MacSlow> Just ran into LP: #894340 "E:Couldn't configure pre-depend libtinfo5 for libncurses5, probably a dependency cycle" while trying to dist-upgrade my desktop-box from oneiric to precise... any hints for a work-around?
<MacSlow> seb128, didrocks, pitti: ^^ any idea
<seb128> MacSlow, hey, I've personally no clue about this one but maybe mvo would
<seb128> or cjwatson
<cjwatson> huh, I wonder why that's at all hard; libtinfo5 Pre-Depends: multiarch-support (which you should already have) and Depends: libc6 (>= 2.4) (likewise)
<MacSlow> mvo, cjwatson: got a tip for a work-around on LP: #894340 ?
<cjwatson> eglibc wasn't uploaded recently or anything
<cjwatson> nor was ncurses
<cjwatson> MacSlow: i386 or amd64?
<MacSlow> cjwatson, amd64
 * infinity wonders why ncurses predepends tinfo instead of just a depends.
<cjwatson> either way, not sure why it should break
<cjwatson> playing around to see if I can restore the apt-clone data from that bug report
<infinity>      - Add Pre-dependency on libtinfo5 to libncurses5 to prevent possible
<infinity>        symbol lookup errors if libncurses5 is unpacked before libtinfo5.
<seb128> somebody else is mentioning the same bug on #ubuntu-bugs
<infinity> That seems like a blatant misunderstanding of dependencies.
<infinity> I'm sure that dropping the pre-dep to a dep will fix the resolver breakage.  Still curious that it breaks though, yes.
<Daviey> Does anyone own/(have access to) trusted boot (intel) hardware?
<cjwatson> infinity: wait, that actually seems reasonable to me
<infinity> cjwatson: It does?
<infinity> cjwatson: Pre-dep is to guarantee a package is configured.  If unpack isn't enough to guarantee symbol lookups, then every binary->library dependency is "wrong".
<MacSlow> cjwatson, so should I just wait for the relevant packages to be rebuild?
<cjwatson> if unpacking the new libncurses5 is going to break without libtinfo5 on the system, then I can't see any way other than Pre-Depends to enforce libtinfo5 being >= unpacked
<cjwatson> MacSlow: huh?
<cjwatson> MacSlow: we haven't analysed this yet.
<cjwatson> infinity: maybe there are Essential binaries linked to ncurses
<cjwatson> it wouldn't overly surprise me
<MacSlow> cjwatson, ok
<cjwatson> I think Priority: required libraries ought to be able to support that, at least
<infinity> cjwatson: Potentially, sure, but ncurses depends on tinfo, I don't see how that can go backward.  There's no dependency loop.
<cjwatson> infinity: right - that's why I'm trying to stuff apt-clone data into place in the hope of reproducing it
<infinity> cjwatson: (And, indeed, our own version in oneiric was a dep, not a pre-dep, and I don't recall any fallout)
<infinity> cjwatson: It was the next Debian revision that promoted that to a pre-dep.
<cjwatson> From binaries in Essential packages, fdisk, cfdisk, and pg link to ncurses
<Wellark> I'm pretty sure that this is some corner case on my system. otherwise we would be getting duplicates every 5 minutes from people doing the upgrade
<cjwatson> It doesn't seem strictly vital but I'd prefer to figure out why apt is eating its own tail rather than reverting the pre-dep
<Wellark> could it be some package I've installed is getting the dependency cycles wrong?
<Wellark> e.i. confusing the resolver
<cjwatson> it's possible; do you have an apt-clone state file somewhere?
<cjwatson> what we need to do is to get a chroot on an expert's system configured to reproduce things
<Wellark> yes, attached to the bug
<cjwatson> ah yes
<Wellark> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/894340/comments/5
<ubottu> Ubuntu bug 894340 in update-manager (Ubuntu) "Release Upgrade Fails: depency cycle for libtinfo5/libncurses5" [Undecided,Confirmed]
<cjwatson> give me a few minutes to try to beat things into shape here
<Wellark> sure sure
<Wellark> I'm not in such hurry
<Wellark> after all my system is still in usable state :)
<infinity> Wellark: Do you have any ncurses*-dev packages installed?
<Wellark> probably, will check
<infinity> I note some multiarch mangling in the -dev packages in 5.9-3.  Curious if that could wreak upgrade havoc.
<Wellark> hmm.. I've only have lib32ncurses5-dev
<Wellark> I thought I had some others, too
<Wellark> I remember doing some ncurses stuff couple of months ago
<cjwatson> yeah, multiarch is certainly a possible source of trouble
<Wellark> oh, but that was with python ncurses
<Wellark> hmm.. using apt-rdepends
<Wellark> I see that file is needed by wine-dev
<infinity> So, you have libncurses5-dev:i386 installed, perhaps?
<Wellark> oh, read the output wrong
<cjwatson> hah, apt-clone gets pretty confused if you try to restore state into an amd64 chroot in an i386 host system
<Wellark> let's see
<cjwatson> (with an amd64 kernel - it's physically possible for it to execute the binaries)
<infinity> cjwatson: linux64 to the rescue?
<infinity> Oh, but amd64 kernel, should be reporting linux64ishly anyway.
<cjwatson> infinity: no, I think it's using the system's apt
<infinity> Yeah.
<infinity> Special.
<cjwatson> and forgetting to set APT::Architecture
<Wellark> infinity: I've got libncurse5-dev installed
<Wellark> and dpkg-query -s says Architecture: amd64
<mvo> cjwatson: heh :) never tried that, what is the error?
<infinity> Wellark: And nothing for "dpkg -l libncurses5-dev:i386"?
<Wellark> no, nothing
<cjwatson> mvo: no error but it downloads i386 package lists instead of amd64 and (I think) tries to restore i386 packages which doesn't go so well
<cjwatson> well, no error before I noticed what it was doing and C-c
 * cjwatson convinces chdist to load that data
<mvo> cjwatson: thanks! good to know, probably trivial to fix (like you said already earlier :)
<cjwatson> mvo: want a bug?
<infinity> Oh, ncurses wasn't multiarch in oneiric, so I guess my questions about having i386 stuff installed are irrelevant.
<mvo> cjwatson: I write a note about it, its hopefully quicker to fix than to write a bug
<cjwatson> mvo: *nod*
<cjwatson> ta
<Wellark> cjwatson, infinity: if you come up any ideas, just ping me, ok?
<Wellark> I'm off to make some coffee
<cjwatson> bah, chdist apt-get dist-upgrade doesn't reproduce this
<Riddell> ARM dudes: problem in qtwebkit compile
<Riddell> https://launchpadlibrarian.net/90264873/buildlog_ubuntu-precise-armhf.qtwebkit-source_2.2.1-1ubuntu1_FAILEDTOBUILD.txt.gz
<Riddell> "/usr/bin/ld: final link failed: Memory exhausted"
<Riddell> ideas?
<Wellark> Riddell: more swap..
<Wellark> qtwebkit can take from 4-8GB of memory on linking stage
<Tm_T> Wellark: James Bond: When 16 GiB is not enough
 * Tm_T hides
<Riddell> Wellark: well yes I could guess that, it's a question of how to get it
<Tm_T> Riddell: I wonder if #canonical-sysadmin would help
<Wellark> Riddell: or #launchpad as it's build service related
<Tm_T> ah, forgot launchpad had their own channel
<infinity> Riddell: Waiting on kernel upgrades on the buildds to make that happy.
<infinity> Riddell: Once the buildds have shiny new kernels, we'll retry the world.  If you see the same failure on that package again, please scream.
<Riddell> infinity: nice thanks
<alexbligh> Does software exist (say an apache module) which provides a web-based view of the CONTENTS of a .deb (or even better, an entire repository), and let individual files be downloaded over the web (I know it's an ar file containing 2 x tgz, and I know I could write something in perl myself, but I suspect it's been done before).
<beuno> alexbligh, you mean something like this?  http://packages.ubuntu.com/precise/comm/asterisk
<alexbligh> beuno, yes, the code behind that (these are .debs we autobuild), save that when you go to (say) http://packages.ubuntu.com/precise/amd64/asterisk/filelist I need to be able to download the files themselves, not just the list of files.
<beuno> alexbligh, on the right-hand side, don'y you have the tar.gz file and such?
<alexbligh> Yes, but I want to download the files IN the package
<beuno> ah, I see
<alexbligh> (i.e. the individual files in the .tgz in the .ar)
<beuno> I don't know of any websites that have that since the packages are uploaded already compressesed AFAIK
<alexbligh> If the source to packages.ubuntu.com is open source, I'd be happy to hack it up so http://packages.ubuntu.com/precise/amd64/asterisk/filelist can be a link
<alexbligh> beuno, yes, but you can extract them with a bit of perl and ar and tar file by file.
<jpds> alexbligh: http://packages.ubuntu.com/about/
<alexbligh> I was just hoping someone had done the work.
<alexbligh> jpds, ooh, thanks. That will be a good start.
<beuno> right, it may not play super nicely with the servers, though, having to decompress a ton of things on the server-side
<alexbligh> beuno, that's true. Perhaps not suitable for public consumption, but this is for internal usage.
<beuno> right, go nuts then!
 * Sweetshark wants to rebase on debian, but alioth is down :/
<Daviey> would someone on foundations like to comment on, bug 913379.. thanks.
<ubottu> Launchpad bug 913379 in ntp (Ubuntu) "Migrate ntp from SystemV to Upstart" [Wishlist,New] https://launchpad.net/bugs/913379
<tomreyn> hi, i'm just looking at bug #879926 and wonder whether there will likely be a SRU?
<ubottu> Launchpad bug 879926 in Evince "evince crashed with SIGSEGV in g_param_spec_pool_lookup()" [Critical,New] https://launchpad.net/bugs/879926
<seb128> tomreyn, could be, though it seems most bugs were from precise and not oneiric, not sure if that's a real issue in oneiric
<seb128> well the code bug is obvious so it's probably is
<seb128> do you get the issue?
<tomreyn> seb128: yes, i ran into it on oneiric, and the bug is also tagged oneiric
<seb128> tomreyn, ok, thanks
<scott-work> it appears that the REVU website is down, it also appears that i cannot dput to REVU
<scott-work> does anyone have any infomration?
<tomreyn> seb128: do you want me to comment on the bug asking for an SRU or will you take it from here?
<seb128> tomreyn, I will add it to my list but feel free to comment on the bug if you want, what we will need is somebody who has the issue to confirm the fix after the upload ;-)
<tomreyn> okay, i'll comment and watch it.
<seb128> thanks
<tomreyn> thank you!
<cjwatson> alexbligh: http://www.mirrorservice.org/ does that: e.g. http://www.mirrorservice.org/sites/archive.ubuntu.com/ubuntu/pool/universe/a/asterisk/asterisk_1.6.2.9-2ubuntu2_i386.deb%5Bpeek%5D
<ogra_> does anyone know if: "Architecture: any-arm" in debian/control should work ?
<ndec> hi. i have tried to use Arch = any-arm for some of our packages, and my upload are rejected in this case. If i use Arch = armel armhf, it works as expected, but i got the feeling from the debian policy that any-arm should work. Anyone can advise?
<ndec> ah... i didn't see that ogra_ just asked the same question ;-)
<ogra_> heh
<ndec> any-arm work when building locally with dpkg-buildpackage in armel or armhf root fs. it's just that the upload is rejected by LP
<seb128> seems like soyuz doesn't handle that yet
 * ogra_ guesses soyuz just knows $(dpkg-architecture -L), any, all
<cjwatson> It might be a bit naive about CPU aliases
<cjwatson> It does know about any-i386, say, but -arm is a bit different
<ndec> so, should I open a bug for any-arm?
<ogra_> well, the footnote at http://www.debian.org/doc/debian-policy/footnotes.html#f88 also talks about gnu triplets ... we dont have any plain "arm" triplet either
<ogra_> or am i reading that just wrong ?
<cjwatson> $ dpkg-architecture -aarmel -iany-arm; echo $?
<cjwatson> 0
<cjwatson> therefore IMO you should file a bug on Launchpad about this, yes
<cjwatson> lib/lp/soyuz/pas.py:determineArchitecturesToBuild doesn't implement the full architecture alias handling
<ogra_> aha
<ScottK> barry: ping re usb-python.
<barry> ScottK: hi
<ScottK> Hello barry.  Did you get the more detailed ping I sent yesterday?
<barry> ScottK: i didn't
<ScottK> OK.  Let me find it.
<ScottK> [11:56:17] <ScottK> barry: ping re python-dbus recommends python-gobject.  This pulls python-gobject and a stack of other things into the Kubuntu seeds that aren't otherwise needed.  Do you think it could be dropped?
<ScottK> Similar for python3-dbus.
<barry> ScottK: it's only a build-dep, right?
<ScottK> No, it's a run time Recommends.
<ScottK> That's why it gets pulled in.
<ScottK> It seems somewhat bogus to me.
<ScottK> But you've been in the code, so I wanted to see what you thought.
<barry> ScottK: ah right, it's in wheezy that way too.  let me just look at a couple of things
<ScottK> Thanks.
<barry> ScottK: so, outside of the test suite (and thus the build-dep), it's only imported in dbus/gobject_service.py.  we could probably split that out into a separate binary package and then only that would need python-gobject.  i don't really know what kind of impact that would have for clients of the package (i.e. how much dbus/gobject_service.py is used)
<ScottK> Any suggestions on how we could find out?
<barry> i guess i could grep through my installed precise *.py to see if i can track down any imports of it
<ScottK> Or any reference to ExportedGObject as that and ExportedGObjectType are the only classes in there.
<barry> yep, good idea
<ScottK> IIRC kees used to have the entire Ubuntu archive unpacked.  Maybe he could do it ...
<barry> ScottK: well, just ran the import check.  zero imports
<ScottK> Cool.
<barry> and all references to ExportedGObject are in dbus itself
<ScottK> If it's not used in any packages, then I think it's safe to drop it to suggests.
<barry> ScottK: rather than separating it into a new binary package?
<ScottK> Yes.
<barry> that's an easy change
<ScottK> Yeah.
<barry> ScottK: i think my latest upload is waiting to be accepted because of the new python-dbus-common binpkg (slangasek rejected it last time due to lintian warnings, since fixed)
<barry> ScottK: once that's accepted, i can make that change and upload.  when the new dbus-python is released upstream i had planned on submitting my changes to debian, so i can push the suggests change at that point
<ScottK> OK.  I'm going to grab the rdepends and grep them, just to make sure.
<barry> cool
<stgraber> @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: stgraber
<ScottK> barry: There's one package that's a problem and it looks like it's unmaintained and likely to go away ~soon anyway.  I'll add the python-gobject depends to it and then your change to suggests is safe.  No need to wait to re-upload, BTW, the newer binaries in binary New will just superced the old ones.
<barry> ScottK: cool.  i'll make that change now then and upload.  could you submit a bug report in debian about it?  you can even assign it to me, and then i'll remember when the time comes there
<ScottK> barry: I take it back, they're all fine.
<ScottK> Sure.
<barry> ScottK: http://paste.ubuntu.com/807510/
<ScottK> barry: What about python3-dbus?
<barry> yep, was just there :)
<ScottK> (that's what I was hoping for for python-dbus)
<ScottK> OK
<barry> ScottK: http://paste.ubuntu.com/807512/
<ScottK> barry: Yes.  Please.
<ScottK> barry: Debian Bug#656230
<barry> ScottK: got it
<ScottK> Great.
<barry> ScottK: uploaded
<ScottK> Excellent.
 * barry -> reboot
<hrw> does someone saw eglibc builds looping?
<dholbach> kirkland, hiya, do you think you can have a look at bug 917682?
<ubottu> Launchpad bug 917682 in byobu (Ubuntu) "Sync byobu 5.3-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/917682
<cjwatson> barry: do you think it would be useful if I packaged the 'six' module?
<kirkland> dholbach: i think it's been done
<kirkland> dholbach: http://packages.qa.debian.org/b/byobu.html
<cjwatson> barry: writing compat layers for cases where wedging 2to3 into the build system is awkward is getting tedious very quickly
<kirkland> dholbach: oh, wait ...
<dholbach> kirkland, eh?
<dholbach> :)
<kirkland> dholbach: they want Ubuntu to sync from debian?
<kees> ScottK: i just have the archive mirrored; the unpack is relatively fast though.
<kirkland> dholbach: no, Ubuntu is upstream here;  Debian byobu is downstream
<ScottK> kees: It turned out to be few enough packages that I downloaded them and checked.  Thanks though.
<dholbach> kirkland, you're CCed on the bug - I identified a few things that were missing in the Debian packaging - I'll leave the bug to you
<kirkland> dholbach: thanks;  the debian maintainer should propose a branch/merge/patch to lp:byobu
<kirkland> dholbach: and I'll integrate
<Laney> get it on the sync blacklist if this is the case
<ScottK> lamont: How goes postfix 2.8.7?
<kees> ScottK: cool
<lamont> ScottK: actually working on it now
<ScottK> lamont: Excellent.  Thanks
<barry> cjwatson: it could be useful.  so far i've managed to port code w/o 2to3 or six, which i think isn't too difficult if you only have to target >= 2.6.  but six could perhaps make that even easier or more consistent
<cjwatson> barry: right, it's just tedium like iteritems.  I could repeat the compatibility code (but that's so boring), or accept the performance hit in Python 2 of using items (but that involves thought about whether it matters)
<barry> cjwatson: right (it rarely does though :) but yeah, i do agree it would be good to promote six as the compatibility layer.  i've been thinking about submitting some code upstream for the other things i've found at both the python and c layers.
<barry> cjwatson: and i completely agree it's better than 2to3 :)
<cjwatson> heh, yeah
<cjwatson> alright, I'll knock a package together
<lamont> ScottK: my ppa
<ScottK> lamont: I'm trying to remember what we decided on Bug #774500 ?
<lamont> ScottK: if you would be so kind as to play with that some?
<ubottu> Launchpad bug 774500 in postfix (Ubuntu) "postfix build does not have documented support of sqlite" [Wishlist,Confirmed] https://launchpad.net/bugs/774500
<ScottK> Sure.
<lamont> ScottK: I believe we decided that I still have some work to do there
<ScottK> OK.
<ScottK> barry: https://launchpad.net/ubuntu/+source/dbus-python/0.84.0-2ubuntu3/+build/3099079 urk.
<ScottK> lamont: trying.
<lamont> ScottK: do you know off the top of your head if libsqlite3-0 is effectively essential?
<ScottK> My recollection is we decided it was.
<ScottK> It's certainly in minimal.
<lamont> ScottK: it's entirely possible that it's fixed in this upload
<ScottK> lamont: debc says there's no dict_sqlite.so
<ScottK> Might as well leave it for 2.9.0 at this point though.
<ScottK> lamont: Tests out fine here.  I say ship it.
<ScottK> barry: I'm going to mash retry since you didn't change anything that would affect that.
<cr3> cjwatson: quick preseed question: if the same value is being set twice in the same preseed file, like partman-auto/method for example, does the last value always take precedence?
<cjwatson> cr3: Yes
<cjwatson> cr3: preseed files are declarative not imperative
<cr3> cjwatson: thanks!
<ScottK> barry: Failed again.  Not sure what's up there.  Over to you.
<cjwatson> barry: OK, six is in Debian NEW now
<ahasenack> pitti: hey,
<ahasenack> pitti: could you release a new postgresql-common for lucid? For the ppa:pitti/postgresql ppa?
<ahasenack> pitti: release 128, which has pg_basebackup ;)
<broder> barry, ScottK: if you still need it, i have the archive unpacked on my lintian runner
<YokoZar> So, I'm working on multiarching Wine and I'm beginning to worry about build daemon skew.  For 32-bit compatibility, I have a few files from wine1.3 split into wine1.3-i386.  wine1.3-i386 is m-a:foreign and builds only on i386, so wine1.3:amd64 installs wine1.3-i386:i386.
<YokoZar> My worry is that if I put a depends: wine1.3 (= ${binary:Version}) on wine1.3-i386, then if the archive updates i386 before amd64 (due to faster build or copy) then a user who runs apt-get update has wine1.3:amd64 and wine1.3-i386:i386 will see something screwy, like the suggestion that they remove wine1.3:amd64 and install wine1.3:i386.
<YokoZar> *wine1.3 is M-A:allowed and the depends in wine1.3-i386 would be wine1.3:any (= ${binary:Version})
<infinity> YokoZar: buildd skew in a development release is somewhat unavoidable.  Users running devel branches need to not trust apt's "removing everything, kay?" solutions without reading.
<infinity> YokoZar: It's a non issue in a released dist, since we won't push from proposed to updates until all arches are built.
<YokoZar> infinity: That seems reasonable.  And I suppose the archive admins will copy the package set from -proposed to -updates concurrently to avoid that as well.
<YokoZar> infinity: Now I'm worried about the launchpad ppa instead, since they have no way of withholding arches currently
<Sarvatt> YokoZar: yeah it's a huge problem in xorg-edgers with daily mesa updates where one arch always builds up to a day later than the other
<YokoZar> Sarvatt: is there an existing feature request to launchpad to let us tick a box for the PPA somewhere that asks to hold as such?
<infinity> YokoZar: The best way to do it in a PPA is to upload to a trunk/devel PPA, and then copy to a release PPA.
<infinity> YokoZar: And encourage users to use the latter.
<YokoZar> infinity: Ok, but I have the same problem with my daily build recipe PPA, and somehow I don't think having a staging PPA for that is correct ;)
<infinity> YokoZar: Perhaps not.
<infinity> YokoZar: Have you actually tested to see that it's a problem?
<infinity> YokoZar: apt might just hold A back if B isn't in sync, rather than suggest removal.
<YokoZar> infinity: it depends on what's marked manually vs automatically installed
<YokoZar> I think
<ScottK> broder: Thanks.  I ended up downloading the relevant packages.
<barry> ScottK: thanks.  we had some ppc failures last time, but rebuilds fixed them.  i'll look at it.
<barry> cjwatson: awesome! thanks
<om26er> stgraber, hey! can you please sponsor this https://code.launchpad.net/~om26er/ubuntu/oneiric/tomboy/fix-880299/+merge/88910 as well
<stgraber> om26er: sure, I was actually wondering if someone would prepare an SRU for it when I saw it land in Precise :)
<om26er> stgraber, thx, i got another can you please sponsor it as well https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/compiz-sru/+merge/85928 :)
<stgraber> @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:
<stgraber> om26er: ok, will do tomboy and that one, then that's it for this shift
<om26er> stgraber, thank you :)
<stgraber> om26er: hmm, actually I'd better have someone with some kind of compiz knowledge to look at the compiz one. The tomboy one I looked at last week and I know the patch is fine, but compiz I'd rather have a desktop/X person sponsor it
<stgraber> om26er: left a comment + review in that direction, hopefully someone will review it soon
<om26er> stgraber, seb128 is aware of the compiz sru
<om26er> its kind of the official SRU followed by a unity sru
<stgraber> seb128: does https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/compiz-sru/+merge/85928 look good to you? if so, I have it ready for upload here so just let me know and I'll push to -proposed
<stgraber> seb128: oh, and btw, you uploaded tomboy at -1ubuntu1.2 to precise instead of -1ubuntu2 which obviously made om26er SRU invalid as 1.2 already existed in the archive... :)
<stgraber> seb128, om26er: Will repload the SRU as -1ubuntu1.1.1 instead
<om26er> oops, thats all the oneirc/precise system switch :/
<stgraber> ok, re-uploaded with a note in the changelog explaining the weird version number :)
<om26er> stgraber, if that matters the same compiz is uploaded to the ~desktop-team ppa so you can safely do the upload to -proposed ;-)
<om26er> https://launchpad.net/~ubuntu-desktop/+archive/ppa?field.series_filter=oneiric
<stgraber> om26er: fine, I'll upload it in 30min or so then ;)
<om26er> stgraber, ok, thx for the 3upload :)
<seb128> re
<stgraber> om26er: have these changes be pushed to Precise?
<seb128> stgraber, the compiz SRU is fine yes, we have it in the ubuntu-desktop ppa since before holidays
<stgraber> om26er: I just had a quick look and can't find any matching patches or changes in Precise
<stgraber> seb128: maybe you can answer that question? ^
<seb128> stgraber, don't bother about precise, a new compiz release is due there but is taking some time due to the testing etc
<seb128> stgraber, it will land in the next week or so
<stgraber> k, as long as I can blame you if someone ask why I uploaded something to proposed without first uploading to Precise, I'm fine :)
<seb128> stgraber, sorry about tomboy, I used dch -i
<stgraber> I guessed so when I saw the previous entry in the changelog ;) Bah, we'll just have some weird version numbers in oneiric-updates, that's fine :)
<stgraber> om26er: compiz uploaded
#ubuntu-devel 2012-01-18
<FuZi0N> hello
<FuZi0N> Anyone know how to modify the maximum number of connections per user for pptp vpn in ubuntu?
<pitti> Good morning
<SpamapS> is precise shipping python 2.6?
<pitti> not by default
<pitti> I'm not sure, but we might even remove the package
<SpamapS> it will be available though
<SpamapS> wondering about bug 900941
<ubottu> Launchpad bug 900941 in protobuf (Ubuntu) "python-protobuf isn't usable on python 2.6" [Undecided,Incomplete] https://launchpad.net/bugs/900941
<pitti> but many extensions are not built for 2.6 any more
<pitti> so it won't be very useful
<SpamapS> it was uploaded to oneiric-proposed ...
<pitti> SpamapS: yep, that's 2.7 only in precise
<SpamapS> wondering if we should just accept that its going to be broken in 12.04 and accept the SRU.
<pitti> I think so
<pitti> well, it's not "broken" as in "unintentionally not working"
<pitti> we are deliberately dropping support for 2.6
<pitti> (in precise, that is)
<SpamapS> A gentle pat on the bottom of the errant user who hasn't found the joy of python 2.7 yet. ;)
<pitti> so an SRU to o-proposed seems fine, the precise task should then be 'invalid'
<micahg> pitti: are you ok waving the 7 day SRU period for my latest Firefox upload to lucid-proposed?, I fixed 2 upgrade issues
<pitti> micahg: yes, as the previous version has already baked there long enough
<pitti> micahg: so it wasn't released yesterday after all?
<micahg> pitti: well, I just had the last version in there about 9 hours ago, wanted it to bake 12 just in case, I'm running through a round of testing as well, should be ready in a couple hours
<pitti> micahg: *nod*
<micahg> pitti: I was going to push out lucid tonight and maverick tomorrow
<micahg> pitti: migration not happening tonight, found an issue
<micahg> *potential issue :)
<pitti> ack
<dholbach> good morning
<pitti> ev: stole the ubiquity task in bug 712677 from you if that's alright with you?
<ubottu> Launchpad bug 712677 in ubiquity (Ubuntu Precise) "Does not report crashes during "Install Ubuntu" installs" [High,Triaged] https://launchpad.net/bugs/712677
<ev> pitti: quite okay
<jamespage> cjwatson: I discussed whether we should keep groovy 2.0.0 from experimental  with the debian maintainer; he expects at least 4 more beta/rc upstream releases before final release so it may not even make the next release of Debian :-)
<FourDollars> dholbach: Thanks a lot. :)
<dholbach> :)
<dholbach> cjwatson, the ubuntu-changes-auto and ubuntu-patches mailing lists look like they are obsolete - is that correct? (just wondering if they should be moved to the bottom of http://lists.ubuntu.com)
<dholbach> ubuntu-changes-auto likely, but ubuntu-patches seems to have an empty archive, which is weird (I recall patches being sent on the list)
<cjwatson> dholbach: I already mailed Elizabeth about this when she asked on behalf of the CC.  ubuntu-patches is *not* obsolete, it just isn't archived.
<dholbach> ok, thanks
<cjwatson> Because it would be a waste of archive space.
 * dholbach nods
<dholbach> yes
<cjwatson> dholbach: ubuntu-changes-auto probably is obsolete, though.
<dholbach> gracias
<cjwatson> So feel free to move that to the bottom.
<dholbach> I will mail IS
<cjwatson> I don't believe we've used that since we switched from dak to Soyuz.
<cjwatson> But it has archives, so perhaps a "historical interest" section or something. :-)
<dholbach> sure, that's why the bottom of lists.u.c would probably make sense - I didn't mean to get them wiped from the disks :)
<cjwatson> Ooh!  Thank you to whoever made Unity 2D's workspaces be a 2D grid rather than a single row!
<cjwatson> So much more comfortable again.
<soren> Wow.
<soren> sed is doing very interesting things for me right now.
<soren> Guess what output I get from: echo 'AA' | sed -e 's/[^A-Z]//g'
<soren> If your guess is "not a thing", you're right.
<soren> echo 'AA' | LANG=C sed -e 's/[^A-Z]//g'
<soren> on the other hand..
<soren> gives me "AA".
<soren> Awesomesauce.
<soren> "aa" is the old Danish way of writing "Ã¥". I guess when you use ranges in sed it uses locale magic.
<soren> So "aa" is interpreted as though it were "Ã¥".
<cjwatson> soren: LC_COLLATE=C is your friend
<cjwatson> Actually possibly LC_CTYPE=C in this case
<ion> Things like getting sed/date/whatever to behave deterministically in a script are pretty much the only thing LC_ALL is good for.
<soren> cjwatson: COLLATE seems to be the right one.
<cjwatson> I've had LC_COLLATE=C in .bashrc for years
<cjwatson> Lots of locales' orderings go AaBbCc or whatever so that also makes [A-Z] not terribly useful
<soren> Heh :)
<tjaalton> Riddell: hey, uploaded a new libwacom, copyright issue should be fixed, and it's a fresh upstream version too .)
<tjaalton> :)
<tjaalton> Riddell: also, the new frescobaldi needs python-poppler-qt4 that I synced yesterday (NEW), so if you can process that too it would be great
<Riddell> looking
<tjaalton> thanks :)
<Riddell> accepted
<tjaalton> yep, noticed
<mdeslaur_> @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: mdeslaur_
<mbiebl> cjwatson: hi, quick question about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655875#10
<ubottu> Debian bug 655875 in libglib2.0-dev "[libglib-2.0-dev]: the location of glibconfig.h" [Wishlist,Open]
<mbiebl> I'm wondering where the "typo" is, i.e. why you reassigned to libglib2.0-dev
<cjwatson> mbiebl: "package: libglib-2.0-dev"
<mdeslaur_> @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:
<cjwatson> note the extra -, which caused it to land in unknown-package@qa.debian.org's inbox
<mdeslaur> @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: mdeslaur
<mbiebl> urgh, ok
<mbiebl> but as you already mentioned, this bug should just be closed
<cjwatson> sure, I was just making a drive-by comment
<mbiebl> I don't see a point in keeping it open
<mbiebl> ok
<mbiebl> just wondering if you planned to keep it open for a reason
<cjwatson> no
<cjwatson> I don't maintain glib2.0 in Debian so didn't want to step on the maintainers' toes
<mbiebl> ok, thanks for the confirmation
<tkamppeter> Anyone around who has experience with libusb (1.0.x)?
<smb> Daviey, Sorry morning is over already, but just remembered we wanted to talk about bug 607039
<ubottu> Launchpad bug 607039 in nfs-utils (Ubuntu) "NFS4 automount using replicated servers doesn't work" [Medium,New] https://launchpad.net/bugs/607039
<Daviey> smb: right!
<Daviey> smb: might be better to wait for hallyn |?
<smb> Daviey, We can. Not really that urgent
<scott-work> cjwatson: i am a little unsure about what we (ubuntu studio team) need to provide to you for transitioning to a live-dvd, would you explain a little more about what is needed?
 * scott-work apologizes in advance if he is being dense or slow
<arges> diwic, hello. any advice for getting a usb audio device to work? i'm pretty sure its somewhat standard as its outputting stereo fine, but it doesn't seem to register the inputs correctly.  not sure if I should be looking at pulseaudio/alsa etc. I can get it working fine with jackd. thanks
<diwic> arges, do you have a bug nr with some hw info in it?
<arges> diwic, yea that will be the next step. just wanted to know which package would be best to associate with it.
<diwic> arges, "ubuntu-bug audio"
<arges> diwic, ok. cool. i also wouldn't mind learning more about how to fix these types of issues to... so is there a wiki or place where I can look more into this to be more helpful?
<diwic> arges, https://wiki.ubuntu.com/Audio and https://wiki.ubuntu.com/DebuggingSoundProblems
<arges> diwic, thanks
<diwic> arges, you're most welcome to help out with audio issues as we lack manpower in that area.
<arges> diwic, awesome!
<scott-work> good morning, diwic!  how are you doing?
<diwic> scott-work, good afternoon! I'm fine, how about you?
<siretart> the system provided -Bsymbolic-function linker flags breaks on of my packages for precise. do we have a wiki page or something how to deal with that problem?
<scott-work> diwic: i believe i am doing well, thank you :)  just trying to resolve a few issues with ubuntu studio before A2
<diwic> scott-work, go ahead
<diwic> scott-work, if there's anything you want to talk to me about? Otherwise; just keep up the good work :-)
<scott-work> diwic: nothing for you, acutally ;)   i just wanted to tell you 'hello' since we had met at uds-p :-)
<diwic> scott-work, cool. Not sure how far we are at the PulseAudio <-> JACK handover stuff, last time I checked I remember we weren't there yet
<diwic> scott-work, how is the low-latency kernel coming along?
<scott-work> diwic: amazingly, REVU does not seem functional at the moment, therefore we are lacking a verctor to get the kernel into the archives currently
<scott-work> however, we are exploring other means and i plan to raise the issue during the weekly release team meeting this friday
<scott-work> diwic: WRT pulseaudio <-> jack; we are shipping the pulseaudio-module-jack with ubuntu studio, does that not lay the foundation for better integration?
<diwic> scott-work, okay, are you finding the resources and people you need for "exploring other means"?
<Laney> revu is back up
<scott-work> Laney: thank you!  yay!
<Laney> thank siretart
<diwic> scott-work, it should, but the handover was a bit buggy last time I checked
<Laney> :-)
<scott-work> siretart: thank you for REVU being up again!
<jml> My headset mic doesn't seem to work any more on Ubuntu
<scott-work> diwic: i will add checking pulseaudio<->jack integration for A2, would you like feedback on this?
<cjwatson> scott-work: mainly we need a clear specification of what your live environment should contain and how the installed system should differ from it
<scott-work> cjwatson: i am inferring that you would expect the two to differ (well, actually you stated that pretty explicitly), but i am unsure how you feel they should differ
<scott-work> cjwatson: sorry if that was cryptic or oblique, i mean that at this point i don't expect them to differ
<cjwatson> scott-work: well, as a simple existence proof, you don't want the installer on the installed system
<diwic> scott-work, how important do you feel it is that it actually works (the handover)?
<diwic> scott-work, if you/ubuntu-studio feels it's important, I guess I better get down to work and try to fix it ;-)
<scott-work> cjwatson: aye, that is true and i think i am beginning to see your perspective
<scott-work> cjwatson: i had statically viewed this from an installed system perspective, but you saying with the live environment as a base point, what would not go into the install
<scott-work> i had viewed this as what would we exlucde from the installed system to define the live envirnoment
<scott-work> diwic: i think that having pulseaudio<->jack integration is rather important and it certainly gives ubuntu studio a sense of legitimacy that other audio distributions already have
<cjwatson> scott-work: it's more usual, although not universal, for the live environment to be a superset of the installed system
<cjwatson> scott-work: ubiquity is much better at copying vast piles of files from the live environment and then removing a few packages at the end than it is at selecting new packages to install on top
<cjwatson> scott-work: anyway, this is why I need a spec of what it should do for your flavour :)
<siretart> scott-work: pas de rien, please notify me when it breaks again (but it shouldn't)
<scott-work> cjwatson: thank you very much for the explanation :)   is there a particular file in the edubuntu seeds that i can reference to see what they have excluded as examples of things i/we might not have thought about?
<cjwatson> scott-work: if you aren't intending any particular differences other than the installer, I can probably deal with it from there; but I do need to know what you want to have in the live system
<cjwatson> you'll basically end up with something like the Edubuntu live seed on top
<scott-work> cjwatson:  this may be a naive consideration, but are there reasons not to have everything that would be installed available in the live system?
<cjwatson> scott-work: only really details like the boot loader
<cjwatson> scott-work: or language packs perhaps
<cjwatson> scott-work: I'd expect the full set of applications to be available in the live system though
<scott-work> cjwatson: that makes sense, thank you again for helping to clarify and explain the scope
<scott-work> cjwatson: do you still require anything from me?
<scott-work> i feel like i am getting off lightly and feel bad about that fact
<Riddell> oSoMoN: hi
<oSoMoN> hi Riddell
<Riddell> oSoMoN: does this help bug 894805? http://paste.kde.org/188354/
<ubottu> Launchpad bug 894805 in cmake (Ubuntu Oneiric) "QT_IMPORTS_DIR is not defined when no QML plugins are installed" [Medium,Confirmed] https://launchpad.net/bugs/894805
<oSoMoN> let me check that
<oSoMoN> Riddell: it seems to work indeed, I get "QT_IMPORTS_DIR = /usr/lib/qt4/imports"
<Riddell> oSoMoN: was there a real world problem you needed this for?
<oSoMoN> Riddell: yes, let me find the link to the real-world problem
<oSoMoN> Riddell: the issue was originally uncovered here: https://code.launchpad.net/~ballogy/bamf-qt/fix-imports-dir-location/+merge/83248
<Riddell> actually I think this is a better fix
<Riddell> http://paste.kde.org/188366/
<Riddell> but I wish I knew why it was like that in the first place
<oSoMoN> Riddell: and here is actual code that works around the issue and that would benefit from a fix: http://bazaar.launchpad.net/~unity-2d-team/bamf-qt/trunk/view/head:/CMakeLists.txt#L108
<cjwatson> scott-work: well, I don't know what set of packages you want in your live environment yet :-)
<Riddell> oSoMoN: ok I think I can upload my fix but I'd like to ask upstream too because I suspect I'm misunderstanding it
<oSoMoN> Riddell: I can confirm that both patches seem to fix the issue
<Riddell> agateau: do you have an opinion on http://paste.kde.org/188366/ for bug 894805 ?
<ubottu> Launchpad bug 894805 in cmake (Ubuntu Oneiric) "QT_IMPORTS_DIR is not defined when no QML plugins are installed" [Medium,Confirmed] https://launchpad.net/bugs/894805
<agateau> Riddell: the patch makes sense to me
<Riddell> thanks
<agateau> Riddell: I would just enclose ${qt_imports_dir} with double quotes, in case it's empty
<scott-work> cjwatson: if we expect to make some new package sets (i.e. tasks or seeds) further in the cycle, should we include those now (even though they are not fully defined) or can this be addes easily later to the live-dvd?
<scott-work> i think this is the last bit of information before i can answer you fully
<cjwatson> scott-work: it'll be easy enough to add them later
<cjwatson> scott-work: if I were you I would keep the seeds for the current tasks in place, and we can just have the live DVD assembled out of an appropriate selection of those, with stuff like the installer bolted on top
<cjwatson> I just need to know which, really
<Riddell> agateau: you mean like "${qt_imports_dir}" ?
<Riddell> or what?
<agateau> Riddell: yes
<Riddell> oh so it ends up as an empty string if the variable is empty
<scott-work> cjwatson: aye, we would be adding new seeds/tasks to supplement the current seeds/tasks
<Riddell> cmake, nicer than the alternatives but still funny syntax
<scott-work> cjwatson: i believe we need:  audio-common, audio-plugins, desktop, font-meta, generation, graphics, recording, video
<agateau> Riddell: :)
<scott-work_> cjwatson: i lost connection and will repeat my last statement
<scott-work_> cjwatson: i belive we need:  audio-common, audio-plugins, desktop, font-meta, generation, graphics, recording, and video
<scott-work_> cjwatson: i presume we do not need ffmpeg-common as i believe it is used to make sure the other seeds pull the correct files
<cjwatson> that'll get pulled automatically
<cjwatson> OK
<Riddell> oSoMoN: bug 894805 has an item for oneiric, should it be fixed there?
<ubottu> Launchpad bug 894805 in cmake (Ubuntu Oneiric) "QT_IMPORTS_DIR is not defined when no QML plugins are installed" [Medium,Confirmed] https://launchpad.net/bugs/894805
<oSoMoN> Riddell: would be nice to have but not essential
<sabdfl> hi folks
<sabdfl> am getting some persistent badsig errors on updates
<sabdfl> W: GPG error: http://archive.canonical.com precise Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<sabdfl> W: GPG error: http://archive.ubuntu.com precise-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<sabdfl> is there a standard way to check that archive keys are correct?
<cjwatson> sabdfl: analysis in comment 67 of bug 24061 may match
<ubottu> Launchpad bug 24061 in apt (Ubuntu Precise) "GPG error with apt-get/aptitude/update-manager behind proxy (BADSIG 40976EAF437D05B5)" [High,In progress] https://launchpad.net/bugs/24061
<sabdfl> colin, you rock star :)
<cjwatson> I would be inclined to 'sudo rm /var/lib/apt/lists/*Release && sudo apt-get update'
<cjwatson> I suspect you'll find that those Release files in /var/lib/apt/lists/ have junk in them
<sabdfl> how would they have been corrupted? proxies?
<cjwatson> there are basically two possibilities
<cjwatson> the one in that bug is the situation where you've been behind a captive portal at some point and you accidentally ended up with HTML junk in place of Release files
<sabdfl> ah
<sabdfl> <A href="https://secure32.ibahn.com/purchase/purchase?MA=f0-de-f1-72-19-d2&SC=AUSW2&DI=169628198&PN=20&BD=e8668ed1&PX=false" name=a1>Click Here To Continue</A>
<sabdfl> </center></body>
<sabdfl> yes
<cjwatson> the other (which I think happens in Millbank from time to time) is that the proxy caches mismatched versions of Release and Release.gpg
<sabdfl> do ew not sanity check updates?
<cjwatson> it's a bit buggy, as per that bug
<sabdfl> before writing them?
<cjwatson> we're supposed to but there are a couple of dodgy edge cases
<cjwatson> David seemed to understand the problem in that bug so I was planning to leave him to it :)
<cjwatson> the mismatch problem will be solved once we switch to inline-signed Release files, but we have to cycle to a new archive signing key first
<smoser> sabdfl, cjwatson last week i put together https://code.launchpad.net/~smoser/+junk/check-archive/ that checks each of the dns mirrors for a given archive.
<sabdfl> ok
<cjwatson> (because of a bug in some old version of apt that we'd be rendering exploitable otherwise - sigh)
<sabdfl> how often have we cycled keys?
<infinity> Never.
<sabdfl> i see barry's got this inprogress
<cjwatson> the word "cough" comes to mind
<sabdfl> he
<cjwatson> we've tested the process
<sabdfl> *cough*tested
<sabdfl> fresh keys for 12.04, let's not do *that* in a hurry :)
<cjwatson> but it'll have to be done at some point, maybe prepare at the next release sprint and do it for 12.10
<cjwatson> I hoped to do it at the last one but we failed to get round to it
<doko> now I fixed my precise installation, and X complains about the config (too low resolution) and I dont have a visible mouse
<roaksoax> .win 12
<jodh> doko: are you using nvidia by any chance?
<ttx> bdmurray: around ?
<bdmurray> ttx: yes
<ttx> bdmurray: we are looking into doing bugdays on the openstack project, and I was wondering if we could reuse your graphs
<ttx> https://wiki.ubuntu.com/UbuntuBugDay/20111027#Progress
<ttx> to track progress during the event
<bdmurray> ttx: for the project not the package right?
<ttx> yes.
<ttx> bdmurray: for example for https://bugs.launchpad.net/nova
<mdeslaur> @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:
<reed> hi all
<doko> jodh: yes
<jodh> doko: I think you may have hit bug 915334 then: I had exactly the same experience as you describe.
<ubottu> Launchpad bug 915334 in nvidia-common (Ubuntu) "nvidia drivers not setup on upgrade from oneiric to precise" [Undecided,New] https://launchpad.net/bugs/915334
<YokoZar> Why is opencl-headers in multiverse?
<bdmurray> mvo: should there be an html version of DevelReleaseAnnouncment at http://archive.ubuntu.com/ubuntu/dists/precise/main/dist-upgrader-all/current/ ?
<mvo> bdmurray: yes, its auto-generated on bzr-buildpackage, but I guess that it really should be part of the rules file instead, there is no reason not to put it there
 * ScottK notes to lamont to peddle faster.  2.9.0 RC1 is out ...
<lamont> we do not upload rcs
<lamont> I may just say "hell with it" and upload the ~build0 revs to precise directly
<mwhudson> barry: around?
<barry> mwhudson: yes!  how are you?
<mwhudson> barry: i am good thanks
<mwhudson> barry: do you have any idea why a friend might get this: http://paste.pocoo.org/show/536930/ running apt-get upgrade?
<barry> hmm, not off hand, but let me look for something...
<barry> mwhudson: do you know which version he's running the upgrade on?
<mwhudson> barry: no, that would have been a good question
<mwhudson> barry: lucid
<barry> mwhudson: just a sec...
<mwhudson> barry: i now have an account with sudo on the machine in question :-)
<barry> mwhudson: lpbug 689306
<mwhudson> barry: ah, this is a lucid -> maverick upgrade in progress
<barry> mwhudson: see comment #9 in bug 689306
<ubottu> Launchpad bug 689306 in python2.7 (Ubuntu) "package python2.7-minimal 2.7.1-1ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 3" [Medium,Confirmed] https://launchpad.net/bugs/689306
<barry> we really should fix this properly :/
<mwhudson> ah hah
<mwhudson> barry: so basically the trick is to install python2.7-minimal and python2.7 from natty?
<barry> mwhudson: that's what doko suggests.  i haven't run into this personally
<fijal> hi
<mwhudson> barry, meet fijal :-)
<barry> hi fijal :)
<fijal> hi barry :)
<barry> fijal: are you "the friend"? :)
<fijal> I hope so ;-)
<barry> :)
 * mwhudson runs dpkg --configure --pending, it is doing some stuff
<mwhudson> but python2.7-minimal failed
<barry> and that was after installing the natty versions?
<fijal> barry: I think I tried to upgrade to natty and then to oneiric
<fijal> but it all failed fairly horribly
<barry> :(
<mwhudson> lsb-release thinks it's maverick currently fwiw
<fijal> I don't even need python2.7, since I have tons of pythons somewhere else ;-)
<barry> fijal: you might try uninstalling python2.7 and python2.7-minimal then.  you'll get them back during the upgrade
<fijal> how do I uninstall them?
<fijal> apt-get remove fails
<barry> dang
<fijal> because stuff is half-installed
<fijal> http://paste.pocoo.org/show/536945/
<fijal> barry: to be precise
<barry> fijal: try apt-get -f install but i bet it will fail
<fijal> that goes back to python2.7-minimal failing
<fijal> barry: are there fixed versions of those packets available somewhere?
<barry> fijal: did you see the above comment about bug 689306 comment #9 ?
<ubottu> Launchpad bug 689306 in python2.7 (Ubuntu) "package python2.7-minimal 2.7.1-1ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 3" [Medium,Confirmed] https://launchpad.net/bugs/689306
<mwhudson> well, judging by the bug report, natty
<barry> in that doko suggests where to get the working packages
<mwhudson> i also wonder if you can hack the postinst
<fijal> barry: so why does oneiric ones don't work?
<mwhudson> or mv /usr/share/python/runtime.d/public_modules.rtinstall /usr/share/python/runtime.d/public_modules.rtinstall-disabled, or something
<barry> fijal: did you try the oneiric ones, or are you asking whether you can try the oneiric ones?
<fijal> barry: I did try the oneiric ones
<fijal> (I guess those were downloaded when I did dist-upgrade)
<fijal> in related news, aptitude dist-upgrade ate 4G of RAM and crashed :/
<mwhudson> fijal: you know skipping releases is unsupported right?
<fijal> mwhudson: no :)
<mwhudson> ah
<mwhudson> well
<mwhudson> fijal: skipping releases is unsupported
<mwhudson> unless it's lts->lts
<barry> yep
<fijal> ah ok
<fijal> so how do I get out of mess?
<fijal> do I do upgrade maverick->natty->oneiric?
<fijal> or would it just all fail?
<fijal> since there is stuff installed already
<mwhudson> well, i guess going back in time and starting again would be best :-)
<mwhudson> i don't know that "unsupported" means "doesn't work"
<mwhudson> just "isn't tested"
<fijal> apparently
<barry> fijal: i would first try to get out of the python2.7-minimal mess by installing the natty version
<fijal> that's the same thing, isn't it
<fijal> barry: that started the problem
<barry> darn
<mwhudson> fijal: i'd like to try mv /usr/share/python/runtime.d/public_modules.rtinstall /usr/share/python/runtime.d/public_modules.rtinstall-disabled
<mwhudson> and then dpkg-reconfigure --pending
<mwhudson> and then put it back
<barry> yeah, give that a shot
<fijal> mwhudson: try?
<fijal> mwhudson: it won't be any worse, seriously
<mwhudson> ok going
<mwhudson> ok, now it's just the perl crud that's failing to configure
<barry> mwhudson: what's this "perl" thing of which you speak?
<mwhudson> fijal: it's going to take a while, so maybe you should run it: try apt-get install -f again
<fijal> running
<fijal> mwhudson: works much better
<mwhudson> yay
<fijal> mwhudson: any surprizes ahead?
<barry> yay
<mwhudson> fijal: if i knew that, it wouldn't be a surprise, would it? :)
<fijal> :]
<fijal> surprises for me ;-)
<mwhudson> judging from /var/log/apt/term.log it seems to be going fine
<mwhudson> fijal: are you in .za?
<fijal> mwhudson: ya
<mwhudson> i'm surprised how easy it is to type over ssh
<fijal> seems like gonna stay here for the forseeable future
<mwhudson> you must have good internet
<fijal> ssh goes via poland btw
<mwhudson> !
<fijal> the best!
<fijal> 4M ADSL
<fijal> (I'm serious, that's the best option I could get)
<mwhudson> heh
<fijal> mwhudson: you should come and visit :)
<fijal> it's not *that* far
<mwhudson> i do some stuff currently which involves ssh over dsl to the uk and it's a royal pain
 * fijal somehow enjoys sentences with "royal" and "uk"
<mwhudson> fijal: heh would be nice
<mwhudson> probably not soon, realistically
<fijal> I'm not in a rush
<fijal> (this is africa after all)
<mwhudson> :)
<fijal> I would come to NZ if some conference pays for tickets ;-)
<fijal> tumbleweed: hi :)
<tumbleweed> hi
<tumbleweed> I see you are sorted, good :)
<fijal> so....
<fijal> how do we go about debian -> ubuntu pypy import?
<tumbleweed> good question
<tumbleweed> this time of night is bad for these sort of discussions
<fijal> ok :)
<fijal> I'm fine having it tomorrow
<micahg> tumbleweed: we're still mid-day in the US here :)
<tumbleweed> micahg: I can't see ScottK or doko
 * ScottK is staying far away from pypy.
<tumbleweed> barry: any thoughts on sneaking a pypy into precise? (It would be a only-useful-with-virtualenv pypy)
<tumbleweed> ScottK: hrm, my tabc-completion didn't see you
<ScottK> tumbleweed: It's still pre-Feature Freeze, so no sneaking required.
<tumbleweed> ScottK: yeah, I notice most of debian-python is :)
<barry> tumbleweed: hi.  there was some feedback from michael foord suggesting that we really should package 1.7 instead of 1.6 (or 1.8 if it were ready in time)
<barry> fijal: ^^
<mwhudson> fijal: looks like something blew up again
<mwhudson> kde this time
<tumbleweed> we have 1.7 now. 1.8 is expected to release soon, and would be easy enough to upgrade to
<fijal> I can have it in a week-two
<fijal> when is feature freeze?
<tumbleweed> fijal: round the corner, but this is a leaf package, so we can upload a new version after the freeze
<mwhudson>   Package udev is not configured yet. doesn't look happy
<tumbleweed> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<barry> tumbleweed: so, it's just a matter of syncing it from experimental?
<tumbleweed> barry: it hasn't built on arm in Debian (none of the buildds have enough ram)
<barry> :)
<mwhudson> Removing 'diversion of /sbin/udevadm to /sbin/udevadm.upgrade by fake-udev'
<mwhudson> info: unrecognized option '--convert-db'
<mwhudson> dpkg: error processing udev (--configure):
<tumbleweed> but it seems to work fine on x86 and ppc (although there are some lingering big-endian issues)
<tumbleweed> https://buildd.debian.org/status/package.php?p=pypy&suite=experimental <- pretty sorry state :/
<barry> i'm a big +1 on it even if it's only usable in a virtualenv
<tumbleweed> in that case, I need to get our virtualenv to support it
<barry> tumbleweed: hmm. have you tried to build it in a ppa?
<tumbleweed> barry: non-canonical, I don't get armel PPAs
<tumbleweed> but no, I haven't
<fijal> as far as we're concerned, pypy on ARM & PPC will be useful in some months
<fijal> not now and not 1.8
<barry> i actually have a local armel buildbot so i could do a bit of debugging.  well, let me grab the debian package and build it in my ppa and see how it goes.
<barry> fijal: ah
<tumbleweed> barry: you'll need 2G of RAM
<fijal> barry: it has not JIT
<fijal> and as such "just a less compatible python that's a fair bit slower"
<mwhudson> we need some of these http://www.calxeda.com/products/energycore/ecx1000
<barry> ouch, okay, maybe not on my local arm box :)
<fijal> is not *really* that interesting
<fijal> no JIT
<barry> well, even i386 and amd64 would be very nice to have
<fijal> yes
<tumbleweed> fijal: sure, but once we start integrating it with other packages, we need it to be at least functional on all archs
<fijal> those are two platforms where I can see uses
<tumbleweed> otherwise things just get too messy
<fijal> ok
<fijal> tumbleweed: still, months away
<tumbleweed> yeah, but that's not important for precies, I think
<fijal> also because we don't have buildbots
<barry> i think a big question, which also affects jython and is really a question for debian-python, is how do we provide packages for alternative implementations?
<barry> but we can worry about that later
<fijal> barry: can we say "we don't" for now?
<barry> fijal: yes, definitely (imo)
<fijal> "use it with virtualenv" does not sound like a bad idea
<barry> fijal: agreed
<tumbleweed> but we need to start thinking of a long-term plan
<barry> okay, let me start by building the experimental package in my ppa and see how that goes. if it looks reasonable, i'll sync it (but it'll end up in the new queue and will need approval)
<fijal> barry: btw, our releases are loosely-time-based and there are no reasons why they happen at the point they do
<fijal> so we can somehow coordinates times, if that would help you
<fijal> (as a symmetry breaking thing rather)
<tumbleweed> barry: grab the current git head, I bumpde the memory requirement in the last upload, but it looks like it was unecessary (it wasn't the problem on ia64, I don't know what was)
<barry> tumbleweed: i'm still trying to figure out how to use !svn with debian :(
<slangasek> why does evince no longer give me a total page count?
<fijal> I'm going to bed anyway
<barry> fijal: i think if you released a 1.8 by mid-february, tumbleweed could update debian, and then we could sync into ubuntu in time
<fijal> barry: I'll certainly do that, preferably in Jan
<tumbleweed> barry: I added PEP3147, but I'm not convinced that was necessary, yet. I'd love feedback :)
<barry> fijal: that would be great,then we wouldn't have to do a freeze exception
<fijal> barry: our releases are very light :)
<fijal> they're just blessed nightlies that don't fail tests
<tumbleweed> barry: if you want to sync it, I'll grant the exception :P
<barry> tumbleweed: nice!  i'm not sure either, but it can't hurt :)
<fijal> but don't tell anyone ;-)
<barry> fijal: :)
<barry> tumbleweed: beauty
<TheMuso> p/c
#ubuntu-devel 2012-01-19
<poolie> is there any way to have apport still save a core file in to your pwd?
<RAOF> ogra_: I see that armhf doesn't have any of the arm-specific X video drivers; is this intentional?
<infinity> RAOF: Example?
<infinity> RAOF: And if it's just a case of someone doing s/armel/armel armhf/ in debian/control, feel free.
<RAOF> infinity: omapfb, tegra, msm.
<infinity> RAOF: (And no, it's not currently intentional for anything on armel to not be also on armhf)
<infinity> RAOF: Oh, except tegra, which is a binary blob.
<RAOF> Right.
<infinity> RAOF: But anything that's actually free software (which I assume omapfb is?) should be compiled on armhf, yes.
<RAOF> I suspected as such.
<RAOF> Ok.
<RAOF> Yeah, omapfb is.
<RAOF> Hm.  Is there a grep-dctrl rune for selecting packages which Depend on xorg-video-abi-10 *and* are only built on armel?
<RAOF> I take it no one cares too much about omapfb?  Does anyone care if it uses softfloat an armhf?
<infinity> RAOF: Err, what?
<infinity> RAOF: If it uses the softfp ABI, it won't work on armhf.
<RAOF> That's not obvious to me.  Good to know!
<RAOF> Anyway, turns out that what we actually want to do is sync from debian.
<infinity> What's the package name in question?
<RAOF> xf86-video-omapfb
<RAOF> Currently it's not built for armhf; a sync from Debian includes all our changes and adds armhf to the list of architectures as an added bonus.
<infinity> It... Does?
<infinity> packages.qa disagrees... Maybe it's lagging.
<RAOF> http://anonscm.debian.org/gitweb/?p=collab-maint/xf86-video-omapfb.git;a=blob;f=debian/control;h=66ec8b102e36c13a766f87bb2aca30bb44b86773;hb=012d94a229e639317a79fa3ad1eadc27d4f75b5a
<RAOF> Unless the tag lies, of course.
<infinity> Oh, indeed.  I was misreading something, based on the date.
<infinity> Wow, that new device "detection" (and I use that term loosely) code is vile.
<infinity> RAOF: But yes, syncing it looks like the right thing to do.
<infinity> RAOF: (Pressing the button)
<RAOF> You don't need to.
<infinity> Too late? :)
<RAOF> Heh.  'scool.  It's staged in the Xserver 1.11 staging PPA with a -build1 version anyway :)
<infinity> Oh.  That seems silly.
<infinity> But okay.
<infinity> And I'm guessing -msm can just have debian/control mangled for great justice.
<RAOF> Well, I don't think I can sync to the PPA and we want to copy everything at once so we don't have archive-skew.
<infinity> Don't see why you wouldn't be able to copy from debian to a PPA.
<infinity> Though I've never tried.
<RAOF> I don't know where the button is.
<micahg> soren has a script for that I think
<infinity> Well, it wouldn't require a script, per se.
<infinity> Though, if you were scripting, you could sync-package --no-lp, and then upload to your PPA instead of the archive.
<infinity> Which would actually make it look like a sync.
<infinity> But.
<infinity> Just copying the sources would be fine too.
<infinity> Since no one gives a crap about what the .changes in a PPA look like.
<micahg> a script could do it w/out transversing your machine though
<infinity> micahg: I'm not convinced the web UI can't do it, though I haven't looked.
 * infinity looks.
<RAOF> I don't think you actually *can* sync-package --no-lp; the PPA will reject the upload if it's aimed at unstable, right?
<cjwatson> syncpackage --no-lp will fiddle with Distribution in .changes.
<infinity> ^
<infinity> It's the target in .changes that matters, not the one in the changelog.
<cjwatson> syncpackage without --no-lp can't copy to PPAs yet
<cjwatson> see Archive._checkCopyPackageFeatureFlags in LP
<cjwatson>             # We have no way of giving feedback about failed jobs yet,
<cjwatson>             # so this is disabled for now.
<RAOF> infinity: https://launchpadlibrarian.net/90400263/buildlog_ubuntu-precise-armhf.xf86-video-msm_1.0.1%2Bgit20100122.5f7df591-1ubuntu1_FAILEDTOBUILD.txt.gz is a FTBFS of mxm on armhf.  It looks like a toolchain issue, maybe?
<infinity> RAOF: Multiarch sadness.
<RAOF> Hm.  Execpt perhaps for the bit where it goes  -march=armv7-a -mfpu=neon -mfloat-abi=softfp
<micahg> umm, I'm curious about the recent uploads limiting the arch, most of them seem to make more sense as p-a-s since it's stuff they build on that's limited
<infinity> RAOF: That's also bad. :P
<infinity> RAOF: Should be -mfloat-abi=hard (or not have the flag at all, since our compilers on armel and armhf get it right)
<infinity> micahg: Which recent uploads?
<infinity> Oh, indi-sbig?
<micahg> https://launchpad.net/ubuntu/precise/+source/indi-sbig/1.0-0ubuntu2, https://launchpad.net/ubuntu/precise/+source/crystalspace-glshader-cg/1.4.0-1ubuntu1
<infinity> micahg: If it depends on some binary blob or something (which I guess is the case in the crystalspace one?), setting the arch in control seems reasonable.
<infinity> It's not arch-specific because it "needs porting", it can't be ported.
<infinity> micahg: Same deal for the other one, it would seem.
<RAOF> Aww, that's so cute.  Hardcoding CFLAGS in Makefile.am
<infinity> Speaking of porting, do I trust this fpc_armhf binary I just built?
<micahg> yeah, I was thinking along of lines of if the thing itself isn't arch specific, just the dependency, that might change over time
<infinity> micahg: Sure, but if the dep changes, you're editing control anyway.
<infinity> micahg: So, you can fix the arches. :P
<infinity> micahg: Which is, actually, way less hassle than P-a-s.
<cjwatson> argh
 * cjwatson introduces gnome-games to Replaces
<infinity> fpc uncleverly compiles everything statically, doesn't it?
<infinity> Which means a new upstream version doesn't require a transition...
<infinity> Hrm.
 * infinity decides to take his newly-built 2.4.4/armhf binary and use it to bootstrap 2.6.0 and see how that goes.
 * RAOF decides that's enough arm faffing and goes to have some lunch.
<cjwatson> Could somebody on a more appropriate timezone than me please update ubuntu-meta after this publisher run finishes, such that it removes gnome-mahjongg and adds mahjongg?  It shouldn't be more than about 15 minutes from now until archive.u.c updates, but I really need to crash.
<cjwatson> And this will fix tomorrow morning's CD builds, not to mention the ARM failures that are coming in now.
<infinity> cjwatson: Can do.
<cjwatson> Ta
<cjwatson> I'm doing xubuntu-meta now since that doesn't need mahjongg to be in main
<cjwatson> Argh, xubuntu-meta fell over with a Packages validation error
<cjwatson> infinity: Would you mind doing xubuntu-meta as well?
<cjwatson> One of these days I'll make germinate more robust against that and have it brutally retry everything without caching on hash mismatches or something ...
<micahg> I can take care of xubuntu-meta
<micahg> unless infinity wants to do it that is
<SpamapS> woot, my touchpad works
<SpamapS> stock precise seems to work perfectly on the MBA 4,1 .. yay
<mwhudson> SpamapS: QUICK RELEASE
 * SpamapS looks at the greybeards guarding the release levers and wonders if he can get past them before they cast Great Fireball to incinerate him
<infinity> cjwatson: I can do both.
<infinity> micahg: ^
<infinity> SpamapS: My beard's not that grey... :(
<pitti> Good morning
<pitti> jibel: I updated https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-lts-upgrades with a link to the gdm->lightdm migration test; it uses python unittest, I believe that's an output format you can handle?
<pitti> jibel: it has a header which explains the details; please let me know if you need it to do something different
<jibel> pitti, good morning
<pitti> jibel: bonjour Monsieur, ca va?
<jibel> pitti, trÃ¨s bien et toi ?
<pitti> jibel: je sui bien, merci!
<pitti> jibel: working on user config migration test right now
<jibel> pitti, thanks for the script, I'll add it to the upgrade test today.
<pitti> jibel: trying to remember which other popular settings we mentioned, besides background image
<pitti> jibel: for the system one it's sufficient to run it after upgrade
<pitti> jibel: for the user one, we need a "prepare" shell script to run in the lucid environment; will that be possible?
<jibel> pitti, yes it will. we can run a script right after the initial bootstrap to prepare the environment
<pitti> jibel: i. e. the prepare script wiggles the old settings (gconf/custom launchers), then you upgrade, and the test_lts_upgrade_user.py script will then check what the new gsettings/launchers are
<jibel> pitti, I added support to catch debconf prompts yesterday
<jibel> pitti, here is an example https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lts/PROFILE=lts-server,alderamin-upgrade=alderamin-upgrade/12/artifact/lts-server/
<pitti> jibel: yay, with the fake editor trick?
<pitti> jibel: ah, you both have a full log, and some "known good/bad" parts of it?
<jibel> pitti, right. It was trickier than expected because the noninteractive frontend overrided the frontend.
<jibel> pitti, I collect the full log then split it in pieces for each /unexpected/ prompt
<pitti> jibel: ah, so you have to monkey-patch upgrade-manager for this? :)
<jibel> pitti, there is also a whitelist for prompts we'd like to see anyway.
<jibel> pitti, the node on which lts tests runs uses update-manager form bzr and I proposed a patch
<jibel> *from
<pitti> jibel: ah; I guess it's enough to not touch it if the environment already has it set?
<jibel> pitti, yes, that's the patch.
<pitti> jibel: do you remember anything else except background image and custom launchers?
<dholbach> good morning
<pitti> jibel: oh, screensaver settings
<pitti> jibel: e. g. lock/nolock and the timeout
<pitti> jibel: .. and I'll set the Radiance theme and check that this is maintained
<pitti> didrocks: ISTR that unity migrates the old panel launchers, does it? I'd like to add it to my LTS upgrade test script
<didrocks> pitti: yeah, it migrates: icons in the panel launcher as well the ones on the desktop
<didrocks> it tries to merge them as well
<didrocks> (I think we don't want to test migrating from cairo-dock, awn, and other docks that it supports too)
<pitti> so I'll try four cases: launcher dragged from app menu to panel (pointing to system .desktop), custom launcher in panel, custom desktop icon, and system desktop icon link
<didrocks> yeah, sounds right
<jibel> pitti, I have just 'popular settings we'd like to preserve' on my notes, and also launcher, lightdm/gdm (autologin), language/keyboard, nm (needs to be tested on hw for wifi), proprietary drivers
<jibel> pitti, we could also check that proxy and a11y settings are preserved
<pitti> jibel: language requires some extra discussion (will ping you again when I did the other stuff), nm pretty much tests itself (do the upgrade over wifi)
<pitti> jibel: proprietary drivers is not on my todo list, right?
<jibel> pitti, no it is not and it also needs hw which can't be tested with the auto upgrade tester. I'll see what I can do with the hw available in the lab and cobbler/orchestra.
<mvo> slangasek: next issue with the new apt, the debian dpkg wants to be configured using pkgname:arch but our dpkg does not understand that yet so it leaves the pkgs unconfigure *sigh*
<pitti> didrocks: got the test cases for app/custom panel starter now, both work; but why would custom .desktop files on the desktop go into the launcher, and not stay on the desktop?
<didrocks> pitti: this was a design request: everything, even on the desktop, should go to the launcher so that people can remove them from the desktop
<pitti> hmkay
<didrocks> pitti: I know it irritated some people at the time, maybe we should check back with John, it was at the time we didn't "show desktop" IIRC
<didrocks> (on UNE)
<pitti> didrocks: let me try it, and I'll add it to the test cases
<pitti> didrocks: if we decide that it shouldn't happen, it's a good negative test case, and we can just flip assertTrue to assertFalse :)
<didrocks> pitti: indeed :)
<didrocks> (changing that will take me 10s FYI in the migration script), so just need to take the time to talk to John
<pitti> didrocks: oh, so it actually copies the .desktop file to someplace else then?
<pitti> didrocks: for the panel launchers it just keeps the ones in .gnome2/panel/...
<didrocks> pitti: I need to refresh my memory, one moment
<pitti> didrocks: if you don't move them, then they'd just stay on teh Desktop, and if you remove them from Desktop/, they'd break from the launcher as well?
<didrocks> pitti: yeah, was definitively at the time we used UNE and didn't show desktop
<didrocks> pitti: so, they are not copied, which seems indeed useless right now
<didrocks> pitti: I'll catch this up with John :)
<pitti> didrocks: merci
<didrocks> pitti: thinking about that, we need to handle the transition from UNE 10.04 -> ubuntu 12.04
<didrocks> pitti: it should import the favorites from netbook-launcher
<pitti> didrocks: ah, indeed
<didrocks> pitti: de rien :)
<pitti> sounds like a nice additional test case, too
<didrocks> indeed
<pitti> didrocks: ah, it's clever enough to just say "gucharmap.desktop"
<pitti> didrocks: instead of Desktop/gucharmap.desktop"
<pitti> didrocks: so that part technically works, although it's looking strange
<pitti> so I'll do add a totally custom launcher, too
<didrocks> pitti: yeah, I have a quite long algorithm to try to prefer system ones
<didrocks> matching on desktop name, then on exec key nameâ¦
<jamespage> morning: can someone help me with this package build failure
<jamespage> https://launchpadlibrarian.net/90422989/buildlog_ubuntu-precise-armel.hadoop_0.20.205.0-0ubuntu1~hadoop4_FAILEDTOBUILD.txt.gz
<didrocks> that's what I meant by "merging the launcher"
<didrocks> (and why you don't have two firefox.desktop launcher icons)
<jamespage> package build fine on the other four architectures and on some armel builds; dpkg-shlibdeps is doing something weird
<jamespage> builds just fine on my local armel install :-(
<pitti> didrocks: ok, got all four covered now
<didrocks> excellent! thanks pitti :)
<pitti> didrocks: avec plaisir!
<fijal> hi
<fijal> I think I managed to crash unity up to the point where it does not start even
<fijal> how can I find out what's going on?
<fijal> is there any log, can I run debug mode?
<tumbleweed> fijal: .xsession-errors?
<fijal> where?
<fijal> in .
<fijal> ?
<fijal> er
<tumbleweed> in ~
<fijal> in ~
<fijal> (unity-window-decorator:2146): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
<fijal> I'm kind of used to that CRITICAL
<tumbleweed> you'll see lots of thnigs like that
<tumbleweed> also, this isn't really a support channel, but if you want to get it back to a sane state: unity --reset
<tumbleweed> barry: I see your i386 pypy PPA build didn't have enough RAM. Retry it and hope that we have bigger PPA builders available?
<fijal> tumbleweed: I know this is not a support channel, but I'm trading priority support for priority support I guess :)
<pitti> jibel: I have the user settings part ready now as well, BP updated
<micahg> pitti: can you please copy ubufox/lucid to lucid-proposed and ubufox/maverick to maverick-proposed from ubuntu-security-proposed?
<barry> tumbleweed: saw that, will do!
<pitti> micahg: oh, just ubufox, not firefox and the langpacks?
<pitti> micahg: oh, nevermind, misread
<pitti> micahg: sure
<pitti> micahg: done
<micahg> pitti: thanks
<slangasek> mvo: hmm, lovely :P
<mvo> slangasek: the unstoppable david worked it out in the end
<slangasek> ok :)
<mvo> preparing a version (again!)
<cjwatson> mvo: is there a particular reason there's no DistUpgrade.cfg.precise in update-manager yet?
<cjwatson> was just looking for how it handled the removal of the transitively-essential lzma, and couldn't find anything
<cjwatson> oh, looks like update-manager doesn't have the same transitively-essential handling that apt itself does
<cjwatson> so I guess it wouldn't run into that
<mterry> @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: mterry
<dholbach> hey barry - with http://blog.bazaar.canonical.com/?p=405 do we have to fix/change our docs?
<Laney> ooh, those are exciting fixes
<smoser> in ec2 instances, i get errors to the console on boot of 'mountall: Event failed'
<smoser> that seems to generally be not a problem, but I'm wondering if anyone would know the source of that message.
<smoser> i see it on all boots, not just the first (when cloud-init is admittedly playing funny as it updates /etc/fstab on mounted /)
<slangasek> cyphermox: hey there
<barry> dholbach: we will :)
<cyphermox> slangasek: hey
<cyphermox> is this about bluez?
<slangasek> cyphermox: yeah ;)  hold that thought, I'm just getting upgraded from -0ubuntu1 to -0ubuntu3
<slangasek> (dunno why update-manager hadn't told me about it yet)
<cyphermox> yeah, it was majorly messed up, sorry
<slangasek> cyphermox: so, after upgrading from -1 to -3, I see the following problems so far:
<slangasek> - bluetooth-daemon service is still running and can't be stopped (because the job file no longer exists)
<slangasek> - /etc/init/bluetooth-daemon.conf.dpkg-backup is left behind even though I never modified this file
<cyphermox> hm
<slangasek> - package is considered successfully installed even though 'bluetooth' job hasn't been started
<cyphermox> slangasek: the big issue was that -0ubuntu1 really, because if you upgrade straight from 4.96-* things work out properly
 * cjwatson spies a pending libwmf merge that should take care of this messy upgrade bug
<slangasek> cyphermox: and the big issue: pulseaudio still doesn't see my headset
<cyphermox> I tried to fix the crap that was there, but I see it didn' t work out -- weird because I tested upgrading between the 4.96-* version and from 4.98-0ubuntu1 before uploading
<slangasek> (after manually shuffling jobs)
<cyphermox> slangasek: rebooting would help
<slangasek> not acceptable ;)
<cyphermox> slangasek:  I know ;)   initctl list | grep bluetooth ?
<slangasek> $ sudo initctl list | grep bluetooth
<slangasek> bluetooth start/running, process 27296
<slangasek> bluetooth-device (hci0:12) start/running
<cyphermox> ah?
<slangasek> also, why are we trying to start/stop bluetoothd on device add/remove *anyway*?
<cyphermox> but was your headset ever paired? let me get mine and test it on this system I just upgraded
<slangasek> what do you mean, "ever paired"?  it's been working for a solid year
<slangasek> this is a regression
<slangasek> if I restart pulseaudio, I can now see it listed in 'hardware', but not available in the input/output list
<slangasek> (under gnome-control-center sound)
<slangasek> and pulseaudio didn't get upgraded, only bluez
<cyphermox> slangasek: what I mean is, I' m trying to understand why it doesn' t work for you, when I precisely tested that on my own system, from either the very old version or the broken 4.98-0ubutnu1, and things *were* working
<dholbach> barry, should I file a bug about it?
<cyphermox> slangasek: ah, what profile is used for your headset?
<cyphermox> slangasek: A2DP?
<slangasek> cyphermox: I use both a2dp and hsp/hfp profiles; it looks like the sink is only missing in the a2dp profile
<cyphermox> slangasek: right, I see that too
<slangasek> cyphermox: ok.  should I file a bug report?
<cyphermox> please
<doko> \o/ notebook working again ...
<cyphermox> that's indeed a regression from 4.96, though it's better than what state 4.97 was in :)
<cyphermox> slangasek: any help with fixing up that upstart job mess would be welcome
<cyphermox> slangasek: the whole point of the upstart jobs was to avoid having bluetoothd running when you don' t have bluetooth devices though
<slangasek> why is that worthwhile?
<slangasek> unused daemons are cheap
<cyphermox> but why keep it running when it' s not necessary
<dobey> it makes up for the ones in use that are expensive
<cyphermox> dobey: meh
<dobey> heh
<dobey> and there's no need to run things that aren't needed
<dobey> saves resources, and energy, to not have them running
<dobey> however miniscule the change is. but 2 million people using 0.01W less is a lot across the board
<slangasek> no, it doesn't
<slangasek> properly-written daemons don't wake up when not needed
<dobey> they still occupy N bytes of memory, which requires electricity
<slangasek> the memory is all powered regardless
<slangasek> this is a false optimization
<pitti> cyphermox: ^ pretty much what we discussed last week already, AFAIK; I think having an upstart rule to auto-shutdown bluezd is an interesting intellectual exercise, but the main point is to power down the _device_ if you disable it
<cjwatson> this was once parodied as "zeroes use less power than ones"
<slangasek> the only time it matters is if you have memory pressure on the machine
<pitti> keeping the daemon running actually helps to avoid cycles the next time you need it again
<slangasek> but you probably have firefox running, so bluetoothd is lost in the noise :P
<pitti> I do agree that bluezd should not start up until you actually have a bluetooth device (or the killswitch on)
<pitti> cjwatson: that was from the pre-CMOS time?
<pitti> (when it probably was quite true)
<seb128> well running process might not use cpu but they use memory
<seb128> not to mention they take time to start so slow boot
<cjwatson> pitti: nope, Ubuntu era
<slangasek> on-demand starting of bluetoothd seems fine, sure
<slangasek> but the stopping is really unnecessary
<pitti> seb128: right, speaking of automatic shutdown
<slangasek> (and probably racy, for that matter)
<stgraber> pitti: I wouldn't mind bluetoothd not being stopped by upstart if soft kill switch was persistent across reboot. I use bluetooth maybe once a year on this machine and I don't have a separate hardware kill switch for bluetooth (except turning it entirely off in the bios ...)
<pitti> cjwatson: reminds me of "investigate power difference between black or white screen (even for DPMS off)"
<slangasek> pitti: that one was investigated and did show power savings ;)
<pitti> stgraber: yes, cyphermox was looking into making the enable/disable persistent across reboots
<pitti> slangasek: right
<diwic> slangasek, right, but it was the white screen (surprisingly!) that was most power efficient?
<stgraber> pitti: that was at the gnome level though so bluetoothd will always start, then the adapter wil lbe turned off when I login but the daemon will still run
<dobey> diwic: on an LCD, yes.
<pitti> slangasek: but I wonder when someone actually measured power consuption with all (free) memory set to 0 or 1 :)
<slangasek> stgraber: the soft kill switch needs to be persistent *regardless*, and stopping the daemon doesn't help with that at all
<cyphermox> seb128: pitti: not simple, unfortunately, since upstream decided gnome-bluetooth was not the right place to do this.
<dobey> but not surprising at all
<pitti> dobey: it is surprising as it said "even with dpms off", i. e with the screen being powered down
<pitti> cyphermox: *nod*; but at least I think we all agree that it's generally a good idea
<dobey> pitti: dpms on an LCD doesn't exactly power the screen down though
<dobey> at least not in the same way it does on a crt
<stgraber> cyphermox: if I was to make soft kill persistent across reboot would that work for you (rather than patching gnome-bluetooth and do it at the session level)?
<dobey> i want an oled screen, but nobody makes any with a good resolution :(
<stgraber> slangasek, cyphermox: Sounds like we just need to dump /sys/class/rfkill/*/soft and restore at boot time
<slangasek> that would be nice
<cyphermox> stgraber: yeah, sure
<cyphermox> I mean, everybody would probably be quite happy about it :)
<stgraber> (probably checking it's the same device too :))
<stgraber> k, will do it later today then, should be pretty easy to do with a simple upstart job
<dobey> anyway, i was talking about the fact that not starting it in the first place would save power. shutting down an idle running (proper) daemon will probably use more power than it does to sit there and not do anything
<slangasek> yep
<cjwatson> http://paste.ubuntu.com/809717/ - anyone object to the creative solution of sticking a no-op prerm in the new libwmf0.2-7?
<slangasek> isn't that the standard workaround? :)
<cjwatson> I hadn't encountered it before
<slangasek> ah... I have
<slangasek> anyway, no objection :)
<cjwatson> where, out of curiosity?
<slangasek> hmm, been a while since I've run into it actually
<slangasek> so probably nowhere readily discoverable
 * cjwatson notices that policy does actually have some careful wording about this nowadays
<cjwatson> All package dependencies will at least be "Half-Installed" and will have previously been configured and not removed. If there was no error, all dependencies will at least be unpacked, but these actions may be called in various error states where dependencies are only "Half-Installed" due to a partial upgrade.
<cjwatson> so you can at least deduce the possibility of this class of problem from the documentation if you think about it
 * cjwatson ponders the feasibility of auditing for this
<BenC> doko: Any ideas on the ghc assembler errors on powerpc that is causing, for example, haskell-hashtables to fail to build?
<BenC> https://launchpadlibrarian.net/87619504/buildlog_ubuntu-precise-powerpc.haskell-hashtables_1.0.0.0-1build1_FAILEDTOBUILD.txt.gz
<doko> BenC, sorry, no. did it build before, or in Debian?
 * doko reboots
<BenC> doko: no idea, just getting into it
<BenC> doko: doesn't exist on ubuntu-ppc
<BenC> hrrmâ¦guess I assumed doko was using screen
<stgraber> slangasek, cyphermox: http://paste.ubuntu.com/809739/ (rfkill-store.conf) and http://paste.ubuntu.com/809740/ (rfkill-restore.conf)
<slangasek> stgraber: is the name guaranteed to be whitespace-clean?
<BenC> doko: it doesn't appear to have ever built on ubuntu at least
<BenC> ubuntu-powerpc that is
<doko> BenC, good =)
<doko> Laney, ^^^
 * Laney perks up
<Laney> ah, yeah, I meant to raise that. It fails the same way on Debian.
<stgraber> slangasek: I can't find a clear definition of it in the kernel documentation other than it being a kernel device name which AFAIK can't contain spaces (I'd expect a lot of the userspace to break if they could)
<slangasek> stgraber: ok - looks fine to me then
<Laney> if you're brave you can pass -keep-s-files to see what's going on
<slangasek> stgraber: which package will own this? rfkill itself?
<BenC> Laney: I did that
<Laney> and another interesting thing would be to try building with ghc from experimental
<slangasek> stgraber: oh, shouldn't this be 'start on runlevel [016]' instead of 'runlevel [!2345]'?  I don't see any reason to save when switching to single user mode
<BenC> Laney:         srwi    3, 4, 32
<stgraber> slangasek: yeah, I'd make it part of rfkill even though it doesn't depend on the rfkill tool itself
<BenC> Laney: that's the 32 that it claims is out of range
<Laney> failing that I believe Erik de Castro Lopo in pkg-haskell is interested in ppc issues
<stgraber> slangasek: oh, correct indeed. I based it on alsa-store but [016] is indeed better
<Laney> d-haskell@ is a good venue
<BenC> Ok, thanks
<slangasek> stgraber: cool - thanks for taking care of this
<stgraber> np. It's been annoying me for a while (on plane for both wireless + bluetooth and for bluetooth the rest of the time), good to have that fixed for 12.04
<Laney> BenC: powerpc is a community supported arch as far as GHC upstream are concerned, with all that that implies
<slangasek> stgraber: on plane you should be using the hardware switch! :)
<stgraber> slangasek: indeed :)
<slangasek> mvo: do you remember what this workitem for lts-upgrades means?: "grep maintainer scripts for dpkg --compare-versions"
<mvo> slangasek: that was to ensure that compat fixups don't get dropped because its no longer relevant for debian but it is for us
<BenC> Laney: I'm not familiar with ghcâ¦does it actually emit the assembler or go through gcc somehow?
<BenC> IOW, where does the blame lie?
<slangasek> mvo: so which maintainer scripts are supposed to be grepped?
<mvo> slangasek: compat fixes in the maintainer scripts, so we would have to build a map of what version are in lucid and try to find out if between lucid and precise maintainer scripts with compat code get dropped
<mvo> slangasek: ideally all I would assume
<mvo> slangasek: but thats obviously a bit of work
<slangasek> mvo: I guess I still don't follow... do you need to look at the maintainer scripts for all binary packages uploaded between lucid and precise?
<slangasek> jibel: your recent edit of foundations-p-lts-upgrades whiteboard has added a line that doesn't seem to be a workitem at all? "It doesn't improve performance because virtual disks are setup to dynamic resizing [...]"
<mvo> slangasek: this is what I remember from the discussion, yes
<mvo> (from the UDS discussion)
<slangasek> mvo: ok - let me expand that description so it's clearer then, thanks
<slangasek> mvo: do you think we need to inspect just the versions shipped with each intervening release, or all uploads to Ubuntu, or all uploads to Ubuntu *or* to Debian?
<Laney> BenC: Both. I believe that powerpc is built "registerised" which means that it uses GHC's native code generator. You can check with `ghc --info'
<jibel> slangasek, that's a comment to explain why it's done but doesn't improve performances. I'll move it to the bottom of the bp.
<Laney> we should investigate using the LLVM backend more
<slangasek> jibel: what doesn't improve performance? eatmydata?
<BenC> Laney:  ,("Unregisterised","NO")
<Laney> BenC: "Have native code generator"?
<BenC> Laney: Yes for native and llvm
<cjwatson> jibel: How do I see what commands were run as part of https://jenkins.qa.ubuntu.com/job/precise-upgrade-lts/PROFILE=lts-main-all,alderamin-upgrade=alderamin-upgrade/lastFailedBuild/ ?  "View Configuration" shows nothing
<Laney> should be using that then (i.e. ghc gets the blame)
<BenC> Laney: is there a way to build ghc that would be more "safe" rather than fast or native?
<Laney> I think the right solution is to be using llvm
<seb128> barry, doko:  CFLAGS="-g -O0-Wall" python-config --cflags  ... returns an attributeerror 'NoneType' object has no attribute 'split' on precise
<cjwatson> jibel: (I'm downloading and restoring the apt-clone state here and want to know how to reproduce the problem locally - even if somebody else is already on top of this one, I want to develop this skill anyway)
<seb128> barry, doko: is that a known python bug?
<seb128> using python2.6-config works
<BenC> Laney: How do I force that? (I don't mind rebuilding ghc)
<seb128> that breaks the build of some GNOME sources
<doko> seb128, yes, need to fix that
<seb128> doko, do you have any workaround or eta for the fix?
<slangasek> jibel: I guess when you get right down to it, I don't understand what your comment says, or how that would interfere with the eatmydata benefits... are you doing the upgrades entirely in a ramdisk?
<jibel> slangasek, yes with eatmydata.
<Laney> BenC: not sure I'm afraid, but you should be able to pass -fllvm at compilation time
<seb128> doko, it's blocking some updates I'm working on
<Laney> BenC: I'm looking at http://www.haskell.org/ghc/dist/current/docs/html/users_guide/code-generators.html
<Laney> maybe there are gremlins I'm not aware of though
<jibel> cjwatson, the configuration of the job is not published on the public instance.
<Laney> hrm, that is for a newer version than we have in Debian
<cjwatson> jibel: is it in a bzr branch somewhere, say?
<doko> seb128, don't set CFLAGS explicitly. it should do the correct thing. but call python-dbg-config for the -debug build.
<seb128> doko, I don't set CFLAGS, something in the toolchain do it for me
<BenC> Laney: ghc: panic! (the 'impossible' happened)
<BenC> Laney: not much better :)
<Laney> heh
<seb128> doko, toolchain -> packaging tools
<Laney> try with 7.4 in exp
<Laney> this is where I defer to debian-haskell :P
<seb128> doko, "dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
<seb128> "
<seb128> doko, not sure I can get around that (python-config is called by the configure)
<cjwatson> but the CFLAGS you quote is completely different
<BenC> Laney: ok, building that on precise now. Thanks for your help
<seb128> cjwatson, right, I took a random example, CFLAGS= python-config --cflags will break
<Laney> np
<seb128> cjwatson, i.e any python-config --cflags call will fail if CFLAGS is defined it seems
<cjwatson> you could 'unset CFLAGS; ./configure' as a temp workaround, presumably
<cjwatson> (or env -u CFLAGS ./configure, neater)
<cjwatson> obviously that means you lose hardening flags so it's not great
<seb128> right
<seb128> which is why I was reluctant to do it
<seb128> I might just replace the python-config call by its result as a workaround until python is fixed
<seb128> i.e hardcode the result
<seb128> cjwatson, doko: thanks
<doko> well, hardening flags are turned on by default, so you only loose the -Wformat-security
<doko> I'll have to fix that
<jibel> cjwatson, https://wiki.ubuntu.com/QATeam/UpgradeTestingSetup
<BenC> Laney: _s235 = _s1Xh >> 0x20U;
<BenC> Laney: this is where the problem is coming in to playâ¦it's trying to do a bit shift of 32 on a 32 bit valueâ¦maybe it works on other architectures, but not powerpc :)
<jibel> cjwatson, checkout update-manager from bzr then go to update-manager/AutoUpgradeTester and run ./auto-upgrade-tester profile/lts-main-all
<BenC> I suspect that affectively nulls the value, but I'm not sure why you would do it like that
<cjwatson> jibel: ah, great, thanks
<jibel> cjwatson, from an apt-clone run auto-upgrade-tester <clone_file>
<jibel> cjwatson, it will create a base image from the clone and upgrade it
<BenC> Or it's expecting a 64-bit var but using a 32-bit by mistake
<cjwatson> looks like 'do-release-upgrade -d -f DistUpgradeViewNonInteractive' should be a decent start given an existing chroot
<cjwatson> (my chroots are slightly hacked)
<jibel> slangasek, the tests are running on qcow2 images on physical disks. I also tried with raw instead of qcow2 and cache=unsafe but the difference with the defaults settings is very small (10s or so for a 4 minutes upgrade)
<jibel> slangasek, FYI the server I used uses hw raid
<slangasek> jibel: hmm, but the point of eatmydata is that the kernel doesn't have to flush it out to the underlying disk at all
<slangasek> I would expect this to have the same effect whether the disk is a virtual image or not
<slangasek> but anyway, if the whole upgrade only takes 4 minutes, yeah, it's not worth it
<jibel> slangasek, that was what I expected too and was surprised by the result. I'll try on a smaller system and bigger upgrades.
<slangasek> jibel: what filesystem are you using within the VM?
<jibel> slangasek, ext4
<mvo> slangasek: sorry, had a call - just the version in each release is my gut feeling
<slangasek> jibel: right, nothing unusual there... I dunno then
<slangasek> mvo: ok
<BenC> Laney: Same errors with experimental ghc 7.4
 * BenC drops this, wasting too much time on it
<Laney> BenC: OK, good findings anyway. If you could mail your summary to d-haskell someone will probably send it upstream
<BenC> Laney:
<BenC> Laney: ok
<Laney> cool
<Laney> why are you interested in this, OOI?
<BenC> Trying to resolve ftbfs on powerpc
<Laney> ah, no special haskell interest then
<Laney> fair 'nuff
<BenC> None whatsoever :)
<YokoZar> Can someone tell me why opencl-headers is in multiverse?  I want to build wine with it but this requires demotion of wine or promotion of opencl-headers
<micahg> it's in contrib in Debian. that's probably how it ended up there
<micahg> YokoZar: seems like a good candidate for universe, I'd suggest filing a bug and subscribing ubuntu-archive and then pinging someone if you need it sooner
 * ScottK agrees
 * SpamapS jumps out of his chair when he realizes the speakers on his MBA are working in Linux now.. and the volume is all the way up.
<BenC> cjwatson: what's the usual process for something like powerpc packages failing in dpkg-gensymbols during build?
<BenC> cjwatson: is it just a matter of getting the symbols updated for that arch?
<om26er_> hey mterry
<om26er_> can you please sponsor https://code.launchpad.net/~om26er/ubuntu/oneiric/nux/sru-819721/+merge/88592
<janimo> BenC, in the few cases I ran into similar with armel I just updated the symbols.armel package as the error suggested
<BenC> janimo: and then reupload with that?
<janimo> unless it is an error and some symbols should not be there but that needs knowledge of said package
<janimo> BenC, yes, it only affects the specific arch
<BenC> Ok
<BenC> I suspect it's just a matter of the maintainer not having access to those symbols
<BenC> janimo: thanks
<janimo> BenC, np
<cjwatson> BenC: yeah, generally what janimo said
 * cjwatson bangs head against python3-apt
<dobey> hrmm
<dobey> what's the best way to do "Depends: libgudev-dev | (libhal-dev >= 0.5 & libhal-dev < 0.6)?
<BenC> dobey: I believe it's "don't do that"â¦but one way might be to have a virtual package that depends on the second half, and use that instead
<cjwatson> or expand it using boolean idedntities
<cjwatson> *identities
<dobey> or i guess i can just not do it, since there doesn't seem to exist a hal 0.6 anyway
<cjwatson> Depends: libgudev-dev | libhal-dev (>= 0.5), libgudev-dev | libhal-dev (<< 0.6)
<YokoZar> ScottK: Bug filed, and thanks :)  https://bugs.launchpad.net/ubuntu/+source/khronos-opencl-headers/+bug/918837  (Wine is currently in dep-wait on this, so at your convenience please)
<dobey> ah right
<cjwatson> but yeah, not having to do it is better :)
<ubottu> Ubuntu bug 918837 in khronos-opencl-headers (Ubuntu) "Please promote opencl-headers to universe" [Undecided,New]
<dobey> thanks cjwatson
<ScottK> YokoZar: I don't have sufficient access for that I don't think.
<YokoZar> I'm genuinely surprised to hear that there's something ScottK can't do :)
<ScottK> YokoZar: https://launchpad.net/~not-canonical
<YokoZar> ScottK: Joining that team now :)
<mterry> om26er_, sorry, was afk.  looking
<om26er_> ah no problem ;)
<cjwatson> YokoZar: done
<YokoZar> cjwatson: Thank you kindly!
<cjwatson> ScottK doesn't have access because I haven't written the relevant Launchpad API patch yet, rather than as a matter of policy ...
<ScottK> Right.  If I worked for Canonical I could do it without said patch.
<scott-work> cjwatson:  apologies for bothering you again, do you require anything else from the ubuntu studio team WRT the live dvd?
<scott-work> cjwatson: also, do we need to create the live or live-dvd seeds or is that something you need to do?
<scott-work> cjwatson:  and is there any further action we need to do independently?
<cjwatson> scott-work: nope, I don't think so, I plan to sort it out this week
 * cjwatson has been fixing upgrade bugs and fighting with python3-apt all today
<ScottK> barry: Is numpy on your python3 list?
<barry> ScottK: not right now
<ScottK> OK.
 * scott-work was on phone with wife
<scott-work> cjwatson: outstanding!  thank you ever so much for your help and assistance, and most importantly thank you for being patient and explaing things to me
<scott-work> i greatly desire to learn :)
<BenC> when things build-dep on binutils and bash-completions, I often wonder about the sanity of the maintainer
<om26er_> mterry, there there :)
<mterry> om26er_, ?
<om26er_> mterry, did you look at my branch?
<mterry> om26er_, yeah
<mterry> om26er_, getting my virtual machine up so i can test it  :)
<om26er_> mterry, awesome :)
<om26er_> the patch is from stable trunk fyi
<lamont> ScottK: done.
<lamont> ScottK: though if you want to do the sync-dance later, that'd be wonderful
<ScottK> Will do.
<smoser> SpamapS, slangasek any thoughts on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/898373
<ubottu> Ubuntu bug 898373 in cloud-init (Ubuntu) "fsck.ext3: Device or resource busy while trying to open /dev/xvda2" [High,Confirmed]
<SpamapS> smoser: can you explain what the cloud-config stanza is trying to accomplish?
<smoser> its not important
<smoser> reproduced outside of that.
<slangasek> smoser: what's this about 'mount -a'?  is this setup not using mountall?
<smoser> also red-herring.
<smoser> 'mount -a' only happens on first boot, when cloud-init sets up some mounts that are not in the image initially.
<smoser> then, it issues 'mount -a'
<slangasek> ah
<smoser> to get them read.
<smoser> but this occurred on subsequent boots. in this case, the 37th
<smoser> comments 3, 4 and 5 are probably most relevant.
<slangasek> I don't know of anything else in the system that should cause the device to be busy
<smoser> i guess 2 things that would have been useful here a.) i dont know if /mnt was mounted on the boot where there were errors.  and b.) the subsequent reboot did not complain and now (some reboots later) /mnt is mounted fine.
<smoser> what would 'mountall: Event failed' come from
<slangasek> well, mountall can be run with --verbose to get more information
<slangasek> not sure about the 'Event failed'; mountall itself doesn't seem to contain that error string
<stgraber> slangasek: this is typically caused by one of the mounted-* failling. Last I saw it, that was mounted-dev failling on LXC getting some permissioned denied when calling MAKEDEV (fixed by my mountall change)
<stgraber> (the string comes from upstart itself)
<mterry> @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:
<hallyn> lamont: hi, was wondering whether bug 913952 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655310) is on your radar?
<ubottu> Debian bug 655310 in util-linux "getty fails when consoles are on devpts" [Normal,Open]
<ubottu> Launchpad bug 913952 in util-linux (Ubuntu) "no console on precise containers" [Undecided,New] https://launchpad.net/bugs/913952
<lamont> hallyn: util-linux is on my radar for the plane this weekend
<hallyn> lamont: great, thanks.
<hallyn> actually, it appears now to be working.  what on earth...?
<kees> magic!
<hallyn> any workaround sufficiently advanced...
<kees> hehe
<stgraber> hallyn: yeah, noticed the same thing. I guess the change in console.conf was enough to make getty work, though I suspect you'll still get some complaints in /var/log/boot.log and /var/log/upstart/* (if starting using -- /sbin/init --log)
<hallyn> stgraber: that fix wasn't enough by itself before...  for me anyway...  huh.
<hallyn> well i recon i better mark those invalid
<hallyn> I'd wait, but i suppose i can always re-mark them valid if i need to
<hallyn> anyway i still have my slew of fixes on the other laptop from plane trip.  hopefully i can get those uploaded by end of tomorrow
<hallyn> jdstrand: stupid question.  shouldn't "make test" automatically get run by debian/rules build?  (re netcf)
<jdstrand> hallyn: well, I thought so, but the build log said it was disabled for some reason
<jdstrand> DEB_MAKE_CHECK_TARGET unset, not running checks
<jdstrand> hallyn: ^
<hallyn> ok, thanks.  will look more
<jdstrand> hallyn: maybe you just need to set that in debian/rules. I'm not totally up on all the new dh stuff
<jdstrand> hallyn: DEB_MAKE_CHECK_TARGET := check ?
 * jdstrand stops looking
<hallyn> yup, thx - will try
<hallyn> (got some kernels to crash first)
<stokachu> hi any patch pilots in the queue?
<seb128> stokachu, https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com
<stokachu> ah sweet
<seb128> stokachu, none active in the topic but I guess you can wait tomorrow ;-)
<stokachu> seb128, that sounds great :) thanks again i've got this bookmarked
<seb128> yw
<seb128> you can also watch the topic on this channel
<seb128> usually pilots put themself there during their shift
<stokachu> ok cool, ill keep checking back .. maybe someone will show up later tonight
<seb128> stokachu, if you subscribe ubuntu-sponsors your bug,merge request will show up on http://reports.qa.ubuntu.com/reports/sponsoring/
<seb128> stokachu, so you don't especially need to be pro active on IRC and ping
<seb128> it might just get sponsored by the normal reviews
<stokachu> seb128, ok, cool just didn't want to get smacked for doing it wrong :D
<seb128> don't worry, people are usually nice here ;-)
<stokachu> lol sounds good
<seb128> you might want to wait a few days if there is no hurry, usually no need of direct ping if things just landed in the queue
<stokachu> ok that sounds good, yea this is no rush ive got other bugs to attend to :)
<hallyn> mdeslaur: haven't look into it at all, but - is it expected that nonfree flash plugin have sound in precise now?
<mdeslaur> hallyn: you don't have sound?
<hallyn> nope
<mdeslaur> hallyn: file /usr/lib/flashplugin-installer/libflashplayer.so
<mdeslaur> is it amd64 or i386, and are you running amd64 or i386?
<hallyn> x86-64
<hallyn> (both)
<mdeslaur> hallyn: do you have libasound2 installed?
<mdeslaur> darn, gotta run, bbl
<hallyn> yup, 1.0.24.1-4ubuntu1
<hallyn> ok - thx
<mdeslaur> hrm, not quite sure what it could be for now...If I think of something, I'll let you know
<hallyn> thx, ttyl
<TheMuso> hallyn: Do you have libasound2:i386 installed?
<hallyn> TheMuso: I do
<TheMuso> hallyn: Do you have libasound2-plugins:i386 installed?
<hallyn> TheMuso: yes
<TheMuso> Hrm ok then, not sure what is going on.
<hallyn> TheMuso: thx anyway - i'll look deeper into whether i have some apparmor thing going on.  I wanted to amke sure whether it was workgin for others
<cjwatson> lamont: you know you can sync your packages yourself nowadays, right?
<lamont> cjwatson: yeah.  I'm aware that such technology exists.  OTOH, I'm happy to let NEW take its time, and let ScottK enable me to not actually figure out the infrequent-for-me process....
<hallyn> well I assume this has something to do with it:
<hallyn> Jan 19 17:05:37 sergelap pulseaudio[5690]: [autospawn] core-util.c: Failed to create random directory /tmp/pulse-guQWh6ykzqbl: Permission denied
<TheMuso> hallyn: Interesting indeed.
#ubuntu-devel 2012-01-20
<NCommander> Any archive admins floating around? I have a binary package which appears to have been universe'd by accident
<NCommander> Looks like the package was rejected at one point and after that the deb appears to end up in universe
<NCommander> python-dbus-common to be specific
<NCommander> ^- GRiD
<NCommander> er
<NCommander> GrueMaster:
<infinity> NCommander: Looking.
<GrueMaster> infinity: Not sure if this is relevant, but looking over the diffs for dbus-python, I see that python-dbus-common was added in 2ubuntu1, but it lists python-dbus as a conflicting package, whereas python-debus lists python-dbus-common as a requires.
<infinity> I see a replaces, no conflicts.
<infinity> Anyhow, promoting, it obviously shouldn't be in universe.
<infinity> But trying to sort out why component-mismatches wants python3-dbus in main too.
<pitti> Good morning
<pitti> doko_: I've been running with the PPA libc6 packages for a week (since you asked), and no problems so far; but yesterday the gdk-pixbuf package trigger started crashing, causing lightdm and desktop session to go totally black
<pitti> doko_: reproducer for me: /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders   /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so
<pitti> doko_: backtrace is not very helpful, though :( http://paste.ubuntu.com/810009/
<pitti> doko_: does that work for you?
<poolie> pitti, hi, thanks for the review and comments
<pitti> poolie: my pleasure :) thanks for the improvement
<poolie> pitti, i may well be confused, but i thought that if apport was enabled, you did not get regular core files
<poolie> even with ulimit -c unlimited
<pitti> you do
<pitti> apport writes them for you
<pitti> it's not supposed to break that, as core files are quite useful for developers
<pitti> poolie: I have half a dozen test cases to make sure that this works
<poolie> ok, good for you
<pitti> doesn't it for you?
<poolie> people were complaining to me that they didn't get core files
<pitti> $ ulimit -c unlimited; sh -c 'kill -SEGV $$'; file core
<pitti> Speicherzugriffsfehler (Speicherabzug geschrieben)
<pitti> core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'sh -c kill -SEGV $$'
<poolie> <3 deutsche :)
<pitti> ah, sorry
<poolie> no it's ok it's awesome
<poolie> i know what you mean
<pitti> it's the usual "segfault"
<poolie> it seems like apport will not overwrite an existing core file, but the default kernel behaviour will
<poolie> could that be true?
<pitti> no, the kernel doesn't
<pitti> it mimics kernel behavior pretty closely
<pitti> well, at least that was the case a few years ago when I wrote that stuff
<pitti> but overwriting existing files sounds a bit evil
<pitti> let me try
<poolie> istr overwriting was the default in the past
<pitti> oh, indeed it does
<poolie> that's why i used to customize it to core.$pid
<pitti> interesting, so apport should do the same then
<poolie> i think so
<poolie> shall i file a separate bug about that?
<poolie> wanting noise on stderr would then be invalid
<pitti> hah, bug 160999
<ubottu> Launchpad bug 160999 in apport (Ubuntu) "Apport doesn't conform to core(5)" [Low,Triaged] https://launchpad.net/bugs/160999
<poolie> it's already questionable
<pitti> poolie: yeah, let's invalidate the other one then, and point to ^
<pitti> I'll fix that one now, easy thing
<poolie> if you are not using nofollow that's a bit of a security risk
<poolie> istr in fact this was exploitable on some old kernels
<poolie> but that may have been fixed separately
<pitti> hm, good point; is there a race free method of replacing an existing file?
<pitti> it currently uses os.O_WRONLY|os.O_CREAT|os.O_EXCL which is race free and secure for new files
<poolie> well, like Gerald says there, i think you want O_NOFOLLOW  but not O_EXCL
<pitti> so I guess it'd need to write a core.RANDOMJUNK and rename it to "core"
<poolie> hm
<poolie> yeah, races if two write at once...
<poolie> ooh
<poolie> the other checks in http://lxr.linux.no/linux+v2.6.26.3/fs/exec.c#L1749 probably need to be copied too
<poolie> l1766
<pitti> ok, will queue this up for later then, not a 5-minute fix
<poolie> maybe you should write a random file and rename it
<poolie> the kernel doesn't seem to care (at least in 2.6) if it gets corrupted by concurrent crashes
<poolie> ok, that's fine with me to leave it as a known bug
<poolie> thanks for helping me understand it
<poolie> pitti, i wonder if we should mention that a core file is still written in apport-bug
<pitti> poolie: well, apport-bug is not really an interface for crashes..
<pitti> "man core" is meant to be that documentation
<pitti> even the previous /var/crash/ is a bit out of place there, but I merged it because you can use apport-bug to report existing .crash files
<poolie> i guess the text i added is not wrong
<poolie> right, possibly there should be an overall 'man apport'
<poolie> anyhow, i think that's enough for now
<poolie> thanks
<pitti> but apport itself does nothing with core files
<pitti> yeah, perhaps; https://wiki.ubuntu.com/Apport could be condensed into a manpage
<pitti> . o O { wow, these screenshots are old! }
<pitti> SpamapS: as the blocking bug is now resolved, can you guys go ahead with bug 711425? or don't want to target that at 10.04.4 any more?
<ubottu> Launchpad bug 711425 in sysvinit (Ubuntu Maverick) "portmap does not stop during shutdown, causing possible root fs corruption" [High,Triaged] https://launchpad.net/bugs/711425
<pitti> cjwatson: bug 563895 has a patch and is targetted for 10.04.4; is that a merge question of sponsoring, or does that need more investigatino?
<ubottu> Launchpad bug 563895 in grub2 (Ubuntu Lucid) "grub2 fails to boot or install when an LVM snapshot exists" [Undecided,Confirmed] https://launchpad.net/bugs/563895
<cjwatson> pitti: oh yes, that milestoning was a reminder to myself - I do want to review it, but I'll do that this morning
<pitti> cjwatson: thanks
<pitti> cjwatson: I cleaned https://bugs.launchpad.net/ubuntu/lucid/+bugs?field.milestone%3Alist=30510 a bit, I figure we'll go through the rest in today's release meeting
<pitti> I pinged some people about particular bugs; still want to ask tseliot about the fglrx one once he comes online
<tseliot> pitti: I'm here
<pitti> tseliot: oh, sorry; didn't see you some minutes ago, good morning!
<pitti> tseliot: so, wanted to ask whether bug 566437 is an easy backport, or whether it should be dropped from 10.04.4?
<tseliot> pitti: good morning to you ;)
<ubottu> Launchpad bug 566437 in fglrx-installer (Ubuntu Lucid) "package fglrx 2:8.723.1-0ubuntu2 failed to REMOVE: error exit status 2 - dpkg-divert: mismatch on package - while removing the package" [High,Confirmed] https://launchpad.net/bugs/566437
<pitti> cnd, bryce, RAOF: so, staging X.org doesn't kill any kittens here on thinkpad x201 (Intel Arrandale)
<tseliot> pitti: I haven't used dpkg-divert for ages now in my packages...
<pitti> tseliot: that's for lucid
<tseliot> pitti: I'll check again my packages for lucid then
<pitti> tseliot: if it's a corner case, we can drop it from the 10.04.4 list, too
<tseliot> pitti: ok, I'll let you know
<SpamapS> pitti: will do the SRU for 711425
<pitti> SpamapS: splendid, thanks
<jodh> SpamapS: thanks for the cookbook update!
<micahg> pitti: I'm finishing up the lucid rapid release testing now, are we still ok to push today, or did you want to wait for Monday?
<SpamapS> jodh: no problem. It was relevant to the zookeeper package. :)
<pitti> micahg: I'm a bit more hesitant on Fridays, but if you feel sure about it, ok
<micahg> pitti: personally, I prefer to be cautious, Monday would be fine for me
<pitti> micahg: ok, let's do that then
<micahg> in that case, I'll finish up something else tonight
<jamespage> @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: jamespage
<SpamapS> jamespage: did you see my zookeeper MP?
<jamespage> SpamapS, I did
<jamespage> not had time yet to review in full but looked OK to me
<SpamapS> jamespage: ok, just wanted to make sure it didn't slip into the ether
<jamespage> SpamapS, it won't!
<jamespage> (on my list alongside the FIX TESTING stuff)
<SpamapS> jamespage: I'm still having a hard time wrapping my head around the testing to make it reboot .. :-P
<janimo> is there a declarative way of stating per-arch install files? debian/binpkg.install is for all archs
<SpamapS> pitti: portmap + sysvinit uploaded to lucid-proposed.
 * SpamapS heads to bed
<pitti> SpamapS: great, I'll review the queue in a bit when they get diffy
<mvo> janimo: yes, hold on a sec I look for a example
<mvo> janimo: pkgname.install.$arch should work
<janimo> mvo, thanks a lot. hug :)
<mvo> yw!
<janimo> that looks like the approach with symbols files, I just never saw examples and googling was unsuccessful
<janimo> still a control file like approach would have been more powerful (ex: usr/lib/file/to/install [!armel !armhf]
<mvo> janimo: yeah, its a bit odd its not documented in the man page either, worth addding I guess
<janimo> as I am looking to exclude some files
<cjwatson> It is documented in debhelper(7) under "DEBHELPER CONFIG FILES"
<cjwatson> Since it applies to debhelper commands in general, not just dh_install(1)
<janimo> cjwatson, thanks, good to know.
<mvo> oh, thanks cjwatson - I just looked at dh_install, my mistake
<mvo> feedback on this http://paste.ubuntu.com/810533/ would be welcome, its about the need to change libept1 to something that changes when the libapt-pkgX.YY soname changes, my current idea about it is that libept1 embeds the libapt version in there too, otherwise may end up with a libept that is linked against a old apt and a app linked against libept and new libapt - or is there a better way for this?
<geser> mvo: could versioning the symbols in libapt fix it too? but you might want to ask someone who is an expert in libraries
<geser> (I hope I understood the idea behind symbol versioning correctly)
<mvo> geser: thanks! it would certainly help but currently there is a global symbol (pkgSystem::SysList) that is touch by both lib versions so linking them both in will segv spectaculary :/
<mvo> so that needs to be fixed first
<cjwatson> mvo: is this what's blocking bug 850264?
<ubottu> Launchpad bug 850264 in apt (Ubuntu Precise) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix committed] https://launchpad.net/bugs/850264
<cjwatson> mvo: that seems OK as a general approach but (a) I guess you really want to ask the libept developers :-) (b) I wonder if there are any binaries linked directly to both libept and libapt, in which case they would still have problems
<mvo> cjwatson: its the current blocker, donkult and I resolved some problems in dpkgpm.cc with the new debian dpkg multiarch interface, so apt itself should be good
<mvo> cjwatson: thanks! a) is indeed important, I asked upstream (but no reply yet) and b) there are binaries linked with both (synaptic, aptitude) so that is a real issue :/ for the builds we can solve it with build-versions, but of course its a lurking problem for local builds - any good tips ? :)
<cjwatson> mvo: do they actually need to link to both or is it overlinking?
<cjwatson> I mean do they use symbols from both directly?
<l3on> pitti: hi! :)
<pitti> hello l3on
<l3on> hi... I saw your comment... but rebuild1 (precise) is still less than ubuntu1
<l3on> i'm talking about bug 843734
<ubottu> Launchpad bug 843734 in ruby-sinatra (Ubuntu Oneiric) "ruby-sinatra : Depends: ruby-rack but it is not installable" [Undecided,Fix committed] https://launchpad.net/bugs/843734
<doko> pitti: yes, thanks. apparently the same thing that smoser did tell me at the ralley. I have now amd64 installed on my laptop
<l3on> pitti: what do you think about oneiric ubuntu0.1 / precise ubuntu1 ?
<pitti> doko: not sure whether it just uncovers a bug in librsvg or whether it's a genuine bug in dlopen
<micahg> l3on: a no change rebuild SRU should have been 1.2.6-1build0.1 IMHO
<pitti> l3on: I want to avoid ubuntu1 for precise, as this would stop autosyncs, and there are no ubuntu modifications
<pitti> l3on: that's why I proposed 1rebuild1
<pitti> for precise
<pitti> 1rebuild1 (precise) > 1ubuntu0.1 (oneiric-proposed)
<pitti> micahg: it's a dependency change in o-proposed
<micahg> ah
<pitti> arguably the dependency shoudl be fixed in oneiric-proposed, though
<pitti> by e. g. adding a Provides:
<pitti> but it'd introduce a delta either way, so it doesn't matter much
<micahg> pitti: 1.2.6-1+build1 would be better as it's higher in precise, but lower than an NMU
<pitti> fine for me
<l3on> so, I'm not following you :) can you explain precisely which versions we should have either in precise and oneiric ?
<micahg> 1.2.6-1rebuild1 wouldn't be higher as r<u
 * micahg learned the + trick from pitti a few weeks back :)
<l3on> dpkg --compare-versions 1build1 gt 1ubuntu1 || echo false
<micahg> l3on: it's not 1build1, it's 1+build1
<l3on> ah ok :DD
<l3on> ok... I'm going to prepare branches each for precise and oneiric
<l3on> thanks micahg and pitti for explanation
<micahg> l3on: pitti: actually, there's another package that build depends on ruby-rack in oneiric, ruby-actionpack-2.3, maybe provides is better?
<geser> hmm, will the autosync for p+1 ignore the "+build1" too and sync this package or will it need a manual sync?
<micahg> ISTR it ignoring everything except ubuntu in the string
<micahg> we could sync 1.4.0 from testing as well :)
<l3on> see you!
<cjwatson> geser: Yes, it will ignore it
<cjwatson> geser: lp:ubuntu-archive-tools auto-sync
<jamespage> doko: planning an update to openjdk-6 in precise any time soon?
<jamespage> just discussed a few issues that I am seeing on armhf with zero with xranby which are probably fixed in latest icedtea6-hg
<doko> jamespage, yes, I have to ...
<doko> hopefully this we
<doko> jamespage, but we still default to jamvm on arm*
<jamespage> doko: thats fine for the time being; I have to switch to zero as the testing I'm doing with hadoop breaks on JamVM
<jamespage> discussing that with xranby as well
<tjaalton> Riddell: kubuntu-restricted-addons seems to have a Recommends on libtunepimp5, which is obsolete (see bug 793929). ok if I remove it from there?
<ubottu> Launchpad bug 793929 in libmusicbrainz-2.1 (Ubuntu) "Deprecate libmusicbrainz-2.1, libtunepimp" [Medium,Triaged] https://launchpad.net/bugs/793929
<Riddell> tjaalton: yes, thanks
<tjaalton> Riddell: thanks, dropping
<cjwatson> mvo: hmm, trying 'do-release-upgrade -d -f DistUpgradeViewNonInteractive' in a lucid chroot - what's supposed to fetch libstdc++6 (>= 4.6) for the new libapt-pkg4.11?
<cjwatson> in fact, why is that coming from precise rather than from lucid-updates ...
<cjwatson> mvo: ah, never mind, my sources.list configuration was wrong before starting d-r-u
<tjaalton> Riddell: also, kdemultimedia can drop the build-dep on libtunepimp-dev (same bug)
<tjaalton> Riddell: then juk won't depend on libtunepimp5 anymore
<Riddell> tjaalton: thanks, I'll change that in bzr and upload next week
<tjaalton> Riddell: cool
<mvo> cjwatson: *puh* thanks, I was a bit worried for a moment
<pitti> apw: FYI, binNEWed linux -10
<smoser> doko, did you get an email from me on that ?
<smoser> i can't find anything that i sent you but i thought i did
<jamespage> @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:
<doko> smoser, no, don't see anything
<smoser> coming now.
<doko> asked pitti to file a report as well, so maybe you can comment on this too
<smoser> sent.
<smoser> i sent you mail just now
<smoser> sorry i forgot to on friday
<brendand> is there any plan to include python-qt4 in main for precise?
<pitti> brendand: it's been in main forever
<brendand> pitti - i guess i'm using main wrongly. on the cd?
<pitti> brendand: ah, "main" != "cd"
<pitti> brendand: no, python-qt4 is huge, doesn't fit on the ubuntu CDs
<brendand> pitti - ok, i stand corrected! from henceforth i will never use 'main' to mean on the cd :)
<pitti> brendand: heh, no worries; we have too much terminology
<pitti> brendand: roughly, main is the union of everything that's on ubuntu and kubuntu CDs and DVDs, plus all their build dependencies and their dependencies
<pitti> plus a few extra bits which we don't want to ship anywhere, but officially support
<apw> pitti, thanks
<brendand> pitti - i 'only' get 51.4 MB of extra dependencies when installing it (i guess that's alot relatively speaking)
<brendand> especially as the image is already full ;)
<pitti> oh yes
<pitti> we are currently 11 MB oversized
<pitti> we usually start arguing if something is bigger than .5 MB
<brendand> in this case it's 100 times bigger - so i'll leave it
<brendand> we doing some work on checkbox that is introducing a python-qt4 dependency. i don't know if you talked with roadmr or cr3 about resolving that?
<Riddell> brendand: ask the ubuntu one people, they might be wanting python-qt in ubuntu desktop
<brendand> pitti - have the been asking ? ^
<brendand> s/the/they/
<pitti> they asked, yes -- same answer, though
<pitti> not easy to change the physical size of a CD :)
<brendand> pitti - use your magic powers :)
<pitti> brendand: I'd rather use it to shrink pyqt4 down to 0.5 MB :)
<Riddell> there is some shrinking that could be done to pyqt, but I suspect not enough
<pitti> now, where did I leave my magic wand and the toad blood..
<dobey> pitti, brendand, Riddell: we are making some space, but if CD is 11MB over, I'm not sure if we're going to get enough with what we're doing, even with splitting up pyqt packaging :(
<pitti> we have a libo in the pipeline which gets it down to 706 MB
<pitti> we need to fix gwibber and ubuntu-sso to drop the old webkit 1.0 stuff
<pitti> that will reclaim another 7
<pitti> then we are back in the game
<chrisccoulson> fixing bug 894166 will probably get us another 2.5
<ubottu> Launchpad bug 894166 in firefox (Ubuntu Precise) "Make hyphenation work with system hyphenation patterns" [High,Triaged] https://launchpad.net/bugs/894166
<dobey> pitti: oh, ok. then i guess we might be ok
<brendand> not sure i understand exactly what's happening though. is the intention to include python-qt4?
<dobey> brendand: yes
<pitti> brendand: most likely not for precise, unless someone finds the time to split it, and the needed parts are less than, say, 2 MB
<pitti> right now it's about 13
<dobey> brendand: well, i don't know which pieces of it you need exactly
<dobey> pitti: well, the needed bits are a little bigger than 2MB
<brendand> dobey - probably only the basics. might we get away with depending on other packages apart from while python-qt4?
<brendand> dobey - we need to be able to use most GUI components
<dobey> pitti: i think i calculated something like dropping 7MB, and adding 6MB back, with all we want to do for u1
<brendand> dobey - i imagine requirements are similar to yours
<dobey> brendand: i mean, python-qt4 has several modules itself, which are shipped as separate libraries for the C++ version
<dobey> brendand: then you should be ok, i think.
<Riddell> brendand: what are you asking for?
<brendand> Riddell - In terms of what? Python modules - or something else?
<Riddell> brendand: what are you planning to use pyqt for?
<brendand> Riddell - oh, to implement a new UI for Checkbox that will run on Ubuntu and Kubuntu
<Riddell> nice
<Riddell> and every other platform of course, go Qt :)
<brendand> Riddell - python-qt4 is already safely on the kubuntu cd
<Riddell> brendand: I knew, we maintain it :)
<pitti> oh dear..
<pitti> https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.0~beta2-2ubuntu3/+build/3091291
<pitti> Started 2012-01-13
<pitti> (that's armel)
<brendand> 1 week. nice
<pitti> I can haz libreoffice blacklist on the old babbage buildds? :)
<pitti> tseliot: thanks muchly!
<pitti> cjwatson: nice, https://bugs.launchpad.net/ubuntu/lucid/+bugs?field.milestone%3Alist=30510 looks a lot better now :)
<pitti> cjwatson: I guess if bug 810068 doesn't make it, it's not a big loss?
<ubottu> Launchpad bug 810068 in partman-iscsi (Ubuntu Natty) "kickstart iscsi option broken" [High,Triaged] https://launchpad.net/bugs/810068
<pitti> (seems you never got any real testing feedback)
<tseliot> pitti: thanks for bringing that bug to my attention ;)
<psusi> is initramfs-tools an ubuntu homegrown package, or is there an upstream somewhere?
<cjwatson> pitti: I was actually just preparing branches for that anyway
<cjwatson> psusi: upstream is Debian, although IIRC it originated in Ubuntu
<psusi> cjwatson: ohh... so not all distributions are using it?  I thoguht the old initrd format was depreciated?
<psusi> the kernel just supports both and doesn't plan on changing that?
<cjwatson> using an initramfs doesn't imply using initramfs-tools
<cjwatson> it's just a gzipped cpio archive; the format is not difficult to generate, it's what you put in it that tends to be rather distribution-specific
<psusi> what other tools are there?  using Linux doesn't imply that you're going to use util-linux's fdisk, but that's kind of the reference implementation... is there not a reference implementation for how to generate an initramfs?
<cjwatson> there used to be yaird, and Fedora uses something entirely separate whose name I forget
<james_w> dracut
<cjwatson> there is no single reference implementation, no
<cjwatson> james_w: thanks, that's the one
<psusi> ahh
<james_w> they are intending that to be /the/ version
<cjwatson> yeah, but they can intend all they like ... :-)
<james_w> indeed :-)
<cjwatson> we looked at it in the past and IIRC it just wasn't worth the ridiculous amount of effort to convert
<cjwatson> Debian maintains initramfs-tools pretty well
<psusi> hrm... launchpad lists the upstream website as www.ubuntulinux.org and the wiki as wiki.ubuntu.com/EarlyUserspace... I take it that is quite out of date?
<cjwatson> yup
<cjwatson> by about five years
<psusi> any idea what the correct links should be?  maybe poke an lp admin to fix it?
<pitti> Daviey: will you still send a server release team meeting update?
<Daviey> pitti: arosales is ON THE CASE. :)
<arosales> pitti: Yes, apologies for the delay in sending it.  Working on getting that out now.  Traveling at the moment and fell a little behind on some tasks
<infinity> psusi: I suspect http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git is as close as you'll get to an upstream website for initramfs-tools.
<infinity> psusi: When we wrote it in Ubuntu, it wasn't done by people who particularly loved writing documentation (*shifty look*), and when maks took it over in Debian, I think he was even less interested in websites and logos.
<pitti> arosales: thanks!
<Daviey> infinity: consider yourself poked, violently.
<Daviey> bug 759545
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
<Daviey> infinity: ^^
<ev> pitti: for the "Stop cleaning up ddebs after 7 days" task in support of the crash database, is it just a lack of disk space preventing us tweaking this, and thus a conversation I should have with James?
<pitti> ev: yes, pretty much; we are running into ENOSPC all the time, and already had to kill many arches/releases from ddebs.u.c.
<ev> okay
<infinity> Daviey: Ow.  HR violation being filed.
<ev> I'll go beg then
<pitti> ev: we recently got some more space on that machine, I already sent an emergency RT a few weeks ago
<pitti> ev: I can certainly bump it a bit, though; how many days do you need?
<Daviey> infinity: i was simply following your request :)
<ev> well, I'd like to see what the upper limit on their side is, as, and correct me if I'm wrong, this is what's causing us to have to mark slightly out of date crashes as invalid
<Daviey> infinity: anyway, you'd need to speak to Machine Resources, HR would be confused why you are speakng to them :)
<pitti> ev: well, not only that; apport-retrace currently uses python-apt to retrieve the debs, i. e. it needs package indexes
<pitti> and our Packages.gz only has the most recent version
<pitti> ev: so it'll require some more work in ddeb-retriever to figure out in which Packages.gz an old version should go into, and then some version selection in apport
<pitti> so far there was not much pressure to do that, since we couldn't even fit all our current ddebs
<ev> pitti: okay, thanks for the clarification
<pitti> ev: and we don't only need the ddebs, we also need the regular .debs in their old version
<infinity> pitti: I take it we're still stalled on ddebs in soyuz?  Cause it has all the logic required to do these things, I suspect (inculding keeping old versions in the index for a while).
<pitti> ev: at that point I guess it's easier to stop using Packages.gz and just directly look up the .deb/.ddeb on the mirror, assuming that they use a standard directory layout
<pitti> infinity: I haven't heard any update about that in a while, so I take it it's "yes, still stalled"
<ev> ah, okay
<infinity> pitti: Maybe we should revisit it sometime.  See what still needs to be done to make it work, identify some bite-sized chunks, and either work on it or escalate.
<infinity> pitti: The "temporary" ddeb infrastructure is a bit past its prime. :P
<pitti> infinity: nice understatement :)
<pitti> nothing ever lasts as long as a stopgap solution
<psusi> hrm... something seems wonky with lp's changelog parser... https://launchpad.net/ubuntu/+source/lm-sensors shows a double entry that folds the debian change entry into mine and makes it look like I did it, but that's not what the changelog looks like in bzr
<psusi> any idea what went wrong there?  that's just goofy...
<infinity> psusi: You mean https://launchpad.net/ubuntu/+source/lm-sensors/1:3.3.1-1ubuntu1 ?
<Laney> that is from the .changes file: http://launchpadlibrarian.net/90508993/lm-sensors_3.3.1-1ubuntu1_source.changes
<infinity> psusi: It just attributes the upload to you, that's all.  It shouldn't be viewed as an authoritative changelog.
<cjwatson> psusi: pretty sure that's a known bug
<psusi> infinity: it attributed both my entry and the debian dev's entry to me
<psusi> so dpkg-genchanges goofed?
<Laney> no. It's just a presentational thing that LP made it look like a changelog.
<Laney> Those are the changes relative to the last version in Ubuntu, so it's correct in that sense
<psusi> listing them both in .changes is correct... removing the debian dev's signature and applying mine to both entries is not
<psusi> well, may be correct.. I'm still not sure about that
<psusi> but it certainly shouldn't be moving my sigangure to cover the debian dev's entry
<cjwatson> like I say it's a known bug.
<psusi> kk...
<psusi> well I guess I'm happy I didn't screw something up...
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/55795
<ubottu> Ubuntu bug 55795 in Launchpad itself "+changelog includes misleading information related to package versions and authors" [Low,Triaged]
<infinity> +changelog being an amalgamation of .changes entries is a bug, to be sure.  But .changes doing what it does is more of a feature than a bug.  It's upload attribution, not changelog attribution.
<ScottK> The fundamental problem is that the page called +changelog isn't a changelog.
<ScottK> Either the content should match the label or the label should be changed.
<pitti> jibel: seems http://reports.qa.ubuntu.com/reports/boot-speed/acer-veriton-01/2012-01-20_03-39-32/bootchart.png is back to normal, though?
<pitti> jibel: not sure where that huge delay came from
<psusi> isn't the bug in dpkg-genchanges?  since it's incorrect right there in the changes file?  and that is generated when the sponsor runs debuild right?
<infinity> psusi: .changes documents the upload, not the changes.  It's perhaps poorly-named. :P
<jibel> pitti, could it be a network problem ? it seems the system is waiting on something.
<Laney> they are the changes in that upload though (relative to the last version in Ubuntu)
<psusi> Laney: sure... listing them both is fine.. the issue I have is that it mangled the signature to attribute both changes to me, instead of showing two changes, with two signatures
<ScottK> Laney: For merges not always (it's not rare for people to for -v)
<pitti> slangasek: actually, I do remember that the buildd descriptions said "panda", but I don't see them now on any of the builders on https://launchpad.net/builders
<slangasek> oh, hmm
<Laney> ScottK: well, yes, since it's manual the usage isn't as consistent as it could be
<slangasek> pitti: ah, if you drill down into the pages, they're listed as e.g., "nasl (arm panda)"
<slangasek> kitalpha is (arm), so not panda
<pitti> ah, seems we only have a few then, thanks
<pitti> slangasek: oh, that's armhf
<pitti> we need armel
<slangasek> pitti, ScottK: note that qtwebkit-source *also* FTBFS on armhf, and *all* the armhf buildds are pandas
<ScottK> slangasek: Different issue.
<slangasek> ah?
 * slangasek digs
<infinity> Which issue are we talking about here?
<ScottK> We need to update the symbols files.
<ScottK> The armel issue is memory exhausted during linking.
<ogra_> infinity, the mmap issue of the arm kernels on the buildds
<slangasek> ScottK: it did on armhf too
<slangasek> "/usr/bin/ld: final link failed: Memory exhausted"
<infinity> ScottK: That is a kernel bug, not a "we need a panda" issue.
<slangasek> infinity: no, the pandas have the fixed kernel deployed
<infinity> ScottK: The armel buildds are being updated for it as well.
<ScottK> infinity: Allededly the pandas have said kernel
<infinity> slangasek: Well, yes.  There's that.  But it's being deployed everywhere.
<slangasek> if it's still OOMing, then it needs > 3GB, not just > 2GB
<slangasek> infinity: point is, "wait for kernel update and retry" is the wrong strategy
<infinity> (And since the package needs a new upload ANYWAY, I'm not sure it's worth caring right now)
<ScottK> Sure enough.  OOM on armhf too.
<ScottK> I swear I looked at that yesterday and it didn't.
<infinity> Kernel version: 2.6.38-1209-omap4 #19-Ubuntu SMP PREEMPT Tue Dec 20 15:41:36 UTC 2011 armv7l <-- Not the fixed kernel.
<infinity> slangasek: Whoever said all the pandas were updated may have fibbed. :P
<ScottK> I must have looked at powerpc twice by accident.
<slangasek> hmm
<slangasek> infinity: well then - all the more reason "wait for kernel update" is the wrong strategy, because I was assured the pandas had already been upgraded which means it's probably not on the todo list ;)
 * slangasek digs up the RT
<infinity> Well, that was also 4 days ago.  Let me look at a current build on nasl.
<infinity> Or nihal.  Or whatever that was.
<infinity> Yeah, still out of date.
<infinity> lamont: Ping, re: mmap kernel updates.
<slangasek> doko: do you recall the RT ticket # for the ARM kernel upgrade?
<slangasek> from what I can tell it's no longer open
<infinity> slangasek: So, looking at recent build logs, it looks like the only one of the distro builders that's been updated is meissa.
<slangasek> score
<doko> slangasek, there was none, buildds did get it with -updates
<infinity> slangasek: I know some of the other pandas around the DC (pseudo-virt PPAs, etc) were updated, but only one of seven of the distro buildds, apparently. :P
<doko> but afaik there still the omap3 kernel missing
<slangasek> doko: but the buildds needed a coordinated reboot, I thought there was an RT filed for that?
<doko> #50176]
<slangasek> doko: thanks
<infinity> That ticket starts out by assuming all the machines were actually updated.
<infinity> I suspect that's the failure.
<slangasek> heh
<infinity> slangasek: And, to be fair, there's no coordinated reboot required.
<doko> so the pandas should be updated
<ogra_> just a random one ?
<doko> infinity, that's what I was told
<ogra_> :P
<infinity> slangasek: Coordinated power-cycling is required when one wants to dump the pandafarm, but if you just type "reboot", they do as you'd expect individually.
<slangasek> infinity: well, I know it was made out to be an involved process when I pinged <shrug>
<ScottK> infinity: So would it be worth retrying qtwebkit-source on meissa to see if it makes it there?
<slangasek> it would
<infinity> ScottK: Sure, but it'll still fail due to symbols files being goofy, won't it? :P
<infinity> ScottK: Or is that PPC-only that's broken?
<infinity> ScottK: (Anyhow, I can make that happen)
<ScottK> infinity: It probably will, but then I'll have the build log to fix it.
<infinity> ScottK: Fair point.
<ScottK> infinity: Please try it.
<pitti> ScottK: still need me to kick a retry? the backscroll looks like that won't help?
<infinity> ScottK: Done.
<ScottK> pitti: I think infinity just did it.
<ScottK> Err he did
<pitti> for armhf, yes
<pitti> I mean for armel
<ScottK> Right.  No point for armel yet.
<infinity> ScottK: Should I try to wrangle something for armel, or will the symbols breakage be the same for both?
<pitti> that's what I understood; ok
 * infinity tries to remember the last qt/kde symbols file he fixed for armhf...
<pitti> unmangled symbols won't work?
<ScottK> I'm checking to see if there are differences currently.
<ScottK> infinity: It may just be powerpc.  Let's see how armhf comes out before you spend time on something complicated.
 * BenC perks up on powerpc
<ScottK> BenC: Just a per arch symbils difference.  Nothing exciting.
 * BenC goes back to sleep
<debfx> we could just pass -c0 to dpkg-gensymbols again like we do in qt4-x11 since it's unlikely that upstream will break abi and 95% of the symbols aren't really part of the public abi anyway
<ScottK> Does the Qt4 ABI guarantee apply to Qt Webkit?
<debfx> yes, qtwebkit is still part of Qt4
<ScottK> OK.  Might make sense then.
<doko> seb128, fixed python2.7 uploaded, a backport was incomplete
<seb128> doko, thanks!
<jtaylor> doko: can you fix the argparse issue too please?
<jtaylor> bug 916188
<ubottu> Launchpad bug 916188 in python-defaults (Ubuntu) "argparse provide breaks builds" [High,New] https://launchpad.net/bugs/916188
<seb128> do the ppa builders always default to use -j2?
<seb128> is there any way to turn that off?
<seb128> webkit seems to not like it and fails to build
<micahg> seb128: ~line 30 in debian/rules is where it's set
<seb128> micahg, hum, it's not set on my local build though, weird
<micahg> default is 1 :)
<seb128> micahg, but I guess I can just drop those lines, thanks
<micahg> seb128: well, they can be dropped until upstream gets parallelizable
<hallyn> jdstrand: so, 'make check' for netcf succeeds in sbuild.  But it fails on the buildds. (https://launchpadlibrarian.net/90473282/buildlog_ubuntu-precise-amd64.netcf_0.1.9-2ubuntu2_FAILEDTOBUILD.txt.gz)
<hallyn> don't know enough about the buildds to be sure what's going on there.
<jdstrand> hallyn: tests/test-suite.log would be helpful
<jdstrand> hallyn: there isn't obvious in the build log
<hallyn> yeah - i'm looking through strace of successful test in sbuild for a clue
<hallyn> nothing in test-suite.log actually
<jdstrand> interesting that it passed on armel
<hallyn> and test-debian.log only shows 6 successful tests :)
<hallyn> yeah
<jdstrand> PASS: test-debian
<jdstrand> so the buildds should all be native builders for the archive
<jdstrand> so I'm not sure why they would fail if it were a buildd problem
<jdstrand> might need to do a ppa build, perhaps cat'ing tests/test-suite.log on failure
<micahg> hallyn: do any of the tests require network access?
<jdstrand> well, the armel should fail then
<jdstrand> and when I ran the tests before I didn't see any network traffic
<hallyn> I've run them locally in an empty netns, successfully
<hallyn> no execs of ifconfig or ip
<jdstrand> hallyn: that would have been my next suggestion
<jdstrand> interesting :)
<hallyn> some missing dep, i would have to think...
<infinity> hallyn: If it works locally (in a clean chroot) and not on the buildds, it's almost certainly network-related.
<infinity> hallyn: Note that the buildds can't even resolve DNS outside their own network.  It's stricter than most people think.
<jdstrand> yeah, but the empty netns points to something else-- and that arm succeeded
<infinity> Oh, I didn't notice that arm* succeeded.
<jdstrand> I run it with tcpdump and didn't see any traffic at all
<infinity> In which case, something's even more special. ;)
 * infinity grabs the source.
<jdstrand> s/run/ran/
<jtaylor> doko: why stop provide in 2.7? isn't that the place it should be provided?
<jtaylor> python-defaults is to me the package that should not provide it
<jtaylor> (though it does not really matter as we only have one py version anyway)
<infinity> Seems weird for "python" to do anything other than depend on python${version}
<superm1> infinity: the mirror that buildds pull packages from, would it be feasible for pulling a source package from too, or are there only binary packages there?
<infinity> superm1: It's ftpmaster.
<jtaylor> doko: why is the argparse provide in debian o_O
<infinity> superm1: But I'm more curious about the origin of this question...
<jtaylor> debian still has 2.6
<infinity> superm1: As in, what do you want to provide source packages to?
<superm1> infinity: well i wanted to add a test to a package that requires pulling the source of grub2 and compiling it with a patch applied.  the binary package wouldn't ship with it
<superm1> but to know if in the field that would break ahead of time with grub that's in the archive
<infinity> superm1: I guess no one can stop you from doing that, since it will, technically, work.
<infinity> superm1: But make the build smart enough to use the mirror in sources.list, don't hardcode it.
<superm1> okay
<superm1> do you have oppositions to the concept of doing a test like that though I take it?
<infinity> superm1: (Mirroring, for example, how debian-installer gets extra stuff during build)
<superm1> right
<infinity> superm1: I have a general icky feeling about testsuites that assume network access.
<infinity> superm1: In the case of "pulling from a Debian repository", you do know it'll work on buildds, though.
<infinity> superm1: It's still icky. :P
<superm1> well maybe make the test not fail if it can't apt-get source then, but only fail if the compile fails
<infinity> superm1: It won't be able to apt-get source at all.
<infinity> superm1: But in the spirit of what you meant, yeah.  I guess it wouldn't be awful.
<superm1> yeah i haven't looked at semantics of how it's done by debian-installer during build yet, so perhaps not apt-get source
<superm1> okay, thanks!
<infinity> superm1: Well, apt-get source won't work because there are no deb-src lines in sources.list.
<infinity> superm1: You could build a sources.list of your own and apt-get -o APT::conf::whatever=mysources
<superm1> but you can specify alternate sources.list files right
<infinity> superm1: But that seems rather like effort.
<superm1> that that's what i was thinking
<infinity> superm1: The end goal of this being a package that allows users to make non-GPL changes to GRUB, I'm guessing?
<infinity> Or, makes said changes for them...
<superm1> infinity: well actually the code is GPL, but it needs to be compiled under mingw
<superm1> and want to make sure that it matches the grub in the archive for any CD builds that would have it built in
<infinity> I think I just burst a blood vessel in my brain.
<superm1> haha
<superm1> long story short, need a grub-setup.exe that can load a core.img boot from grub-mkimage
<infinity> Check.
<infinity> But I'm still mildly curious why you can't ship the resulting binary?
<infinity> I mean, we can, if you're talking about putting it on CDs...
<infinity> So, why not just ship it as an arch_all package?
<superm1> hmm.
<superm1> oh because previously I wasn't aware that it would be possible to fetch a source package from ftpmaster at all
<superm1> so i guess that is a good alternative now
<infinity> Well, that would be the wrong way to go if you wanted to actually ship the binary.
<superm1> but the problem would be what if grub in the archive got updated and this package wasn't rebuilt
<infinity> The right way to go would be either building it from grub2 itself (no-go, since mingw is in universe), or making grub2 produce a grub2-source package that you can build-dep on.
<infinity> While debian-installer does do crazy things outside the realm of build-deps, I'm not sure we want to use it as a precedent either.
<superm1> that would still have the same rebuild problem though if grub in the archive changed
<infinity> Well, any solution other than "build it from grub" has that problem.
<infinity> At some point, someone needs to manually rebuild it, whether locally or by an upload.
<superm1> the current way that it's done is during postinst with an apt-get source, which avoids that problem
<infinity> That's still a local rebuild.
<infinity> And needs to be re-done if grub revs.
<superm1> well not for CD builds at least
<infinity> It also gives you no guarantees that the binary is the same everywhere.
<infinity> Err, oh.  And if you have CD builds now requiring a compiler, that's a bit of extra ick.
<SpamapS> Can things in lucid-proposed still make it in to 10.04.4 ?
<SpamapS> I see that the freeze was tomorrow
<SpamapS> err
<SpamapS> yesterday
<superm1> infinity: yeah it's a bit of a mess, there's some extra hooks to clean up that compiler after the postinst is done right now
<infinity> SpamapS: If they pass validation, that's a big "maybe".
<SpamapS> really want to see bug 711425 land
<ubottu> Launchpad bug 711425 in sysvinit (Ubuntu Lucid) "portmap does not stop during shutdown, causing possible root fs corruption" [High,Fix committed] https://launchpad.net/bugs/711425
<infinity> SpamapS: But as #ubuntu-release.
<infinity> superm1: Yeah, that all sounds very much like a bad way to do it, IMO.
<SpamapS> we'd have to waive the 7 day rule too
<SpamapS> seems like its too late. :(
<infinity> SpamapS: Exceptions can be made.  But generally only for something that affects media.
<infinity> SpamapS: And this doesn't look to.  Upgrading post-install still fixes the bug.
<infinity> SpamapS: (I guess doing a netinst to an nfsroot would be problematic here, that's about all I can see to make it an installer blocker, though...)
<SpamapS> infinity: indeed, postinstall it is then.
<SpamapS> infinity: no, its not an installer blocker, should be fine
<infinity> hallyn: It could just be the age of the kernel?  ARM buildds are newer kernels.
<infinity> hallyn: The machine where your build failed was running linux-image-2.6.24-30-server from hardy.
<hallyn> infinity: it's not inconceivable...
<infinity> hallyn: Spin up a hardy VM? :)
<cjwatson> hallyn: are you actually testing in sbuild, or only in a chroot?  occasionally that makes a difference.
<infinity> hallyn: (FWIW, I couldn't make it fail in a clean precise chroot, it's definitely not a dependency issue)
<hallyn> alrighty, will do, thx
<hallyn> cjwatson: sbuild
<cjwatson> OK
<infinity> cjwatson: The failure on x86 and success on arm* definitely makes me suspect kernel versions.
<cjwatson> I debugged a problem for doko the other day that turned out to happen in sbuild but not in a build started interactively in a chroot, because sbuild redirects stdin from /dev/null
<infinity> I'd suspect weird userspace/toolchain bugs, but those usually affect things in the opposite direction. :P
<cjwatson> I agree kernel versions are a good candidate, I just see too many people blaming "the buildds" without trying in a local sbuild. :-)
<infinity> cjwatson: Well, in this case, it works in sbuild on other arches.
<infinity> (But yeah, still a fair point to make)
<zyga> [    2.220049] ata1: SATA link down (SStatus 0 SControl 300)
<infinity> Some day, I need to write a quick-n-dirty lp-buildd reproducer.
<zyga> sorry, loose mouse
<infinity> ie: grabs the chroot tarball, runs the build in an lp-buildd instance.
<cjwatson> (PS lesson learned from that debugging session: you can't use script(1) in a package build)
<infinity> I'm sure you could if you felt the urge to play FD tag.
<infinity> But given that script exists to make such things unnecessary, I suppose that sort of defeats the purpose.
<cjwatson> I wrote a 51-line Python script instead.
<cjwatson> (About half of which was the licence statement.)
<jdstrand> hallyn: so, the kernel version differences makes sense to me too. if the fix isn't straightforward, it is still worthwhile to either have 'make check' not fail the build or better, to have the one failing test not fail the build. obviously ideally, we fix the issue and have make check fail the build
<hallyn> jdstrand: yeah, this should at least give me an idea of where to look for the fault.
<hallyn> infinity: thx
<infinity> jdstrand: Having make check fail the build is still the right answer, IMO, disabling the one offending test would be the way to go.
<infinity> jdstrand: (And when the buildds move to precise kernels, said test can be turned back on)
<jdstrand> there is that-- but the test is worthwhile on arm
<infinity> All assuming this is the issue.
<jdstrand> *shrug*
<jdstrand> let's try to get the issue fixed first :)
<infinity> jdstrand: Well, one could conditionally run that specific test based on kernel version. ;)
<jdstrand> true
<infinity> minver=2.6.38 or something.
<jdstrand> that is an even better option if the issue can't be fixed
<infinity> Well, it may be unfixable because it may be trying to do things old kernels just plain can't.
<jdstrand> that way local sbuilds would fail appropriately
<infinity> I wouldn't be shocked.
<cjwatson> There exist tests that only fail on newer kernels, too :-/
<cjwatson> (Not this one, I know ...)
<cjwatson> libdevel-bt-perl comes to mind.  I never did get that fixed.
<jdstrand> I'm assuming that was more difficult than the 2.6 to 3.0 transition
<superm1> cjwatson: how would you feel about a grub2-src binary package to come up with a cleaner solution to what infinity and I were talking about above?
<cjwatson> Not particularly happy
<infinity> The two cleanest solutions are definitely either grub2-src or d-i-style pulling-from-the-archive-during build.  Neither lacks ickiness.
<cjwatson> Mainly because I don't like what you're doing in the first place and don't want to encourage it - grub2 objects should be built out of grub2
<cjwatson> And I feel I ship enough weird cruft from the grub2 source package as it is :-)
<infinity> cjwatson: Well, the least icky solution (from a packaging perspective) is pulling mingw into main, but I don't know if we want to open that can of worms.
<cjwatson> That's what I was about to suggest, actually
<cjwatson> Though maybe not for precise?
<infinity> I'm not against the idea, per se.  I just don't know enough about mingw's supportability, etc.
<cjwatson> Ditto
<superm1> okay, so next release cycle will come up with a cleaner way to be doing this then
<cjwatson> Wubi does a few nasty things as well, but at least it only uses shipped tools and doesn't compile anything
<cjwatson> And we do have an arrangement to upgrade the bit of it that goes on installed user systems when grub is upgraded
<cjwatson> With grub2-src you'd also have to be very careful about GPL compliance, and LP doesn't yet support Built-Using so won't help you
<doko> Processing triggers for libgdk-pixbuf2.0-0 ...
<doko> Segmentation fault
<doko> seb128, ^^^ but no error
<maxb> Is there any way to capture stdout from a process run as an upstart job, for debugging?
<seb128> doko, seems the same issue pitti was having yesterday, he said that's due to your ppa's glibc
<doko> ahh
<doko> yes, that's a chroot with it installed
<seb128> doko, not sure if he debug it further
<seb128> he nailed it down due to the ppa version
<seb128> sorry but I don't have details out of this
<doko> that's enough
<stgraber> maxb: yes, upstart 1.4 lets you do that (though it's currently turned off because of a bug that makes upstart crash with some specific jobs)
<stgraber> maxb: you can boot with "--log" added to your kernel command line to turn on the feature until a new upstart is uploaded with a fix
<stgraber> maxb: then you'll get /var/log/upstart/*.log with the output of the jobs
<maxb> stgraber: ok.... well I guess I'll cheat horribly for now..... "console output", and replace /dev/console with a plain file :-)
<stgraber> maxb: (that's assuming you're running on Precise)
<cjwatson> or you can just redirect output to a file in /run for no
<cjwatson> w
<slangasek> pitti: I've learned in a rather roundabout way of urfkill, which seems to be the last component needed to let us get rid of acpi-support; do you happen to know anything about this and if we can reasonably include it in the default install for precise?
<slangasek> seems a bit raw though; it has a config file that lets you twiddle things no one should ever want to manually twiddle, which implies it doesn't actually autodetect everything it should
<slangasek> oh, but there are vendor profiles that override
<cjwatson> astraljava: scott-work laid out for me what ought to be on the Ubuntu Studio live DVD, so I've just gone ahead and implemented that in the seeds - hope you don't mind, I belatedly remembered that you'd taken a work item for that
<cjwatson> astraljava: I'm stealing the "create seeds" work item and marking it done - you still have a "review edubuntu 'dvd-live' seed" work item, but maybe you just want to drop that at this point?
<cjwatson> just waiting for tasksel and livecd-rootfs to build and publish, then I can probably try a build
<cjwatson> assuming I haven't forgotten anything else
<infinity> cjwatson: You've forgotten that it's 9pm on a Friday, and you should walk away from the keyboard? ;)
<cjwatson> infinity: Silence.
<scott-work> cjwatson: within two days i shall review the work items mainly checking for items that should be marked 'postponed' or 'blocked', but i will resolve any outstanding items such as "review edubuntu 'dvd-live' seed"
<cjwatson> scott-work: OK
<cjwatson> I had to copy the ship seed to dvd - couldn't easily reuse it unfortunately due to how germinate works.  I suppose it could have been a symlink but I suspect it may want to diverge in the future anyway.
<astraljava> cjwatson: Wow! Thanks so much! I haven't had much time for the past couple of days for *buntu stuff, so muchly appreciated!
<astraljava> cjwatson: But I suppose we still need to include the ubiquity patch for tasks selection?
<cjwatson> astraljava: Yes (plugin actually, not patch) - I'm not going to do anything with that
<jelmer> /win 8
<astraljava> cjwatson: Ok, thanks for confirming that. I'll get on that next, then.
<barry> cjwatson: still around?
<cjwatson> barry: was just about to leave before infinity mocks me further - is it quick?
<barry> :)  yes.  launchpadlib for python3.  are you working on it, or planning to?  seems like that's the next one on the critical path for me.
<barry> cjwatson: ^^ if not, i'll tackle it
<cjwatson> barry: still trying to finish up python3-apt fixes + python3-debian
<cjwatson> barry: I had been planning to, but if you're blocked, feel free to steal it - there are actually a few packages to work on theree
<barry> cjwatson: cool.  i'll file a bug against launchpadlib, add it to the blueprint and take a crack at it...  yep, +1
<cjwatson> barry: I believe it's oauth, lazr.restfulclient, keyring, launchpadlib (at least)
<cjwatson> barry: plus chasing down some releases/packaging/etc.
<barry> cjwatson: oauth is gonna suck because it's basically unmaintained upstream
<cjwatson> bug 823252
<ubottu> Launchpad bug 823252 in python-oauth (Ubuntu) "Please provide a python3 package" [Undecided,New] https://launchpad.net/bugs/823252
<cjwatson> I started on making oauth be either six or 2to3 - given relative lack of upstream maintenance I really don't think branching it is a good idea
<cjwatson> the patch isn't really all that terrifying though
<cjwatson> barry: maybe you could figure out keyring and I'll finish up what I was doing with oauth at the earliest opportunity?
<barry> cjwatson: that sounds like a plan for today.
 * ScottK thinks the only python that terrifies barry is python 1.5.
<barry> ScottK: actually, 1.6 is the most frightening :)
<ScottK> Ah.
 * ScottK was close.
<cjwatson> my python-debian 3 branch is fairly scary, and currently failing tests :-(
<barry> but nobody knows about the contractual obligation release :)
<barry> cjwatson: dang.  bytes/strings?
<cjwatson> yup
<cjwatson> there's a horrible bit where it needs to parse text before knowing whether it's bytes or unicode
<barry> ouch
<cjwatson> foo = re.compile(r'blah'); if isinstance(text, bytes): foo = re.compile(foo.pattern.encode())
<cjwatson> makes slightly more sense in context but still *shudder*
<ScottK> barry: Google knows about it: http://mail.python.org/pipermail/python-dev/2011-August/112846.html
<barry> cjwatson: try foo = re.compile(br'blah') for a nice change of data types :)
<cjwatson> yeah, I know about that but it didn't really work out
<cjwatson> I left out a 'for line in sequence:' above
<barry> ScottK: google knows everything.  http://www.python.org/getit/releases/1.6.1/
<cjwatson> anyway will probably still change things around given it's failing tests right now - I just took a break to try to split out some of the working bits into reasonably-sized commits
<barry> at least python 3.3 will let you write rb'foo' too :)
 * barry nods
<cjwatson> http://anonscm.debian.org/gitweb/?p=users/cjwatson/python-debian.git;a=shortlog;h=refs/heads/python3
<cjwatson> uncommitted WIP is a 1700-line patch
<ScottK> barry: I particularly love the name of the "CNRI Open Source GPL-Compatible License"
<ScottK> That resulted in a lintian bug report.
<barry> ;)
<barry> cjwatson: nice: http://pypi.python.org/pypi/keyring/0.7#id1
<cjwatson> Handy
<barry> cjwatson: i'll prep a debian update and test it on precise
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656336 is the lazr.uri bug
<ubottu> Debian bug 656336 in lazr.uri "lazr.uri: new upstream 1.0.3 with Python 3 support" [Wishlist,Open]
<cjwatson> barry: you might need to harass somebody to do a wadllib release
<cjwatson> the patch has landed in trunk
<barry> cjwatson: blueprint updated
<barry> slangasek will not be happy with the burndown chart :)
<stgraber> barry: I'll try to do some Edubuntu work this weekend, that should improve our chart a bit ;)
<barry> stgraber: i like how that works out.  i add items and you close them. :)
<ScottK> barry: What was the result of your contacting POX about the status of multibuild?
<barry> ScottK: he says he's been busy with real life, but has some time now to move things forward
<ScottK> Thanks.
<ScottK> infinity: "/usr/bin/ld: final link failed: Memory exhausted" new kernel is not enough for qtwebkit-source.  Urk!
<infinity> ScottK: That's... Not comforting.
<ScottK> infinity: Right.  I wanted to make sure you had a nice weekend.
<infinity> ScottK: That means it must be pretty dangerously borderline on all 32-bit arches.
<ScottK> ;-)
<ScottK> Really?  It's not that different than what we had before that built.
<infinity> ScottK: I'm going to try this locally on a Panda with that kernel over the weekend and see what I can come up with.
<ScottK> Builds on armel in Debian.
<ScottK> infinity: Sounds very good.  Thanks.
<ScottK> Interestingly it gives an ICE on armhf in Debian, so count your blessings.
<infinity> I think Debian's behind on GCC patches, hence the ICE.
<infinity> But binutils needing more than 3G to link this thing is ridiculous. :/
<infinity> And me needing natty to debug it is equally annoying...
 * infinity goes SD card hunting.
<infinity> ScottK: If it's any consolation, our control build (haskell-src-exts) also failed.  It might just be that this kernel is a dud, and wasn't verified correctly...
<micahg> infinity: Chromium is pretty close to 3GB for linking as well BTW
<janimo> infinity, the buildd pandas all have 1GB active now?
<infinity> janimo: Real RAM isn't the issue here, it's the 3G addressable bit.
<infinity> janimo: (And I'm not sure if lamont fixed their cmdline, but even if he didn't, that's only 64M lost or something?)
<janimo> infinity, well I was thinkging of haskell-src-exts
<infinity> janimo: Same story...
<janimo> infinity, at one point they were using half a gig only
<infinity> janimo: In both cases, real RAM isn't the issue.
<infinity> Err, what?
<infinity> I don't recall that ever being true.
<janimo> infinity, well I think some of the builds failed because of thrashing so more physical RAM would have helped
<janimo> infinity, in maverick or even natty at one point pandas were unstable with 1G so we had half a gig or so. Or maybe 600-700M
<janimo> anyway not the full RAM minus fb size
<infinity> janimo: Anyhow, just confirmed that the entire RAM is there.
<janimo> ok
<infinity> I'm cursed.
<infinity> I just panicked an x86 machine while downloading a natty arm image.
<infinity> apw: I blame you.
<infinity> ...
<infinity> And again.
<hallyn> mdeslaur: vm-new is trying to download from releases.ubuntu.com?
<hallyn> trying mini...
<hallyn> slangasek: do you know of anyone ideally suited to look at bug 893450 ?  it turns out to be a perf problem somewhere in the storage stack...
<ubottu> Launchpad bug 893450 in libvirt (Ubuntu) "libvirt fails to start correctly because LVM is not ready" [High,Incomplete] https://launchpad.net/bugs/893450
<barry> stgraber: ping
<stgraber> barry: pong
<barry> stgraber: hi.  iirc, you have some output about the environment in the buildd chroots, right?  i'm seeing something in my local sbuilds with the locale being different than my normal shell locale.  this causes problems with python because sys.getfilesystemencoding() ends up being 'ascii'.  i'm wondering what the actual local is on the buildds
<barry> stgraber: iow, sys.getfilesystemencoding() is 'utf-8' in a normal shell, but 'ascii' in a schroot
<Laney> ls
<Laney> noooooo
<stgraber> barry: https://api.launchpad.net/1.0/ubuntu/precise/amd64 will give you the link to the current chroot used by LP, not sure how much information about the environment you can get out of that though
<tumbleweed> we normally build in the C locale
<tumbleweed> LC_ALL=C python -c 'import sys; print sys.getfilesystemencoding()' gives me ANSI_X3.4-1968
<barry> stgraber: not enough, but thanks ;)
<barry> tumbleweed: hmm.  that tells me that my chroot is accurately reflecting the buildd's which is good.  but now i have to work around the ascii fs encoding ;)  pain awaits.
<stgraber> barry: http://paste.ubuntu.com/811279/
<barry> stgraber: c locale.  cool, thanks, that jives w/tumbleweed.  i'll hack around it
<tumbleweed> barry: yeah, for some packages we have to generate a UTF-8 locale so that the tests can run
<tumbleweed> (e.g. beets, comes to mind)
<stgraber> barry: taken from jodh's procenv's package tests in the buildlog (IIRC that's how we discovered the /dev/stdin weirdness last week): https://launchpadlibrarian.net/89515945/buildlog_ubuntu-precise-amd64.procenv_0.2-1ubuntu7_BUILDING.txt.gz
<barry> stgraber: ah yes, right. james had that nice little package.  thanks!
<barry> tumbleweed: maybe i should look at how beets does that for python-keyring
<barry> tumbleweed: ah.  i see how it does it.  i have to get python-keyring to set the local before it runs setup.py, since that's the first failure
<tumbleweed> that sucks if it won't even install in a non-UTF-8 locale
<tumbleweed> (python's encoding heuristics are one fo my least favorite bits of the language)
<barry> tumbleweed: yep. it reads the CHANGES.txt file next to setup.py, which contains non-ascii
<tumbleweed> ah, yeah, seen that before too
<tumbleweed> I got upstream to take an ASCII-ificantion patch
<barry> tumbleweed: could be an easy solution is a quilt patch to ignore encoding errors
<tumbleweed> yeah, that'd work too
 * barry wonders how far that'll get him
<barry> it's definitely worth submitting an upstream bug
<broder> hmm...is it possible to set a SIGSEGV handler without interfering with apport/kernel's core dumping?
<cjwatson> lamont: I don't suppose you'd have a chance to look at RT#50437?  Should be quick ...
<cjwatson> (will unblock an ubuntustudio work item for me)
#ubuntu-devel 2012-01-21
<chromaticwt> will the next stable release of ubuntu use python3 by default?
<cjwatson> chromaticwt: no; we're working on ramping up the set of libraries provided, but we won't be far enough along to use 3 by default
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-python-versions
<cjwatson> We hope to get to the point where at least one major desktop application is using Python 3
<cjwatson> (for 12.04)
<chromaticwt> so the plan is to be python3 only by 14.04LTS
<cjwatson> ... we hope, yes
<cjwatson> breaking the back of the major sets of libraries we use all the time this cycle should help
<ScottK> chromaticwt: It also depends on what you mean by "by default".  If you mean /usr/bin/python being a symlink to some python3 version, I'd guess that's a decade away.
<broder> ScottK: i desperately hope that we are never so insane as to make /usr/bin/python a py3 interpreter
<ScottK> broder: Never is a very long time.
<ScottK> Certainly not anytime soon.  A decade would be fast.
<Laibsch> stgraber: we've had a few bug fixes and translation updates to pastebinit since the last release.  I think it would be good to release them to Debian in time for precise.  If you don't object, I'd like to create new upstream tarball soonish.
<Laibsch> There's also a couple of branches proposed for merging.  I'll leave that for you, though, I'd rather not touch bzr with a ten-foot pole unless I really have to ;-)
<nava> is canonical writing a SDK ? (for tablets , smartphones ,tv and also desktop)
<l3on> pitti, just a ping to say I uploaded the new patch for bug 843734 (it's about ruby-sinatra, we discussed yesterday ... the versions question...)
<ubottu> Launchpad bug 843734 in ruby-sinatra (Ubuntu Oneiric) "ruby-sinatra : Depends: ruby-rack but it is not installable" [Undecided,Fix committed] https://launchpad.net/bugs/843734
<apw> infinity, seems reasonable
#ubuntu-devel 2012-01-22
<jono> anyone here familiar with writing PyGI apps?
<alabd> Good day all , wana chanage perm of a file on ntfs usb external hard disk , but without error chmod 777 does not take affect
<commandoline> alabd: you might be helped better in the help channel: #ubuntu
<commandoline> this channel is about development of Ubuntu
<alabd> ok thanks  bye
<valterstr> hello
<valterstr> I would be interested in developing ubuntu
<valterstr> and this will sound silly, but, what programming language is used?
<bkerensa> valterstr: A variety
<valterstr> I am looking at https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/bzr/precise
<valterstr> lp:ubuntu/bzr
<valterstr> vala seems to be used
<valterstr> but the directory tree is unusual for mee.
<penguin42> valterstr: I'm not sure if there are many things that use vala; but it's quite neat; but there is a lot of C, Python, C++, perl - everything really
<valterstr> is there an ide?
<valterstr> wait. valac-*.**
<valterstr> ?
<penguin42> a few - I don't use them myself; I think anjuta is used by various people, not sure what it's like or which languages it supports
 * valterstr googes...
<valterstr> *googles.
<valterstr> looks good. will install.
<valterstr> many dependencies...
<valterstr> I have the source files and I have Anjuta
<valterstr> Now when I try to import the project, it asks if I want to use makefile backend or directory backend.
<valterstr> which should I choose?
<valterstr> testing makefile then...
<valterstr> looks ok. but could someone explain which files is the code itself in?
<valterstr> as I have understood, /bzrlib contains the software code in lp:ubuntu/bzr
<valterstr> but in lp:ubuntu/cowbell it is /base
<valterstr> @penguin42: so, there is no "default" directory tree?
<udevbot_> Error: "penguin42:" is not a valid command.
<valterstr> penguin42: so, there is no "default" directory tree?
<penguin42> I don't know what you mean
<valterstr> I mean, e.g. all software files are held in /base folder.
<valterstr> it is different for different packages
<valterstr> ubunte/cowbell package files: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/cowbell/precise/files
<valterstr>  /base folder is used there
<valterstr> ubuntu/bzr package files: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/bzr/precise/files
<valterstr>  /bzrlib is used.
<valterstr> penguin42: that's what I mean.
<commandoline> valterstr: Ubuntu consists about a number of different programs, different packages. They use all kinds of different programming languages and different directory tree structures, it depends on the preference of the developers of the packages.
<penguin42> valterstr: Some of those directories are just what the author decided they wanted - that's the source tree, and the author can make up those names as they want
<valterstr> ok
<penguin42> valterstr: There are some that are fixed in debian/ubuntu packages (e.g. the debian directory) and some that are common (e.g. po and lib)
<valterstr> noticed.
<valterstr> thanks for the info.
<glD> Hi all, I have a problem with new package "esys-particle". It builds fine, but on Ubuntu during start the following error appears
<glD> "ImportError: /usr/local/lib/python2.7/dist-packages/esys/lsm/util/libFoundationPy.so.0: undefined symbol: _ZTIN5boost6python15instance_holderE"
<glD> It seems, it is an ubuntu-related problem, because the same package works fine on Debian
<glD> I would appreciate, if somebody gives an advice how to fix that
<glD> there is a corresponding bug on that: https://bugs.launchpad.net/esys-particle/+bug/916724
<ubottu> Ubuntu bug 916724 in ESyS-Particle "ESyS-Particle has linking problems on ubuntu-11.10 variants" [High,New]
<glD> thanks ahead
<jtaylor> most likely an as-needed problem
<jtaylor>  /usr/local/lib/python2.7/dist-packages/esys/lsm/util/libFoundationPy.so.0 is probably not linked correctly
<jtaylor> glD: ^
<jtaylor> do you have a buildlog of it?
<glD> jtaylor: yes, just a moment
<glD> Debian: https://buildd.debian.org/status/fetch.php?pkg=esys-particle&arch=amd64&ver=2.1-1&stamp=1324594155
<glD> Ubuntu: https://launchpadlibrarian.net/89385870/buildlog_ubuntu-precise-amd64.esys-particle_2.1-1_BUILDING.txt.gz
<jtaylor> glD: there is a bunch of stuff underlinked, see the dpkg-shlibdeps warnings
<jtaylor> also in debian
<jtaylor> that should be fixed
<glD> jtaylor: ok, thanks
<glD> I will try
<jtaylor> python is often one of the first to notice that as undefined symbols in pythion extensions are pretty normal (e.g. libpython stuff)
<jtaylor> thus problems only detected at runtime
<glD> jtaylor: it means, that the code should be patched somewhere?
<jtaylor> no its a makefile issue
<glD> Ok, thanks
<jtaylor> that package has a bunch of far to general library names
<jtaylor> libFields, libParallel
<jtaylor> libModel
<jtaylor> how did that get through in debian :O
<glD> jtaylor: it should be something like libEsysModel, libEsysFields..?
<jtaylor> probably yes
<jtaylor> or they should be private libraries
<jtaylor> = installed in a subfolder of usr/lib
<glD> jtaylor: there are also errors on both buildlogs
<glD> ImportError: libFoundationPy.so.0: cannot open shared
<glD> |            object file: No such file or directory (line 15)
<jtaylor> glD: thats a problem of the PYTHONPATH
<jtaylor> or library path not sure
<jtaylor> should not be a problem when the package is installed
<jtaylor> setting this should work LD_LIBRARY_PATH=debian/tmp/usr/lib/python2.7/dist-packages/esys/lsm/util/
<glD> ah, ok
<jtaylor> having that in PYTHONPATH  should do the same
<glD> jtaylor: what do you think, why the problem appears in Ubuntu, not in Debian?
<glD> I mean the first problem, with symbols
<jtaylor> ubuntu enables as-needed during build by default debian does not
<jtaylor> this has some effect on indirect links which are used here
<glD> can the "quick" workaround be to switch off it? --no-as-needed to make the package working?
<glD> and then to fix all of other issue
<jtaylor> the fix is to link everything properly
<jtaylor> underlinking library causes all kinds of issues
<jtaylor> In my opionion those dpkg-shlibdep warnisn should be errors, that would save a huge amount of trouble
<jtaylor> nobody reads warnigns ...
<glD> jtaylor: ok, thank you!
<glD> will try to fix that
<jtaylor> glD: one issue is in debian/rules, LDFLAGS := -lboost_system
<jtaylor> libraries do not go in LDFLAGS, those will be placed wrongly by autotools
<jtaylor> LIBS is normally the correct varaible
<mdeslaur> hallyn: yes, iso downloads use releases.ubuntu.com
<tsdgeos> tkamppeter: you around by chance?
<tkamppeter> tsdgeos, hi
<tsdgeos> tkamppeter: seen my mail about the huge speed regression?
<tsdgeos> tkamppeter: re poppler and lcms
<tkamppeter> Yes, so you found one PDF where Poppler with lcms2 takes 10 times longer than Poppler with lcms1?
<tsdgeos> i had found that pdf already in 2010 yes
<tsdgeos> but nobody seems to read the mails i sent back then :D
<tkamppeter> tsdgeos, can you attach the file to the thread or at least send it to me?
<tsdgeos> google for it, it's everywhere
<tsdgeos> http://www.eci.org/doku.php?id=es:downloads
<tsdgeos> altona_technical_1v2_x3.pdf
<tkamppeter> tsdgeos, that time you did a migration, nmow Koji Otani did one independently. Did you already try to run the file through Koji Otani's version of the migration?
<tsdgeos> err
<tsdgeos> is my english that bad?
<tsdgeos> yes, i used koji's version
<tkamppeter> tsdgeos, is this the only file which gets that much slower, you told abot 5-10% performance loss is usual.
<tsdgeos> that was koji
<tsdgeos> and me too probably
<tsdgeos> originally i found it to be even faster on some files
<tsdgeos> but going from 0.5 to 5 sec
<tsdgeos> is a bit of a no go
<tsdgeos> i did not try any other files
<tkamppeter> If it is only that one file, you should perhaps report a bug to the lcms developers with the file attached and also tell Koji as he did the migration (and so he could have done something wrong, too).
<tsdgeos> have you even looked at the patch?
<tsdgeos> the migration is basically renaming of stuff
<tsdgeos> you can't do that wrong
<tkamppeter> tsdgeos, OK, then it looks more like a bug in lcms2 which gets triggered by said file.
<tsdgeos> i'd agree
<tsdgeos> i prefer to use software i know it works instead of buggy one
<tsdgeos> and i'd suggest ubuntu to the same ;-)
<glD> jtaylor: ok, thanks, will fix that
<jtaylor> glD: also it appears the libraries don't link with libTml*
<jtaylor> that has been patched for the executables, but not for the libraries
<tkamppeter> tsdgeos, to do a real test one should use a large amount of PDF files (you should have some test repository of PDFs for Poppler's QA) and run them all through the current Poppler, once with and once without Koji's patch, afterwards counting how the results compare in speed and also how many crash without and how many with the patch.
<tsdgeos> tkamppeter: i can't make my pdf suite public, i don't have rights to distribute them
<tsdgeos> tkamppeter: how many crash without the patch? none
<tkamppeter> tsdgeos, but you can publish the statistics.
<tsdgeos> sure
<tsdgeos> i don't feel like doing the work since i've already found a showstopper
<tsdgeos> i mean, found it two years ago :D
<tsdgeos> anyhow, sleep time, let's see if either koji or the lcms dude you put in the CC have anything to say in the matter
<tsdgeos> night@all
<slangasek> hallyn: bug #893450> cjwatson is certainly the expert where sector sizes are concerned... not sure how high that'll be on his list though :/  The bug description sounds like a race condition, not a perf problem?
<ubottu> Launchpad bug 893450 in libvirt (Ubuntu) "libvirt fails to start correctly because LVM is not ready" [High,Incomplete] https://launchpad.net/bugs/893450
#ubuntu-devel 2013-01-14
<mesquka> Hi
<darkxst> chrisccoulson, have you considered pulling in mozjs188(i.e. firefox 17esr spidermonkey engine)?
<micahg> darkxst: there hasn't been an upstream release yet, when that happens, we can look at getting it into raring
<darkxst> micahg, the delta between upstream source and standalone release is just a couple of patches to change version numbers and library names
<micahg> darkxst: yeah, but there might be changes before release which could result in SONAME changes which can be messy
<darkxst> micahg, we can control the sonames tho http://people.ubuntu.com/~ricotz/mozjs/
<darkxst> the only changes to the 17 branch should be security updates anyway
<micahg> darkxst: control? yeah, but hacking around upstream breakage isn't fun
<darkxst> well its not like they will landing api changes into an esr branch
<darkxst> and if they do an official release, it wont be anymore than the 3 patches in the above link
<darkxst> micahg, mozilla certainly dont seem to keen to invest time in providing great standalone releases anymore
<darkxst> I ported gnome-shell/gjs to js188 and it solves basically all the issues with leaks and GC deadlocks
<darkxst> looking at the other rdepends, no one else (apart from gjs uses custom bindings) so should all be trivial to port
<darkxst> 60% a compatibility.h added to mozjs, the other 40% some sed magic
<MrWGW-> astraljava: Studio is an official flavor from what I understand
<MrWGW-> but beyond that, Canonical as the owner of the Ubuntu trademark can stop people from using it
<MrWGW-> beyond that, they could if they wanted to stop people from using 'buntu'
<MrWGW-> and I have zero problems with this
<MrWGW-> if I do a cinnamon flavor, I'll call it cinnabuntu in all probability unless they let me call it Ubuntu Classic or Ubuntu Retro or something
<MrWGW-> btw I'm suprised they didn't crack down on some of the weirder unofficial flavors like Ubuntu Satanic Edition
<MrWGW-> there is a school of thought in corporate identity law that favors cracking down on anyone coming even close to infringing your trademark, because if you don't, the fear is that other companies might be able to say you're not defending it, and that its become a generic word
<MrWGW-> this happened most famously with the word 'Cola'
<MrWGW-> so I don't mind at all Ubuntu being protective about its brand identity
<MrWGW-> at one time before I got into IT back in 2007, I was a graphics designer working in the world of corporate identity, at Interbrand
<MrWGW-> I played a minor role in the development of AT&T's identity and in some airline branding and other things
<MrWGW-> its fun stuff
<darkxst> MrWGW-, don't know if I quite like their taste, but they have some amazing artwork in there
<MrWGW-> Canonical does a much much better job at branding than the vast majority of open source projects, Ubuntu and redHat have had the most professional investments in that
<MrWGW-> darkxst: Ubuntu's graphics are beautiful, but beyond that the Ubuntu font is a spectacular achievement in typography
<slangasek> there's a standing public trademark policy that says you can use the ubuntu trademark for variants as long as they're built from the Ubuntu repository, official flavor or not: http://www.ubuntu.com/aboutus/trademarkpolicy
<darkxst> MrWGW-, the satanic mob
<slangasek> (Ref: "Remix")
<MrWGW-> I really don't have any gripes with the Ubuntu project, I like its technical direction more than ny of the other major distros
<MrWGW-> slangasek: right, I want to do a remix based on Cinnamon, which I love
<MrWGW-> my desire is to use the Debian Cinnamon package, and integrate it with the beuatiful Ubuntu font, and the same desktop background that the contemporary mainline Unity release would feature
<slangasek> Canonical has in fact stopped folks from using the Ubuntu name for things that aren't built from the Ubuntu archive - e.g., "EasyPeasy" which tried to call itself Ubuntu EeePC for a while
<MrWGW-> btw what would be even better would be if Ubuntu just would reach out to Clement LeFebvre and work with him on merging the Unity and Cinnamon projects
<MrWGW-> slangasek: and that's legitimate and I have zero problems with it, they're more than generous as it is
<MrWGW-> IMO Cinnamon is more usable on conventional systems with a mouse and keyboard, whereas I suspect, but haven't had a chance to confirm, that Unity would be superior on tablets and phones
<MrWGW-> and IMO it just doesn't make sense for there to be two separate competing GNOME 3 alternatives
<MrWGW-> at some point this is probably going to have to happen in one form or another
<MrWGW-> either Unity will have to get somewhat better desktop usability on conventional systems, or else some accomodation will have to be reached to stop the bleeding to Linux Mint
<MrWGW-> and IMO the whole point of hte Unity project should be, well, Unity
<slangasek> Unity is not trying to be a "GNOME 3 alternative"; it has its own consistent vision for the desktop (and other form factors)
<MrWGW-> slangasek: its becoming painfully obvious that that vision is not entirely successful on conventional systems
<MrWGW-> remember Unity was originally intended for netbooks
<MrWGW-> many aspects of its design are optimized for systmes with small screens
<MrWGW-> and lead to extreme pain on larger monitors in my experience
<MrWGW-> now imagine if you could just click a button in Unity, and get a Cinnamon style Win95ish UI
<MrWGW-> that would just instantly silence all Unity detractors
<darkxst> MrWGW-, I am very happy with the Gnome3 vision - aka gnome-shell
<MrWGW-> darkxst: some people are, but some people aren't, hence the surge in popularity that alternatives are getting
<MrWGW-> and IMO Unity is better than GNOME 3
<MrWGW-> I have used unity on Netbooks and it shines on that form factor
<MrWGW-> and I suspect it will shine on tablets
<MrWGW-> and btw if an Ubuntu phone comes out this year, I'll buy it
<MrWGW-> if an Ubuntu TV comes out this year, I will buy it
<MrWGW-> in fact...if its possible for me to build my own Ubuntu "TV" by cobbling together a small box and a big screen TV with an HDMI cable
<MrWGW-> I'm going to do that
<MrWGW-> you guys ought to put up a tutorial on how to roll your own Ubuntu TV system
<darkxst> MrWGW-, I supect there are far more happy gnome3 users, than the odd few that right all the bad blogs
<MrWGW-> well, I go to the San Fernando Valley Linux User Group, and the Simi Conejo Valley Linux User Group
<darkxst> s/right/wright/
<MrWGW-> the latter is known for its orchestration of the annual SCALE conference in LA
<MrWGW-> which is one of the premiere Linux conferences
<MrWGW-> at those two LUGs, I don't know of a single user, out of about 60 guys overall, ranging from n00b to expert, from an age of 17 for the youngest member to 80 something for the oldest, who is running GNOME 3
<MrWGW-> a few of them are running Unity, not many
<MrWGW-> also at SCALE last year, I didn't see anyone outside of the GNOME booth who was using GNOME 3 either heh
<MrWGW-> now a lot of people are using KDE 4 and enjoying it, and a lot of people are using other desktops
<darkxst> MrWGW-, why would I care what other people are using? I enjoy gnome-shell so I use it!
<darkxst> and other than submitting the odd patch upstream, I have no affiliation with gnome
<MrWGW-> darkxst: indeed so, I'm just saying, its not as well received as you think
<MrWGW-> I myself still use Windows 98 on some gaming boxes
<MrWGW-> I've taken some flak for that, so I'm the last person who would object to someone else's personal OS preferences
<darkxst> yeh I know some people don't like it, and mostly that is due to the big learning curve, of completely different interface (and/or the early releases really being of alpha quality at best). But I also the supsect and this is just speculation, that the noise from the haters doesnt really correspend to the happy users
<darkxst> I also suspect people also read the blogs from the haters, and then don't really give it a chance themselves
<mesquka> Well, direct people to my blog, lets see if they try ubuntu then?
<pitti> Good morning
<pitti> OdyX: cups 1.6.1 in exp> congrats, great work!
<pitti> tkamppeter__: ^ can we sync again, or does the Ubuntu package have a delta?
<pitti> tkamppeter__: oh, we did already, nevermind; great!
<Laney> quite a nice changelog there ;-)
<Laney> tkamppeter: looks like you miss a (Breaks/)Replaces cups-daemon -> cups in the new cups?
<Laney> for the manpages that weren't moved in 0ubuntu15
<xnox> Laney: ++
<Laney> suspect quite a few will see that this morning :P
<Laney> -o Dpkg::Options="--force-overwrite" FTW
<Laney> ::=?
 * xnox did dpkg -i cups-daemon & then continued dist-upgrade.
<Laney> meow
<OdyX> Laney: that's fixed in 1.6.1 but not widely enough, see the git repository.
<geser> Laney: bug #1099242
<ubottu> bug 1099242 in cups (Ubuntu) "package cups-daemon 1.6.1-0ubuntu15 failed to install/upgrade: trying to overwrite '/usr/share/man/man7/backend.7.gz', which is also in package cups 1.6.1-0ubuntu15" [Undecided,Confirmed] https://launchpad.net/bugs/1099242
<OdyX> Laney: /win 30
<Laney> OdyX: righto
<OdyX> damn.
<Laney> 30? #debian-qa? NO.
<OdyX> Laney: you can (get tkampetter) upload what's in git master branch to Ubuntu if that's urgent. I'd prefer to hold that release a tad more as I'm waiting for some translation updates.
<Laney> OdyX: I suppose breakage like this in development releases isn't OMGcritical
<cjwatson> It should be fixed ASAP
<OdyX> Laney: 6 duplicates still.
<cjwatson> The development release is not supposed to have upgrade errors (for long)
<Laney> but people will continue to report it, so it should be fixed relatively soon
<OdyX> Laney: I can generate a changelog for you, wait a sec
<Laney> sure, I'll upload that
<OdyX> Laney: upload to ppa in process
<Laney> k
<OdyX> Laney: pushed there https://launchpad.net/~odyx/+archive/printing/
<geser> could someone copy/upload the version of libimobiledevice from quantal-updates to raring please? currently the version in raring is smaller than quantal-updates
<cjwatson> geser: copied to raring-proposed
<Laney> there's also chromium-browser kdegames in that situation (as well as some linux-*)
<cjwatson> Yeah, I'm not touching chromium-browser :)
<cjwatson> kdegames doesn't have newer source in quantal-updates than raring - nor do any linux-* that I can see
<cjwatson> I don't tend to copy from -proposed routinely
<cjwatson> People can do so manually if they want
<Riddell> Laney, cjwatson: kdegames is now made from meta-kde
<Riddell> I'll remove the source package
<Laney> was looking in proposed too, indeed
<cjwatson> Riddell: Not all its binaries appear to be superseded?
<Riddell> cjwatson: mm so I see, I'll look into that
<cjwatson> Riddell: Also I think it'd be a good idea to let meta-kde reach raring before you start removing superseded things
<cjwatson> (Since removals don't go through proposed-migration, I tend to be very cautious about them)
<Riddell> doh, too late
<Riddell> hmm I don't see what's holding meta-kde
<Riddell> oh, something on arm
<mesquka> any program that runs right is obsolete
<cjwatson> Riddell: ksudoku and kubrick aren't even attempted on armhf
<Riddell> I wonder whyever not
<Riddell> oh it's in the packaging, weird
<Riddell> uses gl I guess
<cjwatson> So either kdegames needs to become Architecture: any so that it can depend on them only on some architectures, or you need to drop those to Recommends
<Laney> OdyX: Uploaded, thanking you. :-)
<OdyX> Laney: np.
<mlankhorst> infinity: can you review the mesa sru for precise?
<tjaalton> cjwatson: huh, the new precise daily image is still 22MB bigger with just the backport stack on it, compared to .1
<cjwatson> I expect there are other things different
<cjwatson> Will be doing some analysis this week
<mlankhorst> bbiab
<xnox> tomorrow is my "logan day", I mean "patch piloting"
<Laney> good job dholbach isn't around - 107 itemsâ¦!
<tjaalton> and only a handful of people can clean the queue up from bugs that shouldn't be there
<tumbleweed> anyone can ask to join ubuntu-sponsors
<tjaalton> yes please
<tumbleweed> TheMuso: ^
<tjaalton> hmm it was some other team where there is <10 members and >40 applied
<xnox> tjaalton: ubuntu-reviewers?!
 * xnox is still waiting to get into that one
<tjaalton> xnox: that's the one yeah. and the numbers are 24/43 but still :)
<tjaalton> only two admins :/
<pitti> Laney: LibO and bluez-gstreamer also still use 0.10; is there any migration plan for those?
<Laney> I have to figure out what's going on with those two
<pitti> Laney: oh, and libpurple; although that by itself smells rather obsolete; do we actually still need that, or do we have sufficiently many telepathy plugins now?
<Laney> possibly -haze can be dropped indeed
<pitti> ISTR that someone mentioned that at UDS
<pitti> (dropping purple)
<pitti> that's AIM, Yahoo, Gadu-Gadu, and ICQ mostly
<hrw> anyone with SRU power? I lost hope for bug 1085392 ;(
<ubottu> bug 1085392 in Cross distro support for Samsung Chromebook (ARM based) "Merge Chromebook UCM profiles into ALSA packages" [Critical,Triaged] https://launchpad.net/bugs/1085392
<pitti> Laney: hm, I still don't see native telepathy plugins for those, at least not packaged ones?
<pitti> meh
<Laney> at least for ICQ/AIM you can use XMPP
<pitti> Laney: urgh, and sessioninstaller -> python-gst0.10, but that can hopefully use GI now
<pitti> Laney: oh, nice
<Laney> though I'm not sure if there's UI to make it easy
<pitti> account-plugin-icq depends on -haze
<pitti> but testing
<Laney> the plugins probably use haze indeed; I mean that you can set it up as an XMPP connection yourself
<Laney> not that I've verified this - haven't used ICQ in many years
<pitti> at least not with the accounts tool; once I uninstall accounts-plugin-icq, gst 0.10, and -haze there is no GUI for adding ICQ or MSN
<pitti> Laney: yeah, same here
<Laney> that's what I expected
<Laney> but I can imagine entries which automatically populate the correct XMPP information
<Laney> alternatively there is https://developer.pidgin.im/ticket/15299
<zul> mterry:  hey so testrepository should be fine now
<mterry> zul, ok, let me look
<lamont> where did we hide the switch to allow/disallow guest logins via lightdm, I wonder.
<mterry> lamont, /etc/lightdm/lightdm.conf
<mterry> zul, so bug 1098605 can be marked fix released it looks like
<ubottu> bug 1098605 in testrepository (Ubuntu) "Fix failing 'slowest' test" [Undecided,New] https://launchpad.net/bugs/1098605
<lamont> right.  and by default it's allowed, so it wasn't mentioned there.  thanks mterry
<zul> mterry: yeah it was missing the python-tz deps
<mterry> zul, thanks!
<coalwater> hello all
<coalwater> there's this tool i usually see on omgubuntu, they create wireframes for mockups and stuff, what's the tool used for that ?
<hallyn> zul: how did kvm used to get the custom version #? I don't see anything in debian/control
<hallyn> (i.e. it's 1:84+dfsg-0ubuntu16+1.2.0+noroms+0ubuntu7 in raring right now)
<zul> hallyn: no idea
<hallyn> Daviey:  ^ do you know?
<geser> coalwater: I'm not sure but it could be http://www.balsamiq.com/products/mockups
<coalwater> geser: yea it looks like it, but it's not free?
<geser> coalwater: no :(
<coalwater> geser: is there a free alternative?
<coalwater> geser: i found this  http://mashable.com/2010/07/15/wireframing-tools/
<Daviey> hallyn: soryy, dunno
<micahg> infinity: your dkms headers change had the result of removing the headers from the running kernel on my system
<cjwatson> Only, presumably, because you used autoremove
<micahg> well, the packages are marked as auto-installed
<micahg> I'm using aptitude...
<cjwatson> It would surprise me if this were the only instance of this kind of problem
<micahg> it didn't do it yet, I'm looking at the screen
<micahg> well, thanks to dkms, all old headers were kept until now
<cjwatson> What I mean is I don't think this is necessarily v-failed.
<cjwatson> (Because I don't think it is in general wise to blindly trust autoremovals.)
<micahg> well, I guess it wouldn't affect most people that just use update-manager
<cjwatson> There ought to be something that ensures that current kernel image/headers remain installed, certainly.  I don't think it should be dkms.
<cjwatson> It arguably ought to be aptitude itself in this case.
<cjwatson> Does aptitude not honour /etc/apt/apt.conf.d/01autoremove-kernels, or was that not yet in precise?
<micahg> sure, but kernel images aren't marked as auto-installed, whereas headers are
<micahg> not in precise
<cjwatson> Ah, autoremove-kernels doesn't list headers, either
<cjwatson> It probably should
<micahg> or apparently in quantal
<cjwatson> slangasek: ^-
<cjwatson> micahg: I don't think it's sensible for us (collectively) to rely on dkms doing this, in any event.
<micahg> cjwatson: oh, I agree entirely, but until it's fixed properly, this seems to be the wedge holding it together
<cjwatson> We can't drop the dkms change because we have no other way to get the 12.04.2 images back within size limits.
<micahg> cjwatson: since we have an extra week, isn't there time to get the proper fix backporteD?
<micahg> sorry, 2 weeks
<cjwatson> That's part of why I highlighted slangasek; but the extra two weeks are for more QA, not really for more fixes ...
<cjwatson> I'm sure some are possible but only where really necessary
<micahg> well, this would prevent a class of breakage (I'm wondering what unattended upgrades does here)
<cjwatson> I'm going to wait for infinity or slangasek to comment.
 * micahg runs off, will check backscroll later
<wookey> is there a kernel dev irc channel or should I just ask here?
<ogra_> there is #ubuntu-kernel
<wookey> I want to know what of the kernel libfoo-dev build-deps are for host arch and which for build arch
<pitti> cjwatson, infinity, stgraber: could one of you please set a migration blocker for pygobject?
<cjwatson> pitti: done
<pitti> cjwatson: thank you
<hallyn> zul: so kvm has beena  transitional pkg since lucid.  i guess i can just remove it right?
<zul> hallyn: in theory
<infinity> hallyn: Yes.
<infinity> hallyn: Assuming there are reasonable relationships in place that make an upgrade remove the old one.
<infinity> cjwatson: kernel autoremove doesn't need to list headers because kernel images now suggest headers, which keeps them installed.  This works in raring.  None of this is backported to precise yet, though.
<cjwatson> Suggests keeps things installed?  Is that new.
<cjwatson> ?
<infinity> micahg: If dkms was the only thing keeping your headers installed, then you didn't have metapackages installed?
<infinity> cjwatson: It seems to DTRT here.
<ogra_> suggests is the new recommends ?
<infinity> (base)adconrad@cthulhu:~$ dpkg -l linux-\*[0-9]\* | awk '/^i/ {print $2}'
<infinity> linux-headers-3.7.0-7
<infinity> linux-headers-3.7.0-7-generic
<infinity> linux-headers-3.8.0-0
<infinity> linux-headers-3.8.0-0-generic
<infinity> linux-image-3.7.0-7-generic
<infinity> linux-image-3.8.0-0-generic
<infinity> linux-image-extra-3.7.0-7-generic
<infinity> linux-image-extra-3.8.0-0-generic
<infinity> ^-- On a machine where I always autoremove after upgrade.
<infinity> micahg: Or do you mean your running kernel wasn't the latest installed?  In which case, the dkms change would have changed nothing, since it depended on the metapackage.
<infinity> micahg: It was always the case that the situation in precise was you'd only keep latest-installed headers on autoremove.  This should be fixed, but the dkms change shouldn't have made the situation any different.
<infinity> I was on precise when I reported https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1029730
<ubottu> Ubuntu bug 1029730 in linux-ti-omap4 (Ubuntu) "linux-image-$(uname -r) should suggest linux-headers-$(uname -r)" [Medium,Confirmed]
<infinity> So, yeah, autoremove always removed everything but the latest.
<infinity> This isn't new.
<hallyn> infinity: so 'proper relationship' top make kvm go away, would be having another package break+replace it?
<hallyn> or do i have to do more to make the binary package go away?
<ogra_> grr
<ogra_> so i had disabled all my SD card partyitions from showing up in the launcher ... with the last upgrade all of them suddenly show up again
<infinity> hallyn: You might actually need a P/C/R relationship to make it go away completely.  I don't recall if things changed much with the addition of breaks.
<xnox> hallyn: i see packages still dependind/recommending kvm, those should be fixed.
<xnox> e.g. nova-compute-kvm, utah, possibly others.
<infinity> xnox: That's a non-problem if something still provides kvm (assuming the dependency isn't versioned)
<infinity> Still should be fixed anyway, but yeah.
<xnox> infinity: well qemu-kvm does "Provides: kvm"
<infinity> xnox: Indeed.
<hallyn> xnox: infinity: good point, i'll file bugs agaisnt packages depending on kvm in the meantime
<hallyn> stgraber: can qemu now be added to the ubuntu server set?  (even though it failed to upload?  but if it goes into server set i can push the fix at http://people.canonical.com/~serge/qemu-conflict-kvm.debdiff :)
<stgraber> hallyn: added. It should stay in there until at least the next automated packageset update by cjwatson, but hopefully by then it'll be seeded and so won't be removed
<cjwatson> Please make sure it's seeded ASAP then as I'm due another full update
<stgraber> I guess it'll be as soon as it produces binaries
<stgraber> (basically replacing the qemu-kvm/qemu-linaro sources)
<psusi> ok, so if a package is synced from debian, and since quantal there has been only one new version that is a SRU like cherry pick bug fix due to debian also being in freeze, would it be appropriate to just request it be synced back into quantal?
<cjwatson> psusi: No, if nothing else we always want to rebuild for older distributions
<cjwatson> It can be an identical source package apart from the changelog if you like, but it'll need a different version
<hallyn> stgraber: thanks, lemme see if i can upload then :)
<psusi> cjwatson: I thought requestsync could copy the source but rebuild the binaries?
<hallyn> stgraber: can i impose on you to quickly look at  http://people.canonical.com/~serge/qemu-conflict-kvm.debdiff (46 line debdiff) to make sure i got that right?
<cjwatson> psusi: That's disallowed by the archive because binary file names will clash.
<cjwatson> You can only do a copy-and-rebuild between *different* archives.
<psusi> ahh
<stgraber> hallyn: I'm never sure when to use Breaks and when to use Conflicts in such cases, though as kvm is a transitional package, I don't think it really makes any difference anyway, the rest look good
<hallyn> stgraber: thanks, will push then.  just don't want tomake any changes that end up making future package stuff even more complicated
<maco> i think conflicts is "they both have the same filepath included"
<cjwatson> There are a few possible reasons for Conflicts - policy pretty much enumerates them
<cjwatson> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
<psusi> so if I start with the raring version, should I add a new changelog entry with the oldver.1 or modify the version number of the existing entry?
<cjwatson> I would do the latter, so that the diff from <currently in quantal> to <your new package> looks like an ordinary SRU upload.
<psusi> ok
<cjwatson> Credit appropriately, of course.
<psusi> it's me either way ;)
<cjwatson> ok
<psusi> ohh, and I need to say quantal-proposed right?  not just quantal?
<cjwatson> Either works
<cjwatson> quantal will be mapped to quantal-proposed
<psusi> wait, why is there not a name conflict going the other way?  if version 1 is built in quantal, then when raring opens, it's still version 1, but all the binaries are rebuilt arent they?
<maco> dont think so
<maco> not unless an actual full-archive rebuild happens
<maco> by default, the old binaries are just copied
<psusi> ohh... I thought they got rebuilt when a new cycle started
<cjwatson> maco is correct
<hallyn> stgraber: oh, bug 1099155 - that looks like the same network manager bug screwing up lxc-net right?  do you have an open bug for that?
<ubottu> bug 1099155 in libvirt (Ubuntu) "[raring] No ip assigned to bridge and no routes added for routed network" [Undecided,New] https://launchpad.net/bugs/1099155
<cjwatson> They don't, it'd take ages and cane mirrors for not much benefit
<stgraber> hallyn: yep, that looks like it. I don't think I saw a bug specific to lxcbr0, so I guess we can use that one from now on.
<stgraber> cyphermox: ^
<psusi> ok, and the merge shold be proposed into ubuntu/quantal/gparted right?
<cjwatson> Probably easier to just attach a debdiff to a bug
<cjwatson> UDD is a bit patchy for SRU handling
<cyphermox> stgraber: thanks.
<cyphermox> but right now, trying to figure out something funny with openssl
<cyphermox> stgraber: cjwatson: not sure if it's openssl really because it doesn't seem like it changed in the right timeframe but here the wpa enterprise network can't be successfully authentified, i get TLS errors for the certificate
<CodeRed> I'm getting an error on installing ubuntu through wubi " cannot download the metalink and therefore the iso " how to get through this ?
<coalwater> i'm looking for a python project (preferrably one done with gtk (has gui) or something) that's looking for developers, and it would be great if there's a mentor who'll help me with the developing, i already am comfortable with bzr i just want to get used to python more, and learn doing gui apps
<stgraber> cyphermox: NM is connecting fine to my network here, though arguably my certificate is self-signed and I told NM to ignore it :)
<cyphermox> yeah
<cyphermox> this one has a proper cert; but i did say to ignore the fact that I didn't pass a file
<cyphermox> I think it's ignoring the fact that there is no ca passed rather than ignoring whether the CA matches ;D
<cyphermox> http://paste.ubuntu.com/1531834/
<cyphermox> stgraber: yeah, I think it's just that it's not ignorin the right thing; I'll have to go get the CA first to check
<jbicha> how did the audit package migrate without readahead-fedora being rebuilt?
<jbicha> http://people.canonical.com/~ubuntu-archive/nbs.html
<stgraber> cyphermox: though that reminds me, I tried connecting to the Eduroam wireless at the ETS over the weekend and wpa_supplicant wasn't too happy about it
<stgraber> cyphermox: but I don't see any mention of openssl in my syslog, so that was another problem
<cyphermox> yeah, I think it's likely to be exactly the same issue
<cyphermox> unless the UQAM wifi is broken, which is within the realm of possibility
<slangasek> cjwatson: as for autoremove-kernels listing headers, I originally believed the current behavior was by design on the grounds that old kernels you're keeping around for recovery aren't going to need modules newly built for them; but IIRC infinity persuaded me that we should keep the headers too, this just isn't implemented yet
<slangasek> infinity, cjwatson: er, suggests is certainly not *supposed* to have any effect on autoremoval
<infinity> slangasek: Well, it definitely does.  Check your raring machines.  They all have headers matching all installed kernel images.
<infinity> slangasek: And I'm not sure why it shouldn't have an effect.
<slangasek> because suggests are *not* auto installed
<slangasek> so not auto-removing suggests would be asymmetric and broken
<infinity> slangasek: Unless you ask them to be.
<slangasek> which we don't do
<infinity> slangasek: No, but a human can.  And the auto* DB has no way to discern HOW you installed something.
<infinity> (Or, rather, what relationship pulled it in)
<infinity> So, if you install with suggests and recommends, and foo recommends bar, while baz suggests it, removing foo shouldn't remove bar.
<slangasek> infinity: er, nobody in their right mind installs with suggests
<infinity> I still don't see how the behavious is wrong.
<slangasek> you're right that the auto* db doesn't know what relationship pulled it in; but *I* know suggests aren't pulling anything in here
<infinity> It's non-obvious to me that I could silently lose functionality in some application because a suggests is removed when something else that depended on it is removed.
<infinity> Anyhow, it appears to function the way I think it should currently. :P
<infinity> So, I suspect I'm not alone in this belief.
<infinity> Or, working the problem the other direction.  If I use a friendly frontend like dselect or aptitude that offers suggests when I install something, and I opt to install those suggests...
<infinity> Should it mark them auto, or manual?
<slangasek> manual
<infinity> In your world, they'd have to be manual.
<slangasek> and it does
<infinity> But then the suggests stay installed even if the reason I installed them is removed.
<infinity> Which is bizarre when we've put effort into making sure hard deps are removed, but we leave suggests as cruft?
<slangasek> because when you manually select it for installation in the frontend, that's manual installation
<infinity> Well, I don't doubt that's how the frontends currently work.
<infinity> But I'd contend that in a drill-down menu for recommends/suggests, what I'd really want is "install these 5 of the 7 you're offering me, but mark them auto so they go away if I remove the parent".
<infinity> Anyhow, for the kernel autoremoval case, we can also just blatantly ignore what the tools are or aren't doing as far as who believe the features should work how, and add linux-headers-$(abi) to the no-auto-remove list. :P
<infinity> Cause it won't do any harm either way.
<slangasek> my point is that if the headers are being kept installed, it's /not/ because of the suggests
<infinity> slangasek: It pretty much has to be, nothing else on my system depends on them.
<slangasek> have you been doing upgrades using update-manager?
<infinity> No, apt at the command line and autoremove.
<slangasek> hmm
<infinity> (base)adconrad@cthulhu:~$ dpkg -l linux-\*[0-9]\* | awk '/^i/ {print $2}'
<infinity> linux-headers-3.7.0-7
<infinity> linux-headers-3.7.0-7-generic
<infinity> linux-headers-3.8.0-0
<infinity> linux-headers-3.8.0-0-generic
<infinity> linux-image-3.7.0-7-generic
<infinity> linux-image-3.8.0-0-generic
<infinity> linux-image-extra-3.7.0-7-generic
<infinity> linux-image-extra-3.8.0-0-generic
<infinity> Exact matching sets of images and headers, which is what I'd expect if I'm right. :P
<infinity> And I've done nothing special to make that happen.  Just upgrade and autoremove.
<infinity> Andy's also seen the same behaviour since we made the change in the kernel.
<slangasek> bug #1078544, btw
<ubottu> bug 1078544 in aptdaemon (Debian) "python-aptdaemon: upgrading marks auto-installed packages as manual" [Unknown,New] https://launchpad.net/bugs/1078544
<slangasek> (which seems to be an SRU you've approved :)
<infinity> slangasek: Yeah, but I only use apt-get, and these are all makes auto.
<infinity> slangasek: So unrelated.
<infinity> s/markes/marked/
 * slangasek nods
<slangasek> but in my case, they're not marked auto; and if I mark them auto, they get removed
<infinity> On raring?
<slangasek> quantal in this case
<infinity> Right, the image->suggests:headers thing is only in raring.
<slangasek> ah
<mterry> doko, you switched the devscripts python module to be python3 only it looks like.  This causes lots of problems with ubuntu-dev-scripts which is python2.  Like bug 1099091
<ubottu> bug 1099091 in devscripts (Ubuntu) "pull-debian-source crashed with ImportError in __main__: No module named devscripts.logger" [Medium,Confirmed] https://launchpad.net/bugs/1099091
<infinity> slangasek: For evidence completeness: http://paste.ubuntu.com/1532171/
<doko> mterry, yeah, I have to provide the module for python2 too
<infinity> slangasek: Anyhow, I think apt's autoremove behaviour is correct here.  We may disagree on that point.  Either way, it does no harm to *also* add headers to the apt hack, so we may as well.
<infinity> slangasek: And we'll want that if we backport to precise, where the images don't (currently) suggest headers.
<mterry> doko, OK, assigned that bug to you
<mterry> looks like it's the clearinghouse for these issues
<doko> mterry, otoh, it won't hurt to keep these issues open for the relevant packages, that these require a port to python3. could you do that too?
<infinity> Thanks for the subtle reminder to put devscripts on hold before I accidentally upgrade it again. :P
<mterry> doko, molded dup bug 1099537 into an open issue that we should port the scripts
<ubottu> bug 1099537 in ubuntu-dev-tools (Ubuntu) "ubuntu-dev-scripts should be ported to Python 3" [Medium,New] https://launchpad.net/bugs/1099537
<infinity> doko: Are you going to get to the devscripts upload today?  If not, I might revert the previous one in the short term to stop the flow of bugs and confusion.
<doko> yeah, will do, and for the future, please propose to fix it, not revert it
<infinity> I prefer fixing it. :P
<infinity> Almost always.
<infinity> In this case, I'm not sure how best to fix it, though.  I guess building and shipping the python2.7 bits but intentionally skipping the pyhton2.7 dependency?
 * doko add this to the infinity-promised-to-fix list
<infinity> I made no such promise. :)
<stgraber> tkamppeter: hey, looks like cups-browsed depends on avahi but the upstart job doesn't. Causing quite a lot of pointless respawn of the daemon on my machine :)
<stgraber> tkamppeter: http://paste.ubuntu.com/1532299/
<stgraber> tkamppeter: should I upload directly to the archive or are you planning a cups-filters upload pretty soon?
<tkamppeter> stgraber, thanks for finding that. Please upload the corrected cups-filters.
<stgraber> tkamppeter: ok, doing that now then.
<OdyX> ^ stgraber please upload to experimental.
<OdyX> well, in that case it doesn't really matter, granted, but make sure it's committed to the repository. :)
<stgraber> OdyX: I don't think I've got access to the Debian bzr branch, maybe tkamppeter can commit the change there then
<tkamppeter> OdyX, why did you upload the CUPS package ubuntu-only? Why did you not simply make 1.6.1-2 for both Debian and Ubuntu, to keep the sync.
<OdyX> stgraber: ah yeah, damn, I thought it was a git repository on alioth, sorry.
<OdyX> tkamppeter: ah yeah, good catch. You caught me. :) I didn't want to upload at all, but the discussion here showed it was important to have it soon in Ubuntu. Also the fix only affected Ubuntu.
<tkamppeter> stgraber, I can upload the change to the Debian BZR for you.
<stgraber> tkamppeter: thanks
<OdyX> tkamppeter: I didn't want to upload now in Debian as I'm waiting for manpage translation updates for both french and german. I also hope (and asked) that msweet would push a 1.6.2 soon'ish.
<tjaalton> TheMuso: thanks :)
<tkamppeter> jasoncwarner, hi
<bdrung> cjwatson: the libibmad/libibumad transition is worked on and will be finished soon.
<infinity> bdrung: Thanks for the heads-up.
<bdrung> infinity: you are referring to the libibmad/libibumad transition?
<infinity> bdrung: Yeahp.
<bdrung> infinity: i ask the sponsoree. he wasn't aware of the missing packages, because he mis-scripted his checking of build dependencies. he will update the missing packages through experimental.
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<xnox> cjwatson: pitti: or stgraber: please reject https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/postgresql-8.4/precise-proposed/+merge/139408
<bdrung> stupid modem causing connection losses (despite having a reliable working openwrt router)
<stgraber> xnox: done
<xnox> thanks.
<stgraber> xnox: hmm, and what timezone are you on? ;)
<xnox> stgraber: =))))))))
<xnox> stgraber: I patch pilot tomorrow. So I can do it a bit now, then sleep and then do more =)
<xnox> just came back from coaching volleyball
<stgraber> hehe, ok ;)
#ubuntu-devel 2013-01-15
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Bluefoxicy> httperf --hog --num-conn 25000 --rate 10000 192.168.1.144 --timeout 5
<Bluefoxicy> ^^^^ this hangs.
<Bluefoxicy> httperf --hog --num-conn 15000 --rate 10000 192.168.1.144 --timeout 5
<Bluefoxicy> ^^^ this does not.
<Bluefoxicy> echo 1 | sudo tee /proc/sys/net/ipv4/tcp_tw_reuse ; echo 1 | sudo tee /proc/sys/net/ipv4/tcp_tw_recycle
<Bluefoxicy> ^^^ Now neither hangs.
<Bluefoxicy> Ubuntu 12.10
<pitti> good morning
<pitti> stgraber, infinity: can you please remove the pygobject block? all relevant autopkgtests succeeded, except software-center which failed before (and I tested that manually)
<infinity> pitti: Sure.
<pitti> infinity: thanks
<pitti> hey mvo, guten Morgen
<tuxinator> hi all
<tuxinator> i cant figure out if mysql on ubuntu is compiled with openssl support or not
<tuxinator> it looks like have_openssl is only a pointer to have_ssl in mysql?
<coalwater> ls
<coalwater> lol
<coalwater> how do i install package 'quickly' on debian
<coalwater> can't find the ppa
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<cjwatson> bdrung: Thanks (libibmad)
<ev> mpt: why is silent error types just restricted to errors that occur during logout/shutdown? Shouldn't all internal errors be hidden behind the "report previous internal errors" checkbox too? (https://wiki.ubuntu.com/ErrorTracker#error)
<mpt> ev, it isn't, that's just the kind we'd been definitive about so far. That's why it's a bulleted list. :-)
<ev> ah, right
<ev> so can I add non-desktop applications to that list?
<mpt> Which ones?
<mpt> If pulseaudio crashes, for example, that's an internal error that's going to be obvious to the user.
<mpt> Or network-manager.
<mpt> (Assuming that they were using sound or networking at the time.)
<ev> hm, yeah
<ev> if we were getting so precise as to separate out those cases, would it not also make sense to give them special wording?
<ev> so, "sorry but your ability to hear sound may be hindered" rather than "an internal application crashed"
<ev> something to that effect
<ev> I guess I'm just worried that sometimes they'll see "an internal error occurred" and sometimes they wont, and it wont be clear why that's the case
<mpt> ev, maybe. It depends how many we whitelist or blacklist, or whether there's a non-whitelist/-blacklist way of distinguishing them.
<ev> sure
<mpt> ev, perhaps we could go through the leaderboard and sort the non-application packages into those two categories
<mpt> as a way of deciding whitelist vs. blacklist
<ev> sure
<ev> whenever you'd like
<mpt> Thursday?
<ev> mpt: sure
<blami> hi, do I understand correctly that the output of complete multilib transition is that under /lib will be platform directory containing all libraries and current state is mixture of past and future, or am I missing whole thing?
<didrocks> hey cjwatson, infinity: jibel told me that libbamf3-1 was in universe? I don't really understand what happened: I promoted it to main (from proposed) Friday, just after the copy happened for the daily release.
<didrocks> cjwatson: infinity: I think that's why britney migrated it (once we rebuilt the rdepends because of the soname change) to the main pocket
<didrocks> but then, in main, it was back in universe?
<didrocks> s/in main/ in the release pocket/
<xnox> didrocks: there is a bug where packages fall back into universe, after they are copied from -proposed to -release pocket.
<xnox> =/ so most things need to be promoted twice.
<didrocks> xnox: ah, so not related to the daily release at all. For future, it's the case everytime? So we need to repromote after the copy?
<didrocks> ok, got it, good to know :)
<didrocks> thanks xnox
<xnox> didrocks: yes. daily release was all good.
<xnox> np.
<roaksoax> howdy! I was wondering if anyone know if it is possible to determine is package A is to be installed (or has been installed) in package B postinst script?
<pitti> roaksoax: you cannot install packages from postinst scripts, as apt/dpkg are not recursive
<pitti> (the first will lock the dpkg db)
<roaksoax> pitti: yeah I don't want to install a package I just want to determine whether another package has been installed or is to be installed (and if that's even possible)
<pitti> roaksoax: oh sorry, you mean if it already is installed? dpkg -s pkgname >/dev/null 2>&1
<pitti> "about to be installed" would be looking into the future
<pitti> you can check whether it's unpacked, but not configured yet by looking at the "Status:" line
<roaksoax> pitti: right let's say I do: sudo apt-get install meta-package which installs package A and B. Package B gets installed first but I want to know whether A is to be installed or not
<pitti> but apt doesn't unpack everything before it starts configuring, it does that stuff in batches
<pitti> roaksoax: not sure what you want to do, but that's usually the kind of stuff triggers are for
<pitti> so that an already installed package can do stuff when another package gets installed later on
<roaksoax> pitti: alright cool! I;ll look into triggers. Thanks for the info :)
<pitti> roaksoax: "man deb-triggers" FYI
<roaksoax> thanks :)
<tumbleweed> checking whether it's unpacked (instead of using triggers) just sounds like a recipe for non-deterministic behavior
<arges> tyhicks: hey. I can't seem to find bug 1052038 on the pending SRU queue. I think last time we spoke this was ready to go right?
<ubottu> bug 1052038 in eCryptfs "ecryptfs_fnek_sig missing when login at the same time on cron session close" [Medium,In progress] https://launchpad.net/bugs/1052038
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox, sconklin
<cjwatson> blami: Basically yes
<cjwatson> blami: (Though you mean multiarch, not multilib - multilib is something different)
<hrw> sconklin: bug 1085392 maybe?
<ubottu> bug 1085392 in Cross distro support for Samsung Chromebook (ARM based) "Merge Chromebook UCM profiles into ALSA packages" [Critical,Triaged] https://launchpad.net/bugs/1085392
<arges> zul: hello! I'm looking at the cinder FTBFS failure. Looks like a patch that skips the failed tests wasn't enabled. Does it make sense to enable this patch 'skip_failed_tests' and fix the ftbfs?
<sconklin> hrw: Sorry to say, I'm a kernel guy, and only tend to look at kernel bugs
<hrw> sconklin: ok, was worth trying ;D
<zul> arges: yes penable it
<arges> zul: okey dokey
<GuidoPallemans> I'm making a Reddit reader for the phone! Anyone care to join? https://github.com/brambram/UbuntuPhoneRedditApp
<xnox> hrw: now you can bug members of ~ubuntu-sru team to accept alsa packages from bug #1085392 E.g. infinity =)
<ubottu> bug 1085392 in alsa-utils (Ubuntu Quantal) "Merge Chromebook UCM profiles into ALSA packages" [High,In progress] https://launchpad.net/bugs/1085392
<tyhicks> arges: Yes, it has been ready to go for quite a while now. It just isn't getting any attention from ~ubuntu-sru, IIUC.
<arges> tyhicks: well I don't see it on the list: http://people.canonical.com/~ubuntu-archive/pending-sru.html , so wasn't sure why that was
<tyhicks> arges: Lets bug a member of the ~ubuntu-sru team to find out
<tyhicks> infinity: Since you were pinged above for another SRU, can you take a look at bug 1052038 ? It has been sitting for a while now.
<ubottu> bug 1052038 in eCryptfs "ecryptfs_fnek_sig missing when login at the same time on cron session close" [Medium,In progress] https://launchpad.net/bugs/1052038
<dkessel> hello guys. i have a question: under which circumstances does the bluetooth indicator icon get added to the indicator bar?
<dkessel> i am asking because i seem to have a false positive...
<roadmr> cyphermox probably knows :)
<cyphermox> dkessel: if there is a bluetooth type device
<cyphermox> dkessel: it kind of surprises me; maybe you have a device somewhere that says it does bluetooth even if it doesn't
<cyphermox> or if you're using some of those logitech dongles for mice and keyboards
<dkessel> cyphermox, i have a dell netbook. they sell the bluetooth module as an addon. but i don't have it. but i guess that explains it somehow...
<sarnold> does it work anyway? :)
<cyphermox> no, you should actually have a bluetooth device for the indicator to show up ;)
<dkessel> tbh i tried to use it :)
<dkessel> but as i don't have the module.... nothing
<cyphermox> dkessel: what does hciconfig return?
<dkessel> cyphermox, nothing
<cyphermox> O.o?
<dkessel> do i need some parameters?
<cyphermox> going to have to look at the code
<cyphermox> no
<dkessel> :)
<cyphermox> if there is a device it should be listed there
<dkessel> funny
<sarnold> I have to click the indicator and "turn on bluetooth" to get output from hciconfig on my machine..
<infinity> Ditto.
<infinity> Something's smart enough to know I have bluetooth, despite it being currently disabled/disconnected/whatever.
<infinity> In fact, I can't even enable it from the indicator, cause it's hard-disabled by the machine.
<dkessel> even if i do that, there's no output from hciconfig
<roadmr> infinity: maybe something's dumb enough to assume you do; the smarts to know the device has to be enabled are yours :P
<infinity> (But I still have the greyed-out indicator, until I undo my hardware rfkill)
<slangasek> dkessel: what does 'rfkill list bluetooth' show?
<roadmr> dkessel: udevadm info --export-db  |grep -i blue, does that say anything? (this is how checkbox looks for bluetooth so I'm guessing no, but may be interesting)
<dkessel> slangasek, http://paste.ubuntu.com/1535302
<stgraber> dkessel: can you paste the output of "dmesg"?
<dkessel> roadmr, http://paste.ubuntu.com/1535311
<roadmr> dkessel: thanks! so it looks like rfkill may be used to decide whether to display the indicator?
<dkessel> stgraber, dmesg: http://paste.ubuntu.com/1535314
<slangasek> roadmr: well, I think the indicator is displayed based on the presence of the underlying features that rfkill is also exposing
<stgraber> thanks. So yeah, it looks like the applet is showing up when either you have a bluetooth device or the rfkill driver reports that you have one that can be turned on
<roadmr> slangasek: well put, thanks :)
<stgraber> not sure exactly how rfkill works, but I suspect it's getting the information from the firmware somehow (ACPI?) and that something's wrong somewhere in there
<slangasek> dkessel: what's the output of 'ls -ld /sys/class/rfkill/rfkill3/device'?
<dkessel> that takes a bit longer to type :) sec
<dkessel> lrwxrwxrwx 1 root root 0 Jan 15 21:16 /sys/class/rfkill/rfkill3/device -> ../../../compal-laptop
<slangasek> mmk
<slangasek> so either the hardware claims to have a bluetooth interface, or the compal-laptop module has a bug
<stgraber> dkessel: sorry, those are long paths. "cat /sys/class/rfkill/rfkill3/device/device/vendor" and "/sys/class/rfkill/rfkill3/device/device/device"
<dkessel> :D
<dkessel> i just found a new use case for ubuntu one... :)
<stgraber> the first one should give you the hardware vendor id, the second one should give you the hardware product id
 * dkessel pastes command lines
<stgraber> oh, and I forgot cat in front of the second one, but you probably notice that ;)
<dkessel> stgraber, file not found on first "vendor"
<dkessel> stgraber, ...and another file not found on "device"
<dkessel> shall i paste the contents of /sys/class/rfkill?
<stgraber> ok, so based on what I'm seeing here, that'd mean that the driver isn't tied to a physical device (as /device/device should have pointed to the PCI or USB device)
<stgraber> looks like a kernel bug to me... the compal-laptop driver always reports two rfkill entries even if the hardware isn't there
<stgraber> I just tried it on my laptop with "modprobe compal-laptop force" (the force keyword is to bypass the DMI check) and I got two extra rfkill entries
<dkessel> i would probably need help on how to properly file that bug
<stgraber> http://paste.ubuntu.com/1535349/
<stgraber> dkessel: do "ubuntu-bug linux" on your machine, once you have the bug filed on Launchpad give me the bug number and I'll see if there's something that should be added
<dkessel> stgraber, will do
<dkessel> hmm... "it appears you are currently running a mainline kernel".... meh - apport won't let me report... i'm running raring
<stgraber> dkessel: fun... then go directly to https://launchpad.net/ubuntu/+source/linux/+filebug
<stgraber> dkessel: and once the bug is filed, do "apport-collect <bug number>", that one should work without complaining too much
<dkessel> launchpadlib would be part of ubuntu-dev-tools, i guess....
<hrw> xnox: thanks man!
<dkessel> stgraber: bug 1100004 . apport really didn't put much info in it...
<ubottu> bug 1100004 in linux (Ubuntu) "compal-laptop reports bluetooth device, even if there is none" [Undecided,New] https://launchpad.net/bugs/1100004
<stgraber> dkessel: posted a comment asking for a bunch more things that should help the kernel team get a fix matching your hardware
<dkessel> stgraber: that sure spammed some people's mail folders :) well - thanks for the help!
<stgraber> dkessel: oh, they're used to it ;)
<dkessel> :D well I gotta go, see you :)
<romaxa> which channel is hosted for ubuntu-phone people?
<sarnold> romaxa: I think #ubuntu-phone
<romaxa> ;_)
<GuidoPallemans> where can I file QtQuick Ubuntu.components bugs?
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * xnox is back from volleyball ;-)
<xnox> hrw: no problem. I accept payments in cider, monkey nuts and bird seeds =)
<tkamppeter_> Does someone know how one makes the Pandaboard boot from a USB stick?
#ubuntu-devel 2013-01-16
<xnox> tkamppeter_: you can't. You can boot from sdcard or you can boot via OTG mini-usb port.
<xnox> tkamppeter_: google for ogra_ blog posts about booting via mini-usb.
<mwhudson> you can have uboot on the sd card but the rootfs on usb stick
<TheMuso> You may as well use an SD card if you are thinking of using a USB stick. IMO a rotery USB disk is better.
<tkamppeter> xnox, thanks.
<TheMuso> For the root F sanyway.
<xnox> Laney: ;-) here be dragons
<pitti> Good morning
<dholbach> good morning
<diwic> dholbach, congratulations :-)
<dholbach> thanks diwic :)
<Laney> xnox: hoho
<rye> Hi, is this a place one can draw attention to a bug report for raring?
<rye> bug #1085342 FWIW
<ubottu> bug 1085342 in totem (Ubuntu) "Pulseaudio applications hang (Totem, GNOME Shell etc.)" [Undecided,Confirmed] https://launchpad.net/bugs/1085342
<diwic> rye, could you check if it is resolved in PA 3.0? We have packages incoming for PA 3.0, let me give you the link
<diwic> rye, *reading* hmm, maybe it's more of a threading error than PA error?
<rye> diwic: that's glibc error as far as I understand
<rye> in NPTL
<diwic> rye, ok, then I'm not the right person to answer. PA 3.0 is available for testing at https://launchpad.net/~ubuntu-audio-dev/+archive/ppa btw.
<rye> diwic: will test that too
<rye> diwic: basically the bug can be triggered very easily - totem videofile -> seek back and forth a bit. Sometimes totem does not even start playing so in case PA 3.0 has a workaround for this glibc bug then it should stop manifesting. Otherwise all aps will still fail and pulseaudio will look like the one to blame
 * rye has not yet rebuilt libc locally
<rye> diwic: ok, just a heads up, PA 3.0 also hangs under these conditions
<diwic> rye, ack, thanks for testing
<infinity> diwic: If that's the bug I'm thinking of, it's fixed in glibc 2.17, which I'm bouncing to the archive soonish.
<diwic> rye, ^
<diwic> infinity, sounds good. Does it affect any stable releases?
<infinity> diwic: I'm a bit less clear on that.
<diwic> ok
<diwic> infinity, probably not as I haven't heard any riots about it
<infinity> diwic: Always happy to have more datapoints on the topic, if you can easily reproduce with a backported package or something.
<diwic> infinity, ok
<Laney> I'm seeing (something which sounds like) this which correlates with my recent dist-upgrade to raring.
<Laney> diwic: For me it happens with Spotify too; don't know if that gives you any more data (this uses libasound2)
<infinity> Laney: If I give you a glibc 2.17 to test, can you tell me if it goes away?
<Laney> ok
<infinity> Hrm, I'll have to find a build that isn't scary broken.  I trust my source, but none of my binaries...
<rye> infinity: please subscribe me too to glibc 2.17 testing
<rye> infinity: also this can be easily reproduced in VM so if it is broken that's not the end of the world :)
<rye> infinity: for tracking purposes - bug #1085342
<ubottu> bug 1085342 in totem (Ubuntu) "Pulseaudio applications hang (Totem, GNOME Shell etc.)" [Undecided,Confirmed] https://launchpad.net/bugs/1085342
<infinity> rye: Same as Debian #694962?
<ubottu> Debian bug 694962 in libc6 "libc6:amd64: pulseaudio hangs in pthread_cond_wait" [Important,Open] http://bugs.debian.org/694962
<rye> infinity: yes
<rye> infinity: linked it there
<Laney> indeed, my traces have pthread_cond_wait at the top too
<infinity> Right, let me just lob this at a PPA, then.  People can have a hammer at it.
<infinity> rye, diwic, Laney: Uploaded to https://launchpad.net/~adconrad/+archive/ppa for testing fun.
<Laney> cheers
<Laney> pitti: I suspect this is what you reported in #-desktop too ^^^
<cjwatson> ev: I've been looking at the LP implementation of phased updates.  Do you have any thoughts/requirements/etc. on how frequently the phase value for a given package version should be changed?
<infinity> rye, diwic, Laney: There's one test failure in there that still scares the crap out of me, plus a few more things I need to land, so I don't recommend this for "production". :P
<pitti> Laney: sounds right indeed
<diwic> infinity, okay
<cjwatson> ev: I assume it isn't worth smoothing it out *too* much
<ev> cjwatson: I think we can cope with changes up to "fairly frequently", given the proposed design: https://wiki.ubuntu.com/ErrorTracker/PhasedUpdates
<cjwatson> Yeah, I was just hoping for actual numbers on that :-)  Is once a day "fairly frequently"?  Twice a day?
<ev> hah, sorry. Frequently would be several times a day. I think this is something we're going to have to tune once we start getting real world data in. So perhaps start at twice a day?
<ev> and then we can adjust from there
<cjwatson> The reason I'm asking is that it looks like the easiest way to do this in LP is to treat phase as an override, and use changeOverride for it; this should be very simple but involves creating new publications each time
<ev> ah
<cjwatson> Which I think is essentially required anyway since we're changing something in the Packages stanza
<ev> so not something you want to do that often
<cjwatson> It's not horrible since there's only so much in -updates that hasn't been phased up to 100% yet, but I wouldn't want to be doing it every half-hour, no
<cjwatson> ev: Also, what granularity do you need?  Would a 0-100 int be fine, or does it need to be a floating-point type for some reason?
<cjwatson> (Will need to get the database column created more or less first)
<ev> I think an int would be fine
<cjwatson> OK, good
<ev> cjwatson: we should involve bdmurray in these chats, by the way, as he's taking care of a lot of the implementation
<cjwatson> Yeah, I was talking to him a bit last night
<ev> ah, excellent
<cjwatson> Mostly I want to get the LP side done and then get out of the way ;-)
<ev> pitti: do you have any strong opinions on whether silent reports should be implemented as a new filename suffix (.silentcrash) or as a key off the report itself? I'm inclined the say the former, even though it requires changes to whoopsie as well, as it keeps us from having to read through every report file in /var/crash to find the silent ones.
<ev> context: https://wiki.ubuntu.com/ErrorTracker#error
<ev> that bulleted list will grow
<ev> to include most types of system-internal reports
<ev> which we can only make the distinction on by reading .desktop files. Bum.
<pitti> ev: where would we actually save effort by introducing another extension? I'm rather wary of doing that, it requires more changes
<pitti> e. g. in GNOME's mime handler to open them, etc.
<pitti> ev: and no, we can by no means send an error automatically if it appears during logout
<ev> pitti: in what would become "def get_all_silent_reports"
<pitti> if that is for "[ ] Report internal errors, too", we need to reprocess and load those reports anyway
<ev> they're not being sent automatically unless the user has explicitly asked for them to be sent automaticlly
<ev> automatically*
<pitti> also, I don't think we can decide about silence in the core pipe handler in all cases, can we/
<pitti> ?
<ev> in the vast majority of cases, they appear with the next regular application crash
<ev> but if the user has checked the box in system settings for "just send the things", then it will be sent automatically
<pitti> for detecting .desktop files etc. it needs to happen in the apport-gtk post-processing stage, not in the core pipe handler
<ev> yeah, that's what I was wondering
<ev> right, it sounds like this just needs to be a key in the report
<pitti> ev: right, but wouldn't that be implemented by creating teh .upload files at the time of the crash, not by some GUI having to go through and create them for you?
<ev> and getting all of the silent reports to show with the current application crash involves reading all the report files in /var/crash
<ev> or I guess we could drop another 0-byte hint file
<pitti> I thought whoopsie would only consider those with an .upload (and without .uploaded) stamp
<ev> pitti: this is for showing them in the UI at all
<ev> so as an example
<ev> lets say colord crashes
<ev> that should not pop up a dialog
<ev> later, the gimp crashes
<ev> now a dialog appears saying that gimp crashed and an internal application crashed
<ev> asking you to report both at once
<pitti> okay
<pitti> but we need to call apport (post-processing) to find out whether or not a report file is system-internal in the first place
<pitti> I thought we decide this based on whether it has a .desktop file, don't we?
<ev> indeed, my brain just hadn't gotten that far :)
<ev> we do
<pitti> we probalby have more, such as having a $DISPLAY in env
<pitti> (which we can detect in the core pipe handler already)
<ev> we still need to note that the crash file we've just processed is a silent error, to be picked up later though
<ev> so do you prefer a 0-byte .silent file alongside the .crash file, or a key in the report?
<ev> I'm just still thinking of the implementation of "get_all_silent_reports"
<pitti> ev: update-notifier calls apport-checkreport; in principle this could go through and do the "is system internal" decision, create .stamp files for the "silent uplaod" ones, and add the desktop information to the .crash; and then report in its exit status whether there are "interactive" ones left
<ev> okay
<pitti> ev: I don't like yet another stamp file TBH, it starts being confusing
<pitti> I think apport-checkreports could just "do" it, without having lots of other async components in between
<pitti> that's my gut feeling, anyway
<ev> it does, but we need some way of quickly getting the entire set of silent reports that still need to be presented to the user
<ev> they're only silent in the sense that they don't get their own dialog
<ev> perhaps silent is a poor term for this
<ev> grouped might be better
<ev> it does get confusing, that is - I agree
<pitti> ev: so all that update-notifier does is to call "apport-gtk" without arguments
<pitti> if we define "grouped" in terms of "system vs. app", then we already have API to decide that for a particualr report, don't we?
<ev> we might want to show dialogs for some system internal reports, as mpt pointed out yesterday
<ev> for instance, if pulseaudio crashes
<ev> the user probably wants to know why their sound stopped working
<pitti> so ui.py's run_crashes() already iterates through all of them; it coudl then do the decision which ones to show interactively and which ones to batch?
<pitti> i. e. that wouldn't need rewriting the .crash files yet another time, or adding more stamps; or am I missing someting?
<ev> pitti: there might be some time between colord crashing and the gimp crashing
<ev> I don't think this can happen in one run
<ev> oh
<pitti> why, apport-gtk would see the old colord crash when it is being called for the gimp crash?
<ev> right
<pitti> isn't that how it was supposed to be?
<ev> I just caught that
<ev> but
<ev> what happens when we have all system internal crashes and no regular application crashes?
<ev> oh, the same thing, I guess
<ev> I see your point
<pitti> yeah, that's the problem with that model in general; they would never be sent
<pitti> if the user configured "send them automatically", then apport-checkreports could create the .upload files
<ev> would we not just leave them unprocessed for the next run of run_crashes?
<pitti> but if not, then we need the UI to ack the reports
<pitti> (apport-checkreports is being called at desktop startup and each crash)
<ev> pitti: I think I've got enough to take a stab at the algorithm here. Thank you so much for the chat.
<ev> I'll put an MP up for us to discuss more in depth
<pitti> ev: no worries; we can also have a mumble if you want to discuss in more detail
<pitti> or that :)
<ev> :)
<pitti> thanks for working on this! looking forward to it
<ev> ps. my kingdom for code-inline merge proposal comments
<ev> cheers
<pitti> I think for now we can identify the "batched" ones with "system crash", right?
<ev> correct
<ev> mpt and I are going to refine that on Thursday
<ev> you're welcome to join us via mumble or gtalk
<pitti> for the pulseaudio case, we might actually change it so that it appears as an application carsh
<ev> hm, that's an interesting angle
<pitti> ev: please
<ev> noted
<ev> mpt: what time on Thursday?
<pitti> so that it appears immediately, with some appropriate verbiage
<ev> right
<mpt> ev, 1.30?
<ev> pitti: does that work for you?
<pitti> ev: yes, both UTC and CET
<dholbach> looks like we need to do a bit more sponsoring again
<ev> great
<dholbach> would anyone be available to demo a small bug fix or two? we have one 30m slot left: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable
<tjaalton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton
<cjwatson> ev,bdmurray: Also, do you think it's a problem not to support different phases on different architectures?  Supporting that with the apt-ftparchive-based override handling turns out to be a right pain
 * dholbach hugs tjaalton
<cjwatson> Although I still think putting the phase on BPPH is the right place - it'd just be a limitation of the override handling that if the phases were different across architectures it would effectively just pick one
<ev> cjwatson: I think that's entirely okay, mostly because we hadn't considered it ourselves ;)
<ev> second pass if we really need it
<cjwatson> ev: Yeah, not that I'm sure how to do it even in a second pass :-)
<cjwatson> ev: Looking something along the general lines of http://paste.ubuntu.com/1537437/ so far
<cjwatson> Hmm, that's not quite right, need to be able to set the phase to None ...
<cjwatson> Half-tempting to invert the phase value in the database so that I can have the default be 0 :-P
<dz0ny> hi
<dz0ny> is this te right room for questions about ubuntu-defaults-image?
<dz0ny> the*
<tjaalton> dholbach: thanks for adding me to the sponsors & review teams :)
<dholbach> tjaalton, anytime :)
<dz0ny> I'am trying to build 32bit iso on 64bit host, and according to logs it builds 64bit every time. I'am using --arch i386 switch
<dz0ny> here is build script https://github.com/dz0ny/ubuntu-si/blob/12.04/Makefile
<cjwatson> --arch didn't work right until quantal
<tjaalton> dholbach: already forgot that it was TheMuso who added me to -sponsors, whoops :)
<tjaalton> anyway..
<cjwatson> bug 1016121
<ubottu> bug 1016121 in ubuntu-defaults-builder (Ubuntu Precise) "wrong architecture (i386,amd64) packages downloading" [Undecided,Fix released] https://launchpad.net/bugs/1016121
<dholbach> tjaalton, ain't anything stopping you now ;-)
<cjwatson> though that indicates that you should be able to upgrade to ubuntu-defaults-builder 0.31.1 to fix it
<dz0ny> cjwatson: thx
<Laney> infinity: It certainly seems to be stable again with 2.17
<Laney> Aphex Twin are helping me to confirm this
<rye> infinity: are there any other bugs that should have been resolved by 2.17 upgrade i could verify - pulseaudio no longer wants to hang
 * Laney is relieved that it's not gstreamer's fault :P
<caribou> Q:when files that are not part of the upstream tarball needs to be added to a package, how should it be done ? quilt patch even for new files ?
<caribou> for instance, I wrote a script that uses binaries from the tarball and I want to create a new pkg; should that new script be a quilt patch ?
<ricotz> Laney, hi, are there are eglibc 2.17 packages available for raring somewhere?
<Laney> ricotz: infinity provided a PPA of his unfinished packages (still some test failures). ppa:adconrad/ppa
<ricotz> ah i see :)
<ricotz> (and he didnt told me)
<Laney> we were testing a specific bug fix
<OdyX> caribou: patch or under debian/
<Laney> plus you weren't online to be pung
<ricotz> Laney, alright ;)
<caribou> OdyX: thanks
<ricotz> i will test it
<tjaalton> what to do with a merge request that is marked "needs fixing" for a month now and polluting the sponsor queue?
<Laney> change the status to 'work in progress' at the top
<tjaalton> ah, thanks
<hrw> ~curse usb-creator-{gtk,kde} badly
<xnox> hrw: why?! =)
<hrw> xnox: took me a while to find out that it expects lot of things to be done by user before using tool.
<hrw> xnox: such as formatting usbstick as vfat, mounting it etc
<xnox> hrw: it can format by itself, but one needs to download the img/cd.
<xnox> "erase disk button"
<hrw> xnox: did that once. UI frozen, no progress
<hrw> and it remounts stick as 'sync'
<hrw> so it takes 467 minutes according to progressbar instead of copying in 1-2 minutes, doing all needed and then syncing
<xnox> hrw: in raring? yeah i reverted sync, need to reupload.
<hrw> xnox: yes, in raring
<hrw> nice set of languages in xubuntu install when booted to live: English, Spanish, Polish, Portugese, xhosa, Chinese.
<smoser> RAOF, it looked like you were looking at my cloud-init -proposed, i'd *really* appreciate it if you could push those through. (per comment on bug 1073077, i'm not sure how you're "supposed" to show 'verfication-done' for two different releases)
<ubottu> bug 1073077 in zsh (Ubuntu) "zsh complains about locale_warn on launch" [Undecided,New] https://launchpad.net/bugs/1073077
<cjwatson> smoser: I'll do it shortly
<smoser> cjwatson, thanks.
<cjwatson> smoser: done
<hallyn> cyphermox: have you had a chance to take a look at bug 1099155 ?
<ubottu> bug 1099155 in network-manager (Ubuntu) "[raring] No ip assigned to bridge and no routes added for routed network" [Critical,Confirmed] https://launchpad.net/bugs/1099155
<ev> mpt: is it correct that only third-party non-packaged applications still have a "ignore future errors of this type" checkbox? https://wiki.ubuntu.com/ErrorTracker#non-app-crash
<mpt> ev, no, those three kinds should
<mpt> app thread, 3rd-party non-packaged, and OS package
<ev> okay, thanks
<ev> potentially three checkboxes
<mpt> No
<ev> oh
<ev> right
<ev> because that would be regular applications
<mpt> No, not because of that
<mpt> Because of "*and* there is no âReport previous internal errors tooâ checkbox (so that we donât show more than two checkboxes at once)."
<mpt> Is that too fiddly? :-)
<ev> ahhh
<ev> sorry, I sped through that initially
<ev> no, I think that makes sense
<ev> I was worried about the interaction between those two checkboxes
<mpt> yeah
<mpt> I guess "of this type" would be ambiguous if the "previous internal errors" checkbox preceded it, so we avoid that problem too
<ev> right
<cyphermox> hallyn: I have, and upstream is working on it
<hallyn> cyphermox: cool, thanks
<mpt> ev, I just realized why that part of the spec was unclear: In the default wiki theme, table cell borders are invisible. I use the "modernized_cms" theme, where they're visible.
<ev> ah
<ev> well, thanks to moinmoin, you can add them in, cell by cell ;)
<mpt> yeah
<mpt> reported bug 1100325
<ubottu> bug 1100325 in ubuntu-website-content "Table cell borders are invisible in default wiki theme" [Undecided,New] https://launchpad.net/bugs/1100325
<xnox> =)
<tjaalton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<doko> cjwatson, but it would be something like gcc-4.6-$HOST_TRIPLET [cross]
<cjwatson> doko: do you mean "cross profile"?
<cjwatson> which I think is currently spelled <cross>?
<cjwatson> doko: I don't think it's necessary since this would be something sbuild/dpkg-checkbuilddeps would synthesise when they already know they're cross-building; though you can think of it that way if you like
<doko> cjwatson, hmm how? this is about the additional b-d for gcc-4.7 when cross built
<cjwatson> doko: That's a different issue
<cjwatson> doko: *That* will have to be solved using profiles
<cjwatson> doko: I'm talking about packages that build-depend *on* gcc-4.6 or whatever, and that it would be useful to automatically translate that build-dep into gcc-4.6:native, gcc-4.6-HOST on the fly
<cjwatson> doko: This does not prevent using profiles for build-dependencies of the toolchain itself
<cjwatson> Entirely orthogonal
<cjwatson> doko: But the reason I was asking you was that it would be helpful to have some way to detect that there's a -HOST version available that doesn't involve going and looking in the apt cache, because it'd be a layering violation for dpkg-checkbuilddeps to do that
<cjwatson> doko: I do see that the problem you describe isn't quite simple enough that profiles will magically solve it; but it's not the same as the one I was describing and I was hoping to be able to solve problems one at a time :-)
<doko> ok
<cjwatson> when you said "target-triplet" in that sbuild bug - we're not building a cross-compiler in this case, so is target == build or == host here?
<doko> cross building a native compiler, so host == target
<cjwatson> doko: OK, so my proposal isn't actually wrong for you, it just doesn't solve the entire problem
<jcastro> cjwatson: anything I can do to help a precise fix for bug #1060404 ? Most of our juju handouts/website's documentation runs into this.
<ubottu> bug 1060404 in grub2 (Ubuntu Precise) "update-grub runs and fails in containers" [High,In progress] https://launchpad.net/bugs/1060404
<cjwatson> jcastro: fairly sure I already uploaded it, at least the grub-install side (which is as much as is in raring)
<cjwatson> jcastro: it's probably waiting for queue review or something
<cjwatson> (can't check right now)
<jcastro> SpamapS: ^^
<SpamapS> there's no grub in the precise-proposed queue
<cjwatson> SpamapS: I'll recheck when I'm not ircing from a phone
<SpamapS> cjwatson: ACK
<cjwatson> SpamapS: also I need clarity on whether this is affecting grub-install or also update-grub
<cjwatson> because when I looked at this last I'd only changed the postinst (grub-install) and apparently that was making people happy
<cjwatson> if it's also causing people problems on kernel upgrades as well as grub-pc upgrades, then I think there's been some relevant fix somewhere else
<SpamapS> cjwatson: I'm not familiar enough with the mechanics to know for sure. The reports are coming from people installing new grub's, not new kernels.
<cjwatson> SpamapS: ok, good, so that suggests that the fix I have is sufficient and I only need to look into where it went
<cjwatson> hmm, I think perhaps infinity asked for an unrelated change and I forgot to make that - it's in rejected
<cjwatson> SpamapS: I can sort that out later this evening
<jcastro> cjwatson: thanks for the timely response! \o/
<SpamapS> cjwatson: cool, ping me on upload and I'll review it
<noisepub2> quantal kernels in precise are not packaged correctly for multiarch
<noisepub2> linux-header-`uname -r` needs to be Multi-arch: foreign
<cjwatson> #ubuntu-kernel - but might be better to file a bug on linux-lts-quantal
<stgraber> xnox: hey, why did you break su? :)
<mlankhorst> why not!
<stgraber> xnox: http://paste.ubuntu.com/1539328/
<stgraber> xnox: I'm suspecting the new upstream version to be the problem as cjwatson's no change rebuild is fairly unlikely to have caused this (and I can't find old binaries for -1ubuntu1 to check)
<stgraber> hmm, well, not no change rebuild, but no code change rebuild :)
<infinity> stgraber: That's disconcerting.
<infinity> stgraber: $(tty) works, I wonder what's breaking with /dev/tty
<stgraber> infinity: yeah, not too sure, but I have a few scripts that spawn a shell at some point through su and were rather unhappy about the /dev/tty situation ;)
<infinity> stgraber: Possibly due to the fix for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628843
<ubottu> Debian bug 628843 in login "login: tty hijacking possible in "su" via TIOCSTI ioctl" [Critical,Fixed]
<infinity> stgraber: In fact, almost certainly due to that fix.
<stgraber> infinity: yep, that looks like it, not sure if there's a way around it for cases where you specifically want access to the tty (such as when you're starting a shell and don't want it to be close to impossible to use)
<infinity> stgraber: If you're starting an interactive shell, don't use su -c?
<stgraber> infinity: sure, but I have that small problem that I use su in arkose and that the actual command is passed by the user, so I have no clue as to what they'll be running and quite a lot of them (well, it's the default) happen to call /bin/bash :)
<infinity> stgraber: If this is a shell script that's expecting to output to a tty, try $(tty)?
<infinity> stgraber: I guess I'm not sure what the specific use case is that's leading to this failure, since "echo foo > /dev/tty" seems like an artificial reproducer.
<infinity> stgraber: And if that's actual representating code, the fix is s,/dev/tty,$(tty),
<stgraber> infinity: "arkose -h" was the original source of the bug, it'd create an LXC container, then spawn a shell inside it, which would be as root (as lxc requires root privilege), then use su to drop back to user privileges inside that shell and then run a user provided command from there. That user provided command defaults to /bin/bash
<infinity> http://paste.ubuntu.com/1539530/
<infinity> stgraber: Yeah, I guess I'm still failing to see how/where that fails.
<sarnold> stgraber: perhaps have it spawn su -l for the special case of /bin/bash?
<infinity> Sure, but even this works fine here:
<infinity> su root -c "/bin/sh -c '/bin/bash'"
<infinity> So, I'm still a bit confused what the actual failure is in arkose.
<stgraber> infinity: try doing ctrl+c in that shell, you'll see the problem :)
<infinity> Session terminated, terminating shell... ...killed.
<infinity> Cute.
<stgraber> infinity: with a simple su, it's not a big problem as it'll get you out of your shell and just mess a bit with your console, with arkose as it's wrapped in python, that means that the container won't get killed and you end up with a stack trace and a dozen extra mount points (as arkose can't catch the fact that the user exits and call the cleanup function)
<infinity> stgraber: Yeah, that's vaguely unpleasant.
<stgraber> sarnold: that's because you're assuming that this patch doesn't apply to -l ;) it does
<sarnold> stgraber: oh :)
<infinity> stgraber: Well, but when you detect that the command-line is simple /bin/sh or /bin/bash, you can skip the -c entirely.
<infinity> stgraber: And "su root" or "su - root" (or similar) doesn't have this problem.
<stgraber> infinity: yep, which gets me back, to shipping a list of all known shell in the package... fun...
<infinity> stgraber: It goes haywire on the nested shells.
<infinity> stgraber: /etc/shells
<infinity> stgraber: Read from the container, of course, not the host.
<infinity> stgraber: (Since that file is dynamically updated when shells are installed/removed)
<stgraber> infinity: oh, right, forgot about that one ;) and I'll also need a list of all X terminal emulator as unfortunately arkose supports X application, so xterm will also be affected
<stgraber> so yeah, seems like I'll have to spend way more time on arkose this cycle than I had first planned... Porting to python3-lxc should avoid some of the su-related issues and the rest I can re-implement the rest of the privilege dropping directly in python so that it's less likely to break than su (and will work the same way across distro)
<infinity> stgraber: Some more discussion of the problem in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659878
<ubottu> Debian bug 659878 in login "cannot set terminal process group (-1): Inappropriate ioctl for device" [Normal,Open]
<ricotz> infinity, hi, eglibc 2.17 works nicely here so far, deadlocks are gone
<infinity> stgraber: The suggestion to not drop the terminal when suing to root could be a bit of a workaround for your case, maybe.  Still leaves it weird for others.
<infinity> ricotz: Good to hear.
<stgraber> infinity: nope, I drop from root to user, so it's specifically the case the patch is meant to prevent
<infinity> stgraber: Oh, but the initial su (or, at least, the one you gave as an example) is root.
<stgraber> infinity: yeah, my example was so that nobody could tell me it was some kind of weird permission issue ;)
#ubuntu-devel 2013-01-17
<RAOF> smoser: To show verification-done on multiple releases (or anywhere where the SRU isn't a simple one-package, one-release affair) you can just comment like you did there.
<RAOF> smoser: Indeed, in general it's nicer for us if you make some sort of comment when setting verification-done. It makes it easier to trust :)
<smoser> RAOF, well, i had put comments on them on the first upload to -proposed. better comments. then i  just re-played the.
<smoser> !regression-alert
<ubottu> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<smoser> bug 1100491
<ubottu> bug 1100491 in cloud-init (Ubuntu) "[SRU] cloud-init 0.6.3-0ubuntu1.3 failing to process juju-generated userdata" [Critical,In progress] https://launchpad.net/bugs/1100491
<smoser> cloud-init update in precise caused a regression.
<smoser> regressions suck.  the good news here is that the presense in -updates isn't as bad as it is for other packages.  this is because we have not (will not) release a new cloud-image with cloud-init inside it until this fix is applied.
<smoser> i've uploaded the fix to -proposed.
<smoser> RAOF, if you're around, i'd appreciate https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=cloud-init as mentioned above.
<RAOF> smoser: Processing.
<RAOF> smoser: Done.
<smoser> RAOF, thank you.
<RAOF> smoser: Is this something which should have been caught while testing the proposed update?
<smoser> well, clearly yes.
<smoser> but it was collateral damage
<smoser> ie, not somethign that was directly trying to be fixed.
<RAOF> Was it something that should have been identified as a regression risk?
<smoser> its something that ideally would have been found in automated testing of -proposed.
<smoser> RAOF, does the regression fix in -proposed still bake for 7 days ?
<RAOF> smoser: Not necessarily; but we do want some testing.
<RAOF> If you can provide some thorough testing then we can let it through much earlier. What we don't want to do is let it through but find it breaks something else âº
<smoser> well, this particiular change is clear to not make anything worse than the previous one.
<smoser> anyone have thoughts on how to choose the size 'read' ?
<smoser> i'm not terribly concerned about the memory used by the buffer. i'm looking for insite on how to choose one , or a reasonable default.
<smoser> (when reading possibly large MB of data but not wanting to just do 'read()')
 * RAOF would also be intellectually interested in the answer.
<RAOF> I guess the context needed would be: how much data do you need before you can start processing? That's clearly the minimum buffer size.
<smoser> RAOF, yeah, i'm basically copying
<smoser> so 1 byte :)
<smoser> i stuck it at 1MB
<RAOF> Some multiple of the CPU page size would seem a reasonable default.
<sarnold> smoser: just a little birdie from the sidelines, but cloud-image update could probably also wait on this bug: 1060404
<ubottu> bug 1060404 in lxc (Ubuntu Precise) "update-grub runs and fails in containers" [High,Triaged] https://launchpad.net/bugs/1060404
<sarnold> smoser: juju in lxc containers on precise has been useless for a few weeks due to that one...
<sarnold> or, rather, juju in lxc containers with precise ...
<smoser> sarnold, i'd love to have that fixed also, but is there actually a fix for it?
<sarnold> smoser: as I understand, cjwatson re-pushed the package again today
<smoser> precise is just "triaged"
<smoser> oh. wait. no
<smoser> oh. its still just "triaged" in lxc
<sarnold> .. and the lxc fix was a bad idea anyhow, soo..
<sarnold> since reproducing this specific problem is so easy, I'd happily do the verification for the juju folks :) but I haven't got a clue how to shove the fixed package into the image that it puts together. getting a fixed cloud-image seems to me like the far easier way to test it, but that's also way outside of my experience.
<sarnold> (afterall, if there were an easy way to shove commands into early juju instance creation, one could just throw in a pin package command..)
<sarnold> anyway, I feel better knowing it's also on your radar :)
<smoser> sarnold, well, actually your problem magically goes away if you get a new released build
<smoser> because lxc pulls the newer build
<smoser> which wont have the grub or linux image inside when 'apt-get update' is applied.
<sarnold> smoser: hrm, we're running into my lack of experience with juju :)
<sarnold> or lack of experience with lxc :)
<smoser> which is understandable. this stuff shoudl "just work"
<smoser> :)
<sarnold> hehe
<sarnold> smoser: is there an easy way to get the -proposed repository added before the .. charms? juju? cloud-init? .. runs apt-get upgrade?
<smoser> hm..
<smoser> you might be able to just hold grub and linux-image
<pitti> Good morning
<infinity> pitti: Hey, are you still involved in langpack-o-madness?
<pitti> infinity: yeah, together with dpm
<infinity> pitti: langpacks are the biggest offender for https://bugs.launchpad.net/launchpad/+bug/1078697
<ubottu> Ubuntu bug 1078697 in Launchpad itself "Ubuntu archive is missing SHA-1/SHA-256 hashes for some packages" [Low,Triaged]
<infinity> pitti: Are they still being generated on a hardy host/chroot?
<infinity> pitti: And is there any way that could be moved to >= lucid?
 * pitti checks
<pitti> infinity: urgh, indeed, hardy
<infinity> pitti: Kay.  And, since we're not doing point releases for << precise, there's no reason that couldn't be precise, right?
<pitti> infinity: sure, I can file an RT to upgrade it to precise, or just install a new one
<infinity> pitti: But at least lucid.
<pitti> I don't see why we couldn't build a hoary langpack on raring
<infinity> pitti: Getting it fixed before we land the final langpacks for precise.2 would be nice.
<pitti> the source.changes will have the extra checksums, but that doesn't appear anywhere
<pitti> infinity: well, I'm not root in that dchroot, so I can only RT; doing that now
<infinity> pitti: Ahh, if it's a chroot, at least it's probably simple to upgrade (or, indeed, just rebuild it as precise).
<pitti> infinity: RT sent
<pitti> with you CCed
<infinity> pitti: Danke.
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<geser> cjwatson: Hi, could you check what the migration script did to your copy of libimobiledevice from a few days ago? LP says that it got removed from from -proposed as it moved to release but there is no publishing entry for raring for it (raring has still the old version).
<tsdgeos> tkamppeter: is cups forward-port-cups-1-5-x-cups-browsing.patch planned to get upstream?
<pitti> tsdgeos: I think that already has been dropped, and replaced by cups-browsed
<tsdgeos> pitti: in raring you mean?
<pitti> yes
<tsdgeos> ah, tx
<tjaalton> cups-browsed is crashing constantly here
<tjaalton> every 25s
<tjaalton> bug 1098756
<ubottu> bug 1098756 in cups-filters (Ubuntu) "cups-browsed keeps respawning" [Undecided,New] https://launchpad.net/bugs/1098756
<pitti> tsdgeos: http://anonscm.debian.org/gitweb/?p=pkg-cups/cups.git;a=tree;f=debian/patches -> gone
<Daviey> cjwatson: Super, you did the grub2 .d support! Thank you!
<xnox> stgraber: infinity: so with su, it's not a bug it's a feature?!
<tkamppeter> tsdgeos, no, the patch is not intended to get forwarded upstream, as upstream has dropped the old CUPS-specific broadcasting/browsing protocol in favor the standardized Bonjour protocol, standardized by the Printing Working Group (www.pwg.org) for printing and standard for many other network services, like wireless screen forwarding from a mobile phone to a TV. The forward-port is also already removed from Raring. Raring does the comple
<tkamppeter> te broadcasting and browsing via Bonjour. For the browsing part I have written cups-browsed (part of the cups-filters upstream package), but print dialogs will also Bonjour-browse by themselves soon.
<tsdgeos> ok, people seems to wrongly be using the CUPS_SERVER_REMOTE_PRINTER in adminutil.h to create new code
<tsdgeos> devels that run ubuntu most probably :D
<pitti> tkamppeter: ah, so cups-browsed will also disappear eventually?
<infinity> xnox: It's potentially both a bug and a feature.
<tkamppeter> pitti, cups-browsed will probably not disappear so quickly. One must see how well print dialogs will do the job by themselves and when, and how many legacy apps will be around which are not able to broadcast by themselves.
<tkamppeter> pitti s/broadcast/browse/
<pitti> tkamppeter: I thought that mainly affects broadcasting printers to clients from cups servers to cups clients?
<pitti> tkamppeter: if that changes to bonjour, clients shouldn't even notice?
<pitti> tkamppeter: or is that for spooler-less operation, i. e. just with cups-client?
<tkamppeter> pitti, yes. Now CUPS servers broadcast printers via Bonjour, but CUPS daemons on clients do not browse for remote Bonjour printers.
<tkamppeter> pitti, cups-browsed does the browsing job for CUPS currently.
<pitti> tkamppeter: right, but why woudl applications be concerned about which protocol cups uses for discovery?
<tkamppeter> pitti, if print dialogs are able to browse by themselves, they would send these jobs directly to the remote CUPS daemon eliminating the need of a local CUPS daemon.
<pitti> tkamppeter: ah, so this is for spooler-less operation then
<tkamppeter> pitti, yes.
<pitti> but cups-browsed depends on cups
<pitti> which wouldn't be spooler-less any more then
<tkamppeter> pitti, cups-browsed needs cupsd as it creates local raw queues pointing to the discovered remote printers.
<pitti> tkamppeter: but if you are going to have cupsd installed anyway, that could just as well use bonjour for discovery?
<tkamppeter> pitti, this I do as current print dialogs only ask the local cupsd for available printers.
<pitti> right; and as long as the local cupsd says "that printer over --> there", it shouldn't matter much whether it was discovered through the old browsing protocol or DNSSD?
<tkamppeter> pitti, I do not patch the cupsd itself to do the Bonjour browsing as upstream would not accept it. Upstream expects print dialogs to browse, requiring us to wait for the inertia of big desktop projects and leaving us with a lot of legacy apps using old libs or individual dialogs and also not seeing the printers when using the command line.
<pitti> tkamppeter: ah, ok; I understand
<pitti> tkamppeter: FWIW, having print _dialogs_ do the browsing is absolutely the wrong thing
<OdyX> yes (I'm following the interesting discussion :p )
<infinity> tkamppeter: Are there plans to fix the constant crash/respawn cycles people are seeing?
<pitti> tkamppeter: oh, wait, I guess for "browse themselves" you just mean "ask avahi"
<infinity> tkamppeter: "upstart will restart it" is not a fix. :P
<pitti> not actually "send out a request to the network"
<cjwatson> Daviey: it was about time :)
<tkamppeter> pitti, yes for the end user it does not matter whether the printer info is conveyed via Bonjour or the old protocol. The Bonjour is even better as printers appear and disappear immediately and not only within 30 sec.
<cjwatson> geser: looks like it failed with
<cjwatson> 2013-01-14 11:25:15 INFO    Job:
<cjwatson> <PlainPackageCopyJob to copy package libimobiledevice from ubuntu/primary, PROPOSED pocket, in ubuntu raring to ubuntu/primary, RELEASE pocket, in ubuntu raring, including binaries>
<cjwatson> raised CannotCopy:
<cjwatson> libimobiledevice 1.1.4-1ubuntu3 in raring (binaries conflicting with the existing ones)
<cjwatson> geser: this is a known bug when copying from series with more architectures than raring - I should've known better than to copy that
<pitti> tkamppeter: right, so a new printer woudl send out a DNSSD message, avahi picks it up, and dialogs only ask avahi
<pitti> tkamppeter: that makes sense indeed
<cjwatson> geser: I'm going to do a no-change rebuild as the simplest fix for the time being
<tkamppeter> infinity, which crash/respawn cycles do you mean?
<cjwatson> geser: thanks for th report
<infinity> cjwatson: We're long past the point where we shouldn't be copying from previous releases anyway, aren't we?  In the name of building with current toolchains, etc.
<infinity> tkamppeter: https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1098756 for example.
<ubottu> Ubuntu bug 1098756 in cups-filters (Ubuntu) "cups-browsed keeps respawning" [Undecided,New]
<infinity> tkamppeter: Also, possibly unrelated, but the upload to quantal-proposed that adds an apport blacklist for cupsd crashing instead of fixing the crash?
<infinity> tkamppeter: That's just wrong on so many levels.
<infinity> tkamppeter: The claim that daemons crashing is "harmless" because upstart respawns them is... Wrong.
<cjwatson> infinity: arguably, I suppos
<cjwatson> e
<cjwatson> Though that's never scared me because it generally isn't a regression from the previous binaries also copied from the previous release ...
<infinity> cjwatson: (I realise the irony here, as I'm violating that on every single armadaxp and ti-omap4 kernel release right now)
<infinity> And even worse, I suspect the ones I'm copying absolutely would FTBFS in raring.
<infinity> But I'm told there's a 3.8 omap4 kernel coming soon.
<infinity> cjwatson: Anyhow, it's less about regression (though that sucks too), and more about new toolchain shiny.  Like, for instance, the binutils in raring has better ABI tagging for armhf that, once the whole world is rebuilt with it (you know, by 2016 or so), we can drop our awful ld.so hacks.
<cjwatson> Yeah
<tkamppeter> infinity, OdyX, pitti, the upstart script for cups-browsed needs to be modified that cups-browsed starts after avahi-daemon. Did someone of you already do this?
<pitti> start on (filesystem
<pitti>           and started avahi-daemon
<pitti>           and (started cups or runlevel [2345]))
<pitti> looks fine tome
<pitti> (space saving Thursday!)
<OdyX> tkamppeter: not me.
<tkamppeter> pitti, OdyX, I will do it today.
<tkamppeter> infinity, ^^
<pitti> tkamppeter: do what?
<pitti> tkamppeter: it already depends on avahi
<tkamppeter> infinity, about the cups package in quantal-proposed. I know that it is not the best solution to simply suppress the crash messages of cupsd, but the crashes are caused by the temporary forward-port patch for CUPS browsing. This patch is already removed in Raring.
<tkamppeter> pitti, add "and started avahi-daemon" to the cups-browsed startup script.
<infinity> tkamppeter: Yes, I read the changelog.  But if you know the cause, surely you can also fix it, rather than ignoring it.
<tkamppeter> infinity, unfortunately, I do not know the cause within the patch. The crash goes away when turning off browsing.
<tkamppeter> infinity, one thing I already observed is that the crash does not happen when printing but it happens during logrotate.
<tkamppeter> infinity, I could stabilize the logrotate by actually shutting down CUPS before, doing the logrotate, and afterwards starting it again. Currently, the logs get rotated under the running CUPS and after that CUPS gets HUPed.
<OdyX> tkamppeter: the depends on avahi-daemon is there already, in -1ubuntu2, I commented on the bug.
<tkamppeter> OdyX, OK, now I see, this one is not in Debian's BZR repo, so I did not see it.
<pitti> tkamppeter: I thought we moved to the git repo now?
<OdyX> pitti: cups, not cups-filters
<tkamppeter> pitti, got cups-filters also moved? I know that cups got moved.
<pitti> oh, sorry
<OdyX> I'd be more than happy to move cups-filters too. :)
<OdyX> every time I try to use bzr, I have to relearn it from scratch.
<pitti> I really miss bzr bd-do from git-buildpackage, otherwise it's working fairly nicely
<OdyX> what does that do ?
<OdyX> nah, found it.
<pitti> OdyX: it fetches the orig.tar.gz (from pristine-tar, the archive, uscan, or get-orig-source), and puts you into a temporary build tree with the orig unpacked, the debian/ bits copied, and patches applied
<pitti> you can hack in it, then exit, and the debian/ changes get copied back
<pitti> I also use it to build Debian packages
<pitti> bzr bd-do, dchroot, dpkg-buildpackge, exit 1
<OdyX> well, with git, quilt push -a gives you that. :)
<pitti> with git I do git-buildpackage -S -us -uc, cd ../build-area, dpkg-source -x, dchroot, build
<pitti> so that's not so bad; I miss it more for doing experimental changes, and testing them in the temp dir without cluttering my checkout; but again, no biggie
<pitti> oh, we are again down to two ppc builders?
<pitti> poor yellow
<tkamppeter> pitti, are PPC processors still produced? Can you buy any device new with a PPC processor in it?
<cjwatson> tkamppeter: yes, and we just did - infinity is working on getting it up and running as a builder at the moment
<pitti> nice!
<tkamppeter> cjwatson, which device?
<cjwatson> I don't know, some big beast :)
<cjwatson> pitti: yellow was amd64, iirc ...
<cjwatson> itym sulfur?
<pitti> oh right, which one am I thinking of -- the old live image builder
<pitti> right, that was it
<pitti> cjwatson: well, it's also kind of yellow :)
 * pitti wonders where in the periodic table of elements we are, and what we do after nobelium
<pitti> oh, it already exists
<infinity> cjwatson: For the record, linux-ppc built on sagari in 51m.
<infinity> cjwatson: (That takes 13.5h on ross)
<pitti> even ununoctium.canonical.com exists already
<cjwatson> infinity: nice
<cjwatson> pitti: we stopped using elements some time ago
<pitti> oh, even duranium and trilithium exist :)
<infinity> pitti: I'm working on hunting a tg3 bug with the adapter in this machine (not PPC-specific, just specific to this silicon revision of tg3, I suspect), but otherwise it''ll be good to go soon.
<infinity> pitti: If I can't sort the tg3 bug $soon, I may just toss an e1000e in there and let 'er rip.
<pitti> cjwatson: yeah, seems we clearly need more Star Trek episodes that introduce new elements
<cjwatson> pitti: Since elements, we've done Arabic star names and we're now on legendary creatures
<cjwatson> pitti: https://wiki.canonical.com/InformationInfrastructure/SA/MachineNames
<infinity> (I do wonder why every single tg3 silicon revision seems to quirk the crap out of he driver and require two years of bugfixing to work correctly)
<infinity> cjwatson: Didn't you miss fruit in there somewhere?
<cjwatson> infinity: oh yes
<cousteau> ok, so the nvidia-96 package is finally installable in Precise?
<cousteau> tjaalton, you were the one uploading it to precise-updates, right?
<tjaalton> cousteau: yes+
<tjaalton> ?
<tkamppeter> OdyX, infinity, pitti, seems that upstart does not do what it is asked for, see bug 1098756, last comment.
<ubottu> bug 1098756 in cups-filters (Ubuntu) "cups-browsed keeps respawning" [Undecided,New] https://launchpad.net/bugs/1098756
<cousteau> just wanted to thank you  :)  ok, now nothing stops me from definitely upgrading to precise
<cousteau> by the way, can that driver be ported to quantal?  I don't think the nvidia-173 supports some legacy cards
<tjaalton> cousteau: no
<pitti> tkamppeter: perhaps avahi-daemon is crashing?
<tjaalton> avahi-daemon starts and runs fine if I start it manually
<tjaalton> but yeah, boot.log shows that it's started during boot too, but isn't running by the time I'm logged in to check
<cousteau> tjaalton, does that mean I won't be able to use my card on ubuntu versions quantal and newer with the drivers on repos?
<cousteau> (...well, maybe with nouveau)
<tjaalton> cousteau: only with nouveau
<cousteau> I'm seriously considering switching to nouveau...  wonder if there's a big performance difference
<tjaalton> I'd suggest you seriously consider a hw upgrade ;)
<cousteau> (I noticed some Firefox 3D things being faster with Nouveau than the Nvidia drivers)
<cousteau> tjaalton, no PCIe, only AGP.  The range of available cards is small.
<tjaalton> can'áº find any cards for agp that you can buy as new..
<tjaalton> the second hand market should have plenty
<cousteau> well, I found an Nvidia AGP for about 50â¬
<cjwatson> Anyone know Cython and fancy fixing the libimobiledevice build?  I have http://paste.ubuntu.com/1541130/ to deal with the multiarch Python failure, but then I run into a huge pile of Cython garbage.
<cjwatson> Seems not to be fixed upstream.
<geser> cjwatson: I just saw that libimobiledevice FTBFS due to multi-arched Python :( I will try to fix it over the weekend.
<cousteau> actually, both NVidia and Radeon for about the same price, 47â¬
<cjwatson> geser: Lovely, thanks
<cjwatson> The Cython failure seems to be unrelated to multiarching
<geser> I hope I have more success than you
<bdrung> infinity: re bug #633109, it can be seen as regression when going from a ftp to a sftp upload.
<ubottu> bug 633109 in dput (Ubuntu Precise) "No progress bar for sftp uploads" [Undecided,New] https://launchpad.net/bugs/633109
<cjwatson> geser: Looks rather like http://libiphone.lighthouseapp.com/projects/27916/tickets/285-cant-compile-cython-bindings FWIW
<ogra_> cjwatson, ogra@anubis:~/Desktop$ apt-file search types.h|grep /types.h|grep manpages
<ogra_> manpages-posix-dev: /usr/share/man/man7/types.h.7posix.gz
<cjwatson> hah :)
<cjwatson> follow up then
<ogra_> ;)
<cjwatson> looks like I don't have manpages-posix-dev installed here
<cjwatson> mostly if I want posix I use the website
<ogra_> i didnt either, but it seeems to be what he wants now that i looked at it
<cjwatson> well, it will document what POSIX guarantees you get from <sys/types.h>, rather than what Ubuntu gives you
<cjwatson> Which is not quite the same - sometimes people want the extensions
<cjwatson> For example it won't document the LFS/file-offset-bits=64 mess
<ogra_> oh, right
<tkamppeter> pitti, so I should perhaps move the bug on to avahi-damon, as it seems to not stay stably running?
<pitti> tkamppeter: that shoudl be verified first, though
<OdyX> also, cups-browsed must not crash if avahi disappears, but handle the situation gracefully IMHO.
<tkamppeter> OdyX, AFAIR it does not crash, it does "exit 1". Perhaps I should add a wait loop, so that it stays running but starts working when avahi-daemon appears.
<mlankhorst> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mlankhorst
<ev> pitti: shall I give you a ring?
<ev> :
<ev> whoops
<pitti> ev: hangout?
<ev> sure
<pitti> or mumble, etc.
<pitti> ev: first time I try hangout with didrocks' sound fix, let's see whether it works
<ev> pitti: you should have an invite
<pitti> ev: I do, just firefox says the connection has been interrupted
<pitti> argh
<pitti> ev: *hrmpf*
<ev> I've got a desk phone right here, POTS is pretty stable tech
<ev> shall I just give you a ring?
<pitti> ev: it has an abysmally low audio quality, but I guess everything is better than total silence :)
<davmor2> pitti, ev: you should try the canonical sip service it tends to work pretty well in sofiasip from quantal on in empathy
<smb> slangasek, After I had a masochistic moment I tried my luck a bit on some multi-arch conversion, I am now at a point where I think I could be ok with one of the created binary sub-packages. But some others seem hard since I struggle with multiple layers of autoconfig'ish things. Would it be acceptable to go with that stage and do the rest later?
<mpt> pitti, ev: So far in the "worth showing" box we had evolution-data-server and compiz-gnome, and in the "not worth showing" box we had lsb-release and update-notifier.
<pitti> mpt: lsb-release on its own is not really meaningful indeed, but it seemed to have caused a problem in firefox
<pitti> (by not working as intended)
<pitti> mpt: but still, in terms of reporting I agree to "batch mode" for it
<mpt> pitti, the question is, can we expect Firefox to explain the error itself (or to crash and produce an application crash error).
<mpt> If so, there's no point showing it separately.
<pitti> mpt: even if not, I doubt telling the user about lsb_release will be useful to explain what happend in firefox
<mpt> fair enough
<mitya57> barry, ScottK, doko_: I've just filed a python3-defaults MP (just letting you know so that you don't duplicate my work, but I'll be happy if someone reviewed it)
<mitya57> https://code.launchpad.net/~mitya57/ubuntu/raring/python3-defaults/resync/+merge/143697
<ScottK> mitya57: You could use sbuild or pbuilder to run the tests in a chroot.   A full VM is not needed.
<mitya57> ScottK: I've no idea how to do that, is there a script somewhere?
<ScottK> mitya57: pbuilder-dist in ubuntu-dev tools is probably the easiest.  pbuilder-dist raring create then pbuilder-dist raring login
<mitya57> ScottK: I'll try, thanks
<achiang> mlankhorst: hi, this merge of mine has been sitting since before xmas break, can you please take a look at it? (pinging you since you're marked as pilot, not because i think you know about remmina ;) https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/1093511
<ubottu> Ubuntu bug 1093511 in remmina (Ubuntu) "please merge remmina 1.0.0-4 (main) from Debian testing" [Wishlist,Confirmed]
<mlankhorst> sure, I'll take a look :)
<mlankhorst> the revu page in that bug report seems to be dead, 403 forbidden
<barry> mitya57, ScottK i'll take a look in a little while
<achiang> mlankhorst: damn, let me check
<achiang> mlankhorst: all of revu is down
<mlankhorst> achiang: are those diffs available from version control somewhere, or just those diffs?
<bluefoxxx> Gentlemen
<bluefoxxx> The installer is capable of utilizing LVM.
<bluefoxxx> Would it be outrageous to modify the installer such that it automatically partitions 0.25% of the LVM physical volume free, and recommends such if a user manually partitions with LVM?
<achiang> mlankhorst: just have the diffs, sorry
<bluefoxxx> sorry
<bluefoxxx> somethnig I am doing wrong.  10TB should give 250GB... 1TB should give 25GB or 0.025TB ... .1TB is 10%... .01TB ... so 2.5%
<mlankhorst> ah no worries, it's usually easier with version control, debian maintains it in git afaict, not sure about ubuntu
<bluefoxxx> I do not think that is unreasonable.
<bluefoxxx> in any case
<bluefoxxx> All partitions formatted in the LVM would be configured to be fscked once per 180 days
<achiang> mlankhorst: i can upload the *.dsc, etc. somewhere else
<bluefoxxx> once per week, each drive would be snapshotted onto the free space in the LVM PV
<bluefoxxx> the snapshot would be fscked
<bluefoxxx> if clean, then the volume would be marked as recently fscked
<bluefoxxx> i.e. tune2fs -T 0
<mlankhorst> achiang: no those are available, I'm just looking into the source repository atm :)
<bluefoxxx> otherwise an alert would be set and the drive scheduled for fsck.  The administrator could request read-only remount, online fsck.
<bluefoxxx> in this way, periodic fsck of clean file system could be accomplished without associated down time
<bluefoxxx> tune2fs -T now rather
<mlankhorst> achiang: overall looks ok to me, but I don't have any familiarity with remmina
<mlankhorst> achiang: also I don't have upload rights, so I can't actually sponsor the upload for you :(
<Laney> I'll take a look at remmina
<Laney> the two diffs are fine (infact, preferred) to sponsor it
<mlankhorst> thanks Laney
<achiang> Laney: mlankhorst thanks!
<dobey> can someone take a poke at my patch in bug #859600 ? i think it's better than the previously attached patches, but would be nice to get it reviewed/included
<ubottu> bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress] https://launchpad.net/bugs/859600
<dobey> (and pushed into debian if anyone could do so)
<hallyn> is it ever 'done' to have a 'README.Ubuntu' under debian/ ?  Or do we, if no README.Debian exists, create that?
<Laney> achiang: I think you need a Breaks/Replaces for remmina-common that used to contain the desktop file
<hallyn> i'll make README.Debian.  will need to suggest they ship it too, anyway
<slangasek> smb: if the binary package you have converted to multiarch is usefully installable by itself, then sure
<achiang> Laney: ah, interesting. ok, thanks
<Laney> perhaps just Breaks (to help the upgrade order)
<Laney> achiang: No need for you to update it - I'll do that before uploading
<achiang> Laney: great, thanks!
<highvoltage> where could I get an ubuntu phone image?
<Laney> http://www.ubuntu.com/static/u/img/devices/phone-home-industry-269x192.jpg
<Laney> </troll> - they aren't available yet but I heard late Feb (also #ubuntu-phone)
<highvoltage> Laney: ah ok
<xnox> highvoltage: pick your fancy from all of them http://www.ubuntu.com/static/u/img/devices/
 * xnox likes 
<xnox> http://www.ubuntu.com/static/u/img/devices/phone-app-hero-420x338.jpg
<arges> : )
<highvoltage> on a slightly related note. I reflashed my Atrix with Cyanogenmod and lost the default Ubuntu 9.04 installation that it came with. Where could I get Ubuntu for Android?
<xnox> highvoltage: there is no download yet.
<highvoltage> xnox: but it's been existing for so long!
<highvoltage> xnox: who's actually working on it? could I ask someone for an image?
 * xnox didn't know highvoltage is a phone manufacturer =)
 * highvoltage didn't know that you had to be in order to get ubuntu
<dobey> xnox: i've actually been pondering just making my own phone actually. :)
<stgraber> highvoltage: I can give you a tarball of the osh partition (the default 0.94 system) on my Atrix, mine didn't get wiped with the reflash
<highvoltage> stgraber: I'm going to try to follow http://fooprotected.wordpress.com/2012/04/02/debian-on-androidatrix-with-debootstrap/ to get a more recent version than 9.04 running. then at least I can share it for others who'd like to do the same
<stgraber> highvoltage: you won't be able to get a terribly recent userspace on the atrix because of the kernel version
<stgraber> highvoltage: 10.04 chroot/containers work pretty well here, but anything more recent was met with a lot of crashes because of missing/broken syscalls in the android kernel
<highvoltage> stgraber: ah right :-/
<smoser> slangasek, around ?
<smoser> who do i need to talk to to get bug 1100491 into -updates
<ubottu> bug 1100491 in cloud-init (Ubuntu) "[SRU] apt_sources broken in 0.6.3-0ubuntu1.3 [regression]" [Critical,Fix committed] https://launchpad.net/bugs/1100491
<smoser> its not sat for 7 days in -proposed, but we have a broken update in -updates and this fixes that.
 * cjwatson double-reviews
<cjwatson> smoser: I've waived the waiting period; it's on its way into -updates now.
<jamespage> \o/
<smoser> thank you.
<smoser> sorry for suck.
<smoser> utlemming, can you spin a precise-daily build once cloud-init 0.6.3-0ubuntu1.4 is in -updates ? the latest daily has the broken version and want to stop people from getting that even if they're using dailies.
<roaksoax> cjwatson: howdy!! I was wondering if you could take a look to: bug #1092265
<ubottu> bug 1092265 in MAAS "Nodes fail to boot from local disk on raring" [Critical,Triaged] https://launchpad.net/bugs/1092265
<roaksoax> thihs is really an issue with syslinux
<cjwatson> roaksoax: sorry, pretty overloaded
<cjwatson> roaksoax: as you can see we've got back in sync with Debian so I haven't actually touched syslinux in some time anyway
<roaksoax> cjwatson: ack! thanks though :)
<cjwatson> I'd probably suggest starting by looking through changes to chain.c32's source in upstream git
<roaksoax> cjwatson: will do! thanks! :)
<cjwatson> though chain has hardly changed in quite a whwile
<smb> slangasek, I guess, though I would need to throw it over the fence to someone else who has an environment for using that. Though basically it is only one subpackage that only provides libraries (and has done before). Its less clear with some language interface package which then have a perl/ruby/python binding plus an .so part. So following thatis it enough to not have any multi-arch keywords on the other packages in the control file to say tho
<smb> se aren't ready (yet)
<roaksoax> yeah /win 13
<roaksoax> err
<mlankhorst> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<mcclurmc> hi infinity. i submitted a but report and a patch this morning for indicator-weather: https://bugs.launchpad.net/indicator-weather/+bug/1100680
<ubottu> Ubuntu bug 1100680 in Indicator-weather "indicator-weather on Quantal throws exception when adding location" [Undecided,New]
<mcclurmc> any chance this could get looked at?
<slangasek> smb: can you point me at specifics?
<smb> slangasek, I can. Though I think it also makes sense to take this into email where I can add a bit more info. But I think I won't get to that till tomorrow.
<slangasek> smb: ok :)
<bjf> slangasek, i had the following line in my /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT=initcall_debug quiet printk.time=1
<bjf> slangasek, because of that, i was getting failures in /usr/sbin/grub-mkconfig:  /etc/default/grub: quiet: not found
<bjf> slangasek, this was preventing an update of the kernel package. i changed it to just "GRUB_CMDLINE_LINUX_DEFAULT= quiet"
<bjf> slangasek, that fixed my issue
<cjwatson> bjf: You need to quote that
<cjwatson> GRUB_CMDLINE_LINUX_DEFAULT="initcall_debug quiet printk.time=1"
<bjf> cjwatson, ah!
<bjf> cjwatson, thanks
<cjwatson> de nada
<infinity> mcclurmc: I can have a poke.
<mcclurmc> thanks infinity. it's nothing critical, but it'd be good to get it merged
<bdmurray> tkamppeter_: the cups upload in the quantal -proposed queue will prevent all apport crash reports regarding cups which seems rather heavy handed
<BenC> cjwatson: I'm not sure where it needs to go, but msdos is the default filesystem for the e500* systems (right now, it claims ignorance)
<BenC> s/filesystem/partition-map/
<infinity> BenC: That's true for IBM machines too.  Is there some broken assumption somewhere?
<BenC> infinity: the installer just says "we don't know what to do, so you guess and if it's wrong, well then, it's not my fault"
<BenC> It's not that I can't select it on my own, just wondering where to stick in a default for reasons
<BenC> e500* doesn't match powermac/pseries, which I believe are the only two sub-archs it knows about partition-wise
<BenC> and of course ps3, but that's not really in existence anymore
<infinity> BenC: Does archdetect already know about your machine?
<BenC> Yeah, it selects the correct kernel
<infinity> BenC: So, it's just a question of partman-$whatever getting smarter?
<BenC> Right, whatever udeb devices on the default partition map
<BenC> *decides
<infinity> BenC: Any idea what the exact string is? :P
<infinity> (The error string)
<BenC> One moment while I look that up for you sir...
<BenC> My fiancÃ©'s customer service job is rubbing off on my online etiquette
<infinity> Oh, think I may have found it.
<infinity> BenC: What does archdetect return on your two platforms?
<BenC> One other bug I have is that the cdrom-detect isn't detecting things too well in qemu with a media=cdrom virtio-blk device
<BenC> infinity: e500mc and e500 as subarch
<infinity> Did you really need two, you greedy, greedy man? :P
<BenC> infinity: Actually, nm, it's not
<BenC> Showing powerpc/unknown
<infinity> Oh.  Right, then fix archdetect first.
<infinity> Since everything else keys off that.
<BenC> infinity: I might just make it powerpc/sgy
<BenC> Since a lot of stuff is specific to our system (grub, partition map)
<infinity> BenC: Once archdetect does something sane (FSVO sane), your partition map type fix would be in lib/disk-label.sh in partman-partitioning
<BenC> infinity: Thanks
<infinity> BenC: Feel free to fix yourself, but ping someone (like me, Colin, or xnox) perhaps for a quickie review, and see about getting it committed upstream too (which at least two of us can do, maybe all three of us)
<xnox> all three =)
<infinity> BenC: On a side note, MSDOS, really?  On a brand new platform, why not go GPT from the start and future-proof for larger disks?
<infinity> (Or would that have required adding GPT support to u-boot?)
<BenC> infinity: It will work with GPTâ¦doesn't bother me any at all
<BenC> No, just enabling it in our firmware linux-kernel
<infinity> BenC: Just a suggestion, since sticking some future developer (or yourself) with remembering all the places where msdos is hardcoded the day you decide to ship systems with >2TB drives could be irksome. :)
<BenC> infinity: I don't see GPT in linux's partition map selection
<BenC> LDM, OSF, KARMA?
<infinity> BenC: Given that it's default on ia64 and EFI systems, I can only assume the kernel supports it a little bit...
<infinity> Though, no idea what CONFIG_ twiddle makes it happen.
<infinity> Oh, actually, partman just silently forces gpt over msdos on large disks anyway.
<infinity> I guess we assume all OUR kernels and bootloaders can deal with that.
<infinity> (Which I'm betting not all of them can... I know the openfirmware on one of my machines sure can't)
<BenC> infinity: it's EFI, supports GUID GPT partitions
<BenC> I already have that enabled in our firmware kernel, so I'll use that as default on installer
<infinity> BenC: You may want to double-check that all works with a manual install/reboot cycle on GPT before committing, but it just makes sense to me to future-proof the platform now rather than panic later when someone ships a big disk/array/whatever.
<BenC> Makes more sense to me too
<BenC> infinity: I just added two lines to the map_platform[] array to produce powerpc/fsl which will work on bare metal and qemu on this platform
<BenC> Ok to upload that?
<infinity> BenC: debdiff *dsc | pastebinit -f diff
<infinity> BenC: Just to have a quick look for myself.  Also, "fsl" makes it sound freescale-generic, which is probably a lie, no?
<BenC> http://paste.ubuntu.com/1542331/
<infinity> (Given that PegasOS and others are also freescale)
<BenC> infinity: They won't match at this point though
<BenC> I just can't make it servergy specific, because it works in qemu, and that has a generic /proc/cpuinfo
<infinity> Yeah, fair enough.  Go nuts.
<BenC> I'm going on making it generic and if some freescale based platform needs something more specific, they will need to add the extra bits
<infinity> BenC: Well, I assume that first one is your hardware specifically, and the second is generic, right?
<BenC> Right
<BenC> Actually, no
<infinity> BenC: You could follow the chrp/chrp_ibm example and have fsl/fsl_sgy and just make them both do the same thing for now.
<BenC> P4080 DS is generic fsl platform
<infinity> Oh, they're both generic?  Kay.
<BenC> I'd have to detect also the model to get down to something servergy specific
<infinity> I guess if you're the only ones that match this for now, that works.
<BenC> platform	: P4080 DS
<BenC> model		: servergy,jade-rev3
<infinity> Just might need some re-engineering if someone else bases a wildly different platform on the same chip later, I guess.
<BenC> Which at this point is an unknown, so I'll hope that we set the standard for anyone else coming along :)
<BenC> infinity: http://paste.ubuntu.com/1542349/
<BenC> Now to figure out why cdrom-detect chokes on virtio-blk cdroms
<infinity> BenC: Both those diffs look fine, then.  Assuming you've done a manual test and your platform actually boots. ;)
<BenC> infinity: It doesâ¦even if I broke it to high-hell, no one would notice but me at this point :)
<infinity> Heh.
<jbicha_> cjwatson: can we drop the pcsc-lite diff now? http://bugs.debian.org/531592 has been marked fixed for a while
<ubottu> Debian bug 531592 in libpcsclite1 "libpcsclite1: move to /lib" [Normal,Fixed]
<cjwatson> jbicha_: I disagree with their solution
<cjwatson> jbicha_: It means that if you have /usr as a separate partition then you get random behaviour depending on whether wpa_supplicant happens to try to start before or after /usr
<Logan_> Laney: Gah, so sorry. I'm running a test build of the ghc from Experimental right now, as, after attempting a merge, I found that the only delta (an Ubuntu patch) was applied upstream. If it builds successfully (and installs successfully, of course!), I'll file a sync request and link to it in the haskell-devscripts merge.
<cjwatson> jbicha_: Once https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-usr-merge is implemented then it can be dropped; I don't think it should be dropped before then
<Logan_> micahg: and my apologies to you as well
<jbicha_> I didn't think we supported /usr on a separate partition, thanks for looking at it though
<cjwatson> We always hav
<cjwatson> e
<cjwatson> Or at least have tried to
<cjwatson> usr-merge will certainly make life simpler but I don't think we should knowingly break stuff in advance of it landing
<infinity> cjwatson: I suppose that whole spec doesn't need implementing for people to stop caring, just the initramfs early-usr-mounting bit.  I should review a bunch of the competing bits in the BTS for that and commit something sane to Debian git and raring.
<cjwatson> Indeed
<cjwatson> The symlink farm stuff is rather riskier
<cjwatson> (And I think a bit scary, actually)
<micahg> Logan_: well, we try to do the ghc merge/world rebuild just once per cycle if we can get away with, so, you probably want to coordinate with Laney on that
<cjwatson> infinity: doesn't bug 1065827 need a precise task?
<ubottu> bug 1065827 in casper (Ubuntu Quantal) "Kubuntu 12.10 bcmwl install failure" [Critical,Fix released] https://launchpad.net/bugs/1065827
<cjwatson> infinity: (just for bcmwl, not for casper)
<infinity> cjwatson: Oh, indeed.
<infinity> cjwatson: I was so excited that the package otherwise passed my review on this round, I forgot to check all the bug tasks.  Fixed now.
<tion> will new xorg and nvidia-current updates break opengl on my box? i have nvidia FX5200 card. Currently I'm using the 173 driver and opengl is working fine
<xnox> mlankhorst: tjaalton: see tion ^
<xnox> not sure who does nvidia though.
<tion> i installed the current driver before. opengl was broken so i reinstalled the 173 driver should i skip the updates?
<mlankhorst> not that I'm aware of?
<tjaalton> tion: on what? the update adds support for xserver 1.13, so unless you're on precise you haven't actually used the driver AIUI
<dkessel> hey guys. i'm having graphics flickering in the dash since today on raring. i have this card: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML
<dkessel> can i do anything to help debug?
<tjaalton> dkessel:
<tjaalton> http://wiki.ubuntu.com/X/Testing/IntelSNA
<tjaalton> check if you see it with sna
<dkessel> tjaalton: ok, will do :) thanks
<tjaalton> dkessel: actually, check your xorg logfile
<tjaalton> nevermind
<dkessel> tjaalton, shall i try the xorg.conf from the wiki or not?
<tjaalton> yes
<infinity> Ooo, new xserver-xorg-video-intel?  I wonder how this can break my laptop today. :)
<tjaalton> probably does nothing much :)
<bdmurray> hallyn: I think the testcase in bug 1096771 is not for that bug
<ubottu> bug 1096771 in libcgroup (Ubuntu Quantal) "cgroup-bin (deleted) init scripts stick around" [High,Triaged] https://launchpad.net/bugs/1096771
<infinity> tjaalton: So, won't fix my hang?  Sadface.
<infinity> BenC: Oh, BTW.  Too lazy to commit to git for a minor fix.  You're missing a build-dep on openssl in linux-ppc.
<infinity> BenC: This'll become painfully obvious when I remove openssl from the buildd chroots, since it's not meant to be there. :P
<infinity> BenC: (You might want to compare your build-dep line with master, didn't bother to see if you're otherwise in sync)
<hallyn> bdmurray: why?
<dkessel> tjaalton, still flickering. xorg.log says: (II) intel(0): SNA initialized with gen3 backend
<tjaalton> infinity: I doubt it, but it has ~90 sna related commits
<tjaalton> dkessel: and you're on raring?
<hallyn> bdmurray: the bug is that when libcgroup gets updated, its initscripts are not properly removed.
<dkessel> yup, raring
<hallyn> so the test is to reinstall the version with initscripts, upgrade to the testing version, and check whether they were removed
<tjaalton> dkessel: ok, so please file a bug with 'ubuntu-bug xorg'
<tjaalton> dkessel: first verify you have xdiagnose installed
<dkessel> tjaalton: ok thanks
<hallyn> though i'd believe that i was saying or doing something stupid...
<tjaalton> dkessel: you ran raring before today too?
<tjaalton> dkessel: if you happen to have the old version of xserver-xorg-video-intel in /var/cache/apt/archives, mind giving it a go?
<dkessel> well, ony this machine only a few days. could be that i missed the flickering due to using terminal to install stuff and so..
<dkessel> tjaalton, sure, i can do... finishing the initial bug report first
<tjaalton> thanks
<dkessel> bug 1100970
<ubottu> bug 1100970 in xorg (Ubuntu) "transparent dash background flickers on intel graphics" [Undecided,New] https://launchpad.net/bugs/1100970
<dkessel> tjaalton, no old version there... bad luck
<tjaalton> dkessel: ok, and running i386 so none here either
<infinity> https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel/2:2.20.16-0ubuntu1
<infinity> https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel/2:2.20.17-0ubuntu1
<tjaalton> heh, thanks
<infinity> Poke one of those for a previous version to try.
 * xnox is puzzeled at https://launchpad.net/ubuntu/+source/openvswitch/1.9.0~git20130115.ca71f5b-0ubuntu2 FTBFS on powerpc, when it's no-code change upload.
<dkessel> hm, do i just dpkg -i one of those?
<dkessel> nevermind, i did :)
<dkessel> tjaalton, i tried .17, .16 and .9. nothing changes
<tjaalton> dkessel: ok, thanks
<infinity> xnox: Random bogons, or a build-dep broke?
<xnox> infinity: 1 test suite failure, and very cryptic. I could retry... to see what happens, but maybe when the build queue is smaller.
<infinity> xnox: The queue is only an hour.  Just give it a whack.
<dkessel> tjaalton, i'll leave it for today and turn off the machine. if there will be any more instructions added in the bug report, i will try it if i can. thanks so far
<tjaalton> dkessel: one more thing, did you have the xorg.conf there when testing the older versions?
<dkessel> oh... yes i still have it
<tjaalton> might try without it and post the results
<xnox> infinity: can you let me in on a secret of app-install-data-partner package?
<bdmurray> cyphermox: is bug 1055497 fixed in raring?
<ubottu> bug 1055497 in evolution (Ubuntu) "Signature inserted twice when replying or forwarding" [High,In progress] https://launchpad.net/bugs/1055497
<infinity> xnox: Which secret would that be?
<xnox> infinity: how to regenerate it. There is currently a UDD merge proposal for it.
<xnox> https://code.launchpad.net/~baltix/ubuntu/precise/app-install-data-partner/fix-for-missing-applications-flashplugin-skype/+merge/134402
<xnox> yet it removed ~ubuntu-core-dev/app-install-data-commercial/trunk from the vcs-bzr field.
<infinity> xnox: Ahh, hrm.  To be fair, I'm not hugely familiar with the inner workings.  mvo might be a better person to review that.
<BenC> infinity: Ok
<BenC> infinity: What is it that detects the kernel flavor to use in the installer? I need to make sure it wasn't expecting powerpc/unknown
<xnox> well pitti did some work on it as well.
<xnox> pitti: how does one work with app-install-data-partner?
<infinity> BenC: base-installer.
<BenC> Thanks
<infinity> BenC: But it does it based on cpuinfo.
<BenC> I seem to remember it calling archdetect
<BenC> But I could be misremembering
<infinity> Err.  Not cpuinfo as in /proc/cpuinfo, though...
<BenC> You're correct though, it uses /proc/cpuinfo
<BenC> SUBARCH="$(archdetect)"
<BenC> SUBARCH="${SUBARCH#*/}"
<infinity> Oh, yeah, it's /proc/cpuinfo.
<BenC> Well, sort of
<infinity> archdetect for subarch, yeah.
<infinity> But you're ignoring that right now.
<BenC> For kernel selection, it needs to use /proc/cpuinfo regardless
<BenC> Right
<jackyalcine> Where do I go to diagonise problems with Launchpad and PPAs?
 * jackyalcine checks #launchpad in the meanwhile
<Laney> #launchpad
<cyphermox> bdmurray: yeah, bug 1055497 is fixed in raring
<ubottu> bug 1055497 in evolution (Ubuntu) "Signature inserted twice when replying or forwarding" [High,In progress] https://launchpad.net/bugs/1055497
<jackyalcine> Thanks Laney, but you know of a mailing list I can use?
<cjwatson> BenC: kernel selection should at least *involve* the output of archdetect, even if sometimes refined by cpuinfo
<BenC> cjwatson: it uses the powerpc part, but not the /* part
<BenC> It's completely irrelevantâ¦if the CPU is e500 or e500mc, it has to use those kernels
<cjwatson> oh, e500/e500mc is irregular there
<cjwatson> anyway, I should've noticed the lack of support in libdebian-installer
<cjwatson> it would've been clearer to do things in terms of subarch and have *that* detected from cpuinfo, but no matter
#ubuntu-devel 2013-01-18
<tion> the updater is trying to install nvidia-current but my card is unsupported should i skip that update?
<bryce> tion, details?
<tion> the current drivers dont support FX5000 series
<bryce> tion, explain more what you're trying to do
<tion> i had to revert back to 173 v driver to get OGL support back
<tion> now updater is pushing nvidia-current again along with xorg updates
<bryce> tion, keep on going
<tion> the updater is trying to install nvidia-current but my card is unsupported should i skip that update?
<tion> are you just making conversation?
<bryce> tion, no
<tion> http://www.ubuntuupdates.org/package/ubuntu-x-swat/precise/main/base/nvidia-current?id=436581&page=3
<tion> it reads that only 6 gen and up are supported
<bryce> that's true
<infinity> xnox: Your nagios-plugins merge is dragging in a ton of new Perl modules.
<tion> i cant update im f***
<infinity> xnox: Not that I mind.  I <3 Perl and all.  But MIRs, please.  Or drop the deps.  Whichever.
<bryce> tion, I'd need to know more to give you a proper answer.  Like how did you install -173, what version(s) you had installed previously, what version of ubuntu you're running, etc.
<bryce> tion, with so little info all I can guess is if it's offering to move you to an incompatible driver, maybe you manually installed nvidia and your system's broken.
<tion> i installed 173 from the hardware icon
<infinity> tion: On which release?
<tion> 12
<infinity> 12.04 or 12.10?
<tion> lms
<bryce> tion, and now the updater is saying it wants to uninstall -173 and move you to -304?
<tion> after i installed nvidia-current that actually updated to V 3xx and i lost OGL support
<tion> then a reinstalled 137 again res was 640.480
<bryce> tion, 137??
<infinity> bryce: So, there is a need to update nvidia-173 in precise to support xserver-xorg-lts-quantal, possibly.
<tion> now OPG is working
<infinity> bryce: Not that I have any idea if that relates to whatever's being reported here.
<bryce> infinity, that's #1064192
<tion> the problem is nvida current install the wrong version and i lose OGL support
<bryce> infinity, I'm guessing tion didn't upgrade his xserver though, so precise's -173 should still work
<tion> so i have to spik the updates ?
<tion> upodater is tring to push
<infinity> Nothing should be trying to force nvidia-current on your if it wasn't previously installed...
<infinity> s/your/you/
<bryce> tion, maybe, but if it's offering to put something broken on your system, it should not be doing that
<tion> infinity, it was installed and later removed
<bryce> tion, do I understand you had -nvidia-173 installed, then you installed nvidia-current, and then again installed nvidia-173?
<tion> yes
<bryce> so you have both nvidia-current and nvidia-173 installed?
<tion> no
<bryce> so then it is offering to install nvidia-current and uninstall nvidia-173?
<infinity> dpkg -l nvidia\* | pastebinit -f diff
<tion>  GL_VERSION:  2.1.2 NVIDIA 173.14.35
<tion>   GL_VENDOR:   NVIDIA Corporation
<tion>   GL_RENDERER: GeForce FX 5200/AGP/SSE/3DNOW!
<infinity> Err, without the -f diff.  Finger habit.
<infinity> Not that it matters either way. :P
<infinity> tion: Can you paste the output of "dpkg -l nvidia\*" somewhere?
<bryce> tion, do you have any ppa's installed?
<tion> no
<tion> infinity, see pm
<infinity> tion: "ii  nvidia-current      295.40-0ubuntu1.1" clearly shows you have nvidia-current installed.
<tion> Find obsolete NVIDIA drivers
<infinity> If you don't want update-manager trying to upgrade it, just remove it.
<tion>   nvidia-173-updates  173.14.35-0ubuntu0. NVIDIA binary Xorg driver, kernel module and VDPAU lib
<tion> are both drivers working at the same time?
<tion> WTF!
<bryce> tion, you can have both installed but only one "activated", however it's better to just have the one you need installed
<tion> both say kernel module
<tion> wich is the one actually working right now?
<bryce> tion, I would purge all nvidia-*, then reboot onto nouveau and install only nvidia-173.
<bryce> tion, lsmod | grep nv
<tion> nvidia               7098356  24 ????
<infinity> "modinfo nvidia" is probably more likely to point you at a path that tells you which one you've built.
<tion> what are the numbers?
<infinity> But yeah, just removing the whole lot seems saner.
<bryce> tion, yeah try modinfo nvidia, or check dmesg.
<tion> ERROR: modinfo: could not find module nvidia
<infinity> Cute.
<tion> OpenGL version string: 2.1.2 NVIDIA 173.14.35 this is the one driver
<bryce> that's the mesa driver
<tion> thats actually in use
<tion> what mesa driver?
<bryce> no, that's the mesa driver in use, not the kernel module
<bryce> well, I mean the OpenGL driver
<bryce> tion, https://wiki.ubuntu.com/X/Troubleshooting/VideoDriverDetection#Problem:__Need_to_fully_remove_-nvidia_and_reinstall_-nouveau_from_scratch
<tion> only novou driver supports the new X server?
<tion> will 173 still work after updates?
<bryce> which new X server?
<bryce> as long as you're not moving to the Q-series xserver you should be fine
<pitti> good morning
<pitti> xnox: a-i-d-parner> I thought it was merely a collection of .desktop files for software-center to pick up?
<pitti> xnox: so if "work with" means "extend", I guess add a .desktop file there, and verify that s-c shows it and is able to install it; the package must be in the partner repo, of course
<dholbach> good morning
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * dholbach hugs infinity
<Kredo> hi guys, need help: Device /dev/ttyUSB0 is locked (I locked it with pon) - can I send/rcv sms while this gsm modem is connected to the internet? thanks
<xnox> pitti: ok. thanks.
<xnox> infinity: yeah, noticed. i'll drop stuff instead.
<xnox> infinity: openvswitch indeed had cosmic rays on powerpc, built fine after a whack.
<infinity> xnox: Good deal.
<xnox> infinity: also uploaded nagios-plugins which should stop dragging stuff in.
<infinity> xnox: I swear, if we had the hardware resources, I'd build everything twice, and only accept the binaries after proving the output is the same in both runs.
<xnox> =)))))))))))
<infinity> xnox: I don't really want to know (I really don't) how many subtle bugs in any given piece of software (ours or anyone's, really) is due to random bitflips.
<xnox> a modern cpu makes something like 10 000 mistakes a minute =/ to me it's magical any of it actually works =)
<infinity> Probably another argument against "make world" proponents, actually.  At least we can do targetted fixes if we find something needs a rebuild, they're just throwing it all back at the wall and fixing A while potentially breaking B, C, or D.
<rperier> hey, I upgraded this morning to 12.10 (from 12.04) everything works fine, just one problem: I have an intel 4000HD ivybridge and I am running VESA VGA :O
<rperier> cat /proc/fb  --> 0 VESA VGA
<mitya57> pitti: it fails to _build_?
<pitti> mitya57: yes, in:
<pitti> ln -sf -python3.3m-config \
<pitti> debian/libpython3-dev/usr/bin/-python3m-config
<pitti> the extra -
<rperier> I was using the wrong kernel (the one backported from quantal to precise and the real kernel from quantal was not used), it works fine now ^^
<jodh> chrisccoulson: hi - I'm looking at how gnome-session currently shuts down and trying to understand why the following is commented out: http://paste.ubuntu.com/1544640/
<mitya57> hm, it built successfully for me both locally and in ppa:mitya57/test1
<chrisccoulson> jodh, IIRC it was to stop gnome-session from swallowing those signals so we got crash reports with apport
<chrisccoulson> but this was a long time ago ;)
<jodh> chrisccoulson: ok, thanks.
<chrisccoulson> jodh, technically, i think only the call to gdm_signal_handler_add_fatal() needs to be commented out
<chrisccoulson> i can't remember why we disabled all signal handling
<chrisccoulson> i've slept and drank beer since then ;)
<pitti> chrisccoulson: or perhaps a merge error? in the original patch the commented out section might only have been for SIGSEGV, and in newer upstream versions the SIGTERMs got added?
<mitya57> pitti: seems like your $(DEB_HOST_GNU_TYPE) is empty for some reason
<chrisccoulson> pitti, yeah, you're right
<chrisccoulson> the original patch was http://bazaar.launchpad.net/~ubuntu-desktop/gnome-session/ubuntu/revision/18
<chrisccoulson> jodh ^^
<mitya57> should be set by dpkg-architecture
<chrisccoulson> it got changed here by seb128: http://bazaar.launchpad.net/~ubuntu-desktop/gnome-session/ubuntu/revision/233
<chrisccoulson> not sure why ;)
<pitti> that doesn't look intended
<chrisccoulson> jodh, so, the short summary is - the patch is only meant to disable the SEGV handler ;)
<infinity> mitya57: Which package is this you're talking about?
<pitti> https://code.launchpad.net/~mitya57/ubuntu/raring/python3-defaults/resync/+merge/143697
<infinity> Yeah, I just hunted that down from /lastlog
<infinity> pitti: I'm kinda with mitya57 on this one.  What's breaking your environment? :P
<infinity> pitti: DEB_HOST_MULTIARCH is set in debian/rules...
<pitti> je ne sais pas; I'll run it again and log in after the failure
<mitya57> man dpkg-architecture suggests me to add something like this:
<mitya57> DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
<infinity> mitya57: Why?  You don't need GNU_TYPE.
<infinity> Oh!
<infinity> You do.
<infinity> Wait, how did this work?
<infinity> I assumed it was using DEB_HOST_MULTIARCH, which is set.
 * mitya57 looks at his build log
<pitti> $ dpkg-architecture  -qDEB_HOST_GNU_TYPE
<pitti> x86_64-linux-gnu
<pitti> in my VM
<infinity> pitti: Yeah.  This is clearly a bug in debian/rules, I hadn't read far enough.
<infinity> But I'm not confused as heck that this works anywhere. :P
<xnox> mitya57: include /usr/share/dpkg/architecture.mk
<xnox> and then _all_ DEB_(BUILD|HOST)_* vars become available to you =)
<xnox> it's much cleaner that way.
<mitya57> xnox: thanks a lot, I like that much better
<xnox> unless pbuilder is being funny inside adt.
<infinity> xnox: No, it's the package that's buggy, not the environment.
<xnox> infinity: ok.
<infinity> But I'm still mind-numbingly confused that this worked on a buildd.
<pitti> mitya57: please feel free to ping me when I should give it another go
<jodh> chrisccoulson/pitti: thanks - bug 1101154 raised.
<ubottu> bug 1101154 in gnome-session (Ubuntu) "all signal handlers have been removed in error" [Undecided,New] https://launchpad.net/bugs/1101154
<mitya57> pitti: I've updated the branch, please test if it builds for you now
<infinity> Oh, wait.
<infinity> pitti: Does your environment call debian/rules targets raw instead of using dpkg-buildpackage?
<infinity> (Not that that's a bad thing if it does, cause that's meant to work)
<infinity> Looks like dpkg-buildpackage has started exporting dpkg-architecture's variables to builds.  I wonder when that happened?
<infinity> But that's why it doesn't fail on buildds.
<infinity> Despite the package clearly being broken.
<pitti> infinity: indeed, it seems autopkgtest does that; dear Ian, why didn't you use dpkg-buildpackage?
<infinity> pitti: Perhaps because he wanted packages to be policy-compliant?
<pitti> opts.user_wrap(opts.gainroot+' debian/rules binary'),
<infinity> pitti: You did just find a bug after all. :)
<pitti> well, yes, but frankly that shouldn't be a bug
<pitti> if dpkg exports those for you, then it seems redundant to fix each and every debian/rules files to include them again
<infinity> It *is* a bug.  But not a particularly critical one, no.
<infinity> debian/rules targets are meant to work all by themselves without wrappers, however.
<infinity> And it's a bug when they don't.
<infinity> Still, if a-d-t is meant to replicate what a buildd does, dpkg-buildpackage -B/-b is probably saner.
<pitti> mitya57: so it builds now, but one of the tests fails; hang on, running interactively again
<infinity> Still, if a-d-t is meant to replicate what a buildd does, ('dpkg-buildpackage -b -r'+opts.gainroot) is probably saner.
<infinity> Err, assuming gainroot is what I think it is.
<infinity> (either sudo or fakeroot)
<pitti> right, that
<infinity> Oh, and a -uc -us on that commandline, so it doesn't vomit when you have no PGP key. :P
<infinity> Oh, unless there was a reason he was splitting build and binary targets, maybe?
<infinity> To allow for certain trickery?
<infinity> So one can test in between targets, maybe...
<pitti> mitya57: I get
<pitti> dpkg-checkbuilddeps: Unmet build dependencies: python-all
<pitti> mitya57: and indeed debian/tests/control does not require this
<pitti> mitya57: and once I install python-all, it fails with http://paste.ubuntu.com/1544820/
<mitya57> pitti: thanks, will look now
<chrisccoulson> jodh, thanks
<mitya57> pitti: can you please paste the full log for dh_usrlocal issue?
<mitya57> there should be something like: D: dh_python3:80: moving files from debian/python3-foo/usr/local/lib/python3.3/dist-packages to debian/python3-foo/usr/lib/python3/dist-packages/
<mitya57> the dependency is now fixed (python-all -> python3-all)
<mitya57> also, worksformeâ¢
<pitti> mitya57: running again
<mitya57> pitti: ah, I've found the issue myself
<mitya57> EXTENSION_TAG = 'cpython-%smu'
<mitya57> it should be 'cpython-%sm' for 3.3
<mitya57> no, ignore that, I was looking at quantal's code, it's fixed in 3.3.x
<xnox> pitti: about app-install-data-partner, I was hoping for a magic script that i can point at the repository & it would fetch all packages, extract and generate all the needed icons/desktop files for me. Since we do that sort of thing for the main ubuntu archive, don't we?
<pitti> xnox: I'm not sure, i never really touched either; mvo knows this
<xnox> ack.
<jamespage> xnox, thanks for noticing I'd managed to not include that typo fix in my last openvswitch upload...
<mvo> xnox: hi, is it urgent? otherwise we should take monday, its just a script that runs and downloads a bunch of stuff
<xnox> mvo: monday is fine. in the mean time i'll try to verify the quantal-proposed to release that before i'll try to do a next round of fixes for oneiric->quantal.
<xnox> jamespage: =) just clearing up sponsorship queue.
<jamespage> xnox, nice one
<mvo> xnox: cool, I give you details then, need to look what bzr branch to run myself, but its just ./update.sh on a fast machine, should be automated on some server anyway ideally
<xnox> jamespage: I was like "what's the most scary package here, nobody wants to look at? ah openvswitch - hehe just a typo in a comment. win!"
<xnox> mvo: i total rekall something along those lines. maybe I even tinkered with it at one point (when my package was missing an icon in Software Centre)
<jamespage> xnox, I'd noticed the MP and commented and then completely failed to include it when I did the work early this week to upgrade to the new snapshot release.
<xnox> happens =)
<jamespage> yeah
<jamespage> rrd brain
<pitti> mitya57: I'm sorry, forgot: complete log is at http://paste.ubuntu.com/1545274/
<mitya57> :)
<mitya57> pitti: in fact, I've finally set up my autopkgtest in pbuilder (as suggested by ScottK), and it fails with a different error for me
<mitya57> pitti: strange, your dh didn't run override_dh_pysupport target at all :(
<mitya57> (not honoring debian/compat=7?)
<mitya57> it runs it between dh_installinfo and dh_installinit for me
<mitya57> ah, it seems to run it only if /usr/bin/dh_pysupport exists, I'll now add a dependency on python-support
<ogasawara> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara
<infinity> mitya57: python-support?  Really?
<infinity> mitya57: The vile thing we kicked to universe intentionally? :P
<mitya57> infinity: ok, I'll better refactor debian/rules so that it doesn't use override_dh_pysupport
<mitya57> pitti, infinity: done
<pitti> mitya57: running again
<pitti> mitya57: works now \o/
<mitya57> pitti: \o/
<mitya57> pitti: but: can that happen that you vm has libjs-jquery installed?
<mitya57> *your
<pitti> checking
<mitya57> for me it fails with "error: can't copy 'lib/foo/jquery.js': doesn't exist or not a regular file" when it's not installed
<pitti> mitya57: it indeed does
<mitya57> because it's a symlink
<mitya57> pitti: is it really needed there?
<pitti> presumably a reverse recommends of something
 * mitya57 adds a dependency on libjs-jquery
<mitya57> done
<davmor2> hey guys I just hit this on raring https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1101213 is there any other info that would be useful?
<ubottu> Ubuntu bug 1101213 in gnome-control-center (Ubuntu) "G-c-c printing doesn't allow you to select a hp printer" [Undecided,New]
<mitya57> ScottK: can I ask you to commit some of my changes to Debian?
<mitya57> I have prepared a branch: bzr+ssh://bzr.debian.org/~mitya57-guest/public_bzr/python3-defaults/merge-with-ubuntu
<ev> mpt: if we're trying to understand the frequency of the different reasons for not being able to process apport reports and thus would collect some information from a damaged or incomplete report, would there be something better to say than âNo details were recorded for this error.â
<mpt> ev, that sounds perfect to me.
<mpt> oh, wait
<mpt> sorry
<ev> :)
<mpt> Didn't realize *why* it sounded perfect...
<mpt> ev, if you have anything to report at all, does that mean you have a timestamp at least?
<ev> mpt: as it creates a file, yes
<ev> would it be helpful if I collected the types of errors in parsing the report that we account for?
<mpt> ev, the reason I asked is that we could always show the timestamp, before the "No details were etc".
<ev> ah, that would be rather nice
<mpt> Spec updated: https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=135&rev1=134
<ev> mpt: I agree with that, but is that sufficient if we are still going to send some information for why we failed to parse that report (or ran out of memory in loading it, or the application isn't installed anymore, etc)?
<mpt> ev, ah, sure. Yes, it would be informative to distinguish those cases.
<cjwatson> mlankhorst: Can bug 1081122 be marked v-done now?  The three packages you mentioned are in precise-proposed.
<ubottu> bug 1081122 in x11proto-randr (Ubuntu Precise) "x11proto-(gl,randr,dri2)-dev need to be updated for backport stack" [High,Fix committed] https://launchpad.net/bugs/1081122
<mlankhorst> cjwatson: yeah considering the entire backports stack built :)
<cjwatson> mlankhorst: OK, thanks, I'll do that and promote it
<cjwatson> Should help the width of pending-sru.html too since x11proto-randr has a big long version ...
<cjwatson> mlankhorst: How about the backport stack itself?  Do you have a feel as to its safeness for -updates yet?
<mlankhorst> I think so, only outstanding bug is the mesa one with sru and https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1086345
<ubottu> Ubuntu bug 1086345 in libdrm (Ubuntu) "Quantal-LTS-stack: Showing low-resolution screen on shutdown/reboot" [Critical,In progress]
<cjwatson> "the mesa one with sru"?
<mlankhorst> there's a mesa sru about libqt4-opengl-dev uninstalling the renamed stack, but it's solved by doing a sru in unrenamed mesa
<cjwatson> erk, yes, I agree renaming plymouth would be enormously painful
<cjwatson> bug 1098215
<ubottu> bug 1098215 in mesa (Ubuntu Precise) "installing libqt4-opengl-dev uninstalls renamed stack" [Critical,Fix committed] https://launchpad.net/bugs/1098215
<mlankhorst> I think we might have do an unrenamed copy of libdrm from quantal to precise, but I have no idea if we should also do a rebuild of the renamed stack without the renamed libdrm, it wouldn't be hard at least to do
<cjwatson> Hmm.  If you're going to do that it should be soon ...
<cjwatson> And yes, if you do that I think you should rebuild relevant bits of the stack against it
<mlankhorst> yeah I've been asking raof, but no reply yet :(
<cjwatson> So, I don't know.  Is it better to drop the current stack into -updates and fix that in a second round?
<cjwatson> infinity: ^- WDYT?
<cjwatson> It might mean people end up with orphaned libdrm-ltsq-* packages on their system - but I somehow can't see that as a huge deal
<mlankhorst> I can regenerate the entire stack easily, I always kept the option open of not renaming
<cjwatson> How much does it involve rebuilding?
<cjwatson> And hence reverifying?
<infinity> cjwatson: I'd prefer we not promote it while there are still open bugs on it, personally.  Especially with fundamental questions like this still floating.
<mlankhorst> in theory it's just removing libdrm-dev-lts-quantal from build-depends, and setting it back to libdrm-dev
<mlankhorst> and then doing a rebuild of all packages that link against libdrm-ltsq2 currently
<infinity> cjwatson: But you're the dot-two guy, it's your call.
<cjwatson> mlankhorst: How many's that?
<mlankhorst> mesa, xserver, vmware, openchrome, modesetting, intel, nouveau
<mlankhorst> and radeon I think
<cjwatson> So not totally awful
<cjwatson> infinity: Yeah.  I really want to get the new stack landed, but I think I agree with you.
<cjwatson> mlankhorst: OK.  Can we get this done today, then?
<mlankhorst> sure
<cjwatson> I can review stuff for you.
<mlankhorst> I'll do a upload against libdrm from quantal
<cjwatson> mlankhorst: Do we know that we don't need a new plymouth if we have a new libdrm?
<mlankhorst> quantal still builds the old nouveau1a, so we don't need a new plymouth, i think it might require a build fix to find the old nouveau, as does old xserver-xorg-video-nouveau
<mlankhorst> but that's only if you do a rebuild
<infinity> Yeah, that fix was in Q, it can be cherrypicked.
<cjwatson> We should include it, rebuild or not, but it needn't block libdrm
<cjwatson> IMO
<mlankhorst> yeah it's just changing configure.ac from looking for pkgconfig libdrm-nouveau to libdrm-nouveau1 iirc
<infinity> debian/patches/update-libdrm-nouveau-library-dependency.patch from http://launchpadlibrarian.net/112820397/plymouth_0.8.4-0ubuntu1_0.8.4-0ubuntu2.diff.gz
<cjwatson> apw: Hmm, I thought we'd switched to shipping just .signature in linux-signed for 12.04.2?
<cjwatson> apw: Urgh, maybe I forgot to backport those installer patches ...
<mlankhorst> ok I commented out the libdrm rename, regenerating entire stack.
<cjwatson> apw: Actually, maybe it doesn't matter.  I switched the livefs handling over, which is the important bit.  Ignore me :-)
<infinity> cjwatson: Any stellar plans on how we're going to shave the last ~12M off the precise CD size?
<cjwatson> infinity: I'm just downloading .1 so that I can start doing fine-grained comparison
<cjwatson> This is of course why I'm asking apw stupid questions :-)
<mlankhorst> 2.4.39.0ubuntu0.1 good enough as version for libdrm?
<cjwatson> WFM
<infinity> cjwatson: Well, we shrink a bit when we remove the duplicate libdrm.  But that won't be a lot.
<cjwatson> No, indeed
<cjwatson> infinity: Not seeing much else at the package level.  There's 2MB or so for SB loaders
<cjwatson> (In terms of diff from .1)
<apw> cjwatson, i did think we had done it very much for the CD size issue in q
<apw> are we saying we didn't copy them back after all that
<mlankhorst> ok did a check, only build-depends changed on all affected packages, seems some more are affected than I thought
<cjwatson> apw: I backtracked later on in your scrollback - I was misreading
<mlankhorst> nochange stood for that i removed the changelog entries http://paste.ubuntu.com/1545795/
<cjwatson> Right.  I think we need to suck those up.
<cjwatson> From the sounds of your assessment of the libdrm bug, anyway.
<mlankhorst> yeah
<cjwatson> Would be nice to get feedback from RAOF too, but we're running out of time for .2
<apw> cjwatson, phew :)
<mlankhorst> I mailed him about it on the 15th (well 16th for him), but didn't receive a relpy
<mlankhorst> anyhow rebuild order is libdrm, mesa, xorg-server, rest
<infinity> x11-xserver-utils	7.6+3
<infinity> x11-xserver-utils-lts-quantal	7.7~3ubuntu1~precise1
<infinity> Do we need two of those?
<mlankhorst> the second one only has xrandr
<mlankhorst> and in fact depends on x11-xserver-utils for the rest :)
 * ogra_ hopes all of that -lts stuff was heavily tested on arm before uploading ...
<infinity> ogra_: Seems unlikely, since it's meant to go with the lts-quantal kernel, which is x86-only.
<ogra_> oh, ok, i thought it replaced the shipped xorg through -updates
<mlankhorst> I did test it on arm once
<ogra_> yeah, dont bother if it needs kernel changes arm doesnt have
<mlankhorst> but it was a bit of a pain because of blob being incompatible
<cjwatson> ogra_: No, it's a replacement for new installs
<infinity> ogra_: The general theory is that people can choose one stack or the other, it's not forced on you.
<ogra_> k
<cjwatson> If it switches on upgrade then (AFAIK) that's a v-failed
<mlankhorst> only compiz failed on my pandaboard :)
<ogra_> mlankhorst, yeah, thats normal ... i'm still scared nvidia wont provide us a tegra update before we change the abi in raring
<stgraber> cjwatson: when you have a minute can you let my e-mail to ubuntu-devel-announce through
<cjwatson> stgraber: dodne
<cjwatson> -d
<stgraber> cjwatson: thanks
<mlankhorst> hm I need to fix the changelog entries
<cjwatson> mlankhorst: llvm-3.1 should be good to promote to -updates, right?  No libdrm dep there
<mlankhorst> yeah
<mlankhorst> hm is it ok if I rewrite the most recent changelog entry? my package generate scripts can't keep the old ones
<cjwatson> Err, not exactly sure what you mean
<cjwatson> What package?
<cjwatson> And you can't reuse the same version if it's already in -proposed
<mlankhorst> all *-lts-quantal ones :)
<cjwatson> Show me an example diff
<mlankhorst> it's just that when I upload ~precise2, the ~precise1 entry gets deleted
<cjwatson> I'd still like to see an example diff :)
<infinity> If the entries are just something like "autogenerated backporty thingamajig", and you're saying that it's easier to just generate a ~precise2 without preserving the ~precise1 history, that would be fine.
<mlankhorst> http://paste.ubuntu.com/1545849/
<mlankhorst> infinity: I'll try to preserve it in ~precise3, but that has to wait
<infinity> Yeah, preserving the history on that isn't meaningful.
<cjwatson> That's tolerable, if confusing for anyone watching closely
<cjwatson> Do fix your scripts, but not worth delaying in this instance
<mlankhorst> yeah
<infinity> Dropping old changelog entries messes with apt-listchanges' tiny brain, but I'm probably the only person who still uses it.
<cjwatson> I do!
<mlankhorst> I use it, and it's not that confused about it
<cjwatson> Quite a few things seem to mess with its brain.  Is that what causes it to show all changelog entries ever sometimes?
<infinity> Ahh, well then.  Yay.
<mlankhorst> I think it got smarter about it though
<infinity> cjwatson: It shows the whole changelog if it can't find the entry for your currently installed version, yeah.
<infinity> cjwatson: Though, there seem to be other cases where it does so as well.
<cjwatson> Mm.  But syncing over Ubuntu modifications would do the same, and we do that all the time ...
<infinity> Maybe someone fixed that at some point.
<infinity> Would just take a simple version compare and walking the known versions.
<cjwatson> Well, I still get it showing me the whole changelog quite a lot :)
<cjwatson> So maybe it's still there
<infinity> I only run it on my stable production machines, maybe I should re-enable it on my raring laptop and actually fix the things that annoy me some time.
<mlankhorst> I uploaded libdrm, still playing with the stack, trying to add an entry
<mpt> ev, I added a stub "Cross-release comparisons" list. https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=136&rev1=135
<mlankhorst> dpkg-mergechangelog ftw
<mlankhorst> ok I think I may be able to upload precise2 rebuilds now
<apw> cjwatson, does LVM install ticky do anything in raring live CDs ?
<xnox> apw: in desktop cd, it is meant to do separate /boot and the rest / on top of lvm.
<apw> the effect seems to be to do nothing
<mlankhorst> ok great, I can preserve history of changelogs..
<apw> xnox, it cirtainly is not doing that at all or indeed doing anything different at all
<xnox> apw: ... and you are doing wipe & install? (if you are doing upgrade or resize or reuse or replace it will do nothing)
<xnox> as in the checkbox will not have any affect, unless it's a pure wipe & install.
<apw> xnox, wipe and install indeed
<ogra_> tjaalton, whats the status on the nx7 input issue, we're just having the weekly nx7 meeting in #ubuntu-meeting
<apw> though actually it just puked and broke, and didn't install a thing, gah
<xnox> ok. I'll look into it.
<mlankhorst> it's a bit of a hack, but ok it worked..
<arges> hi. if I add the ddeb repo on precise on my x86_64 machine, and install the linux-image-3.2.0-36-dbgsym my /usr/lib/debug/vmlinux-* file is 32-bit ... is this a user-error or bug?
<mlankhorst> cjwatson: ok want me to upload the new affected packages too?
<cjwatson> mlankhorst: Still reviewing libdrm
<cjwatson> mlankhorst: We're going to need to backport a patch or two in plymouth aside from the build issue - bug 927424 at least
<ubottu> bug 927424 in plymouth (Ubuntu Precise) "Please backport commit to enable building without irrelevant drm libs on some arches" [Undecided,New] https://launchpad.net/bugs/927424
<mlankhorst> hm right
<mlankhorst> sorry - I completely forgot that building intel on arm was needed
<cjwatson> mlankhorst: Do you want to do the plymouth changes or should I?  If you do it then I can review :)
<mlankhorst> ok let me check
<ev> mpt: thanks
<cjwatson> mlankhorst: I don't know if you need bug 1018907 as well - hopefully not, since the patch for that was quite large
<ubottu> bug 1018907 in plymouth (Ubuntu Quantal) "plymouth in quantal on arm does only boot with black screen" [High,Fix released] https://launchpad.net/bugs/1018907
<mlankhorst> for 12.04.3 we want plymouth from raring, and disable libdrm-intel/nouveau/radeon entirely
<cjwatson> I guess that was mostly associated with having a new kernel, not with having a new libdrm
<cjwatson> .3> somebody else's problem ;-)
<infinity> arges: Seems weird that you got the i386 package.
<mlankhorst> yeah we don't have to worry about that arm patch, i think it's about more about the new omap driver
<infinity> arges: On the other hand, it's equally weird that the amd64 one didn't make it to the ddeb mirror. :/
<mlankhorst> and it would also work with plymouth from raring if it exposes the dumb api
<arges> infinity: hmm : ) that might be the issue
<infinity> arges: Oh, right.  And if you have a multiarch system, it would have dutifully grabbed the next best thing if the amd64 one didn't exist.  Which it doesn't.
<infinity> That's mildly irksome.
<mlankhorst> cjwatson: bad news though, that patch doesn't apply cleanly to precise plymouth :(
<mlankhorst> iirc I investigated it before, and there were some other changes in upstream git before that
<cjwatson> Do you want me to take care of it then?  I can probably find another reviewer
<cjwatson> It shouldn't be horribly difficult
<mlankhorst> nah I'll do it from the git tree
<infinity> pitti: Did we lose some ddebs with the host cutover?
<cjwatson> Please don't backport any other patches if you can possibly avoid it
<cjwatson> I don't want plymouth from git for .2 ...
<infinity> pitti: Or is the missing set of linux/precise-updates/amd64 udebs just bad luck from our crappy hack sometimes have a sad?
<pitti> infinity: I don't think we did; macquarie had been out of space for 4 or 5 days, and I retrieved the last 7 days from germanium
<infinity> s/udebs/ddebs/
<mlankhorst> cjwatson: nah just for easier diffing
<pitti> infinity: they have a tendency to disappear, but whenever someone notices it the last upload was more than 7 days ago..
<infinity> pitti: Oh well.  Not world ending if they're gone, just a bit of a shame that the one we happen to lose is going to be the 12.04.2 CD kernel.
<pitti> meh
<infinity> Oh, wait.  No it's not.  It's 3.2.0 that went missing, not 3.5.0
<infinity> So, I care even less than I did 2 minutes ago.
<pitti> Tue, 08 Jan 2013 18:36:32 +0000
<pitti> damn
<pitti> three days too late
<infinity> But we reeeeally need to spend a day going through, bit by bit, every thing we need to verify and fix in the pipeline to get this in the librarian.
<pitti> infinity: but 3.2.0 is the precise one
<infinity> pitti: But the 12.04.2 kernel is 3.5.0 :)
<pitti> ah :)
<arges> i thought ddebs.ubuntu.com was upgraded with more space recently?
<infinity> arges: Yeah, very recently.
<arges> so was the ddeb issue related to space or a script problem?
<infinity> arges: Or a buildd disappearing at the wrong time, or any number of other random things that make the current hack so fragile.
<infinity> (In other words: I dunno, and it's too late to hunt it down and fix it)
<pitti> arges: the main cause for lost ddebs had been -ENOSPC, but given how often kernel ddebs go AWOL I have a feeling that there's a script or packaging problem as well
<pitti> arges: we really need to debug this when a kernel upload has happened within the last 7 days, and the ddebs disappeared
<infinity> pitti: I suspect kernel ddebs don't actually get lost any more than others, they're just used more often so people notice.
<mlankhorst> oh right we didn't have a libkms yet, that's why it fails
<pitti> arges: or, having a backup of the .ddebs, that works too
<infinity> pitti: But it could also be because they're huge.
<pitti> infinity: yeah, true; I certainly still see a lot of "missign dbgsym" messages in apport retracer logs
<arges> unfortunately in this case i assume the 3.2.0-36 amd64 ddeb was never uploaded so there was nothing to rsync
<infinity> arges: None of them are "uploaded".
<infinity> arges: They're left in ~/public_html/ on the buildd, and fetched by a script.  There are so many wonderful ways that can go wrong, it's not worth mentioning.
<infinity> We just need to stop doing that and upload them to the librarian instead.
<infinity> See above, re: tracing everything we need to verify (and fix) to make that a reality.
<arges> infinity: ok. so how i can help with this?
<infinity> Run a local instance of launchpad, twiddle some things to make it ask builds to include ddebs in .changes, trace the process from build to upload to publish, see what explodes and why.
<pitti> way to scare off people on a Friday evening..
<arges> whoa
<arges> : )
<infinity> pitti: I'm a people person.
<cjwatson> Not that the librarian is totally without space problems
<infinity> pitti: Also, "I run a local launchpad instance" is a great pickup line.
<infinity> cjwatson: Yeah, the last time we brought this up, we were told it would be alright, but I've been paying attention to recent space firefighting issues.
<pitti> infinity: I have a certain feeling about the kind of people you're gonna pick up with that
<cjwatson> https://lpstats.canonical.com/graphs/LibrarianFreeDiskSpace/ (company-only, sorry)
<infinity> cjwatson: Still worth getting all our ducks in a row WRT making sure it all works right so we can flick the switch when we're told it's okay.
<cjwatson> Yeah
<infinity> I love whoever decided that "22" comes after "2".
<infinity> I guess if you say it out loud as "serve, serve two, and serve two two (or two too?)" it almost makes sense.
<pitti> urgh, what happened yesterday?
<pitti> did we remove 10 old releases or so?
<brendand> is unittest-xml-reporting available for python3 at all?
<mlankhorst> ok I think I got the plymouth patch reworked, will have to test in a vm first
<cjwatson> pitti: slightly long story, but trimming of some private PPAs that needed expiry and had never had any
<tjaalton> ogra_: nothing to brag about :/
<ogra_> tjaalton, pretty bad, couldnt we push the fix into our packages ?
<tjaalton> ogra_: i'll ping the upstream dev next week
<ogra_> thx !
<tjaalton> there is no fix
<ogra_> note that we have weekly meetings for nx7 progress oin fridays at 16:00 UTC
<tjaalton> it's just as broken upstream, but no patchset we've tried has helped any
<ogra_> hmpf, k
<tjaalton> i'm currently at a recording session, couldn't join you this time :)
<ogra_> k
<mlankhorst> cjwatson: erm, what is the autoreconf patch for?
<cjwatson> mlankhorst: sorry?
<cjwatson> mlankhorst: I expect it's the usual ...
<cjwatson> mlankhorst: It dates from before dh-autoreconf being widespread, and we should probably fix that now, but not for precise
<mlankhorst> ah k
<mlankhorst> well it's complaining about nouveau_drmif.h, I suppose I'll need to update it then
<cjwatson> Yeah
<mlankhorst> well plymouth builds now
<cjwatson> infinity: a certain amount is that the new kernel (+drivers) is just plain bigger, and that's partly duplicated in the initramfs
<infinity> cjwatson: We could delete the initramfs from the livefs. :P
<cjwatson> libxul.so has grown rather dramatically
<cjwatson> (9MB or so)
<cjwatson> infinity: It's not in the livefs
<infinity> Oh, kay.  Cause I was gonna say, it shouldn't be if it is.
<cjwatson> infinity: The duplication I meant was between /lib/modules in the initramfs and the livefs
<infinity> Yeah.
<infinity> Alright, I'm finally going to get some sleep.  10:30am seems like a reasonable bed time.
<xnox> indeed.
<cjwatson> /usr/lib/x86_64-linux-gnu/dri/ is up 15MB
<cjwatson> But, again, no idea what to do there
<infinity> cjwatson: That seems excessive...
<cjwatson> mlankhorst: How come the drivers in /usr/lib/x86_64-linux-gnu/dri/ aren't dynamically linked against libdricore any more?
<infinity> Oh, if those objects are all statically linked, that explains their massive size.
<mlankhorst> build system changes in mesa? anyhow it should still compress well
<cjwatson> They're not entirely static
<infinity> And based on the size, I'm guessing there's 6 of them?
<cjwatson> mlankhorst: You trust squashfs to notice that?
<mlankhorst> at least when I checked, the .deb size was only like 1 mb more
<cjwatson> infinity: There are a bunch
<infinity> cjwatson: Well, I'm just counting the 6 that are all >> 4MB.
<infinity> And since libdricore is about 3.7MB, that seems to add up.
<cjwatson> $ cat 1/usr/lib/x86_64-linux-gnu/dri/* | gzip -9c | wc -c
<cjwatson> 5657705
<cjwatson> $ cat 2/usr/lib/x86_64-linux-gnu/dri/* | gzip -9c | wc -c
<cjwatson> 10384236
<cjwatson> If gzip on its own doesn't notice, I'd be surprised if squashfs did
<mlankhorst> cjwatson: try tarring first, then gzip it..
<cjwatson> mlankhorst: Can you (get somebody to) look into this please?  We're very pressed for size
<mlankhorst> is it about the renamed stack?
<infinity> It's the new mesa.
<cjwatson> Size changes vs. 12.04.1.  We are way oversized and there are not many paths left to get back under size
<cjwatson> $ tar -czf - 1/usr/lib/x86_64-linux-gnu/dri | wc -c
<cjwatson> $ tar -czf - 2/usr/lib/x86_64-linux-gnu/dri | wc -c
<cjwatson> 10447832
<infinity> This same bug exists in raring.
<cjwatson> 5688816
<mlankhorst> hmz
<cjwatson> Even aside from the notion that tar might somehow improve compressibility vs. cat ...
<mlankhorst> ok can someone look at plymouth then? I made a .diff but I can't test it locally atm
<cjwatson> Pass it over to me; I can't actually test but I can test-build, if that will help
<cjwatson> And I can add a sanity-check layer
<cjwatson> mlankhorst: This won't solve all our size problems, but it amounts to about a third of it
<mlankhorst> test-build works, http://people.canonical.com/~mlankhorst/plymouth_0.8.2-2ubuntu31.debdiff
<mlankhorst> autoreconf diff is massive :(
<cjwatson> Running autoreconf on precise might be a bit smaller
<mlankhorst> I'm on precise + quantal xserver
<cjwatson> Bluff, that says autoconf 2.69
<cjwatson> And precise had 2.68
<infinity> mlankhorst: Pick the same autoconf and automake versions as the previous package used (you can check headers in configure)
<xnox> bzr shelve debfx ch
<cjwatson> Anyway, I don't care that much about the size of the autotools delta as long as it builds
<mlankhorst> huh, no idea how I got autoconf 2.69
<mlankhorst> must have installed it mnaually at one point
<mlankhorst> but I forgot what for
<cjwatson> Maybe we should just upload everything and test in situ in -proposed
<arges> has anybody had luck installing raring with the daily iso?
<cjwatson> I mean, this looks basically reasonable
<chiluk> arges I installed raring about a week ago with the daily
<mlankhorst> let me figure out which packages need renaming then
<arges> my T420/x220 are not working with 20130118
<mlankhorst> and uploading
<cjwatson> "not working" isn't too informative
<arges> sorry. it is getting stuck booting the kernel so I never reach the first installer scren
<arges> i'll need to boot in verbose mode
 * mlankhorst is going to pretend wayland didn't regress in his rebuilt version..
<mlankhorst> somehow it didn't rename it properly, weird
<arges> looks like it gets to * Stopping Syste V runlevel compatibiltiy * Starting, then i see a cursor and it doesn't respond at all (can't switch to virtual terminal)
<mlankhorst> cjwatson: ok I uploaded all the affected packages as well, they should be identical in debdiff, apart from build-depends and changelog entry :)
<mlankhorst> you want to wait with uploading the drivers until xorg-server is rebuilt though, since in the worst case it could rebuild against the renamed one still, since it provides libdrm-dev
<mlankhorst> cjwatson: fwiw, the build system changes to mesa in quantal made it hard to backport the patches, and at the time those changes have not been completed, so I think we decided to drop it, if I dig I may be able to find back the patch though
<cjwatson> drop which?
<cjwatson> mlankhorst: could you upload that plymouth too?
<mlankhorst> the patch :)
<cjwatson> the one you posted earlier, yeah
<cjwatson> just because I don't really want to accept libdrm without being able to accept that at the same time or shortly after
<cjwatson> (probably at the same time, since it has a tight build-dep)
<mlankhorst> ok but not sure I can upload to plymouth
<cjwatson> oh
<cjwatson> ok, sure, I can sponsor+accept that then
<mlankhorst> http://people.canonical.com/~mlankhorst/plymouth_0.8.2-2ubuntu31.debian.tar.gz http://people.canonical.com/~mlankhorst/plymouth_0.8.2-2ubuntu31.dsc http://people.canonical.com/~mlankhorst/plymouth_0.8.2-2ubuntu31_source.changes ?
<cjwatson> it's ok, I already built source locally
<cjwatson> mlankhorst: if you could invent and fill in some kind of test case in bug 927424, that'd be helpfu
<ubottu> bug 927424 in plymouth (Ubuntu Precise) "Please backport commit to enable building without irrelevant drm libs on some arches" [High,Triaged] https://launchpad.net/bugs/927424
<cjwatson> l
<cjwatson> (I won't block accepting on that though)
<mlankhorst> cjwatson: I can test on my pandaboard if you want
<cjwatson> the more the merrier
<cjwatson> mlankhorst: I still don't quite understand what mesa patch you were talking about above ...
<cjwatson> mlankhorst: is this something to do with the static linking problem?
<mlankhorst> oh sorry, had to get some food since its late here. It was intended to be about mesa, we kept the shared dricore patch, but didn't use it in quantal since the build system kept changing
<cjwatson> right
<cjwatson> ok, so I'm afraid I think that's .2-critical - I'm going to have to take a hatchet to other things as it is, and I'd rather not chop off too much stuff we actually need
<mlankhorst> it looks like it's nice and small
<mlankhorst> hm, isn't dricore already shared though?
<infinity> It's a shared library, but then all the stuff in /usr/lib/triplet/dri is unhelpfully statically linked to it.
<infinity> mlankhorst: ^
<mlankhorst> ah :/
<mlankhorst> isn't it libgallium that's big?
<debfx> xnox: ??
<xnox> debfx: hello =)
<debfx> hi
<cjwatson> mlankhorst: Is that the same as libLLVM-3.1?
<debfx> why would you shelve me? :(
<cjwatson> Oh, no, separate thing
<xnox> debfx: i'm not sure what you mean. What's up?
<cjwatson> mlankhorst: libgallium may be big but so is libdricore - hard to say what's contributing to the giant size increase exactly
<cjwatson> -rw-r--r-- 1 root root 3681104 Dec  4 08:44 2/usr/lib/x86_64-linux-gnu/libdricore9.0.0.so.1.0.0
<debfx> xnox: [18:42:28] <xnox> bzr shelve debfx ch
<xnox> hmmm... interesting =) let me grep my logs.
<mlankhorst> cjwatson: afaict, all the gallium drivers are big, while the intel ones etc are small
<sarnold> xnox: .. just an hour ago :)
<mlankhorst> so considering the evidence, I would say the conclusion is that we have to build gallium shared
<cjwatson> mkay
<mlankhorst> omg, shared-gallium patch still applies cleanly
<xnox> debfx: i remember. my system froze and while my curson was in the terminal it was not typing anything. I was meant to do $ bzr shelve deb<tab>, to shelve ./debian/ changes in my current branch.
<xnox> well ./debian/changelog to be precise. hence the ch later =)
<mlankhorst> this may be easier than  Ithought
<sarnold> xnox: hehe, nice ;)
<debfx> heh :)
<xnox> debfx: sorry for misspinging you. But I do want to talk to you about CMake and multiarch
<xnox> debfx: cause my other logs say you might be an expert there =)
<xnox> debfx: do you maintain cmake in debian or not?!
<mlankhorst> cjwatson: you're lucky, try building mesa with this.. http://paste.ubuntu.com/1546304/
<debfx> xnox: I'm not maintaining it though I have done several uploads in Ubuntu
<debfx> I hope your question doesn't involve python
<xnox> BINGO! =)
<xnox> ok never mind.
<xnox> then ;-)
<cjwatson> mlankhorst: Haha
<mlankhorst> cjwatson: iirc, before the quantal release I did refresh the shared gallium patch, but with the build system possibly still in flux, and the patch quite involved, we went with disabling it
<cjwatson> mlankhorst: (I'm not going to just now, frantically trying to fit in a last few things before dinner)
<jemadux> one question ... will ubuntu 12.04.2 have some packages from 12.10 ?
<xnox> jemadux: that's not really a development question, but rather #ubuntu support question. The answer is no it doesn't not have packages from 12.10. But we did backport & recompile: linux-kernel & X stack from 12.10 (quantal) and it's available to manually install in precise from -updates pockets. It will also be used by default on the 12.04.2 iso images.
<xnox> jemadux: also SecureBoot will be part of 12.04.2
<jemadux> ooh i see .backports
<xnox> jemadux: no, not backports. It's new source packages names published in the -updates pocket. You can choose to install them, if you wish, but one will not get auto-upgraded to them.
<xnox> they are only used by default if one uses 12.04.2 installation media.
<xnox> jemadux: look for packages named *-lts-quantal
<xnox> after 12.04.2 is released.
<xnox> currently they are being tested in -proposed pocket.
<jemadux> a i see ...
<hallyn> stgraber: hey, so for bug 1084000, do you see any downside to using the suggestion solution in the debian bug?  (namely, depending on and using the kernel headers)
<ubottu> bug 1084000 in libcap2 (Ubuntu) "libcap2: List of capabilities not in sync with the linux kernel" [High,In progress] https://launchpad.net/bugs/1084000
<hallyn> I've emailed the upstream maintainer twice, no reponse :(  probably on an extended vacation (or I'm in killfile :)
<hallyn> of course another alternative would be to (temporarily) fork the libcap code and just manually insert the missing capabilities
<sarnold> hallyn: apparmor used to use the kernel's headers too, but when the package is compiled on a machine with an older kernel (or software deployed on newer kernels), then the caps just aren't known / available...
<hallyn> sarnold: good point
<stgraber> hallyn: patch seems reasonable, it's not perfect (as sarnold said) but it's an improvement anyway
<hallyn> heh.  very good point.
<stgraber> ideally you'd want a way to grab the list from the running kernel, but if there was, people would be doing it :)
<sarnold> stgraber: yes :)
<hallyn> stgraber: there is a way,
<hallyn> using the bounding set
<sarnold> hallyn: but you don't get to know the names that way, right? (not sure if your use case cares..)
<cyphermox> hallyn: stgraber uploaded network-manager with a patch to fix the handling of bridge
<cyphermox> there was punctuation missing there
<hallyn> cyphermox: \o/
<hallyn> thanks
<cyphermox> let me know how that goes
<hallyn> sarnold: correct
<hallyn> cyphermox: oh, i misread
<cyphermox> hallyn: given that the interface got already trampled you might want to reboot and stuffs
<cyphermox> hallyn: what?
<hallyn> cyphermox: nothing, i'm goign to shut up now
<cyphermox> hallyn: it works for me, lxcbr0 doesn't get overriden now
<hallyn> cyphermox: so you're saying missing punctuation caused the bug, or that there ismissing punctuation in what he uploaded?
<cyphermox> no, there is missing punctuation in my message, I uploaded, he didn't .
<cyphermox> :)
<hallyn> cyphermox: got it :)  then, again, thanks
<hallyn> sarnold: stgraber: no, then again, i think i prefer to hand-massage the capability.h file in libcap2.  do you object?
<hallyn> (as kernel capabilities maintainer, in theory i should not be missing out on any updates in the kernel...)
<hallyn> (so it should not be unmaintainable)
<sarnold> hallyn: don't mind me :) I just wanted to give you one more data point. hehe.
<hallyn> sarnold: but the builders will always have the right linux-libc-dev ....  right?
<sarnold> hallyn: builders may still run a different kernel than the deployed environment..
<hallyn> sarnold: right, but the patch on the debian bug doesn't check the running kernel, so that's ok
<stgraber> hallyn: linux-libc-dev should usually get your pretty recent headers. Only case where it may miss some things is with kernel backports to LTS
<stgraber> hallyn: if you end up going the linux-libc-dev route, please add a comment in the changelog saying to do a no-change rebuild of the package when new capabilities are added
<hallyn> stgraber: if new capabilities are added to the kernel?
<hallyn> stgraber: only thing is, I assume this will eventually go in through debian using the originanl patch, so that changelog entry would get lost.
<stgraber> hallyn: well, hopefully the Debian maintainer will think of making some note similar to that or will just remember to do a no change rebuild whenever a new capability is added to linux-libc-dev
<sarnold> the trouble is htose are fairly rare events :)
<zobel> xnox: can you PLEASE stop hijacking my package ed in ubuntu!
<zobel> i maintain it in debian and ubuntu.
<zobel> and 17h from a bug report to a hijack is IMHO a no-go!
<jtaylor> ed is not modified in ubuntu?
<zobel> http://launchpadlibrarian.net/128823514/ed_1.6-2ubuntu1_source.changes
<zobel> it was
<hallyn> stgraber: of course in verifying that bug, i  noticed lxc-setcap is broken wrt the new lxc-init location.  We discourage lxc-setcap, so not sure how much we care
<stgraber> hallyn: well, if it's broken I suppose we should fix it upstream at least ;) As for Ubuntu, I'm tempted to say we should drop lxc-setcap and lxc-setuid from the package
<hallyn> stgraber: is there any other place i could put that note, where ppl would actually see it?
<stgraber> hallyn: you could put it in a README.MAINTAINER file or something similar in debian/, not sure it'd be much more visible though
<hallyn> ok, changelog it is, thanks :)
<hallyn> stgraber: yuck.  with that patch, capsh --print shows '35,36' rather than the capability names, though.
<hallyn> So forget it.  I'll patch the file and send that to amorgan.
<zequence> What would be a meaningful channel/mail list to discuss problems with help.ubuntu.com/community, regarding editing privileges (seems like some new accounts can't edit or add pages)
<hallyn> there, that looks better
<xnox> zobel: i am sorry. it wasn't evident from package history, since it's so well kept in sync. note that currently there are significant efforts being put into cross-building & cross-bootstrapping ubuntu and we have cross-builder network running. and we want as much ubuntu-main to cross-build as possible.
<zobel> xnox: see my recent (the second mail) which i send directly to you.
<xnox> one second. let me check.
<zobel> like... 2-3min old.
<ScottK> zequence: Maybe #ubuntu-doc.
<zequence> ScottK: Thanks.
<ogasawara> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2013-01-19
<cjwatson> zobel: Ubuntu modifications are not hijacks
<xnox> cjwatson: yeah, we agreed on that in private =)
<cjwatson> OK, but I want it to be clear for others reading so that there isn't a chilling effect
<mlankhorst> cjwatson: well do you need me for anything still? I cold do a precise3 for enabling gallium, but would rather test on monday
<cjwatson> mlankhorst: No, fine for now, thanks - I'll dribble in those rebuilds over the next day or so
<mlankhorst> kk
<infinity> Dearest apport:  WTF?  Why did you suddenly start opening chromium when firefox is my default browser?
<infinity> Hrm, because the sensible-browser alternative is wrong.  Irksome.
<Controlsfreek_> Im following instructions to build unity unity.ubuntu.com/getinvolved/development/unity/. when i get to 'remake-unity', i get an error "cmake error at plugins/unityshell/cmakelists.txt:25... cannot specify link libraries for target 'unityshell' which is not buikt by this oroject.
<Controlsfreek_> nvm got it.
<c2tarun> I was trying to learn Gtk Development with java, from this page: http://zetcode.com/gui/javagnome/firststeps/d   I am getting this error: http://paste.ubuntu.com/1547890/    I tried googling but the pages containing solution are in different language and google translator is not able to help.
<c2tarun> Can anyone please help me with this problem? ^^
<geser> cjwatson: for libimobiledevice: http://paste.ubuntu.com/1548738/ It looks like the patch for cython >= 0.16 (already included in the package) missed to remove one "inline" (it removed the inline from the .pyx file but not from the .pxd file which acts as a header)
<geser> should I prepare a debdiff ready for sponsoring?
<infinity> geser: Happy to sponsor if you toss it my way.
<infinity> geser: Or, I'll just upload this in your name: http://paste.ubuntu.com/1548915/
<infinity> geser: Err, I would if it didn't also FTBFS due to python multiarch. :P
<cjwatson> infinity: geser's work was on top of my patch - http://paste.ubuntu.com/1548971/
<infinity> cjwatson: Oh.  I just did that entirely differently (using python-config instead)
<infinity> http://paste.ubuntu.com/1548982/
<infinity> cjwatson: Is the plat_specific=True thing the more "correct" method?
<cjwatson> *shrug*
<cjwatson> I just thought it fit better in context
<cjwatson> Yours is more compact, so whatever
<infinity> I'm not picky at all.  Was just curious if there was an argument for one or the other.
<cjwatson> I think on reflection I prefer yours
<infinity> You know how much I don't love Python. :P
<infinity> I'll just upload this, then.
<infinity> dpkg-source-v3 + dh(1) + dh-autoreconf is love.  I might have kept maintaining PHP and Apache2 way back when if I'd had all this magic.
<cjwatson> infinity: Yeah, after a decade of random-walking around the possible ways to do this we seem to have settled on something that's actually fun :)
<infinity> I'd say something naively ambitious like "I should switch glibc to dh(1)", but I don't think I'm masochistic enough to even start figuring out how to do that.
<infinity> Though, I won't deny that it would be nice if more than four people actually understood the glibc packaging.
<geser> infinity: thanks for uploading it
<cjwatson> infinity: I managed to switch grub2 a while back
<cjwatson> infinity: Still working up the nerve to switch ubiquity ...
<cjwatson> Actually, I suppose it wouldn't be too bad, but I kind of feel the need for debian/rules to be less awful in other ways at the same time.
<infinity> hallyn: So, what do you plan to do about qemu and spice?  qemu-kvm-spice appears to be the only thing in qemu-linaro that isn't replaced by the new qemu.
<Bluefoxicy> huh
<Bluefoxicy> what if we did kernel updates by freezing everything, rebooting, then thawing everything?
<Bluefoxicy> It works on Dragonfly
<hallyn> infinity: well i want to take another look at spice, as someone claimed the dependencies may have changed so it may be easier to MIR now
<lifeless> hallyn: oo I was going to ask you about spice
<lifeless> hallyn: w/kvm specifically
<hallyn> infinity: but more likely i'll have to continue having a separate source tree for qemu-kvm-spice.  Though I'll simply build it from the identical source as qemu, to help reliability/testing
<hallyn> lifeless: and MIR ?
<lifeless> hallyn: main doesn't stress me :)
<lifeless> hallyn: I have universe on pretty much everywhere
<hallyn> lifeless: ok - if yo'ure having issues, lets chat monday.  i've gotta run right now
<hallyn> i'm open to changes, as things will have to change anyway - for now note we're ahead of debian with our spice version
<lifeless> hallyn: ciao ;)
<hallyn> (at least last i checked)
<hallyn> ttyl :)
<lifeless> ttyl
<dupondje> It should be possible to copy files from 1 gfvs mount to another no?
<dupondje> gvfs*
#ubuntu-devel 2013-01-20
<Botanic> I created a package and uploaded it to the ppa, I want to test it locally however to make sure I did everything correctly, how can I do that?
<sarnold> Botanic: you could add the ppa using apt-add-repository
<Botanic> its not built yet
<Botanic> itl take like 8-10 hours to be processed
<Botanic> id like to test it a bit sooner then that :)
<sarnold> oh!
<Botanic> as if there is an issue it limits the time I can work on it
<sarnold> very much so :) hehe
<sarnold> look into 'sbuild' or 'pbuild'; they help recreate the build environment on your machine. neither are perfect, but they do give you some confidence that a build didn't succeed because of some local packages that just happened to be installed.
<Botanic> well i know the code is fine, im more concerned with it creating shortcuts properly etc
<infinity> hallyn: Well, looks like I mangled enough of the archive to get qemu to migrate to raring.  Next step, removal of qemu-kvm source (which should be simple, now that the only binary it produces is obsolete)
<infinity> hallyn: But you definitely need to do something about spice, so we can drop the now un-uploadable qemu-linaro.
<hallyn> infinity: yup.  do you object to a duplicated source of qemu, called qemu-spice, producing the (universe) qemu-kvm-spice package?
<hallyn> That would be until either main-universe split is done away with, or spice gets MIR'd
<hallyn> infinity: what do you mean by 'get qemu to migrate' to raring?
<hallyn> ithought that would happen automativally
<infinity> hallyn: Well, I needed to fix some packages with deps on kvm.  And then forcefully whack the kvm binary package.
<infinity> hallyn: Also, there are file overlaps in qemu.
<infinity> hallyn: (Unrelated, just noticing this now)
<infinity> hallyn: Looks like this is inherited from Debian, so not your fault.  But should fix.
<infinity> (base)adconrad@cthulhu:~/qemu/qemu-1.3.0+dfsg$ grep doc/qemu/ debian/qemu-system.install
<infinity> debian/tmp/usr/share/doc/qemu/qemu-tech.html
<infinity> debian/tmp/usr/share/doc/qemu/qemu-doc.html
<infinity> debian/tmp/usr/share/doc/qemu/qmp-commands.txt
<infinity> ^-- Those three end up in both qemu and qemu-system, which seems silly, since all the other docs in doc/qemu are in qemu, but not system.
<infinity> I'm grabbing all the binaries right now to make sure those are the only overlaps.
<infinity> hallyn: I was going to JFDI a fix for the file overlaps, but it might be nice to know what the people who wrote that .install file were thinking (ie: is there a reason at all to have those files in the qemu-system package?)
<infinity> hallyn: Okay, those are the only overlaps I see (and, actually, only two of those are overlaps, but all three seem silly, given that all the other docs live in qemu.deb)
<infinity> hallyn: The quick-and-simple fix would just be to move those to qemu.install instead.  Opinions?  Can you get that into Debian too, so we don't diverge?
<infinity> hallyn: Oh, wait.  Then there's also the two overlaps listed explicitle in qemu.docs.  Fail.
<infinity> hallyn: So, this could go either way.  I can't tell what people really wanted. :P
<infinity> Given that qemu depends on qemu-system anyway, maybe it's easier to remove those from qemu.
 * infinity does that.
<hallyn> infinity: oops, sorry, yeah, I can push it into Debian.
<infinity> Let me test spin this and make sure it gives the result I'm assuming it will.
 * infinity sets his laptop on fire with the awful build of awful.
<infinity> hallyn: Assuming this test build produces plausibly-populated binaries, you probably want to push both these revisions to experimental: http://paste.ubuntu.com/1550856/
<infinity> hallyn: (With an appropriate Closes: in the changelog for the CVE one, the Debian bug is mentioned in the patch header)
 * hallyn curses the request for 2factor auth to d/l as text
<hallyn> infinity: i'll push it to my github tree and pass it along to the debian team
<hallyn> infinity: thanks
<infinity> hallyn: And before you ask, there's no need for a Replaces, since dpkg would have never let him install qemu anyway, so it can't own the files.
<infinity> hallyn: Anyhow.  Testbuid running just to make sure it DTRT.
<infinity> hallyn: The I'll upload.
<hallyn> infinity: odd, the patch author is the guy mainly doing the debian qemu tree.
<hallyn> oh, no, but the bug submitter
<hallyn> oh well
<infinity> I do wonder if maybe I have this backward, given that all the other docs are in qemu, not qemu-system.
<infinity> Do you have an opinion on where these 3 files should ship?
<hallyn> seems to me qemu is just meant to be a meta-package, not ship the docs, so i'd say qemu-system
<hallyn> although, what, they apply to qemu-user too?
<infinity> Well, that's not currently true.  qemu has a ton of docs.
<hallyn> a new qemu-docs pkg? :)
<infinity> http://paste.ubuntu.com/1550873/
<hallyn> i guess qemu makes sense as you certainly can use qemu-user without qemu-system
<infinity> A docs package may not be an awful idea, but I'm thinking for now, I should reverse this patch, and ship those three files in qemu, but not -system, based on the above paste.
 * infinity does that.
<hallyn> nod
<infinity> hallyn: New and improved -- http://paste.ubuntu.com/1550888/
 * infinity rebuilds again.
<infinity> Only takes 20m to build.  I thought it was worse...
<infinity> Maybe someone fixed some parallelisation at some point.
<hallyn> the old old qemu-kvm packages didn't parallelize the build at all.  those were painful.
<infinity> hallyn: As for the spice thing, I object slightly to a qemu-universe that only generates the spice package, but it's no worse than the situation we've had up until now with qemu-kvm and qemu-linaro.
<hallyn> infinity: is there anything else we can do?  how close are we to getting rid of main+universe split?
<infinity> hallyn: If you keep them in sync until such a time as it's not needed, it's probably not a big deal.
<hallyn> right, i'd take the source from our qemu with the relevant part of the old qemu-linaro packaging, i guess
<infinity> hallyn: ArchiveReorg probably won't be done this cycle, so we need a solution for now, whether it's spice in main or a qemu-universe source.
<hallyn> (keep it in a separate branch of the same github tree)
<infinity> hallyn: Duplicate sources aren't world-ending if they're kept completely in sync, so they're trivial to patch for security and SRU.
<infinity> (See, eg: boost and boost-mpi)
<hallyn> infinity: (your debdiff pushed to git://github.com/hallyn/qemu)
 * hallyn takes a quick looka t spice deps 
<infinity> hallyn: Do you keep a Debian branch as well, or just ask people to pull, mangle, and merge?
<hallyn> well shoot
<hallyn> infinity: i've only just started, so so far i just have asked ppl to look and comment and cherrypick if appropriate
<infinity> How/where is it maintained in Debian?
<hallyn> spice deps are looking clean !  i may ahve to re-ask for MIR
<infinity> Ahh, git://git.debian.org/git/pkg-qemu/qemu.git
<hallyn> well, git://anonscm.debian.org/pkg-qemu/qemu.git is what i use, not sure if that's the same
<hallyn> assume so
<infinity> You should probably just ask to be added to the Alioth group and merge appropriate distro-agnostic changes back yourself.
<infinity> Really helps keep the deltas down.
<hallyn> infinity: yeah, that'll be best long term, but i'm happy to spend some time slow-tracking to prove myself
<infinity> My life got a bazillion times easier when I just sucked it up and started maintaining all our glibc stuff in Debian first.
<hallyn> In the meantime we have som ethings we're hashing out in the debian qemu list,
<infinity> (Of course, this also led to accidentally being a Debian/glibc maintainer, but I suppose that's not a bad thing)
 * hallyn looks up what the heck the alioth group is
<infinity> Alright, confirmed that that diff did what I wanted.  Uploading.
<infinity> hallyn: pkg-qemu, according to the UNIX perms on git.d.o
<hallyn> gotcha
<hallyn> all right i'll re-file the MIR for spice, hope for the best
<infinity> hallyn: Well, all its build-deps are in main now, that's a good start.
<infinity> hallyn: If you can get security to sign off on it, I have no issues with it, personally.
<infinity> hallyn: Might want to offer jdstrand or mdeslaur a beer to review it for you.
<hallyn> infinity: luckily they won't be horribly overprised copenhagen beers
<hallyn> priced even
<hallyn> filed bug 1101978
<ubottu> bug 1101978 in spice (Ubuntu) "[MIR] spice" [Undecided,New] https://launchpad.net/bugs/1101978
<infinity> jdstrand / mdeslaur: Can I get one of you to do a quick security audit for bug 1101978?
<ubottu> bug 1101978 in spice (Ubuntu) "[MIR] spice" [Undecided,New] https://launchpad.net/bugs/1101978
<infinity> jdstrand / mdeslaur: Thanks in advance, you're stellar people, hallyn is buying you a pint.
<hallyn> ^ :)  and you as well
<hallyn> all right, with that i'm off to do my part in the war on the common cold.  gnight.
<infinity> Good luck.  Bring reinforcements.
<Kano> hi, what is used to create the current iso images with shim?
<Kano> livecd-rootfs does not contain the work shim
<mlankhorst> cjwatson: hm with just that shared libgallium patch applied (no idea if it runs, only tested building)
<mlankhorst> $ ls -ahl /tmp/static-gallium.tar.gz /tmp/shared-gallium.tar.gz
<mlankhorst> -rw-rw-r-- 1 mlankhorst mlankhorst 9,1M jan 20 20:02 /tmp/shared-gallium.tar.gz
<mlankhorst> -rw-rw-r-- 1 mlankhorst mlankhorst  11M jan 20 20:10 /tmp/static-gallium.tar.gz
<mlankhorst> still seems the object files for mesa are kind of big, but it looks like it might be possible to shrink it down slightly more, would have to investigate on monday
<cjwatson> mlankhorst: good start, thanks
<mlankhorst> cjwatson: how much space do you need?
<mlankhorst> I'm probably going to compare against the old mesa, and just prevent an increase in size only
<cjwatson> mlankhorst: I think we're something like 15MB over target
<cjwatson> (vs. 12.04.1, which was just about crowbarred into space)
<cjwatson> I haven't checked absolutely current image sizes though
<cjwatson> obv. it's not all going to come from mesa, but as much as feasible ...
<mlankhorst> yeah but can't get more than 5 mb off probably, unless you want to drop some drivers from the renamed stack
<mlankhorst> but most of those are small :/
<israeldahl> QML question: Anyone know if the default ItemStyle.class: "new-tabs" colour can be changed to something else?
<israeldahl> There is no documentation I have found that gives any reasonable descriptions for the Flickable tabs...
<sladen> israeldahl: is it Ubuntu specific?  Or a generic QML question?  If the latter, try one of the QML channels
<israeldahl> Ubuntu specific... I am using the "new-tabs" implemented for the Phone Os, and I want to change the background colour... possible on certain events as well  if that is possible.
<israeldahl> sladen: thanks for your reply
<israeldahl> sladen: does a specific Phone app development irc channel exist?
<sladen> israeldahl: #ubuntu-phone
<israeldahl> slade: thanks.. I'll ask there
#ubuntu-devel 2014-01-13
<shadeslayer> is pm-utils still required on the ISO?
<pitti> Good morning
<doko> pitti, I'm annoyed about autopkg tests
<doko> why is the aspcud test run when gcc-4.8 gets uploaded?
<pitti> doko: was it? AFAICS it was run because 1:1.8.0-1 landed in trusty-proposed on Jan 11, and that introduced an autopkgtest
<pitti> (which fails, like almost every new autopkgtest that we get *sigh*)
<pitti> I got another slew of failures over the weekend, going through them todya
<doko> pitti, pretty please can we ignore results for new autopkg tests until they get reviewed
<doko> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735138
<ubottu> Debian bug 735138 in aspcud "autopkg test always failing" [Serious,Open]
<pitti> doko: yes, jibel said he's working on that, to only hold back packages if the test ever succeeded
<pitti> doko: until then, if something is held back by them (not gcc-4.8 though), the release team can set a "known broken" tag
<doko> good to know
<pitti> gcc-4.8 isn't even in -proposed
<doko> pitti, it was, asked infinity to ignore the test. but it's annoying that I have to care about these
<Logan_> infinity: why did most of the ppc64el FTBFSes disappear overnight
<Logan_> I am so confused
<Logan_> wait they were all reset to "needs building"
<Logan_> but why
<Logan_> doko: is this because of your mass rebuild?
<doko> Logan_, he did give back the packages, they should reappear soonish
<Logan_> who did?
<Logan_> I'm so confused :P
<dholbach> good morning
<Logan_> hey Daniel
<dholbach> hey Logan_
<dholbach> how's life over there?
<Logan_> It's going. :P
<Logan_> It is also approaching 3 AM, so I should probably get to sleep.
<dholbach> that sounds like a good idea :)
<Logan_> doko: I'm still confused though. :( Who is "he," and to whom is he giving back the packages? :P
<doko> infinity,
<doko> to the buildds
<Logan_> Ah.
<Logan_> So it is Adam's fault. :P
<Logan_> I am so intuitive.
<Logan_> I also have to forward like 20 ppc64el patches to Debian. So tedious.
<doko> Logan_, are you user-tagging these?
<Logan_> infinity and I were discussing that yesterday with juliank.
<Logan_> I don't think we came to a conclusion about what the usertag(s) should be and if my bugs even need one.
<Logan_> Because the dh-autoreconf/autotools-dev are more futureproofing than necessarily fixing FTBFSes on a specific architecture.
<Logan_> But they do serve an immediate purpose, though.
<Logan_> Hi Jackson.
<Noskcaj> hey Logan_
<Logan_> doko: Please let me know if I should use something, though.
<doko> call-autoreconf
<Logan_> ...and, if so, if I have to retroactively apply it to all ~120 other ppc64el patches I've submitted.
<Logan_> Well, some of those are config.{sub,guess} updates with autotools-dev. I guess that whittles that number down a bit. :P
<doko> you can do that with a control message
<Logan_> Okay. Is this usertag going to be a standard?
<doko> maybe use debian-devel@lists.debian.org as the user, but let's ask others about that first, like cjwatson
<Logan_> Hmm.
<Logan_> There should probably be a larger discussion about this, yeah.
<MacSlow> Greetings folks!
<pitti> dobey: hey Rodney, how are you?
<pitti> dobey: mvo approved https://code.launchpad.net/~pitti/software-center/deprecated-ctors/+merge/201158, would you mind merging this? thanks!
<rbasak> jdstrand: are you aware of bug 1262710, please?
<ubottu> bug 1262710 in nginx (Ubuntu) "[MIR] nginx" [Undecided,Confirmed] https://launchpad.net/bugs/1262710
<Noskcaj> dholbach, What do i do to fix the test failure i just made? I barely know enough C to make a "hello world"
<Noskcaj> And do test failures make the build crash locally and i missed it or has something broke since?
<dholbach> Noskcaj, no the test worked out fine for me locally - I did a test build
<dholbach> Noskcaj, if you don't get very far with your own investigations, you could ask in here, or on ubuntu-devel@ for some help
<dholbach> and if that doesn't help, you could ask upstream
<Noskcaj> ok, will do.
<Noskcaj> Although tomorrow, since i'm not meant to be on the internet
<dholbach> Noskcaj, see you! :)
<Noskcaj> bye, thanks for the tips
<doko> jodh, there is no libnuma-dev on arm64 and armhf
<jodh> doko: yes, I saw that and was wondering how to define that in debian/control as I've already specified some arch restrictions on that package.
<doko> jodh, or you try to build it on these archs ;p
<dholbach> seb128, does Laney's comment on 1268097 make sense?
<jodh> doko: I have been waiting since November for Debian to approve my request to access their porter boxes for that exact reason
<doko> jodh, well, you have access to armhf, and debian doesn't have access to arm64 either
<jodh> doko: sure. I'm trying to keep the process for myself as simple as possible as procenv builds differently on every arch and there are lots to support :) Wouldn't it be great if it was possible to test this out on mentors rather than via an upload? So, do you know how I would build-depend on libnuma-dev for (linux-all - arm64 - armhf)?
<jodh> doko: ... - armel - arm64 :)
<doko> jodh, enumerate the libnuma-dev architectures explicitly
<shadeslayer> could somene look at https://launchpadlibrarian.net/162316715/buildlog_ubuntu-trusty-ppc64el.kubuntu-meta_1.297_FAILEDTOBUILD.txt.gz
<shadeslayer> Can't open desktop-ppc64el: No such file or directory at /usr/bin/dh_germinate_metapackage line 78.
<shadeslayer> nvm
<doko> shadeslayer, you need to add it in kubuntu-meta
<shadeslayer> doko: yep, missing arch in update.cfg
<TJ-> Anyone familiar with apparmor internals? Specifically whether it is supposed to truncate the logged process name in syslog, e.g. comm="qemu-system-x86" instead of comm="qemu-system-x86_64" - looks like a truncate-on-underscore bug unless its deliberate
<cjwatson> doko: I really don't care what the usertag is; pick one :)
<cjwatson> doko: though using debian-devel@ seems to imply a consensus there, which isn't clear
<cjwatson> shadeslayer: I was deliberately not adding it until more of the rest of Kubuntu is built on ppc64el
<Mirv> mitya57: hi! dok_o confirmed that the aarc64 Qt patches are not needed anymore with 5.2
<shadeslayer> cjwatson: oh .... how do I check that ? :S
<doko> well, we could use one of our own email addresses
<cjwatson> shadeslayer: http://qa.ubuntuwire.org/ftbfs/ppc64el.html has a section for it
<shadeslayer> I see
<cjwatson> http://qa.ubuntuwire.org/ftbfs/ppc64el.html#kubuntu in fact
<mitya57> Mirv: great, drop them then :)
<Mirv> will do
<doko> fyi, I demoted trac-bzr to -proposed. is there anybody I should explicitely tell about it?
<shadeslayer> cjwatson: ack
<directhex> is there a way for mortals to developer for aarch64 yet?
<shadeslayer> cjwatson: ugh, eigen is FTBFS
<cjwatson> shadeslayer: can't help you with that one, I don't speak enough C++
<doko> shadeslayer, eigen?
<brendand> where can i get newer versions of pulseaudio?
<shadeslayer> doko: https://launchpad.net/ubuntu/+source/eigen2/2.0.17-1/+build/5345503
<shadeslayer> cjwatson: while you're here, any ideas if pm-utils will go away?
<seb128> dholbach, commented on the bug btw ;-)
<seb128> dholbach, readonly is not really an issue there, we don't want people to have to adb to sudo cp files to add a ringtone, we can do better than that ;-)
<cjwatson> shadeslayer: no idea
<doko> zul, beanstalkd ftbfs
<pitti> shadeslayer: not anytime soon, as long as there are still laptops out there which need suspend quirks
<pitti> shadeslayer: it's optional these days (meaning that logind will work without it), and we don't install it on phones, but we still want it on desktops
<mpt> ev, was the fix for bug 1033902 ever backported to 12.04? From the bug report it seems not.
<ubottu> bug 1033902 in Apport "Application thread crash shows application crash error alert" [High,Fix committed] https://launchpad.net/bugs/1033902
<mpt> â¦Though the bug description is filled out as if it was meant to be.
<pitti> no, it wasn't
<arges> @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: arges
<kentb> xnox: sorry about the mixup with sblim-sfcc...all my fault. I'll work on getting it cleaned up today
<caribou> slangasek: I have a question for you regarding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706655
<ubottu> Debian bug 706655 in kdump-tools "kexec-tools: Please consider including integration for kdump auto-dumping" [Wishlist,Open]
<caribou> slangasek: we no longer use the script in kexec-tools. It has been overriden by the kdump-tools since Raring :
<caribou> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-kdump-tool
<jdstrand> TJ-: re apparmor, I believe that for "comm" that is by design. you'd likely have more luck asking on #apparmor on OFTC
<mlankhorst> chrisccoulson: ping?
<TJ-> jdstrand: OK... I've logged a bug report since it's useless if the reported process name can't be given to aa-complain/aa-disable
<jdstrand> TJ-: normally you use the path to the profile name for that and the path used for binary attachment is "name" not "comm"
<jdstrand> TJ-: reading 'man apparmor', while the text is quite old, it says there is a 15 byte limitation on the process name due to Berkeley process accounting
<psivaa> cjwatson: doko: a precise-alternate issue after 20140111: http://pastebin.ubuntu.com/6744680/ unmet deps.
<psivaa> nothing urgent here for me.. but just letting you know if in case it interests you. and apologies if it doesn't :)
<TJ-> jdstrand: which would explain it... thanks! Caught me out trying to solve an issue with libvirt/qemu-system-x86_64 being denied access to /dev/sr0
<doko> tjaalton, ^^^ could you look at psivaa message? I think you did update precise
<cjwatson> doko,tjaalton,psivaa: I suspect it's a CD-building problem and that tjaalton is going to be a bit stuck
<cjwatson> I'll look at it, but not this afternoon, am going to be offline for a few hours
<tjaalton> hum
<tjaalton> mlankhorst: ^
<tjaalton> missing packages I think?
<cjwatson> no
<tjaalton> ok
<cjwatson> both the enablement stack and the original stack are trying to be installed for some reason
<tjaalton> ah
<tjaalton> sounds familiar
<mlankhorst> yeah
<mlankhorst> maybe some egl drivers are tried?
<cjwatson> the desktop-common seed pulls in the old stack, which is reasonable for the seed in general but the images will need to figure out how to override it
<mlankhorst> oh
<cjwatson> I'll look at it but as I say not this afternoon
<mlankhorst> cjwatson: libtxc-dxtn-s2tc0 is in universe
<mlankhorst> at least for precise
<cjwatson> which no doubt contributes but isn't the sole problem
<cjwatson> at least I doubt it
<cjwatson> I mean it's only a Recommends, it can't be breaking things
<cjwatson> mlankhorst: but I can move s2tc to main in precise-updates if that's what you folks need
<mlankhorst> yes please
<cjwatson> done
<cjwatson> like I say, though, won't fix this
<mlankhorst> yeah something causes the main stack to be installed
<mlankhorst> cjwatson: what image btw?
<cjwatson> precise alternate, as psivaa said
<mlankhorst> I think the snippet is too small to say anything sane about it
<mlankhorst> would need a bigger log
<cjwatson> I agree, need to dig into it in more detail.  we don't need a libglu1-mesa-lts-saucy, do we?
<mlankhorst> no
<cjwatson> though that might just move the problem one level up, anyway
<mlankhorst> libglu split off from mesa after 8.0
<psivaa> mlankhorst: http://pastebin.ubuntu.com/6744772/ is the full install log
<cjwatson> I don't think we're going to get the reason out of logs
<mlankhorst> Jan 13 13:36:45 in-target: invoke-rc.d: policy-rc.d denied execution of start.
<mlankhorst> Jan 13 13:37:20 in-target: Reading package lists...
<mlankhorst> nope, missing the install command :/
<cjwatson> wouldn't do you any good anyway, it's just installing a task, and the definition of the task will be image-specific
<mlankhorst> hm maybe the unrenamed packages are still part of the task?
<cjwatson> no doubt
<cjwatson> which is why this is an image-building problem to debug
<cjwatson> I doubt it's your problem
<mlankhorst> indeed
<cjwatson> mlankhorst: mind you - shouldn't libglamor-ltss0's depends prefer libgl1-mesa-glx-lts-saucy rather than libgl1-mesa-glx?
<mlankhorst> oh, it should..
<cjwatson> mlankhorst: that's the reason germinate's giving me at the moment
<mlankhorst> but the package rename script should have taken care of that..
<mlankhorst> hm
<cjwatson> it's the only match in grep-dctrl -FSource:Package lts-saucy --and -FDepends 'libgl1-mesa-glx '
<cjwatson> so fixing that will either help or will expose the next problem :)
<mlankhorst> it shouldn't be fatal at least... no idea why it wants libgl1-mesa-glx explicitly either
<cjwatson> it's fatal in this case because task construction is not always entirely deterministic and essentially depends on which one of a set of alternatives it sees first
<cjwatson> so right now that's what causes libgl1-mesa-glx to be pulled into the ubuntu-desktop task on the alternate image
<mlankhorst> fun
<mlankhorst> looks like I may need to explicitly depend on libgl1-mesa-glx-lts-saucy in build-depends then or something
<mlankhorst> cjwatson: oh, it seems to be because of shlibs in libgl1-mesa-glx-lts-saucy
<cjwatson> ah
<mlankhorst> I would rather not change that, can I override the shlibs:Depends for glamoregl?
<mlankhorst> hm maybe adding libgl1-mesa-glx-lts-saucy in front is enough
<cjwatson> probably won't be
<cjwatson> worst case you can sed the substvars file
<mlankhorst> it should be enough
<arges> xnox: do you mind if I review this merge? https://code.launchpad.net/~louis-bouchard/ubuntu/trusty/backuppc/backuppc-merge/+merge/200536
<cjwatson> I'd really prefer you didn't take that approach
<cjwatson> I'm not quite sure whether germinate will DTRT with that and it's confusing
<cjwatson> sed -i 's/libgl1-mesa-glx /libgl1-mesa-glx-lts-saucy /' debian/libglamor-ltss0.substvars after dh_shlibdeps should work
<cjwatson> anyway, have to go out
<jamespage> OK - so I'm trying to figure out how to introduce a new libmysqlclient for mysql-5.6 into the archive without causing a transition
<jamespage> the mysql-5.5 client version is 18.0 and the mysql-5.6 client version is 18.1  - is it possible to have two such closely versioned libraries installed at the same time and everything still work?
<chrisccoulson> hi mlankhorst
<mlankhorst> chrisccoulson: do you have some easy way to reproduce bug 1267893
<ubottu> bug 1267893 in Oxide "Shutdown crash due to possible mesa race at startup" [Critical,Triaged] https://launchpad.net/bugs/1267893
<chrisccoulson> mlankhorst, not unless you want to build oxide (which is pretty heavy) ;)
<zul> doko:  building now
<chrisccoulson> mlankhorst, and it obviously doesn't happen every time too
<geser> jamespage: different packagename (and so-version) of the library or same?
<mlankhorst> chrisccoulson: oh was curious if the patch Sarvatt attached fixes it
<chrisccoulson> mlankhorst, yeah, that patch will fix it. i can tell that without even trying it :)
<chrisccoulson> but it doesn't fix the underlying cause, which is that the glx extension gets registered twice. not sure if there are other effects from that
<jamespage> geser, I was thinking libmysqlclient18 (for mysql-5.5) providing libmysqlclient.so.18 and libmysqlclient18.1 (for mysql-5.6) providing libmysqlclient.so.18.1 - just trying to think if there are any gotchas
<mlankhorst> probably not
<chrisccoulson> mlankhorst, so in that case, that patch should be fine
<mlankhorst> my guess is maybe some small extra allocation until close
<jamespage> like if I install the 5.6 client library, does all client use which to the 18.1 version
<geser> jamespage: no, only those which link against it (which would be at first the mysql 5.6 client and server itself)
<jamespage> geser, well those statically link the client - but it sounds like it should be OK then
<geser> jamespage: then for the client it would be even easier, but other programs which are linked against it request specifically libmysqlclient.so.18 (or libymsqlclient.so.18.1 if linked against mysql 5.6)
<jamespage> geser, excellent - thanks for confirming that behaviour
<jamespage> that's what I thought but it felt weird
<geser> just make sure that there is no file conflict between those two library packages
<jamespage> geser, ack
<geser> jamespage: what about the -dev package? are you going to version it to not break linking/building with libmysqlclient-dev (from mysql 5.5)
<jamespage> geser, I think its OK for the -dev package from 5.6 to conflict with the 5.5 version - it only makes sense to ever have one installed
<geser> jamespage: yes, but if mysql 5.6 builds libmysqlclient-dev now then you can only build other packages against 5.6 as it will replace libmysqlclient-dev from 5.5 in the archive
<jamespage> geser, mysql 5.6 would build libmysqlclient18.1-dev for now
<geser> ok, so no problem then
<jamespage> hope not
<jamespage> :-)
<mlankhorst> chrisccoulson: I was hoping for some official confirmation though, so I could merge the patch into mesa
<slangasek> caribou: Debian bug #706655> ok, can you provide a patch to the Ubuntu kexec-tools package to get rid of whatever bits are no longer required, so we can reduce the delta with Debian and I can close out that report?
<ubottu> Debian bug 706655 in kdump-tools "kexec-tools: Please consider including integration for kdump auto-dumping" [Wishlist,Open] http://bugs.debian.org/706655
<caribou> slangasek: ok, arges was pinging me about the kexec-tools merge earlier today
<caribou> slangasek: I will see with him so we get rid of anything that is no longer needed
<stgraber> tseliot: bug 1259237 was automatically marked verification-failed, can you take a look?
<ubottu> bug 1259237 in nvidia-prime (Ubuntu Precise) "Hybrid graphics enablement in 12.04.4" [Medium,In progress] https://launchpad.net/bugs/1259237
<stgraber> we're trying to round up the last few bits for 14.04.4 and there appears to be a dozen packages related to that bug which are targeted at 14.04.4, so the sooner we can have this sorted out the better
<tseliot> stgraber: I worked on a fix (now in 14.04) and I attached a deb package in LP: #1268027 to see if that solves the issue. I can also upload to precise-proposed if you want
<ubottu> Launchpad bug 1268027 in nvidia-settings (Ubuntu) "nvidia-settings crashes on exit" [Medium,Triaged] https://launchpad.net/bugs/1268027
<jjohansen> jdstrand: since you where dealing with this earlier. I've answered bug 1268546
<ubottu> bug 1268546 in apparmor (Ubuntu) "comm process name log entry truncated at underscore" [Undecided,New] https://launchpad.net/bugs/1268546
<jdstrand> jjohansen: ack, thanks
<jdstrand> jjohansen: not saying you have to do it, but man, the ERRORS section of the man page is pretty out of date (I'm not sure I recall ever seeing a log message like the one in the man page :)
<jjohansen> heh I bet, the man page needs some love
<jdstrand> I can send a patch to the list
<sbeattie> ah, yeah, I bet.
<sbeattie> jdstrand: that'd be great
<cjwatson> switching libtool back to M-A: foreign as discussed last week
<cjwatson> I'll also work on testing the results of the debian-devel discussion so that we can have a more permanent solution
<cjwatson> (though probably not today)
<infinity> cjwatson: The proposed option 1 seemed san.
<infinity> cjwatson: sane, too.
<cjwatson> infinity: Yeah.  But I have only proven it correct, not tested it, as the saying goes.
<infinity> cjwatson: Indeed.  It's obviously not harmful to native builds, but I guess some cross-testing (since that's what we're attempting to "fix") would be in order.
<cjwatson> Yes.  Ideally I need an example of something that's actually trying to use /usr/bin/libtool ...
<cjwatson> (That we haven't shotgunned yet)
<cjwatson> I'm not short of normal libtool examples
<infinity> cjwatson: There are a large number of packages (though I can't think of one off the top of my head) that test for /usr/bin/libtool and then don't use it. :P
<infinity> cjwatson: Those all worked fine in the M-A:foreign unsplit case, of course.
<infinity> I don't actually know of a package that *calls* libtool, though there must be a few.
<dobey> infinity: any library that is built with autotools using libtool, will probably call /usr/bin/libtool during the build
<infinity> dobey: That's generally not true.
<infinity> dobey: Anything properly libtoolized has its own local copy of libtool.m4, etc, and configure generates a fresh local libtool that ends up being called.
<infinity> Most of the cases of /usr/bin/libtool usage I've seen have actually just been "-f /usr/bin/libtool" tests and then calling libtoolize. :P
<dobey> infinity: the local libtool in the tree is a shell script, that can call /usr/bin/libtool, iirc
<jtaylor> may I ask what the motivation for ppc64el is? it seems to divert a lot of manpower before the lts.
<jtaylor> I don't recall it being explained on the mailing list
<infinity> (For the record, we just did a test rebuild with a libtool that didn't ship /use/bin/libtool, and it proved your assertion false, I'm not just guessing)
<jtaylor> I just found the debian report which was mostly negative to adding it
<infinity> jtaylor: Which report is this?
<jtaylor> https://lists.debian.org/debian-powerpc/2013/09/msg00045.html
<jtaylor> probably not negative, but I also saw no good reason to add it
<infinity> Anyhow, the short answer is "to have Ubuntu run on POWER8 with IBM's recommended configuration".  No community members are being forced to do any work, so I'm not sure what the complaint would be.
<jtaylor> just discussion about ibm management :/
<jtaylor> I'm not complaining, just curious
<jtaylor> xnox: any news on when qemu arm64 will be fixed?
<infinity> jtaylor: You want hallyn for that question, probably.
<jtaylor> oh sorry
<hallyn> jtaylor: is qemu arm64 broken?
<hallyn> later this week i will push a new qemu that shoudl have kvm support for qemu-system (but not the qemu-user-aarch64)
<hallyn> but not today, hitting deadlines
<jtaylor> hallyn: some of xnoxs arm64 changes in 1.5 were reverted in 1.7 merge
<jtaylor> we discussed it about a week ago here
<hallyn> i don't recall xnox making any changes, but if you're referring to the suse patchset then the latest estimate i know if would be a little over a month to get the new patchset upstream, and i'll pull it in as quick as i can after that
<hallyn> if there is another patch/fix you're referring to, then maybe i just messed up
<kentb> I've got a package for sponsorship review if anyone would like to take a look. Thanks in advance: https://bugs.launchpad.net/ubuntu/+source/openwsman/+bug/1268707
<ubottu> Ubuntu bug 1268707 in openwsman (Ubuntu) "Please upgrade openwsman in universe to latest upstream for Trusty (2.4.3)" [Undecided,New]
<arges> kentb: well i'm piloting today so I'd be glad to look at it
<kentb> arges: ok. thanks!
<arges> kentb: the debdiff doesn't apply cleanly to the version already in trusty
<arges> kentb: 2 out of 2 hunks FAILED -- saving rejects to file cmake/modules/FindRuby.cmake.rej
<kentb> arges: ok. I know which patch that was
<kentb> arges: I took it out when building the package...it is in patches/cmake-findruby.patch
<arges> kentb: its not in the series file
<arges> all that's there is the cmake-pythone-includes.patch
<kentb> arges: sorry. I think I got mixed up here with what you were telling me.  When I originally built the package using the upstream source, there was a cmake-findruby.patch included in the 2.3.6 debian.tgz file.  That patch was no longer needed.  I removed it and also took it out of the series file so it would build.  Does that make sense?
<arges> kentb: even with that patch removed, it still fails to apply your debdiff
<arges> kentb: do this ' pull-lp-source openwsman trusty; cd openwsman-2.3.6; patch -p1 < patch.debdiff'
<arges> that fails
<arges> for me
<kentb> arges: yeah. it just did for me too
<arges> kentb: ok cool. Yea just fix that up, and re-attach that debdiff, and I'll give it another look. Thanks!
<kentb> arges: will do. sorry about that
<arges> kentb: its not a problem  : )
<jtaylor> hallyn: http://launchpadlibrarian.net/157807141/qemu_1.6.0%2Bdfsg-2ubuntu3_1.6.0%2Bdfsg-2ubuntu4.diff.gz
<hallyn> jtaylor: yeah i don't think you can have that patch without having  qemu-user-aarch64
<jtaylor> xnox: didn't you have something working at some point ^?
<jtaylor> I think in irc he mentioned that that was dropped in the merge too
<infinity> hallyn: The first half of that patch is specifically about arch combinations that don't need virt.
<infinity> The second half, sure, is about what might need virt, and that won't work until qemu-user works, but future proofing scripts never hurts.
<infinity> But the second part was wrong.
<infinity> Since it needs to map arm64 to aarch64.
<hallyn> infinity: are you saying the first half of the patch woudl still be appropriate?
<infinity> hallyn: Yeahp.  And should also have amd64-x32 and x32-amd64 added.
<hallyn> if so, xnox could you send me a debdiff for the good part?  (or upload if you prefer, but lemme know and i'll push it to my git repo)
<infinity> (And probably i386-x32/x32-i386 too... Starting to highlight how that little case doesn't really scale)
<hggdh> micahg: hi, someone from the DMB must accept the invite for ubuntu-uploaders to join bugcontrol
<kentb> arges: okay. got it sorted this time. file is openwsman-latest.debdiff
<arges> kentb: ok
<arges> kentb: do you need two different changelog entries for this upload? or could they be combined?
<arges> kentb: and i couldn't find this in debian, is it not included there yet?
<kentb> arges: they can be combined.  debian does not have this yet, although I'm going to try and work on that on the side so we just sync in the future
<arges> cool
<arges> kentb: everything else looks good, and it builds fine for me
<arges> kentb: uploaded
<kentb> arges: awesome. thank you, sir!
<arges> np
<arges> kentb: thank you for getting all this stuff updated
<kentb> my pleasure. it's been a good learning experience :-)
<arges> and that ends my day
<arges> @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:
<cjwatson> dobey: I've just gone through the local libtool in one of my projects, and there's no evidence that it would ever call /usr/bin/libtool.  It'd be extremely peculiar and pointless for it to be set up that way, so I doubt it ever happens.  I'm pretty sure any instances of this are failures to generate a package-local libtool script at configure time.
<Logan_> When will apport start reporting to Launchpad by default in this cycle?
<Logan_> Isn't it usually around Alpha 1 or something?
<jtaylor> doesn't it now go to errors.ubuntu.com?
<Logan_> jtaylor: But that's been disabled during development cycles. At some point.
 * Logan_ pokes pitti. ^
<sarnold> Logan_: it's a bit late/early for pitti, try again in six or seven hors..
<robert_ancell> cjwatson, looking at out of date ttf-indic-fonts package (bug 958345). Don't suppose you can remember back to 2010 and know if any of the changes you made there are still relevant?
<ubottu> bug 958345 in ttf-indic-fonts (Ubuntu) "ttf-indic-fonts packages is not updated for last 2 years" [Wishlist,Triaged] https://launchpad.net/bugs/958345
<Logan_> sarnold: Will do. :P
<robert_ancell> I think the only change we need is the ttf-indic-fonts-core package which is just a default set to save install/download time?
<cjwatson> robert_ancell: I'm pretty sure I've looked at that before and it's been quite a lot of work to merge - needs an equivalent of the -core stuff
<cjwatson> robert_ancell: I can have another go at it this week
<ochosi> robert_ancell: i managed to implement the XSetScreensaver timeout stuff we talked about yesterday in the gtk-greeter by the way (rev180). (it just won't work with nouveau for some reason :D)
#ubuntu-devel 2014-01-14
<robert_ancell> ochosi, how odd!? Does normal screensaver stuff work?
<robert_ancell> cjwatson, I'm working on merging it now, I *think* it's just a matter of making the -core package out of the existing packages, but not 100% sure I've missed something
<cjwatson> robert_ancell: well, if you can get it to work ... I'd suggest fairly careful upgrade-testing in schroot instances though
<cjwatson> I won't actually be *that* sorry to lose touched-it-last on that one
<ochosi> robert_ancell: yeah, within the session everything is fine, but XSetScreensaver (..) and XForceScreensaver don't seem to cause a reaction in the greeter (even though it's all plain xlib as far as i understand)
<robert_ancell> cjwatson, :)
<ochosi> i.e. "xset s $timeout" works also with nouveau during a session
<robert_ancell> ochosi, did you try calling xset from the greeter to confirm it's not your code?
<ochosi> robert_ancell: ehrm, how would i do that? is there an interactive console hidden in the greeter? :)
<robert_ancell> ochosi, I mean using system()
<ochosi> robert_ancell: ah, never tried that (and didn't know about it), thanks, will give that a go!
<Noskcaj> Can someone take a look at bug 1244629 ? It's my first attempt at an SRU bug
<ubottu> bug 1244629 in xfce4-weather-plugin (Ubuntu) "SRU xfce4-weather-plugin, currently showing 'No Data'" [High,Triaged] https://launchpad.net/bugs/1244629
<ochosi> robert_ancell: ok, seems like the values in X get set accordingly, the screen just doesn't blank with nouveau (i.e. something with the X11-screensaver extension seems borked there)
<Noskcaj> doko, Can you merge the NMU for python-werkzeug to ubuntu? It should fix the test failure
<robert_ancell> cjwatson, you blacklisted the fonts-* packages (http://paste.ubuntu.com/6748084/) "to conflicts with existing Ubuntu-versioned binaries" - I can't see any existing binaries with those names
<cjwatson> robert_ancell: that's the thing you're working on
<robert_ancell> cjwatson, the ttf-indic-fonts source package?
<robert_ancell> cjwatson, we appear to have all the font packages available (e.g. fonts-lohit-beng-bengali) which obsolete the ttf-indic-fonts binary packages
<cjwatson> robert_ancell: yes - fonts-beng ships a ttf-bengali-fonts binary package, which is currently in ttf-indic-fonts
<cjwatson> robert_ancell: does fonts-beng not need a -core version then?
<robert_ancell> cjwatson, no, fonts-beng just has "Depends: fonts-lohit-beng-bengali, fonts-lohit-beng-assamese, fonts-beng-extra"
<robert_ancell> and all those exist in the archive
<cjwatson> oh, it's actually a recent change for it to have dropped ttf-bengali-fonts
<robert_ancell> and fonts-indic just depends on fonts-beng and friends
<robert_ancell> yeah
<cjwatson> look at rmadison -u debian -S fonts-beng and you'll see what I mean
<cjwatson> so is it all fine enough grained now that we can just select a reasonably small set of fonts by package name?
<robert_ancell> no, but we have all the binary font packages there and not the metapackages
<cjwatson> one serif and one sans-serif per language was apparently the former criterion
<robert_ancell> so it seems like we might as well have those too
<cjwatson> we shouldn't sync if it's going to regress this though
<cjwatson> if we still need to apply a split, that's effectively a merge
<robert_ancell> we still have the old ttf-* package that is on the image, but it is just removed if you install the newer fonts-* packages
<cjwatson> sure, but that's not indicative in itself ...
<robert_ancell> cjwatson, so, you're saying we should hold back the metapackages until we have a solution for more finely grained fonts?
<cjwatson> I dunno, it's late.  Please batch up the set of things you think I should be removing from the blacklist and mail them to me so I can think about them when I'm awake?
<robert_ancell> sure, thanks
<slangasek> /usr/include/qt4/QtCore/qatomic_arch.h:98:38: fatal error: QtCore/qatomic_aarch64.h: No such file or directory
<slangasek> hmph
<Logan_> slangasek: I just got that same FTBFS on a package that I just uploaded
<slangasek> Logan_: cool, are you feeling inspired to track down the bug in qt4-x11? :)
<Logan_> I am actually feeling especially inspired today
<Logan_> lemme see what I can do
<Logan_> this came about with the latest upload, right?
 * Logan_ pokes shadeslayer just in case he's alive
<slangasek> no idea; I just saw it in an avahi build
<Logan_> looking at the diff
<Logan_> oh wonderful, it's making Firefox hang
<Logan_> https://launchpadlibrarian.net/162395910/buildlog_ubuntu-trusty-arm64.unixodbc-gui-qt_2.3.0-3ubuntu1_FAILEDTOBUILD.txt.gz is the other package that just FTBFSed on arm64, fwiw
<slangasek> O horror, a delta for unixodbc-gui-qt and you haven't forwarded it to the Debian maintainer ;)
<Logan_> oh hi maintainer :P
<Logan_> slangasek: I'm going to take a gander
<Logan_> I think:
<Logan_> -usr/include/qt4/Qt/qatomic_aarch64.h
<Logan_> in the .install diff has something to do with it :P
<slangasek> heh
<Logan_> the file still exists, so I think it's just a semi botched merge
<Logan_> should I try adding it back to the install file?
<slangasek> makes sense to me
<Logan_> watch this be maintained in a Bazaar branch
<Logan_> I hate it when that happens
<Logan_> oh, it's also in Main
 * Logan_ isn't a core dev :'(
<Logan_> slangasek: what should we do? you're a core dev, so you can upload to Kubuntu branches
<Logan_> slangasek: here's the relevant part of the diff: http://paste.ubuntu.com/6748482/
<Logan_> Riddell: Around?
<slangasek> Logan_: you could certainly do a bzr mp for it; grabbing the branch now to look
<Logan_> Kubuntu tends to ignore merge proposals on their branches, unfortunately
<Logan_> I've tried in the past
<Logan_> shoot, now Qt stuff in the rebuild queue is failing, which will create false positives
<Logan_> slangasek: unless you were to approve my mp? :P
<slangasek> I could presumably do this :)
<Logan_> okay, I'll propose in a few. I'll ping you
<Logan_> ...don't mind me
<Logan_> slangasek: here's your freshly-baked mp: https://code.launchpad.net/~logan/kubuntu-packaging/qt4-x11-arm64/+merge/201535
<Logan_> thanks Steve! :)
<slangasek> Logan_: sure thing :)  (now, finding all the bits so that I can actually upload it is another matter)
<Logan_> right
<Logan_> should we test it in a PPA first?
<Logan_> or is this relatively trivial?
<slangasek> Logan_: I'm not testing in a ppa.  Have you done a test binary build?
<Logan_> slangasek: I can't really do it locally - it takes 1.5 hours to build on the build
<slangasek> looks like it'll take another 4 minutes for the tarball to get here over the pub wifi, so you have time yet to test ;)
<Logan_> buildd
<slangasek> ah, k
<Logan_> so should I push to a PPA?
<Logan_> it'll probably take forever...
<slangasek> Logan_: nope, it's not worth taking the ppa time up for verifying something that's as low-risk as this
<Logan_> ok
<micahg> hggdh: thanks, done
<Logan_> hey Micah!
<Logan_> slangasek: How's it going?
<slangasek> Logan_: uploading now
<Logan_> sweet
<Netsnipe> hi everyone
<Netsnipe> does anyone know which package/project that the Ubuntu AMIs are covered by in Launchpad?
<Netsnipe> Ubuntu AMIs in AWS that is.
<Logan_> tumbleweed: Are you around?
<pitti> Good morning
<pitti> Logan_: indeed, I guess it's about time
<Logan_> pitti: Morning! I forget when it happened the last cycle. Should I check?
<pitti> Logan_: it's usually "when we have the feeling it's a good time" :)
<Logan_> Ah.
<Logan_> I'm indifferent, honestly. I've been getting hardly any crashes.
<pitti> there isn't that much churn on GNOME etc. that we expect much breakage in the beginning
<pitti> and we have errors.u.c., too
<Logan_> True.
 * Logan_ shrugs. Just a thought.
<Logan_> Maybe closer to Alpha 2 would make more sense.
<Logan_> That's when it was done for Oneiric, at least.
<Logan_> It was enabled on June 21 for Trusty, which was before Alpha 1. Hmm.
<pitti> right, that's our usual time
<Logan_> So I guess it makes sense to enable it now.
<Logan_> Especially since this will be an LTS. We want crash reports to be as visible as possible, I think.
<Logan_> slangasek: it built successfully on a few arches so far, so that's good - I'll try rebuilding the affected packages in the morning
<slangasek> Logan_: spiff, thanks
<dholbach> good morning
<Logan_> slangasek: https://launchpad.net/ubuntu/+source/unixodbc-gui-qt/2.3.0-3ubuntu1/+build/5455791 hooray
<mitya57> LoganCloud: thanks for fixing it!
<Laney> @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: Laney
<darkxst> Laney, can you take a look at gnome-themes-standard during your shift?
<Laney> okay
<doko> zul, ntdb needs a MIR (b-d of samba)
<doko> seb128, unicode-data needs a MIR (b-d of gucharmap)
<doko> same for the recommends of http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg ttf-indic-fonts
<seb128> doko, thanks for pointing it out
<doko> and see indicator-datetime and lightdm
<doko> and fonts-wqy-microhei
<seb128> ?
<seb128> doko, you are looking at component-mismatch?
<seb128> doko, those are not real issues, they are provides resolved in a confusing way because of ppc64el builds missing
<seb128> well, they are issues in the sense that we should make e.g unity-greeter and unity build on ppc64el
<seb128> it's just that e.g lightdm recommends a greeter, with unity-greeter as preferred, but that one is not available so it fallback to the gtk one
<seb128> the indicator has the same issue, it needs a rendered and our default one is unity
<seb128> doko, unicode-data ... https://launchpad.net/ubuntu/+source/unicode-data ... do you know why it was demoted in trusty?
<seb128> doko, it has a MIR approved/closed and was in main in saucy
<doko> seb128, maybe it did fell out, and pitti was quick to demote it? ;p
<doko> re-promoting
<seb128> I don't think pitti does archive admin cleanups nowadays, you need to find somebody else to point finger there ;-)
<seb128> danke
<doko> in the past he was quicker than I could fix bugs ;)
<mitya57> doko: fonts-wqy-microhei is a rename of ttf-wqy-microhei, if the previous one was in main the new one can also be safely promoted
<doko> micahg, yes, needs a MIR for xdelta3
<doko> mitya57, ^^^
<mitya57> Do renames really need a MIR?
<mitya57> Oh, or is it a new dependency?
<doko> mitya57, it's a new b-d
<Laney> Has our ubuntu delta been applied to fonts-wqy-microhei?
<mitya57> Laney: yes
<mitya57> I am amazed by the changelog, but it doesn't say anything about xdelta
<Laney> wow, that changelog
<doko> tkamppeter, pitti: please see the splix ftbfs in -proposed, seems to be apport related. https://launchpadlibrarian.net/162345035/buildlog_ubuntu-trusty-i386.splix_2.0.0%2Bsvn315-1fakesync1_FAILEDTOBUILD.txt.gz
<pitti> doko, seb128: no, I didn't touch component-mismatch recently
<doko> pitti, there was a smiley ...
<pitti> tkamppeter: ^ seems the merge/sync dropped our apport hook?
<pitti> doko: (no worries)
<mitya57> pitti: the changelog says "* Add apport hook on Ubuntu and derivatives (reduces the package delta)."
<pitti> yeah, I figure someone forgot to git add the file
<mitya57> Also, the restriction doesn't make much sense as Debian has apport package as well
<OdyX> tkamppeter already reported it to debian-printing, I'm waiting on the maintainer (or a patch). Best would be a normal bug with a patch that'd allow NMU.
<mitya57> doko: xdelta3 package looks sane to me, do you know any team that can be subscribed to bugs/
<mitya57> s/\//?/
<ggvaberi>  hello. I need to write bash script and need some gnome theme setting. for example icon-theme. I use gsettings command for it but not sure if this command is stable part of gnome. can i use this command and be sure that it will come with gnome always?
<doko> mitya57, fonts? desktop? enoclue
<mitya57> ggvaberi: Yes, gsettings is stable and is not going to go away
<mitya57> doko: It is a binary variant of diff/patch, mostly unrelated to fonts or desktop
<mitya57> Will you approve the MIR if I'll be the only person subscribed?
 * mitya57 was one who synced fonts-wqy-microhei, so I feel responsive for fixing the mess :)
<doko> mitya57, no, should be a team. seb128, could the desktop team do that?
<seb128> mitya57, doko: subscribe desktop-bugs if you want
<doko> thanks
<mitya57> I can't do that
<ggvaberi> <mitya57> thank you. :)
<doko> mvo, https://launchpad.net/ubuntu/+source/aptdaemon/1.1.1-1ubuntu2/+build/5304049/+files/buildlog_ubuntu-trusty-i386.aptdaemon_1.1.1-1ubuntu2_FAILEDTOBUILD.txt.gz
<ggvaberi> and one more question. Is possible to access to key org.gnome.desktop.interface icon-theme by dbus? for make alternate to this command 'gsettings get org.gnome.desktop.interface icon-theme' but using only dbus, without gtk gio or GSettings.
<mitya57> doko: bug 1268905 filed
<ubottu> bug 1268905 in xdelta3 (Ubuntu) "[MIR] xdelta3" [Undecided,New] https://launchpad.net/bugs/1268905
<mitya57> Had to submit a watch file to Debian for that :/
<mitya57> doko: please really subscribe desktop-bugs if you can
<doko> mitya57, seb128 has to do that
<doko> jamespage, please subscribe to the new packages in https://bugs.launchpad.net/ubuntu/+source/parsedatetime/+bug/1268909
<ubottu> Ubuntu bug 1268909 in python-recaptcha (Ubuntu) "[MIR] python-recaptcha and parsedatetime, b-d's of moin" [Undecided,New]
<seb128> doko, mitya57: done
<doko> mitya57_, promoted
<mitya57_> thanks!
<mitya57> Laney: hi, are you still piloting? Can you maybe upload lp:~kubuntu-packagers/kubuntu-packaging/qt, which fixes bug 1268690?
<ubottu> bug 1268690 in qt4-x11 (Ubuntu) "package libqtdbus4 (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/i386-linux-gnu/libQtDBus.so.4.8', which is also in package libqt4-dbus:i386 4:4.8.4+dfsg-0ubuntu22" [High,In progress] https://launchpad.net/bugs/1268690
<Laney> mitya57: ok
<mitya57> Thank you!
<Laney> xnox: could you please check the argyll merge?
<Laney> I'm not sure if your patch is obsoleted
<cjwatson> pitti: Are the precise language packs good to promote to -updates?
<pitti> cjwatson: I built them one week ago; I haven't heard any problems about them, so yes from my POV
<pitti> cjwatson: they were meant for 12.04.4 preparation, and we thought we'd build them early to have them in iso testing
<pitti> (and I checked a few of them with binary debdiffing)
<cjwatson> pitti: OK, cool, I'll see about copying those then
<pitti> $ sru-release --pattern precise language-pack-
<pitti> cjwatson: thanks
<cjwatson> Yep, I just found the operator guide off the AA wiki
<jodh> Laney: xnox is away this week.
<Laney> jodh: I see
<tumbleweed> LoganCloud: hi
<ahmed__> hi
<ahmed__> hi
<ahmed__> how to create .deb file ?
<ahmed__> I have project wanna to publish in .deb format
<davmor2> ahmed__: that is better asked on the #ubuntu-app-devel channel, but there are some wiki guides for building a deb package
<ahasenack> pitti: hi, around? Question about postgresql 9.1 -> 9.3 upgrade to trusty
<ahasenack> pitti: there is no 9.1 in trusty, and no 9.3 in < trusty, so if you upgrade, your db is gone (not erased, just not accessible)
<ahasenack> what's the plan, upgrade to 9.3 from apt.postgresql.org on ubuntu < trusty and then upgrade to trusty?
<pitti> ahasenack: why is -9.1 gone? it shouldn't get removed during upgrade, we have some special handling for that in update-manager
<pitti> ahasenack: the intention is that on upgrade you keep the precise (or saucy) -9.1 packages and the "obsolete version" debconf note which explains how to upgrade to 9.3
<ahasenack> pitti: 9.1 packages are not in trusty as far as I can see, only plperl, client and server-dev
<pitti> ahasenack: right, only -plperl, as we don't want to support *installing* -9.1 in trusty
<ahasenack> pitti: https://launchpad.net/ubuntu/+source/postgresql-9.1/+changelog rbasak pointed me at that
<ahasenack> pitti: the 9.1 packages were removed as far as I can tell, let me try to find sometihng in the logs
<pitti> ahasenack: we need plperl as precise's/raring's etc. plperl packages don't work in trusty, due to how perl is packaged; but the rest works
<pitti> ahasenack: yes, yes, I know
<pitti> ahasenack: they are removed from the trusty *archive*
<ahasenack> pitti: the machine was "accidentally" upgraded to trusty, I don't know who did it (it's a shared machine)
<pitti> ahasenack: but they shoudln't get removed *from your system* on upgrade
<ahasenack> pitti: so let me double check that, but the person who found this out had to install 9.1 from apt.postgresql.org
<pitti> ahasenack: ok, I'd need the /var/log/dist-upgrade/ logs for that, to see why postgresql-9.1 got removed
<ahasenack> ok
<pitti> it's certainly not intended that it gets removed; and as you say, this would lock you out from your clusters
<ahasenack> pitti: I think it was a hackjob, whatever happened release-upgrade wasn't involved, those logs are from may 2013
<ahasenack> pitti: I'll ping again if i find anything that points to a bug
<pitti> ahasenack: apt-get dist-upgrade should be fine, too
<pitti> ahasenack: do you know from which release it was upgraded? I can try in a chroot
<ahasenack> pitti: so keeping 9.1 would not be a release-upgade trick, just plain packaging deps
<ahasenack> pitti: I was told saucy, but i see commented quantal lines in sources.list
<pitti> ahasenack: right; the "trick" in u-m is just to avoid removing packages which went away
<pitti> ahasenack: i. e. usually u-m does that, but it shouldn't for postgresql
<ahasenack> ok, saucy, confirmed
<ahasenack> via .save files in sources.list.d
<pitti> I'll try after lunch
<jamespage> doko, ubuntu-server subscribed to those two packages
<Laney> @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:
<Laney> mitya57: I uploaded it
<Laney> there's some autopkgtest failures on excuses for the previous version
<mitya57> Laney: Thanks, will take a look at the failures
<mitya57> Oh, so all those users who filed those bugs were using -proposed :(
<Laney> yeah, it happens
<Laney> on the bright side it found a bug
<mitya57> Right :)
<mitya57> Humm, both those tests never passed, not sure if they should really block the migration
<hggdh> micahg: ubuntu-uploaders membership does not expire anymore
<mterry> @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: mterry
<barry> doko: how's the test rebuild going?  is there a new page with results?  the link you gave me last week still has no results for anything but main
<doko> barry, there's enough to fix in main ;)
<doko> barry, also, jamespage might want your help with python-django-compressor
<barry> doko: yeah ;)  i'm going to try to spend some time on that today.
<barry> jamespage: sure thing, feel free to ping me
<doko> cinder
<doko>   needs webop?
<doko> click:
<doko>   test failures
<doko> distro-info:
<doko>   test failures
<doko> genshi:
<doko>   test failures
<doko> germinate:
<doko>   test failures
<doko> grub2-signed:
<doko>   test failures
<doko> barry: ^^^ these are python3.4 as default related ftbfs
<barry> doko: ack.  i'll look at those first
<mterry> cyphermox, I'm looking at bug 1264630.  Do you have any background info on how safe that sync would be?
<ubottu> bug 1264630 in modemmanager (Ubuntu) "Sync modemmanager 1.0.0-1 (main) from Debian experimental (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1264630
<Laney> we already talked about that in #ubuntu-desktop earlier
<mterry> oh
<Laney> someone should have commented :(
<Laney> but cyphermox said he'd handle it, so I'd assign it to him and remove sponsors
<mterry> ok, will do
<micahg> hggdh: thanks
<knocte> Cimi: ping
<Cimi> knocte, pong
<knocte> Cimi: hey! been already a week since your review: https://code.launchpad.net/~knocte/ubuntu-themes/bring-back-zebra-striping/+merge/200429 why is not merged? I thought the bots would do it
<knocte> Cimi: if I'm missing some very important aspect about launchpad, please enlighten me!
<Cimi> knocte, I don't know :) I'll have a look later
<knocte> cool thanks :)
<Laney> knocte: Cimi: At the very least it hasn't been top approved
<knocte> Laney: what does that mean?
<Cimi> Laney, you right
<Cimi> Laney, top apprived
<Laney> Status: needs review
<Laney> -> approved
<knocte> oh thanks, is there any launchpad docs where it explains this better? I find https://dev.launchpad.net/UsingMergeProposals a bit lacking
<Laney> umm, not sure, it's part of the Ubuntu-specific CI process
<Laney> https://wiki.ubuntu.com/DailyRelease/ & friends is probably useful, although that is being redesigned a bit atm
<knocte> Laney: cheers
<zul> doko/barryw: doko ping
<doko> ?
<zul> doko:  python-lxml  imports beautifulsoup but there is not build dependency? does that make sense
<doko> zul, maybe not
<tumbleweed> isn't that only in the soupparser module?
<zul> doko:  im asking because beautifulsoup is in universe and bs4 is in main
<LoganCloud> Tumbleweed: I noticed that you originally added DDE support to pull-lp-source. It appears to be dead, so the script now hangs for a bit, trying to resolve it, if you don't specify an actual package
<rbasak> I'm about to upload an apache2 merge, where some functionality has moved to a different source package (mpm-itk) that has already synced to universe. There's a transitional binary generated by the apache2 source now, which depends on that. How do I get that transitional binary overriden to universe, and is this the right thing to do?
<rbasak> (I'm not sure that we need an MIR for mpm-itk, but in any case I'd like to at least get apache2 done first)
<cjwatson> rbasak: tell #ubuntu-release when it appears in NEW
<rbasak> OK, thanks.
<cjwatson> rbasak: or just don't worry about the overrides and we'll figure it out
<rbasak> Great. Just wanted to make sure that I'm not causing trouble :)
<infinity> rbasak: Well, we need to make a decision (you need to make a decision) about whether you want to support mpm-itk installations, and thus move it all to main, or vice versa.
<infinity> rbasak: But yeah, if your take is that the install base is low, you don't care about main-only upgrades, and you'd rather have itk in universe, that'll pretty much sort itself, cause we'll demote things the tools tell us to demote due to not being seeded.
<rbasak> Hmm. It looks like apache2-mpm-itk has always been in universe, so maybe it's overridden already.
<glass|2> hi, i've unsquashed and then resquashed filesyste.squashfs, rebuilt the iso but at boot it show only a initrd shell. how fix this?
<mterry> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<mterry> @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:
<mterry> ahem
<tumbleweed> LoganCloud: aah, best solution is probably to fix DDE
<LoganCloud> Tumbleweed I have no idea how long it's been dead
<tumbleweed> yeah, I always use src: syntax
<LoganCloud> Maybe we should contact the maintainer
<LoganCloud> Lunch, bbl
 * cjwatson swears at hg and runs "git hg clone http://hg.python.org/cpython" so he has some hope of deciphering the history
<tumbleweed> LoganCloud: erm, seems to be working just fine for me
<LoganCloud> Tumbleweed http://dde.debian.net/dde/
<LoganCloud> Couldn't connect to server
<tumbleweed> oh, I lie
<tumbleweed> I'll poke enrico
<LoganCloud> Ok thanks
<tumbleweed> LoganCloud: apache seems down on that box
<kentb> is there a way to test whether or not a fix works for a ftbfs on ppcel64?
<kentb> err ppc64el
<cjwatson> No porter boxes as yet, but you can often guess fairly reliably by e.g. observing whether a build on another architecture updates the autotools files that need to be updated
<cjwatson> (Or rather, not ones that are generally available)
<kentb> ok. thanks!
<kaie> Hi darkxst: Regarding your gdm update 3.0.4-0ubuntu15.2 which is used on 12.04 lts. It broke automatic startup of the display manager. On my system, the plymouth-ready event, which have added as a precondition for starting gdm, is never produced.
<kaie> I had to remove that precondition from /etc/init/gdm.conf
<kaie> I sent email to Tim. Cheers
<Logan_> How can we bootstrap ghc for arm64 and ppc64el? It needs itself apparently...
<Logan_> Oh, never mind. I see the ML thread.
<Logan_> cjwatson: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2013-December/014796.html Any chance of getting that going?
<cjwatson> Logan_: I tried for ppc64el, still haven't got it working
<Logan_> :/
<cjwatson> Logan_: (but not given up)
<Logan_> so much yellow in the FTBFS list, lol
<cjwatson> Logan_: AFAIK arm64 needs upstream work; maybe with 7.8
<cjwatson> Logan_: I did get a stage1 ghc that sort of worked to the point of producing a useful hello-world, but it crashed upon trying to do anything complicated
<cjwatson> Logan_: and unfortunately it tends to take hours per iteration
<cjwatson> (to build on my laptop, that is)
<cjwatson> so, yeah.  will try again soonish
<Logan_> ah, cool. thanks for your work!
<Laney> keep an eye on https://ghc.haskell.org/trac/ghc/ticket/7942
<barry> infinity, wgrant: doko said i should ping you about his test rebuild and put backs.  i just uploaded a new version of nose to the main archive, which should fix several of his build failures.  can you copy these to his test-rebuild-20140108 and put back the following packages: pastedeploy, python-dbusmock, python-oauthlib, python-webob ?  (if webob builds okay, then there will be a couple more retries)
<infinity> barry: If it's already built and in the release pocket, there's nothing to copy.  Just some give-backs.
<barry> infinity: cool.  nose 1.3.0-2.1ubuntu1 hasn't been promoted from proposed yet, so i'll wait for that and then ping you for the retries
<barry> infinity: https://launchpad.net/ubuntu/+source/nose/1.3.0-2.1ubuntu1
<infinity> barry: Yeah, found it. :)
<barry> :)
<infinity> barry: Looks like you just got promoted.
<jtaylor> barry: would you sponsor a cython test fix?
<jtaylor> I want to get numpy in, but I guess I need to fix cython first :/
<jtaylor> at some point we need 0.20 for py3.4
<jtaylor> but its not released yet
<barry> infinity: yay!  can you do the give backs?
<infinity> barry: Once the publisher's done, yeah.
<barry> jtaylor: sure, i'll take a look
<barry> infinity: thanks
<barry> jtaylor: if you tell me where to look ;)
<jtaylor> its not done yet, just checking if some one would look at it
<barry> jtaylor: ah, okay.  nearing eod but i'll be here for a little while longer
<jtaylor> I'll file a merge tomorrow, won't get a build done today anymore, takes about 3 hours :/
<barry> jtaylor: lucky for you i'm also piloting tomorrow :)
<jtaylor> are there any plans to backport a way to get the multiarch tag to precise?
<jtaylor> I'm guessing no, but it makes it impossible to propose sane fixes to upstreams :/
<jtaylor> *from python
<infinity> barry: Those 4 seemed to be much happier.
<barry> infinity: awesome, thanks.  will look in a sec
<barry> infinity: looking good!  can you retry cinder (might work with the new webob now)
<infinity> barry: That's not going to work.  The rebuild archive doesn't rebuild against itself, only against the primary archive (it throws away the binaries).
<infinity> barry: But if the goal here is to make these all have py3.4 support, perhaps some archive uploads are in order?
<barry> infinity: ah, didn't know that.  yep, i'll take it from here.  thanks
<apb1963> Setting up google-chrome-stable (32.0.1700.77-1) ...
<apb1963> /var/lib/dpkg/info/google-chrome-stable.postinst: 26: /var/lib/dpkg/info/google-chrome-stable.postinst: update-desktop-database: not found
<apb1963> oops.  Sorry
<apb1963> Wrong button
<apb1963> Does anyone know how to update Qt to a later version? Kubuntu 12.04.3, KDE 4.12.0, Qt 4.8.2
<apb1963> In reference to
<apb1963> Setting up google-chrome-stable (32.0.1700.77-1) ...
<apb1963> /var/lib/dpkg/info/google-chrome-stable.postinst: 26: /var/lib/dpkg/info/google-chrome-stable.postinst: update-desktop-database: not found
<apb1963> dammit
<apb1963> In reference to: https://bugs.kde.org/show_bug.cgi?id=329793
<ubottu> KDE bug 329793 in general "Krash!" [Crash,Resolved: upstream]
<apb1963> Which just happened to me again now.
<sarnold> apb1963: yikes. if you do replace your qt with upstreams, you're going to be on one funky system...
<sarnold> apb1963: have you filed the bug against ubuntu yet?
<apb1963> Well, it seems my system is already funky
#ubuntu-devel 2014-01-15
<apb1963> Which bug?  The bug in Qt?
<sarnold> yes
<apb1963> No
<apb1963> It was suggested I install 4.8.5.. since the bug is in 4.8.2, it doesn't seem likely that anyone will care.
<sarnold> except we've decided to support 12.04 LTS for another three years..
<apb1963> that's the story yes
<apb1963> Lord, there's page after page after page of how to report a bug and I've yet to find the link to actually report the bug.
<sarnold> apb1963: try: ubuntu-bug konversation
<apb1963> And is that different from https://bugs.kde.org/show_bug.cgi?id=329793
<ubottu> KDE bug 329793 in general "Krash!" [Crash,Resolved: upstream]
<sarnold> apb1963: yes, that would be filed in the launchpad bug tracker, where probably ScottK would find it and look into it..
<apb1963> great.  Thank you for that.
<apb1963> ugh
<apb1963> apport crashed
<sarnold> o_O
<sarnold> you very well might have a funky system, hehe. is there anything informative in dmesg or /var/log/  about it?
<sarnold> (I had a system with machine check exceptions, it wasn't much fun..)
<apb1963> you mean besides neverending dhcp requests?  No.
<sarnold> :(
<apb1963> so... ubuntu-bug apport then?
<sarnold> worth a shot, it just might work.. :)
<sarnold> (it _should_ work, but it already crashed once on you..)
<apb1963> wait.... just noticed this.... prepare for minor flooding
<apb1963> ubuntu-bug konversation
<apb1963> python: ../../src/xcb_io.c:529: _XAllocID: Assertion `ret != inval_id' failed.
<apb1963> KCrash: Application '' crashing...
<apb1963> KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
<apb1963> sock_file=/home/apb/.kde/socket-asterisk.saveabunny.com/kdeinit4__0
<apb1963> QSocketNotifier: Invalid socket 68 and type 'Read', disabling...
<apb1963> here's how I came to be... first I installed the mini iso for i386... then I installed kubuntu-desktop... and other stuff.
<Logan_> apb1963: Have you updated?
<apb1963> Every 20 minutes
<Logan_> apt-cache show apport
<Logan_> Which version do you have?
<apb1963> Version: 2.0.1-0ubuntu17.6
<Logan_> Hmm, yeah, you're updated.
<apb1963> Depends: python (>= 2.6), python-apport (>= 2.0.1-0ubuntu5), lsb-base (>= 3.0-6), python-gi, gir1.2-glib-2.0 (>= 1.29.17), sysv-rc (>= 2.86.ds1-14.1ubuntu2), upstart-job
<Logan_> You might want to take this to #ubuntu. This is a development channel.
<apb1963> That's where I started 6 hours ago
<Logan_> Or maybe even #kubuntu.
<apb1963> So crashing software is not a development problem
<Logan_> Well, it's more of a support problem if it's not occurring in a development release.
<apb1963> yeah, they both passed the buck
<apb1963> as did #kde, #kde-devel, #plasma and #konversation... though admittedly it's a library issue so it's amazing they were among the most helpful.
<apb1963> Until finally someone said:
<apb1963> <Sho_> I mean, I thought the idea behind LTS was 'get bigfixes really long'
<apb1963> [Tuesday, January 14, 2014] [03:46:24 PM] <Sho_> *bugfixes
<apb1963> [Tuesday, January 14, 2014] [03:47:00 PM] <PovAddictW> fsvo "bugfixes"
<apb1963> [Tuesday, January 14, 2014] [03:48:03 PM] <PovAddictW> actually, 4.8.5 isn't available even in the latest ubuntu
<apb1963> [Tuesday, January 14, 2014] [03:50:43 PM] <apb1963> who normally takes care of something like that?
<apb1963> [Tuesday, January 14, 2014] [03:52:37 PM] <PovAddictW> ubuntu developers
<apb1963> And so I came here
<sarnold> apb1963: well, you can start with this: https://bugs.launchpad.net/ubuntu/+source/konversation/+filebug -- be sure to refernce the kde.org bugreport you filed earlier; it'd be a help if you could copy and paste the traceback, too.
<sarnold> apb1963: once it's done, run "apport-collect <bugnumber>" -- and see if that runs or crashes..
<apb1963> i'm actually installing debug symbols now
<apb1963> what do I fill in for <bugnumber> ?
<sarnold> whatever bug number you get from filing the bug manually at https://bugs.launchpad.net/ubuntu/+source/konversation/+filebug
<apb1963> got it
<apb1963> not positive since I got no feedback... but I think it's done.
<apb1963> still waiting on debug symbols for apport
<sarnold> apb1963: what bug number?
<apb1963> apport-collect 1269199
<YokoZar> bdrung: https://github.com/YokoZar/ppa-stats   <-- What do you think for inclusion in ubuntu-dev-tools ?
<YokoZar> (gets download counts for a PPA)
<Logan_> mfisch: Are you around?
<doko> barry, for simple rebuilds which require 3.4 as the default we now have the https://launchpad.net/~ubuntu-toolchain-r/+archive/python3 ppa.
<pitti> Good morning
<pitti> infinity, RAOF: can you please set an exfail for colord 1.0.5-1's autopkgtest? colord newer worked
<pitti> (holding up systemd)
<RAOF> Bah, sorry.
<RAOF> pitti: I don't know how to set an exfail, sorry.
<doko> pitti, do you feel good enough to look at zeitgeist test failures?
<pitti> RAOF: right, that was more like a CC:
<doko> https://launchpad.net/ubuntu/+archive/test-rebuild-20140108/+build/5433297
<pitti> seiflotfy__: ^
<pitti> seiflotfy__: not very verbose, thanks to that silly automake parallel runner :(
<doko> which timezone is he?
<pitti> British or Central European, I think
<pitti> so, still a bit early for hackers
<seiflotfy__> doko: i thought i fixed thoise
<seiflotfy__> let me have a closer look
<seiflotfy__> vala keeps changing and zeitgeist keeps breaking
<doko> seiflotfy__, seen in a test rebuild, so you need to update to trusty
<seiflotfy__> thi is based on the latest release not git right?
<doko> seiflotfy__, what you find in trusty
<doko> 0.9.14-0ubuntu3
<seiflotfy__> where can i find the source of this package?
<seiflotfy__> doko:
<seiflotfy__> nm
<doko> apt-get source zeitgeist, if you are running trusty
<doko> or dget <find the dsc file>
<pitti> seiflotfy__: it's upstream 0.9.14 plus a few patches: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/zeitgeist/trusty/files/head:/debian/patches/
<pitti> seiflotfy__: the first two patches are harmless, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/zeitgeist/trusty/view/head:/debian/patches/pre_populator.patch looks more interesting
<seiflotfy__> ouh nice
<pitti> seiflotfy__: more generally, I think there was a way to make failures less ridiculously useless with the automake 1.13 parallel runner
<pitti> i. e. more than just "FAILhahagofigure"
<seiflotfy__> i think i know what it is
<seiflotfy__> but cant do patching right now
<pitti> some "verbose" flag, if only I could remember
<seiflotfy__> doko: pitti can one of view try someting for me please?
<pitti> seiflotfy__: sure
<seiflotfy__> pull the latest code from git and tell me if it works for you "make check"
<seiflotfy__> because we had a "not building" issue when vala 22 came out and we fixed it just recently
<seiflotfy__> pitti: ?
<pitti> seiflotfy__: yes, on it; currently in daily dist-upgrade, need to wait until I get apt again for its build deps
<seiflotfy__> ok cool
<pitti> http://cgit.freedesktop.org/zeitgeist/zeitgeist/ ?
<pitti> seiflotfy__: I try building the package with http://cgit.freedesktop.org/zeitgeist/zeitgeist/commit/?id=42f0f6b0f17a584b703981b8a392c3225c7a8e98 until the git checkout finishes (that takes a while)
<seiflotfy__> yes sir
<seiflotfy__> thats the patch
<pitti> seiflotfy__: indeed, that helps quite a bit
<pitti> now test/c has two failures
<pitti> test/direct now succeeds
<seiflotfy__> oh man, vala can really take a toll on me sometimes
<seiflotfy__> ok upgrading a vm here  test this
<pitti> seiflotfy__: git checkout done, building trunk here
<pitti> seiflotfy__: the previous patch doesn't look like a vala-ism, though?
<seiflotfy__> it is
<seiflotfy__> because it worked with vala 20
<seiflotfy__> but not with vala 22
<seiflotfy__> we did not commit any changes in 6 months
<seiflotfy__> so we did this to fix it for vala 22
<pitti> oh, you disabled optimize_variant_allocation()
<seiflotfy__> yes sir
<pitti> trunk "make check" WFM
<seiflotfy__> show me the failure print out for test/c
<seiflotfy__> i have thin i know what it is
<pitti> could be because package build runs tests under fakeroot or something; "fakeroot make check" fails early, but our package has some "disable_failing_tests.patch" for that AFAICS; hang on
<doko> pitti, which b-d am I missing when I see
<doko> telepathy-farstream/Makefile.am:69: HAVE_INTROSPECTION does not appear in AM_CONDITIONAL
<pitti> seiflotfy__: http://paste.ubuntu.com/6754838/
<pitti> doko: probably "gobject-introspection"?
<doko> thanks
<seiflotfy__> pitti: fixing it
<pitti> seiflotfy__: oh, you have an idea? it happens during package build, but not with a plain "make check", even in our package tree
<pitti> probably the package build cleans the environment
<pitti> seiflotfy__: ah -- "env -i make check" in trunk reproduces it
<pitti> seiflotfy__: for you, too?
<seiflotfy__> yeah
<seiflotfy__> it stilly
<seiflotfy__> in test/c/test-event.c line 29
<seiflotfy__> 39
<seiflotfy__> sorry
<seiflotfy__> setting the xdg directory fails
<seiflotfy__> it used to be
<seiflotfy__>   if (old_xdg_data_dirs != NULL)
<seiflotfy__>     old_xdg_data_dirs = g_getenv ("XDG_DATA_DIRS");
<seiflotfy__> but that segfaulted when i did make checks
<pitti> seiflotfy__: oh, so in teardown() the g_setenv() gets a NULL
<seiflotfy__> yeah
<pitti> seiflotfy__: indeed, no XDG_DATA_DIRS during package build
<pitti> so that's a simple fix
<seiflotfy__> can you send me a patch or so
<seiflotfy__> i need to shower and dress up (and get spanked at work)
<seiflotfy__> pitti: ^
<pitti> seiflotfy__: yes, on it
<pitti> seiflotfy__: http://people.canonical.com/~pitti/tmp/0001-Fix-unit-test-failure-if-XDG_DATA_DIRS-is-not-set.patch
<pitti> seiflotfy__: want me to attach that to a bug report, or can you just push it? (it's trivial)
<seiflotfy__> bug if poosible
<pitti> seiflotfy__: https://bugs.freedesktop.org/show_bug.cgi?id=73651
<ubottu> Freedesktop bug 73651 in Engine "tests fail if $XDG_DATA_DIRS is not set" [Normal,New]
<pitti> doko: zeitgeist fix upstreamed ^ and test-built in sbuild, uploaded
<doko> pitti, seiflotfy__: nice!
<doko> pitti, fyi, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140108-trusty.html
<doko> will send an announcement later today
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<pitti> doko: looking at cdbs test failures -- is dh_python2 supposed to stop moving files to /usr/share/pyshared/ ?
<pitti> the package calls dh_python2 and then expects /usr/share/pyshared/testing/foo.py; but there is only ./usr/lib/python2.7/dist-packages/testing/
<Logan_> doesn't it still create symlinks?
<Logan_> I could be wrong, though
<doko> pitti, yes, disabled that. upstream did start working around it for some reason
<pitti> that's what I thought; file in /usr/share/pyshared/
<pitti> and symlinks in /usr/lib/python*
<doko> had to revert some upstream commits
<doko> need to forward and propose that to debian
<pitti> hm, I remember http://bugs.python.org/issue19352, but that was only for unittests, not general module loading
<pitti> doko: forward the reversion of upstream commits, or drop the /usr/share/pyshared/ moving?
<pitti> doko: in other words, should I adjust cdbs' tests to not expect /pyshared any more, or will pyshared reappear soon?
<doko> pitti, no, it should not reappear. but when you forward, please say that this is not yet in debian
<pitti> ack
<pitti> doko: ah, from https://launchpad.net/ubuntu/+source/dh-python/1.20131021-1ubuntu5 ?
<doko> yes
<doko> pitti, looks like you were even involved with that: http://bugs.python.org/issue19352 ;p
<pitti> doko: right, what I wrote 5 mins ago; but that was only for unittest
<pitti> doko: and I uploaded a reversion of that patch to fix that (you said "go ahead" with that back then)
<doko> sure
<twb> Is there a standard place in a lp ppa that says "this isn't in main because <details>" ?
<twb> Specifically I'm looking at https://launchpad.net/~arminha/+archive/python-aosd-release and I can't see such a thing; plan B is to email the maintainer (who is also upstream) and ask him.
<pitti> doko: http://paste.ubuntu.com/6755022/ works now; does the changelog entry make sense?
<doko> pitti, sounds fine
<pitti> doko: ack, uploading and forwarding
<Logan_> twb: no, there is no standard for that - better to do your plan B
<twb> OK, thanks.
<doko> pitti, does the test succeed without and with it?
<pitti> twb: PPAs don't care much about components
<pitti> doko: sorry, without what?
<doko> pyshared
<pitti> doko: tests currently fail because dh_python doesn't do pyshared any more
<pitti> that's the reason for the FTBFS
<doko> pitti, right, but does your updated version succeed in debian too?
<pitti> i. e. dpkg -c | grep -q '/usr/share/pyshared/testing/foo.py'
<pitti> fails
<pitti> doko: I'll sbuild it in sid as well to make double-sure, but I don't see why not -- there's still the symlink, right?
<doko> yes
<zyga> good morning :-)
<pitti> if that file wouldn't exist, python couldn't import it; that's how I wrote the changelog
<pitti> hey zyga
<pitti> doko: looking at pkgbinarymangler, too
<Laney> hmm
<Laney> anyone using debmirror? I started getting "rsync error: error in rsync protocol data stream (code 12) at io.c(605) [Receiver=3.0.9]
<Laney> Warning: failed to use rsync to download extra files.
<Laney> " lately
<zyga> Laney: I was using it extensively until recently
<zyga> Laney: which repository caused that problem for you?
<Laney> yeah, the cronspam doesn't say sadly
<zyga> Laney: (though I never saw anything like that)
<Laney> it's doing ubuntu, ports and debian
<zyga> Laney: hmm, well, I haven't kept my mirror up to date for a few weeks so I don't know
<zyga> Laney: but I should be able to tell you if I see that later today
<Laney> okay
<doko> pitti, the folks ftbfs looks vala related
<pitti> doko: pkgbinarymangler FTBFS fix uploaded
<ekarlso> -/win 22
<didrocks> hum
<didrocks> Your mail to 'ubuntu-devel' with the subject
<didrocks>     Post by non-developer to moderated list.
<didrocks> I sent from didrocks@ubuntu.com
<doko> didrocks, demoted ;p
<didrocks> doko: seems so ;)
<seiflotfy__> pitti: your patch works fine
<seiflotfy__> pitti: trying to release a new package
<doko> didrocks, you can re-enable that by fixing ten ftbfs issues ;)
<didrocks> no, still in it seems: https://launchpad.net/~ubuntu-core-dev/+members#active ;)
<pitti> seiflotfy__: ah, good; I added the patch to our package, it built fine now
<didrocks> doko: can I get a cookie then? ;)
<seiflotfy__> but it keeps complaining about install -D ../../../doc/libzeitgeist/zeitgeist-gtkdoc-index.sgml docs_c/zeitgeist-2.0-docs.xml
<seiflotfy__> install: cannot stat â../../../doc/libzeitgeist/zeitgeist-gtkdoc-index.sgmlâ: No such file or directory
<pitti> seiflotfy__: so, no urgency from my side
<doko> didrocks, not only one, ten!
<pitti> seiflotfy__: hm, autogen.sh'ed without --enable-gtk-doc or so?
<didrocks> heh
<seiflotfy__> o hyeah
<seiflotfy__> my bad
<seiflotfy__> ok will roll out a release then :D
<seiflotfy__> pitti: will release on friday? is this ok? can you guys use the current git status...
<seiflotfy__> ?
<pitti> seiflotfy__: as I said, not urgent for us, I added the patch to our package already
<seiflotfy__> ok cool
<pitti> @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: pitti
<doko> mlankhorst, do you care about the libxcb transition?
<mlankhorst> erm why?
<doko> mlankhorst, soname change?
<mlankhorst> hm not particularly care, but it sounds like something that would need solving :/
<doko> then please do
<mlankhorst> did any soname change then? I thought it was just adding present/dri3
<seb128> mlankhorst, http://packages.qa.debian.org/libx/libxcb/news/20131227T000024Z.html has "Rename libxcb-sync0 for SONAME bump. "
<mlankhorst> oh indeed
<mlankhorst> libqt5gui5 and kde-window-manager depend on it, it seems
<doko> mlankhorst, honestly you should be aware of such changes *before* you upload ;p
<mlankhorst> if it was anything important or commonly used thing I would have noticed at least
<doko> seb128, do you know why nobody added the ubuntu fonts to the fontconfig conf?
<seb128> doko, I guess because nobody is actively maintaining fontconfig
<doko> seb128, then why are you uploading new upstreams? ;-P
<seb128> doko, because nobody else does and that's better than nothing ;-)
<doko> seb128, could you merge the debian changes? would like to avoid interaction ...
<seb128> doko, is there anything in there we specially need?
<seb128> that merge is non trivial and I would prefer to let it to somebody who knows fontconfig a bit better than me
<Laney> I don't know that it's safe to add the Ubuntu font there yet
<Laney> sladen or someone knowledgable on the subject would be better to ask
<darkxst> Laney, thanks for getting the cogl transition rolling ;)
<Laney> darkxst: np, it's basically done now
<Laney> looking at the last issue
<doko> Laney, well, why not? the ubuntu fonts are not that new. is sladen still working on these?
<Laney> somewhat
<Laney> It's whether they can be substituted for other fonts without it looking weird
<Laney> why don't you try it on your system?
<seb128> well, it's not easy to try if you don't know what to look for
<seb128> like you might need to look at office documents to see if it impacts on layouting there
<doko> Laney, send me a patch and I'll check. just was looking at why openjdk didn't use these. and it's using fontconfig now
<Laney> nice try :P
<Laney> how do I get to a BPPH on launchpad's web interface?
<cjwatson> https://launchpad.net/ubuntu/trusty/i386/groff-base
<Laney> ta
<cjwatson> You can search from the distroarchseries I think, but I find memorising the URL pattern easier :)
<Laney> ok that doesn't help
<cjwatson> (OK, you need to append the version to get the BPPH as such)
<cjwatson> What are you looking for?
<Laney> what happened to toonloop/arm64?
<Laney> cogl transition, see update_output
<cjwatson> That was in p-m's output before the cogl transition
<cjwatson> update_excuses is clearer in this case; it's depending on things not ported yet
<Laney> so it never migrated on arm64
<Laney> ?
<cjwatson> Indeed
<cjwatson> If it weren't built on arm64/ppc64el at all, it would be OK, but since it is it isn't allowed to increase the uninstallable count
<cjwatson> It might actually be simplest to port gstreamer0.10-plugins-bad and mencoder
<cjwatson> (Haven't looked at what's blocking those)
<mitya57> Hi, I need some advice on bug 1269203. If the package tries to overwrite files in libqt4-dbus:[ARCH], is Breaks/Replaces on libqt4-dbus (<< ...) not enough?
<ubottu> bug 1269203 in qt4-x11 (Ubuntu) "package libqtdbus4 4:4.8.5+git192-g085f851+dfsg-2ubuntu3 failed to install/upgrade: trying to overwrite '/usr/lib/x86_64-linux-gnu/libQtDBus.so.4', which is also in package libqt4-dbus:amd64 4:4.8.4+dfsg-0ubuntu22" [Undecided,New] https://launchpad.net/bugs/1269203
<mitya57> Do I need Breaks/Replaces on libqt4-dbus:any in that case?
 * s1aden reads scrollback re Laney and doko
<sladen> Laney: there are certainly some fallbacks we could set to eg. have the monospace fallover to other monospace fonts, (rather than to something proportional in cases like arabic)
<sladen> Laney: I guess it was not necessary to add it, since external documents coming are requesting things like "Times" "Helvetica", and those are what you need to provide substitutes for
<sladen> Laney: whereas something asking for Ubuntu, on an Ubuntu system is likely wanting Ubuntu
<sladen> Laney: (and going to suceed)
<doko> sladen, I was reading #937200 and #1003857
<doko> so should apps asking for serif or sans get dejagnu or ubuntu?
<doko> dejavu even
<mlankhorst> ok just a rebuild bump for qtbase-opensource-src and kde-workspace is enough for the libxcb-sync transition
<mlankhorst> abi didn't even changed, just some symbols were removed and that triggered the soname bump
<Laney> cjwatson: oh, it migrated anyway
<pitti> happyaron: should I sponsor bug 1266520, or are you on it? (also relevant for Debian)
<ubottu> bug 1266520 in ibus-pinyin (Ubuntu) "ibus-setup-pinyin aborts with ImportError" [High,Triaged] https://launchpad.net/bugs/1266520
<Riddell> mlankhorst: give us a ping if there's a change to be merged into kde-workspace packaging branch
<streulma> hello, I see nothing difference between 13.10 and 14.04 for the moment
<Laney> at least your system isn't broken :P
 * ogra_ sees massive differences ... on his phones and tablets :)
<mitya57> hello, I see nothing difference between Ubuntu and OS X for the moment
 * mitya57 hides
<Laney> we have a modern bash version
<ogra_> mitya57, you forgot to mention the versions :P
<mlankhorst> Riddell: ok
<mitya57> And gcc :P
<mlankhorst> Riddell: no change rebuild incoming :P
<streulma> is it normal that the ubuntu sound is lower at starting dvd?
<ogra_> streulma, see the channel topic, this is no support channel, please go to #ubuntu for support
<streulma> the tamtam is different from earlier versions
<streulma> I speak about trusty :p
<Laney> try #ubuntu+1
<ogra_> right
<Riddell> mlankhorst: got a debdiff?
<mlankhorst> https://launchpad.net/ubuntu/+source/kde-workspace/4:4.11.5-0ubuntu2 somewhere
<Riddell> :)
<mlankhorst> doko: ping
<pitti> tjaalton, mlankhorst: is https://code.launchpad.net/~mitya57/ubuntu/trusty/xkeyboard-config/2.10.1-1ubuntu1/+merge/200141 something you want to handle in your team? (e. g. a two-way merge with Debian, some of our changes are useful for Debian as well)
<mlankhorst> I thought xkeyboard was generic low level stuff, not x specific?
<pitti> I don't know -- it's just a question
<pitti> I'm happy to review/sponsor it, too
<tjaalton> hmm, could push some of that to debian
<tjaalton> mlankhorst: it's on package-status.html, and x-swat is sub'd to the bugs ,)
<tjaalton> ;)
<mlankhorst> well if you want to take it
<mitya57> I didn't forward my changes to Debian because I prefer to get them applied upstream first
<mlankhorst> erm for debian the changes should go into upstream first, because of policy :P
<mitya57> Didn't know about that, but I agree :)
<tjaalton> i'm fine with pushing the merge to trusty as-is
<tjaalton> but stuff like multiarch and split xkb-data-i18n could probably be used by debian as well
<mlankhorst> yeah
<tjaalton> mitya57: are you a member of pkg-xorg on alioth?
<mlankhorst> I'm testing why I get a kernel panic with nouveau from time to time atm
<mitya57> tjaalton: No :(
<tjaalton> mitya57: it's trivial to get accepted
<mitya57> Please push it yourself if you can (and agree with the changes)
<tjaalton> sure
<tjaalton> but we host our git branches there as well
<tjaalton> so you could just merge there and directly ask us to sponsor (we're on #ubuntu-x)
<tjaalton> in the future I mean :)
<mitya57> ok, will know
<mlankhorst> yeah git is preferred :)
<mitya57> pitti: thanks for sponsoring all my packages!
<pitti> mitya57: yw!
<doko> mlankhorst, just ask
<mlankhorst> doko: how do I use hardening-wrapper in xorg-server?
<doko> mlankhorst, ugh ... never did use this. maybe ask jdstrand or mdeslaur?
<mdeslaur> mlankhorst: sbeattie can provide guidance when he arrives
<pitti> tjaalton, mitya57: ok, not touching xkeybaord-config then?
<tjaalton> pitti: nah feel free to
<pitti> ack
<doko> pitti: don't know who is responsible for platform-api ... but it sits in component-mismatches, and I doubt we want lcov in main
<rharper> hallyn: https://code.launchpad.net/~raharper/qa-regression-testing/scripts-test-qemu-fixups  -- this passes all 22 tests on a trusty vm -- I'm going to run against the previous releases next to make sure I didn't regress any tests
<pitti> doko: that was tvoss, I think
<hallyn> rharper: awesome, thanks
<rharper> np
<rharper> hallyn: once I confirm I didn't regress, should I propose for merging ?
<hallyn> rharper: yeah that'd be good
<rharper> cool
<hallyn> rharper: we can ask whether jdstrand wants to review it, if not I *think* I can merge it
<rharper> ok
<hallyn> jdstrand: speaking of reviews, who should I be bribing^Wasking about getting a security review of the cgmanager package at lp:~serge-hallyn/+junk/cgmanager ?
<hallyn> jdstrand: aside from a security review of the code,I'd also like to re-review the design to discuss whether I'm opening up any possibilities for unprivileged users to abuse privileged ones
<hallyn> jdstrand: so if anyone from security team will be in london we could do it in person there perhaps
<jdstrand> re that merge> isn't that going to fail on earlier releases?
<infinity> pitti: colord hint bumped.  Is there a Debian bug, or anyone with an urge to fix it? :P
<jdstrand> hallyn: re cgmanager> probably sarnold (code mostly) and mdeslaur (design mostly)
<jdstrand> hallyn: we won't be
<pitti> infinity: thanks; RAOF looked into it recently, but there's still one failure left (no bug ATM)
<hallyn> jdstrand: I haven't looked at the merge proposal yet for qrt
<jdstrand> rharper (and hallyn): it seems the test-qemu.py fixes need to be made trusty-specific and remain unchanged for earlier releases. we use these scripts for security updates
<hallyn> jdstrand: thanks, I'll ping them both then
<hallyn> jdstrand: rharper: right, so the changes need to be put under checks for the lsb_release, as is done throughout that file (and in http://people.canonical.com/~serge/qrt-qemu.diff)
<hallyn> biab
<doko> dholbach, you sponsored Jackson Doak's libstatgrab upload which ftbfs everywhere
<dholbach> doko, I pinged him about it
<dholbach> doko, I tested it locally
<rharper> jdstrand:  what about tagging a release of the testsuite prior to the fixes?  it does seem odd to skip tests altogether on releases that can run the commands but the test case is just not written correctly
<jdstrand> rharper: tagging doesn't work with the way the scripts are run-- plus it would be hard to get new tests. if the test is wrong, can it be fixed to work on all releases?
<rharper> jdstrand: yes -- that's my next step
<rharper> I need to re-run the updated suite on the previous releases
<rharper> there are a few older release (like older than say 10.x ) that probably don't have monitor commands to do the new hotplug
<rharper> but otherwise, it should run on all releases
<rharper> a few changes need the special casing since the monitor output changed between releases
<rharper> so, let me re-work the patch and provide results  on passing; how far back do I need to run ?
<rharper> release-wise
<jdstrand> rharper: it is fine to remove tests/etc for EOL releases. however, qemu still gets support on 10.04, so it needs to work there
<rharper> ok, so 10.04 up to current ?
<rharper> or just the LTSes between 10.04 and now ?
<jdstrand> rharper: 10.04, 12.04, 12.10, 13.04, 13.10 and 14.04 are the current supported releases
<rharper> ok
<rharper> perfect
<jdstrand> rharper: thanks! :)
<rharper> np
<knocte> ubuntu's default bluetooth manager is an app that depends on gtk2?
<pitti> dholbach: ok, that looks better: http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
<pitti> @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:
<dholbach> pitti, you're a hero!
<teward> pitti: thanks for sponsoring the wireshark ftbfs fix :)  purely curious, though, why are we ahead of Debian with Gtk 3.10+?
<pitti> teward: let's rather say Debian is behind a lot; first there was the wheezy release, and now I'm not sure what's blocking the update in Debian
<teward> pitti: heh
<teward> pitti: well, at least one of the FTBFS caused by Ubuntu having gtk 3.10+ is fixed, thanks again.
<mlankhorst> weird, how did libqt5gui5 get promoted to main while libxcb-sync1 is still only in -proposed?
<infinity> mlankhorst: s/main/release/ ... Very confusing to use the wrong terminology.
<mlankhorst> oops
<infinity> mlankhorst: And the answer is simple, your rebuild was against libxcb-sync0.. Check a build log.
<mlankhorst> hm
<infinity> libxcb-sync0-dev is in build-deps.
<mlankhorst> that shouldn't have happened..
<mlankhorst> ah right
<mlankhorst> it can still be explicitly installed
<mlankhorst> and provides ends up as noop
<mlankhorst> the new package provides libxcb-sync0-dev, so it pulled it in on my local build
<infinity> mlankhorst: Ew, really?  foo1-dev doesn't provide foo0-dev in any sane meaning of the word.
<zyga> I'm getting WIFSTOPPED on waitid for a child that failed to exeve(), I'm trying to understand why but all my searches turn out negative
<mlankhorst> infinity: some symbols were removed and that was a reason for a soname bump
<infinity> mlankhorst: Does someone really think this is a good thing to do?  Will foo2-dev provide foo1-dev and foo0-dev just to avoid fixing build-deps?
<infinity> mlankhorst: No, no.  The SONAME bump is good, I'm not saying it's not.  I'm saying the provides is bogus.
<zyga> does anyone know why waitid() returns such a value? the code after execve() just called _exit() with a status code I can see
<zyga> (see in si_status)
<mlankhorst> wasn't me who did it, no idea why it was done..
<infinity> mlankhorst: If there's never any intent to offer multiple versions of that dev package, it should be "libxcb-sync-dev", and fix all the build-deps once, so future no-change rebuilds work right.
<mitya57> mlankhorst: try http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qtbase.git;a=commitdiff;h=374b4205a374d4070e95b144fce03391789702bb
<mlankhorst> yeah
<infinity> Ahh, and indeed, that's what they've done going forward.
<infinity> So, yeah.  Fix the build-deps. :P
<infinity> (base)adconrad@cthulhu:~$ reverse-depends -b libxcb-sync0-dev
<infinity> Reverse-Build-Depends
<infinity> =====================
<infinity> * kde-workspace
<infinity> * libkscreen
<infinity> * qtbase-opensource-src
<mlankhorst> hm libkscreen build-depends on it? didn't show up in reverse-depends libxcb-sync0
<infinity> Looks like render0, shape0, shm0, xfixes0 (and who knows how many others) will have this same issue soon.
<infinity> mlankhorst: It build-depends on it.  Could be spurious if it doesn't actually link against it.  But it should still be looked at and fixed.
<mlankhorst> well from the source I guess it looks if it exists, nothing seems to use it :P
<infinity> mlankhorst: Well, the proper fix would probably be submitting a patch to upstream to stop doing that, but the path of least resistance is certainly just fixing the build-dep to be unversioned and handwaving. :P
<mlankhorst> yeah
<mlankhorst> well, should be fixed in https://mblankhorst.nl/etc/sponsor.tar
<TJ-> Why are the packaging branches for upstart out-of-sync with what is in the archives? The changelogs don't even show the released version yet contain UNRELEASED versions later than the released version. (checked both ubuntu/trusty/upstart and ubuntu/upstart)
<mitya57> TJ-: check package-import.ubuntu.com
<mitya57> TJ-: also, I believe upstart packaging is maintained in some other place
<TJ-> mitya57: *sigh* well, the branches I pulled have changes dated 8th January... sure is confusing. Package import failed due to VersionNotPresent... but the source path shows natty ... makes no sense to me!
<mitya57> Hum, no, only Debian package uses Vcs, it is quite different from Ubuntu
<TJ-> mitya57: I'm on about bzr branch lp:ubuntu/trusty/upstart etc.
<mitya57> TJ-: Right, that is broken. It's not easy to fix it, try something different (like filing bugs with debdiffs)
<mitya57> If the changelogs contain UNRELEASED, that probably means someone broke it
<TJ-> mitya57: Yeah... very much so. I've just pulled upstream and it has no debian/ directory at all!
<TJ-> mitya57: I was hoping to work on tracking down a kernel panic killing init when doing "dpkg --configure -a"
<mitya57> TJ-: hm, no, contents of lp:ubuntu/upstart look up-to-date
<cyphermox> knocte: no, gnome-bluetooth depends on gtk3
<mitya57> TJ-: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/debian/changelog
<jodh> mitya57, TJ-: UNRELEASED as there are pending fixes in the bzr branch not yet in the archive version. However, it does look like one of the recent changes to changelog has pasted in some extraneous (old) entries.
<TJ-> jodh: good catch... I didn't go too far into the changelog once I say a 1.10-??? entry
<TJ-> jodh: my sanity is restored... thanks :)
<mitya57> I still need some advice for bug 1269203. The package tries to overwrite files in libqt4-dbus:[ARCH]. I added Breaks/Replaces on libqt4-dbus (<< ...), but that looks not enough. Do I need a B/R on libqt4-dbus:any instead?
<ubottu> bug 1269203 in qt4-x11 (Ubuntu) "package libqtdbus4 4:4.8.5+git192-g085f851+dfsg-2ubuntu3 failed to install/upgrade: trying to overwrite '/usr/lib/x86_64-linux-gnu/libQtDBus.so.4', which is also in package libqt4-dbus:amd64 4:4.8.4+dfsg-0ubuntu22" [Undecided,New] https://launchpad.net/bugs/1269203
<TJ-> Reported. bug #1269487
<ubottu> bug 1269487 in upstart (Ubuntu) "bzr branches changelogs broken" [High,New] https://launchpad.net/bugs/1269487
<jodh> TJ-: thanks
<infinity> mitya57: That should work as-is...
<mitya57> infinity: Right, but it doesn't. I thought my ubuntu3 upload would fix that, but that bug says it has ubuntu3 installed
<infinity> mitya57: Not arguing that the log doesn't show what it does, just that it makes no sense, cause it shouldn't. :/
<infinity> mitya57: Might have to do some local testing and see if I can reproduce it at all...
<mitya57> infinity: that would be nice, I ran out of ideas
<mitya57> bug 1269297 is similar, but that is i386 package on amd64 system
<ubottu> bug 1269297 in qt4-x11 (Ubuntu) "package libqtdbus4 4:4.8.5+git192-g085f851+dfsg-2ubuntu3 failed to install/upgrade: trying to overwrite '/usr/lib/i386-linux-gnu/libQtDBus.so.4.8', which is also in package libqt4-dbus:i386 4:4.8.4+dfsg-0ubuntu22" [Undecided,New] https://launchpad.net/bugs/1269297
<infinity> mitya57: Weeeird.  So, on the first bug, the actual logfile shows -2ubuntu1, not -2ubuntu3...
<infinity> mitya57: And the second bug shows -2ubuntu2
<happyaron> pitti: thanks, it's already on my list, :)
<mitya57> infinity: Interesting
<infinity> mitya57: So, maybe apport's doing something very silly here.
<infinity> mitya57: If you check the DpkgTerminalLog for each, neither one is using your latest.
<mitya57> pitti: ^ any ideas? apport is putting wrong package version into the bug report
<infinity> mitya57: So, if you can't reproduce this with -2ubuntu3 (and I don't see why you could), I'd just close both (and any dupes) with "fixed in -2ubuntu3".
<mitya57> I will mark them as dupes when/if pitti looks
<mitya57> infinity: thanks for finding the issue, btw!
<pitti> infinity, mitya57: well, this would be the version you upgrade *from*, not *to*, right?
<infinity> pitti: Check the bug. U-Boot 2013.04-mustang_sw_1.08.12-beta_rc (Oct 18 2013 - 15:19:00)
<infinity> Er,
<infinity> pitti: https://launchpad.net/bugs/1269203
<ubottu> Ubuntu bug 1269203 in qt4-x11 (Ubuntu) "package libqtdbus4 4:4.8.5+git192-g085f851+dfsg-2ubuntu3 failed to install/upgrade: trying to overwrite '/usr/lib/x86_64-linux-gnu/libQtDBus.so.4', which is also in package libqt4-dbus:amd64 4:4.8.4+dfsg-0ubuntu22" [Undecided,New]
<infinity> pitti: The bug title and metadata claims the bug is in 4:4.8.5+git192-g085f851+dfsg-2ubuntu3, but the Dpkg Log clearly shows it's -2ubuntu1
<infinity> pitti: Is apport doing some lpapi thing to get the version or some such?  It's obviouly not reporting on the version that was actually attempting install.
<mitya57> Right, "Unpacking libqtdbus4:amd64 (from .../libqtdbus4_4%3a4.8.5+git192-g085f851+dfsg-2ubuntu1_amd64.deb)"
<mitya57> That doesn't sound like "from"
<infinity> Speaking of... If apport does manual parsing of the dpkg output, it's going to get even more confused after the next merge. :/
<infinity> guillem changed that output.
<pitti> infinity: apt calls /usr/share/apport/package_hook with an explicit --package (but without the version) when the actual problem happens; and then, when you report it, apport collects the remaining info, including the package version
<pitti> infinity: so I suppose what happened is this:
<pitti> - dist-upgrade
<pitti> - failed to unpack -2ubuntu1, created an apport report
<pitti> - the user further upgraded to -2ubuntu3
<infinity> Or apt-get updated.
<pitti> - only *then* the user filed that apport report
<infinity> If it's using apt-cache, you wouldn't need to actually upgrade, just update.
<infinity> So, there'd be a race there with the apt cronjob, even without human interaction.
<pitti> i. e. we should capture the affected package version right away in this case, not just during data collection in the UI
<doko> infinity, dpkg merge ping (to keep pitti busy)
<infinity> Heh.
<pitti> infinity: no, it's using python-apt with the "installed" paackage version, so it's not due to apt-get update (indexes don't matter)
<mitya57> Shouldn't the version number be inserted when report is generated, not when it's filed?
<pitti> ideally yes
<TJ-> infinity: can I ping you about bug #1269405  ... might be an emerging issue since the upload yesterday
<ubottu> bug 1269405 in upstart (Ubuntu) "Kernel Panic when 'telinit u', or (re)installing packages" [Undecided,Confirmed] https://launchpad.net/bugs/1269405
<cjwatson> TJ-: if "telinit u" is causing a reboot then that's more a jodh thing
<cjwatson> libc is just one of a number of packages that uses it
<infinity> Indeed, not a glibc issue, and just confirmed that a glibc upgrade here works fine.
<TJ-> cjwatson: infinity: thanks... will dig deeper
<jodh> cjwatson: yes, but what's weird is that it's just started happening seemingly and upstart hasn't changed in a couple of months now.
<cjwatson> nor has dbus
<TJ-> There are some invasive changes to recent glibc uploads... I've got an affected user who has reverted to glibc  2.18-0ubuntu2 and it still shows up; he is going to try older kernels later today.
<cjwatson> that would suggest that the invasive changes aren't relevant, then :)
<infinity> TJ-: Which "invasive changes" are those?
<infinity> TJ-: (Hint, between ubuntu2 and ubuntu5, there's exactly one patch that affects amd64)
<TJ-> cjwatson: infinity: the debian experimental merge. So ...ubuntu2 showing the issue suggests the bug has either been latent, or a change elsewhere (linux maybe) is triggering it
<cjwatson> or the other possibility, that it has nothing to do with eglibc at all
<infinity> TJ-: Or it's, perhaps, an upstart job that's common to those systems and confusing upstart.
<TJ-> infinity: Yes, I saw that... I've been working through trying to narrow down the possibilities ... I'll wait for the user to report back on older kernels
<Laney> I've had that a few times actually
<Laney> I was suspecting flaky hardware but now that I think about it some of the times were during dist-upgrades
 * Laney loves being concrete
<jodh> Laney: if you can you recreate the issue, please add details to the bug. Also, any sign of /var/log/upstart/upstart.state on your system?
<Laney> jodh: no, and I will do now that I have an alternate suspect
<Laney> It's happened several times so I'm confident we'll see it again
<barry> @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: barry
<seb128> xnox, hey, is there anything blocking bug #967229 to get uploaded to trusty?
<ubottu> bug 967229 in plymouth (Ubuntu) "Text mode shown briefly with various "cryptic" texts when logging out or shutting down" [High,Triaged] https://launchpad.net/bugs/967229
<slangasek> probably the main blocker is that it touches both lightdm and plymouth, and needs to be vetted for versioned deps/breaks and to make sure other DMs (or DM-less server systems) don't break as a side effect
<seb128> slangasek, would it help if some of us test those changes?
<slangasek> seb128: I can't say; I looked briefly at the diff to see if it was something I could push through quickly, saw the extent of the changes and backed away.  I think we should wait for xnox to follow through
<seb128> ok, wfm
<seb128> I pinged mostly because I saw ara's comment and it looks like something we should try to land early in the cycle rather than late
<seb128> it can wait on xnox to be back for sure though ;-)
<seb128> slangasek, thanks!
<slangasek> n/p
<mitya57> doko: Can you please submit your Qt4 arm64 patch upstream? It would be nice to have it included in 4.8.6 so that we can reduce the number of Ubuntu-specific patches.
<doko> mitya57, it's not mine, it's the one from Fedora, and then fixed to work
<mitya57> doko: Hm, OK, the author is hrw?
<doko> I think so
<barry> jtaylor: i'm guessing that https://code.launchpad.net/~jtaylor/ubuntu/trusty/python-numpy/new-upstream/+merge/200473 is the one you wanted me to review, right?  the mp is against the wrong branch, so the diff is, um, unusable ;)
<jtaylor> barry: I think its right
<barry> jtaylor: oh, yes, you're right it's against the right branch.  the diff is still useless ;)  btw, debian experimental has 1:1.8.0-1.  have you tried that to see if it fixes the issues?  should we just sync from exp?
<jtaylor> we can't
<jtaylor> no matplotlib in main
<jtaylor> this one should go in first: https://code.launchpad.net/~jtaylor/ubuntu/trusty/cython/numpy-fix/+merge/201837
<jtaylor> though technically no, as its jsut a test fix
<barry> jtaylor: well, merge (sync + delta)
<jtaylor> barry: might as well use the branch then, it contains more bugfixes
<jtaylor> its based on the stable branch of numpy
<barry> jtaylor: okay, that's what i was wondering - sounds like all the needed fixes are not yet in the debian branch
<jtaylor> we might be able to replace it with 1.8.1 before trusty release
<jtaylor> they will go into debian on unstable upload
<jtaylor> barry: added a small addition to cython merge
<barry> jtaylor: okay, let me look at the cython one first
<jtaylor> that too will get synced over by 0.20 later
<mitya57> wgrant: I see you also have authored some Qt4 patches (aarch64_fix_atomic_set.patch & aarch64_fix_jsc.patch). Did you forward them upstream?
<jtaylor> barry: mind if I bump the upstream commit of numpy? just allows dropping two patches
<jtaylor> memoryview*patch
<bdrung> YokoZar: yes. that fits into u-d-t
<jtaylor> barry: my cython test build finally succeeded :)
<barry> jtaylor: \o/  i got distracted.  i'll look at your cython branch now
<jtaylor> barry: I'll push a new numpy if you didn't already look at it
<barry> jtaylor: please do, thanks
<Fudge> are unity keybinds like shift super 1 supposed to still spawn another instance of Nautilus? Or is this intentionally not the case any longer.
<stokachu> barry: have you run into issues where you package a python3 only version but dh still tries to run pyversions?
<jtaylor> stokachu: have you disabled pysupport?
<jtaylor> its run by default (or is this off now?)
<barry> stokachu: py3-only?  no.
<stokachu> hmm
<jtaylor> I think newer compats should turn it off
<barry> jtaylor: i think so too
<stokachu> i dont have anything using python2 but it still tries to copy files to the 2.7 build directories
<jtaylor> which compat?
<stokachu> 9
<barry> stokachu: branch or package?
<barry> stokachu: which branch or package?
<stokachu> barry: its private but i can paste the debian files
<barry> stokachu: d/rules and d/control to start with
<stokachu> ok one sec
<jtaylor> a buildlog would be interesting
<stokachu> barry: http://paste.ubuntu.com/6758565/
<barry> jtaylor: yep
<stokachu> and the build log i have http://paste.ubuntu.com/6758566/
<stokachu> one sec i have another log of the actual debuild
<jtaylor> hm I think I saw this before
<stokachu> http://paste.ubuntu.com/6758574/
<stokachu> this show where it copies stuff over to xxxx2.7
<stokachu> like line 5
<stokachu> 52
<jtaylor> yes you have to disable python2 explicitly
<jtaylor> basically vice versa of what you have to do for python3
<stokachu> like a Conflict?
<jtaylor> no override dh_auto_build
<jtaylor> and all others
<stokachu> that makes me sad
<jtaylor> you could use pybuild, it should be able to deal with py3 only
<stokachu> ah ive never used pybuild ill need to read up on it
<barry> +1 for pybuild
<barry> stokachu: https://wiki.debian.org/Python/LibraryStyleGuide
<barry> stokachu: i just looked at system-image's packaging (it's py3 only)
<barry> override_dh_auto_build: $(PYTHON3:%=build-python%)
<barry> PYTHON3=$(shell py3versions -dvr)
<barry> but i haven't switched it over to pybuild yet
<stokachu> so should i use this way or pybuild?
<jtaylor> yes just regular py3 packaging overriding everything, with the twist of disabling the provided ones instead of running them for py2
<jtaylor> pybuild will be cleaner
<jtaylor> depends on your backpoprt requirements
<barry> jtaylor: agreed!
<stokachu> so for backports i could switch it out to distutils?
<stokachu> if using pybuild
<jtaylor> with switchout = rewrite yes
<jtaylor> pybuild and old python packaging are quire different
<jtaylor> from the rules style
<barry> isn't pybuild available in (some) backports?
<stokachu> ok
<jtaylor> its not yet in anything older than saucy
<jtaylor> and saucy has a buggy version
<jtaylor> for binary extensions at elast
<jtaylor> and you have the backports depending on backports issue if thats not fixed yet
<barry> blarg
<stokachu> thanks guys going to try with pybuild
<jtaylor> pybuild also gives you pypy support
<stokachu> interesting, that may be beneficial for my other package
<jtaylor> pybuild with binary extensions debug and pypy: http://anonscm.debian.org/viewvc/python-modules/packages/pyzmq/trunk/debian/rules?revision=27065&view=markup
<stokachu> it supports py2, py3
<jtaylor> relatively simple % the pyzmq specifics
<barry> you might be able to get away with just PYBUILD_NAME
<barry> instead of all those DESTDIRs
<jtaylor> might be that its already a little outdated
<barry> stokachu, jtaylor here's what i use for flufl.i18n (py2 and py3, but still)
<barry> https://alioth.debian.org/scm/viewvc.php/packages/flufl.i18n/trunk/debian/rules?view=markup&revision=26544&root=python-modules
<barry> jtaylor: for the cython patch, is there an upstream tracker issue open for this?
<jtaylor> it just adds python-..NAME packages I guess?
<stokachu> nice im testing my build now with pybuild
<jtaylor> barry: a mailing list post, its in the 0.20.x branch
<jtaylor> I thin k I forgot the commit id
<jtaylor> but its going to be obsoleted by sync soon anyway
<barry> jtaylor: so no Bug: header for the quilt patch
<jtaylor> I can add the id if you haven'T started a build yet
<barry> jtaylor: i haven't, go for it
<jtaylor> k
<TJ-> Anyone know of an issue when installing on UEFI whereby the boot menu option isn't added? I've tracked the failure down to "Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting" when installing 'secureboot-db' even though the live installer booted in, and recognised, UEFI mode.
<jtaylor> barry: added
<barry> jtaylor: thanks.  i'll test build and upload if it looks good
<jtaylor> don't bother if you don't have at least 2 hours time
<barry> jtaylor: wow, really?  last time i built cython it took a while but not *that* long
<jtaylor> we have an extra cython
<jtaylor> python
<jtaylor> maybe your machine is also faster :)
<barry> jtaylor: the patch looks fine to me.  if i just sponsor it for you, will you watch for ftbfs?
<jtaylor> barry: yes I'll get the 0.20 sync
<jtaylor> cython is broken with python3.4
<jtaylor> currently its just ignored
<barry> jtaylor: sounds good.  if the build looks like it's going to take 2h, i'll kill it and just sponsor
<stokachu> yay successful!
<barry> stokachu: \o/
 * barry is rather curious to see if his machine *is* faster :)
<jtaylor> it was quite a bit longer than 2 hours on mine let me check how long exactly
<jtaylor> about 3hour 15 minutes, but I was building scipy on the machine in the meantime too
<barry> ouch.  okay, let see how far it gets while i make some tea :)
<jtaylor> good that we don't ahve 4 pythons anymore :)
<jtaylor> = 8 builds with debug
<jtaylor> but in return we have pypy :/
<stokachu> so with pybuild do i have to do anything special to have my package built as a private module?
<stokachu> https://github.com/sosreport/sosreport/blob/master/debian/rules
<stokachu> previously that is what i was doing to make that happen
<jtaylor> probably --install-args or --install-dir
<jtaylor> the former should allow you to do the same thing as your old rules
<stokachu> ok
<jtaylor> but don't know for sure, never tried it for private
<stokachu> yea looks like setting PYBUILD_INSTALL_DIR will do it
<barry> jtaylor: it's still running, so i'm going to push the cython branch
<jtaylor> barry: should be fine, and its not a runtime dependency
<jtaylor> so it shouldn't even lock stuff in proposed if it fails
<barry> yep.  okay, so back to numpy
<jtaylor> thx :)
<jtaylor> I convinced the debian maintainer to accept the ubuntu diff (dh_python2 etc)
<jtaylor> so its easier to manage
<jtaylor> basically just the matplotlib patch and build depend
<jtaylor> and ppcel64
<jtaylor> (compared to debian svn)
<barry> great!
<barry> jtaylor: hmm, i'm getting merge conflicts for lp:~jtaylor/ubuntu/trusty/python-numpy/new-upstream against ubuntu:python-numpy
<jtaylor> barry: no idea about that, I never merge in udd, just bzr-buildpackage and cowbuilder
<jtaylor> whats the checksum of the orig you got?
<jtaylor> might be due to quilt files? I never figured out how to deal with those inb zr
<jtaylor> I think they are not applied
<jtaylor> (how I like it)
<barry> jtaylor: probably yeah.  quilt is always tricky
<barry> jtaylor: i can't bzr bd when there are conflicts, so i'll just have to try your branch
<barry> jtaylor: the conflicts don't happen in debian/ so i can still review that
<barry> jtaylor: i think instead of adding a return to the top of test_basic2() in test_ctypeslib.py, it would be better to add a skip, something like:
<barry> @dec.skip('Skipped as per debian/patches/python3-soabi.patch')
<udevbot> Error: "dec.skip('Skipped" is not a valid command.
<jtaylor> the effect is the same
<jtaylor> I don't really like the patch
<barry> jtaylor: yes, but better documented and less mysterious when looking at the file
<barry> me neither, but i can't think of anything better
<jtaylor> should I add the skip? I don#t think anyone will look at it
<jtaylor> the file not the patch
<jtaylor> the patch has a description
<barry> jtaylor: i've done it here
<jtaylor> k thx
<RAOF> infinity: The colord autopkgtest failure is infuriating. It fails *only* on our Jenkins hardware as far as I can tell, not anywhere else.
<jtaylor> welcome to the club
<jtaylor> skimage the same
<jtaylor> (the pre py3.4 failure)
<barry> jtaylor: cython build finished:
<barry> Build needed 01:29:26, 381920k disc space
<jtaylor> your machine is a lot faster than mine :)
<barry> :)
<barry> jtaylor: numpy uploaded
<jtaylor> great thanks :D
<jtaylor> now I can start getting the science stack in order :D
<barry> jtaylor: good luck!
<barry> @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:
#ubuntu-devel 2014-01-16
<slangasek> infinity: say, do you have any plans to merge newer dpkg for trusty?  It would be nice to have DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT from 1.17.2 available for trusty
<slangasek> (making multiarch maintscripts more robust)
<infinity> slangasek: Yeahp.
<slangasek> infinity: ok
<infinity> I wonder if it'll break all of bdmurray's custom bug patterns.
<infinity> Have you noticed that guillem changed the unpack output (for the better, but changed nonetheless).
<slangasek> I didn't notice, no
<infinity> Preparing to unpack .../dpkg-dev_1.17.6_all.deb ...
<infinity> Unpacking dpkg-dev (1.17.6) over (1.17.5) ...
<infinity> Preparing to unpack .../libdpkg-perl_1.17.6_all.deb ...
<infinity> Unpacking libdpkg-perl (1.17.6) over (1.17.5) ...
<infinity> Much prettier, but also much different.
<infinity> Anyhow, I'll merge it tonight or tomorrow.  I suspect the only thing that parses that output is bdmurray's stuff, so we can sort out fixing that.
<sarnold> oh that's much prettier :)
<bdmurray> infinity: where does that appear?
<infinity> bdmurray: dpkg stdout.  If you're using that for any pattern matching on bug signatures, your world is going to be a bit confused.
<infinity> Compare to old-stype output:
<infinity> Preparing to replace libc6-dev:amd64 2.18-0ubuntu2 (using .../libc6-dev_2.18-0ubuntu5_amd64.deb) ...
<infinity> Unpacking replacement libc6-dev:amd64 ...
<Logan_> Ooh, that is much nicer.
<melodie> hi
<melodie> is there someone on board at this time, who has knowledge related to the creation of custom versions, either with debootsrap, or mini iso, or whatever nice clean method can be used? (I know there is a wiki but not up to date with the latest changes, and not accurate enough for a first start)
<melodie> I would like to meet with someone who could be a guide in the following days and weeks, act as a mentor for a new remix projet involving next Ubuntu version and Openbox :)
<melodie> mainly for the first steps, for I never could remix from scratch, which I would be very eager to learn
<Noskcaj> melodie, Couldn't you start with on of the custom cd makers, for the easiest way
<melodie> hi again
<melodie> <melodie> is there someone on board at this time, who has knowledge related to the creation of custom versions, either with debootsrap, or mini iso, or whatever nice clean method can be used? (I know there is a wiki but not up to date with the latest changes, and not accurate enough for a first start)
<melodie> <melodie> I would like to meet with someone who could be a guide in the following days and weeks, act as a mentor for a new remix projet involving next Ubuntu version and Openbox :)
<melodie> <melodie> mainly for the first steps, for I never could remix from scratch, which I would be very eager to learn
<melodie> <Noskcaj> melodie, Couldn't you start with on of the custom cd makers, for the easiest way
<melodie> Noskcaj left and I missed him. I'll tell him next time: done that so far. would like to get to the higher stage. Here is the achievement so far: http://linuxvillage.org/en/2013/11/bento-ubuntu-remix-rc/
<dobey> huh. the logo in the boot screen is not exactly what i would associate with the word "bento" :)
<melodie> hi dobey yes, that might be right :)
<melodie> however bento should not be associated directly, but rather like a second meaning: the distro where you can add or remove what you want to, from the recipe
<melodie> I'll add that I didn't choose the name, it came from a member of the linuxvillage.org forum. now I'd like to learn the other method, from the groundup, because I would like to work on a new project someone started at Launchpad : very much like the one I am doing, but with a few extra ideas which I'm interested about (ToriOS)
<melodie> and also if I had been able to start right away from the groundup I would have done that long before
<dobey> i don't know anything about the imaging tools
<melodie> dobey thanks for talking to me :)
<melodie> what time is it in your country?
<dobey> 2300
<melodie> aha
<melodie> are you in NY state?
<dobey> no
<melodie> or around?
<dobey> i am in need-to-suspend state :)
<melodie> aha I meant country :D
<melodie> I'm in South France and it's super early here, 5:05
<shadeslayer> anyone have a clue on http://pastebin.ubuntu.com/6760116/
<shadeslayer> ah wait
 * shadeslayer looks closely
<melodie> shadeslayer from this line:
<melodie> make[4]: *** No rule to make target `/usr/lib/libperl.so.5.18.1', needed by `perl/blib/arch/auto/KDECore4/KDECore4.so'.  Stop.
<shadeslayer> melodie: right
<melodie> I would say there is probably an error in the Makefile
<shadeslayer> melodie: so libperl-dev probably should depend on perl-base
<melodie> I say that, but I'm no dev
<shadeslayer> hm, but perl-base is pulled in
<melodie> if you don't get more help about it right on, you might try your guess
<shadeslayer> yeah, I've added perl-base to the build-depends
<shadeslayer> lets see
<melodie> have you had a look at the versions of the packages involved? (libs, devel libs, mainly?)
<shadeslayer> melodie: versions?
<melodie> yes, if the versions used match the requirements provided upstream
<melodie> for each package involved
<melodie> (I saw you are working on Trusty, so this might be something to have a look at)
<shadeslayer> CMake thinks everything is good
<shadeslayer> yep, adding perl-base makes it build
<melodie> I am not a dev. Does a dev have to trust CMake blindly? (I'm not a dev... so I don't know if yes or if no)
<melodie> great!
<shadeslayer> CMake isn't *usually* wrong
<melodie> :)
<melodie> if you solved it, I'm happy I could encourage you. Just remember, you did it all.
<melodie> have you indeed solved it? that ended with a good build?
<melodie> shadeslayer ?
<shadeslayer> yes
<melodie> :)
<shadeslayer> though lintian says depending on perl-base without a version is bad
<melodie> solved?
<shadeslayer> so I'm thinking of depending on perl instead
<melodie> you can try
<melodie> then you see if that works
<melodie> are you mainly someone who builds packages, or do you also write code?
<melodie> I see something you said a few minutes ago:
<melodie> <shadeslayer> yeah, I've added perl-base to the build-depends
<shadeslayer> I do both, though more of building packages
<melodie> shadeslayer as far as I know, if libperl-dev pulls in perl-base then you should not have to add perl-base to the build depends
<infinity> perl-base doesn't need to be in build-depends, it's Essential.
<tarpman> perl-base in build-depends seems odd. it's already essential (and your paste shows it's installed before your build ever starts)
<melodie> infinity :D
<tarpman> ... hi infinity :D
<shadeslayer> infinity: tarpman I know, but adding perl-base to depends fixes the build
<melodie> this is odd
<melodie> do the versions match?
<infinity> shadeslayer: I'd assume your science is faulty here, then.
<shadeslayer> possibly
<shadeslayer> I am still unsure how to fix this in the PPA though :/
<melodie> shadeslayer if no one can help you better right now, what about trying the product of your build in a real install in a Trusty environment, with the debug mode? Maybe you could find something?
<infinity> shadeslayer: Well, for starters, why is the makefile looking for libperl.so.5.18.1 when you probably have libperl.so.5.18.2 installed?
<infinity> -- Found PerlLibs: /usr/lib/libperl.so.5.18.2 (found version "5.18.2")
<infinity> No rule to make target `/usr/lib/libperl.so.5.18.1'
<infinity> That's pretty suspect.
<hyperair> required by perl/blib/arch/auto/KDECore4/KDECore4.so
<hyperair> perhaps perl/blib/arch/auto/KDECore4/KDECore4.so has a greater mtime
<TJ-> shadeslayer: You need to add to the Makefile, "-Wno-undef" for "kdecore/src/CMakeFiles/kdecore4.dir/kdecore4handlers.o" at least
<hyperair> i don't think you can edit the makefile directly with cmake
<TJ-> shadeslayer: You may also need "-Wno-switch-default"
<shadeslayer> sure, that probably gets rid of the warnings, but what about the real issue
<hyperair> no wait i mixed up
<hyperair> hmm
<melodie> shadeslayer according to the answers 3 persons just gave you, what do you think about what infinity just told you about the versions of libperl?
<melodie> hi Noskcaj :)
<melodie> Noskcaj I read your answer a moment ago, my answer to yours is this one: http://linuxvillage.org/en/2013/11/bento-ubuntu-remix-rc/
<shadeslayer> aha
<shadeslayer> infinity: good catch
<melodie> so now I'd like to learn deeper, and learn how to start from scratch
<Noskcaj> hey melodie
<melodie> :)
<Noskcaj> ok. I can't really help you with that then
<melodie> Noskcaj I knew it, however if you know anyone who could help me, or could help me find who can help me, that would be most welcome. I'm following these two projects, related to creating new versions:
<Noskcaj> I think Unit might know. He's on the lubuntu channels and phill's channel
<melodie> https://answers.launchpad.net/ubuntu/+source/debian-cd/+question/240037
<melodie> and this one:
<melodie> https://launchpad.net/~torios
<melodie> Noskcaj strange that phillw didn't say about Unit at the question page
<Noskcaj> just a guess, since he helps with making extra xubntu isos
<melodie> ok
<melodie> what are extra ubuntu isos?
<melodie> xubuntu*
<tarpman> melodie: have you looked at ubuntu-defaults-builder?
<melodie> tarpman ? first time I hear about that
<melodie> would you have a link?
<tarpman> melodie: apt-get install ubuntu-defaults-builder; man ubuntu-defaults-image; man ubuntu-defaults-template
<Noskcaj> melodie, Different temporary test ISOs. Unit193 is his full irc nick
<melodie> tarpman I grab all this and keep it for further look. thank you very much.
<melodie> Noskcaj I know I met him already. I'll keep that in mind
<Noskcaj> ok
<tarpman> melodie: http://packages.ubuntu.com/search?keywords=ubuntu-defaults lists some existing defaults packages in the archive that work with that tool
<melodie> tarpman what do you think about the question asked by Fabrizio Balliano here? https://answers.launchpad.net/ubuntu/+source/debian-cd/+question/240037
 * tarpman -> afk, sorry
<melodie> oh ok
<melodie> thanks :)
<melodie> leaving now. Noskcaj have a nice day. ubuntu developers : Happy New Year 2014 to all! Thanks for all!
<melodie> :)
<pitti> Good morning
<RAOF> pitti: Oh, I've found and fixed (pending upload) the lcms2 bug causing the colord autopkgtest failure.
<pitti> RAOF: oooh, splendid! so there was indeed some miscalculation somewhere?
<RAOF> pitti: Yeah, lcms2 (and, for that matter, colord) has a braindead API that stores a dotted version in a float.
<pitti> haha
<pitti> version 1.999999734?
<RAOF> Indeed.
<RAOF> And lcms2 wasn't rounding, it was floor()ing.
<pitti> well, I mean, strings are *expensive*
<pitti> RAOF: so it was a real bug after all
<RAOF> The ICC format has a byte and two nibbles storing that value.
<RAOF> I have no idea why lcms2 decided that a floating point value (which *can't actually store* the full range of valid versions!) was a good idea.
<RAOF> ie: ICC version 4.10.2 is a valid ICC version. What are you going to store that in as a float?
<RAOF> Gah!
<RAOF> pitti: Now that the autopkgtests should be fixed, feel like testing it by uploading colord 1.0.6 from the tag in alioth git? :)
<pitti> RAOF: sure
<pitti> RAOF: sbuilding
<pitti> RAOF: uploaded
<pitti> "Jenkins Fixed - trusty-adt-colord 39"
<pitti> RAOF, infinity: ^ \o/
<dholbach> good morning
<doko> pitti: do you take care about the libgweather transition?
<pitti> doko: Noskcaj was going to, and seb128 wanted to do evolution
<ara> Hello!
<Leagnus> good day to everyone!
<ara> Someone in the SRU team could approve these two uploads, please? https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=notify-osd
<seb128> ara, hey ;-)
<ara> seb128, :)
<seb128> ara, we don't have much europeans doing SRU reviews nowadays I think, if you don't get a reply try again in the afternoon, or ping directly slangasek bdmurray infinity (just did for you;-)
<ara> seb128, well, RAOF should be online still, i.e. ;-)
<seb128> that's a good point!
<RAOF> ara: Well, it's 8pm for RAOF, but I'll have a look at it :)
<ara> RAOF, already 8pm! (wow)
<seb128> RAOF, with that heat wave, isn't that the time when it start being cold enough that your brain can start working again? ;-)
<ara> RAOF, thanks, if you are already EOD, don't worry, I will ping someone later when the Americas wake up
<RAOF> seb128: Ah, today has been nicely mild; about 22C or thereabouts.
<RAOF> Tomorrow will be hotter, though.
<RAOF> Hobart's far enough south to be spared the frankly ridiculous 46C or whatever Adelaide has reached.
<seb128> RAOF, oh, ok, you are not on the crazy spot of .au ;-) I was reading about the 43Â°C in Melbourn, tennis player are not really happy about it
<Leagnus> 	i think Unity is nice
<Leagnus> 	but file manager with panel in it
<Leagnus> 	which reacts on LMK (left mouse key), MMK (middle ~) RMK (right ~) is sufficent if
<Leagnus> 	there will be panels with info on it
<Leagnus> 	or with run software buttons
<Leagnus> 	that appear depending on context
<Leagnus> 	or certain windows.
<Leagnus> 	So special file manager plus special launch / info panels is sufficent environment for me.
<Leagnus> 	But how to realize it?
<ggvaberi> hello. can anyone recoment some link/tutorial, for prepare application tray icons correctly? I need to let my application to have correct reaction when user change icon-theme. for example from dark to light...
<seb128> RAOF, thanks for approving the notify-osd SRUs!
<seb128> ara, ^
<ara> RAOF, thanks!!
<doko> seb128, folks ftbfs ping
<seb128> doko, what about it?
<seb128> I've no idea about that package
<doko> seb128, ftbfs, desktop package ... https://launchpad.net/ubuntu/+archive/test-rebuild-20140108/+build/5424633
<seb128> k
<doko> thanks
<zyga> good morning :-)
<doko> zyga!
<zyga> doko: finally setup my stuff at home, I'll get that autopackagetest fixed today
<doko> thanks!
<doko> yolanda, fstat and qping ping
<yolanda> hi doko
<doko> ahh, no qstat and fping =)
<doko> yolanda, could you re-add the recommends as suggests?
<yolanda> doko, i was told to remove them, because they were already in the extra package
<yolanda> isn't that ok?
<doko> ahh, ok, maybe add  a comment
<doko> in the bug report and the changelog
<yolanda> doko, so i leave them in extra, and also add to main nagios-plugins in suggests?
<doko> yolanda, yes, you could do that, or just say in the changelog, that you dropped these because they are already in extra
<doko> s
<yolanda> doko, ok, better second option
<doko> so that dumb people like me do understand it too
<yolanda> heh
<yolanda> i'll resend a debdiff
<fishor> hello devs, is it possible  to make ubuntu-installer automatically create ext4 with 64bit enable? This option is needed to eanable methadata checksum. In my work on repair and datarecovery i noticed relativly big amount of hdd with silent corruptions. So checksumming getting more and more important. With SSDs situation is not really better :/
<fishor> it will be just great it methadata checksum would be enabled by default, but suddenly it is not "stable" or good tested.
<fishor> first step in easy testing will be ext4 with 64bit support.
<mapreri> I'm trying to understand why pinta is not auto-syncing with debian, even if the last version hit testing a month ago. Can someone check it?
<zyga> mapreri: maybe it's in -proposed?
<Laney> it is not
<mapreri> nope
<Laney> that *is* interesting
<Laney> cjwatson: ^?
<cjwatson> Laney,mapreri: investigating
<cjwatson> argh, impeded by Debian apparently having just dropped Sources.bz2 in favour of Sources.xz (which isn't the cause of this problem, since auto-sync has been running happily in general)
<mitya57> dholbach: Alles Gute zum Geburtstag!
<pitti> ooh!
<pitti> dholbach: alles Gute! *hug*
<dholbach> thanks mitya57, thanks pitti!
<ochosi> oh, congrats dholbach
<doko> seb128, are you now test-building on i386 so that you don't see ftbfs on amd64? ;p
<cjwatson> mapreri: (attacking with pdb)
<cjwatson> mapreri: oh, I see, it's confused by the existence of https://launchpad.net/ubuntu/quantal/+source/pinta/1.4-1~ubuntu12.10
<cjwatson> mapreri: I shall try to limit that check
<seb128> doko, I'm using i386 yes
<seb128> doko, I don't understand how stuff like incorrect linking don't show up there though, is the toolchain buggy on i386 and doesn't stop on those errors?
<cjwatson> incorrect linking should show up on i386
<cjwatson> usually does for me
<Laney> oops, that's an illegal backport
<ogra_> sue it !
<seb128> cjwatson, doko, dunno why https://launchpad.net/ubuntu/+source/glade/3.16.1-0ubuntu1 builds on i386, there is no -lm in the build log ... anyway, fixing the bug
<doko> thanks
<cjwatson> seb128: maybe it has something to do with ceil being an ifunc on amd64.  *shrug* dunno
<cjwatson> mapreri: OK, sorry about that, fixed (http://bazaar.launchpad.net/+branch/ubuntu-archive-tools/revision/807) - next auto-sync run in 5h35m or so will pull it in
<pitti> jodh: oh dear, this test_conf_preload failed again on i386, but succeeded on amd64: https://jenkins.qa.ubuntu.com/job/trusty-adt-upstart/52/ARCH=amd64,label=adt/console
<pitti> jodh: I'll retry; is that known-racy?
<Laney> mmm, update-manager failed
<mapreri> cjwatson: sorry, I was having launch. Good to know, thanks! :)
<pitti> jodh: retry worked
<pitti> Laney: fix uploaded
<Laney> pitti: hm, you didn't need to add at-spi2-core to test-deps?
<pitti> Laney: apparently not, why?
<pitti> I guess it's transitively pulled in by u-m's dependencies?
<Laney> oh I see
<Laney> that's just a warning
<pitti> Laney: it was just the new pep8 error
<Laney> nod
<Laney> I saw "** (nosetests3:11651): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files"
 * zyga is seriously impressed by ubuntu phone image QA process, *that* is the way to go! :-)
<ogra_> zyga, lots and lots to be improved, but we're getting there :)
<zyga> ogra_: yeah but the *direction* is right
<ogra_> yep
<mdeslaur> pitti: thanks for fixing update-manager, mdeslaur--
<Laney> haha, I like your change mdeslaur
<Laney> did you ask design? :P
<mdeslaur> Laney: it's based on mpt's design in that bug
<Laney> oh, neat, I thought it was a deliberate thing
<pitti> jibel: FYI, I usertagged autopkgtest issues in Debian: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=autopkgtest;users=autopkgtest-devel@lists.alioth.debian.org
<pitti> jibel: ^ these are just the ones reported by me; I think you submitted a few as well, which mail address do you usualy use?
<pitti> jibel: ah, http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=jean-baptiste.lallement@canonical.com
<pitti> tagged those, too
<mitya57> wgrant: Hi, can you please forward your arm64 support patches for qt4 upstream? We have *too* may local patches now, so it would be nice if we can reduce that via forwarding
<wgrant> mitya57: Linaro and RH people are working on it upstream at present, AIUI.
<wgrant> I saw some patches moving around a week ago.
<mitya57> wgrant: Ah, good to know. Were they the original patch authors?
<wgrant> My patches were just fixes to Linaro's.
<wgrant> So yeah, it's mostly driven by Linaro people.
<mitya57> Ok, thanks for the info
<mitya57> (So far I have only seen patches for Qt 5 landed in 5.2, but Qt 4 is different)
<pitti> cjwatson, xnox: has there already been some discussion about the perl 5.18.2 transition? (it's stuck in -proposed, makes a gazillion packages uninstallable, etc.); presumably it just requires the 63 rebuilds?
<cjwatson> pitti: oh, I didn't notice it
<cjwatson> pitti: I'll take care of it
<pitti> I just noticed it as lintian's autopkgtest started failing (I have an "autopkgtest cleanup day" today)
<pitti> cjwatson: ok; I'm happy to help out if you want
<pitti> $ grep perlapi-5.18.1 /var/lib/apt/lists/*i386*_Packages | wc -l
<pitti> 540
<pitti> ouch, could be some more rebuilds
<cjwatson> yeah, they're usually trivial though
<pitti> yes, just a lot of them
<cjwatson> I'll sort out a tracker first
<cjwatson> pitti: it's nothing like that bad
<cjwatson> pitti: perl-base still provides perlapi-5.18.1
<cjwatson> pitti: it's just the stuff in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734650
<ubottu> Debian bug 734650 in release.debian.org "transition: perl 5.18.2" [Normal,Open]
<cjwatson> (probably - I'll still set up a tracker to check for other Ubuntu-specific things)
<pitti> ah, nice; that looks rather harmless indeed
<pitti> and we already have libperl-apireference-perl and libmodule-corelist-perl (the two sourceful uploads)
<cjwatson> pitti: http://people.canonical.com/~ubuntu-archive/transitions/perl5.18.2.html agrees; I've uploaded those four rebuilds
<pitti> cjwatson: many thanks
<barry> doko: can you try to give back python-fixtures in your test rebuild?
<barry> doko: nm
<doko> barry, should I? -configglue didn't migrate to trusty yet
<barry> doko: i think both those need the b-d on python3-all.  just uploaded new ones of both.  i forgot to specify the right chroot in my local test build
<barry> doko: so no worries, new uploads should fix both of those
<doko> ok
<dholbach> infinity, do you have any idea what might need to be done to fix 1265625? or what it looks like to you?
<barry> doko: i suspect there are a bunch of failures related to b-d on python3 instead of python3-all
<doko> barry, I think so. I think we should do the fixes like you did. if we cannot for some reason, we should upload the package to the ubuntu-toolchain-r/python3 ppa
<barry> doko: agreed.  i am also filing bugs or fixing svn in debian
<barry> doko: i've pinged upstream genshi - they're looking at it.  yay for ast changes in 3.4
<infinity> dholbach: There's not really enough information there to even know what the bug is.
<ogra_> infinity, come on, its his birthday
<ogra_> pull out your crystal ball !
<infinity> dholbach: It could certainly be 1248642 though, to which the solution is "stop using crap non-free drivers".
<Snow-Man> pitti: around..?
<pitti> hey Snow-Man
<Snow-Man> pitti: Have you been following pgsql-hackers at all wrt the ALTER SYSTEM SET and conf.d stuff?
<pitti> Snow-Man: no, I'm not on that list
<Snow-Man> pitti: Well, it's kind of impactful wrt the packaging and whatnot.
<Snow-Man> pitti: would love to get your feedback and thoughts on it..
<Snow-Man> pitti: http://www.postgresql.org/message-id/52D6D914.8090207@agliodbs.com
<Snow-Man> pitti: That's the start of the "small" thread about these things.
<pitti> Snow-Man: thanks; queueing for reading
<Snow-Man> k
<dholbach> infinity, hrm, thanks
<doko> slangasek, cjwatson: why are postings to ubuntu-devel moderated?
<cjwatson> I assume you mean "for you", since they've been moderated in general for years
<doko> yep
<cjwatson> there may have been a regression in the thing that auto-whitelists all Ubuntu developers, since didrocks reported something similar
<cjwatson> but I have no access to that.  please ask #is
<doko> thanks
<pitti> doko: looking into libgweather transition, BTW (some things already done, some things  blocked by upload ban of packages that affect phone)
<doko> pitti, I thought that did end
<pitti> there was another regression, so it was put up again
<cjwatson> I'm looking into the libwebp transition
<pitti> doko: so gnome-panel and gnome-clocks are done now, evolution-data-server blocked by phone ban, looking at evolution; that should be it
<doko> pitti, evolution-data-server needs a fix, see bug #1266492
<ubottu> bug 1266492 in xorg-server (Ubuntu Trusty) "ld:i386 crashes with -static -fPIE -pie" [Critical,Triaged] https://launchpad.net/bugs/1266492
<pitti> doko: right; e-d-s is on seb128's list
<doko> barry, see my email to u-d-a, told that people should complain here on the channel about the 3.4 failures
<barry> doko: cool, reading
<barry> doko: looks good
<pitti> doko: FTR, I prepared evolution, but it needs e-d-s, so will need to wait for the lifting of the phone upload freeze
<pitti> seb128: ^ actually, we could upload them to -proposed and set a propagation blocker bug, so that stuff can build in -proposed without breaking the phone?
<seb128> pitti, let's do that tomorrow morning if the block is still in place
<pitti> *nod*
<ogra_> block will still be in place for 5-6h before we even have test results
<seb128> ogra_, well, tomorrow I might just decide to step over your block and get some work done :p
<ogra_> seb128, tomorrow it should be fine ... i dont care btw, the only person you make really unhappy is didrocks q
<ogra_> (well, and asac )
<ogra_> (dont call it "my blocker" :P)
<seb128> ogra_, you are included in the group that put that blocker in place :p
<ogra_> i'm just sitting on the side nodding
<seb128> but yeah, having that lifted tomorrow would be nice
<seb128> let's see how things look in the morning
<ogra_> yeah, the image is close to be done ...
<ogra_> then its like 5h to get test results from the autotests
<didrocks> we'll get dogfooding results first, I trust my popey more than the 500 AP tests ;)
<seb128> ogra_, you need to feed more hamsters to the test setup or something
<ogra_> seb128, the tests only take minutes
<ogra_> seb128, publishing the results on the dashboard takes so long
<popey> lol
<didrocks> we should change ci.ubuntu.com with "popey approved" yes/no
<didrocks> it's either 0 or 100%
<didrocks> :)
<pitti> barry: oh, you sponsored numpy?
<pitti> barry: this breaks a few packages, like pandas
<pitti> https://jenkins.qa.ubuntu.com/job/trusty-adt-pandas/22/ARCH=i386,label=adt/
<pitti> barry: I followed up in the MP, seems Julian was aware of that
<pitti> jibel: ^ seems numpy wasn't held back by the pandas breakage; I've run into that several times (known-broken packages got propagated), do we still actually hold back packages when they fail?
<pitti> jibel: or did we disable that?
<jibel> pitti, it is not disabled. The only run I found of pandas has been triggered by eglibc and there is not result at all for the tuple numpy/pandas
<asac> seb128: man, there is no block. just check with us, work on a special approach while we are ain alert (like testing more etc.)
<asac> no big deal really ... if you have an urgent landing, we will help landing it as much as we can
<ogra_> asac, e-s-d drags in a good chunk of changes with its rdeps
<asac> but just uploading without talking while your peers are fighting fires
<asac> is just not nice
<asac> talk, offer and receive help
<bcurtiswx> mthaddon, howdy
<barry> pitti, jtaylor: ack.  let me know if you need anything
<pitti> jibel: FYI, I filed bug 1269886 for the bzr autopkgtest failure; looks like it started to fail since python 2.7.6-5
<ubottu> bug 1269886 in bzr (Ubuntu) "autopkgtest fails in trusty: TestSmartTCPServer.test_graceful_shutdown_waits_for_clients_to_stop" [Undecided,New] https://launchpad.net/bugs/1269886
<pitti> vila: seems you maintain bzr these days mostly? Is that something you can look into?
<jtaylor> barry: what was to ack? scrolled of my backlog
<pitti> jtaylor: updating python-numpy reverse dependencies that now fail with the new numpy
<pitti> (like panda)
<barry> jtaylor: that ^^ :)
<jtaylor> yes thats known
<jtaylor> will be fixed
<jtaylor> pitti: just synced scipy, I'm expecting adt failure, but that will be fixed on the new upstream due maybe this weekend
<pitti> jtaylor: thanks
<vila> pitti: forget about that one, it's transient
<pitti> vila: well, the history of https://jenkins.qa.ubuntu.com/job/trusty-adt-bzr/ doesn't look that transient
<vila> pitti: damn
<pitti> vila: https://jenkins.qa.ubuntu.com/job/saucy-adt-bzr/ too
<pitti> vila: it is rather unlikely that it started to fail consistently on the exact same time when python2.7 was updated with some upstream changes
<pitti> vila: I mean, it's rather likely
<bcurtiswx> mthaddon, You can catch me in #ubuntu-us-dc most times.
<zyga> pitti: out of curiosity, how do you read the actual failure from, say: https://jenkins.qa.ubuntu.com/job/saucy-adt-bzr/18/testReport/
<vila> pitti: rhmm, can't reproduce locally >-/
<zyga> pitti: (how do you know what really failed?)
<pitti> zyga: seems the saucy logs are gone
<zyga> ah
<zyga> ok
 * zyga wishes for lava-like test introspection from log files
<bdmurray> hallyn: could you update bug 1244694 with SRU information?
<ubottu> bug 1244694 in OpenStack Compute (nova) "Creating snapshot fails due to nonexistent temporary directory" [Undecided,New] https://launchpad.net/bugs/1244694
<pitti> zyga: usually it's https://jenkins.qa.ubuntu.com/job/trusty-adt-bzr/? -> choose build -> choose architecture -> console log
<pitti> (or look at the individual test stdout/stderr file)
<vila> pitti: and saucy succeed too so that would explain why I can't reproduce, I'm late upgrading to trusty :-/
<pitti> vila: right; as I said in the bug this started with python2.7 2.7.6-5
<vila> pitti: but that python version is not available for saucy right ?
<vila> pitti: (trying to catch up)
<vila> pitti: wait, even rmadison doesn't know about 2.7..6-5 where do you get that one ?
<pitti> python2.7 | 2.7.6-5          | trusty           | source, amd64, arm64, armhf, i386, powerpc, ppc64el
<pitti> vila: it's in trusty
<infinity> And sid.
 * vila blinks
<vila> wow, why is there a difference between python and python2.7 ?
<infinity> vila: python is a metapackage build from python-defaults, python2.7 is the real binary.
<infinity> s/build/built/
<vila> (given  python | 2.7.5-5ubuntu3   | trusty          | amd64, arm64, armhf, i386, powerpc, ppc64el that is)
<vila> infinity: wow, thanks
<vila> confusing though
<infinity> A bit.  doko tries to keep the versions vaguely in sync to avoid too much confusion, but I guess he's a bit behind on the .5->.6 bump.
<vila> infinity: ha ok
<infinity> (And the version isn't actually meaningful, except for the confusion bit)
<vila> infinity: right, poor me ;)
<hallyn> adam_g: ^ you told me you would fill in SRU info for bug 1244694 ?
<ubottu> bug 1244694 in OpenStack Compute (nova) "Creating snapshot fails due to nonexistent temporary directory" [Undecided,New] https://launchpad.net/bugs/1244694
<pitti> vila: should be reproducible in a chroot/schroot, I guess
<pitti> anyway, need to leave for today, good night!
<vila> pitti: right, according to qblame, is the same MP that introduced all the other transient failures.. will comment on the bug
<adam_g> hallyn, i said i would test it once it was accepted to proposed :)
<adam_g> hallyn, but ill fill in the SRU data if you'd like
<hallyn> 22:43 < hallyn> that is, to -proposed, so awaiting a SRU justification from you :)
<hallyn> 22:44 < adam_g> hallyn, cool.
<hallyn> miscommunication then, sorry.  but yeah please do
<adam_g> hallyn, bdmurray https://bugs.launchpad.net/nova/+bug/1244694 updated
<ubottu> Ubuntu bug 1244694 in OpenStack Compute (nova) "[SRU] Creating snapshot fails due to nonexistent temporary directory" [Undecided,New]
<hallyn> adam_g: thanks!
<zyga> barry: any chance for signalfd/eventfd in python anytime soon?
<barry> zyga: probably not.  there's this: https://pypi.python.org/pypi/python-signalfd but afaict nobody's proposed anything for python proper, and 3.4's in feature freeze.
<zyga> barry: I saw that, I want python3 version :/
<zyga> barry: I may just try and propsoe one for 3.4, it's very useful and I'd love to see it
<zyga> barry: though I'm not sure how hard it would be to get into the core, since it would (probably) change how python does signals and that's across the board :/
<barry> zyga: it's too late for 3.4.  i would highly suggest contributing to the pypi project (hosted on lp), get it all happy, and then propose it for 3.5
<zyga> for 3.5 then
<jodh> infinity: what do you make of #16 on https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1269731.
<ubottu> Ubuntu bug 1269731 in upstart (Ubuntu) "init crashed with SIGSEGV" [Critical,Confirmed]
<jodh> infinity: as you stated yesterday, I cannot see how the eglibc changes as documented could cause this.
<infinity> jodh: Given that someone else said that downgrading to -0ubuntu2 didn't help, I'd blame bad science on the part of the other person.
<jodh> infinity: has to be, unless it's gcc?
<jodh> infinity: ...which seems also to have changed around this time.
<infinity> jodh: Would be nice if any of us could reproduce it...
<jodh> infinity: agreed :(
<infinity> "I can't speak for him, but I can say that I have tried 2.18-0ubuntu5 and 2.18-0ubuntu2 and I get a KP with both of them with I run "sudo telinit u"."
<seb128> so, "fun", ubuntu-wallpapers has a file with ' chars in the filename and those listed in the .install
<seb128> that started failing in trusty in the test rebuild
<infinity> So, that seems to rule out the 4->5 claims, and it's something far more subtle...
<seb128> works if you use \'
<seb128> is that a wanted debhelper change? a bug in ubuntu-wallpapers?
<infinity> seb128: I'd say unquoted 's are asking for trouble...
<seb128> infinity, right, they were working until recently though
<seb128> should I just add some \ \ in the .install and declare that a fix? or is that something that should be investigated on the debhelper side to know if that's a wanted behaviour change?
<infinity> seb128: Yeah, I'm not seeing an explicit mention of it in the changelog.
<seb128> yeah, me neither
<infinity> seb128: Maybe fallout from:
<infinity>   * dh_install, dh_installdocs, dh_clean: Fix uses of find -exec
<infinity>     which cause it to ignore exit status of the commands run.
<infinity>     Closes: 719598
<infinity> Maybe.
<infinity> seb128: So, the find -exec call was replaced with find -print0 | xargs -0 -I ... {} ...
<seb128> infinity, so probably unwanted side effect ... I wonder if there is any other package weird enough to use a ' in a filename listed in a .install, I'm unsure that's worth the effort of a bug report or that I care enough to even report it
<seb128> infinity, wdyt?
<infinity> seb128: Well, it's a behavioural regression.  If we can sort out a proper fix that DTRT in all the cases we can think of, I'm happy to file the bug with joeyh.
<infinity> seb128: Otherwise, the dh_install manpage should mention that shell special chars need to be quotes in .install files, which it doesn't currently.
<seb128> infinity, want to handle that? ;-)
<infinity> And, indeed, the use of -print0 | xargs -0 usually implies that the called wanted to avoid the need for quoting.
<infinity> But I suspect -I {} foils that.
<infinity> s/called/caller/
<slangasek> {} foils everything
<infinity> slangasek: Opinions?
<slangasek> infinity: attempting to formulate one now
<slangasek> infinity: I got nothin'.  I do think it's a debhelper bug, though I don't see a good way to solve it using find+xargs
<infinity> Hrm.
<TJ-> jodh: have you examined the #1269731 traces in detail?
<infinity> A quick reduced testcase of 'find . -type f -print0 | xargs -0 -I {} cp {} {}2' doesn't actually show it failing on files with ' in the name...
<infinity> So, maybe my guess about the errant commit is wrong.
 * infinity grabs ubuntu-wallpapers to see what it's doing.
<infinity> Ever weirder, Gota_D'Ã¡gua_by_Eiti_Kimura.jpg copies just fine before THE_'OUT'_STANDING_by_ydristi.jpg fails.
<miseria> "no estoy de acuerdo con la pena de muerte, al final las leyes sobrenaturales nos tienen condenados a morir" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<infinity> slangasek: Ugh, gets more interesting.  The working dh_install from saucy fails on trusty.
<infinity> slangasek: So, time to go witch-hunting.
<Logan_> mfisch: Around?
<mfisch> Logan_: yep whats up
<Logan_> mfisch: https://launchpad.net/ubuntu/+source/gwyddion/2.33-1ubuntu1 Do you know if the Unity global menu fix is still necessary in the latest upstream release of gwyddion?
<Logan_> Because I either want to merge or sync. I most likely don't need the change I implemented in 2.33-1ubuntu2.
<mfisch> Logan_: no I'm not sure, I probably left it in just to be on the safe side
<mfisch> Logan_: what change did you make?
<Logan_> I did an autoreconf to get new libtool macros for ppc64el, but they did a libtool update upstream.
<Logan_> So do you want to merge with just that Unity patch?
<mfisch> Logan_: I'm on a business trip so unlikely to update it anytime soon, can you do it?
<Logan_> Sure!
<seb128> doko, did you saw https://bugs.launchpad.net/ubuntu/+source/pycurl/+bug/1269532 ?
<ubottu> Ubuntu bug 1269532 in pycurl (Ubuntu) "package python3-pycurl 7.19.0-5ubuntu9 failed to install/upgrade: trying to overwrite '/usr/share/doc/pycurl/tests/setopt_lifecycle_test.py', which is also in package python3-pycurl-dbg 7.19.3-0ubuntu1" [Undecided,New]
<mfisch> Logan_: I've generally not asked the previous uploader of something unless they're the maintainer when I did previously nobody seemed to care
<Logan_> Usually people prefer that you ask. I haven't done that a lot in the past, though...
<Logan_> It's supposed to prevent duplicated work.
<mfisch> Logan_: sure and thanks for taking it
<mfisch> Logan_: you have blanket permission to merge or sync anything I did ;)
<Logan_> Sweet. :)
<barry> infinity: can you give back python-greenlet to doko's test rebuild?
<infinity> barry: Done.
<barry> thx
<barry> infinity: i have another one for you: python-httpretty
<infinity> barry: That one's dep-wait...
<infinity> barry: Because it build-deps on python-sure, which is in universe.
<barry> infinity: ah.  gotcha, thanks
<hallyn> has anyone gotten usb-creator-gtk to work this year?
<infinity> hallyn: I'm sure people cause it to run occasionally, and write things to USB keys.  I'm less convinced that the results are ever sensible.
<hallyn> infinity: i'm just doing dd right now and will mangle some free space into the remainder by hand...  was wondering if there is a better way :)
<infinity> hallyn: The better way would probably be to fix usb-creator.  It's something we really need to do before we ship 14.04 anyway, but so far no one's volunteered, and I don't think anyone's yet been voluntold. :P
<infinity> slangasek: Was Foundations going to take ownership of that mess and try to render it slightly more sensible?  I vaguely recall comments to that effect.
<hallyn> infinity: hm.  since it has the name "-gtk" at the end I've historically avoided lookin at it :)
<hallyn> but as i do want to make a usb boot stick for traveling, maybe i should seehow fixable it is
<hallyn> for a mere mortal
<slangasek> infinity: I recall that xnox did some updates already to move it to udisks2 recently
<slangasek> that's not the same as saying Foundations is taking ownership of the whole mess :P
<infinity> slangasek: Perhaps that was wishful thinking on my part.
<infinity> slangasek: We probably should put it through some testing and shake out some of the nastier bugs, though.  Usually, when people complain their USB sticks don't boot, we say "are you using usb-creator?  Yeah, don't do that, here's a dd command".
<infinity> slangasek: Which seems suboptimal.
<hallyn> infinity: ppl get that far?  it always refuses to allow me to hit 'install', only 'erase' button works, and that hangs
<hallyn> i'll dig deeper though, hopefully tonight
<infinity> Oh neat, guillem moved the setlocale() stuff to a common libdpkg function.  We get to patch one spot instead of 7 now.
<infinity> \o/
<hallyn> is that in usb-creator?
<infinity> hallyn: No, dpkg. :P
<hallyn> ah
<shadeslayer> cjwatson: do you have a link handy to the page that lists the build status of KDE packages? ( the one accessible via Launchpad )
 * shadeslayer has lost it :(
<slangasek> infinity: I agree, we should test all these things; I just don't know if we're going to make any headway on that this cycle
<slangasek> the plate is rather full, and balanced on a stick
#ubuntu-devel 2014-01-17
<TheMuso> @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: TheMuso
<cjwatson> shadeslayer: http://qa.ubuntuwire.com/ftbfs/#kubuntu is probably simplest
<TheMuso> @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:
<darkxst> TheMuso, Thanks!
<TheMuso> darkxst: np
<pitti> Good morning
<pitti> doko_: do you happen to have an idea about bug 1270025? i. e. is calling "dot -c" in postinst the right thing to do?
<ubottu> bug 1270025 in graphviz (Ubuntu) "graphviz package does not configure plugins" [Undecided,New] https://launchpad.net/bugs/1270025
<pitti> vila: FTR, I can reliably reproduce bug 1269886 locally; you can't?
<ubottu> bug 1269886 in bzr (Ubuntu) "autopkgtest fails in trusty: TestSmartTCPServer.test_graceful_shutdown_waits_for_clients_to_stop" [Undecided,Confirmed] https://launchpad.net/bugs/1269886
<darkxst> hey pitti
<darkxst> would autopilot work with gnome-shell?
<Noskcaj> darkxst, Should do. Check "autopilot launch gnome-shell"
<Noskcaj> Since it's gtk3 it should introspect
<darkxst> Noskcaj, gnome-shell doesnt really use standard gtk3 widgets though
<Noskcaj> darkxst, good point. As long as it will launch without error via autopilot, it should work. It might be a bit more complex though
<pitti> darkxst: yes, I don't see why not
<pitti> Noskcaj: hey
<Noskcaj> hey pitti
<pitti> Noskcaj: wrt. the libgweather transition: don't worry; some bits were done yesterday, and the two remaining ones are new versions of evolution and evolution-data-server which are prepared (but blocked by the "don't change the phone" ban ATM)
<Noskcaj> ok
<darkxst> well It launches but getting a ton of unsupported type warnings
<darkxst> although they seem to be standard GTK bits,
<Noskcaj> darkxst, Provided it's nothing like Gtk-Message: Failed to load module "autopilot", you're good
<pitti> darkxst: yes; that warning is already silenced in trunk, but it's been a while since we released AP
<wolter> Is unity launcher api on topic in this channel?
<pitti> darkxst: in fact we are trying to, currently held up by bug 1270025
<ubottu> bug 1270025 in graphviz (Ubuntu) "graphviz package does not configure plugins" [Undecided,New] https://launchpad.net/bugs/1270025
<pitti> darkxst: FTR, autopilot can only introspect simple property types (int, string, float, flags, enums, etc.); it has some special cases for GtkTextBuffer, but for properties of other class types it can't do introspection
<pitti> darkxst: btw, if you need a particular property and there is a sensible way to represent it as a string, please file a bug against autopilot-gtk
<darkxst> pitti, I really just want a test to make sure gnome-shell has loaded properly
<pitti> darkxst: so I guess you just want to check that you can find a few representative widgets and ensure that they are visible?
<darkxst> yes
<pitti> you can also check their globalRect for plausible values
<pitti> darkxst: does gnome-shell run in xvfb? (i. e. with software rendering)
<pitti> darkxst: then this could become an autopkgtest, and we'd immediately know when it breaks due to a new upload
<darkxst> it certainly runs with software rendering
<darkxst> and yes that would be better, because once gnome-shell breaks, so does gdm ;(
<pitti> darkxst: note you need to run xvfb like that: xvfb-run -s "-screen 0 1024x768x24" <program>
<pitti> (without that it runs in 8bpp which doesn't work with rendering)
<pitti> that's a common trap, in case you don't know
<darkxst> pitti, that gives XRANR missing
<darkxst> which makes gnome-shell unhappy
<pitti> ah :/
<pitti> darkxst: the other day there was a  patch floating on the upstream ML for adding xrandr support to Xvfb; but it seems it never got accepted :/
<pitti> https://launchpad.net/~pitti/+archive/ppa/ still has an xorg-server package with that patch
<pitti> but that was for raring
<pitti> darkxst: X.org with the dummy driver does know xrandr, that might work better
<darkxst> how do I run that?
<pitti> darkxst: https://git.gnome.org/browse/gnome-settings-daemon/tree/tests/gsdtestcase.py#n202
<pitti> darkxst: you can skip the copy part
<pitti> $ Xorg -config xorg-dummy.conf -logfile /tmp/log :5
<pitti> $ DISPLAY=:5 xrandr
<pitti> Screen 0: minimum 320 x 240, current 1024 x 768, maximum 1024 x 768
<pitti> darkxst: ^ something like that
<pitti> the rest of that code just does the synchronization and error handling
<pitti> tjaalton, mlankhorst, RAOF: would you happen to know anything about the fate of http://lists.x.org/archives/xorg-devel/2013-January/035114.html ? it works nicely, but it seems it got zero replies
<pitti> (in a year)
<RAOF> My guess: nobody X-ish cares enough about xvfb.
<RAOF> Particularly since the dummy drivers exist.
<pitti> yeah, see above, but it's two magnitudes harder to set up than xvfb-run
<pitti> Xvfb is still the #1 tool to run tests during project and package build, or is there something better these days?
<RAOF> pitti: Really, we should just add a wrapper script that implements xvfb-ish
<RAOF> As a regular server + dummy conf.
<pitti> RAOF: I guess that would look similar to above gsdtestcase.py function
<RAOF> Note: Not volunteering to implement said server :)
<pitti> I'm happy to do that, it's not particularly difficult
<RAOF> Right.
<pitti> but again, if it stays Debian/Ubuntu specific it's still not something you could put into upstream test suites
<pitti> like in gnome-settings-daemon and the like
<RAOF> Ideally you'd do it in something that you can do signals and fd passing in; if you pass in a fd X will write the display it's found and if you set SIGUSR1 to ignore the server will raise that once it's ready.
<RAOF> That's something that could be either upstreamed to xorg or as a trivial extra project.
<RAOF> It's probably just big enough to be a project you could get everyone to depend upon for their unittests :)
<pitti> hm; all that instead of applying this rather small patch..
<pitti> xvfb-run already implements all that logic, after all (and it's far from trivial)
<RAOF> Mostly.
<pitti> perhaps I should temporarily subscribe, and poke on the list for a review?
<RAOF> Could work.
<darkxst> hmm, xorg segfaulted when I launched xrandr ;(
<wolter> Is there a complete Unity Launcher API somewhere?
<wolter> I want to do a Pomodoro timer but I can't find stuff on connecting actions to dbusmenu items
<pitti> doko_: ah no, the *.postinst/*.postrm scripts just weren't updated for libgvc5-config-update -> libgvc6-config-update, doing
<tjaalton> pitti: yeah, I don't see why it couldn't be accepted upstream, and master is open again
<vila> pitti: haven't tried reproducing locally yet, my hands are full :-( I strongly suspect this bug to be a test-only issue given the past similar test transient failures caused by that MP. I.e. I'm a bit afraid about spending time diagnosing more precisely and ending up with the same conclusion :-/ So if you have a way to just skip this test for the time being, that sounds like the most pragmatic thing to do
<pitti> vila: bzr selftest has an -x, that should work?
<vila> pitti: yup
<vila> pitti: you can add that thanks to dep8 right ?
<pitti> yes, in debian/tests/testsuite
<vila> pitti: I dislike excluding tests instead of turning them into expected failures, but again, that's the most pragmatic here :-/
<dholbach> good morning
<pitti> vila: well, the next upload can't be done without fixing it, as the package will fail to build, so that's ok
<pitti> hey dholbach
<dholbach> hey pitti
<vila> pitti: ionce I get to the point where I can add a trusty chroot to http://babune.ladeuil.net:24842/ it will show up again anyway
<vila> pitti: so nothing will be lost
<pitti> vila: ack, thanks
<vila> pitti: FTR, it pisses me off to not be able to look at that more closely. On a more positive side, is there a way to have bazaar@lists.canonical.com mailed when such a failure happens ? (Don't worry about not being subscribed, I'll white list when it'll happen)
<pitti> vila: hm, after I hit dput it occurred to me that this probalby won't work -- the test will fail during package build so that never gets into trusty; I'll have to ignore it during package build as well
<pitti> vila: usually the last uploader gets mailed for them
<pitti> plus jibel and me for all of them
<pitti> we don't currently have a more flexible way of subscribing, sorry
<vila> pitti: no idea who the uploader is this way, ha, too bad, never mind
<pitti> vila: so for now I do the  "ping vila" approach if I see a failure :)
<vila> s/way/day/
<vila> pitti: ok ;-D
<zyga> good morning
<doko_> pitti, thanks
<doko> slangasek, I assume the qt5 update will still take a while?
<mlankhorst> morning
<zyga> can anyone confirm that python3.3-coverage program from python3-coverage package crashes on import
<darkxst> oh gah, what will happen with modemmanager 1.0 in -proprosed, pretty sure there are rdepends that are non-trivial to port to the new api;(
<zyga> what?
<zyga> barry, doko: is python3.4 the default python now?
<seb128> doko, e-d-s failing to build ... you commented saying it uses hardening without the corresponding build-depends, but even with hardening-wrapper installed the configure hits the same "Error in `/usr/bin/ld.bfd.real': corrupted double-linked list"
<zyga> python3-coverage has shebang of python3.4
<doko> seb128, can you sbeattie how to properly build with hardening-wrapper and pie?  the problem is that configure calls gcc with -static -fpie
<doko> in the past this did work by chance
<seb128> sbeattie, hey
<doko> zyga, you can answer this question yourself by building in a trusty chroot
<zyga> doko: I am running trusty and I actually followed your test rebuild archive
<zyga> doko: I'm trying to understand if this is a bug or is it expected
<doko> zyga, depends on what the build-dependencies are. in general, we do not want to have version specific shebangs. python3 should it be
<zyga> doko: python3 is still 3.3 for me, so it seems the coverage package is broken
<zyga> doko: I think coverage might be a bit special there as you want to use specific coverage if invoked as specific pythonX.Y-coverage script, it just seems those scripts are generated incorrectly (or patched incorrectly, maybe)
<zyga> (specific python version, not coverage version, sorry)
<doko> zyga, I'll have a look later, or I'll ask barry to have a look
<pitti> barry: would you mind looking into the mailman autopkgtest failures? there are a lot of failed tests (reproducible with run-adt-test locally, so it's not a DC/networking issue)
<apachelogger> how do I find out why a package is being held in trusty-proposed?
<Laney> apachelogger: https://wiki.ubuntu.com/ProposedMigration is useful
<Laney> there's two links at the end of the first section which contain the output
<apachelogger> thanks
<doko> jamespage, b-d golang-go [amd64 armhf i386]
<jamespage> doko, for juju-core? not just yet
<doko> ?
<doko> it's dep-wait on the other archs ...
<jamespage> doko, yes - and it will continue to be until I have done the work to package a separate go tool for use with gccgo
<doko> ahh, ok
<jamespage> doko, davecheney has something working from mainline golang with gccgo - once he's happy with that I'll package and upload
<jamespage> doko, for now I'm building with both for existing archs so people can test it out and compare/contrast
<barry> pitti: i can look
<barry> zyga: what's up?
<zyga> barry: hey
<zyga> barry: I think python3-coverage is busted
<zyga> barry: first off, python3-coverage is running python3.4
<zyga> barry: then python3.3-coverage throws ImportError that is really odd
<zyga> barry: this is on 3.7+dfsg.1-4
<barry> zyga: yep, looks like they are.  can you file bugs and send me the #s
<zyga> barry: certainly, filing now
<zyga> barry: https://bugs.launchpad.net/ubuntu/+source/python-coverage/+bug/1270167
<ubottu> Ubuntu bug 1270167 in python-coverage (Ubuntu) "python3-coverage uses python3.4 as interpreter " [Undecided,New]
<seb128> cjwatson, hey, what determines if the grub menu should be open on boot (out of the grub config)? (I guess it writes a file somewhere that is cleaned after a successful boot to do the "open on next boot in the previous boot didnt work")
<seb128> cjwatson, I'm asking because playing with your new grub I managed to land in a position where it displays the menu at every boot now
<barry> zyga: subscribed.  i'll double check on debian - i'm in regular contact with the maintainer
<cjwatson> seb128: right, it sets a flag using save_env before booting, which is cleared by /etc/init.d/grub-common when we get to the end of rc2
<cjwatson> using grub-editenv
<seb128> cjwatson, the only thing I did is to hammer ctrl/shift to open the menu and ctrl-alt-suppr some of the boots on plymouth beause I didn't manage to open the menu
<cjwatson> seb128: check whether /etc/init.d/grub-common is actually being called at boot
<seb128> what's the easiest way to see that? logs?
<cjwatson> hack it to write to some file of your choice
<zyga> barry: https://bugs.launchpad.net/ubuntu/+source/python-coverage/+bug/1270168
<ubottu> Ubuntu bug 1270168 in python-coverage (Ubuntu) "python3.3-coverage crashes with ImportError on startup" [Undecided,New]
<zyga> barry: thanks a lot
<seb128> ok
<zyga> barry: looks like some of the multi-version magic went wrong, I read the debian packaging but it was pretty comples for what is otherwise setup.py install
<zyga> complex
<seb128> cjwatson, otherwise, if that's me pressing shift that leads to open the menu, I think that it opens with the 10s timeout on manual trigger when it used to open without timeout
<seb128> cjwatson, or my testing/setup might just be buggy
<cjwatson> seb128: you might also try "grub-editenv /boot/grub/grubenv list" after boot to see what that says
<seb128> cjwatson, on the good news side, boots works fine, as do recovery mode etc (my setup is a "boring" 1 disk, 1 OS, no uefi though)
<seb128> $ grub-editenv /boot/grub/grubenv list
<seb128> $
<cjwatson> seb128: timeout handling has changed around a bit, I may have to double-check that.  wouldn't be a blocker though
<cjwatson> seb128: pastebin /boot/grub/grub.cfg?
<seb128> cjwatson, http://paste.ubuntu.com/6768202/
<zyga> stgraber: hey, pastebinit *stilL* uses /usr/bin/env python shebang, it will still be broken in every python3 virtualenv :-(
<cjwatson> seb128: and /etc/default/grub please?
<seb128> cjwatson, http://paste.ubuntu.com/6768212/
<cjwatson> seb128: Hmm, looks like 569766e4 broke this
<cjwatson> seb128: Could you mention this in the bug?  I'll have to try to chase this down upstream
<seb128> cjwatson, done, I'm not sure what details are useful but I guess you will fill those?
<seb128> cjwatson, let me know if you need more debug infos from my system
<cjwatson> Nope, I basically just need to think very hard about the timeout stuff, again
<barry> 5ols
<seb128> cjwatson, was your "commit id creating the issue" comment about the 10s timeout on manual opening or about the menu opening on boot?
<seb128> cjwatson, the grub-common script is correctly called and it seems the flag is not set from a "list" call, so I guess the menu is opening for another reason (doesn't happen anymore after downgrading to the trusty version)
<seb128> on that note, time for some exercice, be back in 1h
<cjwatson> seb128: they're the same thing
<cjwatson> seb128: (Looking at it, I think I'm not quite correct in blaming upstream - the upstream change is trying to preserve previous upstream behaviour, and I dropped a little bit too much of the Ubuntu patch set)
<stgraber> zyga: I'm pretty sure the release I made yesterday uses /usr/bin/python3
<zyga> stgraber: ah, sorry then, it's probably not on my development box yet
<stgraber> zyga: yeah, I don't take care of the packaging myself, I'm just the upstream for that one. I notified the Debian maintainer but it hasn't been uploaded yet.
<cjwatson> seb128: OK, figured it out, fixed for the next upload
<seb128> cjwatson, great, thank you!
<cjwatson> thanks for the testing
<brendand> doko, my packages build is failing seemingly because python3.4 is in py3versions, but python3.4 is not there
<brendand> doko, in trusty
<doko> brendand, is the package b-d on the python3-all / python3-all-dev package?
<brendand> doko, no - python3 (>= 3.2),
<doko> brendand, which package?
<brendand> doko, it's checkbox-certification. it's only in a PPA
<brendand> doko, so it should b-d on python3-all?
<doko> brendand, yes
<rbasak> chiluk: please could you see if bug 1270151 is a possible -proposed regression on mysql-server-5.5 5.5.34-0ubuntu0.12.04.2, or just user error?
<ubottu> bug 1270151 in mysql-5.5 (Ubuntu) "package mysql-server-5.5 5.5.34-0ubuntu0.12.04.2 failed to install/upgrade: le sous-processus script post-installation installÃ© a retournÃ© une erreur de sortie d'Ã©tat 1" [Undecided,New] https://launchpad.net/bugs/1270151
<chiluk> rbasak ... sure
<chiluk> rbasak doesn't look like it.
<rbasak> chiluk: thanks. Often users misconfigure mysql and then apport files postinst failure bugs because the service doesn't start. So it could be that. I just noticed that it's from -proposed.
<chiluk> I'll verify the upload now though.
<rbasak> Thanks!
<chiluk> rbasak, sure thing... I was pretty careful with that upload... so I don't have much faith that this is a regression.
<cjwatson> Grr.  Why does https://launchpad.net/ubuntu/+source/ruby-gettext/3.0.3-2/+build/5470350 fail but https://launchpad.net/~cjwatson/+archive/ppa/+build/5473079 (identical build in a PPA, identical set of build-dependencies installed, same version of launchpad-buildd) succeed?
<cjwatson> Kernels differ but the chances of that affecting locale-ish tests seem fairly remote
<cjwatson> I guess I can try hitting it with LC_ALL=C.UTF-8 but I'm a bit reluctant to do that without some way to reproduce the problem
<cjwatson> Maybe if I try a devirt PPA ...
<chiluk> rbasak I was able to install 12.04.1 and upgrade to 12.04.2 without issue.
<rbasak> chiluk: thank you for verifying, and for doing the work!
<chiluk> rbasak it is entirely possible that he does not have enough free disk space
<chiluk> and the post script is failing due to the new check for free space.
<chiluk> rbasak.. I also don't speek french.. so I'm not entirely sure what the error messages are saying.
<rbasak> chiluk: it's a postinst failure.
<rbasak> chiluk: postinst returned error status 1
<chiluk> rbasak.. I gathered that much.. I was more curious what MySQLConf.etc.mysql.my.cnf: Error: [Errno 2] Aucun fichier ou dossier de ce type: '/etc/mysql/my.cnf'
<chiluk>  means
<rbasak> Oh
<rbasak> Hmm
<tarpman> chiluk: no such file or directory
<chiluk> well there's your problem.
<tarpman> ENOENT
<rbasak> OK so that's the user.
<rbasak> Thanks
 * rbasak learns a little more French
<chiluk> I wouldn't expect it to function before the upgrade either.
<rbasak> That seems likely. I just wanted to be sure. That makes it clear, and I'm now confident it's not a regression. Thanks!
<chiluk> Google translate = "Any file or folder of this type:"  ... not as helpful
<rbasak> (and thanks tarpman)
<tarpman> :)
<rbasak> Usually I guess the translations but I didn't spot that one.
<infinity> cjwatson: devirts are far more likely to have, as some point, had lp-buildd restarted or upgraded by hand, rather than started by init.
<infinity> cjwatson: Which leads to the locale environment leak issue you fixed in bzr but we haven't rolled out.
<cjwatson> Yeah, I was half-thinking that
<cjwatson> The failure reproduces in a devirt PPA
<cjwatson> So I should maybe just try to get that lp-buildd rolled out early next week rather than bothering with an upload.
<infinity> cjwatson: Well, I think a package that fails its testsuite due to locale issues is still buggy.
<infinity> cjwatson: It's nice for buildds to provide a consistently sane environemnt, but that's no excuse for shoddy packaging either. :P
<infinity> (And easy enough to test locally by just building in C, C.UTF-8 and en_US.UTF-8 and seeing what explodes)
<cjwatson> I'd be more worried about that if the failure reproduced with sbuild locally
<cjwatson> But let's try it if I force LC_ALL=C
<infinity> I'd be inclined to test locally in a chroot I can control and know the state of, rather than throwing random hammers at buildds who's environment I'm guessing at.
<infinity> whose*
<cjwatson> I'm only throwing random hammers out of desperation at being unable to reproduce the failure locally
<infinity> I ran into one of these a while back that was confusing as all heck to track down.
<infinity> cjwatson: I bet I can reproduce.  Lemme look.
<cjwatson> That's obviously where I started
<cjwatson> OK.  Note that you need to have a bootstrap ruby-gettext in the chroot
<cjwatson> (Or available via apt sources)
<infinity> Check.  The one from your PPA should do, I guess.
<cjwatson> Yeah, or the one from Debian
<infinity> cjwatson: Okay, I apologize for questioning your science.  Not only can I not reproduce, but I'm officially confused.
<cjwatson> infinity: I wonder what lp-buildd's env on the builders in question actually says
<infinity> Throw something at a devirt with "printenv" and "locale" in debian/rules, and aim it at toyol, so we're debugging the same machine?
<cjwatson> Or I could ask a webop
<infinity> Well, that doesn't get you the env during a package build.
<cjwatson> Finding the env of lp-buildd would probably do
<infinity> Probably.
<stgraber> infinity: pushing procenv to that buildd should do the trick
<cjwatson> Let me do that quickly then
<infinity> Already done.
<cjwatson> k
<infinity> Well, once process-upload hears me.
<cjwatson> Copies are usually a bit quicker :)
<infinity> Yeah, I wasn't thinking.
<infinity> https://launchpad.net/~adconrad/+archive/ppa/+build/5473272
<infinity> And in case i386ness matters:
<infinity> https://launchpad.net/~adconrad/+archive/ppa/+build/5473275
<infinity> Hrm, and can't reproduce when mirroring that env either.
<infinity> Double-U Tee Eff.
<cjwatson> infinity: I can
<cjwatson> -       dh_auto_install
<cjwatson> +       LANG=C LANGUAGE=en_GB: LC_ALL=C dh_auto_install
<cjwatson> reproduces it in sbuild
<infinity> cjwatson: Huh.  Didn't seem to break it here when I just set that in my chroot env.  But yay.
<infinity> Oh.  Balls.  My science was probably crap.
<infinity> I used debuild, which I bet cleanses.
<cjwatson> changing LC_ALL to C.UTF-8 is indeed sufficient
<infinity> cjwatson: Or unsetting LANGUAGE would probably also do.
<cjwatson> Still fails one test if I do that
<infinity> Fun.
 * cjwatson uploads, let's see
<infinity> cjwatson: It would appear that you don't win.
<cjwatson> https://launchpad.net/ubuntu/+source/ruby-gettext/3.0.3-2ubuntu1/+build/5473400  argh
<cjwatson> I give up, it's dinnertime anyway.  Feel free to continue beating on it if you get a chance ...
<jtaylor> can one force push scipy out of proposed?
<jtaylor> its a minor test failure, and a new upstream release is due in a few days where I will skip it
<jtaylor> but py3.4 scipy helps for rdepends
<jtaylor> oh wait builds are against proposed anyway
<jtaylor> so nevermind, didn'T think about that
<hallyn> all right this sandbox-upgrade-testing script is getting on my nerves.  It's killing my nested kvm with copying host to destination...
<infinity> cjwatson: ruby-gettext hammer applied and forwarded to Debian.
#ubuntu-devel 2014-01-18
<cjwatson> infinity: great, thanks
<paddy> elky: so lets do this again
<paddy> come on Mrs Pride
<elky> i didn't kick you. talk to rww
<paddy> you asshole gave him #o
<paddy> OPs
<paddy> for heavens sake, how stupid are you?
<paddy> and now you need the cowboy as backup or what?
<paddy> what a woman
<paddy> sabdfl: i have a serious problem with the code of conduct and some of your people
<paddy> do we talk via twitter maybe?
<paddy> or here?
<paddy> sabdfl: this is no joke. elky gave channel access to a person who would break the code of conduct just because she thought she would not break it on her own
<rww> paddy: I believe the correct venue for this would be #ubuntu-ops.
<paddy> rww: please be quiet, abuser.
<rww> paddy: Also, if you believe that op actions violate the code of conduct, the correct escalation is to the IRC Council, which has delegated authority from the Community Council to deal with such matters.
<paddy> rww: is that what elky copied you to say?
<paddy> rww: you have own arms and own legs, right?
<rww> paddy: Indeed, which is why I find your first reply and your fixation on elky a bit odd.
<paddy> rww: does that mean you kicked me from #ubuntu-offtopics without reason to talk to me on #ubuntu-ops about it?
<paddy> its well known that i have a fixation on females, rww. we all remember how i was stalking christel, etc.
<rww> No, I kicked you from #ubuntu-offtopic because you're a troll. And again, this is not the right place to be having this conversation, because it's a channel for Ubuntu development, not #ubuntu-offtopic's ban resolution channel.
<paddy> this is the pefect place to make some people aware of a problem
<paddy> a serious problem
<paddy> elky, rww and a few others dominate the channel #ubuntu-offtopic so that it is no longer useful for most people
<paddy> i can bring enough people who say that too
<paddy> you guys better make a new channel and make this your home
<paddy> #ubuntu-offtopic is for _users_
<paddy> those who you call trolls
<rww> Interesting idea. Put it on https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda and the relevant people can discuss it with you at the appropriate time :)
<paddy> you guys use derogatory language in places where the code of conduct applies
<paddy> you guys try to discriminate me and other people
<paddy> this is not acceptable
<paddy> rww: you better stayed on #moocows on OFTC
<paddy> rww: you dont need to copy me thinks that elky wants you to say
<rww> paddy: FYI, if you're looking for someone to complain about #ubuntu-* operators to, IdleOne is a member of said IRC Council and is currently online.
<paddy> rww: you dont need to copy me thinks that elky wants you to say
<paddy> when rww tells elky "give me ops so i can boot paddy for no reason" and she does so then she is in the line of fire
<paddy> has nothing to do with her stupid gender
<paddy> but you tried to play that card again, right?
<rww> paddy: Happily, IdleOne is in #ubuntu-offtopic too, and thus will have logs of me (not) saying this, so please go talk to them so they can get elky fired or whatever it is you want. Let's leave #ubuntu-devel for making Ubuntu better :)
<paddy> but you tried to play that card again.
<paddy> and now you are hilighting random people because you are helpless
<paddy> what a _man_
<paddy> you two make a super nice couple, really
<rww> Actually, I'm highlighting one of the people in charge of Ubuntu's IRC operators, which is why I keep saying you should talk to them. Seriously though, they're the people you should be directing this towards.
<paddy> you guys escalate so i can escalate and now you are absolutely helpless
<paddy> how sad is that for adults?
<StevenK> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<paddy> lets escalate to twitter
<paddy> will take a while till i have a a log ready to be spread
<paddy> but you guys want it to be like this
<Hobbsee> paddy:
<Hobbsee> paddy: you can leave now, or I can ban you in a minute.  Take your pick, but you're not going to stay here and keep talking.
<paddy> make sure you set a reason that makes sense
<IdleOne> paddy: Would you kindly not disrupt channels with discussion of things that don't concern those channels.
<paddy> is that the required warning before you can ban?
<IdleOne> I'm asking you nicely
<paddy> i see
<IdleOne> wasn't trying to warn you about anything
<IdleOne> oh it works
<IdleOne> Hobbsee: at ease soldier :)
<IdleOne> didn't mean they had to leave :/
<shadeslayer> btw is there a way to debug why I have no com.ubuntu.Upstart session dbus interface>
<iainkay_> anybody tried compiling compiz plugins extra on ubuntu 13.10?
<Peace-> just a question wtf this version is a bit old ?
<Peace-> mawk -W version
<Peace-> mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brenna
<Peace-> why ?
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554167
<ubottu> Debian bug 554167 in mawk "New mawk upstream version" [Wishlist,Open]
<Peace-> sigh
<miseria> "charlando con un arbol pregunte: porque tenia el cerebro enterrado? responde: la mision es proteger la tierra" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<Logan_> wat
<mdeslaur> anyone know how to do a "python setup.py configure --blahblah" with dh_python2?
<Noskcaj> roaksoax, kirkland. Any chance of  testdrive release? mostly because it's now broken in trusty because of bug 1270331 .
<ubottu> bug 1270331 in testdrive (Ubuntu) "In trusty testdrive will not create a virtualbox virtual machine of lubntu i386 guest from trusty amd 64 host" [Undecided,New] https://launchpad.net/bugs/1270331
<Noskcaj> And could we keep it as 3.25 rather than 3.25-0ubuntu1 so i can get this uploaded to debian.
#ubuntu-devel 2014-01-19
<Noskcaj> Can someone please get lp:~noskcaj/ubuntu/trusty/argyll/merge and re-add the drop-usb-db.patch in a way it applies?
<Noskcaj> I have no idea how the patch is working, so i can't really fix it
<Noskcaj> Can someone retry pinba-engine-mysql on am64 and python-dmidecode on i386? Both had schroot failures
<mitya57> Noskcaj: retried
<Noskcaj> ty
<Noskcaj> mdeslaur, bdmurray: Could either of you look at https://code.launchpad.net/~noskcaj/update-notifier/tray-notification/+merge/202210
<tester56> will trusty use chromium by default?
<Noskcaj> xnox, Can you re-add the drop-usb-db.patch to argyll for me? I can't get the patch to apply on the merge. https://code.launchpad.net/~noskcaj/ubuntu/trusty/argyll/merge
<brainwash> can anyone take a look at this merge proposal please?
<brainwash> https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-power-manager/systemd/+merge/202226
<brainwash> the bug is affecting many xubuntu/xfce users in trusty and saucy, it is literally the number 1 issue currently
<Noskcaj> pitti, For gnome-system-tools, why would we drop gthread.patch? It's from debian and isn't hurting anything
<Noskcaj> pitti, I've un-split g-s-t's binaries, I think the other changes you suggested aren't needed, so could you please review?
#ubuntu-devel 2015-01-12
<rlaager> Okay, so I rebuilt my backport of libgadu against libgnutls26. Now, I definitely get "Unable to locate package libmessaging-menu-dev" on Trusty: https://launchpadlibrarian.net/194579012/buildlog_ubuntu-precise-amd64.pidgin_1%3A2.10.11-1ubuntu0%2Bpidgin4.12.04_MANUALDEPWAIT.txt.gz
<rlaager> err, that's precise, nevermind
<rlaager> Okay, so now trusty says, "libgadu-dev : Depends: libgnutls26-dev but it is not installable".
<pitti> Good morning
<pitti> hallyn: cgmanager startup behaviour> ah great, then all is well AFAICS?
<darkxst> morning pitti
<pitti> hey darkxst
<darkxst> pitti, is there some way to override make check in cdbs (for xvfb-run)?
<pitti> darkxst: yes, there is; /me needs to look, it's been a few years
<pitti> there's DEB_MAKE_CHECK_TARGET, but that's not sufficient
<darkxst> nope, best I could find was DEB_MAKE_INVOKE, but that runs the entire build through xvfb
<pitti> darkxst: perhaps just don't define DEB_MAKE_CHECK_TARGET and run the checks in common-post-build-arch::?
<darkxst> I did try something like that, but tests (for gjs) still seem to run
<darkxst> I suppose I could make the DEB_MAKE_CHECK_TARGET non fatal though, then it would work
<darkxst> or just completely ignore build tests, since we have autopkgtests also?
<darkxst> does that seem reasonable? pretty sure its exactly the same test suite
<pitti> jamespage: thanks for starting the init migration on nova! FTR, it's stuck in -proposed as nova-objectstore doesn't seem to start automatically (https://jenkins.qa.ubuntu.com/job/vivid-adt-nova/47/ARCH=amd64,label=adt/console)
<pitti> darkxst: setting DEB_MAKE_CHECK_TARGET to "check || true" would run everything twice
<pitti> darkxst: build tests are still nice as they run on all the arches
<pitti> darkxst: I still don't understand -- AFAICS cdbs does not run "make check" automatically
<pitti> darkxst: are you sure you don't have anything in your rules which invokes the tests automatically? perhaps it even happens through normal "make" in the upstream build system?
<darkxst> pitti, when I removed DEB_MAKE_CHECK_TARGET I still had two sets of tests running, one for the override
<darkxst> though gjs doesnt seem to run make check atleast in jhbuild
<dholbach> good morning
<pitti> didrocks: argh, floodlight holding up sysvinit again :/
<pitti> Laney, infinity: could either of you please force-badtest floodlight?
<didrocks> pitti: it's a different test failing than last time?
<pitti> didrocks: no, exactly the same
<pitti> (three)
<didrocks> ah :(
<didrocks> pitti: so, systemd hackfest this week it seems? I planned to do some dev story stuff, but will see if I can join
<pitti> didrocks: yes; we should wait for slangasek's definitive answer, but I think Thu/Fri
<slangasek> yes Thu-Fri
<didrocks> ok, let's see if I can join (I did some transitions last week)
<pitti> oh, hey slangasek -- unsual hour :)
<pitti> slangasek: so, I updated https://wiki.ubuntu.com/SystemdForUpstartUsers, will create a pad for coordination with links and lists of packages to convert grouped by openstack/desktop/juju/etc.
<pitti> slangasek, didrocks: as for IRC, I think just #u-devel should be fine, WDYT?
<slangasek> yes, that's my preference
<didrocks> pitti: yeah, sounds good to me
<pitti> and then we can have hangouts as necessary, but having it on all the time is too distracting IMHO
<didrocks> agreed
 * pitti yays https://launchpad.net/ubuntu/+source/keystone/1:2015.1~b1-0ubuntu2 and smells another MIR coming for didrocks  :)
<slangasek> ok; I'd like to at least have a daily hangout at the start of the overlap between US and EU
<pitti> that sounds good
<didrocks> pitti: it's MIR-day anyway, 11 packages now (fctix, second edition) :p
<didrocks> pitti: I'm a little bit afraid about that autogenerated systemd units btw
 * pitti creates http://pad.ubuntu.com/systemd-porting-sprint
<pitti> didrocks: I haven't looked at it at all yet TBH
<didrocks> seems like it will just "have everything started on runlevel 5 equivalent"
<didrocks> instead of seeing relations between services
<pitti> didrocks: the current upstart jobs aren't really much different either AFAIR
<didrocks> right
<didrocks> it was just the opportunity to get it right :)
<didrocks> but having a tool doing that genericnessâ¦ meh
<jamespage> pitti, will look this morning
<pitti> didrocks, jamespage: yeah, .init.in also sounds a lot like it should just use /lib/init/init-d-script
<didrocks> yeah, as I did for whoopsie IIRC
<jamespage> pitti, hmm - maybe - currently the openstack-pkg-tools helper produces one that has some systemd specific actions as well
<jamespage> pitti, I think we'll run with that for this cycle at least as it brings us a bit closer to Debian as well
<pitti> jamespage: sounds good; merging/getting closer with Debian makes stuff easier in its own right, too
<jamespage> pitti, oops - missed the init.in for objectstore - fixing now
<pitti> jamespage: thanks! (and yay tests!)
<pitti> slangasek: I prepared http://pad.ubuntu.com/systemd-porting-sprint
<pitti> I think jamespage could already grab some of the OpenStack ones which he already started
<didrocks> pitti: I'm unsure how often the file system update on the server, but some are already transitionned from Friday
<pitti> didrocks: yeah, it's lagging several days behind for some reason
<pitti> didrocks: I also transitioned two (apport-noui and mythtv)
<pitti> didrocks: but so far it has always updated eventually
<didrocks> yeah, it will just need some refresh then or should I remove those already done?
<pitti> didrocks: just remove them from the pad, please
<didrocks> doing
<jamespage> pitti, canonical server team will deal with the openstack ones
<jamespage> pitti, I have a few to review from coreycb last week
<didrocks> jamespage: will you handle the server ones as well?
<jamespage> didrocks, sure
<pitti> jamespage: ack; I kept them separate in the categorization as I figured converting those might be a bit special (upstream coordination, and they are all relatively similar, etc.)
<jamespage> didrocks, rbasak will help out there as well
<didrocks> great ;)
<pitti> jamespage: (no need to add "TODO" -- perhaps instead say "jamespage"
<pitti> jamespage: I updated the status of keystone
<jamespage> pitti, ah - right - yes - indeed - its stuck in proposed
<pitti> slangasek: should I send the u-d-a@ announcement now, or is there something further to be done?
<pitti> slangasek: ah, I have an XX:XX for the hangout time, but we can update the pad later
<jamespage> pitti, when's the planned switch to systemd happening? I'll poke the juju dev team to deal with the autogenerated upstart jobs
<pitti> jamespage: "we release when it's ready" by and large, but we do aim for 15.04, i. e. vivid
<pitti> we shouldn't drag it for too long
<pitti> jamespage: https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration has the remaining work aside from porting the jobs
<jamespage> pitti, oh I agree - but do we have a target for the swithover?
<pitti> jamespage: I figure by feature freeze?
<pitti> (no particular date)
<jamespage> pitti, sounds reasonable
<jamespage> pitti, I know that the juju team will prioritize the work accordingly - all of our vivid openstack testing will break on switchover unless we have the new juju bits
<pitti> jamespage: so end of January would be nice, so that we still have enough time to fix the rough edges
<jamespage> +1 ack
<pitti> jamespage: cool, thanks for coordinating that!
<jamespage> pitti, I've raised a bug for juju-core, linked it to the blueprint and pinged the ta and engineering manager for juju-core
<jamespage> hopefully that should get some attention post haste
<pitti> thanks; tagged and subscribed
<pitti> jamespage: and replaced the textual WI with the bug
<jamespage> pitti, ack
<jamespage> rbasak, ^^ fyi - I know you are point on juju-core crossteam activities
<cjwatson> rlaager: There's no such package libgnutls26-dev in trusty; it was called libgnutls-dev
<cjwatson> rlaager: Generally I'd advise using chdist from devscripts to reproduce this kind of thing; that way you can have an isolated apt-get environment (that can't actually install packages, but it can tell you whether it would be able to resolve dependencies) that only considers trusty plus the PPA in question
<rlaager> cjwatson: Thanks. I wasn't aware of that tool.
<pitti> stgraber: oh, I see -- /lib/udev/bridge-network-interface is one of the udev-y things which would bring up bridges refering to a recently up'ed physical interface
<pitti> (40-bridge-network-interface.rules)
<pitti> didrocks: erk -- check /usr/sbin/invoke-rc.d line 577
<pitti> didrocks: I just got an error message "op: not found" due to the extra line break
<pitti> from http://launchpadlibrarian.net/194237210/sysvinit_2.88dsf-53.2ubuntu3_2.88dsf-53.2ubuntu4.diff.gz
<pitti> didrocks: want to upload a fix, or want me to if you don't have time?
<cjwatson> that was already fixed
<cjwatson> http://launchpadlibrarian.net/194242250/sysvinit_2.88dsf-53.2ubuntu4_2.88dsf-53.2ubuntu5.diff.gz
<pitti> cjwatson: no, it wasn't -- the error above is the line immediately below that
<cjwatson> oh yeah, good point
<pitti> i. e. the printerror
<cjwatson> misread, sorry
<pitti> well, *shrug*, I'll just upload it
<pitti> cjwatson, didrocks: ^ uploaded (2.88dsf-53.2ubuntu6)
<pitti> jamespage: nova test succeeds again, cheers!
<jamespage> pitti, np
<cjwatson> there was already an ubuntu6 ...
<cjwatson> pitti: you'll need to rebase on https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-53.2ubuntu6
<pitti> argh, sorry about that
 * pitti says "Use pull-lp-source, Luke!" a hundred times
<pitti> ubuntu7 is the charm! uploaded
<highvoltage> heh :)
<didrocks> pitti: sorry, was out for some exercise
<pitti> didrocks: no worries
<didrocks> pitti: I really wonder what I did with my vim snippet in that upload to get the 2 breaksâ¦
<pitti> tseliot: I updated bug 1312255 with some info and a question, but by and large translating this into a unit looks reasonably straightforward; let me know if you have questions
<ubottu> bug 1312255 in nvidia-prime (Ubuntu) "[systemd] nvidia-prime package needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312255
<pitti> didrocks: forgot to hit the pastetoggle key? :-)
<didrocks> pitti: probably :p
<tseliot> pitti: I'll have a look at it, thanks
 * xnox has an evil plan for upstart-local-bridge
<didrocks> xnox: based on generators, from what I see :)
<xnox> didrocks: yeah, but with full compat for system-systemd, session-systemd, session-upstart without system-upstart.
 * xnox should post an email about it.
<didrocks> nice ;) yeah, please do
<LocutusOfBorg1> pitti, thanks for the answers, I don't know the best solution, feel free to do what you think is best
<LocutusOfBorg1> ;)
<pitti> LocutusOfBorg1: I don't know what is best, I don't know why that line got removed
<pitti> LocutusOfBorg1: is there some upstream commit that this refers to which might have some more info?
<pitti> stgraber: systemd with the recent user lxc fixes is now in vivid
<LocutusOfBorg1> pitti, found it https://www.virtualbox.org/changeset/48422/vbox/trunk/src/VBox/Additions/linux/drm/vboxvideo_drm.c
<LocutusOfBorg1> " Additions/linux/drm: removed .fasync as drm_fasync is an unneeded no-op to be removed in Linux 3.12."
<pitti> LocutusOfBorg1: ah cool, thanks!
<Bluefoxicy> folks
<Bluefoxicy> listen, seriously.
<Bluefoxicy> Turn off swap.
<Bluefoxicy> Now have a process eat a ton of RAM.  Just buttload it.
 * pitti did ages ago
<Bluefoxicy> Like, that disk cache thing, the buffers?  They go down.
<Bluefoxicy> 16GB RAM, 7GB used, 9GB disk cache?  Turns into 15GB used, 1GB ... then 0.5GB... then 100MB
<Bluefoxicy> know what happens?
<Bluefoxicy> Your computer starts thrashing the hard disk, and just locks up.  If you wait long enough, the OOM killer eventually kicks in (if the process keeps consuming more RAM), kills something, and you can use your PC again.
<Bluefoxicy> Because you wind up re-reading the same library files again and again several times per second when you run low on disk cache.
<Bluefoxicy> So
<Bluefoxicy> really
<pitti> LocutusOfBorg1: uploaded, thanks! I update the bug
<Bluefoxicy> Why isn't there a tunable to tell the kernel to kick in OOM kill early?
<LocutusOfBorg1> thanks for caring pitti ;)
<Bluefoxicy> e.g when reclaimable RAM (including disk cache, buffers, etc.) drops below a certain threshold
<Bluefoxicy> just to say "your PC really won't be usable if you have less than this much RAM for disk cache and buffers, so falling below this is an OOM situation"
 * Bluefoxicy sets kernel.sysrq to 240 so he can throw an OOM kill manually when this happens.
<highvoltage> /win 11
<pitti> highvoltage: /lose 5
<pitti> highvoltage: hey Jonathan, how are you?
<highvoltage> pitti: hey! doing good thanks and you?
<pitti> highvoltage: quite fine, thanks!
<pitti> highvoltage: the ZA summer a few weeks ago was nice :)
<highvoltage> pitti: are you visiting again next month?
<pitti> highvoltage: no, I won't; I'll go to FOSDEM (Brussels)
<xnox> pitti: see you there ;-) i've booked everything for myself.
<pitti> xnox: I don't have much to book except for the train
<pitti> xnox: beer time after the hackfest and on Sat evening then, I figure? :-)
<highvoltage> ah, still nice :)
<xnox> pitti: yeap.
<hallyn> pitti: i'm a bit lost at this point.  You mean all is well if we just do nothing?
<pitti> hallyn: well, we still need to start cgmanager by default
<pitti> hallyn: but I meant aside from that it seems there's nothing else blocking that?
<pitti> jamespage: ironic's new dep on the nonexisting python-pysendfile -- is that just a typo and should be python-sendfile, or is that a PPA package of some sort?
<jamespage> pitti, argh that's me being a dumbass
<jamespage> pitti, at least I think so
 * jamespage looks
<didrocks> pitti: didn't you tell there was an issue about ressource management? like both settings process in the same cgroup resources?
<pitti> jamespage: debian/pydist-overrides removes "pysendfile", that apparently led to that
<hallyn> pitti: with no other changes?
<jamespage> pitti, hmm - apparently so although I thought the dh-python was clever enough to figure out where that comes from based on installed packages
<pitti> didrocks: obviously everything has to decide whether it talks to systemd or cgmanager for shuffling stuff around, but the use cases should be fairly non-overlapping
<pitti> hallyn: the "disallow fumbling with the systemd controller" was discussed and isn't possible, and you already wrote that cgmanager doesn't change the setup at startup
<hallyn> yup
<pitti> hallyn: so I see nothing else ATM -- do you still?
<pitti> jamespage: ah, that was bug 1391960 -- so apparently it either needs to become a build dep or a manual binary dep?
<ubottu> bug 1391960 in ironic (Ubuntu) "Missing python-sendfile dependency breaks GlanceImageService" [Undecided,New] https://launchpad.net/bugs/1391960
<didrocks> tedg: so nothing to do for you as well in UAL then? ^
<jamespage> pitti, it is a build dep
<pitti> jamespage: oh ok, so dh_python isn't as clever as it should be then?
<pitti> didrocks: yep
<pitti> didrocks: talked to tedg a few days ago
<xnox> pitti: hallyn: is that cgroups/systemd discussion somewhere on a bug report mailing list, or just irc?
<tedg> didrocks, It depends on Upstart, if it's still using CGManager to create the cgroups, we need to talk to cgmanager to access them. Which I think is the plan. So there's no UAL items (in theory).
<pitti> xnox: summary is on bug 1400394, and I hope followups go there from now on
<ubottu> bug 1400394 in cgmanager (Ubuntu) "Unity8 fails to start applications, cgmanager is not started under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1400394
<jamespage> pitti, that may indicate something broken in sendfile - looking now
<xnox> jamespage: pitti: one can provide hints / overrides for dh_python there was a text file where to hint what dh_python should do when it sees "foo" requires.
<hallyn> pitti: hm, so was that only done in debian/rule?
<pitti> jamespage: ok; sorry for nagging, just reviewing what's stuck in -proposed
<hallyn> pitti: just remove the --no-enable?
<jamespage> xnox, yeah - I know but I'm pretty sure it should be able to figure out the binary package from the install bits
<pitti> hallyn: "that"?
<hallyn> yeah, having it not run by default
<pitti> hallyn: oh -- yes, that should suffice, hang on
<hallyn> yeah i thought ther emight e something in the actual systemd unit file too, but i see nothing
<hallyn> stgraber: ^ is there anything else beside the 3 last patches to help lxcfs which you'd want in a new cgmanager releases?
<pitti> hallyn: yep, that should do
<hallyn> (any features i haven't implemented yet)
<hallyn> jamespage: had any thoughts of merging ipxe from debian? :)
<hallyn> (if not i'll do it, don't want to step on toes)
<jamespage> hallyn, happy for you todo that :-)
<pitti> cyphermox: looking at urfkill -- what was the reason to drop d-bus activation in favor of an upstart job? isn't starting on demand appropriate somehow? (and how doesn't that affect debian then?)
<rbasak> Logan_: any objection if I sync haproxy 1.5.10-1 from Debian experimental? Looks like a straightforward upstream bugfix release.
<hallyn> jamespage: on it
<stgraber> hallyn: nope, I think we're good with current git trunk
<stgraber> pitti: cool, thanks!
<hallyn> pitti: are you by chance DD ?
<pitti> stgraber: bonjour !
<pitti> hallyn: yes
<hallyn> pitti: cool, i'll hit you up for sponsoring? :)
<pitti> hallyn: "by chance" .. it's what brought me into this Ubuntu business in the first place :)
<hallyn> pitti: i really need ot pursue dm
<pitti> hallyn: sure!
<hallyn> pitti: i had a feeling  :)  but i've been wrong about that before
<pitti> hallyn: so, toss me a .dsc or a debdiff or a git link, and I can upload it
<pitti> hallyn, stgraber: btw, any immediate idea what breaks overlayfs (for lxc-start-ephemeral) on current 3.18 kernel? I filed bug 1409425
<ubottu> bug 1409425 in lxc (Ubuntu) "lxc-start-ephemeral stops working with kernel 3.18 - overlayfs change?" [High,Confirmed] https://launchpad.net/bugs/1409425
<pitti> I tried to look into the upstream git, and there's a commit that sounded related
<pitti> but we already have that
<pitti> hallyn, stgraber: i. e. my question is -- is current git head working for you? if so, then I'll just wait for the new release :0
<stgraber> pitti: nope, no clear idea as to what's going on here. I'd have to try the daily PPA on a 3.18 system to see what's going on. (Currently running on a 3.13 kernel here as I've been having other problems with 3.16 and 3.18)
<Saviq> tvoss, hey, could we have your opinion on https://bugs.launchpad.net/ubuntu/+source/trust-store/+bug/1384950/comments/7 ?
<ubottu> Launchpad bug 1384950 in mir (Ubuntu RTM) "Trusted prompts need to be part of the lifecycle" [Undecided,In progress]
<tvoss> Saviq, sure, on my list
<hallyn> pitti: i'm on 3.18.0-8-generic #9 with ppa lxc.  overlay clones are working for me
<pitti> hallyn: great! I like retroactive bug fixing :)
<pitti> stgraber: ^ FYI
<cyphermox> pitti: as I recall there was a conflict between the dbus activation and the upstart job; but really xnox and awe knew about the details of this more than I did
<hallyn> pitti: i would've thought the mount fix for overlay was in the archive...  but maybe not
<pitti> hallyn: it is, that's the thing
<hallyn> hm
<pitti> hallyn: maybe it needed something else or there was a followup fix which I missed; I didn't really look very hard
<hallyn> pitti: could you 'lxc-start -n <container> -l trace -o outout' and pastebinit outout?
<cyphermox> pitti: the only thing I could think of right now is that we'd want urfkill to be started as early as possible on touch, earlier even than NM would start it or whatever, since it has to do some device enablement early on
<pitti> hallyn: lxc-start is fine, it's -ephemeral which is broken (overlayfs)
<pitti> hallyn: and l-s-e doesn't seem to have any debug options?
<xnox> cyphermox: yo, sup? use busname in systemd units, don't mix dbus activation and upstart jobs. E.g. look at ofono, $ sudo stop ofono => yet org.ofono remains on the bus.
<xnox> (spawned as a new process if there were any org.ofono clients e.g. d-feet)
<pitti> xnox: I was looking at our urfkill delta, and we install an upstart job instead of using dbus activation, and I was wondering why
<xnox> pitti: let me tell you why.
<pitti> xnox: cyphermox's "early device setup" certainly makes sense, if we need that
<pitti> Debian might not have that use case
<hallyn> pitti: oh, but try 'lxc-clone -s -o container1 -n container2' and then lcx-start -n container2
<pitti> hallyn: how does that use overlayfs?
<cyphermox> pitti: I'm not sure that's a good enough reason not to properly fix urfkill to be started properly by systemd ;)
<hallyn> yes
<pitti> hallyn: cloning and starting works fine
<pitti> oh, -s?
<hallyn> d'oh
<hallyn> pitti: don't bother
<hallyn> stgraber: i was thinking lcx-start-ephemeral used the api more tha nit does.
<hallyn> stgraber: lcx-start-ephemeral needs to be updated the same way the api did, for the new overlayfs options
<xnox> pitti: did urfkilld restore state of things? and thus we wanted it to start earlier. Anyway, it should be systemd unit with busname and WantedBy=multi-user.target or some-such, to stay equivalent.
<xnox> pitti: and my grep of all upstart jobs and initscripts does not reviel any reverse dependencies (e.g. start on started urfkill) or anything like that.
<xnox> cyphermox: pitti: oh I remember why i dropped dbus activation and added upstart job.
<stgraber> hallyn: ah, right
<xnox> cyphermox: pitti: we were at a sprint in malta and the phone testing would not work, because urfkill would start even when not needed during testing.
<cyphermox> not needed during testing?
<xnox> cyphermox: pitti: dropping dbus activation allowed to reliably control execution -> not needed with proper systemd unit / dbus-activation.
<xnox> cyphermox: as in testing would mock urfkill, and the real one should not be present at the time.
<xnox> cyphermox: there was this other guy from phonedations that came to me with a bug about it.
<cyphermox> ah, makes sense
<cyphermox> yeah, Tony
<xnox> old, tall, skinny, scruffy. probably tony.
<hallyn> xnox: hi, any updates on the netcf upload for debian?
<xnox> pitti: is there a way to suspend dbus activation?
<hallyn> (don't know what tz you'r ein and don't want to miss you :)
<xnox> hallyn: bah, did not upload. Can you please drop me an email to xnox @ debian . org, such that I do it when I'm back home?
<xnox> hallyn: mostly +0 UTC ~=
<pitti> xnox: yeah, don't install a .service file
<hallyn> xnox: thanks
<pitti> xnox: so, why would a test not just stop the system urfkill and/or replace its bus name?
<xnox> pitti: well that's what we did.... I mean suspend on temporary basis.
<pitti> xnox: anyway, it's not a problem to port the upstart job, I was just curious why
<xnox> pitti: good point. i mean have .service file, but disable it via /run or some such.
<xnox> pitti: with .service file and systemd-dbus activation one can do $ systemctl disable urfkill and that will suspend that job, even if dbus activation of it is attempted (as far as i can tell)
<xnox> pitti: talk to tony, he might remember where/how "urfkill was getting spuriously activated, when not desired"
<pitti> xnox: right
<xnox> pitti: i have just little bits and pieces to extend in the local-bridge and then our session-upstart-init will be fully decoupled from upstart-pid1 and we can port phone to systemd, atleast for pid1.
<xnox> well, phonedations people can.
<pitti> yay!
<Riddell> didrocks: what's the status of bluez5 in utopic?
<Riddell> didrocks: _Groo_ is packaging bluedevil
<didrocks> Riddell: waiting on some unity-system-settings change
<didrocks> Riddell: then, we'll be good to go, but we need rsalveti and the kernel team to work on the Touch side
<Riddell> didrocks: this new bluedevil only supports bluez5, is there a ppa we should put it in until bluez5 gets in the archive?
<didrocks> Riddell: yes! please use https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions
<didrocks> Riddell: core-devs should have access to it
<didrocks> Riddell: building on all archs
<Riddell> all arches? ppas can do that?
<slangasek> pitti: hi, why did you remove the juju-related systemd workitem from the blueprint?
<pitti> slangasek: it was replaced with a bug link
<slangasek> ok
<didrocks> Riddell: some are devirtualized, yeah
<didrocks> Riddell: it's using the distro builders
<slangasek> pitti: regarding mailing u-d-a, I'm not sure this needs u-d-a as opposed to just u-d
<pitti> slangasek: u-d@ WFM too, but I thought such kinds of announcements would be on-topic
<xnox> slangasek: are phonedations people going to be on the sprint?
<xnox> doko: why do you statically link libpython2.7 into the python interpreter?
<pitti> slangasek: anyway, I think except for a hangout time (which we can put into the pad later) we should be set?
<hallyn> pitti: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.35-1.dsc
<pitti> hallyn: any reason why you didn't just write LP: #1400394 in the changelog to actually close the bug?
<ubottu> Launchpad bug 1400394 in cgmanager (Ubuntu) "Unity8 fails to start applications, cgmanager is not started under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1400394
<pitti> hallyn: can I do that on upload, or will that disrupt some git?
<slangasek> pitti: is this pad the draft for the announcement you're sending?  if so I guess we should set the hangout time first :)
<hallyn> pitti: no git involved.  i just didn't do it bc debian <shrug>
<hallyn> pitti: please go ahead
<pitti> slangasek: no, that's the actual working scratchpad; for the annoucement we shouldn't replicate that IMHO, just saying when and wher it happens
<slangasek> pitti: ok
<slangasek> let me give the pad a quick read this morning (currently otp)
<xnox> pitti: can i haz url plz =)
<pitti> xnox: http://pad.ubuntu.com/systemd-porting-sprint
<mitya57> sil2100, hi, when will you be able to look at appmenu-qt5?
<mitya57> I got submenus working yesterday, that needed some patching on qt side
<mitya57> also I tested it with more real-world applications, worked fine
<pitti> hallyn: uploaded
<sil2100> mitya57: hey! Sorry about that, I was supposed to do that before EOY but I think I got distracted due to the last-year touch image milestone, I promise looking at parts of it today and finalizing it tomorrow
<mitya57> Thank you, no problem, we all were on holidays
<hallyn> pitti: thanks!
<jamespage> pitti, ironic should be sorted now - pysendfile was missing egg-info
<flexiondotorg> I've submitted some merge proposal for livecd-rootfs and ubuntu-cdimage that add support for Ubuntu MATE.
<pitti> jamespage: ah, dh_python looks at that to map the "import" to the python:Depends? I see
<jamespage> pitti, indeed it does
<flexiondotorg> How do I go about "integrating" (for want of a better expression) the Ubuntu MATE seeds?
<flexiondotorg> Is there a package I should create a merge proposal against?
<flexiondotorg> The Ubuntu MATE seeds are here - https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.vivid
<hallyn> jamespage: the kvm-ipxe package was there for p->t transitions, so we can drop it now right?
<hallyn> yeah i think so.  anyway i'll try some upgrades to make sure
<cjwatson> flexiondotorg: Mm, that stuff is not handled very well, needs an archive admin to mirror them on http://people.canonical.com/~ubuntu-archive/seeds/ and point a few things at them.  Will sort that out for you.
<flexiondotorg> cjwatson, Many thanks for helping.
<cjwatson> flexiondotorg: That part is done, should be visible soon.  There are various bits of lp:ubuntu-cdimage that need to be edited to point to the appropriate places.  Grepping for something like ubuntu-gnome is probably a good way to find them.
<xnox> cjwatson: has kylin been fixed in those places?
<cjwatson> I think so
<xnox> cool.
<flexiondotorg> cjwatson, Thanks. I think I've identified all the place ubuntu-mate need to be added. Prepairing a new proposal now.
<flexiondotorg> cjwatson, When I try to resubmit the merge proposal launchpad tells me: This branch is not mergeable into lp:~ubuntu-cdimage/debian-cd/ubuntu.
<cjwatson> flexiondotorg: That's because your branch is in the ubuntu-cdimage project, not in the debian-cd project.
<cjwatson> flexiondotorg: You can move it on https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-cdimage/ubuntu-mate/+edit
<pitti> slangasek: off for the night; if/when you are happy with the pad, perhaps you can send the announcement over your day, otherwise I'll send it tomorrow morning?
<flexiondotorg> cjwatson, Understood.
<flexiondotorg> cjwatson, Thanks for your help. I've resubmitted and it looks sane.
<hallyn> jamespage: pushing a test build of ipxe to ppa:serge-hallyn/virt.  will push to vivid in a few hours
<hallyn> stgraber: did you want me to take a stab at that lxc-start-ephemeral update, or are you doing it?
<stgraber> hallyn: feel free to do it. I'm currently busy getting the lxcfs packaging ready for the archive. Though I'm happy to take care of it once I'm done.
<hallyn> stgraber: ok, doesn't look too bad;  and i see Miklos made the overlay filesystem type 'overlay', so you can check for a 'overlay' (in additoin to or instead of 'overlayfs') entry in /proc/filesystems.
<stgraber> hallyn: right
<hallyn> stgraber: feh, just lost some time bc i was re-using a test container in a bad state
<hallyn> k got something working
<ahoneybun> balloons, I have a machine I can play around with now, how best do I help with testing?
<Unit193> ahoneybun: I'd think the best place to ask would be channel 27, #ubuntu-quality.
<ahoneybun> k thanks Unit193
<staylor_> Curious about the recommended way of handling device trees with custom kernel packaging.  We have a custom package for support various embedded boards for a number of customers, right now we have one package per customer but the kernels themselves are effectively all the same and custom device tree files is the main difference.
<staylor_> So I'm thinking of just removing the *.dtb from the kernel-image-custom package and instead have a number of device-tree-customerA/device-tree-customerB packages.
#ubuntu-devel 2015-01-13
<hallyn> i think i need to change my apt-cacher-ng settings.  i dont' want it pulling new Packages.gz every time, that's gratuitous.
<jtaylor> actually could ubuntu now use debians pdiff method? now that it also works well on high bandwidth connections?
<dupingping> Now In QT4, the font over 48pt, can not be showed with Bold.
<dupingping> How to solve this problem?
<pitti> Good morning
<hallyn> jtaylor: oh, i'll have to read up about that
<darkxst> pitti, hi
<darkxst> does the rules snippet in http://pastebin.com/uxX1WYwy seem reasonable? (common-post-build-arch runs under fakeroot which also breaks tests...)
<pitti> hey darkxst, how are you? looking
<pitti> darkxst: yes, it does; but doesn't the new check-stamp need to be cleaned up, too?
<darkxst> pitti, yes good point
<pitti> jodh: good morning James, how are you?
<pitti> jodh: could you please pull http://people.canonical.com/~pitti/tmp/migration-to-systemd.bundle into the migration-to-systemd branch? it adds a few more packages to the blacklist
<pitti> jodh: also, I just ran it in my account and it got me http://people.canonical.com/~pitti/systemd/packages-to-convert/2015-01-13.txt which looks correct
<pitti> jodh: http://people.canonical.com/~jhunt/systemd/packages-to-convert/2015-01-13.txt is out of date by at least 5 days, so I wonder if there might be some caches in your home dir or something?
<dholbach> good morning
<LocutusOfBorg1> hi dholbach and developerz!
<dholbach> hi LocutusOfBorg1
<jamespage> pitti, any chance you could promote python-oslo-context to main, unblocking neutron in proposed - the MIR is approved.
<pitti> jamespage: avec plaÃ®sir
<pitti> jamespage: done
<jamespage> pitti, thanks!
<pitti> http://people.canonical.com/~pitti/systemd/packages-to-convert/2015-01-13.txt looks a lot better now already!
<mitya57> mdeslaur: will you mind if I merge wget from experimental? (you TIL)
<Mez> What's the best way to go about reporting Security issues nowaday ?
<mitya57> the progress bar bug (debian #768110) is annoying
<ubottu> Debian bug 768110 in wget "wget: strange progress display with certain locale settings" [Important,Fixed] http://bugs.debian.org/768110
<Mez> Is this chat dead?
<mitya57> Mez: when reporting a bug using the normal procedure you will be able to select its type, i.e. "Public Security" or "Private Security"
<mitya57> The normal procedure is "ubuntu-bug PACKAGE" or https://launchpad.net/ubuntu/+source/PACKAGE/+filebug
<Mez> I think the package is xubuntu-desktop though
<mitya57> That is a metapackage, I don't think it can have security issues
<Mez> It can if someone has chosen to include a package that is in beta, as a main security feature, and therefore has caused the system as a whole to be insecure.
<Mez> https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1410195
<ubottu> Error: launchpad bug 1410195 not found
<mitya57> OK, you managed to file it as a private security one :)
<Mez> Ah
<Mez> I should also be subscribing ubuntu security team bugs, right ?
<mitya57> It should be subscribed automatically
<pitti> stgraber: FYI, lxcfs' autopkgtest fails due to a missing lxc-unshare: https://jenkins.qa.ubuntu.com/job/vivid-adt-lxcfs/1/?
<mitya57> sil2100: unity8 built on all three archs: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+sourcepub/4663108/+listing-archive-extra
<sil2100> mitya57: oh yeah! So uitk built thanks to qtpim building + the unity8 fpic fix?
<sil2100> mitya57: thanks :)
<mitya57> vice versa, unity8 needed uitk
<mitya57> I have also merged qtscript & qtwebkit from debian, which will unblock qtdoc and qtwebkit-examples
 * mitya57 retries ubuntu-html5-theme
<mdeslaur> mitya57: go right ahead, thanks
<mitya57> ok, will do later today
<ogra_> pitti, ugh ... ureadahead doesnt work on systemd systems ? is there any equivalent that gets us "burst reading on boot" to not lose the 7 seconds ureadahead gains us oin i.e. the phone on boot (on usual armhf MMC setups the speedup is *very* significant when you enable ureadahead)
<LocutusOfBorg1> pitti, why mosquitto can't be fixed by merging/syncing from debian?
<pitti> ogra_: I replied on the ML
<LocutusOfBorg1> the version in ubuntu is almost useless, too old for being useful, I always grab the source from upstream
<pitti> ogra_: well, ureadahead only has upstart jobs and depends: upstart, so at the moment it gets removed
<pitti> LocutusOfBorg1: I'm sure it can (I have no idea about mosquitto)
<ogra_> pitti, ah, so it isnt a systemd incompatibility (because systemd does something similar to ureadahead) but just lazyness of the porters, ok :)
<pitti> ogra_: yeah, just lack of interest mostly
<ogra_> well, i think it is a requirement for switching the phone to systemd
<LocutusOfBorg1> Logan_, ^^^^^^
<pitti> ogra_: I guess most Ubuntu developers have SSDs today as well, so I guess we share the sentiment :)
<pitti> ogra_: if it makes that much of a difference on touch we need to take that into account of course
<ogra_> unless you know any other way to load the whole set of needed files at once into ram
<pitti> ogra_: it's just useless (and in fact makes things worse) on a desktop SSD
<ogra_> yeah, it is useful on systems with a lot of IO-wait
<ogra_> definitely not on SSDs ... but arm is usually using MMC/SD card
<pitti> ogra_: it's been years since we actually verified ureadahead's impact, but if you did that on a phone recently, it shouldn't be rocket science to port its two upstart jobs and adjusting the dep
<ogra_> not *that* recently ... was about a year ago that i looked into boot speed
<ogra_> but yeah, i'd say 3-7 seconds speed up are typical for slow MMCs
<pitti> ogra_: I added a WI to https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration
<Tribaal> bdmurray: hi, I'm working on the landscape-client SRU. Since we had several weeks of testing looking that the bugs in the SRU are indeed fixed, would ensuring that the -proposed package and our tested ppa package have the same contents allow us to bulk-verify the bugs? I just tested them, and all md5s match (except one file, where the only change is the
<Tribaal> version number).
<ogra_> gracias !
<Tribaal> bdmurray: I'm trying to not have to re-test everything manually a second time because of (basically) a version bump
<pitti> LocutusOfBorg1: so if you have an idea what mosquitto is and how to give it a quick test, then by all means feel free to merge/update it :)
<alexbligh1> In do-release-uprade, what causes packages to be considered 'obsolete'? Symptom I'm trying to understand: User running P has non-Ubuntu package A on the system, which has many dependencies (A1 ... A99). Upgrading P->T via do-release-upgrade ends up saying 'remove obsolete pacakages' (which lists A), and then lists A1.A99 as "Remove (was auto installed)". Does this happen because one of An has a dependency that
<alexbligh1> at one point in the install process can't be satisfied?
<rbasak> alexbligh1: o/
<rbasak> alexbligh1: sorry I've not looked at the apache2 SRU yet. Been a bit swamped. Doing MySQL this week. Hopefully I'll find a gap soon.
<alexbligh1> rbasak, hi there. That would be great. Anything I can do to help?
<maxb> iiuc, obsolete == no longer present in the repositories, for the new release
<alexbligh1> maxb, A+A1..A99 are provided by our own repository, and they are still there (in our own repo).
<rbasak> alexbligh1: no, this is entirely on me. Sorry. Or we could find another apache2 uploader who can review it.
<maxb> But, unless you overrode that, the release upgrader likes to disable third party sources.list entries
<rbasak> alexbligh1: it is (unfortunately) quite an invasive patch. I agree it's necessary, but I think it needs particularly careful attention to minimise regression risk. I just don't want a big pile of Ubuntu apache2 users screaming about a regression :)
<alexbligh1> rbasak, I'm really hoping it will make 14.04.2. If you think you can get to it next week, it's probably easier if you do it as you understand the issue, unless there are any other willing victims^Wvolunteers.
<alexbligh1> rbasak, quite agree.
<alexbligh1> maxb, aha! Is there any obvious way to avoid the release upgrader doing that?
<maxb> There is a config file you can set somewhere in /etc - just be careful that it will cause upgrades to error out if the user has ANY third party sources that don't support the target release
<maxb> http://wiki.samat.org/CheatSheet/Ubuntu
<alexbligh1> maxb, thanks
<LocutusOfBorg1> pitti, I hope somebody will have a look before me, I really would like to fix the virtualbox situation
<jamespage> could someone re-poke the ceph autopkgtest - its timed out waiting for packages to install for i386
<jamespage> ta
<pitti> jamespage: done
<jamespage> pitti, thanks muchly
<pitti> jamespage: FTR, I'm getting all failures and retry those regularly
<didrocks> mterry: hey! if you have some time, I added an easy (I guess) MIR in the queue this morning: bug #1410106
<ubottu> bug 1410106 in jayatana (Ubuntu) "[MIR] java appmenu integration for applications using swing" [Undecided,New] https://launchpad.net/bugs/1410106
<jamespage> pitti, I'll not setup an auto-nag as you have auto-pitti watching things :-)
<pitti> jamespage: at that rate you won't have anything left to do on the sprint :)
<mterry> didrocks, ok
<didrocks> thanks!
<bdmurray> Tribaal: we usually want people to test with the version from -proposed but maybe slangasek or infinity would have a different opinion.
<jamespage> pitti, glance should be ready today as well - coreycb is nearly done
<coreycb> yep, just about there
<flexiondotorg> Trevinho, I'd like to add compiz support to Ubuntu MATE.
<flexiondotorg> Trevinho, We discussed this briefly in the past. I've just read my notes.
<flexiondotorg> Trevinho, Do you think it would be a good idea for me to integrate the MATE change in lp:compiz via a merge proposal?
<Trevinho> flexiondotorg: yes
<Trevinho> flexiondotorg: that would be nice
<flexiondotorg> Trevinho, I'll give it a whirl later tonight and make a PPA package to prove it works.
<flexiondotorg> Trying to "hack" an existing compiz install it simply not working out so well.
<Trevinho> yeah, I agree. It's just better to have things upstream
<tseliot> slangasek: I seem to have missed the expiration email of my core-dev account. Can you reactivate my account, please?
<tseliot> or Riddell ^
<Laney> does anyone know if the sponsoring report automatically updates itself from bzr?
<flexiondotorg> Trevinho, I've done the simple thing first. Basically create profiles and gsettings overrides and export COMPIZ_CONFIG_PROFILE via /etc/X11/Xsettings.d/
<flexiondotorg> TrafficMan, I added compiz-mate package that depends on compiz-gnome and just installs the few MATE related files.
<flexiondotorg> Trevinho, I added compiz-mate package that depends on compiz-gnome and just installs the few MATE related files.
<flexiondotorg> Sorry TrafficMan
<flexiondotorg> However, I've migrate the gnomecompat plugin to matecompat.
<Trevinho> flexiondotorg: looks fine
<flexiondotorg> Trevinho, Your thoughts on adding the matecompat plugin?
<Trevinho> flexiondotorg: as for the etc/X11/Xsettings.d thing we don't use that anyumore in unity, as we use upstart in session
<flexiondotorg> Trevinho, Yeah I found etc/X11/Xsettings.d was used for xubuntu. I've just extended it to catch "mate" too.
<flexiondotorg> Trevinho, is the upstart stuff in lp:compiz or elsewhere?
<Trevinho> flexiondotorg: mh,  it should be in ubuntu-session or something like that
<flexiondotorg> Trevinho, OK I'll see what I can dig up. Although upstart? Should I bother? How much upstart will remain in 15.04?
<infinity> Who runs the host at the other end of seeded-in-ubuntu?  It seems sad.
<bdmurray> xnox: Did you try building ubuntu-release-upgrader with your changes? the test is failing for me
<bdmurray> xnox: I've sorted it out.
<slangasek> tseliot: looks like somebody beat me to fixing it?
<bregma> anyone know why more recent generic x86/amd64 kernels have been built with CONFIG_USB_OTG=y again? Apparently it's still broken...
<bdmurray> slangasek: what is the right place to fix bug 1403982?
<ubottu> bug 1403982 in gnupg (Ubuntu) "mini.iso installer cannot load additional components" [High,Confirmed] https://launchpad.net/bugs/1403982
#ubuntu-devel 2015-01-14
<slangasek> bdmurray: the mini.iso is built from debian-installer source, so probably there; though it's possible the correct fix is "stop building the mini.iso"...
<cjwatson> The bug sounds like a gnupg problem ...
<cjwatson> I mean the netboot mini.isos are genuinely useful and used, and there's no particular reason they shouldn't be able to load additional components
<cjwatson> And this is probably affecting all use of d-i netboot
<cjwatson> Compare https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753985
<ubottu> Debian bug 753985 in gpgv-udeb "gpgv-udeb: fails to validate Release files (missing sha256 support)" [Grave,Fixed]
<cjwatson> Though why is sha512 needed?  Our Release/Packages/Sources files don't use it
<cjwatson> oh, Release.gpg
<cjwatson> publish-distro.d/10-sign-releases:                      printf '%s\n' "-u 437D05B5 -u C0B21F32 --digest-algo SHA512"
<cjwatson> so the attached patch in comment #8 is correct and should be applied
<cjwatson> slangasek: ^-
<cjwatson> probably doesn't affect CDs because we re-sign Release for those, IIRC
<slangasek> cjwatson: oh, alrighty then
<cjwatson> (due to reconstructing Packages)
<slangasek> bdmurray: so turns out gnupg is the right place to fix it :-)
<cjwatson> d-i will need to be rebuilt afterwards, but that happens reasonably often anyway because hi kernel
<bdmurray> slangasek, cjwatson: alright, thanks
<micah> so these pages about how to get software into the software center used to exist, but now they dont and the only thing on developer.ubuntu.com are things related to mobile, where is the non-mobile stuff gone? http://developer.ubuntu.com/publish/apps/other-forms-of-submitting-apps/my-apps-packages/ http://developer.ubuntu.com/2012/02/how-to-prepare-a-compiled-application-for-ubuntu-software-center/ ?
<micah> hm, maybe this isn't the right place for app development questions
<micah> it looks like it was moved, and there were no redirects made for it
<anishparanjpe> I want to find all the modules that ubuntu installed apart from those in the kernel source. Is there a list of those modules?
<pitti> Good morning
<pitti> stgraber: I filed bug 1410666 for tracking this
<ubottu> bug 1410666 in lxcfs (Ubuntu) "lxcfs makes lxc's upstart job hang forever" [High,New] https://launchpad.net/bugs/1410666
<dholbach> good morning
<seb128> hey dholbach
<dholbach> hey seb128
<LocutusOfBorg1> hi developerz!
<flexiondotorg> Trevinho, I've had some success with adding MATE support to lp:compiz ð
<flexiondotorg> Trevinho, I need to tweak the plugin configuration so it is sane for MATE, but it is working.
<flexiondotorg> Trevinho, When I am done should I submit the merge proposal against lp:compiz or is there another repo I should use?
<flexiondotorg> cjwatson, In order to make iso images of Ubuntu MATE using my own scripts I had to create meta packages from my seeds.
<flexiondotorg> cjwatson, I assume that I do not need to make my meta packages available for official builds because tasksel tasks are made from the seeds, correct?
<cjwatson> flexiondotorg: It's usual to put metapackages in the archive too
<flexiondotorg> cjwatson, So if I have meta packages for ubuntu-mate-* those should all go in to the official archive too?
<cjwatson> flexiondotorg: Yes, I would say so
<cjwatson> slangasek: ^- could flexiondotorg have another contact to work with to help merge all the Ubuntu MATE stuff?  I can't promise to be desperately responsive
<flexiondotorg> cjwatson, for package uploads dholbach has been helping me, but again I know he is somewhat busy too.
<dholbach> flexiondotorg, do you need help with anything?
<cjwatson> flexiondotorg: It would be helpful I think if you had somebody who's a specialist in image builds.
<cjwatson> dholbach doesn't have access to all the right pieces ...
<dholbach> ah ok
<flexiondotorg> dholbach, I am going to start preparing my requests for packaing. I'll subscribe ubuntu-sponsors.
<cjwatson> But in any event it needs to not be me, because I'm mostly doing Launchpad now.
<flexiondotorg> cjwatson, dholbach I basically have two areas I'm takling. The build system and getting some packages into the archive.
<flexiondotorg> I think dholbach can help with the later?
<cjwatson> The odd bit of help is fine, but not as a default contact.
<cjwatson> Yes, I expect so.
<flexiondotorg> cjwatson, I have submitted merge proposal to livecd-rootfs and ubuntu-cd that adds Ubuntu MATE support. They are pending.
<flexiondotorg> cjwatson, I'm happy to do the leg work and submit the merge proposals.
<lesshaste> does anyone maintain the bzip2 source code? The official web page has no changes since 2010
<flexiondotorg> cjwatson, Is there anything else I should be modifying for the build Ubuntu MATE images?
<cjwatson> flexiondotorg: Right, which is why I'm asking for my previous manager to give you a contact to get that stuff properly reviewed and merged.
<cjwatson> And to answer that last question.
<flexiondotorg> cjwatson, Understood. Thanks. I'll try and progress with slangasek.
<Trevinho> flexiondotorg: lp:compiz is fine
<flexiondotorg> Trevinho, Thanks.
<pitti> cjwatson, xnox: I'm looking into providing systemd units for ubiquity; do you have a clever technique how to test a locally built ubiquity deb on a live system?
<pitti> like, interrupt the boot early, scp/dpkg -i it or so? or does it require rebuilding the image (expensive)?
<cjwatson> pitti: break=casper-bottom
<cjwatson> then you can fiddle in /root; don't recall whether you have networking (it should be possible but maybe not by default), if it's just text files you can just edit them in manually
<pitti> cjwatson: ah, thanks; I figure I can call dhclient -1 eth0 or so
<cjwatson> Yeah, well you probably don't have dhclient but ipconfig from klibc-utils should be there
<cjwatson> Or you can use stuff from /root with judicious use of LD_LIBRARY_PATH or chroot, which you'll need to do for scp anyway
<pitti> cjwatson: that seems to work: chroot /root, mount -t proc proc /proc, dhclient -1 eth0
<pitti> cheers
<cjwatson> np
<xnox> pitti: whilst above is good, I do following -> boot to desktop, fiddle with files, switch to tty1 -> service lightdm stop, killall -9 X, service lightdm start
<xnox> pitti: note that ubiquity jobs is start on starting lightdm.
<pitti> xnox: ah, that sounds good too
<xnox> pitti: in systemd world, I hope you can boot to live desktop.
<pitti> xnox: right, I'll do the  same
<cjwatson> I can understand wanting to not get into that when bringing up systemd jobs though
<pitti> xnox: yes, that works fine
<cjwatson> I mean you'll definitely want to test behaviour from clean boot too
<pitti> xnox: just the "directly to installer" mode obviously doesn't work, that's the one I want to create
<xnox> pitti: from there start ubiquity job and it should do things. Imho, ubiquity should be highjacking default dm, cause that's what it is.
<xnox> pitti: in general ubiquity job should pre-empt normal one, given the conditions on the kernel command line.
<pitti> xnox: yeah, either it registers itself as "the" dm (display-manager.service) or it does like in the upstart world and starts itself before display-manager.service
<pitti> I factorized the startup logic into scripts/start-ubiquity-dm and share that from the .upstart and the .service
<xnox> pitti: probably before is best, cause "on exit, normal dm should start and autologin"
<cjwatson> ConditionKernelCommandLine should make things much nicer
<pitti> anyway, I'll put up an MP for critisizing once I'm done
<xnox> is the current expected behaviour
<pitti> xnox: right
<xnox> pitti: https://wiki.ubuntu.com/DesktopCDOptions you might find it useful. "automatic-ubiquity only-ubiquity maybe-ubiquity debug-ubiquity" should run ubiquyity
<xnox> pitti: there are also kernel options for oem-config as well.
<xnox> (that needs porting as well)
<pitti> xnox: yes, I'm aware of the oem-config bits, but one at a time :)
<shadeslayer> Could someone advise me of a way to throw away changes to a file system after it's unmounted?
<pitti> shadeslayer: overlayfs/aufs?
<shadeslayer> pitti: I was using that, but that keeps the the changes in the upper dir
<shadeslayer> use case : I need to expose files on a host to a schroot, and any changes inside the schroot should be thrown away
<shadeslayer> +after the schroot is closed
<pitti> shadeslayer: with a tmpfs as the upper dir and lazily unmounting upper dir afterwards might work?
<pitti> shadeslayer: sounds like you are reimplementing schroot :)
<shadeslayer> heh
<shadeslayer> I'm using this at the moment : /var/lib/jenkins/workspace/ /var/lib/jenkins/workspace/ overlayfs rw,lowerdir=/var/lib/jenkins/workspace/,upperdir=/tmp/jenkins 0 0
<pitti> shadeslayer: so, I don't know exactly how schroot does that, but it's by and large that -- r/o lowerdir, tmpfs (or dir) upperdir, and unmounts everything if you close the schroot
<cjwatson> schroot uses some unionfs (aufs, overlayfs, unionfs depending on config) with a throwaway overlay
<cjwatson> if schroot isn't throwing away the changes then you just need to adjust its config
<cjwatson> I would just tell the fstab in the relevant schroot profile to bind-mount the relevant directory, and then schroot's own overlay handling should take care of the rest
<cjwatson> hm, actually that's not quite right is it
<cjwatson> I think your problem is that /etc/schroot/setup.d/10mount comes after 05union
<cjwatson> which is normally right, but you need to get in beforehand
<cjwatson> so unless there's some way to do it with the standard setup.d scripts that I missed, I'd add another setup.d script before 05union that does the bind-mount you need
<cjwatson> maybe 04mount_early with a fstab-early config file in the profile
<cjwatson> but read through the existing setup.d scripts first to see what you can do already
<pitti> meh, scp doesn't work in casper -- netcat FTW
<shadeslayer> cjwatson: hm, I'll have a look
<willpearson> Hi, we are having a problem with USN-2469-1 on Ubuntu 12.04 LTS causing a problem with graphite.
<willpearson> The change to serving the static content isn't working for us.
<stgraber> pitti: cool, thanks, I'll upload the fix today
<pitti> stgraber: ah, you know what's wrong?
<pitti> seems the systemd unit also needs some love (see first comment on the bug)
<stgraber> pitti: yeah, needs to be changed to "starting lxc or cgmanager-ready"
<pitti> stgraber: oh, lxc depends on cgmanager? i. e. dependency loop?
<stgraber> well, started cgmanager is bad to begin with because in a container you'll get cgproxy, not cgmanager, so you need the cgmanager-ready event. Now when you have a "starting" and depend on something else, the "starting" in this case lxc will be held until the other event is emitted (in this case started cgmanager)
<stgraber> as upstart doesn't keep and replay the event history, that basically means hanging until cgmanager restarts and started cgmanager is emitted again
<shadeslayer> stgraber: btw I wanted to setup a unpriv lxc container, tried following the steps here https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-unpriv but I get a error that ~/ doesn't have the 'x' bit set
<shadeslayer> stgraber: are there more proper instructions than that?
<stgraber> shadeslayer: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
<stgraber> that does mention the chmod +x (or setfacl)
<shadeslayer> stgraber: lxc_container: confile.c: network_netdev: 482 network is not created for 'lxc.network.link' = 'lxcbr0' option
<shadeslayer> lxc_container: parse.c: lxc_file_for_each_line: 57 Failed to parse config: lxc.network.link = lxcbr0
<pitti> stgraber: ah, makes sense; I think I ran into this a few years ago, nice gotcha when thinking about states instead of events
<stgraber> shadeslayer: what do you have in ~/.config/lxc/default.conf ?
<shadeslayer> http://paste.ubuntu.com/9748358/
<stgraber> shadeslayer: that first line looks a bit mangled
<shadeslayer> aha indeed
<shadeslayer> stgraber: lxc-start: conf.c: mk_devtmpfs: 1181 Permission denied - Unable to create /dev/.lxc for autodev
<pitti> stgraber: mangled? it's perfect Klingon! :-)
<shadeslayer> xD
<stgraber> shadeslayer: hmm, what's in that container?
<shadeslayer> stgraber: I just downloaded the sid container
<shadeslayer> though trying to run it on a non-systemd utopic machine
<stgraber> shadeslayer: ah, that'd be why, yeah, sadly that won't work until proper systemd support lands
<shadeslayer> aha
<stgraber> we have the patches though so hopefully that'll all land in vivid in the next couple of weeks
<shadeslayer> I assumed the containers on the website worked
<pitti> shadeslayer: install sysvinit-core into it (chroot into its rootfs)?
<stgraber> yeah, that'd be a fair assumption and that's usually quite true, expect that I never got around to blacklisting sid and jessie after they switched to systemd
<shadeslayer> now I get lxc-start: lsm/apparmor.c: mount_feature_enabled: 61 Permission denied - Error mounting securityfs
<shadeslayer> after installing sysvinit-core
<stgraber> shadeslayer: can you try a trusty container just to make sure that lxc itself is happy?
<shadeslayer> checking
<shadeslayer> stgraber: yeah, so it's a debian specific issue
<stgraber> wheezy starts fine, but probably a bit too old for you :)
<shadeslayer> yeah :P
<stgraber> I've added jessie and sid to the blacklist for now so they should vanish from the list pretty soon
<stgraber> and will come back once unpriv systemd support lands
<shadeslayer> ack
<shadeslayer> thanks :)
<stgraber> pitti: so I'm really unsure what's going on with that systemd unit... Does systemd expect the command to background itself or to stay in the foreground?
<stgraber> pitti: I assume the former so that's why I'm not passing the -f flag as I am with upstart, besides that, it's the exact same thing running in either case...
<pitti> stgraber: usually it should stay in the foreground (Type=normal)
<stgraber> ah, so that's probably the problem
<pitti> stgraber: Type=forking is for daemons which fork; some can't be run in the foreground
<pitti> stgraber: it's usually better to let them run in the foreground, to capture their stdout/err, and the extra fork is just unnecessary
<stgraber> pitti: ok, if you're still on systemd with lxcfs installed, can you edit ExecStart and add a -f in there, see if that does the trick?
<stgraber> pitti: yeah, agreed and I always do that with upstart, just wasn't sure that systemd had the same default behavior
<pitti> stgraber: I'm not, but easy enough to bring one up, hang on
<pitti> stgraber: still the same
<stgraber> pitti: and no extra error messages this time?
<pitti> still the same "Failed to start FUSE filesystem for LXC."
<pitti> $ sudo /usr/bin/lxcfs -f -s -o allow_other /var/lib/lxcfs/
<pitti> Failed opening dbus connection: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /sys/fs/cgroup/cgmanager/sock: No such file or directory
<pitti> WARNING: failed to escape to root cgroup
<stgraber> no cgmanager running?
<pitti> stgraber: bug 1400394
<ubottu> bug 1400394 in cgmanager (Ubuntu) "Unity8 fails to start applications, cgmanager is not started under systemd" [Undecided,Fix released] https://launchpad.net/bugs/1400394
<pitti> stgraber: yep, systemctl start cgmanager, then start lxcfs -> runs
<stgraber> pitti: ok, so After=cgmanager.service should become Requires=cgmanager.service then?
<pitti> stgraber: drop the local-fs.target, not needed
<stgraber> pitti: ok
<pitti> stgraber: and then Requires=cgmanager.target\nAfter=cgmanager.target
<stgraber> ah, why .target and not .service? (sorry, still new to this)
<pitti> stgraber: Type=simple is also the default
<pitti> stgraber: err sorry, .service of course
<pitti> stgraber: the local-fs.target was still in my head apparently
<stgraber> :)
<pitti> stgraber: OOI, why KillMode=? isn't the default (control-group) ok?
<pitti> stgraber: I tested this, and confirmed it to work (also after reboot): http://paste.ubuntu.com/9748762/
<pitti> stgraber: before/after is ordering, requires/wants is dependencies, they are both independent (sometimes you only need one or the other)
<stgraber> pitti: so the expected problem with cgroup killing is that lxcfs escapes its cgroup :)
<pitti> stgraber: oha :)
<pitti> stgraber: systemctl stop lxcfs works (no lxcfs process any more), but indeed it did escape its cgroup
<stgraber> does systemd have some kind of fallback then?
<pitti> stgraber: apparently so; I'm not yet familiar with that level of detail
<stgraber> anyway, I think it's better to stick with =process for now :)
<pitti> I learned more than I ever wanted to know about how it sets up cgroups (when I wrote the lxc user support patch), but haven't yet looked at the teardown
<pitti> stgraber: yep, sounds fine
<pitti> stgraber: so my diff is: add -f, drop the default Type= and the unnecessary local-fs.target, add Requires=cgmanager.service
<stgraber> pitti: sounds like what I've got here
<stgraber> pitti: https://github.com/lxc/lxcfs-pkg-ubuntu/commit/67f3a4d7ecc183cb1e798cc0ffc48bdae010d39b
<pitti> stgraber: LGTM, thanks!@
 * pitti eyes at the @, where did that come from
<stgraber> ok, uploaded. Hopefully adt will be happy this time.
<stgraber> pitti: so the latest cgmanager upload is supposed to enable the unit by default, is that not the case in practice?
<pitti> stgraber: it actually is; maybe I still had 0.34, lemme check
<pitti> no, it's 0.35
<pitti>    Loaded: loaded (/lib/systemd/system/cgmanager.service; disabled; vendor preset: enabled)
<pitti> stgraber: oh, I know!
<pitti> stgraber: 0.35 doesn't enable itself during upgrades (hallyn knew about that)
<pitti> stgraber: I figure we need to wait for a cloud image with 0.35 proper; I figure my image just got dist-upgraded from 0.34 to 0.35
<pitti> well, it helped us spot that bug
<stgraber> pitti: ah, I guess that makes sense
<mitya57> ScottK, hi, what's your opinion on https://bugs.launchpad.net/ubuntu/+source/qtenginio-opensource-src/+bug/1409433/comments/3
<ubottu> Launchpad bug 1409433 in qtwebsockets-opensource-src (Ubuntu) "[MIR] qtenginio-opensource-src and qtwebsockets-opensource-src" [Undecided,New]
<pitti> stgraber: "Jenkins Fixed - vivid-adt-lxcfs 4" -- c'est de la musique dans mes oreilles :)
<stgraber> yay!
<mitya57> cjwatson, hi, do you think it will be possible to drop perlqt dependency from debconf? That will allow us to demote a bunch of packages (see mterry's comment on bug 1409433).
<ubottu> bug 1409433 in qtwebsockets-opensource-src (Ubuntu) "[MIR] qtenginio-opensource-src and qtwebsockets-opensource-src" [Undecided,New] https://launchpad.net/bugs/1409433
<cjwatson> mitya57: Probably pretty hard, the B-D is needed to generate the .ui file
<mitya57> cjwatson, can we just use the pre-generated one?
<cjwatson> mitya57: No idea
<mitya57> cjwatson, well, if I write the patch (which will be Ubuntu delta), will you have any objections?
<cjwatson> mitya57: I would expect it to be hard to load the .ui at run-time (one of mterry's suggestions), because debconf has to work when unconfigured
<mterry> cjwatson, as I mention in the bug, the file is just 155 lines.  We could patch it in or maybe even change the code to load the .ui file instead of using a .pm one
<mterry> cjwatson, ok
<cjwatson> I don't hugely object if you patch in the pregenerated file as long as you maintain that patch henceforth
<mterry> cjwatson, but still.   Patching 155 lines to avoid many large packages in main seems worth it.  Do you know roughly how often that .ui file changes?
<cjwatson> No idea
<cjwatson> Check git history
<cjwatson> Build-time changes are safe enough as long as you're actually going to maintain them.  Run-time changes are risky
<mitya57> cjwatson, last change in 2010 (by you)
<mitya57> http://anonscm.debian.org/cgit/debconf/debconf.git/log/Debconf/FrontEnd/Kde/WizardUi.ui
<mterry> And before that, 2009, then 2003
<mterry> mitya57, Seems like a reasonable amount to maintain.  If it changes in future and you're busy, just send me a poke.  I'll gladly take the risk to demote all those packages
<mterry> mitya57, the 2009 and 2010 changes were just removing and adding the frontend back.  The file itself hasn't changed since 2003 it seems
<mterry> Although I guess it was ported to qt4, which probably did have changes
<mterry> But still.  Point is, not a frenzy of updates
<mitya57> I think it will need to be ported to Qt 5 before Stretch
<mitya57> But that will be easy to merge
<shadeslayer> does anyone know if there's a way to make a package upgradable but not uninstallable? ( I'm not sure if such a state exists )
<mitya57> mterry: I will then wait for ScottK's reply (maybe he knows other reasons why qscintilla/pyqt5 need to stay in main), and after that upload a patched debconf
<shadeslayer> I'd prefer not to mark it as essential
<cjwatson> make the prerm fail
<cjwatson> hope you (a) have a good reason (b) don't put it in the primary archive, though
<shadeslayer> heh
<shadeslayer> sounds extremely icky
<PaulW2U> ssh -p 60000 paul@vps.pcw.me.uk
<shadeslayer> chrisccoulson: firefox question for you, if I want to rename the firefox package to say .. magic .. I imagine alot of stuff would break if I  change MOZ_PKG_BASENAME / MOZ_PKG_NAME
<shadeslayer> chrisccoulson: so, what would be the right way to go about this?
<davmor2> cjwatson: to make a perm fail surely you just wash your hair before the magic 48hours is up ;)
<Odd_Bloke> Surely a prerm is a haircut?
<kkirsche> Hey guys does anyone know where I can find the Sign On API for Ubuntu One so I can implement a sign on option using Ubuntu One?
<kkirsche> found it http://canonical-identity-provider.readthedocs.org/en/latest/resources/token.html#token-oauth
<dobey> kkirsche: sign on to what?
<kkirsche> dobey: I want to extend omniauth to allow Ubuntu One as a method of authentication for web apps
<dobey> oh, ok. thought maybe you wanted to use it in a client app on ubuntu :)
<kkirsche> :) nope, sorry. Thanks though
<dobey> anyone smarter regarding the archive/proposed stuff than me, that can tell me what this bit of log actually means? http://pastebin.ubuntu.com/9752159/ slangasek maybe?
<Riddell> anyone able to tell me why the transitions I'm doing for kate4/kate and konsole4/konsole aren't going into the archive? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<Riddell> both apps have moved to qt5 but we want to keep the plugins from the qt4 version around for apps which use them
#ubuntu-devel 2015-01-15
<Riddell> cjwatson: mitya57: we don't even use debconf's perlqt frontend in kubuntu, we use debconf-kde which is a c++ library so I expect it can be dropped
<RAOF> Hm. Who's familiar with the seeds/germinate process? I need to know why mir-client-platform-mesa is being pulled in to the vivid touch image, and how to stop it.
<mdeslaur> ROAF: because it's a reverse-depends of libmirclient8 perhaps?
<RAOF> mdeslaur: It's an alternative rdepends of libmirclient8, yes.
<RAOF> But mir-client-platform-android is explicitly seeded, and satisfies that alternative.
<mdeslaur> RAOF: hrm, not sure then. perhaps infinity would know
<infinity> RAOF: It's almost certainly because of the alternate dep, and could just need a blacklist.
<infinity> RAOF: Germinate's not always bright in the face of alternate deps.
<RAOF> Ah.
<RAOF> Let me see if I can work out how to do that...
<infinity> RAOF: To be fair, situations that call for blacklists usually mean your deps are wrong, but I can see how this is a curious special case, since you want two different defaults.
<RAOF> An alternative would be to *not* depend on a driver module at all for libmirclient8.
<infinity> Which is possibly also correct.
<RAOF> That would probably be reasonable.
<infinity> Unless it needs it to load.
<RAOF> Well... it's not *linked* to the driver module, but it'll fail as soon as you try to do anything with it.
<RAOF> But that's a solution that doesn't require me to try and work out how germinate works again, so... :)
<infinity> RAOF: Decoupling it is probably the right thing anyway.
<infinity> RAOF: Since the android/gnu thing really needs to *stop* being how we define "touch" and "not".
<RAOF> Heh, yes.
<infinity> RAOF: That all needs to be defined in hardware support packs that just drop the right bits in place, and userspace should opprtunistically use the right bits as it discovers them.
<infinity> RAOF: Otherwise, any hope for convergence is a bit of a joke, IMO.
<infinity> RAOF: Or any hope for touch devices with free driver stacks. :P
<RAOF> We've *very nearly* landed the necessary bits in Mir to do that, yes.
<RAOF> (This has been apparent for a while âº)
<lamont> Unpacking python-oslo-config (1:1.6.0-0ubuntu1) ...
<lamont> dpkg: error processing archive /var/cache/apt/archives/python-oslo-config_1%3a1.6.0-0ubuntu1_all.deb (--unpack):
<lamont>  trying to overwrite '/usr/lib/python2.7/dist-packages/oslo/config/cfg.py', which is also in package python-oslo.config 1:1.5.0-0ubuntu1
<lamont> I wonder if that is already known
<infinity> lamont: Sounds like some missing Breaks/Replaces.  Report and/or pester jamespage and/or fix it yourself cause you're still a core-dev? :)
<infinity> lamont: Oh, already reported as LP: #1410727
<ubottu> Launchpad bug 1410727 in oslo-config (Ubuntu) "package python-oslo-config (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/python2.7/dist-packages/oslo/config/cfg.py', which is also in package python-oslo.config 1:1.5.0-0ubuntu1" [High,Confirmed] https://launchpad.net/bugs/1410727
<infinity> jamespage: ^
<pitti> Good morning
<ScottK> mitya57: I don't know.
<pitti> slangasek: any preference for today's EU/US sprint handover hangout?
<slangasek> pitti: preference - do you mean for time?
<pitti> slangasek: oh, nevermind, I just saw the cal entry
<slangasek> my /preference/ is to have it quite a bit later than I actually scheduled it ;)
<pitti> (I didn't get a mail notification for it, weird)
<pitti> slangasek: I have a meeting 17:00 to 18:00 UTC, anything before and the hour after would WFM
<slangasek> pitti: would an hour later work, maybe?
<slangasek> that's more realistic considering I'm still awake
<pitti> slangasek: yes, even two hours
<slangasek> pitti: two hours later runs into other conflicts
<pitti> slangasek: not three hours (as that overlaps with my other meeting), but four works again
<doko_> hangover hangout?
<pitti> did I actually write..
<pitti> no :)
<pitti> doko: today is the handover; tomorrow (at Friday evening) is the hangover :)
<pitti> slangasek: time added to the pad
 * pitti invites jamespage
<pitti> cjwatson, slangasek, xnox: who maintains ubiquity these days? If we work review based, I'd appreciate a look at https://code.launchpad.net/~pitti/ubiquity/systemd/+merge/246535
<pitti> I believe I tested it sufficiently, but more eyes can't hurt
<pitti> slangasek: do you want to tackle bug 1312976 for the sprint? you said you wanted to rearrange the init.d scripts as well, do that in Debian, etc.
<ubottu> bug 1312976 in nfs-utils (Ubuntu) "nfs-utils needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312976
<pitti> slangasek: apparently upstream also has native systemd jobs (I've seen some patches fly by via CC: systemd-devel@), so maybe we can just use those
<pitti> didrocks: ah, having a look at some touch ones?
<pitti> I got some easy ones without android deps this week; for the others we should probably wait for xnox to wake up?
<pitti> well, some of those might still be simple
<didrocks> pitti: I'm currently on the edubuntu one, but I think we should start with the android config one first and try to understand how that exactly works
<didrocks> pitti: it contains a lot of upstart jobs, maybe we should do Touch once all the others are done?
<didrocks> and do a real iterative work on it
<pitti> didrocks: I don't have a good feeling about how much work it is TBH
<pitti> I'm not very familiar with the phone booting
<didrocks> pitti: I think it would be better to directly Do The Right Thing and revisit(Tm)
<didrocks> pitti: but TBH, seeing how close rtm is on rebasing on vivid from what I heard, I doubt they will move to systemd this cycle, still doesn't stop us of doing the work
<didrocks> but my gut feeling is it would be less work to really understand the dependencies and directly optimize it
<didrocks> wdyt?
<pitti> not sure what you mean with DTRT? you mean stop listening to android events?
<pitti> I don't think we can do that anytime soon
<pitti> maybe for special cases like MTP (as I hinted in my reply to xnox), but I haven't investigated that really
<didrocks> pitti: it seems to me that there are a lot of jobs that are just events in the middle or specific for one device
<didrocks> pitti: I'm pretty sure some cruft piled up over time
<pitti> oh, for sure
<dholbach> good morning
<mardy> seb128: hi! Does the session-migration stuff work on Ubuntu touch?
<tseliot> doko: hi, are we going to switch to gcc 5.0 in 15.04?
<didrocks> mardy: it does run, yeah
<pitti> didrocks: please remove from the pad when the package moves to vivid; please keep it as long as it's in -proposed still
<pitti> didrocks: we've had several packages getting stuck
<mardy> didrocks: cool, thanks!
<didrocks> pitti: ok, got it
<didrocks> mardy: yw ;)
<didrocks> mardy: if you have never used it, some hints: http://blog.didrocks.fr/post/Announcing-session-migration-now-in-ubuntu
<didrocks> mardy: or ask me for the dh_migration usage if needed
<mardy> didrocks: IIRC I've used it once, long time ago; but I'll certainly ask, if in doubt :-) thanks :-)
<didrocks> no worry ;)
<seb128> mardy, hey, what didrocks said
<kickinz1> o/
<mardy> seb128, didrocks: LOL, sorry, I just realized that I mixed you guys up -- must be because of your Frenchness ;-)
<didrocks> mardy: sure sure, "all the same" :p
<mardy> ;-)
<LocutusOfBorg1> hi developerz!
<darkxst> pitti, what locale gets used during package build tests? and is it the same on debian?
<pitti> darkxst: C.UTF-8 usually
<pitti> darkxst: and yes, it should be the same everywhere
<darkxst> pitti, tracker tests fail on debian, but not ubuntu
<darkxst> martyn thinks its  sorting issue due to locale's
<pitti> darkxst: oh, wait, during *package build*
<pitti> darkxst: I thought autopkgtest, sorry
<pitti> darkxst: so, should be C for both D and U
<darkxst> pitti, actually I meant autopkgtest
<pitti> darkxst: ah; Debian runs in a simple schroot, Ubuntu in qemu; that might explain it
<darkxst> pitti, I can reproduce the debian failures just running adt tests locally in a debian vm
<mitya57> Riddell, I think I will keep it as it will be less delta than dropping it :)
<mitya57> Oooh, I just realized that libqtgui4-perl is used not only when generating .pm file, but when actually drawing the interface, too.
<cjwatson> infinity: blacklists are not only normally a sign of wrong dependencies, but normally flat-out don't work for what people try to use them for :-)
<cjwatson> pitti: I see xnox is reviewing, so I'll leave it to him.  I don't immediately see anything wrong ...
<pitti> cjwatson: thanks
<xnox> morning =)
<pitti> hey xnox, wie gehts?
<xnox> pitti: sehr gut, danke schon ;-)
<pitti> xnox: ah, while I do see the oem-config debconf page, I can't actually do anything there
<pitti> doesn't react to any keypresses
<pitti> xnox: that might be because its running in an upstart job which get their own PTY as stdin/out/err?
<xnox> pitti: yes.
<xnox> "console output" in upstart speak, in systemd there are Stdin= Stdout= stanzas or some such, no?
<pitti> xnox: there are TTY* options; usually units don't have any tty/pty at all, their stdout/err goes to the journal
<pitti> xnox: I updated the MP
<pitti> (comments, not code yet)
<pitti> xnox: or perhaps under upstart it collides with getty1 somehow?
<pitti> xnox: anyway, I won't put a lot of effort into debugging this under upstart now :)
<xnox> pitti: well, console output means that "/dev/console" is being opened with O_RDWR | O_NOCTTY
<xnox> in upstart.
<xnox> pitti: StandardIntput=tty, StandardOutput=tty for oem-config job? for both oem-config & oem-config-debconf jobs.
<xnox> .... sorry "units". jobs in systemd are state transitions
<pitti> xnox: yep, I'm testing that ATM
<pitti> xnox: sorry, doing three things at once
<pitti> TTYVHangup=yes too, I think
<pitti> and TTYReset=yes also couldn't hurt
<pitti> OK, I have a clean test VM again; my previous try purged oem-config, so using -snapshot now :)
<xnox> pitti: yes, it likes to purge itself.
<pitti> jamespage: do you know if someone is looking at manila?
<jamespage> pitti, noone yet
<jamespage> pitti, I was going to take a look after my meeting finishes
<jamespage> pitti, kickinz1 is looking at maas
<pitti> xnox: hah, now I have a systemd unit which behaves in the exact same way -- I see debconf, but dead keyboard :)
<xnox> pitti: ship it, it's no regression parity =)
<pitti> xnox: I wonder if that's a qemu quirk or so
<pitti> xnox: Bazinga!
<pitti> xnox: ok, all hunky-dory now; I updated the MP
 * pitti goes back to isc-dhcp and its umpteen  jobs
<doko> tseliot, no
<jhenke> hi, are there any plans for updating boost in the v cycle? currently in archive are 1.54 and 1.55, but upstream released 1.57 in november 2014
<tseliot> doko: ok, thanks
<pitti> xnox: do you want to re-review the ubiquity MP, or are you happy with it?
<xnox> pitti: i have not looked at your recent commits.
<xnox> pitti: in general i'm happy with it.
 * pitti is very sure to not have broken upstart mode, so we might just upload it now to ease testing tremendously
<xnox> pitti: do you know how to merge & release ubiquity the right way, or shall I do it?
<pitti> jamespage: yay you
<jamespage> pitti, that was a package in need of some love
<pitti> xnox: well, for merging I'd just push my commits to trunk (looks cleaner than merge IMHO)
<pitti> xnox: as for releasing, is it more than just bzr bd -S? that already does a lot of magic like downloading packages etc.
<xnox> pitti: yes, bzr bd -S should do the right thing.
<pitti> xnox: at least it's now I built my local test debs
<pitti> xnox: that doesn't do the "Automatic update of source packages..." thing, though
<pitti> I suppose there's a script for that?
<xnox> pitti: ./debian/rules update; debcommit; bzr bd -S
<xnox> pitti: bzr bd -S -> does update-local which will bail the build if out of date.
<pitti> xnox: ok, I'll do that
<pitti> xnox: ah, nothing new apparently; well, last update was just a week ago
<xnox> cool.
<pitti> xnox: ack, then I'll upload, and ask some cdimage folks in the afternoon to get us a new live image
<pitti> xnox: thanks
<pitti> xnox: argh, can't push, EPERM -- can you pull from my branch and push, please?
<pitti> (or merge if you prefer)
<cjwatson> I generally use debuild -S rather than bzr bd -S
<cjwatson> which is not to say the latter won't work
<pitti> it's become a habit of mine
<xnox> pitti: i think i can grant you permissions.
<cjwatson> but it saves effectively re-running the d-i update bits
<xnox> cjwatson: i added bzr bd -S magic, because you called me out on having unclean stuff in the ubiquity upload debdiffs =))))))
<xnox> pitti: you have permisssions now.
<xnox> pitti: also spam =)
<pitti> I was afraid of that :)
<xnox> ev: i have successfully passed the batton to pitti.
<xnox> \o/
<xnox> pitti: congrats on being the new maintainer of ubiquity =)
 * pitti runs away screaming -- err, to have some lunch
<cjwatson> xnox: well.  mostly I called you out for not reading the debdiffs before upload :)
<cjwatson> but ok
<jamespage> pitti, re the zentyal packages; i've pinged the upstream developers who are mean't to maintain those packages; basically if they don't want to update, I suggest we remove zentyal from the archive
<jamespage> its not been touched for over two years now so is vastly out-of-date
<pitti> jamespage: ah right, and not in Debian either; no objection to cleaning them up if they don't reply or don't want to indeed
<xnox> jamespage: pitti: zentyal would be broken / dangerous if we switch to systemd by default.
<xnox> for pid 1.
<jamespage> xnox, indeed
<xnox> also would be nice to remove system-config-* bits.
<pitti> oh, that's the "new" name for ebox
<pitti> xnox: dangerous because they are very upstart specific and the web frontend etc. only configures that?
<xnox> pitti: yes.
<xnox> pitti: not sure where the upstream stand at, but they did claim way back when that they will maintain it in ubuntu.
<jamespage> xnox, that's not happened so much
<jamespage> xnox, they have ppu rights for zentyal
<pitti> tseliot: do you have some minutes to help me understand the nvidia-prime upstart job? for bug 1312255
<ubottu> bug 1312255 in nvidia-prime (Ubuntu) "[systemd] nvidia-prime package needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312255
<pitti> tseliot: I'm fine with porting it if you don't have time, but the upstart job looks a bit weird
<pitti> is anyone looking for a really easy upstart â systemd porting to learn about it? ltsp-cluster-{accountmanager,lbagent} are simple
<didrocks> apw: hey, I see you are conmux's upstream, does this package makes sense under systemd or should it be replaced with manually instanced serial-getty?
<apw> didrocks, it does something other that that which getty does, i can add system startups if that is needed
<apw> systemd
<didrocks> apw: I have some spare cycles to do it now, seems quite a nice one with instantiated services. Just wanted to know if you feel it worthed it
<pitti> jamespage, xnox: https://github.com/Zentyal/zentyal seems to be quite active though; it just seems they stopped uploading to Ubuntu; maybe people are supposed to use their own archive now
<didrocks> apw: so, it seems that indeed, it does make sense, so doing it
<didrocks> pitti: FYI ^
<apw> didrocks, ahh, do indeed, but who knows how much use it gets these days
<pitti> apw, didrocks: also see Debian bug 775185
<ubottu> Debian bug 775185 in conmux "conmux: has only upstart job, no upstart dependency" [Normal,Open] http://bugs.debian.org/775185
<didrocks> apw: mind answering on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775185?
<pitti> would make sense to upload it there too
<didrocks> pitti: I'll attach a debdiff to it
<pitti> apw: including a systemd unit upstream would be nice indeed
<rbasak> pitti: we just had a conversation in #ubuntu-server about Zentyal. Conclusion is to remove it from Vivid.
<pitti> hey rbasak
<rbasak> pitti: in favour of their own repository, yes.
<rbasak> pitti: o/
<pitti> rbasak: ack, sounds good; I'll clean them up then
<rbasak> Thanks!
<didrocks> pitti: ah, you referenced the bug in the pad, funny, I was looking at conmux's bug to see if a patch was already attached were I saw we were in sync :)
<pitti> didrocks: yeah, that's a curious case -- must be the only upstart-only package in Debian :)
<pitti> (and undeclared on top of that)
<didrocks> pitti: yeah, we found it! :) the package was in ubuntu first and just uploaded in debian as-is
<didrocks> pitti: that means though, they will have the same postrm and so on issue once switch to systemd on that package as they don't have our patch
<didrocks> (in invoke-rc.d)
<pitti> jamespage, rbasak: zentyal> *flush*
<pitti> ok, I'll grab the ltsp-cluster-* ones now; might just as well get it over with
<jamespage> pitti, rbasak: yes indeed
<jamespage> pitti, I'd flush all of them
<pitti> jamespage: yes, that's what I did (not just those on the pad)
<pitti> $ remove-package -m 'unmaintained in Ubuntu for 2 years, upstream has their own repository' zentyal-ca zentyal-dhcp zentyal-dns zentyal-firewall zentyal-network zentyal-ntp zentyal-objects zentyal-openvpn zentyal-printers zentyal-services zentyal-users zbuildtools zentyal-common zentyal-samba zentyal-squid
<jamespage> pitti, thanks
<pitti> I checked reverse-depends
<didrocks> pitti: do you know if it's possible to start some instances of a template service from another one (rather than running systemctl start fooservice@barinstance)?
<pitti> didrocks: Requires=otherinstance@%I.service ?
<didrocks> pitti: well, the instance name is dynamically generate, though more from a script
<didrocks> pitti: maybe a generator would be the best solution, but I feel that being a little bit overkill for conmux
<pitti> didrocks: uh, a template template?
<pitti> didrocks: how dynamic? you can also create .d dirs in /run/systemd/system/ with the extra Requires, but I suppose that needs some daemon-reload
<didrocks> pitti: basically, there is 'for filename in dir -> start conmux-daemon@filename'
<pitti> didrocks: ah -- well, that does sound like a generator
<didrocks> until now, it was conmux.upstart doing that (after starting the main server)
<didrocks> yeah, ok, let's go for a simple generator then
<tseliot> pitti: what is it that's not clear about nvidia-prime.upstart?
<pitti> didrocks: /bin/dash FTW :)
<didrocks> pitti: not a bin fan in term of perf as it impacts boot time, but well :)
<pitti> didrocks: well, *shrug*, the upstart job was also a script, so not really a regression?
<didrocks> pitti: true :) and so, creating some conmux.d/ -> Requires
<didrocks> on all those instance
<didrocks> sounds sane?
<pitti> tseliot: it seems it only starts start-nvidia-persistenced if prime is *not* supported
<pitti> didrocks: yes
<pitti> didrocks: and TBH, as long as a script uses only builtins and doesn't call grep and other external programs a lot, it should be fine
<didrocks> pitti: yeah, it's really rudimentary
<pitti> one can do a lot with POSIX sh already, and bash is even more powerful :)
<pitti> ok, [ "${haystack%needle*}" != "$haystack" ] isn't exactly easy to read, but much cheaper than a grep
<tseliot> pitti: we can probably get rid of that, as we start and stop nvidia-persistenced with a udev rule /lib/udev/rules.d/71-nvidia.rules in the nvidia packages
<pitti> apw: btw, in https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration you have a WI to merge initramfs-tools; infinity once said he'd also want to do a two-way merge with Debian (but that was already a long time ago)
<pitti> apw: just saying for coordination
<pitti> tseliot: ah, that's much more elegant indeed
<tseliot> pitti: I think I need to take care of this myself, as I need to test it with my systems with hybrid graphics. Sorry it's taking so long, but I've focussed on the drivers (speaking of which, nvidia-graphics-drivers-346 and nvidia-graphics-drivers-346-updates are still in Vivid NEW)
<pitti> tseliot: but I figure that wouldn't provide the same "do that before lightdm" synchronization?
<pitti> tseliot: ok
<pitti> tseliot: actually I wonder if that upstart job is doing what you expect -- it basically doesn't do anything if prime-supported is true
<tseliot> pitti: the do before lightdm is a requirement only for switching between graphics drivers (as X will be off)
<pitti> s/is true/shows something/
<pitti> tseliot: that's what's confuzing me
<tseliot> pitti: yes, maybe I made the upstart job redundant as I now handle a lot of stuff directly in the gpu-manager
<tseliot> this is also why I need to check
<tseliot> (mostly because I don't remember, it's been a while)
<pitti> rbasak, jamespage: do you know what "CPC cloud images" are? https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration mentions that they have some dynamic upstart jobs
<hallyn> pitti: thanks for your help with the versioning - do you mind also sponsoring http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.1.9-2+deb7u1.dsc ?
<pitti> hallyn: will do in a few mins
<pitti> ?quit
<rbasak> pitti: that's utlemming and Odd_Bloke's department. Cloud images, basically.
<pitti> rbasak: ah, so the CPC doesn't mean anything special?
<pitti> hallyn: is debian bug 726127 fixed in testing/unstable? if so, the bug should be closed with an appropriate Version:
<ubottu> Debian bug 726127 in libnetcf1 "libnetcf1: The function ipcalc_netmask in netcf had a bug for any netmask > 24" [Important,Open] http://bugs.debian.org/726127
<Odd_Bloke> rbasak: pitti: Also rcj.
<pitti> utlemming, Odd_Bloke, rcj: does "CPC" cloud image mean anything special? https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration mentions that they create some dynamic upstart jobs
<Odd_Bloke> pitti: We're the Certified Public Cloud team, so it just means the cloud images that we produce.
<pitti> Odd_Bloke: ah, so just http://cloud-images.ubuntu.com/ ?
<pitti> i. e. this affects all cloud images, it's not an upstart job only in some "special" fork of them?
<Odd_Bloke> pitti: I'm not 100% sure; utlemming would be able to answer that question better.
<Odd_Bloke> pitti: But we do build images from the ci.u.c images specifically for some clouds, so we do have forks/derivatives of the images there.
<pitti> halfie: uploaded
<pitti> hallyn: uploaded
<pitti> halfie: sorry, tab error
<pitti> awe_: hey Tony, how are you?
<pitti> awe_: do you want to review https://code.launchpad.net/~pitti/ofono/systemd/+merge/246103 or should I just push/upload this? no-op for upstart, tested with systemd on a desktop
<pitti> didrocks, slangasek, xnox: hangout now, right?
<pitti> jamespage: ^ if you want to join, too
<jamespage> pitti,
<jamespage> ok
<awe_> pitti, just started a mtg ( that I'm leading ), will ping you when I'm done
<xnox> pitti: url?
 * xnox saw no emails.
<pitti> xnox: in the pad
<pitti> xnox: you didn't get an invite?
<hallyn> pitti: yeah, that bug was fixed long ago in unstable.
<xnox> lol, i joined and the hangout froze =)
<slangasek> pitti: did you get the ubiquity review you were looking for?
<xnox> pitti: without the property bridge, touch should boot but without mtp support and the like.
<xnox> lxc-android-boot & lxc-android-config are needed though.
<pitti> slangasek: yes, ubiquity is in vivid  now
<pitti> slangasek: and xnox also told me the secret how to test it in text  mode
<pitti> slangasek: so now, while it's broken in text mode under upstart, it actually works under systemd :)
<slangasek> heh
<pitti> hallyn: ah, can you close the bug then? send to XXX-done with "Version: 1.2.3-4" (first fixed version) in the first line, and then some quick explanation
<hallyn> pitti: ok - i was actualy going to do that first this morning, then realized wheezy might be a problem still :)
<hallyn> pitti: thanks
<pitti> slangasek: so if you could build a new ubuntu desktop live, I'd appreaciate -- I'd like to do the full end to end testing without the crazy casper hacking to install local .debs
<pitti> hallyn: ack, thanks
<slangasek> pitti: I kicked off the build, it should be running now
<awe_> pitti, looks good to me.  One question though...what's the meaning of --nodetach on the ExecStart line?
<awe_> also does "multi-user.target" == desktop?
<xnox> awe_: multi-user.target ~= standard runlevel.
<pitti> awe_: --nodetach is to keep it running in the foreground instead of demonizing
<xnox> (default boot state for server, desktop, phone, cloud)
<pitti> awe_: that's generally preferable under systemd and upstart, as it (1) avoids the unnecessary fork, and more importantly (2) you get the output logged properly, instead of it going to /dev/null
<pitti> awe_: multi-user.target is roughly "runlevel 2"
<pitti> awe_: i. e. it would be started on graphical and text boots after rcS/single user mode (in SysV terms)
<awe_> pitti, ofonod actually does the double fork
<pitti> awe_: unless it's decidedly graphical (like lightdm) or early-boot, it's the most common default target to hook it in
<awe_> which is why the upstart job has "expect fork"
<awe_> ( unless I'm mistaken )
<pitti> awe_: right, I know; but not with --nodetach
<awe_> is there documentation for "--nodetach"?
<pitti> awe_: I think I just did ofonod --help or so
<awe_> hmmm
<pitti> awe_: it was fairly easy to find, so I guess I got it from --help or the manpage
<awe_> sorry, for some reason I thought that was being passed to ExecStart
<awe_> lemme check the ofono src
<pitti> awe_: so, there's two types: Type=simple (the default) just stays in the foreground, and "Type=forking" (equivalent to upstart's "expect fork") for daemonizing ones
<pitti> awe_: yes, it is passed to the program you specify in ExecStart
<pitti> awe_: but with it staying in the foreground it's a lot easier to debug problems (sudo systemctl status ofono will show the recent output -- journal magic)
<awe_> yea... sorry, just never used --nodetach before
<awe_> so... aren't there security implications for not forking into the background?
<pitti> awe_: so, it works just fine by itself and with phonesim (that's already systemd-ified, I uploaded yesterday)
<pitti> awe_: no; forking is really just an old way of starting daemons when we only had SysV init
<pitti> awe_: it's completely obsolete with upstart or systemd
<pitti> awe_: these already do that forking/isolation for you
<awe_> OK, not something I was aware of...  I'll take your word for it, for now.  ;)-
<pitti> awe_: it was the same in upstart -- daemonizing and "expect fork" worked, but you never got a log in /var/log/upstart
<awe_> pitti, reviewed/approved
<pitti> awe_: with --stay-in-the-foreground (for whatever daemon) and without "expect fork", we had /var/log/upstart/<job>.log
<pitti> awe_: ack, thanks
<awe_> pitti, that cause the log output when to syslog, where I expected it to!
<awe_> ;)
<awe_> it's very useful to see ofono's log messages intertwined with NM's messages
<pitti> awe_: you can still do that :)
<awe_> ok
<pitti> awe_: so, I don't mind much if you want to switch to Type=forking and drop the --nodetach
<pitti> this is just how most other stuff behaves these days
<pitti> awe_: so you get the per-unit output separately, or everything in one log, or any filtering of the complete log
<awe_> let's leave it as for now.  We can discuss more when we go to move the phone image to systemd
<pitti> awe_: ack; either way, it's simple enough to flip
<awe_> if possible, I'd like to get rid of the need for the override
<awe_> if possible...
<pitti> awe_: sorry, which override?
<awe_> hey, one other thing.. if you get a chance, we're seeing an issue with phonesim-autostart on vivid: https://bugs.launchpad.net/ubuntu/+source/ofono-phonesim/+bug/1401143
<ubottu> Launchpad bug 1401143 in ofono-phonesim (Ubuntu) "Installing ofono-phonesim-autostart makes the phone unusable" [High,Confirmed]
<xnox> pitti: where is the ofono job?
<Odd_Bloke> So I just ran pull-lp-source and it stomped on an existing directory; is there a backup of the directory it stomped on anywhere?
<awe_> any chance you could take a look
<awe_> pitti, there's an ofono.override installed in touch images
<xnox> pitti: did you add that it should claim the BusName=org.ofono?
<xnox> awe_: don't worry about the touch, i'm working on the ofono override for touch.
<pitti> awe_: ah! yeah, I guess we'll get to that when we review the touch upstart jobs tomorrow
<xnox> pitti: awe_: please please =) i have a patch to the event bridge to make ofono job work on the touch properly.
<awe_> xnox, please keep me in the loop... as mentioned, if possible it'd be great to get rid of the need for an override
<pitti> xnox: no, I didn't; so far it doesn't do socket activation and notification anyway, but  I guess it wouldn't hurt
<xnox> awe_: there is an email on ubuntu-devel with rough plan, tomorrow i'll post working debs for testing. But I don't have phone to test it on, so will ask for remote hands.
<awe_> xnox, ack
<awe_> I"m off this afternoon, but will be around tomorrow to review/test/...
<pitti> awe_: ugh, only happens on krillin, not on mako? explains why I've never seen it :/
<pitti> awe_: I keep this open and have a closer look, and check if there's anything fishy wrt. stopping it
<awe_> yea... if you don't have a krillin, I can do some more debug on my end, but might have to wait till Mon
<awe_> pitti, the one pain in the ass is the upstart watchdog that we added... if the respawn limit gets hit, the phone goes into a hard reboot loop
<awe_> ( which I've suggested we get rid of and put a limit on number of reboots that happen )
<pitti> awe_: ah, was that added only on krillin?
<awe_> no
<awe_> but only vivid, not rtm
<pitti> awe_: but ofonod is running, it's just not through its upstart job
<pitti> ah
<awe_> yea, but somehow upstart gets confused and tries to restart the ofono job
<awe_> and fails repeatedly hitting the respawn limit
<awe_> which then triggers the watchdog to reboot the phone
<awe_> ad infinitum
<xnox> pitti: ofono on the phone should not do dbus activation, this is one of the things i have fixed....
<xnox> pitti: otherwise watchdog has no idea.
<pitti> xnox: ah right, so BusName= is just to determine a more precise "did that service finish starting up"
<awe_> xnox, yea...that was fixed awhile back
<xnox> awe_: in systemd watchdog is builtin, thus you can specify which units to activate on failure, etc.
<awe_> xnox, watchdog is a new thing... to detect system processes that are in a bad state
<awe_> xnox, cool
<xnox> pitti: yeap, if it's on the bus, it's ready to accept connections. Previously we needed fork as the notification when it's ready.
<awe_> anyways, I have to jump on to our stand-up
<awe_> be around tomorrow to discuss more
<awe_> thanks!
<pitti> xnox: works fine, pushed to https://code.launchpad.net/~pitti/ofono/systemd/+merge/246103
<xnox> slangasek: pmcgowan: https://bugs.launchpad.net/juju-core/+bug/1409639/comments/5 *shrug*
<ubottu> Launchpad bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged]
<ericsnow> we (juju core) are working on getting systemd support in place for the dev feature freeze (see https://launchpad.net/bugs/1409639)
<ubottu> Launchpad bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged]
<ericsnow> we would welcome any pointers on gotchas we should be aware of, particularly relative to dynamic script/unit generation
<xnox> ericsnow: use systemd go bindings; don't work to systemctl; use correct location for units.
<xnox> ericsnow: if you are doing boot-time generation of units -> use systemd generator spec (see for example gpt-auto-generator)
<ericsnow> also, we rely on LXC and on cloud-init, and it is unclear from the various resources I've seen what the status is for those (relative to systemd)
<xnox> ericsnow: for any other on-the-fly generated things store them in /run/systemd/system/, activate and enable them.
<xnox> ericsnow: LXC in ubuntu does work i believe, talk to stgraber/hallyn for details.
<xnox> ericsnow: i don't know the status of cloud-init port to systemd, i believe it was done a while back - pmcgowan any comment on cloud-init?
<stgraber> xnox: at the moment LXC works on a systemd host. systemd containers don't work so well in the distro (that's what I'm working on right now)
<xnox> slangasek: is pmcgowan - ubuntu server team manager?
<pmcgowan> xnox, I think you are asking the wrong person
<stgraber> got one more patch to get upstream and then we need to release and get 1.1 in Ubuntu
<xnox> pmcgowan: right.
<stgraber> xnox: gaughen is
<ericsnow> xnox: thanks for the updates
<xnox> gaughen: is cloud-init ported to systemd?
<xnox> pmcgowan: sorry for confusion.
<pmcgowan> np
<xnox> gaughen: https://bugs.launchpad.net/juju-core/+bug/1409639/comments/5
<ubottu> Launchpad bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged]
<pitti> ericsnow: wrt. dynamic: transient units should go into /run/systemd/system/, they will only be valid for the current boot; permanent unpackaged units (I think that's what you are after) into /etc/systemd/system/
<pitti> ericsnow: unless you generate the units automatically based on some configuration file, then you mgiht rather want a generator (which synthesizes them in /run/ based on the config)
<xnox> ericsnow: packaged things will be in /lib/systemd/system -> thus one cannot just check for files, always talk to systemd over the API.
<pitti> ericsnow: (I'm deliberately very high-level here -- happy to dive down if you are interested in either)
<ericsnow> xnox, pitti: how much can we depend on /run/systemd/system/ being the right path on all systems (ubuntu or otherwise)?
<xnox> ericsnow: you should use pkg-config to query the paths, if you want dynamic discovery of the locations.
<pitti> ericsnow: those are standard upstream paths everywhere
<ericsnow> xnox: which go systemd binding are you referring to?
<xnox> ericsnow: but /run/systemd/system is fairly universal.
<pitti> ericsnow: /etc as well; just /lib/systemd/ isn't, but you shouldn't write there anyway (unless through .debs)
<gaughen> smoser, can you answer xnox's question above about cloud-init/systemd
<ericsnow> xnox: (good point on using the bindings, by the way)
<gaughen> xnox, I would think that cloud-init is systemd friendly since we used it for snappy
<gaughen> but I need to pull in the expert.. ahem, smoser
<xnox> ericsnow: the one in the archive, used by coreos & docker, actively maintained - golang-go-systemd-dev https://launchpad.net/ubuntu/+source/golang-go-systemd https://github.com/coreos/go-systemd
<ericsnow> xnox: I'll look into using systemd generator spec
<pitti> ericsnow: high-level: it's a program (or a script) which reads whatever config files you have, and create unit files or links (for additional dependencies) in /run/systemd/system
<xnox> ericsnow: generator spec is ok, but is invoked very early in the boot - before one has network. It's good for static things - e.g. generate .mount units from /etc/fstab to mount things. (that's upstream in the systemd)
<pitti> ericsnow: we use that to generate units for sysv init scripts, or units for network interfaces defined in /etc/network/interfaces -- that's the spirit/use cases for them
<pitti> ericsnow: if OTOH you have a "make install" situation where you install packages and configure them through a charm, creating them statically in /etc/systemd/system/ sounds more appropriate
<staylor_> I'm a little confused by the proper way to package a kernel for sharing, I started off with make-kpkg but it seems the official kernels may be built using the pkg-deb system built into the kernel?
<pitti> xnox, ericsnow: btw, there's nothing inherently wrong with calling systemctl; it might just not be the most comfortable/efficient API
<smoser> reading
<smoser> xnox, um... looking at the changelog *your* name appears wrt cloud-init and systemd :)
<xnox> pitti: it's localised output, instead of static no? (e.g. not like upstart)
 * xnox eye roll
<smoser> xnox, i really suspect there is work to do for cloud-init and systemd. i do not think that it probably behaves exactly as i'd like it to.
<pitti> xnox: yes; as I said, depends on what you want to do; if you just need to call "systemctl enable" or similar, the exit status is just fine
<xnox> smoser: does it boot? i can't remember if i tried that in the end.
<smoser> it does boot. yes. used in snappy.
<pitti> I also run systemd in adt VMs (which are also cloud-init based), just not for the initial run
<xnox> smoser: cool.
<xnox> ericsnow: cloud-init with systemd in ubuntu works fine.
<Odd_Bloke> cjwatson: https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1411310 <-- these are the changes I've had to make to live-build to produce CPC images
<ubottu> Launchpad bug 1411310 in live-build (Ubuntu) "[PATCH] Enable tuning of EXT images produced by lb_binary_rootfs" [Undecided,New]
<smoser> it does work, i'm almost certain there are bugs.
<didrocks> xnox: you can always rely on systemctl show output, not systemctl cat or whatsover (and no localized output for anything in systemctl, but no garantee either that it stays stable apart from some commands like show, is-enableâ¦)
<didrocks> xnox: always be aware that /run/systemd/generator*/ are not bound to boot time, but by daemon-reload time, so if you update/install any package executing that command, it will be entirely cleaned and reloaded, not sure it's what they want if they don't use a generator (seems /etc would be better for them as juju is in some admin role in some way)
<didrocks> ericsnow: FYI ^
<cjwatson> Odd_Bloke: fair enough, but you probably want somebody from foundations :)
<cjwatson> doesn't look too complex
<Odd_Bloke> cjwatson: Ack; is there a process I should be following that isn't "10 PING random Foundations person; 20 SLEEP 12h; 30 GOTO 10"? :p
<cjwatson> Odd_Bloke: 10 ACQUIRE core-dev 20 UPLOAD it yourself
<cjwatson> :-P
<cjwatson> Odd_Bloke: or, more seriously, subscribe ubuntu-sponsors and it should pop onto the sponsorship queue which gets frequent attention
<Odd_Bloke> Done.
<Odd_Bloke> (The latter. :p)
<tseliot> pitti: can you remind me how to switch to systemd in vivid, please?
<tseliot> (or point me to the docs)
<didrocks> tseliot: https://wiki.ubuntu.com/SystemdForUpstartUsers#Switching_init_systems
<pitti> tseliot: https://wiki.ubuntu.com/SystemdForUpstartUsers#Switching_init_systems shows how to do it one-time or permanently
<pitti> ah, thanks didrocks :)
<didrocks> sorry, thought you already EOD ;)
<tseliot> didrocks, pitti: thanks!
<pitti> xnox: I alraedy reviewed the upstart logrotate one ages ago, and I'm afraid the "no classes" one doesn't tell me anything, that needs another upstream
<pitti> xnox: the update-notifier is just dropping the :sys:, is that what's meant by "class"?
<pitti> xnox: either way, that looks fine; do you want to upload that yourself, or want me to sponsor it?
<xnox> pitti: "no class" is a bad name, a better name would "run udev-bridge on the session upstart, in addition to system upstart"
<xnox> pitti: and drop memory usage of loca-bridge -> do not store all upstart jobs classes, as they are not used.
<xnox> pitti: and drop event bridge config file for system init as it makes no sence on the system init (retransmit system init events... to system init)
<pitti> xnox: off for dinner, but can sponsor the update-notifier MP if you can't/don't want to
<tseliot> pitti: does the Requires= section support alternative dependencies, as with ||
<tseliot> ?
<xnox> tseliot: no, but your alternatives (pluginA || pluginB) can both do [Install] WantedBy=the-main-one
<slangasek> right; or you can use Wants instead of Requires
 * xnox looks if there is requiredby.
<tseliot> I'd like to start the service only if either lightdm or gdm has started
<xnox> tseliot: it's better to ask what's your main thing, and what the alternates are.
<xnox> tseliot: then use [Install] WantedBy=graphical.target
<xnox> tseliot: without requires.
<xnox> tseliot: what's the service?
<xnox> pitti: i'll upload things tomorrow.
<tseliot> xnox: it's a service that should replace the nvidia-prime upstart job. All it has to do, is actually unload a module when the login manager (being only lightdm or gdm) is stopped
<tseliot> as per LP: #1312255
<ubottu> Launchpad bug 1312255 in nvidia-prime (Ubuntu) "[systemd] nvidia-prime package needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312255
<xnox> tseliot: note that you can do conditionals based on udev devices, can we construct conditionals for nvidia-prime devices regardless of custom scripts in use?
<xnox> tseliot: in your case you should use things like Wants,Before and display-manager.target
<xnox> tseliot: note that display-manager.target is dynamic and is the "currently configured for use display-manager" without need of encoding "ligtdhm | gdm |...."
<tseliot> xnox: I'm not sure we can. This is only for users of the nvidia binary driver, and it can be a bit of a mess, as the NVIDIA GPU may be disabled (in which case udev wouldn't work)
<tseliot> xnox: is that display-manager.target or display-manager.service?
<xnox> tseliot: target
<tseliot> ok, thanks
<ericsnow> xnox, pitti: thanks for the help; I'll come back if I have any more questions
<xnox> tseliot: it's a generic target, and each $dm.service hooks on to it. Just boot vivid and checkout things with systemctl - critical paths, boot order, dependencies etc.
<tseliot> xnox: would [Install] WantedBy=graphical.target be useless in this case?
<pitti> tseliot: sorry, was cooking dinner
<pitti> tseliot: not directly (as that would be a bit of gambling during boot -- which one do you start?)
<pitti> tseliot: but usually in this case you use Alias= and Requires= that
<pitti> tseliot: in your specific case, Requires=display-manager.service
<pitti> xnox: ^ FYI
<xnox> pitti: however i think nvidia-prime should be started before, rather than together with display-manager.
<pitti> tseliot: ah, then it's better to create a display-manager.service.d/nvidia-prime.conf with an ExecPostStop=rmmod
<pitti> tseliot: seems easier
<tseliot> pitti: np. BTW, I was thinking that, since the upstart job only unloads the module on shutdown, then maybe something like this should do the trick: http://pastebin.ubuntu.com/9756959/
<pitti> xnox: that's Before=display-manager.service
<tseliot> and leave login managers alone, since all we have to do is make sure that the specific module is not loaded on shutdown
<tseliot> or nasty things can happens on some systems
<pitti> tseliot: I'm not 100% sure if the .d/ directories work for "virtual" units (i. e. Alias=)
<pitti> tseliot: would be nice if they did, then this would be super-easy
<pitti> tseliot: failing that, I'll think about something else, but let me try that first
<xnox> tseliot: could you email ubuntu-devel mailing list describing how nvidia prime works and what needs to happen, imperically, not in terms of any init system?
<tseliot> pitti: I stole the WantedBy=multi-user.target line from the wiki page
<xnox> cause i really have no idea how nvidia-prime works, and it's fairly non-typical integration.
<pitti> yeah, and the upstart job looks really the wrong way around
<pitti> if the udev rules DTRT, it can probably just go away?
<tseliot> pitti: udev won't help if the discrete GPU was disabled by ACPI
<pitti> tseliot: but then you wouldn't  have an nvidia card?
<tseliot> xnox: yes, I can do that but it's really just the pre-stop stanza of the upstart job that I need at this point
<pitti> tseliot: http://paste.ubuntu.com/9756999/
<tseliot> pitti: if a system is intel+nvidia, and you disable nvidia, you still have to make sure that nvidia is re-enabled before shutdown (by unloading the bbswitch module)
<pitti> tseliot: this works fine -- after boot I get a /tmp/pwned, so the .d/ trick works fine for virtual units
<tseliot> or the system might not see the nvidia GPU on next boot (at all)
<pitti> tseliot: ah, that's this part, not the start-nvidia-persistenced bit
<pitti> tseliot: in your case you want ExecStopPost=..., I just used that for easier visibility
<tseliot> pitti: yes, we can leave alone the persistenced bit, that is covered by a udev rules (and it's just a leftover in the upstart job)
<pitti> tseliot: so, just ship a static file like that and all should be well
<pitti> ok, time for eating now, bbl
<tseliot> pitti: like the one I put on pastebin, right?
<xnox> tseliot: pitti: i think we want to steal this job https://wiki.archlinux.org/index.php/bumblebee#Enable_NVIDIA_card_during_shutdown
<pitti> tseliot: just not with [Install], as display-amanger.servie already exists
<xnox> tseliot: pitti: on shutdown, without anything else enable nvidia card.
<pitti> tseliot: oh, ExecStopPost=-/bin/rmmod ... (the minus makes failure of that command non-fatal)
<xnox> tseliot: or just use that pattern for anything you want to happen on shutdown, e.g. rmmod.
<tseliot> xnox: oh, nice
<pitti> xnox: that works too, yes
<tseliot> pitti: ok, no "install" then
<pitti> if you only want this to happen when ther's a display manager, my .d solution will do that, but the above will always rmmod
<xnox> see ya'll tomorrow
<pitti> need to run, bbl
<tseliot> xnox, pitti: thanks!
<pitti> tseliot: re; so, either approach should work, it depends on whether this should always happen (also for text mode), or only if there is (or rather was) X.org/lightdm/gdm
<pitti> tseliot: for the .d/ extension you don't need to do anything, for the separate unit like in the wiki you need [Install] and dh_systemd_enable
<tseliot> pitti: if there's no X or login manager of any kind, then I doubt the bbswitch will be loaded (as gpu-manager loads it)
<pitti> tseliot: btw, 'echo ON > /proc/acpi/bbswitch' sounds like pretty much the opposite of rmmod bbswitch?
<tseliot> pitti: I don't echo ON, as I set the module to re-enable the GPU when unloaded anyway
<tseliot> I think my solution is better (vs the echo ON one)
<pitti> tseliot: I was just quoting that from https://wiki.archlinux.org/index.php/bumblebee#Enable_NVIDIA_card_during_shutdown
<tseliot> pitti: yes, I know. It's mostly the same
<pitti> tseliot: rmmod has a tendency to block or cause kernel crashes for some modules, but if it works for that one, ok
<pitti> ack
<pitti> tseliot: thanks
<tseliot> yes, I haven't seen any problems with that
<tseliot> pitti: thanks to you
<pitti> mterry: hey Mike, how are you?
<pitti> mterry: would you have some time to look at the two python MIRs in bug 1407695?
<ubottu> bug 1407695 in xmlsec1 (Ubuntu) "[MIR] python-saml2, python-repoze.who, xmlsec1" [High,New] https://launchpad.net/bugs/1407695
<pitti> /lib/init/init-d-script: 12: /etc/rc2.d/S02whoopsie: -c: not found
<pitti> oh, -ENODIDROCKS
<pitti> slangasek, ericsnow: any remaining questions for me for today?
<ericsnow> pitti: no, thanks
<slangasek> pitti: nope!  thanks :)
<pitti> slangasek: ah, we have a new desktop image; giving that a quick whirl still,
<pitti> jodh: would you mind blacklisting oem-config-debconf and upstart-watchdog in the to-migrate branch?
<hallyn> say, what is it that builds a "*egg-info" file in a python related package?
<hallyn> i'm looking at the libvirt-python source package, but all it has is a rule in the .spec file to rm the files.  nothing about genearting them
<pitti> hallyn: usually setup.py install
<pitti> hallyn: sorry, setup.py build
<pitti> hallyn: i. e. python distutils
<hallyn> pitti: i don't see *distutils* in debian control, and no setup.py install in debian rules...
<pitti> hallyn: distutils is built into python
<pitti> hallyn: is it using pybuild/
<pitti> ?
<hallyn> pitti: so the complaint is that the file is present in trusty but not precise
<hallyn> is tha texpected, i.e. precise package builds didn't do it automatically, trusty's do?
<pitti> hallyn: yep, dh auto-detects teh build system as python and calls ./setup.py
<pitti> hallyn: I suppose precise's package didn't use dh yet, but had all the build steps manually?
<pitti> still a bit odd why that didn't build an .egg-info; or perhaps it just didn't install it?
<hallyn> seems likely
<hallyn> guess i'll try by hand
 * pitti pull-lp-source libvirt-python precise
<pitti> err, doesn't exist there?
<hallyn> right it was included in 'libvirt'
<pitti> hallyn: indeed, libvirt-python was added in trusty
<pitti> ah
<pitti> hallyn: hah, easy -- that used autoconf, not ./setup.py (i. e. python distutils)
<pitti> no distutils, no egg
<hallyn> so is there an easy way to add it manually to the precise package?
<hallyn> it does have include /usr/share/cdbs/1/class/python-distutils.mk
<hallyn> well the bug reporter suggests just manually creating one
<hallyn> maybe i'll just do that
<pitti> slangasek: yay, ubiquity-only+oem mode+systemd end-to-end testing success; and with that, good night :)
<pitti> hallyn: yeah, distutils.mk won't help you as there's no setup.py
<pitti> hallyn: shipping a statically made-up one seems easiest for an SRU, if it's crucial
<slangasek> pitti: thanks, g'night!
<sarnold> hey pitti, late night :) how's the feet?
<pitti> sarnold: much better already, thanks
<sarnold> pitti: nice! glad to hear it
<pitti> sarnold: yeah, quite late, but I'm really happy about the progress
<pitti> maybe tomorrow I won't start at 6 again :)
 * pitti waves good night
<sarnold> :)
<sarnold> nn
<hallyn> pitti: thanks.  (i marked the bug medium, as i don't thin kit's critical;  meaning it doesn't meet SRU threshold;  wlil see if the submitter deems it important enough to reply)
<jdstrand> arges: hey, now that you've been able reproduce the qcow2 corruption bug, would it be ok for me to say, migrate to ext4? I'm ok with staying on saucy qemu for now if it would help with future testing (I don't run untrusted vms)
<bdmurray> zul: is there an SRU bug for this heat upload in the unapproved queue for utopic proposed?
<arges> jdstrand: running with ext4 should be fine. You shouldn't need to use saucy qemu however
<arges> jdstrand: and yea I just reproduced it again with upstream qemu. so i'll hack on that more when I have time
<jdstrand> arges: yeah, I wasn't clear. I meant-- I am on ext3 now. it is my understanding going to ext4 may solve my problems with later qemus
<arges> jdstrand: yes. thats right
<jdstrand> arges: so, I am wondering if I go to ext4 and supported qemu is ok, or if you want me to stay put
<arges> jdstrand: nope please use ext4, i have everything documented to reprodue and fix
<jdstrand> oh nice
 * jdstrand hugs arges :)
<jdstrand> of course, now I need to decide how to get there :)
<jamespage> bdmurray, reject that please - its gone to the wrong place
<jamespage> it should have been for vivid
 * jamespage rejects
<jamespage> rechecks rather
<bdmurray> jamespage: I'm sorry are you double checking?
<Bluefoxicy> Oh that is hilarious.
<Bluefoxicy> Steam does a rm -rf /
<roadmr> stgraber: hello, what's the proper way to add a config item via the lxc python api? I tried container.set_config_item("lxc.mount.entry", blah) then container.save_config() but the config file got borked and the container doesn't start :(
<stgraber> roadmr: set_config_item on lxc.mount.entry will override the existing mount list
<stgraber> roadmr: you probably want append_config_item in that case
<roadmr> stgraber: oh! cool, let me try that then
<roadmr> thanks!
<roadmr> stgraber: \o/ it works!! yay, thanks :D
#ubuntu-devel 2015-01-16
<shadeslayer> anyone have a clue on how to pass a env var into a schroot?
<shadeslayer> ( I'd rather not pollute it with everything by passing -p , and I just want to specify one var for the setup.d scripts )
<darkxst> shadeslayer, just add custom key to schroot conf
<pitti> Good morning
<pitti> slangasek: hey Steve, how are you?
<dholbach> good morning
<pitti> dholbach: ooh, hey Daniel! Alles Gute zum Purzeltag! *hug*
<dholbach> hi pitti
<dholbach> vielen Dank! :)
 * dholbach hugs pitti back
<DrManhattan> I have upgraded my samba to version 4.1.6 but Im still getting the talloc memory leak error. Is there any way I can keep samba password sync to user accounts and get rid of this memory error? no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory
<pitti> xnox: FYI, I updated the pad with instructions how to boot touch (in the emulator) with systemd and how to make adb work
<LocutusOfBorg1> hi folks!
<pitti> hey LocutusOfBorg1, how are you?
<LocutusOfBorg1> fine thanks :)
<xnox> pitti: \o/ awesome
<stevenm> It seems since 11.04 packages like firefox and thunderbird get updates even in LTS released to their latest versions regardless of the fact it introduces new features that may have new bugs (i.e. the updates are not just for security/bug fix reasons like any others) - where can I read about this policy (about the rules for the exception itself) as well as what other packages fall under this rule?
<stevenm> *LTS releases
<ivoks> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<ivoks> iirc, reason was 'mozilla will not allow it to be called firefox/thunderbird if it's a patched version'
<jrwren_> so THAT is why debian ships iceweazel
<mgedmin> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model
<mgedmin> "it's unfeasible to try to do our own stable release branch maintenance as this would require far more resources than we can get at any point in the future"
<didrocks> kirkland: hey, still interested in powernap? I can handle the systemd transition if you don't have time
<kirkland> hey didrocks!  sorry, I had promised pitti I would do it by now, but I haven't gotten to it
<kirkland> been a crazy week
<kirkland> didrocks: that would be great!
<didrocks> kirkland: no worry, doing then ;)
<kirkland> didrocks: :-)  thanks!
<didrocks> yw ;)
<rbasak> Are others seeing many more Hash Sum Mismatches in test builds recently?
<rbasak> On Vivid.
<hallyn> hm, corrupt ext4, cna't create files.
<pitti> hey xnox -- we got unity etc. to work now :)
<xnox> pitti: \o/
<pitti> rbasak: that happens fairly often to me too
<xnox> pitti: i should start pushing patches for testing.
<xnox> or run the emulator myself i guess.
<Laney> rbasak: on Translation_en I was seeing it often enough to disable translations inside the chroots
<rbasak> Laney: yeah - mine seems to be on translations too.
<rbasak> pitti, Laney: would you say the rate has gone up recently? I'm seeing far more than a few weeks ago.
<pitti> rbasak: not subjectively; I've pretty much always got them, and apt-cacher-ng seems to aggravate it
<Laney> I don't really remember a problem before a few weeks ago
 * Laney handwaves
<rbasak> If I hit it many times more then subjectively I think I'll claim that the rate has gone up, supported by Laney's handwaving, and file an RT I think.
<rbasak> There was some careful tuning we did a while ago (a year or two maybe) to try and minimise it happening. Maybe a config was changed that broke this.
<pitti> hallyn, stgraber: OOI, when do you plan the next LXC upload? (wrt. bug 1350947)
<ubottu> bug 1350947 in lxc (Ubuntu) "apparmor: no working rule to allow making a mount private" [High,Fix committed] https://launchpad.net/bugs/1350947
<pitti> jodh: hm, now my http://people.canonical.com/~pitti/systemd/packages-to-convert/2015-01-16.txt suffers from the same problem as your's -- it's behind
<pitti> jodh: maybe that's because this is based on Contents.gz which only gets updated once a week or so?
<shadeslayer> Hey, anyone know why kde-runtime doesn't migrate? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<cjwatson> rbasak: Depending on how fine your tuning was, I suppose it's possible it was exacerbated by the publisher getting in general a bit faster around the start of the year
<cjwatson> (apt-ftparchive source caching)
<cjwatson> pitti: Contents is supposed to update daily, but there's a race that sometimes breaks it, https://bugs.launchpad.net/launchpad/+bug/1384797
<ubottu> Launchpad bug 1384797 in Launchpad itself "Contents generation races with publisher" [Low,Triaged]
<Laney> shadeslayer: because of those test regressions
<pitti> cjwatson: ah, thanks
<shadeslayer> Laney: were marked to be skipped
<shadeslayer> Laney: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/files ( see jriddell
<shadeslayer> darkxst: btw I'm not exactly clear on the documentation regarding those
<shadeslayer> re: env vars in schroot
<rbasak> cjwatson: thanks, I'll keep that in mind. I don't recall the details - but they were to do with what cache expiry headers were issued, and with what timing, so that might have something to do with it. Is the publisher still half-hourly?
<cjwatson> Riddell,shadeslayer: should be force-badtest ("ignore test failure for this package"), not force-skiptest ("ignore all failed tests triggered by this package"), so it was right before r875.
<cjwatson> Riddell: I suggest reverting that
<shadeslayer> cjwatson: Riddell's gone out, mind doing it? I don't think I have permission to do that
<cjwatson> rbasak: The publisher hasn't been half-hourly for quite some time.  It attempts to run every five minutes, provided that another instance isn't already running; runtimes vary depending on how much work it has to do, but on average it manages about three to four runs per hour.
<cjwatson> shadeslayer,Riddell: done
<rbasak> cjwatson: ah. I'll need to think about what I recommended before about cache times. Thanks.
<rbasak> I think what we did before was arrange for the cache to expire at a time when the publisher was unlikely to publish any updates, thus avoiding the race where the proxy cache sees a half updated state (that breaks apt) and caches it.
<rbasak> If the publisher runs as soon as it can, then there isn't any window like that any more.
<cjwatson> That's correct, there isn't.
<rbasak> I don't see any easy way to work around it now then. Only to make the repository format actually race-free during updates.
<smoser> hey. this is something new to me. i fresh installed vivid in december some time, and now something on my desktop is eating 'alt-2' and 'alt-[0-9]' keys. previously i'd use those to interact with qemu-system-x86_64 (both -curses and X). neither are getting key input now.
<smoser> also  i notice that shell isn't getting them. in a gnome-terminal window (normally it'd show 'arg 1' or something if you hit that)
<pitti> xnox: interested in joining the systemd meeting?
<xnox> pitti: yes, one sec.
<caribou> is it possible to have a sponsor for Bug #1387594 on trusty & utopic ?
<ubottu> bug 1387594 in libnss-ldap (Ubuntu Utopic) "init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock" [Critical,In progress] https://launchpad.net/bugs/1387594
<rbasak> caribou: looking
<smoser> anyone know how to fix that luser error above ? tried disabling HUD, but that has no affect.
<Laney> smoser: in gnome-terminal, clear the keybindings for 'switch to tab'
<Laney> if you're seeing it outside of the terminal, don't know I'm afraid
<rbasak> caribou: is the patch committed upstream?
<rbasak> and/or released?
<caribou> rbasak: it's been a while, let me check...
<caribou> rbasak: version 265-3 is in Vivid and has the fix
<rbasak> caribou: is that via packaging, or direct from upstream?
<Odd_Bloke> rbasak: I feel like we might be seeing more Hash Sum Mismatches when building vivid images.
<caribou> rbasak: I got it from debian.
<smoser> Laney, thank you.
<caribou> rbasak: I found out talking to bryanquigley that upstream has abandonned development
<rbasak> Odd_Bloke: based on Colin's explanation of how the publisher changed, I now understand and would expect that :-(
<roadmr> stgraber: hello :) I'm using attach_wait and lxc.attach_run_command to run "ls -la /", it's somehow seeing the host's FS, not the containers :( what magic am I missing?
<rbasak> caribou: I see, OK.
<caribou> rbasak: bryanquigley has asked to demote libnss-ldap to Universe
<Odd_Bloke> rbasak: Yeah, just caught up with the rest of the backlog.
<Odd_Bloke> That's what retry loops are for, I guess. :p
<stgraber> rbasak: can you pastebin your code?
<stgraber> s/rbasak/roadmr/
<roadmr> stgraber: sure, just a sec
<rbasak> Odd_Bloke: https://wiki.ubuntu.com/AptByHash was a plan to fix this, if you're interested. I mostly got it working, but never quite finished it.
<rbasak> It might be an idea to resurrect that.
<caribou> rbasak: someone just commented a few minutes ago that he had the problem & worked around by pulling the Vivid pkg
<roadmr> stgraber: here: http://paste.ubuntu.com/9762095/ the problem happens with the provision_container method, right now it's just the dummy ls -la /
<rbasak> caribou: so what I don't like about this is that the patch seems a bit invasive in an area where if there's a regression, it'll be in multithreading code that'll be non-deterministic and thus difficult to test.
<rbasak> caribou: OTOH, it's broken on ppc64el at the moment? That means we need to fix it.
<rbasak> Having an active upstream that had committed the code would give me more confidence that the patch is good (since they're more familiar with the code and will have reviewed it)
<rbasak> But Debian have committed it, so that's better than nothing.
<caribou> rbasak: yes, it's in jessie
<caribou> rbasak: and I pulled the patch w/o any change
<stgraber> roadmr: container.attach_wait(lxc.attach_run_command, command)
<roadmr> stgraber: ah doh :)
<stgraber> roadmr: otherwise, you're passing the result of lxc.attach_run_command(command) to attach_wait() :)
<stgraber> roadmr: that's a reasonably common mistake ;)
<rbasak> caribou: I think we have no choice but to push it to Trusty (and Utopic), but we should let the SRU team decide at that stage. IMHO, my concern should be noted in "Regression Potential", so I'll do that now.
<caribou> rbasak: ok, thanks
<roadmr> stgraber: thanks for your help (and politeness, it's my fault for not reading the examples carefully...)
<rbasak> caribou: a couple of minor review notes. 264-2.2ubuntu4.14.04.01 is identical to 264-2.2ubuntu4.14.04.1, so probably a little less confusing to others to use the latter.
<rbasak> caribou: I'd also note in the changelog that this fixes a segfault on ppc64el and on any rebuilds on other architectures.
<caribou> rbasak: true
<rbasak> caribou: I'll make those changes now and test and upload if you're happy?
<caribou> rbasak: more than happy !
 * rbasak gets to it
<caribou> rbasak: thank you for your help & valuable comments
<xnox> ?
<shadeslayer> cjwatson: thx :)
<ericsnow> for juju, the template for the upstart job is located at https://github.com/juju/juju/blob/master/service/upstart/upstart.go#L228
<ericsnow> we would do something similar for systemd
<didrocks> kirkland: uploaded! once you get time, do you mind pulling lp:~didrocks/powernap/systemdification and pushing to lp:powernap? I don't have commit access it seems, I assume you do :)
<pitti> ericsnow: ah, thanks
<pitti> ericsnow: that doesn't look too bad indeed
<pitti> didrocks, xnox: ^ we could just put the whole script into /run/somewhere/ and ExecStart= it, and the rest is pretty straightforward
<didrocks> pitti: xnox: indeed, quite simple! I'm happy to do that
<xnox> ericsnow: why juju-template-restart.conf instead of telling cloud-init to shutdown at the end?
<xnox> ericsnow: in the clonetemplate.go
<xnox> ericsnow: then in files.go it references /etc/init
<xnox> ericsnow: not sure why static units are created, instead of using instance jobs.
<ericsnow> xnox: where are those files you are talking about?
<ericsnow> xnox: keep in mind that I haven't spent a lot of time with the upstart code and it predates my time in juju :)
<xnox> e.g. you can have juju-machine@.service in debian and then do $ systemctl enable juju-machine@15.service -> thus making this machine boot / start juju-machine 15 service.
<xnox> ericsnow: state/backups/files.go
<ericsnow> xnox: so I can't say much to rationale
<ericsnow> xnox: k
<xnox> pitti: ericsnow: $ git grep "etc/init" -> shows a lot of places where upstart assumptions are made
<ericsnow> xnox: ah, so having a single unit for juju as a whole and then any other units are set as dependencies?
<ericsnow> xnox: then that single unit would be always installed with juju?
<xnox> ericsnow: not quite.
<xnox> ericsnow: a template is always installed to run e.g. machine $i with juju --machine $i, in the template.
<ericsnow> xnox, pitti: yeah, the upstart assumptions are why our job isn't as easy as it could have been :(
<xnox> systemctl enable juju-machine@10.service -> would then make an instance, substitue 10 instead of $i and have that start by default on boot.
<xnox> anyway.
<xnox> pitti: slangasek: what's our upgrade story? dist-upgrade to vivid will install systemd-sysv?
<xnox> and break all juju deployed machines?
<ericsnow> xnox: that could work, but only one jujud should be running on a host, so I'm not sure what a template buys us
<xnox> ericsnow: you have juju-db jujud-machine-* no?
<ericsnow> xnox: I'm pretty sure that's just a hold-over from an earlier version of juju that ran more than one jujud on a host
<xnox> ack
<ericsnow> xnox: however, if I've misunderstood on that point then using a template *would* make sense :)
<ericsnow> xnox: so I'll keep that in mind
<xnox> ericsnow: doesn't --deploy-to machine make an instance multi-machine
<ericsnow> xnox: that just adds more juju agents running in the existing jujud
<pitti> xnox: does one actually dist-upgrade workloads?
<pitti> ericsnow: ^
<pitti> or do you just re-deploy on a new instance?
<pitti> as charms often are release specific anyway
<pitti> if dist-upgrading running instances to newer releases is a supported thing (although it sounds scaringly brittle), I guess we do need to build that "create mathcing systemd unit" into the upgrade story, either via a generator or by calling juju again
<ericsnow> pitti: normal use of juju does not involve sysadmin tasks by users on the instances juju creates
<pitti> ericsnow: i. e. dist-upgrading an instance from say precise to trusty wouldn't be supported anyway
<ericsnow> pitti: my understanding is that once the instance is set up (right after provisioning), we don't do any further upgrades
<pitti> ericsnow: that's my understanding as well; well, certainly -updates/-security, but not a new release
<pitti> xnox: anyway, even though we might not strictly need it, the generator is just a too crazy^Wnice idea to not have it :)
<ericsnow> pitti: right
<ericsnow> pitti: since everything in juju is driven by series
<ericsnow> xnox: FYI, juju *does* have a separate juju running (and a separate init script) for each running juju agent
<ericsnow> xnox: so using a template makes sense
<xnox> ericsnow: yeah.
<ericsnow> xnox: sorry for being confusing :/
<xnox> pitti: ^
<ericsnow> pitti: regarding dist-upgrade, to quote sinzui (on #juju-dev): "Deploy a new service to get the new os, not upgrade an existing one"
<ericsnow> pitti, xnox: are you talking about a juju-specific generator or a more generic upstart->systemd one?
<ericsnow> pitti, xnox: presumably the latter
<pitti> xnox: anything I need to sponsor/review for you?
<pitti> ericsnow: no, a juju specific one
<xnox> ericsnow: i'm talking about /etc/init/juju-*.conf -> /run/systemd/system/juju-*.service specific generator
<xnox> with no future compatibility
<pitti> ericsnow: it can only apply to a concrete template; there's no generic way to translate an upstart job to a systemd unit, as the two are conceptually too far apart
<ericsnow> got it
<ericsnow> pitti: makes sense (too bad)
<xnox> ericsnow: that way juju from this week can launch tomorrows vivid.
<ericsnow> xnox: cool
<xnox> ericsnow: or machines launched with vivid today continue to boot after upgrade to vivid +1 week.
<pitti> xnox: e. g. want me to do the update-notifier merge/upload?
<xnox> pitti: let me do it now.
<ericsnow> xnox: yeah, should be pretty doable given our basic usage with upstart
<xnox> pitti: just got off the call.
<pitti> cyphermox: file moving resulting in broken permisions> ugh
<xnox> ericsnow: imho that is safer. However I will include a safe-guard -> if juju itself generate .service files nothing will be done.
<pitti> cyphermox: that also explains why the manual workaround works
<cyphermox> pitti: hey ;)
<pitti> cyphermox: i. e. rm/cp
<cyphermox> yeah
<cyphermox> if you rm first, then move, it's fine
<pitti> cyphermox: oh, it's moving over an existing file which does that?
<cyphermox> if you move back your backup file onto the old position, the backup filename becomes the invalid char device ;)
<cyphermox> pitti: er, I'm not sure what you mean by that
<cyphermox> from what I can tell it's moving a file from the underlying read-only FS that triggers this
<cyphermox> ie. mv /vmlinuz /vmlinuz.backup  -> pain
<cyphermox> mv /vmlinuz.backup /vmlinuz -> vmlinuz is fine, but now vmlinuz.backup is your invalid char device :)
<tarpman> cyphermox: sounds like bug 1410480
<pitti> cyphermox: I mean "mv a b" is fine if b doesn't exist, but if b does exist it causes that bug? or did I misunderstand this?
<ubottu> bug 1410480 in linux (Ubuntu) "overlayfs v1: renaming existing file uses chardev whiteout (should be symlink)" [High,In progress] https://launchpad.net/bugs/1410480
<pitti> cyphermox: ah, ok
<cyphermox> tarpman: thanks
<cyphermox> pitti: irrelevant to the existance of b
<xnox> pitti: system() vs fork()/exec() vs popen() -> any preference with invoking systemctl?
<pitti> xnox: oh, plain C, no glib or libpipeline or Qt or libnih or anything?
<pitti> xnox: systemctl what?
<pitti> xnox: if it's just enable, disable, calling symlink() or unlink() might be miles easier :)
<pitti> xnox: i. e. is this a generator you are working on? they shouldn't call a lot of externals if possible, as they run *very* early and are boot time critical
<xnox> pitti: upstart-local-bridge calling "systemctl stop android-container@key=*.target"
<xnox> pitti: libnih only has helpers to watch children, not exec children.
<pitti> xnox: ah, for arbitrary values I think fork/execl is safer; shell injection and stuff
<pitti> execlp() even
<ericsnow> xnox, pitti: so with that juju-specific generator, keep in mind that juju currently makes explicit calls to initctl
<ericsnow> xnox, pitti: does that matter?
<pitti> ericsnow: yes, they'll fail
<pitti> ericsnow: that should become calls to "service" to start/stop stuff
<pitti> (which works with sysvinit, upstart, and systemd)
<ericsnow> pitti: so would that unit generator still buy us much?
<pitti> ericsnow: no, I guess not then
<ericsnow> pitti: :(
<pitti> ericsnow: yeah, was a nice idea :/ but trying to emulate initctl would go too far :)
<ericsnow> :)
<xnox> ericsnow: use "service" command that works on debian/ubuntu against upstart & systemd
<xnox> ericsnow: systemctl works against systemd only
<xnox> ericsnow: initctl works against upstart only
<ericsnow> xnox: right, that's one of the things we have to fix for juju 1.23 :)
<xnox> hm waitid is failing for me with no reason.
<pitti> xnox: doing the update-notifier upload now
<xnox> pitti: oh cool.
<xnox> pitti: is there anything special I need to do to run the emulator with systemd?
<pitti> xnox: yes, several things; I put all in the pad
<xnox> pitti: ok...
<tseliot> pitti: apparently my system with nvidia dies (as in nasty backtraces in dmesg) in vivid now. I'll have to investigate this before I can test my changes for systemd. It's probably this: https://devtalk.nvidia.com/default/topic/796559/linux/kernel-3-18-warning-no-drm_driver-set_busid-implementation-provided-by-nvidia_frontend_exit_modu/
<tseliot> which I can't fix unless somebody approves my packages in NEW first
<pitti> tseliot: the two nivida-graphics-drivers-*?
<tseliot> pitti: yep
<pitti> you don't have a local build for them?
<tseliot> pitti: I do, but I think 331 in the archive is broken too
<pitti> xnox: hm, update-notifer FTBFSes due to a test failure
<tseliot> so users are probably left with a black screen now
<pitti> xnox: unrelated to your change
<pitti> xnox: oh, probably because I have an apt proxy
<rsalveti> pitti: any specific testing you want to run with silo 1?
<pitti> rsalveti: not really; just that it still starts up, i. e. guard against compiler oddities etc.
<pitti> rsalveti: it's a no-change for upstart
<pitti> xnox: question in https://code.launchpad.net/~xnox/ubuntu/vivid/upstart/fix-rotate-logs/+merge/246052
<rsalveti> yeah, unless you want to test the systemd part, we can land it
<pitti> rsalveti: I tested a local build of that
<rsalveti> alright, landing then
<pitti> rsalveti: cool, thanks!
<pitti> rsalveti: had to rebuild your's and could add my merge into your landing? or doing that separately?
<rsalveti> pitti: landed mine first, then rebuilt yours
<rsalveti> once we land yours, I got another one but a rebuild should be fine
<pitti> ack, thanks
<pitti> rsalveti: I'm afraid I can't test it myself any more today
<xnox> pitti: i did a fake in fix-rotate-logs.
<xnox> pitti: "normally" - system "rotate-logs" is emitted, event-bridge listens to events, receives it does sprintf(":sys:%s", event_name) and emits again to session init.
<xnox> pitti: here i change event name, verbantim, to ":sys:rotate-logs" and emit direct to every session init. Bypassing system init emit, session-event-bridge, reemit.
<xnox> pitti: i guess it would be more clear to change "start on :sys:rotate-logs" to "start on rotate-logs" in the session job as well.
<pitti> xnox: ah, perhaps I misunderstood the other branch then
<xnox> instead of doing this fakery.
<pitti> I thought the prefixes would go away entirely
<xnox> pitti: automatic ones are. for consistency i guess i should drop them everywhere.
<xnox> pitti: let me push something that is obvious.
<pitti> xnox: oh, you mean with just that branch but not the other it would work?
<pitti> xnox: so yeah, I guess I don't know enough how these are plumbed together
<xnox> pitti: user space uses verbantim ":sys:rotate-logs" events, and i've kept that legacy name.
<pitti> xnox: like, what consumes them, whether the consumer needs to be adjusted, and how that relates to the no-classes branch
<xnox> on the session bus.
<xnox> if i emit ":sys:rotate-logs" i don't need to change any consumers of it on the session init.
<pitti> xnox: ah ok, so that MP is correct (if we entirely ignore the other MP for a moment)
<xnox> nor e.g. to logout.
<xnox> pitti: $ sudo initctl foo -> used to emit two events. "foo" (system-level) & ":sys:foo" (session level)
<xnox> sudo initctl emit foo, that is.
<xnox> i've changed to
<xnox> initctl emit :sys:foo
<xnox> thus generating ":sys:foo" (session level)
<xnox> all events are equal
<xnox> pitti: e.g. i guess i can change udev-bridge on the session level to prefix all events with ":sys:" as well thus having no API change on the session level for any existing session  level jobs.
<pitti> xnox: oh, and in debian/upstart-bin.upstart.cron.daily there's a small typo: that the# session Inits
 * xnox things
<pitti> xnox: ah, I guess that would have made the update-notifier one obsolete (but doesn't hurt)
 * pitti -> dinner
<xnox> pitti: faking ":sys:" prefix is better for 3rd party session jobs if there are any.
<xnox> i guess we will have systemd on the session by the next LTS.
<xnox> pitti: http://paste.ubuntu.com/9762971/
<xnox> pitti: i think this is more clear.
<xnox> pitti: http://paste.ubuntu.com/9762982/
<xnox> with the grammar fix
<tseliot> pitti: I *think* my changes to nvidia-prime worked
<tseliot> pitti: http://paste.ubuntu.com/9763020/
<tseliot> pitti: sorry, too much detail: http://paste.ubuntu.com/9763024/
 * tseliot ended up re-using the systemd unit from the wiki
<LocutusOfBorg1> have a nice weekend people!
<pitti> tseliot: http://paste.ubuntu.com/9763024/ LGTM, thanks! (you don't need the dirs.in bit, though -- dh_install creates dirs as needed)
<pitti> rsalveti: thanks for the landing
<rsalveti> np
<tseliot> pitti: oh, ok, I'll get rid of that entry then. Thanks
<arges> infinity: does bug 1407702 look like an installer issue, I'm not sure the target is correct?
<ubottu> bug 1407702 in linux (Ubuntu) "Console message "could not open builtin file '/lib/modules/3.16.0-28-generic/modules.builtin.bin' " is got while installing Ubuntu15.04" [Undecided,New] https://launchpad.net/bugs/1407702
<infinity> arges: d-i might be an appropriate place to land the bug for now, assuming it's a question of "why are we spewing that to the console at all" (and, honestly, I'm not sure how they're managing that, it should be in syslog).
<arges> infinity: ok i'll re-target it.
<infinity> arges: The actual misbehaviour is going to be a combination of kmod and linux, in that either kmod's being too picky or linux isn't shipping a file, or both.
<infinity> arges: But d-i is a good place to start for now, and Andy and I can argue about the details. :P
<arges> infinity: yea you'd think it would spit out the module it was trying to load. but it says couldn't find the builtin file
<arges> infinity: thank
<arges> s
#ubuntu-devel 2015-01-17
<xnox> can i get a silo for a hand upload of upstart?
<xnox> hm ubuntu-emulator fails to start for me.
<xnox> pitti: heya, upstart is in silo1. Would you please test that phone still boots/works (upstart-local-bridge) under upstart as pid 1?
<xnox> if that is good, then it's ok to land.
<xnox> it also suppose to enable android-container@key=val.target under systemd as pid1. I've tested that on amd64 desktop.... and i believe is beyond me to run the ubuntu-emulator.
<xnox> i get kernel panic of the vivid-emulator on the trusty host here.
<xnox> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-001/+packages
#ubuntu-devel 2015-01-18
<kramsmada> Hi all. I'm a new contributor and I was had a quick question. If I've filed a bug about an issue and created a branch with the fix, what's the best way to get it reviewed by someone?
<jtaylor> kramsmada: kreate a merge request, there should be a link somewhere on the branch page
<jtaylor> kramsmada: alternatively attach the debdiff to the bug and subscribe ubuntu-sponsors
<kramsmada> jtaylor: Thanks!
<kramsmada> jtaylor: So... this should get someone's attention eventually:  https://code.launchpad.net/~kramsmada/ubuntu/vivid/gnupg2/1407513-gpg-agent-set-ssh-env-vars/+merge/245538
#ubuntu-devel 2016-01-18
<GunnarHj> doko: Whatever the reason was for the l-s build failure a few hours ago, it has made it now, so you can disregard my question above.
<hrob> hi
<hrob> I see very old bug reports about ubuntu crashing when creating new master pointer devices...  yet  xinput2 has been around for 5 or more years.
<hrob> I need a little help around Ubuntu's support for Wacom only... and also how Ubuntu has been crashing when creating a second master input device.
<hrob> I'm wondering what I can do to get things going on these two fronts.
<hrob> so, the first issue... there are many competing pen taplet/screen/touch brands out there,  yet the Ubuntu config menu specifically rejects any brand that isn't "Wacom"
<hrob> this is super strange... considering that the other brands. such as  Yiyama  together with  Wacom/Cintiq   use the usb input devices standard.... so... its like an ISO standard here. fully supperted already by xorg xinput
<hrob> yet... the tablet config menu ... not so aptly named "Wacom" ... rejects my non wacom pen device...    xinput does not... it sees it and says hello
<hrob> I've had to go out of my way and develop a more general config app that supports both.... http://wenhsinjen.github.io/ptxconf/
<hrob> it talks with xinput
<hrob> Now,  should I continue on this path... or is it easier just to change the name of the Ubuntu wacom config dialog too... pen and tablet config dialog?
<hrob> hello
<hrobjartur> hello
<hrobjartur>  does anyone know the motivation for Ubuntu ignoring other usb input devices "ISO" compliant devices?
<hrobjartur> Ok so in the ubuntu config panel there is a trademark name "Wacom"
<hrobjartur> I meant
<hrobjartur> instead of saying "pen device/touch device" config it says "wacom" config
<hrobjartur> and the config rejects any input mode absolute pointing device that isn't with manufacturer Wacom.
<hrobjartur> not good code re-usability there -- should I develop my own xinput configurator ?    seems pointless, unless Wacom is sponsoring Ubuntu not to reject other pen devices
<hrobjartur> *to reject
 * tsimonq2 is gone: 
<amigaguru> hi
 * amigaguru greets everybody politely
<amigaguru> @all: you heard of Amiga?
<udevbot> Error: "all:" is not a valid command.
<amigaguru> lol
<pitti> Good morning
<pitti> hallyn: thanks for the patch, will look at it right now
<lpotter> my first computer was an amiga 500
<amigaguru> my too
<amigaguru> err sorry. my first computer was a Dragon 32
<pitti> hallyn: hm, this doesn't yet seem to suffice in my tests
<pitti> hallyn: and the original code looks right (the non-inverted condition)
<pitti> hallyn: hah, got it
<hallyn> pitti: you fixed my broken patch? :)  +1  (though my patch *did* work fo rme for libvirt, but i assumed it couldn't be so simple)
<pitti> hallyn: wow, I actually don't see how it could have worked
<pitti> hallyn: xenial fix uploaded and bug updated.
<pitti> hallyn: sorry, I didn't realize the double calling of dh_s_s on Friday night..
 * pitti preps the wily SRU
<smb> more libvirt fun... note to myself to check for cdbs in other pkgs too
<hallyn> pitti: oh - yeah.  i had noticed the two stanzas
<amigaguru> exibel
<hallyn> pitti: thanks!
 * hallyn -> bed
<pitti> hallyn: good night!
<ginggs> pitti: morning!  [08:43:45] <tumbleweed> d!oko: cffi got caught up in your python3.4-dropping. packages are building without 3.4 in proposed, but the adt tests are expecting 3.4, because they're using the old -defaults
<jamespage> pitti, good morning - I was chatting with stgraber last week about the correct way to detect whether something is running in-container or not - for upstart/14.04 we have /run/container_type - is the same applicable for 16.04?
<pitti> ginggs: ack, re-running with p3-defaults from -proposed
<xnox> Odd_Bloke, http://www.redmine.org/issues/5880#change-68618 =)
<pitti> jamespage: no, that's upstart specific
<pitti> jamespage: please use systemd-detect-virt --container
<Laney> not running-in-container?
<pitti> that's also an ubuntu-ism
<pitti> and systemd-detect-virt works under sysv and upstart too
<Laney> hah
<Laney> interesting name
<ginggs> pitti: thanks!
<Laney> ginggs: hey, do you know if https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/d/dbus-test-runner/20160115_172614@/log.gz is caused by the new pcre3?
<ginggs> Laney: it could be, that was run against the old pcre3.  can we try run it against the new pcre3?
<Laney> hmm this is perl itself
<Laney> yeah it's probably the perl update
<Laney> nm
<ancaemanuel> jdstrand: https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923 for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apt please ?
<ubottu> Launchpad bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New]
<ancaemanuel> or anybody else ?
<alkisg> Hi, https://launchpad.net/ubuntu/+source/adobe-flashplugin/+changelog says "NPAPI: 11.2.202.559" yet the flash player about site says 11.2.202.554, and firefox complains that flash is out of date
<alkisg> chrisccoulson: would that be a bad installation on my behalf, or is it possible that the last adobe-flashplugin has the wrong NPAPI version installed?
 * alkisg checks more...
<alkisg> Hmm no sorry, my version 1:20151208.1-0ubuntu1 is too old even though I've dist-upgraded, checking what went wrong with the updates.
<alkisg> Nope that's the latest version for 16.04
<alkisg> chrisccoulson: as far as I can see, adobe-flashplugin 1:20151228.1-0ubuntu1 claims to have NPAPI: 11.2.202.559 but has .554
<ricotz> alkisg, are you using -proposed?
<alkisg> No
<ricotz> "1:20151228.1-0ubuntu1 	proposed (partner) 	2015-12-28" claims to be still in the partner-proposed pocket
<teward> which i just said in #ubuntu+1 where this ended crossposted
<alkisg> Hmmm let me investigate how I ended up with that adobe-flashplugin version, without having -proposed, and with the wrong flash inside it
<alkisg> I'll look at apt logs
<alkisg> OK bad eyes. The version numbers are different, 1208 vs 1228.
<alkisg> It's been in proposed for 20 days though, and no versions show up in the partner repository... is there something blocking it?
 * alkisg enabled the partner-proposed repository and everything is good again, thank you guys...
<doko> xnox, do you keep a list of s390x porting stuff?
<xnox> doko, elaborate? there is a report of things that have never built on s390x yet (in launchpad that is)
<xnox> doko, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/primary-xenial-s390x-release.html
<xnox> doko, i am working on those things. But e.g. from main i ahve only opencryptoki (in progress) and openvswitch to get done. I'm ignoring the rest of main packages, as they are desktop only. and then universe.
<xnox> doko, is there something in particular you are after?
<doko> xnox, well I thought instead of fiddling around with mpich, maybe better port openmpi
<xnox> doko, .... haha =) it's listed as unported in like fedora and suse. so i guess nobody cares to port it =)
<doko> should be a handful of assembler lines and using the GCC atomics
<xnox> doko, on my list of priorities it's all the way down with the "build freepascal cross compiler, to bootstrap freepascal on arm64 and ppc64el" =)
<xnox> doko, hm, sounds interesting. it would be nice indeed to have openmpi.
<doko> xnox, fpc is done for arm64, and works on the trunk on ppc64el
<Laney> doko doesn't mess around when it comes to pascal
<doko> Laney, well, I tried to backport the trunk fpc to 3.0 for ppc64el, but then lost interest
<Laney> you monster
<cjwatson> fpc is done?  oh, experimental only
<doko> yep
 * xnox knows how to derail a conversation
<teward> heh
<ogra_> are there actually still people that use pascal (beyond for academic and teaching purposes) ?
<xnox> ogra_, as far as i can tell dephi and/or kylix are dead as far as I can tell, and i guess that's the end of objective pascal....
<ogra_> yeah
<rbasak> I hear about legacy projects that are still maintained from time to time.
<ancaemanuel> @Michael Hudson-Doyle: \o/ https://lists.ubuntu.com/archives/xenial-changes/2016-January/005020.html GO go !
<udevbot> Error: "Michael" is not a valid command.
<ancaemanuel> ^ Updates for s390x support, for golang \o/
<ancaemanuel> that means juju people have some work to do...
<cjwatson> doko: OK, will do
<cjwatson> err, echan
<ancaemanuel> freepascal is more important than apt ?!?
<cjwatson> ancaemanuel: huh?
<ancaemanuel> https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923 for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apt please ?
<ubottu> Launchpad bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New]
<cjwatson> I don't know how on earth you get from there to "more important than apt"
<cjwatson> there is not a single linear to-do list for all developers
<ancaemanuel> I sent the same message several hours ago
<ancaemanuel> no answer
<cjwatson> ancaemanuel: and the person it's assigned to is likely asleep right now
<cjwatson> the world is inconveniently spheroid
<cjwatson> it makes more sense to wait for them to wake up in order to find out how far along they are, rather than potentially duplicating work
<ancaemanuel> ok, thanks
<LocutusOfBorg> good morning ubuntu developers
 * LocutusOfBorg for a very strange meaning of "morning"
<LocutusOfBorg> I did upload libsdl2_2.0.4 on debian experimental, and I would like to know your opinion about a sync
<LocutusOfBorg> it changed API/ABI, but upstream convinced us that the changes are still ABI safe (and if something segfaults, it's because they are using the library in a wrong way)
<LocutusOfBorg> so I didn't bump soname
<LocutusOfBorg> https://lists.alioth.debian.org/pipermail/pkg-sdl-maintainers/2016-January/thread.html
<LocutusOfBorg> the rationale is there ^^^
<LocutusOfBorg> how do you feel about a sync from experimental or unstable (I plan to test reverse dependencies a week or two and then go for unstable)
<LocutusOfBorg> s/sync/merge
 * ogra_ guesses you should ask the same in #ubuntu-mir 
<sil2100> pitti, cjwatson: hey guys! Do you remember how the translations work for the overlay PPA? We're using ubuntu-rtm/15.04 for the translations there, but we were wondering if uploads to the overlay PPA are scanned, or is there some assumption that we land the same thing to the development series?
<sil2100> pitti, cjwatson: e.g. is an upload to overlay-ppa only enough for launchpad to do its work?
<cjwatson> sil2100: uploads to the overlay PPA have their translations magically redirected to the ubuntu-rtm/15.04 series
<sil2100> seb128: ^
<cjwatson> uploads to vivid in that PPA, anyway
<sil2100> seb128: so it's as I thought, some workaround is done
<sil2100> cjwatson: thanks
<seb128> ok, I don't know why it's not working then
<cjwatson> see https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/rosetta_translations.py
<seb128> cjwatson, the template from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5961354/+listing-archive-extra wasn't imported
<seb128> but now I manually uploaded it so that might have changed the state to be able to debug
<seb128> cjwatson, should those import show on e.g https://translations.launchpad.net/ubuntu-rtm/15.04/+source/trust-store/+imports ?
<cjwatson> seb128: That upload doesn't appear to have built a _translations.tar.gz, so nothing to import
<cjwatson> seb128: see the build logs
<seb128> cjwatson, hum, right ... do you know why? pkgstriptranslations is used and the package is in main
<seb128> pitti, ^
<cjwatson> seb128: because it's a build in a non-virtual PPA, so tries to behave like the primary archive, and that package is in universe in the primary archive for vivid.  Adding X-Ubuntu-Use-Langpack: yes to debian/control would fix it
<seb128> cjwatson, oh ok, I looked at the package for xenial, thanks!
<cjwatson> np.  took me way too long to spot that :)
<seb128> well at least you did figure it out ;-)
<Laney> doko: any chance you could look at why http://autopkgtest.ubuntu.com/packages/u/ubuntu-sso-client/xenial/i386/ started failing?
<Laney> the package itself didn't change
<Laney> pitti: ...and do you know anything about udisks2/ppc64el or upstart? :)
 * Laney goes to lunch it up
<pitti> seb128: looking
<seb128> pitti, unping
<pitti> sorry, I ignored IRC while handling moving files in essential packages, that needed some attention :)
<seb128> pitti, the package was in universe in vivid
<seb128> Colin figured it out
<pitti> seb128: oh, good
<pitti> Laney: TBH I even have trouble finding the failed test in upstart log
<pitti> not ok 26 - with single-line script that is killed
<pitti> wrong value for WIFSIGNALED (status), expected TRUE got FALSE
<pitti> at tests/test_job_process.c:1760 (test_start).
<pitti> ah, here we are
<pitti> Laney: no clue, but it started failing before glib, so I'm fine with badtesting it
<ricotz> hi, as a reminder https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/1532799
<ubottu> Launchpad bug 1532799 in gettext (Ubuntu) "[Merge] gettext 0.19.7-2 from debian unstable" [Wishlist,New]
<pitti> Laney: so the dbus-test-runner regression "Unescaped left brace in regex is deprecated", that's prce, not glib, right?
<cjwatson> that's a new warning from perl 5.22
<cjwatson> https://bugs.launchpad.net/intltool/+bug/1490906
<ubottu> Launchpad bug 1490906 in intltool "intltool-update spits warnings with Perl 5.22 (which might be wrongly used by callers)" [Undecided,New]
<pitti> ah right; still, not glib, so I'm force-skiptesting, the rest looks unrelated
<cjwatson> dobey might be able to look at that perhaps?
<ricotz> the mentioned gettext update also includes a perl 5.22 fix for texi2html
<ancaemanuel> @piti, how is possible to run for more than 24 hours on armhf on autopkgtest for apache2 ?
<udevbot> Error: "piti," is not a valid command.
<ancaemanuel> unnoticed ?
<ancaemanuel> piti: ? ^
<cjwatson> people's highlights usually work better if you spell their nicks correctly :)
<cjwatson> tab-completion helps
<pitti> ancaemanuel: that's an lxc bug in xenial, I killed them earlier today
<pitti> and fixed adt-run to properly time out on a hanging lxc-stop
<ancaemanuel> oh,
<ancaemanuel> this one: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=9008c6f285bcfa6c4f8f6cf172497116042307db ?
<pitti> ancaemanuel: right
<ancaemanuel> thanks, pitti, waching now http://autopkgtest.ubuntu.com/running.shtml
<ancaemanuel> pitti, is there anything to speed up apt ( see messages above )
<pitti> ancaemanuel: apt isn't even running ATM?
<pitti> ancaemanuel: but I speed it up as much as possible -- I disable translations, foreign arches, set dpkg unsafe IO and run through eatmydata
<ancaemanuel> it needs lz4
<cjwatson> pitti: ancaemanuel is talking about https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923, which requires somebody in ~ubuntu-mir to handle it
<ubottu> Launchpad bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New]
<ancaemanuel> in main
<cjwatson> i.e. neither you nor I :)
<pitti> ancaemanuel: ah, you mean https://launchpad.net/ubuntu/+source/apt/1.2 doesn't build
<pitti> (nothing to do with tests)
<pitti> ancaemanuel: right, needs MIR team
<ancaemanuel> https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923 for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apt please ?
<ubottu> Launchpad bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New]
<ancaemanuel> I repeated this the #3 time now
<Odd_Bloke> !regression-alert
<ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<cjwatson> yes, and you still haven't waited long enough for the person it's assigned to to be clearly within their working hours
<cjwatson> patience!
<Odd_Bloke> https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1535349
<ubottu> Launchpad bug 1535349 in coreutils (Ubuntu) "`df /dev/sda1` no longer reports information for /dev/sda1" [Undecided,New]
<Odd_Bloke> Oh, that's an exciting list of people to ping.
<cjwatson> Odd_Bloke: it's been in trusty-updates for a month, so I shouldn't think that blacklisting it from the archive is appropriate at this point
<cjwatson> chiluk prepared the upload and mterry/cyphermox sponsored it, so perhaps they can look
 * mterry looks up
<Odd_Bloke> cjwatson: Yeah, agreed.  (The SRU wiki page doesn't make it clear what will happen when you do !regression-alert; I would probably have been a bit more chill if I'd realised it would ping all the people ^_^)
<mterry> chiluk, ^
<cyphermox> indeed that's very broken
<mterry> Odd_Bloke, ok, assigned bug to chiluk and opened a trusty task
<Odd_Bloke> mterry: Great, thanks. :)
<Laney> pitti: I handled the regex one already
<Laney> just those three I pinged about
<Laney> I mean sure we could badtest things, but ...
<ogra_> pitti, do you have an idea whyx systemd always grabs the last option from the kernel commandline and appends it to init ?
<ogra_> i.e.:     1 ?        Ss     2:32 /lib/systemd/systemd fixrtc
<pitti> ogra_: not off the back of my hand, but supposedly to do something like "single", like the old runlevels?
<ogra_> (it doesnt do harm indeed, but its like an itch i cant scratch :P )
<Laney> like obviously something changed to break ubuntu-sso-client build
<Laney> I was happy to take the pain until we find out what that is
<pitti> hallyn: with schroot I now get tons of "call to remove-on-empty (freezer:0) failed: invalid request"; is that due to the new libpam-cgm cgroup?
<ginggs> where do i report a gcc internal compiler error? package ncbi-tools6, only happens in arm64 build, package built fine in debian
<xnox> pitti, can you retrigger golang-github-gorilla-handlers autopkgtest with golang as a trigger?
<xnox> pitti, or is there a way for me to do that?
<pitti> xnox: with both gorilla and golang; done
<pitti> xnox: no, not at the moment
<pitti> xnox: only folks with snakefruit access
<mdeslaur> infinity: I've filed bug 1535379 to get refpolicy removed from xenial. What team do I need to subscribe to that bug?
<ubottu> bug 1535379 in refpolicy (Ubuntu) "Please remove refpolicy" [Undecided,New] https://launchpad.net/bugs/1535379
<rbasak> mdeslaur: ~ubuntu-archive usually, or should this be an exception?
<mdeslaur> rbasak: ok, thanks
<chiluk> Odd_Bloke, cjwatson, mterry re: coreutils bug, I'll take a look tomorrow.  Xenial appears to have the correct behavior so hopefully the diff is not too great. I'll take a closer look tomorrow when I'm fully back from holiday
<Odd_Bloke> chiluk: Thanks!
<tumbleweed> pitti: didn't seem to have any effect on s390x. (python-cffi)
<hallyn> pitti: it is - it's fixed in the new (ubuntu4) version;  did that not pass proosed yet?
<hallyn> pitti: no, it got promoted - can you check if you still get it with the upgrade?
<tkamppeter> Anyone around who can help me on a buildds problem? https://launchpad.net/ubuntu/+source/cups/2.1.2-2 It says that cups-filters (> 1.0.38~) is not going to be installed.
<cjwatson> tkamppeter: root cause is that liblouisutdml needs an MIR
<mjeanson> cking: I'm using zfsutils-linux on xenial, the package "Replaces" and "Conflicts" with zfs but does not "Provides" so I can't install packages that depends on zfs, would it be possible to add it?
<cking> mjeanson, sure, please file a bug so I can track this and I'll get around to it this week
<mjeanson> cking: thanks, here you go : https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1535428
<ubottu> Launchpad bug 1535428 in zfs-linux (Ubuntu) "Missing "Provides: zfs" on zfsutils-linux" [Undecided,New]
<cking> mjeanson, thanks!
<allizom> which repository should patent-encumbered FLOSS software not officially supported by the Ubuntu team be packaged into? universe or multiverse?
<Pharaoh_Atem> allizom: multiverse
<allizom> thanks Pharaoh_Atem, why x264, lame and other software are in universe then?
<Pharaoh_Atem> allizom: because universe technically maps to debian's main repos, while multiverse maps to nonfree and contrib
<Pharaoh_Atem> universe and multiverse are filled out by importing from the corresponding debian repos
<allizom> I understand, that was not so clear in the user documentation
<allizom> so when a given software is not packaged in debian, but has the aforementioned properties, it goes in multiverse
<allizom> but when it is in debian main, i'd say en exception is granted and it goes in universe
<allizom> did I understand it the correctway?
<ScottK> allizom: No.
<ScottK> The patent policy is a bit complicated.
<ScottK> It mostly depends on how active enforcement of the patents is.
<ScottK> If no one is actively suing over patents, the policy is to ignore them (as it's impossible to write any non-trivial piece of software that doesn't at least in theory infringe some patent)
<allizom> ScottK: hmm... can you show me an example? for instance why avidemux is in multiverse while other video editing software are in universe? or another one if you prefer
<tumbleweed> allizom: probably because it came from debian-multimedia.org
<ScottK> Not really.
<Pharaoh_Atem> allizom: it'd be dangerous to give an example
<ScottK> https://wiki.ubuntu.com/PatentPolicy
<allizom> tumbleweed: what does "came from" mean in this context?
<Pharaoh_Atem> because then that means someone knows, and then it's willful infringement
<Pharaoh_Atem> allizom: as it is, Canonical is walking on a tightrope here, so...
<allizom> Pharaoh_Atem: I believed the user is the one tasked with obtaining applicable patent licenses, the software itself can be distributed without issues, or am I wrong?
<pitti> hallyn: ah cool, thank you!
<pitti> hallyn, stgraber: out of interest -- will you deprecate the user lxc mode in favor of lxd at some point in the future, or continue to support all three modes (sys lxc, user lxc, lxd)?
<pitti> AFAIUI lxd is the privilege level of user lxc, but shared amongst all users
<Pharaoh_Atem> allizom: wrong
<Pharaoh_Atem> completely wrong
<stgraber> no plan on deprecating anything though the lxc-* tools will be moving to a new lxc-legacy binary package (lxc will in turn become a meta-package installing lxc-legacy for now)
<Pharaoh_Atem> allizom: it depends on the jurisdiction, really
<hallyn> pitti: no, lxd is more like libvirt - users who may use lxd on the host areno longer unprivileged
<Pharaoh_Atem> software patents are super-murky
<stgraber> note that you can also run LXD itself as an unprivileged user, not all features work then though
<pitti> stgraber: ah, so the "lxd" group more or less just gives you containers that are shared amongst users, but the same privileges in the container?
<Pharaoh_Atem> allizom: if it was quite that simple, Fedora would be shipping that stuff
<Pharaoh_Atem> and while Ubuntu doesn't have Fedora's policy, Canonical isn't US-based
<allizom> Pharaoh_Atem: of course a distribution bears a risk of getting sued, I understand
<allizom> Fedora policy is more straightforward in this regard, the Ubuntu one is not clear cut
<allizom> but is this why a package gets put in universe rather than in multiverse? or is it the software license?
<allizom> from what i read, free software = universe, nonfree = multiverse
<allizom> no mention as to the patents
<ari-tczew> is it true, that debhelper since 9.20160114 uses autotools-dev as default? does it mean, if we got that revision, adding autotools-dev to d/rules and B-D to d/control will be not needed anymore?
<Pharaoh_Atem> Debian and Ubuntu's policies on this are... confusing
<Pharaoh_Atem> allizom: it's a bit inconsistent from what I can tell
<allizom> Pharaoh_Atem: that's why I got confused in the first place and asked here :)
<Pharaoh_Atem> Mageia's policy is that patent encumbered stuff goes into nonfree
<Pharaoh_Atem> Fedora's policy is that it doesn't go into the distribution at all
<Pharaoh_Atem> Debian's policy is... ???
<allizom> Pharaoh_Atem: it goes in main if it is free software, even as it is patent-encumbered
<tumbleweed> Pharaoh_Atem: https://www.debian.org/legal/patent
<ginggs> Pharaoh_Atem: https://wiki.debian.org/SourcesList#Component
<allizom> tumbleweed: interesting
<tumbleweed> "patent encumbered" isn't clear-cut. I think it's safe to assume that there are patents covering every piece of software in the archive, because many many stupid, unenforceable patents are granted. So, there's some value in not wasting time on the problem
<rbasak> Also there's a jurisdiction problem. "Patent encumbered" in which jurisdiction?
<rbasak> And who decides whether a patent applies to a particular piece of software, given that a court could end up deciding something different?
 * tumbleweed prefers the jurisdictions that don't recognise patents :)
<rbasak> Also, mere examination for patent encumbrance risks triple damanges in some jurisdictions.
<rbasak> (if you decide differently from what a court later decides)
<rbasak> http://www.ubuntu.com/legal/ubuntu-advantage/assurance is relevant here. You always carry a risk regardless of what distro you use. For Ubuntu, Canonical will take the risk away (for a fee).
<allizom> debian policy seems to reject software that is 'encumbered' by patents, without explaining for instance whether a royalty-free licensing and not-to-sue assertions are considered 'encumbering'
<tumbleweed> debian wouldn't consider royalty-free licencing an option
<tkamppeter> cjwatson, found out that I had forgotten to "git push" the separation of the Braille stuff, will appear with cups-filters 1.7.0-1.
<tumbleweed> DFSG #8
<tkamppeter> cjwatson, but thanks anyway for the hint.
<allizom> tumbleweed: that just says it cannot be debian-specific
<allizom> I have a feel we are being quite ot now though
<allizom> if it is royalty-free for all, then it should be good
<tumbleweed> sure
<tumbleweed> and in that situation nobody will sue, so there's no problem anyway
<allizom> thank you tumbleweed and the others, that's enough discussing this issue for me, even though the only conclusion that I can draw wrt my original question is: the reasoning behind why to put X in universe or multiverse is inconsistent
<allizom> as far as some freely licensed software that *may* infringe on some patents goes
<Pharaoh_Atem> allizom: Red Hat does something similar to Canonical for RHEL, too: https://www.redhat.com/en/about/open-source-assurance
<Pharaoh_Atem> royalty-free does not imply freely usable
<Pharaoh_Atem> as the key is that it has to be usable, redistributable, and modifiable
<Pharaoh_Atem> that's a hard requirement
<allizom> Pharaoh_Atem: the code implementing the patented invention has to be free software, so that freedoms would be granted
<allizom> how about modifying a patent?
<Pharaoh_Atem> allizom: not required
<Pharaoh_Atem> and not possible
<Pharaoh_Atem> but the license of the patent must allow for the software implementing it to be freely modifiable
<allizom> of course. what about a license that permits anyone to implement the covered patent royalty-free the way they choose?
<barry> doko: \o/
<ari-tczew> xnox, doko: is there any plan to grab latest cmake soon?
<xnox> ari-tczew, do you need it, or is it a nice-to-have thing?
<ari-tczew> xnox:  I'm having odd trouble with FTBFS, I'm guessing it's cmake related
<xnox> ari-tczew, show me =)
<ari-tczew> xnox: https://launchpadlibrarian.net/234550380/buildlog_ubuntu-xenial-amd64.kraft_0.59-1~ppa01_BUILDING.txt.gz
<ari-tczew> the same package builds fine on Debian
<xnox> ari-tczew, link to ppa? one cannot go from launchpadlibrarian -> build record reliably =)
<ari-tczew> xnox: https://launchpad.net/~ari-tczew/+archive/ubuntu/testing/+build/8867098
<xnox> tah
<ari-tczew> however, the same FTBFS I got on pbuilder locally
<xnox> ari-tczew, the error is with kdelibs5-dev provided cmake module, and the package you are building, have you tried debian's cmake and does it actually make any difference?
<cjwatson> xnox: one actually can for package builds, though it's utterly undocumented and obscure :-)
<xnox> i'd think either ubuntu's or debian's kdelibs5-dev are ahead.
<xnox> cjwatson, i don't want to know... =) is like iterating build-records with API calls?
 * xnox ain't got time for that =))))))
<cjwatson> xnox: find the bit that says PACKAGEBUILD-8867098, then https://launchpad.net/builders/+build/8867098 redirects
<xnox> fun. thanks.
<xnox> kind of like bugs/+bug/ i guess.
<cjwatson> doesn't work for all build types, I've never bothered to work out what's different
#ubuntu-devel 2016-01-19
<xnox> or some such.
<cjwatson> ish.  there isn't really a global build collection, it's rather a cheat
<ari-tczew> xnox: No, I didn't try with cmake from Debian.
<xnox> ari-tczew, or kdelibs5-dev from debian =)
<xnox> ari-tczew, then how do you know we should spend time merging cmake? =) for soemthing in your ppa, rather than in the archive too ;-)
<xnox> i mean getting newer cmake is always good, but takes time reverse-building things.
<ari-tczew> xnox: I didn't say "you should merge cmake", I just asked about my problem and I've got answer from you, that's all.
<xnox> ari-tczew, i shall note that "is there any plan to grab latest cmake soon?" == "can anybody please see what's weird going on with this cmake buildlog?" =))))))))))))))))
 * xnox is being a bit mean. i'm sorry =)
<xnox> it does look like a werid build failure.
<ari-tczew> xnox: Well, maybe my 1st question was not appropriate. I'm trying to catch some merges, but they're failing. So, I'd figure out where is the problem. I guess that you think, you waste time for such question like mine.
<xnox> ari-tczew, no i don't waste time. i try to help.
<xnox> ari-tczew, it's just build-log indicates a miscompat between in-tree cmakefile of the package being built, and cmake module from kdelibs5-dev. as my first guess, i'd assume incompatability of the two (e.g. one is too old / too new for the other)
<xnox> rather than cmake core changes. Sure the error is generated by cmake, but it simply says cannot have two conflicting targets doing diffrent stuff =/
<ari-tczew> xnox: Sorry that my first target was cmake. I don't know everything, that's the reason why I ask more skilled people.
<ari-tczew> You said it's not cmake related, rather kdelibs5-dev, then I'll forward the question to the #kubuntu-devel
<ancaemanuel> jdstrand: ping
<ancaemanuel> what are you doing more important than this https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923 ?
<ubottu> Launchpad bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New]
<pitti> Good morning
<LocutusOfBorg> pretty please, can anybody retry libquazip/marble autopkgtest?
<LocutusOfBorg> I uploaded marble, and the test was successful, I don't understand why it hasn't been automatically retried the one from libquazip too
<pitti> LocutusOfBorg: done
<LocutusOfBorg> thanks :)
<Laney> @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: Laney
<xnox> Laney, may the force be with you
<cyphermox> good morning!
<juliank> Why are there no xenial branches on https://code.launchpad.net/ubuntu/+source/software-properties - and why does checking out the xenial branch give me 0.96.16, while 0.96.17 is in the archive?
<rbasak> juliank: UDD is generally broken. Use pull-lp-source.
<juliank> Ugly
 * juliank has to merge the latest Ubuntu releases into Debian
<rbasak> juliank: https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html
<juliank> Mkay
<juliank> Not sure what I'll do then
<rbasak> Right now I import using pull-lp-source downloads into git using a dsc-committing-tool. Would that help?
<rbasak> It's effectively what UDD did for bzr, but for git, but manually.
<rbasak> Until Launchpad has a new git importer ready.
<juliank> It's just ... work
<juliank> But it seems like the most sensible option of some sort
<LocutusOfBorg> pitti, I see the libquazip marble autopkgtest
<LocutusOfBorg> but why did it take the old one?
<LocutusOfBorg> 4:15.08.2-0ubuntu3  libquazip 0.7.1-1
<LocutusOfBorg> there is an ubuntu4 right now
<LocutusOfBorg> Laney, pretty please if you can look at llvm-* on wily queue :) many people suffers from problems about not being able to build some graphic drivers, because clang is not available there and I fixed the build failure
<pitti> LocutusOfBorg: we do that with all -proposed packages -- we test them in isolation as much as possible
<pitti> LocutusOfBorg: i. e. for verifying if the new libquazip is good, we take its proposed version and run tests against the released versions of rdepends, unless dependencies force the version in -proposed
<LocutusOfBorg> ah ok fine
<LocutusOfBorg> but the -release is broken :)
<LocutusOfBorg> thanks for the explanation
<Laney> LocutusOfBorg: I'm sorry but I'm not in the sru team :(
<pitti> LocutusOfBorg: apparently that fails here, so I'll re-run it against -proposed
<LocutusOfBorg> thanks pitti I wasn't aware of this, otherwise I would have specified it
<LocutusOfBorg> good to know
<LocutusOfBorg> Laney, no problem :)
<Laney> LocutusOfBorg: these people are your friends https://launchpad.net/~ubuntu-sru/+members
<LocutusOfBorg> Laney, I'm doing a libgksu merge, do you want to have a look? you are the last uploader :)
<Laney> You should ask the last uploader before doing the work
<Laney> but in this case it was just a rebuild so I would have said to go ahead
<LocutusOfBorg> oh I'm not going to upload anything :)
<LocutusOfBorg> I'm going to open a bug
<LocutusOfBorg> with a patch
<LocutusOfBorg> just I don't know if robert is on irc
<pitti> WTF just happened to prodstack
<pitti> LocutusOfBorg: ok, I will re-run it as soon as the infra comes back to live
<LocutusOfBorg> thanks a lot!
<LocutusOfBorg> it is the first transition I try to make it finish :)
<LocutusOfBorg> the first ubuntu transition ;)
<mdeslaur> @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: mdeslaur, Laney
<doko> tumbleweed, given back three times ... https://launchpad.net/ubuntu/+source/pyzmq/15.1.0-1build1
<Mirv> thank you mdeslaur
<mdeslaur> Mirv: np! thanks for spotting that
<Laney> zyga: hey, could you maybe subscibe the checkbox-dev team to pyotherside bugs?
<Laney> zyga: MIR team usually likes to see someone subscribed to main package bugs and that seems to be the team for checkbox itself
<Laney> seems this MIR is blocking builds of Ubuntu desktop images atm
<spineau> Laney: hello (I'm the one who filed the pyotherside MIR bug)
<spineau> Laney: I subscribed https://launchpad.net/~checkbox-bugs for this package
<spineau> Laney: All checkbox related packages use this ML (e.g https://launchpad.net/ubuntu/+source/plainbox)
<zyga> Laney: I'll look into it
<zyga> Laney: done
<Laney> hi spineau, thanks!
<Laney> hopefully someone will come and look quite soon
<spineau> Laney: I hope so too
<Laney> @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: mdeslaur
<yofel> Hi, could someone from the DMB add extra-cmake-modules back to the kubuntu packageset please? It's part of kde frameworks that's mostly maintained by us.
<yofel> and is there an easy way to list the reverse-*build*-dependencies of something? e-c-m is used by some qt5 packages so I would like to testbuild those just to be safe
<cjwatson> reverse-depends -b
<yofel> thanks
<mdeslaur> @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:
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach
<dholbach> :)
<smoser> hey.
<smoser> is ureadahead still relevant ?
<pitti> smoser: not at all on SSD, but still on spinning rust, and ogra says it helps on MMC too
<smoser> i had in my head that upstart made use of it and with a systemd system i'd guess its not used.
<pitti> smoser: it actually is, I fixed it to work under systemd because phone
<pitti> but it still uses an ancient ubuntu kernel patch, so it won't work with upstream kernels
<smoser> pitti, oh. ok. that was my query. i just didn't know if it could be dropped from seeds
<pitti> there's been a replacement for years, but ureadahead needs to be ported to that
<pitti> smoser: oh, do drop it from clouds
<pitti> it makes zero sense on virtual machines
<smoser> its way down
<pitti> kees, stgraber, slangasek, infinity: TB meeting in 4 mins, reminder
<smoser> The following packages will be REMOVED:
<smoser>   ubuntu-minimal* ureadahead*
<pitti> smoser: I suppose we should unseed it from minimal and seed it into standard or even desktop+touch
<smoser> well, if it does in fact help on spinning disks, then ...
<smoser> you'd be actively hurting server installs to spinning disks by removing it
<smoser> hey. other random question
<pitti> smoser: does server not install ubuntu-standard?
<slangasek> not true that ureadahead is only useful for spinning disks; I forget the details, but it did have relevance for SSD
<smoser> (i thought that too at least at one point, slangasek).
<slangasek> this may /no longer/ be the case, but Keybuk had benchmarked it
<smoser> pitti, one way or another, d-i and maas installs are going to get ubuntu-minimal
<smoser> other qustion, was https://wiki.ubuntu.com/Releases shows 15.04 EOL is Feb 4.
<smoser> but distro-info-data says 01-23
<smoser> is that a designed difference ?
<mdeslaur> smoser: it's feb 4th because the eol notice was sent out late
<smoser> ok. so readers of distro-info-data just get an early kick in the pants. that is fine.
<pitti> smoser: Jan 23 is "end of love", feb 4 is "end of life" :)
<pitti> although I guess with $phone it'll actually stay alive for much longer
<tumbleweed> doko: let's keep trying :(
<tumbleweed> doko: next retry worked :)
<pitti> doko: debhelper merge uploaded
<smoser> apt is much less GET'y lately.
<smoser> previously apt-get update would do something like 58 GETs and now it does only 6.
<smoser> https://gist.github.com/smoser/5586288
<smoser> horay!
<pitti> smoser: wow, that's apt 1.1, or the new 1.2?
<pitti> I wonder if it does that, http2 and some bundling or so? AFAIK the structure on archive.u.c. didn't change
<cjwatson> pitti: InRelease is recent-ish, although wouldn't account for all of that.  But Julian has been doing a lot of optimisation work
<pitti> cjwatson: I see how that would cut down the GETs by a few (not downloading the Release.gpg), but I don't think that explains 58 â 6?
<cjwatson> Indeed
<pitti> cjwatson: anyway, thanks for pointing that out, I wasn't aware of InRelease yet
<cjwatson> Maybe this was David - I see a bunch of vaguely-relevant-looking stuff in e.g. 1.1~exp9
<juliank> pitti: smoser: Mostly the work of mvo and DonKult in 1.1, as APT now only fetches files listed in the (In)Release files, instead of trying everything it might need.
<juliank> cjwatson: ^
<cjwatson> Ah, cool
<smoser> juliank, \o/ thank you!
<smoser> oh. and DonKult and mvo.
<juliank> The Ubuntu archive really should start shipping pdiffs though, then there would be more GETs, but things would be *much* faster
<smoser> GETs are heavy
<infinity> I've never noticed pdiffs made my life better.
<infinity> I turn them off on Debian hosts.
<juliank> smoser: Fetching a few 100 kb compared to a few MB/s is a huge difference
<pitti> infinity: really?
<pitti> they absolutely rock
<juliank> infinity: They only really do since recently.
<pitti> apt-get update on Debian is a non-issue
<pitti> like, lightning fast
<infinity> I dunno, I have a lot of bandwidth and slow CPUs.
<pitti> on Ubuntu it's a serious task
<infinity> Maybe things improved recently, but the tradeoff used to absolutely not be worth it.
<smoser> pitti, on xenial its dramatically improved.
<pitti> wow, I have a completely different experience
<juliank> infinity: They improved *a lot*
<pitti> well, even on squeeze
<pitti> even apt-get with 20 pdiffs is still much faster than on ubuntu
<smoser> by-hash: https://bugs.launchpad.net/launchpad/+bug/1430011
<ubottu> Launchpad bug 1430011 in Launchpad itself "support apt by-hash mirrors" [High,Triaged]
<smoser> then super!
<infinity> Getting there.
<juliank> An update takes 10 seconds here for unstable+experimental with Packages, Sources, Contents files for amd64 and i386
<cjwatson> Yeah, by-hash is on my list, but I wanted to finish xz support first, and that's still blocked on some infrastructure deployments to avoid e.g. incorrect squid caching of .xz files
<Unit193> pdiffs are so slow, that's why I as well turned them off in Debian.
<juliank> Unit193: *were*
<cjwatson> The problem with pdiffs in Ubuntu has historically been that we cycle our archive a LOT more often than Debian, so could end up keeping an awful lot of the things around
<juliank> Since 1.1.7 it's really fast
<cjwatson> But I would like to do it at some point now that the client implementation is sensible
<infinity> juliank: It would have to be super fast, given that 24h of pdiffs in Ubuntu could be 48 (or more) diffs.
<Unit193> Not sure if I've noticed a huge change in Debian chroots, I suppose I'll have to try it (or wait for infinity to. >_> )
<juliank> infinity: The amount of pdiffs does not make a difference, just the total size, given that they're pipelined and merged before being applied
<infinity> juliank: Curious.  Yeah, that definitely sounds better than before.
<juliank> The bottleneck we had was because reads were unbuffered, so we were doing read(..., 1, ..)
<juliank> Well, that was the most important bottleneck
<rbasak> juliank: it seems that pipelining doesn't work when behind a traditional (non-pipelining-supporting) squid proxy though? pdiffs are slow for me, I think because of the round trip time.
<juliank> rbasak: Right, it requires HTTP/1.1, older squids only do 1.0
<juliank> If you want extreme performance, you might want 1.2, that also runs the rred processes in parallel
<juliank> But that's only really useful for Contents files
<smoser> 'rr'ed ?
<nacc> round robin'd?
<nacc> dunno :)
<juliank> smoser: It's the thing applying the pdiffs
<smoser> if thats parallel hits on the same mirror, thats great (what https://github.com/ilikenwf/apt-fast does).
<smoser> oh.
<juliank> smoser: No, that would not be great
<smoser> well, then... since this is like Christmas here for apt... what about ^
<juliank> It's one line to enable that, but we're not going to do it
<smoser> why ?
<juliank> Because it's unfair.
<smoser> hm..
<juliank> and if your mirror is fast enough, it would be slower
<juliank> due to additional overhead
<smoser> well, having it configurable would be wonderful. on a per-mirror basis possibly ?
<juliank> If your mirror is limiting you because it does not have enough bandwidth, you are stealing bandwidth from other users.
<smoser> it is a *massive* improvement on S3 mirrors.
<Unit193> juliank: This is not horribly slow, thanks for shouting.
<smoser> on s3 mirrors a connection takes a long time to "bring up". the pipe is virtually limitless.
<smoser> but doign serial connections kills you.
<smoser> on other scale-out style solutions, i'd think behavior might be similar.
<juliank> smoser: Shouldn't pipelining take care of that?
<juliank> Or is it the connection from the front to the back end
<juliank> on the server?
<smoser> well, they had a bug in pipelining , which was later fixed, but even then it was not significantly improved.
<juliank> hmm
<smoser> yeah.. i think the server side took a while to determine you were allowed access to the file or somethign.
<smoser> but amazon's suggestion was "our object store is designed to scale out... throw as many connections as you want at us"
<smoser> and test validated that.
<smoser> using apt-fast we could saturate the link that was provided to the instance.
<smoser> but without it, not a chance.
<smoser> ie, 4-5M/s -> 40M/s
<smoser> (in an 'apt-get --download-only ubuntu-desktop')
<smoser> i respect your decision to have clients play nice with servers... but some servers are perfectly fine with parallel connections.
<juliank> I can talk to the rest of the team about that use case
<juliank> But we do have a limit of min(CPU count *  2, 10)
<juliank> Well, no
<juliank> You could set 10 to a higher value
<juliank> But the number of processes we spawn needs to be controlled in some sort, and we basically append random() % (CPU_COUNT * 2) to the queue name to limit the amount of queues
<gQuigs> any suggestions on what to investigate next for https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1515446 ?  It works in debian testing (even though it still gives the nameserver error)
<ubottu> Launchpad bug 1515446 in systemd (Ubuntu) "NFS shares in FSTAB no longer mount at boot" [Medium,Confirmed]
<gQuigs> seems to be caused by network-manager/systemd, but I tried installing network-manager from debian and doesn't work any better...
<gQuigs> guessing there is a mounting difference between Ubuntu and debian that makes debian retry?
<pitti> gQuigs: the main difference in that regard is that ubuntu ships nfs-utils systemd units while debian uses the init.d script
<gQuigs> pitti: interesting.. I think that is likely the issue..  guess I can try adding a "Network-manager wait for online" to one of those services?
<gQuigs> I guess I should report a bug to debian on it, because likely the NetworkManager difference (not having anything depend on NetworkManager-wait-online.service) will end up affecting debian as well..
<pitti> gQuigs: sorry, just here with half an ear (doing a sprint)
<pitti> gQuigs: nothign is suppposed to directly wait for NM-waitonline; only to network-online.target
<pitti> gQuigs: and NM-waitonline is an "implementation" of network-online (another one is to wait for ifupdown interfaces)
<pitti> gQuigs: so waiting on network-online.target is right for NFS
<gQuigs> pitti: np, in Fedora it works by having NetworkManager-wait-online.service as a wants on to network-online.target.
<pitti> [Install]
<pitti> WantedBy=network-online.target
<gQuigs> pitti: that was removed in Debian's network-manager, and now NFS mounts fail because nameservers aren't up yet
<pitti> gQuigs: yes, same thing
<rharper> xnox: hi, wanted to mention that I'm looking at the strongswan merge;  once I have something working after merging, I'll send a note to ubuntu-devel with the changes for discussion, as there is quite a delta (specifically in the packaging of plugins)
<gQuigs> so is it a Debian bug? or should our network-online.target be changed (I know how to do this), or our NFS utils?
<barry> apw: are you still around?  had some questions about LP: #1519894
<ubottu> Launchpad bug 1519894 in Auto Package Testing "add JSON output for queued and running tests" [Wishlist,In progress] https://launchpad.net/bugs/1519894
<pitti> gQuigs: what is actually wrong about our network-online.target? it has Before=network-online.target, so it ought to be fine?
<pitti> gQuigs: err, I mean, our NetworkManager-wait-online.service has that Before=
<smoser> does anyone know how i would "Blacklist python2.7 and libpython2.7 from cloud and server: " ?
<smoser> https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
<smoser> i believe next cloud image builds (with cloud-utils at 0.27-0ubuntu21 will drop euca2ools (and thus python2.7)
<smoser> and if that is in fact true, i want to make it stay that way
<cjwatson> man germinate   /blacklist
<pitti> smoser: indeed, I've been purging python2 from my autopkgtest xenial cloud images for a long time
<smoser> cjwatson, thank you.
<smoser> pitti, well, we had made it in wily
<smoser> but then 1 week before release, we got python2 back
<gQuigs> pitti: it's not actually blocking network-online.target and I don't know if it actually ever runs
<gQuigs> sudo systemctl status NetworkManager-wait-online.service shows no log data at all...
<gQuigs> pitti: if you do ' sudo systemctl add-wants network-online.target NetworkManager-wait-online.service ' and reboot it actually shows log data and shows it exited green
<pitti> gQuigs: ah, so you mean that we don't actually enable NetworkManager-wait-online.service
<pitti> gQuigs: sorry, I didn't think of that; I remember that there was some discussion at some point, about whether we should do that by default
<pitti> bug 1430280
<ubottu> bug 1430280 in NetworkManager "NetworkManager-wait-online.service not enabled after package installation" [Medium,Confirmed] https://launchpad.net/bugs/1430280
<pitti> (firefox awesome bar to the rescue!)
<pitti> gQuigs: it ran on my system, but maybe I configured it manually at some point
<pitti> gQuigs: but the intention was that it got enabled automatically since vivid
<juliank> Shouldn't devel-* point to xenial and not to wily?
<pitti> err, for sure
<juliank> Hmm, on de.archive it points to xenial, but on archive.ubuntu.com it points to wily
<gQuigs> pitti: awesome, I'll see about making a debdiff for that then.  thanks!
<pitti> gQuigs: ah, was that accidentally dropped later in a merge or so?
<gQuigs> pitti: looks like it, it doesn't run by default
<gQuigs> and I had no idea that sudo systemctl enable NetworkManager-wait-online.service == the add-wants given the before line
<gQuigs> makes sense though
<pitti> gQuigs: no, enable doesn't look at the Before= line, it creates the symlinks for the [Install] section, i. e. the WantedBy
<doko> pitti, still awake?
<Unit193> It's a pitti if he isn't.
<sarnold> considering he's often starting his day in four or five hours, it's probabl best if he's still sleeping :)
#ubuntu-devel 2016-01-20
<doko> jtaylor, any idea about https://launchpad.net/ubuntu/+source/python-scipy/0.16.1-1build2/+build/8871562 ?
 * mwhudson sighs
<mwhudson> INFO: pkgstripfiles: waiting for lock (libgolang-github-pborman-uuid1-dbgsym) ...
<mwhudson> ^ what does this mean?
<mwhudson> oh wait, this is what doko was complaining about
<doko> mwhudson, please wait until pkgbinarymangler is published, then cancel and give back the builds
<mwhudson> doko: this is local, but ok
<mwhudson> ah seems it is published
<doko> https://bugs.launchpad.net/bugs/1535949
<ubottu> Launchpad bug 1535949 in debhelper (Ubuntu) "handling of -dbgsym packages breaks pkgbinarymangler" [High,Confirmed]
<mwhudson> distro development feels like juggling a sack of cats sometimes
<sarnold> hehe
<mwhudson> doko: new pkgbinarymangler seems to fix it indeed, thanks
<doko> ahh, no, this looks worse, packages can not be uploaded
<doko> pitti, https://bugs.launchpad.net/bugs/1535949
<ubottu> Launchpad bug 1535949 in debhelper (Ubuntu) "handling of -dbgsym packages breaks pkgbinarymangler" [Critical,Confirmed]
<mwhudson> waaiittt a minute
<mwhudson> does sbuild not override PATH?
<doko> pitti, slangasek: 1535949 still needs to get resolved. however I'm afk now. cancelled all looping builds
<doko> cancelled all affected builds. please give all cancelled builds back once the issue is fixed
<mapreri> I just got a reject from a archive@u.c for an upload I did to debian and got synced:
<mapreri> sigil-dbgsym_0.9.2+dfsg+dfsg-2_powerpc.deb: control file lists name as 'sigil-dbgsym', which isn't in changes file.
<mapreri> uh, just had the same failure for ppc64el and armhf now
<sarnold> mapreri: I think you get to ignore that https://bugs.launchpad.net/bugs/1535949
<ubottu> Launchpad bug 1535949 in debhelper (Ubuntu) "handling of -dbgsym packages breaks pkgbinarymangler" [Critical,Confirmed]
<mapreri> oh, I received that mail too, but didn't read it (subscribed to dh bugs through debian's pts
<mapreri> ok, thank you.  guess somebody else will take care of fixing dh and retry all the affected uploads (or the build)
<pitti> Good monring
<pitti> doko: we still have the previous patch to disable dbgsyms, and I didn't notice any in my local sbuild, but I'll look; argh
<pitti> slangasek: FYI, I figured out the "apt pinning compatible apt-get source" to also work for linux now, so audit and friends went in
<cpaelzer> good morning
<pitti> doko: fixed debhelper uploaded
<pitti> doko: and all 70 "failed to upload" builds retried
<LocutusOfBorg> pitti, <3
<LocutusOfBorg> BTW while I'm highlighting you, you retried libquazip test against marble-proposed, but it didn't start for s390x
<LocutusOfBorg> so the migration is still stuck I think
<pitti> LocutusOfBorg: yep, it's on my radar; s390x has some trouble ATM, I'm working on a fix to at least see the error message, and will then do a mass-retry
<LocutusOfBorg> thanks, double thanks
<cpaelzer> pitti: LocutusOfBorg: all of what I saw so far with s390x was packaging and stuff which you guys are way++ more experienced - but if it every seems to come down to s390 instructions or other real close-to-HW issues let me know
<cpaelzer> same is true if the dasd/eckd disk design ever troubles you
<ginggs> morning all! There are now only a handful of ubuntu-specific packages still using python-support LP: #1535318 . Most of them haven't been touched in several years.  Do we want to fix them or remove them?  pitti: system-config-date has your name on it :)
<ubottu> Launchpad bug 1535318 in system-config-date (Ubuntu) "deprecation of python-support" [Undecided,New] https://launchpad.net/bugs/1535318
<pitti> ginggs: indeed Debian dropped pysupport recently, so we absolutely shoudl fix it
<pitti> ginggs: having a tracking bug for the remaining Ubuntu ones would be really useful indeed
<pitti> ah, that :)
<pitti> quite a few more than I expected
<pitti> but I think a lot of them should be in Debian too, and thus either be merges or removals
<pitti> Depends: python, python-support (>= 0.90.0), python-gtk2, python-gnome2, gksu
<pitti> ginggs: that really smells like a remova ;)
<ginggs> pitti: no, only the ones I have linked to debian bugs are in debian
<pitti> ginggs: e. g. python-cogent is only blocked on the arm64 FTBFS (https://launchpad.net/ubuntu/+source/python-cogent/1.5.3-10/+build/8774183) which is again blocked on some blast FTBFS
<pitti> tricky
<ginggs> yeah, ncbi-tools6, arm64 built fine in Debian
<ginggs> but in ubuntu we get a gcc internal compiler error
<ginggs> is removing the old arm64 binaries for ncbi-tools6 and python-cogent an option?
<LocutusOfBorg> mapreri, ^^^^
<pitti> ginggs: it has a bunch of reverse dependencies, so we need to find out which and remove them all
<ginggs> pitti: yeah, i do see them with 'reverse-depends'.  do we have an equivalent for 'dak rm' in ubuntu?
<pitti> ginggs: if that auto-removes reverse depends, then no
<ginggs> it can tell you what will be removed
<pitti> stgraber: can I override /usr/share/lxc/config/ubuntu.common.conf in /etc/ somewhere?
<pitti> stgraber: I edit it on the LXC autopkgtest instances, but every dist-upgrade that includes lxc resets it
<pitti> stgraber: oh, I suppose I could at least use /usr/share/lxc/config/common.conf.d/README
<pitti> well, without the README obviously
<alkisg> mitya57: hi, have you ever considered making an ubuntu flavor with gnome-flashback as the default session? I think edubuntu will have its last release ever in 16.04, so an ubuntu-flashback flavor would fill a big gap there...
<highvoltage> alkisg: out of curiousity, what would suck a flavour use for file browser, viewing images, login manager, etc?
<highvoltage> *such
<alkisg> highvoltage: the gap I'm thinking is "as much close to ubuntu as possible, but for clients without 3d/compositing abilities"
<alkisg> So I would like it if it used whatever ubuntu uses (which afaik gnome-flashback already does)
<highvoltage> wouldn't ubuntu-mate fit that use case well?
<Laney> doko: file conflict in libxapian-1.3-5 update
<alkisg> ubuntu-mate is basically an older gnome which is now maintained by a few students, I'm not sure it's a better choice than upstream gnome + ubuntu + a thin layer (=flashback, menus etc)
<Laney> doko: bug #1536093
<ubottu> bug 1536093 in xapian1.3-core (Ubuntu) "package libxapian-1.3-5 (not installed) failed to install/upgrade: trying to overwrite '/usr/share/xapian-core/stopwords/dutch.list', which is also in package libxapian-1.3-4 1.3.3-0ubuntu2" [Undecided,Confirmed] https://launchpad.net/bugs/1536093
<highvoltage> alkisg: gnome-flashback is also not upstream gnome (despite the name)
<alkisg> highvoltage: yes, but it's a thin layer, it is something maintainable by a couple of devs, unlike ubuntu-mate which as years go by and gnome2 gets extremely out of date, will require many more devs...
<mapreri> LocutusOfBorg: what particular line are you highlighting to me?
<LocutusOfBorg> mapreri,
<LocutusOfBorg> [09:36:34] <ubottu> Launchpad bug 1535318 in system-config-date (Ubuntu) "deprecation of python-support" [Undecided,New] https://launchpad.net/bugs/1535318
<ubottu> Launchpad bug 1535318 in sadms (Ubuntu) "deprecation of python-support" [Undecided,New]
<LocutusOfBorg> I know you like to kill python-support with fire, don't you? :P
<mapreri> LocutusOfBorg: packages in ubuntu-only are so outdated and without love in every possible way...  (looking at the dh_python2 transition tracker in ubuntu)
<mapreri> I think for now I'll not be involved in getting rid of pysupport from ubuntu
<mapreri> ... and then you notice packages with Maintainer: a DD in a ubuntu-only package, and wonder how that can happen :|
<rbasak> There are plenty of packages in Debian that are rotting too.
<rbasak> Popular packages end up in sync.
<stgraber> pitti: right, common.conf.d is most likely the way to go for you
<pitti> stgraber: still seems strange to put them into /usr, but I can work with that; certainly much better than changing the deb-shipped file :)
<tjaalton> are upgrades from lts + lts-backport-stack supported to next lts only?
<rbasak> tjaalton: if you're not aware of the page, https://wiki.ubuntu.com/Kernel/LTSEnablementStack might have an answer.
<tjaalton> I am aware, and point 12. mentions something about "issues", but no clear wording about "don't do that"
<tjaalton> someone upgraded from 14.04.3 to vivid and things broke, no surprises there
<rbasak> AH
<rbasak> Yes, I think that's a serious issue. I had a similar use case explode on me. I filed a bug about it.
 * rbasak looks
<tjaalton> the page probably should have a command for reverting back to stock trusty packages
<rbasak> bug 1252843
<ubottu> bug 1252843 in update-manager (Ubuntu) "Permits upgrade from an LTS system on an HWE stack to a broken system" [High,Triaged] https://launchpad.net/bugs/1252843
<rbasak> My use case was to initially install 12.04.(something), and then eventually decide to roll up to 13.10 or something because I needed some newer package. And the install exploded.
<rbasak> s/install/upgrade/
<tjaalton> looks like it's still an issue
<xnox> doko, btrfs-tools has ice on arm64 in ubuntu =( https://launchpadlibrarian.net/234669123/buildlog_ubuntu-xenial-arm64.btrfs-tools_4.4-1_BUILDING.txt.gz
<xnox> doko, the build-log looks like it has a clean gcc dump too.
<doko> looking
<doko> xnox, work around is to build with -O2 instead of -Os
<xnox> doko, =(
<xnox> doko, is it a known bug?
<slangasek> pitti: nice!
<doko> xnox, https://bugs.linaro.org/show_bug.cgi?id=2001
<ubottu> bugs.linaro.org bug 2001 in General "[5 Regression] ICE in final_scan_insn, at final.c:3020 on aarch64-linux-gnu" [Major,Unconfirmed]
<doko> barry, tumbleweed, jtaylor: http://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-only.html   a few packages left
<xnox> doko, tah.
<ginggs_> doko, pitti: looks like that arm64 bug is the same in ncbi-tools6? https://launchpad.net/ubuntu/+source/ncbi-tools6/6.1.20120620-10  "pseed3.c: In function 'seedEngineCore':
<ginggs_> pseed3.c:631:1: error: could not split insn"
<jtaylor> doko: scipy will get a new upstream soon, I may check the failure then
<jtaylor> doko: though I'll be only partially available in the next 10 days, so if someone else wants to fix it go ahead
<barry> doko: cool.  we're still sprinting for the next 2 days
<sergiusens> hi there pitti, I'm trying to use adt with lxd and getting http://paste.ubuntu.com/14582679/ is there anything obvious I'm missing?
<pitti> sergiusens: nothign obvious, I think
<pitti> sergiusens: if you do "lxc launch images:ubuntu/xenial/amd64 x1", wait a bit (boot should take < 5 s), and "lxc exec x1 bash"
<pitti> sergiusens: I suppose it fails to boot, can you check journalctl?
<jtaylor> is there a docker update planned for xenial? given the issues we have in trusty and the next version 1.10 will have large changes in its internal layout I think it would be best to have it as new as possible (or not at all)
<sergiusens> pitti, launching works just fine
<sergiusens> I've been using lxd for a bit now for playing with random things
<sergiusens> and to confirm, lxc exec for bash worked just fine
<pitti> sergiusens: and "runlevel" says something like "5 N"?
<sergiusens> pitti, ah, it indeed says unknown
<pitti> sergiusens: so something went wrong with booting the container
<pitti> sergiusens: checkig "runlevel" is the least common denominator that I found for handling arbitary testbeds
<sergiusens> pitti, there are a couple of failing services
<pitti> sergiusens: what does "systemctl status" say? degraded, or still booting?
<sergiusens> pitti, 'starting'
<sergiusens> pitti, 3 units failed, which is the amount of failures I saw when running systemctl
<sergiusens> if it is of any worth http://paste.ubuntu.com/14582730/
<pitti> sergiusens: yeah, I get that too, that's just unpriv container limitations
<pitti> sergiusens: so for me I get "State: degraded" (which is "booted, but some failed units"), and runlevel "N 5"
<pitti> and the same three failed units
<pitti> sergiusens: can you pastebin "journalctl"?
<sergiusens> pitti, http://paste.ubuntu.com/14582749/
<sergiusens> pitti, oh, now I recall bridging the containers to my network card, not sure it should affect booting, but it will affect adt :-)
<pitti> sergiusens: it doesn't care much about networking as long as your tests don't; but of course that will blow up if you run --apt-upgrade or install test deps
<sergiusens> pitti, yeah, I will certainly hit that
<pitti> networking.service: Start operation timed out. Terminating.
<pitti> Failed to start Raise network interfaces.
<pitti> sergiusens: so, that
<pitti> sergiusens: and previously the unit was still starting, until it hit the timeout
<pitti> so it didn't yet appear in --failed
<sergiusens> pitti, great, I'll look into this later, thanks for all the pointers!
<Laney> doko: https://launchpadlibrarian.net/234703765/xapian1.3-core_1.3.4-0ubuntu3_1.3.4-0ubuntu4.diff.gz should be libxapian-1.3-4
<doko> ohh crap
<RAOF> cjwatson: I seem to recall at some point you making the buildd chroot tarballs available over lpapi. Is that me confabulating, or is this possible? (This is cf: jenkaaaaaaas).
<pitti> RAOF: serach for "chroot_url" on https://launchpad.net/+apidoc/1.0.html
<RAOF> pitti: Maha! Thanks!
<RAOF> Also, thanks for the apidoc link :)
<pitti> "http://launchpadlibrarian.net/222053869/chroot-ubuntu-xenial-amd64.tar.bz2"
<pitti> $ wget -q -O- https://api.launchpad.net/1.0/ubuntu/xenial/amd64/chroot_url
<pitti> RAOF: ^ imagine these two lines swapped around :)
<pitti> RAOF: (-: Éá´lÉÉ¹Êsnâ É¹oÉ É¹ÇpÉ¹o ÊÉ¥Æá´É¹ ÇÉ¥Ê uá´ ÇÉ¹É ÊÇÉ¥Ê 'ÊllÉnÊÉÉ
<RAOF> :)
<sergiusens> xnox, hey, btw, when should my upload rights become effective?
<RAOF> Well, that's sad. I don't think I can slurp a vivid-overlay chroot out of that :)
<xnox> sergiusens, i dunno =) i don't think i've acted upon doing so, yet.
<cjwatson> RAOF: That's just the same as the vivid chroot.
<xnox> sergiusens, i will not get around to do it today, sorry. added a todo for tomorrow.
<RAOF> cjwatson: ...of course it is. HAH!
<sergiusens> xnox, ah, I was just wondering what the time lines were; no worries
 * RAOF knew that. Or would have, had he thought about it for any extended period of time.
<Laney> xnox: you can't do PPU anyway, need to ask TB person for that
<xnox> Laney, right that's i thought.
<xnox> and all of them expired, unless stgraber was back-doored in
<Laney> https://launchpad.net/~techboard/+members lies
<stgraber> TB terms have been extended a bit so we have time to deal with elections
<caribou> xnox: while you're at it, might think of changing my access as well :-)
<caribou> or whoever can
<mightyiam> Yo, I'm on 16.04 and some package doesn't upgrade
<mightyiam> python3-xapian1.3 is partially installed
<mightyiam> Some dependency issue
<mightyiam> http://i.imgur.com/ONip6pN.png
<mightyiam> But libxapian-1.3-5 is marked for installation
<sarnold> mightyiam: file a bug against the xapian1.3-core source package with ubuntu-bug xapian1.3-core -- include the copy-and-paste output inlcyuding the file-overwrite attempt and the killed paste command
#ubuntu-devel 2016-01-21
<Logan> doko: if you're around, I've pinged you in Bug 1536093 - just needs a quick fix. it's affecting a lot of people, unfortunately
<ubottu> bug 1536093 in xapian1.3-core (Ubuntu) "package libxapian-1.3-5 (not installed) failed to install/upgrade: trying to overwrite '/usr/share/xapian-core/stopwords/dutch.list', which is also in package libxapian-1.3-4 1.3.3-0ubuntu2" [High,Triaged] https://launchpad.net/bugs/1536093
 * alkisg had to purge a lot of apt related packages and to reinstall them later in order to get past this...
<ricotz> alkisg, "dpkg -i --force-overwrite libxapian-1.3-4_*.deb"
<alkisg> Ah, I tried dpkg-divert but I didn't take time to try other things, and I worked around it with purge + reinstall, thanks :)
<sarnold> how'd this package make out of -proposed?
<pitti> Good morning
<pitti> sarnold: we don't do upgrade testing as part of -proposed tests
<pitti> sarnold: we implicitly do for packages which are in a minimal install, but xapian is far from that
<sarnold> morning pitti :) I'm surprised to see you already, I though tyou just quit a few hours ago...
<pitti> sarnold: right, I did a nightshift for the proposed-migration sprint
<sarnold> pitti: did this pass then because there's no autopkgtests that rely upon it?
<sarnold> pitti: eep :) I had assmed maybe you'd be over on this continent..
<pitti> sarnold: no, but fresh installs of the debs are fine -- this is an upgrade prolbem
<sarnold> pitti: ahhhhhhh
<pitti> sarnold: only in spirit :) day time in Europe, night shift for the US guys
<spineau> mitya57: hello, I've updated pyotherside packaging in debian to unblock the MIR (https://bugs.launchpad.net/ubuntu/+source/pyotherside/+bug/1534067). If you could review/sponsor it I would be extremely grateful.
<ubottu> Launchpad bug 1534067 in pyotherside (Ubuntu) "[MIR] pyotherside" [Undecided,Confirmed]
<sarnold> pitti: thanks for the explanation
<pitti> sarnold: so, we actually have (or at least had) daily upgrade tests which should pick this up
<sarnold> pitti: piuparts thing?
<pitti> but https://platform-qa-jenkins.ubuntu.com/job/upgrade_ubuntu-trusty-xenial-desktop-amd64_qemu/ has failed for a while
<pitti> sarnold: no, I don't think this uses piuparts; just a standard desktop/server/etc. base image, and do-release-upgrade, and some post-upgrade checks ("does thist still boot", etc."0
<sarnold> that's a lot of red dots :)
<pitti> https://platform-qa-jenkins.ubuntu.com/ has green ones, too
<pitti> https://platform-qa-jenkins.ubuntu.com/job/upgrade_ubuntu-trusty-xenial-desktop-i386_qemu/59/console
<pitti> lol
<cyphermox> Good morning!
<pitti> I don't think that actually even started the upgrade
<pitti> which might be an actual problem given that the  other tests work, or some desktop specific upgrade test problem
<pitti> hey cyphermox!
<pitti> $ sudo dpkg -i --force-overwrite /var/cache/apt/archives/libxapian-1.3-5_1.3.4-0ubuntu4_amd64.deb
<pitti> FTR, to fix this locally
<Unit193> pitti: Err, I liked `sudo dpkg --purge libxapian-1.3-4` better, less --force.
<LocutusOfBorg> wonderful, virtualbox doesn't build, and I don't know how to fix
<LocutusOfBorg>  sbuild-build-depends-virtualbox-dummy : Depends: texlive-fonts-extra but it is not going to be installed
<LocutusOfBorg> texlive-fonts-extra/amd64 unsatisfiable Depends: fonts-roboto-hinted
<LocutusOfBorg> I did a syncpackage fonts-roboto
<LocutusOfBorg> not sure why it has been kicked out
<sarnold> looks like there's a fonts-roboto but not the -hinted variant https://launchpad.net/ubuntu/+source/fonts-android
<LocutusOfBorg> I think I'm talking about src:fonts-roboto
<LocutusOfBorg> not the one provided by fonts-android
<sarnold> ahhhh
<sarnold> hmm, did that also drop the fonts-roboto-hinted? check the changelog https://launchpad.net/debian/+source/fonts-roboto
<LocutusOfBorg> fonts-android needs a merge I think :)
<LocutusOfBorg> I checked the PTS https://packages.debian.org/unstable/fonts-roboto-hinted
<LocutusOfBorg> any pretty please sponsor for this?
<LocutusOfBorg> "syncpackage -s costamagnagianfranco -V 1:6.0.1r3-2 -f -b 1536547 fonts-android"
<LocutusOfBorg> after double checking
<rbasak> LocutusOfBorg: I would but I'm hesitant to touch that package because it looks like the phone is a heavy consumer. Maybe get one of that team to check and sync it?
<LocutusOfBorg> well, somebody will hopefully take the job :)
<LocutusOfBorg> seems it won't block the virtualbox migration hopefully
<LocutusOfBorg> even if fonts-droid took over a binary package from it
<LocutusOfBorg> doko, can you please sync python-greenlet? or fakesync, since the orig tarballs seems to differ
<pitti> xnox: any luck with the ppc64el instance?
<xnox> pitti, yes. You can kill it by the way. I have reproduced the bug with more logs. and then loggedout. I have uploaded new btrfs-tools into debian, it synced into ubuntu. However, need to resolve ftbfs on arm64 for it to migrate and build updated iso image.
<xnox> due to compiler ice.
<pitti> xnox: ah, great! so d-i in nested QEMU worked?
 * pitti kills it to reclaim some quota back
<xnox> pitti, somewhat slow =)
<xnox> pitti, yeah do kill it.
<pitti> crw-rw---- 1 root kvm 10, 232 Jan 19 17:08 /dev/kvm
<pitti> xnox: ^ this didn't help? (I didn't put ubuntu into the kvm group)
<LocutusOfBorg> pitti, is openvpn on your radar? if not, can I do a merge and ping you with a debdiff?
<xnox> pitti, can't remember if i checked that or not. I think i was rebel, and run it as root anyway.
<xnox> pitti, it was good enough. so meh =)
<LocutusOfBorg> well, I did it and opened LP: #1536568
<ubottu> Launchpad bug 1536568 in openvpn (Ubuntu) "please merge openvpn from debian" [Undecided,New] https://launchpad.net/bugs/1536568
<pitti> LocutusOfBorg: thanks
<pitti> LocutusOfBorg: ah, I see Debian accepted our startup ordering patch
<pitti> LocutusOfBorg: LGTM! Just one nitpick:
<pitti> Remaining Ubuntu changes:
<pitti> [...]
<pitti>   - drop openvpn@.service change, included in Debian
<pitti> this looks strange, as that's not a "remaining change", it's the opposite
<pitti> I'll just drop that changelog line
<pitti> LocutusOfBorg: test-building and running with my VPN, then I'll upload
<pitti> LocutusOfBorg: uploaded, thanks!
<LocutusOfBorg> thanks :)
<LocutusOfBorg> I wasn't sure about not mentioning, or mentioning the not-a-delta-anymore line
<LocutusOfBorg> :)
<pitti> LocutusOfBorg: it's fine to mention it as a second entry, like " * Drop..." (but not under " * Remaining changes:")
<pitti> LocutusOfBorg: but really, it's just a tiny detail
<pitti> LocutusOfBorg: but as the Debian changelog gets included, I usually leave it out
<LocutusOfBorg> thanks, I was thinking the same, the change was mentioned a few lines below, but with a different phrasing
<pitti> apw: hm, all linux* stuff and d-i are valid candidates, but there's some uninstallability; did you already check this, or shoudl we look into this?
<apw> pitti, oh i know what it is, it is ppp being in the pile
<apw> isdnutils has a tight ppp linkage
<apw> i am looking at the merge right now
<pitti> apw: that's not on the uninstallabilitly list on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt though
<pitti> apw: not for "trying: linux" I mean (it's separately uninstallable, but due to NM)
<apw> Trying easy from autohinter: debian-installer/20101020ubuntu412 linux-signed/4.3.0-7.18 linux/4.3.0-7.18 ppp/2.4.7-1+1ubuntu1 pptpd/1.4.0-7 network-manager-pptp/1.0.8-2ubuntu1 linux-meta/4.3.0.7.8
<pitti> ah, so linux blocks on d-i blocks on ppp
<apw> right and that is blocked on isdnutils which has
<pitti> apw: thans
<pitti> (OMG, it's 2016, we still ship isdnutils?)
<apw> Depends: ppp (>= 2.4.6), ppp (<< 2.4.7),
<apw> which is preventing pppd from migrating
<apw> there is an update in debian which i have just merged, just need to review if it makes _any_ sense
 * Laney knows of people still using ISDN
<yofel> Laney: could you please add extra-cmake-modules back to the kubuntu packageset?
<yofel> and is there a better procedure for such requests than pinging some dmb member on IRC? ^^
<Laney> emailing the list
<yofel> the private one?
<Laney> no
<Laney> devel-permissions
<yofel> ok, thanks.
<Laney> why isn't it in your set?
<Laney> because something else uses it I suppsoe
<yofel> probably, but I haven't found out what
<apw> pitti, ok the merge is small enough to be eyeballable i recon, so i think i'll build test it and throw it over the wall
<Laney> fcitx at least
<pitti> apw: it's not like anybody could really test it :)
<Laney> anyway it seems ok
<pitti> apw: ISDN had been a big thing in Germany (and not much in other states) until ~ 2000 or so; these days companies still use it for internal phone networks, but *nobody* hooks a linux server up to an ISDN box
<pitti> (any more)
<apw> i hope not :)  though as you say .de loves it
<apw> i reemeber our uni converting the 30line isdn thing into an IP line and gaining a bunch of performance, 20 years ago
<maswan> roughly 20 years ago the old phone monopoly was starting to think about introducing isdn in .se, using convoluted pay-per-traffic schemes, around the same time ethernet to the apartment started to get common. It never got anywhere here.
<apw> isdn seemed to last about a year as a network thing here
<mitya57> zyga, spineau: ok to sponsor pyotherside (in Debian) now?
<Laney> mitya57: doooo it
<spineau> mitya57: +1000
 * Laney is anxious about iso build breakage
 * mitya57 does
<Laney> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu
<mitya57> spineau, unstable or experimental then? The previous upload was to experimental.
<spineau> mitya57: I don't know it was experimental the first time
<spineau> mitya57: if ubuntu can be sync'ed from experimental I wouldn't probably change it now
<mitya57> It can be synced, yes. Though I can't find any reason why the previous upload was in experimental.
<mitya57> Are 1.2.0 and 1.4.0 releases compatible?
 * spineau is looking at http://pyotherside.readthedocs.org/en/latest/#version-1-4-0-2015-02-19
<mitya57> Ok, let's keep it in experimental for now. It's easy to do another upload pushing it to unstable if needed.
<mitya57> Uploaded!
<mitya57> (Please tag it yourself)
<spineau> mitya57: I was asking in a separate channel (#checkbox) but for us (and our usage) 1.4.0 brings more features and we didn't have to change out code to be compliant but we are not using all pyotherside new methods
<mitya57> For Ubuntu there's no difference. If you want to upload checkbox to Debian too and need pyotherside in unstable, ping me and I'll do another upload.
<mitya57> In any case I heard zyga wanted to make some other changes to the packaging like moving it to pkg-kde team.
<spineau> mitya57: ok, checkbox (-converged) is ubuntu specific so I think we're good now
<mitya57> Ok
<spineau> mitya57: about tag, you meant git-dpm tag?
<mitya57> Yes
<spineau> mitya57: ok, doing it right now
<spineau> mitya57: again thanks a lot for your help and time
<mitya57> You are welcome! I'll try to sync it into Ubuntu when LP picks it up (that'll be tomorrow).
<mitya57> spineau, oops, I forgot it has a new binary. I'll reupload it now, but that also means it'll take a bit longer until it is accepted.
<spineau> mitya57: like going into the NEW queue
<mitya57> Yes
<spineau> mitya57: ok, I think I have to convince cyphermox to accept the MIR with the package as it is today
<mitya57> :)
<spineau> mitya57: as the best we can do now is waiting for ftp masters
<mitya57> They are usually quick on processing new binaries (but not for new sources)
<mitya57> Where quick means less than week
<Laney> you could fakesync it
<spineau> Laney: what would it mean in practice (sorry it's the first time I'm facing such issue)
<mitya57> That means a normal upload to Ubuntu rather than sync.
<mitya57> I have no problem with waiting, but I can do that too if you want.
<spineau> mitya57: the mir bug is critical as it blocks the xenial daily builds, if you can fakesync to ubuntu, I'm sure the MIR team will accept pyotherside
<mitya57> Ok, will do that now
<spineau> mitya57: thanks
<Laney> thanks mitya57
<Laney> we could also unseed checkbox for a bit until this is fixed
<mitya57> Done!
 * mitya57 afk
<apw> pitti, bah overlapped with someone else, theirs hit the queue 5m before mine
<pitti> yay coordination :/
<apw> anyhow its been uploaded, so i assume it will unplug shortly
<apw> yeah i cna't have tlaked about it more here, so, whatever
<spineau> Laney: it depends if it's easy to restore. The last time I filed a MIR bug, it took less than a day from fix-committed to fix-released. So if someone from the MIR team could review https://bugs.launchpad.net/ubuntu/+source/pyotherside/+bug/1534067 today we could have successful builds tomorrow morning
<ubottu> Launchpad bug 1534067 in pyotherside (Ubuntu) "[MIR] pyotherside" [Critical,Confirmed]
<pitti> spineau: that's not the issue -- once a MIR is approved, any archive admin can promote it and that's fast
<pitti> but this MIR hasn't been reviewed/approved yet
<Laney> maybe we can ping a friendly MIR teamer
<spineau> ok, if I can help/answer questions about pytherside in ubuntu, just ping me
<zyga> mitya57: hey
<zyga> mitya57: thanks for helping us out :)
<cyphermox> mitya57: spineau: looking at pyotherside now
<jamespage> anyone know if there is a nice way to make AC_CHECK_HEADERS multi-arch aware?
<spineau> cyphermox: thank you
<jamespage> i.e. /usr/include/<tuple>
<jamespage> for checking like
<flexiondotorg> If anyone is able, I'd really appreciate some sponsoring for Ubuntu MATE :-)
<maswan> doko: RH seems to think that CVE-2015-7575 (rejecting md5 for tls) applies to java as well, does this apply to ubuntu (or debian) versions of openjdk too? There has been quite a bit of discussion in $work regarding this today.
<ubottu> Mozilla Network Security Services (NSS) before 3.20.2, as used in Mozilla Firefox before 43.0.2 and Firefox ESR 38.x before 38.5.2, does not reject MD5 signatures in Server Key Exchange messages in TLS 1.2 Handshake Protocol traffic, which makes it easier for man-in-the-middle attackers to spoof servers by triggering a collision. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7575)
<mdeslaur> maswan: probably, yes. We follow new openjdk releases, I believe we're going to publish one soon.
<cjwatson> jamespage: you shouldn't need to do anything; /usr/include/<current triplet> is on the include path by default
<cyphermox> spineau: who will deal with fixing things in Ubuntu if bugs happen? neither you nor zyga seem to have the requisite upload rights?
<jamespage> cjwatson, yeah - I think I see my problem - something else (I thought it was this)
<spineau> cyphermox: we can fix bugs indeed but someone else will have to upload them
<spineau> cyphermox: is that an issue?
<cyphermox> well it will certainly make your life harder
<cyphermox> what is pyotherside used for in checkbox?
<spineau> cyphermox: the new checkbox-converged is still using QML but we get rig of the dbus service to use python from QML thanks to pyotherside
<spineau> s/rig/rid
<spineau> cyphermox: it's the bridge between the python3 plainbox lib and QML
<maswan> mdeslaur: thank you
<spineau> cyphermox: I'll soon apply for checkbox upload rights. Do you think I should also apply for pyotherside?
<spineau> I mean with the same application
<cyphermox> spineau: it's up to you, if you can show work you've done on the packages
<spineau> cyphermox: I'll do my best for pyotherside. But you'right, w/o such upload permissions bug fixes may be delayed in ubuntu
<cpaelzer> I seem to miss something when creating my dsc & .changes with dpkg-buildpackage
<cpaelzer> the background is that I pulled the source from another ppa, made a few changes and want to dput it to my ppa
<cpaelzer> for one of the related archives dpkg-buildpackage decides to go "dpkg-source: info: building openvswitch-dpdk using existing ..."
<cpaelzer> now when I puload the .changes file launchpad (correctly) complains about that archive being missing
<cpaelzer> I guess there is a way to include (or not exclude) that file, but the manpage isn't obvious enough for now
<cpaelzer> rbasak: in case you know ^^
<cjwatson> cpaelzer: dpkg-buildpackage -sa
<cjwatson> cpaelzer: that's autodetected in some cases but not all
<cjwatson> (to be clear, I mean add -sa to the other options you're already passing)
<cpaelzer> cjwatson: "-sa    Forces the inclusion of the original source." on dpkg-genchanges bassed by buildpackage - thanks
<spineau> cyphermox: thanks for the pyotherside MIR review.
<spineau> cyphermox: should we change the status of the bug now?
<cyphermox> spineau: nah it's good
<spineau> cyphermox: ok
<LocutusOfBorg> pitti, a regression in openvpn :( did you read it?
<LocutusOfBorg> lp: #153568
<ubottu> Launchpad bug 153568 in Moblin Browser "New page will always be opened in current tab instead of new tab" [Medium,Fix released] https://launchpad.net/bugs/153568
<LocutusOfBorg> lp: #1536568
<ubottu> Launchpad bug 1536568 in openvpn (Ubuntu) "please merge openvpn from debian" [Undecided,Fix released] https://launchpad.net/bugs/1536568
<pitti> LocutusOfBorg: no, not yet; sorry, busy
<LocutusOfBorg> seems an user error
<LocutusOfBorg> np
<tkamppeter> pitti, hi
<tkamppeter> I have a question: The liblouis source package and most of its binary packages are in Main, but liblouis-bin is in Universe, how do I get liblouis-bin into Main?
<cjwatson> tkamppeter: make something in main (build-)depend on it or recommend it
<tkamppeter> cjwatson, thank you very much. I will do so.
<mitya57> zyga, you're welcome!
<doko> stgraber, https://bugs.launchpad.net/bugs/1536727
<ubottu> Launchpad bug 1536727 in make-dfsg (Ubuntu) "make crashes in xenial lxc" [Undecided,New]
<tedg> slangasek: It seems that (though we haven't traced it down entirely) the upstart session can't set the cgroup of a job on xenial.
<tedg> Does that ring a bell? Or are we likely barking up the wrong tree.
<tedg> Hmm, I think we might have started it after the session. Will check that.
<slangasek> tedg: I saw a blog from hallyn talking about changes to cgroups handling in xenial, not sure if that could be related?
<hallyn> the cgroup handling changes is only for logins - so could affect upstart user jobs if they are making assumptions about cgroup paths, and could affect unprivileged trusty containers o nxenial
<tedg> Reading the blog post, and I *think* we're okay because we're using freezer... but the path thing doesn't seem to be there.
<tedg> Doesn't the path end up relative?
<hallyn> tedg: it's created relative to the cgroup path of upstart, yes
<SpamapS> marcoceppi: aw, I've missed Jorging. ;)
<marcoceppi> SpamapS: are you in the audience?
<SpamapS> marcoceppi: hi from 3 rows behind you to the right btw. ;)
<tedg> slangasek: hallyn: I added a bug task for bug 1535058 to Upstart
<ubottu> bug 1535058 in upstart (Ubuntu) "applications close instantly when launched from the launcher or dash" [Undecided,New] https://launchpad.net/bugs/1535058
<tedg> Basically it seems that if my Upstart job has "cgroup freezer" it won't start
<tedg> So it's not even back to my code talking to cgmanager, it is an issue with Upstart itself talking to cgmanager.
<hallyn> tedg: thx
<spineau> mitya57: I've made a mistake in pyotherside packaging (forgot to update the path to the test suite for adt-run). I've just fixed it in 1.4.0-3
<spineau> mitya57: I'll need your sponsorship once again to update the version in debian/new and fakesync it to ubuntu
<spineau> mitya57: I tested to be sure the fix works using adt-run on vivid img (http://pastebin.ubuntu.com/14592729/)
<smoser> hey. is this known...
<smoser> http://paste.ubuntu.com/14592856/
<smoser> the key l ines there being:
<smoser> update-initramfs: deferring update (hook will be called later)
<smoser> /bin/cp: cannot stat â/boot/initrd.img-4.3.0-7-genericâ: No such file or directory
<smoser> Failed to copy /boot/initrd.img-4.3.0-7-generic to /boot/initrd.img at /var/lib/dpkg/info/linux-image-4.3.0-7-generic.postinst line 745.
<smoser> anyone else seen that ? i'm seeing it in a chroot with qemu-static, but it seems from those lines fairly straight forward error.
<smoser> update-initramfs got delayed, but the postinst was trying to copy it
<mwhudson> when i run adt-run -U ... --- qemu adt-xenial-amd64-cloud.img the apt-get update fails
<smoser> well, filed that at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536810
<ubottu> Launchpad bug 1536810 in linux (Ubuntu) "kernel install failed /bin/cp: cannot stat â/boot/initrd.img-4.3.0-7-genericâ: No such file or directory" [Undecided,New]
<smoser> mwhudson, yah, i saw apt-get update errors earlier today too.
<smoser> xenial moving target is guaranteed to happen at points.
<smoser> until https://bugs.launchpad.net/launchpad/+bug/1430011 is fixed.
<ubottu> Launchpad bug 1430011 in Launchpad itself "support apt by-hash mirrors" [High,Triaged]
<mwhudson> smoser: nah, this is more fundamental (sorry got distracted)
<mwhudson> W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/restricted/source/Sources  Cannot initiate the connection to 10.0.2.2:3142 (10.0.2.2). - connect (101: Network is unreachable)
<smoser> hm.. yeah.
<mwhudson> i am ... familiar ... with the hash sum mismatch problem
<bdrung> Mirv, reported the requested bug: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1536843
<ubottu> Launchpad bug 1536843 in qtbase-opensource-src (Ubuntu) "vlc refuses to compile against qtbase-opensource-src" [Undecided,New]
#ubuntu-devel 2016-01-22
<SpamapS> marcoceppi: FYI, a few of us are headed to karaoke in Korea Town later this evening.. :)
<SpamapS> marcoceppi: Cafe Brass Monkey. You can pass that along if you want.
<Bluefoxicy> I have no idea what i'd file for a bug for this
<Bluefoxicy> Install Monodevelop, create new ASP.NET MVC project, it doesn't compile out of the box.
<Bluefoxicy> Requires System.Web.Mvc 3.0, which comes installed; this requires a ton of 3.0 libmono stuff, which doesn't come installed.  4 hours of futzing with nuget packages later, still won't work.  :|
<Bluefoxicy> at the very least, a new, blank project should work out of the box.
<pitti> Good morning
<mitya57> spineau, will do now
<spineau> mitya57: Good morning
<mitya57> Good morning!
<mitya57> spineau, also, I'll take the liberty to change the ugly .install.in file to a normal install file using dh-exec
<mitya57> (if you don't mind)
<spineau> mitya57: oh sure, if there's a more compliant way to do the same thing
<mitya57> I'll say more nice rather than more compliant
<mitya57> spineau, and also, set -e as a separate line in debian/rules didn't make any sense :)
<spineau> mitya57: indeed, I'm reading how dh-exec works
<mitya57> spineau, uploaded to both Debian and Ubuntu
<spineau> mitya57: thanks again
<mitya57> Yw!
<flexiondotorg> Can I request that today's patch pilots take a look at sponsoring some Ubuntu MATE requests that we would like for 16.04 Alpha 2.
<flexiondotorg> These are in the queue for Ubuntu MATE: https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1535927 https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1535922 https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1535910
<ubottu> Launchpad bug 1535927 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 16.04.1 new release [debdiff attached]" [Wishlist,New]
<ubottu> Launchpad bug 1535922 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 16.04.1 release [debdiff attached] " [Wishlist,New]
<ubottu> Launchpad bug 1535910 in ubuntu-mate-meta (Ubuntu) "Please update ubuntu-mate-meta for 16.04 Alpha 2" [Low,New]
<Odd_Bloke> apw: Quick kernel SRU/lifecycle question; when we see an SRU for a release kernel, will there also have been an SRU release for the LTS kernels?
<Mirv> flexiondotorg: looking and probably sponsoring the first two, I don't know what needs to be updated in the meta package
<flexiondotorg> Mirv, That's great.
<flexiondotorg> Mirv, Usually someone from foundations updates the meta package.
<Laney> Mirv: download the source package, run ./update, debuild, upload
<Mirv> that sounds easy
<Mirv> ah, it just runs germinate update
<flexiondotorg> Mirv, Yep, that's all that is needed :-)
<Unit193> Mirv: Thanks!
<Mirv> Unit193: you're welcome!
<gj|work> I'm going to set up a LX-Container to run a Desktop based on Trusty. I neary works out of the box, but there is a problem with the user session management: If i log in -- either via GUI or via ssh -- there is no session listed by 'loginctl'. From this, i e.g. can't do actions requirering authorisation via the desktop. Please, how to debug (or solve) this?
<xnox> doko, thank you for fixing gcc on arm64
<ginggs_> doko, yeah thanks! i fired off rebuilds for a couple of things earlier
<cyphermox> good morning!
<mitya57> spineau, ignore the rejected mail please, I've sorted it out with a ftp master
<spineau> mitya57: ok, nice, thank you
<flexiondotorg> Mirv, Thanks for your sponsoring :-)
<spineau> cyphermox: hello, do you know who can do the universe->main migration for pyotherside? I'd like to unblock the xenial builds
<spineau> cyphermox: mitya57 sponsored a new version this morning that passed all the tests. The package is ready for a copy
<cyphermox> spineau: ask in #ubuntu-release :)
<spineau> cyphermox: ok thanks
<Mirv> spineau_afk: you'll need to go through this process https://wiki.ubuntu.com/MainInclusionProcess
<Mirv> spineau_afk: ah, I only didn't find a bug because it was already handled, great :)
<dasjoe> cjwatson: re: grub2 + zfs: thank you!
<cjwatson> dasjoe: np, sorry it took a while
<dasjoe> cjwatson: no worries, I'm happy the patches will be in 16.04 so I'll be able to upgrade my servers' rpools :)
<LocutusOfBorg> xnox, I just uploaded re2c that should already have the Big Endian fix, can you please "syncpackage -s costamagnagianfranco -V 0.16-1 -f re2c when possible?
<spineau> Mirv: indeed, Colin took care of it while I was lunching :)
<Odd_Bloke> pitti: Hello! I'm debugging a problem we're seeing in some (partner-specific) cloud images, and have a couple of questions: Was network interface renaming enabled in wily?  And what are the possible (sensible ^_^) ways that it could be disabled?
<Odd_Bloke> pitti: (A little background: two wily images in different clouds, one is renaming (and therefore breaking), the other is not renaming; I'm trying to work out why renaming is happening in one and not the other)
<pitti> Odd_Bloke: we switched to ifnames in wily, yes; /usr/share/doc/udev/README.Debian.gz shows to ways how to disable that (one kernel CLI based, one config file based)
<pitti> Odd_Bloke: was this an upgrade? we don't change the  naming schema on upgrades, if there's an existing 70-network-names.rules that'll continue to work
<pitti> mid-term that doesn't solve the problem, though, and we should stop hardcoding "eth0" in images (that leads to actual problems)
<Odd_Bloke> pitti: No, this is on new instances; and, yeah, we need to work out how we're going to get rid of eth0 stuff.
<rharper> Odd_Bloke: one possibility for the different behavior is the type of nic being used;  at some point systemd didn't recognize virtio devices as "Stable" and would not attempt to apply naming rules (ens3); but things like emulated e1000 (qemu default nic) would get renamed;
<rharper> Odd_Bloke: at some version systemd did include virtio in the nic renaming
<Odd_Bloke> rharper: Aha, really useful note; thanks!
<rharper> Odd_Bloke: https://bugs.launchpad.net/ubuntu/+bug/1483457  may have some other useful bits of info as well
<ubottu> Launchpad bug 1483457 in cloud-init (Ubuntu) "non-virtio devices get named with systemd "predictable network interface names"" [Critical,New]
<rharper> rbasak: I've got a new strongswan package merge;  it still needs the upgrade path changes but I would like you to take a look at what I've got so far, if that's ok;
<mitya57> Laney, new keyring uploaded (to Debian)
<mitya57> Looking at autopilot-legacy now
<Laney> mitya57: ssssssssweeeeeeeeeeetttttttttt
<kickinz1> rbasak, ping
<mitya57> Laney, https://github.com/sphinx-doc/sphinx/pull/2261 fixes the first issue, but now I get another one
<mitya57> Ah, no, that's because of missing build-dep, so after applying that PR it works
<mitya57> Laney, I won't add it in Debian until upstream ACKs it, but feel free to cherry-pick that into Ubuntu in the mean time
<elopio> doko: ping. I was told you could give us a hand here: https://bugs.launchpad.net/ubuntu/+source/make-dfsg/+bug/1536727
<ubottu> Launchpad bug 1536727 in make-dfsg (Ubuntu) "make crashes in xenial lxc" [Undecided,Confirmed]
<rbasak> slangasek, tdaitx: what's the status of the squid3 merge, please? It's been months! Is this going to get done imminently, or do I need to take it back to make sure it gets done in time for feature freeze?
<slangasek> rbasak: I think you should take it back, I don't think we're going to have
<slangasek> rbasak: time to get to it
<slangasek> rbasak: sorry!
<rbasak> slangasek: OK, thanks.
<rbasak> tdaitx: please note I'm taking the squid3 merge back.
<Laney> mitya57: thanks
<Laney> what missing build-dep?
<Laney> that's basically the same patch that I haxed up locally for testing and would have PRed if you didn't respond :P
<pitti> kirkland: heh, on snappy (or any r/o root) you don't have much choice about /tmp being a tmpfs :)
<pitti> kirkland: interesting point/data about /tmp being slow on cloud deployments, I wasn't aware that this is that bad
<kirkland> pitti: well, usually the storage in the cloud is remote to the machine hosting the vm
<kirkland> pitti: it's typically a huge disk array or san
<pitti> RLY
<kirkland> pitti: sure, "EBS" is exactly that
<kirkland> pitti: same with OpenStack
<pitti> kirkland: so, more tmpfs then :)
<kirkland> pitti: azure's I/O is absolutely horribly embarrassingly bad
<kirkland> pitti: almost unusable
<pitti> kirkland: wow, how do people use DBs and high-load webapps there?
<kirkland> pitti: they usually pay extra for expensive ssd-backed instances
<kirkland> pitti: or instances that have *local* ssd storage, in an ephemeral volume
<kirkland> pitti: however, that volume is usually not protected against failure
<kirkland> pitti: it's "ephemeral"
<rbasak> rharper: sure, I'll review. Not sure I'll get a chance today though. Is your tree in Launchpad?
<Odd_Bloke> (Whilst cursing the CTO who chose Azure ^_^)
<rharper> rbasak: yes, it's updated
<rbasak> Thanks
<rharper> the "merge" branch is origin/new/debian_copy_in_old/debian
<rbasak> kirkland: if it's particularly needed for azure, could we use vendor-data there to enable it on a per-cloud basis where it makes sense?
<pitti> kirkland: so you said "[treshold] will be 3 GB", so that's planned/done now?
<rbasak> kirkland: a more gradual switch like that would be less scary
<rharper> and I've placed a build of the current merge in my ppa (  ppa:raharper/merges )
<rbasak> rharper: ack
<rharper> rbasak: I'm preparing a note to ubuntu-devel for review and comments;  I have some remaining todos, specifically the upgrade path
<rbasak> rharper: sounds good!
<rbasak> rharper: BTW, I'm gaining some experience reviewing a bunch of people picking up my workflow at once.
<kirkland> pitti: well, "would be" according to the rfc/proposal
<rharper> rbasak:  =)
<rbasak> rharper: I'm starting to think an intermediate review of the "logical" stage might be a good idea. It sounds like you're well past that stage this time though.
<rharper> rbasak: I think the logical stage is a *great* place for review
<rharper> that's exactly where experience can help with how much to break up or leave
<rharper> I am past that but it's definitely the right place for sanity check before rebase
<rbasak> rharper: right, but also because if there's any confusion it can be cleared up before rebasing on new/debian to avoid wasted effort.
<rharper> =)
<rharper> yes
<bdmurray> pitti: I did get some work done on the email functionality but it is incomplete / untested.
<rharper> I have to say there were many times that I thought I had lost it all but having everything in git with tags/branches made recovering *much* easier
 * rbasak wonders if he can unblock others by getting others doing this to sanity check each other
<rharper> rbasak:  so thanks! =)
<rbasak> rharper: np :)
<rharper> rbasak: personally the logical stage is very easy to review with the changelog, so I think it makes a great place to do peer review
<rbasak> Note that a tag is effectively a backup in git, unless you destroy your git repo some more direct way. You can always reset a branch back to a tag.
<rharper> yep
<pitti> bdmurray: oh, great! btw, I realized that the place we discussed yesterday might not be the best -- we must remember that we sent the mail, not do it every time we run britney
<rbasak> Also, even if you forget to tag, the reflog can help undo as well; it's just a bit more effort to figure out the exact point you want to restore to.
<rharper> I also backed up my git/gitwd at various stages as well =)
<pitti> bdmurray: so shuffling this stuff around and sending the mail when downloading a new result would be better
<bdmurray> pitti: where does downloading a new result happen?
<pitti> bdmurray: "def fetch_one_result" in autopkgest.py
<pitti> bdmurray: that's the only place that adds to self.test_results, the other parts just read it (or init it from the results.cache file)
<tsimonq2> hi, I am trying to use backportpackage for the sake of learning how to use it, and I keep getting backportpackage: Error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
<tsimonq2> my OpenPGP key is in LP
<tsimonq2> so idk what the problem is
<cjwatson> that has nothing to do with your key - for some reason your system is unable to verify LP's SSL certificate
<tsimonq2> cjwatson: how do I diagnose this?
<cjwatson> do you have full output?
<cjwatson> including the command you're running
<tsimonq2> backportpackage -u ppa:tsimonq2/backports -s xenial -d precise ccid
<tsimonq2> backportpackage: Error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
<cjwatson> any HTTP proxy in use in your environment?
<tsimonq2> nope
<cjwatson> what release is the host system?
<tsimonq2> xenia;
<cjwatson> ok, I would suggest trying with something simpler such as lp-shell (in the lptools package), and probably drill down with things like strace from there
<tsimonq2> cjwatson: so I installed lptools, what do you suggest I do now?
<cjwatson> see if you can reproduce the same thing with lp-shell, and if so, drill down with things like strace
<cjwatson> don't have time to advise further right now sorry
<tsimonq2> all ok
<tsimonq2> *ahh
<tsimonq2> thanks
<cjwatson> the LP API itself is working fine
<tsimonq2> httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
<tsimonq2> same error
 * tsimonq2 uses the Python shell and imports the launchpadlib library
<cjwatson> lp-shell is basically just that
<tsimonq2> hmm http://pastebin.ubuntu.com/14598694/
<tsimonq2> same error
<cjwatson> right, the possibilities are basically that you don't have the right system certificates installed, or that there's some network corruption between you and launchpad.net (in which I include both random data corruption and "transparent" proxies), or that somebody is trying to man-in-the-middle your HTTPS connections
<cjwatson> perhaps visiting https://api.launchpad.net/ in a browser will be more informative (or perhaps not)
<cjwatson> browsers have tools to report on certificates, as does e.g. the openssl command-line tool
<tsimonq2> cjwatson: what page should I look at for an example?
<cjwatson> tsimonq2: unimportant
<tsimonq2> cjwatson: what am I looking for? this is a normal output...
<cjwatson> tsimonq2: browsers typically let you look at the security certificates in use for any given page, and you could use that to help work out why Python apparently isn't picking up the same certificates
<cjwatson> it's a debugging exercise and I don't know exactly what the problem is, so I cannot walk you through it
<tsimonq2> cjwatson: I'm not by any means literate in this, what am I supposed to look for?
<cjwatson> please could somebody else help tsimonq2?
<cjwatson> like I say I don't have the time at the moment
<xnox> tsimonq2, i find it very odd why you hae launchpadlib installed globally from pacakging, yet httplib2 in /usr/local
<xnox> tsimonq2, i would expect for you to use httplib2 from /usr/lib i.e. one provided on your system.
<cjwatson> ah good point, pretty sure the system httplib2 carries a patch to use system certificates
<tsimonq2> xnox: so what do I need to do?
<xnox> tsimonq2, why do you have python packages in /usr/local? it's quite a bad idea. as that affects everything on the system. Either use virtualenv, or per user python.
<tsimonq2> thanks for your help cjwatson :)
<tsimonq2> xnox: I didn't know that, how do I fix it? :)
<xnox> tsimonq2, i would try $ sudo mkdir -p /var/tmp/backup; sudo mv /usr/local/lib/python2.7 /var/tmp/backup/usr-local-python2.7
<cjwatson> I would instead try sudo pip uninstall httplib2
<cjwatson> though it may take out other stuff you've locally installed there
<xnox> tsimonq2, assuming you do know what you have in /usr/local....
<xnox> right.
<cjwatson> but that will have the useful effect of telling you what you need to fix to use a virtualenv instead ...
<xnox> cjwatson, btw - i dream to kill /usr/local support by default. there are more people who break their systems with it, than those who really know how to use it. and most people don't need /usr/local at all, given the fancy pants deployment things of the modern day.
<tsimonq2> ooh ooh ooh thanks xnox, that fixed it :)
<xnox> tsimonq2, well we don't know what we broke =) andy why you have things installed in urs/local. if you run something and a python thing is missing, try installing things with apt first, rather than pip.
<tsimonq2> ahh ok
<tsimonq2> and now it should be in my ppa, yay :) https://launchpad.net/~tsimonq2/+archive/ubuntu/backports
<kickinz1> rbasak, ntp logical delta against old/ubuntu is: logical/1_4.2.6.p5+dfsg-3ubuntu9
<kickinz1> rbasak, new merge proposal is: logical/4.2.8p4+dfsg-3ubuntu1
<kickinz1> rbasak, hold-on
<dannf> cjwatson: fyi : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009/comments/28
<ubottu> Launchpad bug 1533009 in linux (Ubuntu) "arm64: "unsupported RELA relocation"" [High,Triaged]
<dannf> cjwatson: i saw your grub upload, just noting that because it'll hit GCC6 as well, but likely needing a different flag
<mitya57>  Laney: thanks for the sphinx upload! And btw the pr is now merged upstream.
<cjwatson> dannf: phcoder implemented the relocations, so I can probably drop it once I've tested that that's enough
<cjwatson> (which I haven't yet)
<RAOF> What would people feel about linking Mir using the gold linker?
<coreycb`> mitya57, is sphinx working ok for you?  I'm getting a 'no such file or directory' error.
<coreycb`> I'm not sure if it's on my end or something with sphinx
<coreycb`> nevermind, I think it's on my end
#ubuntu-devel 2016-01-23
<kickinz1> rbasak, old logical: logical/4.2.6.p5+dfsg-3ubuntu9
<kickinz1> rbasak, new logical: logical/4.2.8p4+dfsg-3
<Ionic> so I'm trying to build using this recipe https://code.launchpad.net/~ionic/+recipe/reprepro-daily from lp:~ionic/ubuntu/precise/reprepro/precise, but after pushing my commit, launchpad is failing to build the package due to... changes to the files I have patched? what have I been doing wrong? build log: https://launchpadlibrarian.net/235005886/buildlog.txt.gz
<Ionic> (that is, yes, I expect these files to be changed, obviously)
<Ionic> I probably could have been added this as a quilt patch, but I don't see the cloned repository doing this either for any commit, instead they just merge upstream changes (and maybe rebuild the package)
<cjwatson> Ionic: you do need to use a quilt patch, since debian/source/format says "3.0 (quilt)".  The reason you're not seeing this in the branch you started from is, I expect, that it has the upstream .orig.tar.gz available
<Ionic> yeah, okay, I'll revert and redo this via quilt
<LocutusOfBorg> hi can anybody please retry libupnp ppc64el autopkgtest (vlc)?
<juliank> tkamppeter: Is sys5ippprinter tested? it seems to produce severe heap corruption in set_option_in_str() for me (option string: https://paste.debian.net/367407/), causing it to die with a huge error. Note that this option string was created by a patched cups-browsed where I whitelisted image/urf - because I'd like to get AirPrint printers work and there was a (I thought) reasonably looking patch at http://forums.openprinting.org/read.php?19,1
<juliank> 4900,14900 to add URF support [the patch is not applied to sys5ippprinter.c, though, it's the normal sys5ippprinter]
<juliank> Given that the printer advertises application/vnd.hp-PCL, it should probably take the PCL paths in the code
<juliank> Apparently the strong is too long or something, if I remove "sides=two-sided-long-edge [...]" it works
<tkamppeter> juliank, hi
<juliank> oh hi
<juliank> tkamppeter: ^ WRT that option setting issue; I found out that it seems to vary based on the string length, but in any case, something seems off.
<juliank> For my convenience, I reported it in the Debian BTS, but that seems offline right now, so a copy is at https://paste.debian.net/367446/ for now
<tkamppeter> juliank, the sys5ippprinter is rather new and so not tested so much. So it is possible that there are still bugs in it.
<tkamppeter> juliank, please report bugs on http://bugs.linuxfoundation.org/, product OpenPrinting component cups-filters.
<tkamppeter> juliank, there you can also report a feature request for AirPrint support.
<tkamppeter> juliank, if you have an AirPrint printer and you are able to do testing with it I would be happy if you could refine and debug all AirPrint/URF patches so that I can adopt them.
<juliank> tkamppeter: I do have an AirPrint printer. The patch/bzr bundle on the forum is broken though, at least missing the end of main(), and BufferWrite() calls which should be bufferWrite() - so it was not really tested.
<juliank> Not sure about the discovery part, it *seems* to create grayscale printers
<juliank> tkamppeter: Whose idea was it to manage patches in the forum, BTW? http://www.linuxfoundation.org/collaborate/workgroups/openprinting/database/instructionsforcontributors says "If you do not have write access to our Bazaar repositories, post the file resulting from step 10 or 11 on our forums or put it into your web space and post a link to it. "
<tkamppeter> juliank, can you contact the poster in the forum, perhaps he can complete/correct his patch.
<juliank> I guess I can send him an email, I'm not registered in the forum
<tkamppeter> juliank, I think this should be changed, as of now I would prefer a feature request in Bugzilla.
<tkamppeter> juliank, would be great if you could do so.
<juliank> sent
<tkamppeter> juliank, thank you very much.
<juliank> tkamppeter: AirPrint support would basically kill the need for vendor/specific drivers for most modern wifi-enabled printers for most users :)
<tkamppeter> juliank, this would be great, there is also another method which is completely based on free standards, it is IPP Everywhere, but this standard was only completed right now and printers still have to appear on the market. This is the standard I am supporting currently. But any additional method is welcome, AirPrint is wide-spread, only disadvantage is that it is proprietary.
<juliank> AirPrint also requires multi-function devices to advertise HTTP based scanning, I'm thinking about finding out how that works and writing a SANE plugin for it.
<tkamppeter> juliank, and the great goal of current OpenPrinting efforts is to get driverless printing, a printer should be connected as eaily as an USB stick.
<tkamppeter> juliank, great.
<tkamppeter> juliank, are you a student?
<juliank> tkamppeter: yes, in my third master semester (out of 4) - 9th overall if you count the bachelor.
 * juliank studies computer science in marburg
<juliank> tkamppeter: why do you ask?
<tkamppeter> juliank, I am asking because I participate in the Google Summer of Code and would accept you for doing one of your projects, for example the scanner stuff as a GSoC project. With this you can earn USD 5000 on it.
<juliank> tkamppeter: While this sounds nice, I have master thesis to write this summer (roughly April-October +/- 1 month)
<juliank> I'm not sure if it is sensible to merge a GSoC project into that time frame
 * juliank sort of fears bureaucracy 
<tkamppeter> juliank, then better not to do it as GSoC project.
<tkamppeter> juliank, but independent of this I would appreciate if you succeed with the AirPrint printer/scanner integration.
<juliank> I'd appreciate it as well :)
<juliank> tkamppeter: Do you happen to be German (or -ish) as well
<juliank> ?
 * juliank being curious, because most people he does stuff with happen to be German or German-speaking
<tkamppeter> Yes, I am German.
<juliank> :)
<tkamppeter> juliank, it is possible that in filter/rastertourf.c of the patch from the forum only the last closing '}' of the main() function is missing. Please check.
<juliank> Well, should be "return 0; }" - depending on the C version, the return may not be strictly needed, though.
<juliank> (IIRC)
<juliank> But still, it does call writeBuffer() in places, but the function is WriteBuffer()
<tkamppeter> juliank, I think in main() it is needed, as it is "int main()". The value is the exit status of the program.
<tkamppeter> juliank, this looks really like a never tested.
<juliank> It looks like he copied it over or something, then changed the function name to start with an uppercase for cleanup but forgot to change call sites before committing
<juliank> tkamppeter: The thing with return is that C99 has an implicit "return 0;" at the end of control flow of main()
<tkamppeter> juliank, if the author of the patch does not answer, simply correct these two issues and try whather it builds.
<juliank> tkamppeter: I did, and it builds.
<tkamppeter> juliank, can you then check whether you can actually print with it?
<juliank> No success yet, but it may be the printer acting up
<juliank> it's acting a bit weird right now
<juliank> The scanning thing is cool. From what I can tell, Apple just adopted HP's eSCL protocol.
<juliank> Which means that it would make sense to (just) rip that out of hplip and into SANE
 * juliank wants to add that he does not like the implicit-return rule of C99/C11/C++11
<tkamppeter> juliank, I am back.
<tkamppeter> juliank, good idea, you should try that with ripping the scanning stuff out of HPLIP.
<juliank> Will see
 * juliank needs some sleep now
#ubuntu-devel 2016-01-24
<MrBIOS> hi there, are there any Canonical folks here at SCALE still?
<wjx> I get package iso-codes_3.57-1_all.deb Size mismatch error when trying to create build target in SDK,  , Does  anyone know this problem?
<ginggs_> doko: hi, i've uploaded aster, i think petsc should migrate now
<LocutusOfBorg> autopkgtest for vlc 2.2.1-5: amd64: Pass, armhf: Pass, i386: Pass, ppc64el: Regression, s390x: Pass
<LocutusOfBorg> can anybody please retry ppc64el ^^^ libupnc
<Ionic> hmm... I don't understand from what branch a package is coming from
<Ionic> if I take a look at https://launchpad.net/ubuntu/+source/reprepro, I see a precise package from 2014-05-20 with version 4.8.2-1ubuntu0.1
<Ionic> however, switching to the "code" tab and examining the lp:ubuntu/precise/reprepro branch on https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/reprepro/precise I can only see the latest change being a rebuild on 2012-03-16
<Ionic> so that seems to be the wrong branch to clone, but what is the correct one?
<cjwatson> there may well not be one.  use pull-lp-source
<cjwatson> the automatic importer thing is falling apart and due a replacement
<Ionic> urgh, okay...
<Ionic> let's see what pull-lp-source actually is
<cjwatson> we plan to replace it with a thing based on git but still have more pieces to write
<cjwatson> pull-lp-source just downloads the source package, but has suite lookup and such so that you don't have to work out versions manually and so that it doesn't necessarily have to correspond with what's in your apt cache
<Ionic> ah, that's a program
<Ionic> that probably downloaded the dpkg source... well, whatever, seems there is no corresponding bazaar branch
<cjwatson> right, either synthesise it yourself or make do without, I'm afraid
<cjwatson> the git import should be more reliable once we have that going, as it's fundamentally harder to get it into a state where it doesn't want to proceed (but we don't have it scheduled yet - it'll be months rather than weeks)
<Ionic> I can synthesize it myself
<Ionic> it's just some metadata changes and a quilt patch
<Ionic> do you plan to switch from bzr to git?
<cjwatson> Ionic: as I said above, that's the plan for the package imports, yes
<Ionic> but not for general development?
<cjwatson> Ionic: likely that too, but organically over time rather than a big flag day
<cjwatson> Ionic: various bits and pieces have already switched
<cjwatson> Ionic: it won't be an "as of June everyone must switch away from bzr" kind of thing; I wouldn't ever expect that
<Ionic> huh, okay, just asking because I personally prefer git and always have a hard time mapping git concepts back to bzr whenever I use launchpad
<cjwatson> Ionic: well, whenever you use bzr on Launchpad as opposed to git on Launchpad, you mean :-)
<cjwatson> Ionic: I prefer git nowadays for my own projects too
<Ionic> I didn't even *know* I can use git on launchpad
<Ionic> although I do use git-imports, so... yeah, would make sense that these stay git archives and are not implicitly converted to bzr archive...
<cjwatson> Ionic: we added git support to LP last year
<cjwatson> Ionic: git-to-git imports are on the list, hopefully this year
<Ionic> great to know, thanks!
<cjwatson> git recipes will be available to beta testers next week
<cjwatson> so we're gradually ticking things off
<Ionic> I welcome the change :)
<cjwatson> Ionic: https://help.launchpad.net/Code/Git FYI
<doko> ginggs_, still ftbfs on s390x ... https://launchpadlibrarian.net/235090139/buildlog_ubuntu-xenial-s390x.aster_11.5.0+dfsg2-3ubuntu2.1_BUILDING.txt.gz  unconditionally linking against -lscalapack
<ginggs_> doko, yeah it's never built on s390x in debian either, i don't know what that's about :(
<lfaraone> cyphermox: to fix #1273201, you removed bridge_ignore_without_connections.patch from n-m. is it now expected that e.g. lxcbr0 shows up in NetworkManager now?
<lfaraone> bug #1273201
<ubottu> bug 1273201 in network-manager (Ubuntu) "bridge_ignore_without_connections.patch breaks NM created bridge at boot" [High,Fix released] https://launchpad.net/bugs/1273201
<robert_ancell> ximion, Do you have any plans to split the gnome-software package into subpackages for plugins? Asking mostly because it seems a waste of time to put limba into main
<ximion> robert_ancell: I currently want to explicitly avoid doing that, since it will result in some people having fwupd support, some have Limba support and some have xdg-app support or any combination of these...
<ximion> those different featuresets would result in making it pretty hard to rely on stuff
<robert_ancell> ximion, yeah, it wasn't clear to me how you'd divide them up either.
<ximion> robert_ancell: I thought about this a bit, since I saw that issue coming, and decided that I would like to avoid splitting out plugins - GS not knowing about modules can be a prblem on it's own
<ximion> (GS makes the components, Limba, fwupd and soon xdg-app visible, if it starts without them users will wonder why GS is not showing the app they just installed, until they notice that gnome-software-plugin-xdg-app is missing)
<ximion> also, which plugins should be split out is another complicated question
<ximion> robert_ancell: btw, you might want to put appstream in main too ;-)
<robert_ancell> ximion, yep, will do that
<ximion> for that thing I also though about creating some smaller binary to provide the minimal functionality needed, but decided against that since that would have resulted in lots of C code duplication, slow Python code or other dumb reimplementations of existing stuff, and I really wanted this bit to be fast (every apt update runs it)
<ximion> robert_ancell: will you be at FOSDEM as well?
<robert_ancell> ximion, not at FOSDEM
<ximion> hmm, would've been cool to meet you there
<robert_ancell> yeah, I don't do FOSDEM because too far for a short trip
<ximion> btw, having Limba in main would of course be awesome, and in case you consider it I would be happy to help (you don't need to install it by default, of course ^^) - otherwise it would be cool to have the plugin in unstable, at least
<ximion> we will have an Ubuntu-centric AppStream meeting after FOSDEM
<robert_ancell> Nice!
<ximion> so I thought you might join that :P
<robert_ancell> I'll do the MIR for limba, just wondering if we'll get any pushback from security etc.
<ximion> btw, thanks for the ratings&reviews work! I already love it for finally putting the star-ratings to good use, I never liked the way hughsie comouted them
<ximion> also, it would be nice to maybe make the protocol for ratings & reviws part of the AppStream specification, if people can set up the server by themselves and if it is not too Ubuntu-specific
<robert_ancell> ximion, I don't know much about the details of appstream but we should certianly make it work for other distros.
<robert_ancell> The server code is open and should in theory be runnable by other distros (and it can also have reviews from different sources in the same server).
<ximion> robert_ancell: Limba has a suid binary, but that one got a code review last year in January (it changed a lot though in the past year, but the stuff it does before dropping privileges is still rigurously checked)
<dobey> how is g-s getting the u1 token now?
<ximion> when I have some more time, I would like to make it available in AppStream - putting it in there would essentially mean that any distribution is encouraged to implement it
<ximion> robert_ancell: speaking of Limba and xdg-app, any plans for a Snappy backend in GS?
<ximion> Richard, Alexander and I put quite some work into GS and the AppStream spec to make these bundling tools integrate well ;-)
<robert_ancell> dobey, attente updated it to use the sso service
<robert_ancell> ximion, I'm playing around with Snappy
<dobey> robert_ancell: a token from sso is required to submit reviews. i'm just curious about the client side and how it works
<robert_ancell> dobey, you can see it on the wip/rancell/reviews-3-18 branch on GNOME Software
<robert_ancell> dobey, reviews welcome :)
<dobey> robert_ancell: i take it that is something in a git somewhere?
<robert_ancell> dobey, GNOME Git
<dobey> becuase... https://launchpad.net/~rancell is not you
<robert_ancell> yeah, I'm robert-ancell on Launchpad
<ximion> robert_ancell: nice! I still need to work with it - conceptually it seems to be similar to Limba, but without resource-sharing but with the ability to build whole OSes from Snappy packages
<dobey> robert_ancell: why the complicated dbus bits?
<robert_ancell> dobey, which bits?
<dobey> robert_ancell: for sso
<ximion> btw, you likely want this bug fixed for Xenial: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808993 - since it requires a few bigger changes in asglib, I poke hughsie from time to time to fix it or allow me to change it :P
<ubottu> Debian bug 808993 in appstream-glib "gnome-software: Screenshots not loading" [Normal,Open]
<dobey> robert_ancell: or is it still just using ubuntu-sso-client for the actual login stuff?
<robert_ancell> dobey, just for getting the token
<dobey> robert_ancell: ah. is that a temporary thing? i understood the plan was to also replace ubuntu-sso-client
<robert_ancell> dobey, not sure, attente got that bit working
<dobey> ok
<dobey> well i hope it's temporary :)
<robert_ancell> dobey, so what is the correct way to get a token now?
<dobey> robert_ancell: my understanding from UOS was that someone was going to write something to replace u-sso-client, using the newer REST API, for the gnome-software integration; ubuntu-sso-client isn't "incorrect" as it were, but it is using the older API, which I think the ols team would like to drop at some point (but not sure how feasible that is at this point anyway), and it is python 2.x code.
<ximion> robert_ancell: if you need any information/help on AppStream, Limba and/or xdg-app or plugin stuff, let me know :)
<robert_ancell> ximion, will do, thanks!
<ximion> (for gnome-software itself, hughsie is the ultimate authority)
#ubuntu-devel 2017-01-16
<mbiebl> too late for the release team
<Son_Goku> mbiebl: what, why?
<Son_Goku> the hard freeze isn't until next month
<mwhudson> hm
<mwhudson> can i use autopkgtest to build a package and then run some other packages tests against the built package?
<mwhudson> i guess i can do it by hand easily enough
<Son_Goku> :'(
<ginggs> is it known that merges.ubuntu.com hasn't updated since 2017-01-11?
<tsdgeos> Mirv: no qtpurchasing updte?
<Mirv> tsdgeos: it was rebuilt
<tsdgeos> Mirv: ah, but still 5.6?
<Mirv> if a new version is wanted, I'd guess the people involved in payments would like to land + test such
<Mirv> I can help with packaging of course
<tsdgeos> ok
<tsdgeos> was just wondering :)
<xnox> infinity, yes it's just a note "your vps is sucks". Good to know that you don't refuse these things.
<Odd_Bloke> Can I find if there are Ubuntu/Launchpad bugs corresponding to particular Debian bug numbers?
<pitti> Odd_Bloke: yes, somethign like https://bugs.launchpad.net/bugs/bugtrackers/debian-bts/1234
<ubottu> Launchpad bug 1234 in Launchpad itself "Gina is an unmaintainable mess of command line options, environment variables and shell scripts" [Medium,Fix released]
<pitti> but I'm not sure about the "debian-bts" name
<pitti> Odd_Bloke: oh, it's /debbugs (see https://launchpad.net/bugs/bugtrackers/debbugs)
<pitti> Odd_Bloke: so e. g. https://launchpad.net/bugs/bugtrackers/debbugs/740749 redirects you to the LP bug which is linked to that debian bug
<ubottu> Launchpad bug 626798 in aptdaemon (Ubuntu Natty) "duplicate for #740749 update-manager crashed with DBusException in _run()" [High,Fix released]
<Odd_Bloke> pitti: Excellent, thank you!
<cjwatson> ginggs: yes, I've been getting cron mail about that, I need to get it past the current thing it's crashing on
<ginggs> cjwatson: thanks!
<_SleePer_> hello everybody, i am using test drive to do a test but it give me an error when i use the kvm for virtualization. Give me that "failed executing command: `/usr/bin/qemu-img create-f qcow2/home/user/.cache/testdrive/img/testdrive-disk-kK3Ihy.img Oyher...G`
<_SleePer_> can anybody help me?
<cpaelzer> _SleePer_: did that loose some spaces when copy&pasting or might that be the issue?
<cpaelzer> create-f => create -f
<cpaelzer> qcow2/home => qcow2 /home
<cpaelzer> maybe more
<_SleePer_> that loose some spaces when i copy and paste
<_SleePer_> did you now what is that error cpaelzer?
<cpaelzer> _SleePer_: well it doesn't even list on what it fails
<cpaelzer> _SleePer_: it only tells you the command it fails on
<cpaelzer> _SleePer_: if you have more detailed logs check those, if not i'd hope test-drive leaves you the artifacts around and you can rerun that command to see what is happening
<_SleePer_> and how can i solve the error?
<cpaelzer> _SleePer_: sorry the message you posted doesn't contain the error, so I can't even guess
<cpaelzer> _SleePer_: this is like "mv fails for me - what is the reason"
<cpaelzer> _SleePer_: well one would need the actual error - like file not found, or whatever applies
<_SleePer_> ok ok, i will "investing" thank you very much
<cpaelzer> _SleePer_: all I can tell you atm is that I've used qemu-img this morning and it worked, so it is not generally broken
<cpaelzer> _SleePer_: please come back if you found and more detail and we can help interpreting that
<_SleePer_> ok, i instal qemu-utils a 1 hour ago, can i did a bad instalation?
<cpaelzer> _SleePer_: there is not much that can be done wrong, if you want to check the integrity of the files belonging to a package you can use "dpkg --verify"
<cpaelzer> _SleePer_: but I'd very much guess that the way testdrive calls it causes an issue, so try to isolate that
<_SleePer_> ok, i will run that
<cpaelzer> _SleePer_: either for its error message, or to reproduce
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<cpaelzer> hey co-devs - what is the most easy way to check for component mismatches?
<cpaelzer> I'm pretty sure the merge I'm on has a lot
<cpaelzer> can I run anything against e.g. the buildlog or the created debs/source files?
<cpaelzer> I mean I can massage the buildlog to hold a list of depends and recommends and check them all in a not-too complex script - or push stuff to a ppa and throw reverse-depends at it, but I'd expect there is a better way already
<cjwatson> check-mir(1)
<cjwatson> (though it probably needs to be updated to stop caring about build-deps)
<cpaelzer> thank you cjwatson
<rbasak> cpaelzer: also, if you have a test build, you can grep for universe in the build log.
<rbasak> I'm not sure that's guaranteed to work in every case, but it works well enough for me :)
<cjwatson> The build log will only tell you about build-dependencies, which are precisely those not required to be MIRed nowadays ...
<cjwatson> You'd want the install log instead if you were taking that approach
<caribou> barry: did you notice that your upload for LP: #1647031 is held in -proposed ?
<ubottu> Launchpad bug 1647031 in systemd (Ubuntu) "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [High,Triaged] https://launchpad.net/bugs/1647031
<barry> caribou: yep.  it's blocked on some systemd regressions which i've been unable to reproduce.  looks like it's even works for systemd 232-8.  would love to get some help with that, but i will be looking at it again this week
<barry> (the systemd 'upstream' autopkgtest is failing)
<caribou> barry: I'll try to rerun the DEP8 tests locally
<barry> caribou: cool.  ping me with any info.  tbh, i've been running network-manager out of my own ppa just so schroots work :/
<cpaelzer> ok rbasak, that is what I thought before - combined with the tool cjwatsonrecommended that should be good
<cpaelzer> rbasak: just from the changelog I see quite a lot coming my way and since humans are bad at catchign the tail end of dependency trees I want tools
<caribou> barry: I stop systemd-resolved everytime I reboot my laptop & manually change the nameserver entry; Maybe I should test your PPA
<barry> caribou: https://launchpad.net/~barry/+archive/ubuntu/experimental
<caribou> barry: tnks
<barry> been working great for me
<caribou> barry: that's the same bits as the ones in -proposed ?
<barry> caribou: yep
<barry> only difference is d/changelog
<rbasak> cjwatson: ah. Good point.
<cjwatson> ginggs: should be up to date again now
<ginggs> cjwatson: Generated at 2017-01-16 18:16:44 UTC. \o/
#ubuntu-devel 2017-01-17
<piet> chrisccoulson: could you perhaps take a look at this security issue concerning Firejail?
<piet> https://bugs.launchpad.net/ubuntu/xenial/+source/firejail/+bug/1655136
<ubottu> Launchpad bug 1655136 in firejail (Ubuntu Xenial) "Multiple CVEs in xenial" [High,In progress]
<piet> A fix has been provided by Reiner Herrmann, but it needs to be uploaded by a member of the Ubuntu Security Team.
<piet> Would you perhaps want to do that?
<chrisccoulson> piet, sure, will take a look
<piet> chrisccoulson: thanks!
<Dmitrii-Sh> Hi guys. Could anybody from the SRU team take a look at this one? https://bugs.launchpad.net/ubuntu/+source/barbican/+bug/1570356
<ubottu> Launchpad bug 1570356 in barbican (Ubuntu) "unable to load plugins in Centos" [High,Triaged]
<sil2100> Dmitrii-Sh: will try taking a look at it
<Dmitrii-Sh> sil2100: thx
<sil2100> Laney: hey! Could you take a look at http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#dbus ? There are libnih tests there that are infinitely "Test in progress" (even though I re-run them explicitly with our tools)
<Laney> sil2100: It's blacklisted https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/worker-config-production/worker.conf
<Laney> also see https://bugs.launchpad.net/auto-package-testing/+bug/1579090
<ubottu> Launchpad bug 1579090 in Auto Package Testing "When a test is blacklisted, mark it as a failure" [Medium,Triaged]
<sil2100> Laney: oh, ok, so I should probably just ignore those being in progress, thanks!
<mdeslaur> infinity: meeting?
<xnox> barry, whos responsibility is it to fix ADT tests regressions for the SRU uploads?
<xnox> (as pointed out on pending-sru report)
<tjaalton> the new systemd-resolve thingy isn't too happy to work with my home dns, although it shows the server as listed but can't find any machines
<tjaalton> Host eldon not found: 2(SERVFAIL)
<seb128> tjaalton, check the bugs reported on https://bugs.launchpad.net/ubuntu/+source/systemd/+bugs?field.tag=resolved
<tjaalton> seb128: thanks, found it
<seb128> which one is it?
<tjaalton> not sure actually
<tjaalton> yeah it's #1647031
<tjaalton> updating n-m fixed it
<seb128> good
<tjaalton> it's been in proposed for ten days though?
<tjaalton> almost
<seb128> the systemd autopkg is having issues so the update is not considered
<seb128> barry, ^ is that something you are looking at sorting out?
<seb128> "upstream             FAIL timed out"
<tjaalton> mesa update needed several autopkg reruns, some timeouts and some weird errors
<barry> seb128: yeah, i know about that one.  i still haven't figured it out :(
<seb128> barry, hum, k, do we have anyone looking at systemd since p_itti left? since that seems the issue there...
<barry> seb128: yeah, i don't think so :(  i've tried to look, and will be getting back to it when i can
<seb128> can slangasek or xnox help you maybe?
<barry> seb128: possibly.  i'll raise this with our team
<barry> (systemd responsibilities in general)
<xnox> barry, i think it maybe me....
<xnox> howerver not sure how the upstream tests are run. i'm sure it uses pitti's github credentials and tokens
<xnox> also i'm packing for volleyball and going out in a moment
<Laney> No, don't get the distro tests confused with the PR tests
<Laney> Not that either of them use anyone's personal credentials
<xnox> horum, ok
<Laney> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/tests/upstream
<Laney> night!
<pitti> xnox, seb128: hm, the upstream tests are supposed to work, they run in upstream CI all the time (but on xenial, so different kernel etc.); nothing to do with my github creds, they just call the upstream QEMU tests, you can run them in local autopkgtest like any other
<pitti> xnox: at first sight it seems to coincide with linux 4.9?
<pitti> and FWIW, I don't think it's a good idea to just hint over that.. (which apparently happened)
<pitti> ah sorry, no, I looked at linux-meat
<pitti> meta
<barry> pitti, xnox yeah, and the problem i've had is that when i run the upstream tests locally, it crashes qemu (in kvm.c iirc)
 * barry gives it a try again now
<pitti> barry: the inner qemu? or even the outer one?
<barry> pitti: the inner one
<pitti> nested qemu had been a bit flaky in the past, but it has worked rather nicely in the recent years
<barry> pitti: let me run it again and see if 1) it still crashes; 2) i can get you a log
<pitti> barry: http://autopkgtest.ubuntu.com/packages/s/systemd/zesty/amd64 coincide with linux 4.8 vs. 4.9 fairly consistently
<pitti> except for that dnsmasq failure, but that was not a timeout, "just" a flaky test
<pitti> so confirming on that seems like a good direction
<barry> pitti: you mean one kernel fails consistently and the other passes?
<barry> (i'm still testing against systemd 232-8)
<sarnold> mmm linux-meat
<barry> not even counting the network-manager change, just systemd in zesty
<pitti> barry: looks like it, at least
<pitti> sarnold: we clearly need a linux-veggie flavor!
<sarnold> pitti: heheheh
<barry> pitti: http://paste.ubuntu.com/23818532/
<sushi__> hello, I have a weird behaviour with fancontrol and my usb audio card
<sushi__> I've run pwmconfig to create the config file /etc/fancontrol
<sushi__> In this file, I've the line INTERVAL=10 wich means that the temperature sensors which are used as input for the fan speed monitoring are read every 10 sec
<sushi__> It's working fine
<sushi__> However, every 10 sec, I can hear a buzz in the sound when the usb sound card is playing some sound
<sushi__> I've tested with the internal audio chipset and no problem in this case
<sushi__> So I guess there is some conflicts with temperature sensors reading and usb
<sushi__> any ideas ?
<sladen> sushi__: the method of reading the I2C bus with the sensors on is probably having to turn off interrupts
<sladen> sushi__: from memory, there are different ways that the I2C can be read.  Some of less reliable, but don't involved disabling interupts
<sushi__> sladen: thank you. Thus, how to change the ways of reading I2C bus or where to find this info ?
<sarnold> sushi__: hehe, you know that bit about "shall not generate harmful interference and shall accept all interference in the environment" bit stuck on every piece of electronics? this is why :)
<sushi__> sarnold: so you think It's not a bug but some electric interferences ?
<sarnold> sushi__: hard to say without hearing the noise myself
<sarnold> sushi__: but I've heard very similar noises from e.g. ethernet nics or hard drive controllers via audio cards
<sushi__> sarnold: let me reduce the interval from 10 sec to 1 sec and record the audio output..
<sarnold> sushi__: folks used to generate radio signals using their CPUs and put a radio near the computer, to see it..
<cjwatson> You could probably still test that kind of thing by putting a handheld radio near it
<cjwatson> (Though it's a bit harder to tell when the interference is from something that itself makes noise)
<sushi__> sarnold: http://www.sekisushai.net/usb_buzz.wav
<sarnold> sushi__: wow, that's -really- annoying.
<sushi__> sladen: could you give me some more info on how to configure I2C bus reading way ?
<sarnold> sushi__: also, I think I was wrong :) ignore everything I wrote above :D
<sushi__> sarnold: yes, very annoying ... it's with my usb-audio card only and if fancontrol module is off then no problem at all
<sushi__> sarnold: no probs, thank you anyway
<sarnold> sushi__: maybe you can workaround the issue by setting realtime scheduling priorities for your music player, maybe pulseaudio too if you use it
<sushi__> sarnold: the issue is not there, I've tested using the card with alsa, or with jack server with real time on an off and the buzz it's still at the periodicity of the I2C bus reading
<sarnold> sushi__: is it possible to try moving the card to a diffreent usb port?
<sushi__> sarnold: same issue with all the usb ports, I've tested that too
<dasjoe> What about adding an USB hub?
<sushi__> dasjoe: I don't have one... :( but I guess it would be the same
<sladen> sushi__: all I'm going to be able to do is Google for things like "fancontrol" "lm-sensors" "i2c" "interupts"
<sladen> sushi__: these days I think the kernel has the i2c stuff built, in and readable under /sys
<sladen> sushi__: the buses are probably visible with 'grep -r . /sys/bus/i2c/devices/*/name'
<sarnold> does reading those give the same stutters?
<sushi__> sladen: with the usb card plug or unplugged it's the same output : http://pastebin.com/87EXnQLe
<sladen> sushi__: what about   grep . /sys/class/hwmon/hwmon*/device/*temp*
 * sladen skimming https://wiki.archlinux.org/index.php/fan_speed_control
<sushi__> sladen: nothing for  grep . /sys/class/hwmon/hwmon*/device/*temp*
<sladen> sushi__: fancontrol is non-standard.  How did you configure it?
<sladen> sushi__: what values are in the 'fancontrol' configuration file  (these tell 'fancontrol' where to read data from)
<sushi__> sladen: http://pastebin.com/55ewukdj
<sushi__> sladen: i've install the package fancontrol, then run pwmconfig to generate /etc/fancontrol
<sladen> sushi__: prepend '/sys/' to these paths in the config file
<sladen> sushi__: eg. find /sys/devices/platform/coretemp.0/.../...
<sushi__> sladen: prepending /sys/ makes fancontrol not work anymore
<sushi__> sladen: i guess the /sys/ prefix is already known somewhere..
<sushi__> sladen: I will open a bug in launchpad, thank you for your help
#ubuntu-devel 2017-01-18
<FourDollars> Hi, I would like to do a SRU for https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1100546 on xenial. Could you help me?
<ubottu> Launchpad bug 1100546 in indicator-power "Power indicator favours 'not present' mouse over laptop battery level" [Medium,Triaged]
<sarnold> FourDollars: have you seen this yet? https://wiki.ubuntu.com/StableReleaseUpdates
<FourDollars> sarnold: I am reading it.
<FourDollars> sarnold: Is there any thing I missed?
<sarnold> FourDollars: I -think- just a mention that you've been running it locally without trouble, mention if the zesty fix has had any bugs reported or not, and maybe bug the sru team
<sarnold> FourDollars: this handy chart should say who is on sru duty any given day https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<FourDollars> sarnold: OK. I see.
<FourDollars> sarnold: Thx for your information.
<sarnold> FourDollars: you're welcome :) I hope it's useful, hehe
<FourDollars> sarnold: But I need to nominate it for xenial first. Do you have the permission to nominate it?
<sarnold> lets find out :)
<sarnold> yay looked like it worked :)
<FourDollars> sarnold: OK. Thx a lot. :)
<pitti> barry: I just ran the systemd "upstream" autopkgtest on debian sid, which also recently got kernel 4.9; same problem with the qemu crash apparently
<ahasenack> hi, any idea why apt on xenial would "Ign" downlading a Release.gpg file when there is no InRelease file?
<ahasenack> http://pastebin.ubuntu.com/23821750/
<ahasenack>  /var/lib/apt/lists only has the two files at the bottom: Packages and Release
<ahasenack> it's missing Release.gpg, which the repository has (http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/xenial-updates/newton/)
<ahasenack> if I run apt update again, it still won't download the gpg file
<ahasenack> only if I remove the two files it downloaded (Packages and Release), then it will download the gpg one and be happy with the signature
<cpaelzer> ahasenack: I can confirm your finding once I forced it into the state http://paste.ubuntu.com/23821784/
<cpaelzer> I don't know how you got there, but if I just drop the gpg file I kind of end up like your pastebin
<cpaelzer> ahasenack: with Ign and the gpg not being refreshed
<ahasenack> I see
<barry> pitti: that's interesting, right? :)
<juliank> bdmurray: Ah, I just found out what is wrong with apt xenial test case. The bug only involves redirects from http to https in xenial
<juliank> And the provided test case tests a https->https redirect so it does not break in xenial, because we let curl handle it internally there
<juliank> I should replace the test case then with "install ttf-mscorefonts-installer" I think
<juliank> 1/4th of my dinner is burnt because I was so eager to find out what happened :/
<bdmurray> that seems more fragile to me
<juliank> Oh, I can also do my own test case
<juliank> but that one is in the test suite already...
<juliank> bdmurray: You could also try "https://people.debian.org/~jak/a b/c" - in 1.2.18 it will request "~jak/a b/c" which apache redirects to "~jak/a" causing a 404
<juliank> Ehm, with http not https
<juliank> Although it fails with https as well in 1.2.18
<bdmurray> okay, that failed and succeeded for me
<juliank> bdmurray: Now we're getting all kind of weirds report that it does not work on the bug because users just upgraded apt and not apt-transport-https ...
<juliank> The same used to happen with libapt-pkg and friends
<juliank> All people ever do is "apt install apt" and then wonder why things did not get fixed :)
<bdmurray> maybe put the package name in the test case?
<juliank> I added a note now
<juliank> I wonder if I should add a "Breaks: apt-transport-https (<< ${source:Version}" to apt anyway.
<juliank> That simplifies things a bit.
<juliank> but it seems a bit overkill
<pdeee> hlieberman, RAOF: is one of you working on https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978/comments/25 ?
<ubottu> Launchpad bug 1640978 in python-letsencrypt-apache (Ubuntu Yakkety) "letsencrypt 0.4.1 contains numerous bugs fixed upstream" [Undecided,New]
<pdeee> I'm not sure who the right person to handle rbasak's request is
<pdeee> meanwhile the upstream Certbot team is wanting to change what we say about Xenial at https://certbot.eff.org/
<doko> coreycb: python/trusty ping ...
<pdeee> the options are use our certbot-auto script, which is a bit janky but works, or use OndÅej SurÃ½'s PPA, which has recently reached maturity, but which might also create complexity because it contains a bunch of other packages
<acheronuk> anyone able to help with the failing (timeout) unity8 test which is blocking migration on qtbase here?
<acheronuk> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
<coreycb> doko, hi
<doko> coreycb: were you able to test your patch with the python2.7 version in trusty?
<coreycb> doko, yes, i believe it's in the trusty upload queue now
<doko> coreycb: cool, thanks! did you have time to look at the other issues?
<coreycb> doko, that fix (for kombu) fixed up cinder and glance. i just noticed nova also had a failure.  i'll see if that's also fixed by the kombu update.
<setuid> Can someone with access to kernel.ubuntu.com please run 'git update-server-info' in the ubuntu-zesty.git repo root?
<setuid> It's a broken repository right now
<doko> coreycb: thanks!  I'll give back the builds once the fix is in the archive
<coreycb> doko, ok great
<setuid> $ git clone http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-zesty.git
<setuid> Cloning into 'ubuntu-zesty'...
<setuid> fatal: repository 'http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-zesty.git/' not found
<setuid> It's a valid directory and URI, but the repo is broken
<cjwatson> setuid: you may get more relevant eyeballs in #ubuntu-kernel; I expect you could also work around it for yourself by cloning https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/zesty instead
<setuid> cjwatson, I was looking for current mirrors, found some... questionable.. mirrors
<cjwatson> setuid: I *believe* that the kernel.ubuntu.com repo is itself a mirror of the one on Launchpad ...
<cjwatson> (or maybe it's the other way round, not totally sure)
<setuid> ubuntu-xenial, 9 commits. ubuntu-yakkety, 9 commits, ubuntu-trusty, 422087 commits
<setuid> aye
<cjwatson> Certainly the intent was eventually for LP's git hosting to supersede kernel.u.c, though there are some long-standing feature requests we need to sort out regarding fine-grained access control before that can really happen
<doko> slangasek, infinity: we need to address the dpkg merge at some time, and decide about pie on some archs. my understanding with kees (private discussions) is that performance regressions should be considered
<rharper> slangasek: rbasak:  I've marked verification-failed on  bug 1649931 ; added comments;  it's likely we may want the nvme fix to go in asap and then re-submit the DNS issue after that clears through;
<ubottu> bug 1649931 in resolvconf (Ubuntu Yakkety) "systemd-networkd needs to ensure DNS is up before network-online.target" [Medium,Fix committed] https://launchpad.net/bugs/1649931
<slangasek> rharper: yep, I have already uploaded the new systemd to the queue, thanks :)
<rharper> cool!
<slangasek> (and accepted it)
<achiang> teward: hola, noticed that you maintain the nginx ppa -- wondering if you could upload a 1.10.2 stable version to pick up some bug fixes...
<teward> achiang: relevant: https://twitter.com/teward001/status/814545963960377345 and https://twitter.com/teward001/status/817472538230030336 and https://twitter.com/teward001/status/821855809361608708 and all comments on the first one.
<teward> in that order chronologically
<teward> achiang: always track my twitter, where I make notices about those PPAs.
<teward> such as when things don't build and i'm stuck at not being able to make it work, etc.
<teward> working on stuff now though (just don't bug me until it's done)
<teward> *swears on the live of his ex and his current love interest he will smack the next person to ask for the PPAs to get updated*
<teward> achiang: also relevant: https://bugs.launchpad.net/nginx/+bug/1657596
<ubottu> Launchpad bug 1657596 in Nginx "[PPA] fPIE/fPIC build problems" [Critical,In progress]
<achiang> teward: ok, sorry for the noise. didn't realize twitter was the best way to keep up with this ppa
<teward> achiang: I always announce updates there
<teward> a lot of PPA users follow me just for those announcements
<teward> achiang: it also never hurts to look at https://launchpad.net/~teward/+archive/ubuntu/nginx-stable-testing/+packages either, 'cause test packages get uploaded there
<teward> when you see a lot of red Xes next to the archs, and a package revision of 1.10.2-* you know something is being worked on but it blew up
<teward> this took me almost 3 weeks to debug
#ubuntu-devel 2017-01-19
<cpaelzer> hi, I was wondering to land a lib and a dependent together what the right steps are
<cpaelzer> in my case the lib is a sync from Debian and the dependent package would be a no-change rebuild to pick up the change
<cpaelzer> I know bileto can be used for such transitions, but I was wondereing if syncpackage ... --no-lp and then into bileto ppa would be ok given the amount of warnings about --no-lp in man syncpackage
<rbasak> cpaelzer: to copy straight into a PPA, you can use copypackage instead, from ubuntu-archive-tools.
<Odd_Bloke> If a core dev has a minute to review https://code.launchpad.net/~tribaal/livecd-rootfs/fix-ova-manifest/+merge/314682 it would be much appreciated.
<rbasak> cpaelzer: I've never used copypackage to source from Debian, but I presume that's possible.
<rbasak> cpaelzer: you don't need to use bileto though unless you want to. It's fine to syncpackage, and then upload a no-change rebuild for the dependent once the sync has built. It'll be stuck in proposed until it's all done, but that's the point of proposed so it's fine.
<Odd_Bloke> (There's also https://code.launchpad.net/~tribaal/livecd-rootfs/fix-ubuntu-ovf-attributes/+merge/314702 but the diff there is a bit chunkier.)
<Tribaal> not *much* chunkier though :)
<rbasak> cpaelzer: no point in uploading the no-change rebuild early though - it'll rebuild without the update, so that's pointless. Have to wait until the synced package is built and the binary published.
<Tribaal> thanks Odd_Bloke
<rbasak> cpaelzer: it's copy-package, sorry.
<cpaelzer> rbasak: thanks
<tumbleweed> `/win 35
<cpaelzer> rbasak: and I just see - other than with dput these days for syncpackage you still have to call it $release-proposed instead of just the release name right?
<rbasak> cpaelzer: I'm not sure. Doing so would do no harm. But why would you use copypackage to copy into a -proposed pocket in this case?
<cpaelzer> rbasak: no syncpackage
<cpaelzer> rbasak: like "syncpackage --release=zesty-proposed --debian-version=16.11-1 --bug=1539775 --force --verbose dpdk"
<cpaelzer> tumbleweed: http://hpoussineau.free.fr/qemu/arc20081202-nt350-4.png that is :-)
<rbasak> Ah.
<rbasak> I believe zesty-proposed is implied.
<rbasak> I've never used --release
<cpaelzer> I think current-release is the default according to the doc
<Laney> Yes, and it'll take the latest available version by default too
<cpaelzer> let check if it implies -proposed, because with --release=zesty it told me that I don't have permissions to do so
<cpaelzer> thanks everone, worked as it should now
<rbasak> I'm pretty sure it must imply -proposed, because it's succeeded and done the right thing for me in the past.
<tumbleweed> cpaelzer: :P
<cpaelzer> rbasak: dpdk sync worked just fine and I waited till the build said pblished in proposed >30 minutes ago. Yet the subsequent rebuild of openvswitch still pulled in the older version :-/
<rbasak> cpaelzer: are you sure it was the binaries that were published rather than just the source?
<cpaelzer> rbasak: the solution is easy - upload another no-change, but I really want to avoid proliferating the numbers due to that - what is the hard check to go for if it is ready to pull the new package version
<cpaelzer> hmm checking
<rbasak> cpaelzer: the binaries aren't published - they're held in NEW.
<cpaelzer> harr, that got me - thanks for helping me to find the reason
<cpaelzer> yes it has a few new packages as the dpdk zoo of sublibraries grew
<rbasak> cpaelzer: you're welcome. On https://launchpad.net/ubuntu/+source/dpdk/16.11-1, it says "(New)" against the builds. IIRC it also tells you there when they are pending publication, but I'm not sure.
<cpaelzer> rbasak: it does tell me there, I was wrongly checking published and build on https://launchpad.net/ubuntu/+source/dpdk/16.11-1
<cpaelzer> but that only was source + build as you assumed
<cpaelzer> I can't see binary publsihed (or not) on that page
<cpaelzer> https://launchpad.net/ubuntu/+source/dpdk when you flip open the release thing tells me pending publication
<cpaelzer> well you can see it - by not seing anything - under the binaries list on https://launchpad.net/ubuntu/+source/dpdk/16.11-1
<cpaelzer> That said the pending publication down there could be useful
<cpaelzer> I might file an LP bug for that
<cpaelzer> ok, I have abug for it now
<cpaelzer> thanks rbasak to help my finding my misassumption
<coreycb> infinity: hi, any chance you could upload 0.158 of ubuntu-dev-tools to debian?
<Saviq> wgrant, hey, is there a bug# for the arm64 builders kernel issue? I'm afraid we're encountering the same in our CI, trying to enable arm64 there...
<doko> tjaalton: when do you plan to build mesa with llvm 3.9 in the stable releases?
<tjaalton> doko: only mesa 13 backport will
<tjaalton> not the currently SRU'd 12.0.x
<tjaalton> because there were some issues with it, though it was easy to get it build with 3.9
<tjaalton> mesa 13 is the first one that properly supports 3.9
<tjaalton> should requestbackport work on xenial?
<tjaalton> lazr.restfulclient.errors.BadRequest: HTTP Error 400: Bad Request
<dmj_s76> jbicha: So I want to fix a number of bugs by adding hidpi support to Humanity.  Should I branch from lp:humanity or lp:~ubuntu-art-pkg/humanity/release ?
<dmj_s76> I'm assuming the latter since that's where commits have been lately.
<dobey> i almost never say that anything needs "hidpi" support, but man, does the steam overlay stuff seriously need some improvement there
<dmj_s76> dobey: hmm...details?
<dobey> dmj_s76: i mean i like small icons/text normally. but when playing games at 4K and then i open the steam overlay, everything is even tinier than it normally is in the steam client. the notifications for achievements are especially annoying, because they're super tiny and stuck hard to the far upper right corner. those would be much better if they ended up like standard notifications in ubuntu
<dmj_s76> dobey: Maybe this needs reporting to Valve.
<dobey> probably yeah
<dobey> i know you can't do anything about it. was just trolling a bit because everyone thinks my normal font size is tiny
<dmj_s76> In this case Humanity icons not supporting @2x is a problem, causing the wrong icons to be shown and graphical bugs in Ubiquity.
<dobey> @2x?
<udevbot> Error: "2x?" is not a valid command.
<dobey> err, thanks bot
<dobey> i thought that was an apple thing
<dmj_s76> How you signal GTK, etc to use the normal icon and scale up rather than picking the bigger one (which can be the wrong metaphor) eg, "scale up the 24 px icon, not use the 48px icon"
<dmj_s76> It's a Linux thing too.
<dobey> i know gtk+ has that scaling thing; i didn't realize it was doing dumb things with icons like appending @2x to the size
<dmj_s76> well, you basically just need @2x symlinks to the correct folders
<dmj_s76> and an update to the index.theme
<jackpot51> Is there a maintainer for the wpa source package?
<jackpot51> It just says "Ubuntu Developers"
<sarnold> jackpot51: the changelog lists a wide variety of folks https://launchpad.net/ubuntu/+source/wpa/+changelog
<jackpot51> That is unfortunate. pitti: Since you did a change for the wpa_supplicant.service, would you talk to me about my changes?
<sarnold> pitti's moved to another employer in the meantime, it might be a while before he has time to review something not for new work
<rbasak> jackpot51: all packages in Ubuntu are team maintained. There are no individual maintainers.
<rbasak> jackpot51: if you need to talk to people about a proposed change, then you can do it here, on the mailing list, or in a bug. And any person (subject to appropriate permissions on that package) can upload any change.
<jackpot51> the problem is that systemctl isolate kills wpa_supplicant.service
<jackpot51> This is easily seen where it is used in the OEM installer - wifi connections are lost after oem-config finishes
<sarnold> isn't that the intention of isolate?
<jackpot51> systemctl isolate graphical.target is used
<jackpot51> graphical.target should depend on wpa_supplicant.service
<jackpot51> ethernet connections are not lost due to network manager not being killed
<jackpot51> wifi is lost due to wpa_supplicant being killed
<jackpot51> related bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1576024
<ubottu> Launchpad bug 1576024 in network-manager (Ubuntu) "Wifi "device not ready" after booting into OS for the 1st time" [Undecided,Confirmed]
<rbasak> How does network manager avoid getting killed?
<tsimonq2> *sits in*
<tsimonq2> Had that bug before
<tsimonq2> (didn't know it wasn't hardware-specific)
<jackpot51> it is not hardware specific - system76 and dell laptops experience it on first boot
<jackpot51> switching cards does not solve the issue
<rbasak> jackpot51: it sounds like you've done a great job pinning down the root cause. Thanks! If nothing else, please could you write that up in the bug?
<sarnold> jackpot51: nice :D
<jackpot51> will do
<rbasak> jackpot51: as for the correct fix, should it be done the same way that network manager avoids getting killed? How is that, and doesn't network manager spawn wpasupplicant as a child, or is it really using a separate systemd service?
<sarnold> maybe NM systemd unit file needs adjusting to require wpa_supplicant..
<jackpot51> it is a seperate service - as a side note, bluetoothd has the same issue
<wgrant> Saviq: https://bugreports.qt.io/browse/QTBUG-54822
<jackpot51> I fixed it the "wrong" way by adding IgnoreOnIsolate=true to [Unit] in wpa_supplicant.service
<rbasak> jackpot51: and it'd be nice to have the relevant Debian maintainer's agreement if possible before fixing it in Ubuntu, so we can do it the same way and get additional review
<rbasak> Assuming the same bug exists in Debian and that they want to use graphical.target in the same way.
<rbasak> If urgent, we can always fix first of course. I'm just not confident enough in this area to confirm any fix is correct.
<jackpot51> My fix would mean that going to a non-networking target would not kill wpa_supplicant
<jackpot51> I don't think that happens in the real world often though
<jackpot51> here is the most upstream service file: https://w1.fi/cgit/hostap/tree/wpa_supplicant/systemd/wpa_supplicant.service.in
<sarnold> and does NM depend upon it properly?
<jackpot51> I am not sure: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/data/NetworkManager.service.in
<jackpot51> It isn't in the upstream service file
<jackpot51> by the way, it is possible to trigger the bug running on your own system. All you have to do is run `sudo systemctl isolate default.target` while connected to WiFi
#ubuntu-devel 2017-01-20
<rnetocombr> 16.04.2 build delayed ?
<jbicha> rnetocombr: yes, see https://lists.ubuntu.com/archives/ubuntu-release/2017-January/003998.html and https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
<rnetocombr> jbicha: ok! thanks!
<pitti> rbasak: hmm, jackpot51 isn't here, but "isolate" is pretty much defined as "stop everything which is not part of the given target"
<pitti> so this sounds like a case of YAFIYGI to me -- isolate isn't something which users should ever want to actually use...
<lpotter> uyhjjjjjjjjjjj
<fooctrl> did anyone have any success getting ubuntu working on macbook pro 2016 (with touch id)?
<seb128> slangasek, hey, is there any reason you copied the yakkety SRU to -updates but not the xenial one on bug #1506427?
<ubottu> bug 1506427 in ido (Ubuntu Xenial) "Using calendar with keys might cause Indicator-datetime to crash unity-panel-service" [Medium,Fix committed] https://launchpad.net/bugs/1506427
<lpotter> sorry. cat meets keyboard
<rbasak> pitti: any suggestion on what should be done instead for this? Bug 1576024.
<ubottu> bug 1576024 in network-manager (Ubuntu) "Wifi "device not ready" after booting into OS for the 1st time" [Undecided,Confirmed] https://launchpad.net/bugs/1576024
<happyaron> rbasak: we got some SRUs to nm and nm-applet, that should improve the situation a lot
<rbasak> happyaron: are you referring to the root cause that jackpot51 isolated, or something else?
<rbasak> I'm just trying to help out because he has proposed a fix that will probably work (or so it seems to me) but it may not be the right fix.
<seb128> happyaron, reading the comment that bug seems specific and having to do with systemd integration in oem mode, so likely differently from the upstream code issues which make wifis sometime snot listed (which you likely refers to)
<seb128> rbasak, ^
<pitti> rbasak: I guess what you said -- find out who added that isolate call there
<seb128> hey pitti, wie gehts?
<happyaron> we have several reports that results into similar situation, but for systemd stuff no
<seb128> what component is calling the isolate?
<pitti> seb128: bonjour ! Ã§a va bien, merci ! j'apprends javascript et angular maintenant
<pitti> seb128: in bug 1576024
<ubottu> bug 1576024 in network-manager (Ubuntu) "Wifi "device not ready" after booting into OS for the 1st time" [Undecided,Confirmed] https://launchpad.net/bugs/1576024
<seb128> pitti, right, I read that, doesn't tell what is doing the systemctl isolate call, is that the oem tools?
<pitti> supposedly, yes
<Laney> what should it be doing there?
<rbasak> pitti: OK, thanks
<seb128> pitti, do you know what's going on there? https://autopkgtest.ubuntu.com/packages/postgresql-9.5/xenial/armhf
<doko_> Laney: what does this mean in an autopkg test? autopkgtest for linux/blacklisted: i386: Regression
<Laney> it means the package is blacklisted
<pitti> seb128: supposedly coincides with moving from lxc to lxd; got fixed by https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git/commit/?id=fc40fc34 but this isn't in xenial yet
<seb128> pitti, thanks, it looks like the xenial/krb5 current SRU is blocked by the postgrestql/autopkg issue, should that just be ignored then?
<pitti> seb128: short term it can be ignored (the test succeeded, just that stderr spew), mid-term it would be good to SRU that p-common fix
<seb128> pitti, k, thanks
<seb128> SRU team, ^ you probably want to consider krb5/xenial as good to be copied to updates (if the autopkg issue is what is blocking it, it's old in the queue and verified but currently there is no clear communication about those issues, maybe it would be good to comment back on the corresponding bug when there is a blocker)
<seb128> bdmurray, rbasak, sil2100, ^
<doko_> Laney: just the i386 build?
<Laney> doko_: Yeah, blacklists are per series and arch
<Laney> It makes the test machines OOM and die
<doko_> ok, ta
<rbasak> seb128: commented in the bug.
<rbasak> seb128: I'm happy to take their word for what they say; I'm just concerned that they're missing an entire class of use cases. If say they've considered it and are being careful about them, then that's fine.
<seb128> rbasak, thanks, I don't know the specifics of that SRU but I noticed that a few didn't get copied over despite beeing aged+verified and it looks like some SRU team members at least don't copy over things that have autopkg issues listed but they don't say so either/comment on the bug and the uploaders don't get notified/notice so the updates get silently stucked forever
<seb128> which is a process issue
<seb128> would be good if the SRU team had a mailing list or some place for such discussions (or is there one but I just don't know about?)
<rbasak> seb128: understood and agreed. I've noticed this too. When looking at releasing SRUs I keep having to comment to ask about any reported autopkgtest regressions. IMHO there should be an automatic comment in the bug if autopkgtest regressions are detected, so that the bug driver can comment instead of having to do yet another round trip.
<rbasak> It would save the SRU team work as well, helping us process more quicker. A comment of "autopkgtest failure X is a regression because Y and therefore this SRU won't cause problems due to Z" would be really helpful.
<rbasak> But that can only happen if the bug driver knows about it.
<seb128> indeed
<rbasak> I do try to look at the reported regressions and make my own determinations about false positives, but it is rather time consuming to have to look at so many, and sometimes I am not confident but the bug driver (whom I trust) is.
<seb128> yeah, should be up to the uploader to follow up on those, not to the SRU team
<seb128> which they would probably do if they were told that they need to investigate
<slangasek> seb128: probably just that the xenial SRU of ido was lost in the noise of all the stale unverified SRUs
<seb128> slangasek, k, I though that since the bug was being handled all series would be looked at, but if you work from the queue and by serie I guess the workflow is different
<kdub> what could cause dh_auto_build to not compile in parallel? (package is compat 9, so passing -O--parallel of course)
<doko_> coreycb, barry: updated https://bugs.launchpad.net/ubuntu/+source/kombu/+bug/1656333 (this issue needs verification itself, didn't do that yet). The one outstanding issue is python-glanceclient
<ubottu> Launchpad bug 1656333 in kombu (Ubuntu Trusty) "[SRU] Fix uuid shim in newer Python versions" [Undecided,Fix committed]
<doko_> jamespage: ^^^
<coreycb> doko_, thanks.  have a link to the new build output?
<doko_> coreycb: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20161216-updates-python2712-trusty.html  the old logs (failing ones) are overwritten
<coreycb> doko_, thanks. i'll take a look at glanceclient
<catbus1> Hi, I assume the 16.04 daily build will become 16.04.2 on Feb 2nd. Am I right? If so, if someone wants to test 16.04.2 before the release date, they can grab it from here: http://cdimages.ubuntu.com/ubuntu-server/xenial/daily/current/ right?
<catbus1> As of now, it doesn't have 4.8 kernel yet.
#ubuntu-devel 2017-01-21
<mapreri> Unit193: can't you file things like LP: #1658268 in debian instead?  Givan that you are also a Debian contributor I'm surprised you preferred to go through ubuntu instead, tbh.
<ubottu> Launchpad bug 1658268 in gvpe (Ubuntu) "Please update to 3.0" [Undecided,New] https://launchpad.net/bugs/1658268
<nkh> Hi guys, I need to set up a local repository on my server, but I want to setup and maintain it like real ubuntu repositories, I mean I have to support multiple distributions, provide dist-upgrades, so one can migrate from 14.04 to 16.04 and get the new packages ... I want to automate this on my server. For example, I have some packages being built on the server by continues integration [Jenkins]  ... Anyhow, I need to know about how actual ubuntu repositories
<Unit193> mapreri: I'm a Debian contributor? :3  (But yeah, I have more upload perms here, easier time with the bt, etc.)  Also, while I didn't file anything, already talked to upstream (and have been in contact for a while), and the maintainer isn't planning on updating it before stretch.
<mapreri> yes, updating to stretch now is a bad idea; you know, freeze and all.  but he could uploda to experimental and we could sync from there.
<mapreri> but so you're in contact with the debian maintainer too?
<Unit193> "In contact" would be a bit of an overstatement, I emailed and he never responded.  What I know I heard from upstream, and he said "No openssl 1.1 support, no upload."
<mapreri> oh
<mapreri> well
<mapreri> Unit193: did you use the version you download with uscan, i.e. sha256 0e0a2db4dc7ac591c4368989329773a1b2399bca959d1cc10fa9f95884acc1ec ?
<Unit193> mapreri: Yeah I've been using 0e0a2db4dc7ac591c4368989329773a1b2399bca959d1cc10fa9f95884acc1ec since about the time it came out, and a snapshot before that.
<Unit193> mapreri: I'd rather there be no incompatibilities between Debian and Ubuntu, but to me the newer version is worth it considering the better keys.
<mapreri> Unit193: nonetheless, please file a debian bug too, possibly link it with the lp bug.
#ubuntu-devel 2018-01-15
<xnox> xnox_, hey!
<xnox> xnox_2, hey
<xnox> xnox_chrome, hello!
<rbasak> juliank: we use debian/sid as the target for the merge because then Launchpad generates a useful preview.
<rbasak> It's a hack really.
<juliank> Ah
<juliank> for context: So I played with git-ubuntu (to merge multipath-tools). Not sure if I did everything right, but I figured it would be nice given the work already put into it. The wiki said to use debian/sid as the target for the merge proposal, but that does not seem to make much sense to me.  https://code.launchpad.net/~juliank/ubuntu/+source/multipath-tools/+git/multipath-tools/+merge/336097
<rbasak> The changelog generation hasn't been intended to be completely automatic. Perhaps it can be in the future. I still find it useful to provide a starting point though.
<rbasak> You don't have to use it.
<rbasak> Perhaps we need to fix the docs on that. You're not the only person to have different expectations from what it actually does ;)
<Pharaoh_Atem> rbasak: I'm just surprised that git-ubuntu isn't turning into a nice little fedpkg-like tool for ubuntu stuff
<rbasak> Pharaoh_Atem: ?
<Pharaoh_Atem> rbasak: https://www.mankier.com/1/fedpkg
<Pharaoh_Atem> a central tool for managing packaging workflows
<juliank> git ubuntu is extremely complicated to work with, but I guess it has to since the whole merging with Debian thing is complicated
<rbasak> Why do you say it's complicated?
<juliank> Well, the workflow is complicated
<juliank> with all the rebasing and stuff
<rbasak> The _package merge_ workflow is complicated.
<rbasak> That's not all of git-ubuntu.
<juliank> rbasak: That's all I played with so far :)
<rbasak> But yeah, like you say, that's the consequence of the nature of what Ubuntu is as a derivative.
<rbasak> Fundamentally the package merge workflow is "git rebase".
<Pharaoh_Atem> well, more like a child distro that hasn't yet walked away from the parent ;)
<rbasak> What makes it more complicated is splitting up previous Ubuntu uploads that didn't use the workflow.
<rbasak> Which of course is to be expected; it's the migration cost.
<sil2100> cjwatson, wgrant: hey! Can we get https://dev.launchpad.net/Translations/LanguagePackSchedule updated to include bionic? I switched langpack-o-matic cron to run the l-o-m bits in place of yakkety
<cjwatson> sil2100: done
<sil2100> cjwatson: thanks again!
<zomaar> #1734147
<Unit193> LP 1734147
<ubottu> Launchpad bug 1734147 in linux (Ubuntu Artful) "corrupted BIOS due to Intel SPI bug in kernel" [Critical,Fix released] https://launchpad.net/bugs/1734147
<zomaar> Thx
<zomaar> Was trying to figure out what the minimal approach was to trigger it
#ubuntu-devel 2018-01-16
<alkisg> Hi, where can I report the #ubuntu IRC operator Flannel?
<Flannel> alkisg: You want #ubuntu-ops
<alkisg> Thank you
<tkamppeter> xnox, hi
<juliank> Can anyone think of a reason _not_ to merge gnutls28 3.5.16?
<ogra> it is work :P
<juliank> ogra: other than that.
<juliank> :D
<ogra> yeah, i knew it would be a lame reason :)
<juliank> ogra: You know what they say: one merge a day keeps the doctor away
<ogra> haha
<tsimonq2> juliank: The only reason I see is that a bunch of builders are still down, so I wouldn't expect it to build on a lot of arches
<xnox> xnox_konversatio, heya!
<xnox> xnox_konversatio, heya again
<ogra> he doesnt want to talk to you it seems :P
<xnox_konversatio> ogra: not happy with hexchat under gnome-shell, trying a few irc clients, and they all seem to suck w.r.t. gnome-shell notifications....
<xnox_konversatio> i think i will have to get down and dirty and fix hexchat....
<ogra> +1
<tsimonq2> xnox_konversatio: psst, switch to irssi, we have cookies :P
<ogra> do you also have tea to dip them into ?
<tsimonq2> If you want :D
<xnox> tsimonq2, i only do biscuits!
<tsimonq2> xnox: We have those too ;D
<xnox> tsimonq2, do you have gnome-shell notifications that i can click and would take me into the right view? (the right window/tab/chat screen of the person/channel with the highlight?
<xnox> )
<tsimonq2> xnox: Ah, no, not *that* advanced, sorry
<cjwatson> builders> I can push through primary archive stuff on request, although autopkgtests still won't run
<tsimonq2> cjwatson: autopkgtests> But amd64 and i386 will still run, right?
<tsimonq2> cjwatson: builders> What qualifies to be pushed through?
<cjwatson> amd64/i386> I think so, though that won't be enough for proposed-migration
<cjwatson> Things that would previously have been eligible for building on non-virtualised builders when those were a thing; i.e. primary archive or PPAs exclusively uploadable by Canonical staff
<cjwatson> (also it's a bit clickyclicky right now so I'm only doing things that are actually worth bothering with)
<tsimonq2> Ok
<tsimonq2> Is there any sort of ETA for these builders to return?
<cjwatson> Not yet, sorry
<tsimonq2> Alright.
<cjwatson> Everything apart from ARM might be relatively soon since I noticed kernel updates today
<cjwatson> Haven't been able to find out the ARM state yet
<tsimonq2> Alright.
<xnox> tsimonq2, is it for webkit with spectre fixes? or was that pushed through already?
 * tsimonq2 hopes it's done in time to get Qt and nodejs transitions done before A2 freeze
<cjwatson> For transitions in the primary archive you can absolutely ask me
<cjwatson> Though as mentioned that won't help with the autopkgtest bit
<cjwatson> Anyway, going out now
<tsimonq2> cjwatson: Alright, I was just hoping to stage it in Bileto though.
<tsimonq2> xnox: I'll look into it, although you might be interested in joining #ubuntu-qt and asking there ;)
<tsimonq2> (other people might have better answers)
<seb128> cjwatson, hey, do you know if we considered enabling the "download updates" option by default in the installer in the past? or what had been the reasons to not do it?
<cjwatson> seb128: Sorry, I don't remember :-/
<xnox> (note, these days, with ssd drives, install finished before one manages to download any meaningful amount of updates, and they are not applied - just cached in target for install post boot, as far as i recall)
<tsimonq2> (I wonder if Lubuntu could figure something like that out for Calamares...)
<seb128> cjwatson, no worry, I was asking in case since we are being requested to change the default for that option
<infinity> tsimonq2, cjwatson: Are there any plans to fix the publisher explosion brought on by the cart-before-horse lubuntu seed git transition?
<tsimonq2> infinity: ...there was a publisher explosion?
<tsimonq2> infinity: I'll be happy to send code.
<tsimonq2> (you know, as soon as someone tells me what exploded so I can investigate...)
<juliank> tsimonq2: I found out in the meantime that it needs a new unistring version. I have a merge ready for this, but it breaks API (not sure how much. probably not a lot) and ABI, so I'll wait with that until the builds and tests run again. Or I just build with the bundled libunistring as it does now.
<tsimonq2> juliank: Ok.
<tsimonq2> juliank: (you're talking about gnutls28?)
<juliank> yeah
<tsimonq2> Ok
<infinity> tsimonq2: Well, the explosion is that it's trying to germinate based on the bzr branch that now contains no seeds.  I'm not sure what needs to be done to make it look at the git bits instead.
<juliank> tsimonq2: sorry ofr the confusion
<tsimonq2> infinity: Can I get a link to what you're referring to here? I thought that particular element was fixed.
<tsimonq2> juliank: np ;)
<infinity> tsimonq2: No link to logs, but I'm trying to unwind this.  Kinda figured Colin would chime in by now. :P
<sarnold> tsimonq2: what'd you break that needs both infinity *and* colin? :)
<tsimonq2> sarnold: The thing is, I don't know :P
<sarnold> tsimonq2: hah :) well done :)
<infinity> tsimonq2: Well, the first thing you broke was deleting your seeds.
<tsimonq2> infinity: That shouldn't have done anything wrong if the tooling knew Lubuntu seeds were in Git now.
<tsimonq2> sarnold: heh
<infinity> tsimonq2: Yes, and how was "the tooling" meant to know that? :P
<infinity> (hence my "cart-before-horse" comment)
<tsimonq2> Right, I sent MPs.
<tsimonq2> cdimage knows, archive tools know, what did I miss?
<infinity> launchpad.
<tsimonq2> Aah.
<tsimonq2> Ok.
 * tsimonq2 loops slangasek in either way. :P
<tsimonq2> infinity: I'll throw an MP at LP when I get home unless another kind soul feels inclined.
<infinity> tsimonq2: Well, I'm still trying to unwind where this goes wrong...
<infinity> It was obvious when you replaced your seed with a text file and the error was "no STRUCTURE file", it's less obvious now that the branch is deleted entirely.
<tsimonq2> infinity: I'm confused. Why would Launchpad itself ever need to call germinate directly?
<infinity> tsimonq2: The publisher germinates on every run to update overrides and task headers.
<tsimonq2> infinity: Oh,
<tsimonq2> infinity: I imagine it might just need a repo location update and a s/bzr/vcs=auto/ in the Germinate call.
<tsimonq2> I could be totally wrong though.
<infinity> tsimonq2: That would be true if it forked germinate, but it imports it in-process, which is more fun.
<tsimonq2> infinity: Interesting. How is the VCS passed then?
<infinity> So far, I'm going with "it's not".
<infinity> Since the internal defaults worked fine right up until a few weeks ago.
<tsimonq2> Hm.
<infinity> Meh, this probably means diving into germinate itself so I can figure out what method(s) take vcs arguments so I can mangle the LP bits.
<infinity> I'll save that for when I care a bit more.
<tsimonq2> I can look into it later; I've already had to dig in there a bit.
<tsimonq2> Colin might know more as well when he comes around.
<infinity> kees, slangasek, stgraber, mdeslaur: TB.
<nacc> slangasek: is there a way with sysv to say that if corosync starts that it should start pacemaker, if pacemaker is available? The phrasing of "Should-Start" is close, but then I think it's semantics don't make a ton of sense (or I misunderstand them)
<cjwatson> tsimonq2: you want to look in lp:ubuntu-archive-publishing rather than LP itself (it was split out a while back)
<cjwatson> hmm, but I didn't think that cared about the seed source.  lemme check
<cjwatson> OK, no, the problem is surely the seed checkouts on snakefruit
<cjwatson> infinity: tsimonq2 has done their bit here; the problem is that we need to switch some things over on snakefruit.  I'm busy just now but I'll sort it out.
<tsimonq2> cjwatson: OK, cool.
<tsimonq2> Thanks.
<infinity> cjwatson: Yeah, the snakefruit hint was just given to my by cyphermox who pointed out that a tool looking at "people" was failing.
<infinity> cjwatson: And then I remembered from firewall rule discussions when we set up archive-team.internal that the publisher probably looks at that same goop.
<slangasek> nacc: not really any primitives for that in sysv, no.  you can have one init script manually call the other...
<tsimonq2> Oh hey slangasek :D
<rlink> In response to https://shibboleth.net/community/advisories/secadv_20180112.txt (CVE-2018-0486), is a patch preferred, or a pull from Debian (which is how it appears Shibboleth-related updates have gotten into Ubuntu previously)?
<ubottu> Shibboleth XMLTooling-C before 1.6.3, as used in Shibboleth Service Provider before 2.6.0 on Windows and other products, mishandles digital signatures of user attribute data, which allows remote attackers to obtain sensitive information or conduct impersonation attacks via a crafted DTD. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0486)
<tsimonq2> rlink: Is there an Ubuntu delta on the stable release and are there more changes than just security updates between the versiom in the stable release and Debian?
<tsimonq2> If the answer is no to both, then yeah, fakesyncing seems like the best option.
<tsimonq2> Otherwise a patch is probably needed.
<tsimonq2> Regardless rlink, you're likely looking for the person in the topic of #ubuntu-hardened. :)
<sarnold> rlink: for devel release, a sync from debian is best; for supported releases, a debdiff with smallest feasible patch is best
<sarnold> rlink: there's some description of the update process in https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
<rlink> So, this is fun.  Trusty got a fakesync from Debian in July 2016, explicitly to pick up the backported patch that allows disabling DTD parsing (which conveniently also negates this new bug).  Xenial never got any such thing.
<sarnold> yes, that can happen :(
<nacc> slangasek: ok, that might be what need to do, i assume with a [ -f ... ] check tha thte other init script exists?
<nacc> slangasek: and different question, how do I check, if it's sensible, in sysv that a given init script is enabled? Is it sufficient to look for a symlink in the appropriate /etc/rc*.d directory?
<cjwatson> infinity,tsimonq2: Should all be sorted out now.  The update-seeds changes were fine, but they needed to be deployed, and I had to move the existing branches aside.
<tsimonq2> cjwatson: Thanks!
#ubuntu-devel 2018-01-17
<sarnold> bdmurray: polite poke re https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1738581  :)
<ubottu> Launchpad bug 1738581 in apport (Ubuntu) "apport is leaking environment variables (including passwords!) to public bug reports" [Undecided,New]
<slangasek> nacc: enabled> ugh.  I'd say there are no good interfaces here, and it'll be hard to implement this in a way that won't break once things start to move to systemd (not necessarily in tandem)
 * xnox wonders if i am back on irc
<Odd_Bloke> xnox: You appear to be.
<xnox> whoop whoop
<Unit193> Nah, you aren't, xnox.
<juliank> I don't entirely understand MoM's days old. For example, wpa's Oct 2017 upload was merged, but it says 326 days old
<cjwatson> I believe it's supposed to be the date on which it was superseded - i.e. the creation date of the first Debian source publication with a higher version
<juliank> cjwatson: hmm, there was a newer version in experimental before that, amybe it picked thatu p
<juliank> jbicha: Seems we can sync libsecret now? gjs is back on s390x, and you pushed the disable vala & python there patch to Debian
<rbasak> I think MoM only sees unstable, not experimental.
<rbasak> Even if Ubuntu is synced to experimental.
 * rbasak is guessing
<jbicha> juliank: yes
<juliank> jbicha: ok, done.
<cjwatson> rbasak,juliank: mm, except there is a bug here.
<cjwatson> at least arguably
<cjwatson> juliank: fixed for the next run, fingers crossed.  http://bazaar.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/revision/303
<juliank> cjwatson: awesome!
<rbalint> lool: do you mind if i merge flash-kernel from unstable?
<juliank> oh, it's about time for that one :)
<juliank> 3.0~rc.4ubuntu66
<rbalint> juliank: i figured no one wanted touch it :-)
<juliank> I wonder if I should have a go at wpa
<juliank> ^ mostly mdeslaur 's playground :)
<rbalint> juliank: it is a desktop package, so i'm trying to fix foundations ones first
<juliank> There aren't many _good_ ones left :D
<juliank> Oh coreutilsmight be nice
<juliank> strace is blocked on 3 broken tests, I should figure out why they're broken. ugh.
<juliank> We should add some classes and javascript to the MoM output so we can filter out the green and gray stuff, and perhaps a search thingy, that would be nice.
<rbalint> juliank: i'd prefer a way different strategy, driving the outstanding merges so low that we should not care about the filtering :-)
<juliank> that works too
<juliank> I already took out 4 of them today so far
<juliank> two on monday, two more queued in a ppa
<juliank> and what, 7 or 8 last week?
<rbalint> juliank: great! :-)
<juliank> My bionic is a bit unstable. From time to time, it does not register clicks
<juliank> only for like 5 seconds, then it works again
<juliank> using the X session :D
<mdeslaur> juliank: I'm not a wpa expert, go ahead if you feel like it!
<willcooke>  juliank hey!  Re: mouse clicks, could it be this?  https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1181666
<ubottu> Launchpad bug 1181666 in GNOME Shell "gnome-shell randomly blocks mouse clicks from working in app windows" [Critical,Confirmed]
<juliank> willcooke: sounds like it
<juliank> willcooke: though for me it's only temporary and solves itself
<willcooke> juliank, I think soving itself is in keeping with what duflu is saying.
<willcooke> I'll follow up with him and see whats going on there
<rbalint> pitti: i'm looking at merging procps from unstable if you don't mind
<pitti> rbalint: sure, go ahead; I don't have taps on anything right now
<lool> rbalint: absolutely not, would love if you would
<rbalint> pitti, lool: thanks, taking them then
<juliank> apw: if you don't mind I'll have a go at merging cryptsetup
<juliank> apw: Though I don't quite understand why you did all these changes like dropping c99, they seem pointless to me.
<juliank> oh, that might just be wrongly indented changelog
<juliank> xnox: seems you made the _BSD_SOURCE => _DEFAULT_SOURCE, removal of -std=c99 changes in cryptsetup. May I ask why? seems like a useless diff
<juliank> * last year in August
<xnox> juliank, because the new world order is c11; and it FTBFS; _BSD_SOURCE no more; it's _DEFAULT_SOURCE now
<juliank> It FTBFS due to std=c99?
<xnox> no, it's just std=c99 used be higher than the default standard; now it's lower than the default standard; and hence I upgraded to c11.
<xnox> and _BSD_SOURCE was tripping up the preprocessor i believe.
<juliank> #define _GNU_SOURCE
<juliank> #define _BSD_SOURCE
<juliank> #define _POSIX_C_SOURCE 1
<xnox> yes
<juliank> that's what Debian uses now....
<xnox> well, that's nuts =)
<juliank> seems more complicated than yours :D
<juliank> "Oh, let's see what we can add to make it compile"
<xnox> juliank, i'm all for dropping delta's and going with whatever debian has, on the grand scheme of things, this is marginally irrelevant.
<xnox> juliank, i hope they have dropped c99, or have they not?
<juliank> xnox: No they have not.
 * xnox ponders if _DEFAULT_SOURCE works on kfreebsd and hurd
<xnox> maybe i should forward them a patch, but not sure if i care about these thigns.
<juliank> xnox: But the thing is, it could be a mere statement that this is supposed to be C99
<juliank> Not neccessarily for technical reasons
<xnox> i think it would fail to compile with 89
<xnox> cause it actually relied on c99
 * xnox that's from memory
<juliank> xnox: They also pass -pedantic though, so they kind of have to pass -std=c99 or something, as gnu99 or gnu11 is not pedantic enough :D
<juliank> I don't think you even need _DEFAULT_SOURCE in gnu11 mode
<juliank> But since this is debian/-only, I wonder anyway why they want to build in ISO C mode
<rbasak> sil2100: any idea what's going on with bug 1718824 and pulseaudio in Xenial genreally?
<ubottu> bug 1718824 in HWE Next "The analogue audio does not work on the Dell USB Dock" [Critical,In progress] https://launchpad.net/bugs/1718824
<rbasak> For example publishing history https://launchpad.net/ubuntu/+source/pulseaudio/+publishinghistory for 1:8.0-0ubuntu3.5
<rbasak> I see no SRU process comments in the bug
<rbasak> But you've been involved, I think
<rbasak> And there is stuff in the queue.
<sil2100> rbasak: hm, I don't know anything about this sadly
<sil2100> rbasak: I don't remember being involved in this bug, but maybe my memory is just wrong?
<rbasak> I don't see your involvement in the bug specifically.
<rbasak> But I saw you in publishing history for  1:8.0-0ubuntu3.7
<sil2100> I did some publishing of it in the past indeed, let me take a look at what's in this SRU
<nacc> slangasek: ok, for context, LP: #1740892
<ubottu> Launchpad bug 1740892 in corosync (Ubuntu Bionic) "corosync upgrade on 2018-01-02 caused pacemaker to fail" [Medium,In progress] https://launchpad.net/bugs/1740892
<juliank> cjwatson: The MoM change seems to have worked well :)
<juliank> Better merge prioritisation possible :D
<tsimonq2> Speaking of MoM, now that I know where the source code is and I'm remembering to do it: https://code.launchpad.net/~tsimonq2/merge-o-matic/increase-graph-size/+merge/336265
<tsimonq2> :D
<juliank> +1
<tsimonq2> juliank: Could you merge it then? You're a Core Developer ;)
<juliank> tsimonq2: merged
<juliank> tsimonq2: not sure if it needs somebody to update some infra or not
<tsimonq2> Good point. cjwatson?
<juliank> I should add search filter javascript stuff
<tsimonq2> +1
<juliank> and of course make MoM useful for non-native packages by using unapplied patches states
<juliank> * more useful
<tsimonq2> YES
<tsimonq2> That annoys me SO MUCH
 * tsimonq2 slides juliank a preemptive cold one
<tsimonq2> (er, maybe not the right word, you get it :) )
<juliank> tsimonq2: it's not that easy it seems
<juliank> or it should be
<tsimonq2> juliank: Right, it might involve some tweaking irt patches.ubuntu.com
<tsimonq2> afair it grabs the patches from there and then applies them
<juliank> tsimonq2: https://code.launchpad.net/~juliank/merge-o-matic/skip-patches/+merge/336267
<juliank> tsimonq2: it generates patches.ubuntu.com
<juliank> AFAICT
<tsimonq2> oh
<tsimonq2> juliank: lgtm (although I'm not a ~core-dev so you'll have to merge it yourself :) )
<juliank> I'll leave that up to someone who knows what they're doing
<tsimonq2> Ok
<nacc> slangasek: infinity: when there is a buggy prerm of a package, is there any pattern established for how to handle that in a fix? In this case, it's corosync, where the old package's prerm stops corosync, which ends up stopping pacemaker, and nothing currently starts pacemaker back up. I don't know of a way to determine in the postinst (when using --restart-after-upgrade to dh_installinit) that
<nacc> pacemaker was running when the old prerm ran.
<nacc> my initial stab tried to use /etc/init.d/pacemaker status in the init script, but that's run from the postinst, which means pacemaker is in the stoppe state
<cjwatson> juliank,tsimonq2: deployed MoM r305
<tsimonq2> cjwatson: ack, many thanks
<tsimonq2> cjwatson: How often does cron run there?
<cjwatson> tsimonq2: 05,35 * * * *   /srv/patches.ubuntu.com/code/cron.daily
<cjwatson> though that's subject to locking
<juliank> cjwatson: Opinions on https://code.launchpad.net/~juliank/merge-o-matic/skip-patches/+merge/336267 welcome too, if you have time :D
<cjwatson> not tonight I'm afraid
<juliank> cjwatson: no problem :)
<tsimonq2> cjwatson: thanks
<juliank> tsimonq2: big graphs look better, yeah
<juliank> :D
<juliank> latest merge page has them now
<tsimonq2> I saw :D
#ubuntu-devel 2018-01-18
<Bert_2> Quick question, because of the large security issue announced on https://shibboleth.net/community/advisories/secadv_20180112.txt and the reaction by the debian shibboleth team to backport xmltooling for all their (old)stable repo's https://lists.alioth.debian.org/pipermail/pkg-shibboleth-devel/2018-January/thread.html
<Bert_2> Will Ubuntu follow debian and release for 14.04 and 16.04?
<sarnold> Bert_2: is that this issue? https://bugs.launchpad.net/ubuntu/+source/xmltooling/+bug/1743762
<ubottu> Launchpad bug 1743762 in xmltooling (Ubuntu Bionic) "Security bug in XMLTooling-C before 1.6.3 [CVE-2018-0486]" [Undecided,Triaged]
<Bert_2> Aha, I must have missed that issue
<Bert_2> I think it is, I looked in the morning but this issue has been created later
<Bert_2> sarnold: let me login and tag that we're affected ;)
<Bert_2> sarnold: do you think this will happen? Because I found a few previous requests for backports of security fixes in de shibboleth SP that just died a silent death
<sarnold> Bert_2: ray actually did the work of preparing one backport .. once we get it built and someone reports that it works, it should be released pretty shortly afterwards
<Bert_2> ok, that is really really good news :)
<Bert_2> We checked and normally we aren't affected as we force endpoint and credential communication to https, but we prefer to be sure :)
<Bert_2> Thank you for giving me a heads up :D
<sarnold> Bert_2: from #ubuntu-hardened < sbeattie> rlink: published trusty and xenial. I tweaked the version and changelog a bit.
<Unit193> sarnold: I'm a bit surprised that Debian still hasn't picked up irssi 1.0.6, considering it's a sec update.
<JanC> Unit193: did you file a bug report about it (or did someone else do)?
<Unit193> JanC: Rhonda is pretty close to upstream, usually picks it up quickly and I'm sure knows of this one too.
<JanC> might be on vacation or exceptionally busy or something then?
<Bert_2> sarnold: got the email from launchpad and we've updated all our servers already and token restarted shibd and apache2
<Bert_2> thank you very much for helping along getting this out there :)
<interserve> hello
<interserve> i have a problem when doing apt-get update on trusty 14.04.5
<interserve> all lines Failed to fetch
<blahdeblah> interserve: please use #ubuntu for general technical support
<eoli3n> Hi
<eoli3n> cjwatson: o/
<eoli3n> still on my kickstart install without kicking existing windows install
<eoli3n> a question: does zerombr do something in ubuntu implementation ?
<juliank> AFAICT, 69 merges out of the 276 in https://merges.ubuntu.com/main.html are gray, meaning something's in proposed. awesome.
<eoli3n> juliank: for me ?
<eoli3n> debian-installer : days old 2614, hughh
<juliank> eoli3n: it's totally unrelated to anything you wrote
<eoli3n> yep, but finally it is, that's why its funny :)
<cjwatson> eoli3n: https://paste.ubuntu.com/26409694/
<eoli3n> thx cjwatson
<eoli3n> i have something strange, if you could help a bit it could be great
<eoli3n> https://ptpb.pw/Sj_G
<eoli3n> it still break my windows install...
<eoli3n> without any reason, partition doesn't change
<eoli3n> windows boot and ask for reparation
<eoli3n> recovery i mean
<cjwatson> Sorry, I really can't help with this
<eoli3n> ok np
<juliank> I don't seem to be having success building stuff without running tests.
<juliank> I tried DEB_BUILD_OPTIONS=nocheck debuild --preserve-env
<juliank> I must be doing _something_ wrong
<cjwatson> I've always done debuild -e DEB_BUILD_OPTIONS=nocheck
<juliank> oh, that sounds interesting
 * juliank tries
<juliank> cjwatson: It worked, thanks
<cjwatson> excellent.  I forget why your version doesn't; I'm sure I worked it out once
<cjwatson> (and it's probably at least a doc bug)
<juliank> It's weird.
<ndanl> hi guys
<ndanl> I have a problem ater updating my ubuntu openstack controller
<ndanl> whenever I try to start any of the openstack services I get the errors like this one http://paste.openstack.org/show/646929/
<ndanl> all errors cointain something about monotonic.py
<ndanl> could this be broken in 16.04 xenial
<ndanl> ?
<nacc> ndanl: i think you want #ubuntu-server
<ndanl> thanks
<ndanl> channel is +r
<teward> ndanl: so register?
<teward> (#freenode for help with that though)
<nacc> ndanl: then register?
<bigon> xnox: hey, we had the same idea, I was looking at the upstream plymouth patches just now
<juliank> I should also write a PSA that you can now download stuff in parallel in apt by using mirror://
<juliank> though only in proposed :D
<juliank> And please shout at me if I broke MoM, thanks!Â°
<bigon> xnox: I see several patches in the ubuntu package that could be upstreamed, anyplans to do so?
<xnox> bigon, not really, no. feel free to do so, if you understand them / they are upstream relevant.
<xnox> bigon, i finished merge and uploaded it. it looks good.
<xnox> bigon, there is still some flicker with vt.handoff=1 but oh well. Not sure I'll manage to figure out if that's grub clearing things; or kernel clearing things; or plymouth clearing things.
<bigon> It's indeed not flicker free
<xnox> but i have plymouth to gdm3 flicker free, with vt.handoff=1 and with non-degraded system (i.e. systemctl list-units --failed is empty)
<xnox> anyway, i should get ready to go to volleyball.
<xnox> ok, one more thing, and i'm not gonna touch this anymore.
<mdeslaur> juliank: thanks for the wpa merge!
<juliank> It was surprisingly trivial
<juliank> mdeslaur: happy to.
<juliank> zsh is next
<smoser> sil2100 or bdmurray. rharper and i just uploaded a new curtin to -proposed for artful an xenial.
<smoser> there are few changes from the one there. the primary reason for the new upload is that Zesty tests will fail in our automated tests.
<smoser> (as they try to use the archive which ... is not there)
<smoser> so we disabled those tests as zesty not supported.
<smoser> could one of you re-review those today and let the new version into -proposed ?
<bdmurray> smoser: I can have a look - could you update the bug with new version number?
<smoser> bdmurray: i'll check
<smoser> bdmurray: done.
<smoser> rharper: could you get the combined chagnelog in to that bug ?
<smoser> with bug references ?
<rharper> smoser: yes, lemme update the sru bug
<smoser> https://bugs.launchpad.net/ubuntu/artful/+source/curtin/+bug/1743618
<ubottu> Launchpad bug 1743618 in curtin (Ubuntu Artful) "sru curtin 2018-01-18 - 17.1-11-ga4c9636b-0ubuntu1" [Medium,Fix committed]
#ubuntu-devel 2018-01-19
<FourDollars> How can I switch to X Window System from Wayland on bionic-desktop? I found the original option in GDM has gone.
<tjaalton> FourDollars: I still have it
<FourDollars> That is interesting. I just download the ISO from http://cdimage.ubuntu.com/daily-live/current/ and install the system.
<seb128> FourDollars, if you don't have it it's probably because it thinks your videocard/driver doesn't allow you to use wayland
<FourDollars> seb128: What I am trying to do is to test the radeon driver. XD
<tjaalton> amdgpu pro?
<FourDollars> radeon
<tjaalton> ok, should work
<FourDollars> https://bugs.freedesktop.org/show_bug.cgi?id=103370 This one
<ubottu> Freedesktop bug 103370 in DRM/Radeon "`vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)" [Normal,New]
<FourDollars> OK. After I install gnome-session-flaskback, I can see the option now.
<FourDollars> I know what happened. Because of the radoen and amdgpu module issues, there is no wayland support. It was Xorg (llvmpipe) by default and no other option.
 * juliank just merged transmission to check out the new MoM results, I hope the desktop team does not mind
<juliank> Apparently that also fixes the CVE already fixed in artful, so yay?
<Unit193> juliank: Debian #887725
<ubottu> Debian bug 887725 in transmission-qt "transmission: New upstream release 2.93" [Normal,Open] http://bugs.debian.org/887725
<juliank> Unit193: it's not released yet :D
<juliank> Anyhow, I have no long term transmission interest, I just wanted to check the MoM output, and it ended up being a few seconds to then build it too
<TJ-> I've a 16.04 system that came back from "systemctl suspend" within a few seconds but still thinks it is asleep (e.g. "nmcli gen" reports "asleep" and therefore no networking, log files not being updated). Before I reboot it is there anything I should look at to capture useful info for a bug report and/or try to wake it up?
<cpaelzer> xnox: hey I'd need your help/guidance on libnss that you touched recently
<cpaelzer> it has headers like /usr/include/nss/hasht.h which are backed by a .so in a subdir /usr/lib/x86_64-linux-gnu/nss/libfreebl3.so
<cpaelzer> those are usually not meant to be direct includes, but it has symbols for it and everything
<cpaelzer> it currently breaks the change of a lib usage that is not in main to use nss for this instead
<cpaelzer> so I wonder if that lib should maybe not be in the subpath, but actually directly in /usr/lib/x86_64-linux-gnu/
<cpaelzer> xnox: slangasek pointed out that you touched it recently, so we had some hope you might have a hint on this
<cpaelzer> as it seems not really to be ment for dlopen only (symbols/headers available "normally")
<cpaelzer> I'm on sprint, so latency to reply is high, but it would be great to hear your insight on this
<xnox> cpaelzer, i will look into it. It does seem odd.... unless like libnss.so itself knows how to dlopen extra things.
<xnox> can't recall anything special around it, off the top of my head.
<cpaelzer> xnox: thanks for taking a look
<cpaelzer> xnox: if it is meant to be internal only ok, but if not making it properly public would be great
<cpaelzer> xnox: ping (or mail) me once you have a more detailed opinion then after checking it
<caravena> Hello: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1743872/comments/8
<ubottu> Launchpad bug 1743872 in linux (Ubuntu) "Not work 802.11ac WLAN Adapter" [Medium,Incomplete]
<mitya57> Hi! Autopkgtest retry links give internal server errors, e.g.: https://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=amd64&package=sasview&trigger=mathjax%2F2.7.2%2Bdfsg-1
<mitya57> Is it only me, or a global issue?
<Laney> Retries are offline for now - should be back before too l ong
<mitya57> ok
<alexarnaud> Hello all
<alexarnaud> In the last days of december jbicha tells me to contact you to upload the new BRLTTY package on the Ubuntu repository.
<alexarnaud> I've filled a bug about that : https://bugs.launchpad.net/ubuntu/+source/brltty/+bug/1741070
<ubottu> Launchpad bug 1741070 in brltty (Ubuntu) "New upstream release 5.5" [Undecided,New]
<xnox> cpaelzer, i am failing to understand what it is; but on e.g. Fedora, they have a separate source package nss-softokn which does have binary packages nss-softokn-freebl[-devel] which does ship those libs as normal public libraries; they also have some dracut snippets to include those into initramfs....
<xnox> they have .chk files and can be used in FIPS mode
<xnox> not sure about /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so what that one is yet, as it does not appear to be anywhere.
<xnox> oh maybe that one is in the base nss package, one sec.
<caravena> Hello: https://bugs.launchpad.net/ubuntu/+source/rtl8812au/+bug/1744311
<ubottu> Launchpad bug 1743872 in linux (Ubuntu) "duplicate for #1744311 "0bda:a811" - Not work 802.11ac WLAN Adapter" [Medium,Incomplete]
<caravena> Help my, thanks!
<cpaelzer> xnox: ok, but as TL;DR I read your findings as "it should be in a normal path"
<juliank> alexarnaud: so I can try to merge the new brltty, but I don't think I can really test it
<juliank> So I guess let's hope I don't break anything or somebody notices.
<kzh> \j #tmux
<kzh> oops how embarassing
<cpaelzer> xnox: I'll drop off soon, to not miss the case I filed bug 1744328
<ubottu> bug 1744328 in nss (Ubuntu) "libfreebl3.so should be public, not in the nss subdir" [Undecided,New] https://launchpad.net/bugs/1744328
<tomreyn> mpt: just a heads up (in case you are swamped by bug mails) - this was just a topic on -hardened, prompting me to post an update: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/319146
<ubottu> Launchpad bug 319146 in update-manager (Ubuntu) "When a release reaches End-of-Life, update manager should show EoL status and provide a link with working procedures and more information." [Wishlist,Confirmed]
<mpt> tomreyn, thanks. Iâd like to work on it, but if anyone else wants to contribute design and/or code theyâre more than welcome
<tomreyn> mpt: i'm afraid i won't personally have the resources to do so, just happen to have a day off work today...
<tomreyn> i appreciate your openness to external contribution, however.
<alexarnaud> juliank: I could test the new release.
<juliank> alexarnaud: It's in bionic-proposed (or about to be)
<alexarnaud> They is a way to simulate a braille display on QEMU. I've a physical one.
<alexarnaud> juliank: So do you wait a test to switch from bionic-proposed to main, isn't it ?
<alexarnaud> thanks
<juliank> Well, things will migrate from bionic-proposed to bionic eventually
<juliank> but right now that's all blocked with builders offline
<alexarnaud> OK, I'll test.
<ejat> hi ..anyone can help to look at bug 1728354
<ubottu> bug 1728354 in ntfs-3g (Ubuntu) "ntfs: unsupported reparse point" [Undecided,Confirmed] https://launchpad.net/bugs/1728354
<nacc> in a maintainer script, which is 'set -e', is there a best practice to avoid having a status check on a service (sysv or systemd) which might return non-zero not cause the script to fail? Is it appropriate to set +e for the added stanza and then set it back?
<sarnold> I often see || true
<nacc> sarnold: ah good thinking
#ubuntu-devel 2019-01-14
<joelkraehemann> hi all
<joelkraehemann> https://packages.ubuntu.com/search?keywords=gsequencer&searchon=names&suite=disco&section=all
<joelkraehemann> ^^ I wanted to do a sync request but it tells me it has the current version of debian ...
<joelkraehemann> So is the above showed information of packages.ubuntu.com just wrong
<Laney> joelkraehemann: not exactly, the package is in disco-proposed but not disco proper: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer (read https://wiki.ubuntu.com/ProposedMigration/ for more information on the process)
<joelkraehemann> Laney: the test runner crashed
<Laney> sounds like a thing to be fixed
<joelkraehemann> Laney: it would be nice to obtain stack-traces and tell upstream
<joelkraehemann> I do now a i386 chroot
<rbasak> joelkraehemann: unfortunately the volume of test failures is so large that it isn't practical to examine them all, isolate if they are introduced by the distribution or if they are genuine upstream bugs, obtain stack traces and report upstream. It's not practical :-/
<rbasak> We do what we can.
<joelkraehemann> rbasak: do you know systemd-coredump?
<rbasak> No.
<joelkraehemann> if a process crashes you can obtain a stack trace using `coredumpctl debug`
<rbasak> I do know how to obtain stack traces, thanks.
<joelkraehemann> You don't have to run within a gdb session
<joelkraehemann> and obviously you didn't
<joelkraehemann> I just run `libtool --mode=execute gdb ags_check_system_functional_osc_server_test`
<joelkraehemann> it passed in my chroot
<joelkraehemann> ... may be because I use bionic
<doko> cjwatson: do you remember why we need pbuilder in main? that dates back to 2008 ...
<cjwatson> doko: more like 2004; it was from the very first seed commit (the history is just obscured slightly by the platform split)
<cjwatson> doko: IMO sbuild is sufficient and we don't need two
<doko> ok, will demote
<joelkraehemann_> FYI: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919269
<ubottu> Debian bug 919269 in autopkgtest "autopkgtest: provide stack-traces of crashed integration tests" [Normal,Open]
<ahasenack> sil2100: hi there, bileto still seems to be a bit broken, it times out after SSO redirects back to it, do you know if #is is working on it? Should we file an RT?
<xnox> ahasenack, are you logged in, in the autopkgtest.ubuntu.com as well?
<xnox> i find that bileto -> autopkgtest -> login flow is borked, but one can work around that by loggin into autopkgtest.u.c directly
<ahasenack> tryng
<ahasenack> I don't see a login link in autopkgtest.u.c, nor my name indicating I'm already logged in
<ahasenack> going to bileto.u.c now, it shows me logged in
<ahasenack> but I see a bunch of empty tickets
<ahasenack> they look like attempts to create tickets that failed perhaps
<Laney> that's not really the case, there are just links from excuses to request.cgi
<Laney> no particular login flow, so that sounds like a red herring to me
<sil2100> ahasenack: hey, yeah, it's still broken, I don't think IS is looking into it as last time they were not able to figure out what's the reason
<sil2100> ahasenack: I was looking into it as well but then got preempted out of it
<sil2100> ahasenack: could you fill in an RT for tracking?
<ahasenack> sil2100: yeah, last time was kind of fire fighting, we may need a ticket
<sil2100> ahasenack: the thing that's broken are mostly redirects, for reasons yet unknown
<sil2100> So it's all usable, but one needs to remember about that, and refresh the page for instance after creating a ticket
<sil2100> And then modifying the ticket info
<sil2100> Same for other operations
<sil2100> geh
<ahasenack> I see
<ahasenack> not just login then
<ahasenack> I'll file the rt
<sil2100> I'll try to look into it again today as well, will need a moment for that though as those are the parts of code I don't know much about
<sil2100> And well, Robert's vision of elegant code doesn't really help with readability
<ahasenack> sil2100: filed,  you are cc'ed
<ahasenack> 1thx
<sil2100> ahasenack: thanks!
<juliank> So apparently, merging translations from master is as simple as
<juliank> for i in po/*.po; do msgmerge -q --previous <(git show master:$i) $i | sponge $i; done
<juliank> hmm
<juliank> this made one string fuzzy that was not fuzzy before
<juliank> for i in doc/po/*.po po/*.po; do msgcat --use-first <(git show master:$i) $i | sponge $i; done
<juliank> this + then running update-po (that is, msgmerge) works better
<rbasak> jbicha: looks like libical3 can be synced now. I'll do that in a bit unless I'm missing something.
<rbasak> (or you object)
<jbicha> rbasak: mismatched tarball so you can fakesync if you want
<rbasak> :(
<rbasak> I was just driving by. I've never done a fakesync so I might leave it for a time when I can pay more attention.
<Laney> rbasak: syncpackage can do those, if you're interested
<jbicha> rbasak: it's good practice if you want to try it. You'll just have to use the --fakesync option (it suggests it when necessary) and then manually dput the result
<rbasak> Oh OK, thanks. AFAICT I can just run it then for this case?
<Laney> You end up with a source package that you can look at
 * rbasak tries
<rbasak> It's just the lack of supervision here that vexes me a little. I usually take great care in reading all possible docs when doing something new :)
<rbasak> OK I've done sufficient debdiffing of the results I think.
 * rbasak uploads
<rbasak> Thank you for your help. Now I understand the tooling it seems far more straightforward and less error prone than I had expected.
<bdmurray> superm1: I'd like to see something on StableReleaseUpdates re fwupd being a special case so other SRU team members also know about it and we have a reference.
<joelkraehemann> hi all
<joelkraehemann> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
<joelkraehemann> ^^ I have tried to reproduce using LXC but without success
<joelkraehemann> http://paste.debian.net/1060526/
<joelkraehemann> my only idea for is, the tests share a NIC and the OSC server gets a conflict ...
<joelkraehemann> or something messes with the address 127.0.0.1
<joelkraehemann> it would be interesting to run the integration tests with isolation machine.
<superm1> bdmurray, which area should I raise that discussion point?
<superm1> because changing a wiki is one thing, but I feel it probably needs to be discussed
<bdmurray> superm1: The wiki is the way to go - https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
<superm1> perfect thanks, I'll do that
<bdmurray> superm1: I'd be happy to review the plan
<joelkraehemann> Laney: are you still here?
<joelkraehemann> does anyone have the right to rerun the tests?
<joelkraehemann> please trigger only one container, e.g. i386
<joelkraehemann> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
<joelkraehemann> This time, I was running the ags_check_system_functional_osc_server_test in 2 different containers ...
<joelkraehemann> As the amd64 container completed, I have got SIGPIPE in i386 container
<joelkraehemann> http://paste.debian.net/1060540/
<joelkraehemann> as running alone in i386 it passes
<superm1> bdmurray, okay: https://wiki.ubuntu.com/firmware-updates
<superm1> let me know if I should just email the list instead
<bdmurray> superm1: I think it'd be worth mentioning fwupdate-signed. Also could you elaborate on "OEMs ... can place information into the metadata"?
<superm1> Sure thing
<superm1> bdmurray, ok modified
<bdmurray> superm1: Why should the ageing requirement be waived?
 * jbicha squints at https://launchpadlibrarian.net/406229560/folks_0.11.4-1ubuntu1_0.11.4-1ubuntv1.diff.gz
#ubuntu-devel 2019-01-15
<doko> gah ...
<doko> $ ls -l /usr/bin/libtool
<doko> -rwxr-xr-x 1 root root 0 Jan 12 14:10 /usr/bin/libtool
<Faux> libtool is installed? You poor soul.
<doko> https://launchpad.net/ubuntu/+source/ruby2.5/2.5.3-3ubuntu2  shows certificate failures during the build ...
<doko> xnox, are you guilty?
<vorlon> did the embedded certificates expire?
<xnox> fun
<xnox> doko, well, it's not _my_ certificates ;-)
 * doko hates d-shlibs
<joelkraehemann> hi all, I think there is a problem with the build container's networking stack ...
<joelkraehemann> ^^ I try to prove my assumption
<joelkraehemann> Laney: If my assumption is correct then you have fix it
<joelkraehemann> ^^ to
<Laney> joelkraehemann: I made it happen in an autopkgtest-buildvm-ubuntu-cloud built VM, you might want to try that
<Laney> e.g. autopkgtest-buildvm-ubuntu-cloud -r bionic --arch i386
<Laney> (s/bionic/disco/ ...)
<mdeslaur> jbicha: FYI, policykit: https://gitlab.freedesktop.org/polkit/polkit/merge_requests/17
<jbicha> mdeslaur: yes, I saw pitti cherry-picked it to Debian, we just need to add https://gitlab.freedesktop.org/polkit/polkit/commit/6cc6aafee135 on top for Debian/Disco
<mdeslaur> ack
<joelkraehemann> Laney: I have already 2 different containers up and running, one amd64 and another i386
<Laney> k
<BenderRodriguez> Laney: k
<seb128> bdmurray, can you unblock the gvfs/cosmic SRU as discussed the other day?
<seb128> simpoir, hey, I noticed that https://launchpad.net/ubuntu/+source/landscape-client/18.01-0ubuntu4.1 is waiting verification for a way, maybe you could try to verify/find smeone to verify that SRU?
<seb128> bdmurray, oh, and bionic as well
<joelkraehemann> where are the debugging symbols?
<joelkraehemann> don't you provide any?
<joelkraehemann> https://wiki.ubuntu.com/Debug%20Symbol%20Packages
<simpoir> seb128: thanks. I'll poke a few people to help with the verification.
<seb128> simpoir, thanks
<bdmurray> seb128: yeah, I'll do that today
<bdmurray> joelkraehemann: They should be at ddebs.ubuntu.com
<seb128> bdmurray, thx
<joelkraehemann> kill -STOP $(pidof ags_functional_audio_test)
<joelkraehemann> then enter the autopkgtest directory
<joelkraehemann> ^^^doesn't work
<juliank> seb128, xnox regarding the duplicity autopkgtest failure. it's creating /tmp/adt/source and then backing it up to /tmp/adt/backup, then restoring to /tmp/adt/restore. The files seem to be going missing. Could it be that systemd-tmpfiles is running a cleanup job on /tmp while we're running the test/duplicity?
<juliank> Laney: ^
<xnox> juliank, hm.... do you reboot as well?
<juliank> because /tmp/adt/source seems to be missing too after duplicity ran, but it was backing that up
<seb128> good question, I don't know enough about systemd-tmpfiles to say
<xnox> juliank, it shouldn't be running if the system is booted (ie. systemctl is-system-running is running|degraded)
<juliank> xnox: only autopkgtest [19:37:10]: rebooting testbed after setup commands that affected boot
<juliank> then it installs test dependencies and runs the test
<juliank> it's about 20 seconds from boot to test run
<juliank> On the other hand, it says: SourceFiles 1
<juliank> SourceFileSize 7 (7 bytes)
<juliank> which seems wrong too
<juliank> Oh
<juliank> xnox: I assume it's copying the literal /bin symlink on a usrmerged system and backing that up
<juliank> hence the failure
<juliank> it does cp -r /bin $TMPDIR/source
<juliank> it should do cp -a /bin/ $TMPDIR/source
<juliank> ok, that should be fixed
<juliank> sorry for the noise :)
<seb128> juliank, ah, that would explain ... do you fix it or want me to handle that?
<juliank> seb128: I uploaded a fix 4 minutes ago :)
<seb128> great, thx!
<Laney> juliank: that was a quick test run ð
<juliank> Laney: I just tested my assumption with a sample symlink :)
<seb128> I didn't know that /bin and /bin/ were different things, learning every day!
<juliank> seb128: I think it's an odd detail most people are not aware of
<juliank> it's not as bad as rsync, though
<juliank> like "rsync bin foo", creates bin/foo, but "rsync bin/ foo" copies stuff from inside bin to "foo"
<juliank> um creates foo/bin of course
<juliank> that's utterly crazy
<juliank> Laney: Oh, and I need to clean that up now
<joelkraehemann> Please trigger rerun autopkgtest of i386 for
<joelkraehemann> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
<juliank> ok
<joelkraehemann> ^^ I don't have permission to do so
<Laney> why?
<juliank> yeah, why?
<Laney> what's changed that might make it pass?
<juliank> only amd64 has passed anyway
<juliank> if there's a fix, I'd assume it fixes all !amd64, not just i386
<juliank> joelkraehemann: ^
<juliank> I mean, it segfaults
<joelkraehemann> Yesterday, I was able to reproduce SIGPIPE
<joelkraehemann> today, not anymore ...
<joelkraehemann> juliank: It passes on my container anyway
<joelkraehemann> without any segfault
<Laney> I told you earlier that I ran it in a test VM and it failed in that way for me
<Laney> we have an insane test backlog atm, you won't get your result for a long time - suggest doing what I said earlier
<juliank> Laney: whoa, the queue is really intense
<juliank> Laney: also, we wanted to subscribe me to autopkgtest emails or something I think
<juliank> I don't share the email pain atm
<Laney> feel free to do a merge proposal to autopkgtest-cloud if you want to join that party
<Laney> the part of people who delete one email an hour
<Laney> party*
<juliank> ugh, steam lock
<joelkraehemann> I give your cloud image a try
<juliank> Laney: I do wonder how useful it will be, given that I can't commit to the repositories :)
<Laney> it's possible to contribute without being able to commit
<Laney> that's usually what people do first :P
<juliank> I know
<Laney> btw, I ran your new duplicity test and it failed because the cp copies broken symlinks and that makes diff not work
<juliank> something is odd
<juliank> Laney: lol
<Laney> sorry for being suspicious enough of you to run it myself :-)
<juliank> Laney: something is odd here: https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/361791
<juliank> Laney: it shows your "lxd too" commit in the merge, but I just fetched that from origin...
<Laney> weird
<juliank> cjwatson, wgrant: ^
<Laney> it doesn't show on https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+ref/master
<Laney> probably need to rescan, I can do that
<juliank> oh well, ok
<Laney> there we go, sort of (I forgot how to regenerate the diff)
<juliank> +1
<Laney> lp.load('~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/361791').scheduleDiffUpdates()
<juliank> whoa magic
<superm1> bdmurray, sorry copy and paste error - that wasn't intended.  I just corrected it
<bdmurray> superm1: alright, thanks
<joelkraehemann> Laney: you were right. It crashes :/
<joelkraehemann> Laney: So guess what? My tests eat your RAM ...
<joelkraehemann> as passing --ram-size=8192 to autopkgtest-virt-qemu it just passed
<sivang> hi all
<sivang> does the postgresql server snap enables me to have an isolated execution of PG such that I can restore my system to prestine state before installation?
<sivang> Most of the snaps I can install tell me they're in classic mode, hence full isolation is not possible so I'm curious to see how to enjoy the isoation feature...
 * gQuigs is too excited with what is the final blocker to dropping python2 from images is almost here -  Samba 4.10 RC1 Released: Adds Offline Domain Backups, Now Defaults To Python 3 | https://www.phoronix.com/scan.php?page=news_item&px=Samba-4.10-RC1-Released
<sivang> gQuigs: oh niceee
<sivang> python2 should be left to decay gracefully
#ubuntu-devel 2019-01-16
<nehaljwani> Hi! I am creating a debian package and adding it to a repo like this: https://paste.ubuntu.com/p/rVDBRDYpCk/  But when I install it , apt list --installed shows: <my-package>/unknown . What could be the reason?
<nehaljwani> How do I remove 'unknown'?
<nehaljwani> Found the problem. Suite: section was missing from conf/Distributions . Shouldn't apt fall back to use codename? Eh
<rbalint> ginggs, how about passing --jobs 4 in mercurial's debian/tests/testsuite to speed it up and let it pass on arm64, too?
<ginggs> rbalint: did you try it?
<rbalint> ginggs, not yet, but should work
<rbalint> ginggs, i'm just asking since you touched the package last and did not want to upload without a ping
<rbalint> ginggs, if you pass i'm giving it a try
<ginggs> rbalint: go ahead :)
<rbalint> ginggs, ack
<ginggs> rbalint: please fix the breaks while you are there
<ginggs> mercurial-git (<< 0.8.12-1~) as in changelog instead of mercurial-git (<= 0.8.12-1~)
<rbalint> ginggs, ok
<ginggs> rbalint: thanks!  i only noticed the typo now
<abeato> seb128, hey, any ETA for https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1781597 in bionic?
<ubottu> Launchpad bug 1781597 in network-manager (Ubuntu Bionic) "[SRU] WoWLAN settings are not supported" [Wishlist,Triaged]
<seb128> abeato, hey, we need to clear off the current SRU first, see https://community.ubuntu.com/t/call-for-testing-network-manager-1-10-14-in-bionic/9424 ... maybe you can help verifing that one? :)
<rbasak> bdmurray: did you miss doing SRU paperwork for your update-manager upload, or is this  somehow special?
<abeato> seb128, sure think - had not seen that
<seb128> abeato, thx
<xnox> doko, rbasak - any volunteers to figure out why nodejs builds in debian, but not ubuntu? v10 is the LTS with openssl 1.1.1 so it would be nice to have it.....
<xnox> and we are getting a tonne of node things in, which i guess target the new nodejs =/
<bdmurray> rbasak: it doesn't do anything per se just provides a new variable which ubuntu-release-upgrader will use and I still need to upload that
<rbasak> bdmurray: it should still have SRU paperwork before uploaded then though, no?
<rbasak> Separately, I suggest that it be uploaded/reviewed at the same time as the ubuntu-release-upgrader SRU then. If for example it turns out further changes are needed, then we'll have wasted an SRU.
<rbasak> (and regression risk, etc)
<bdmurray> rbasak: yes, it should still have the paperwork
<rbasak> OK, I'll leave it there for now, thanks. Sorry, I thought your first reply was implying that it wasn't needed.
<LocutusOfBorg> xnox, doko rbasak I might have a nodejs clue
<LocutusOfBorg> let me see if I can prove it
<LocutusOfBorg> tl;dr: upload nodejs with testsuite disabled, and then reupload with testsuite enabled
<LocutusOfBorg> it might be due to it using something old in the system
<LocutusOfBorg> it might be a chicken and egg bootstrap issue
<LocutusOfBorg> testsuite not using everything from the build directory but picking up something in the system
<juliank> How did my email from @gmail get to ubuntu-devel? That's odd
<juliank> I mean, that list is subscriber only I thought
<xnox> LocutusOfBorg, i'm testing that locally at the moment, on a fast ppc64le builder
<rbasak> AIUI posting is restricted to Ubuntu developers onlyu
<rbasak> Presumably a Launchpad team.
<xnox> LocutusOfBorg, please don't abuse our builders for this, especially if we don't know if it will work =)
<rbasak> Does Launchpad know about your gmail address?
<LocutusOfBorg> xnox, it is in a ppa, lower priority I would hope
<LocutusOfBorg> juliank, how did you upload a build2 package without a build1 one?
<xnox> LocutusOfBorg, also possibly better to do it in a bileto PPA, such that archive is not exposed to the testsuite-less build.
<xnox> LocutusOfBorg, ppa is fine, cool =)
<LocutusOfBorg> xnox, sure, of course
<LocutusOfBorg> but meh, I plan to redo in bileto in case it works :)
<juliank> LocutusOfBorg: the build1 was in the bileto ppa
<LocutusOfBorg> ah ok so you followed my advice
<LocutusOfBorg> I don't see the "grouped with ppa:" in update excuses page... strange
<juliank> LocutusOfBorg: Yeah, because I published without doing the bileto building stuff I guess
<LocutusOfBorg> ah ok
<LocutusOfBorg> nice to know
<LocutusOfBorg> thanks
<LocutusOfBorg> nice the check override didn't work
<LocutusOfBorg> xnox, how did you do it?
<LocutusOfBorg> -	-ln -s /usr/bin/node node
<LocutusOfBorg> -	mkdir -p $(NODE_TEST_DIR)
<LocutusOfBorg> -	make $(DEB_MAKE_CHECK_TARGET)
<LocutusOfBorg> -	rm -f node
<LocutusOfBorg> -	rm -rf $(NODE_TEST_DIR)
<LocutusOfBorg> +	echo "no testsuite, everybody happy!"
<LocutusOfBorg> +	#-ln -s /usr/bin/node node
<LocutusOfBorg> +	#mkdir -p $(NODE_TEST_DIR)
<LocutusOfBorg> +	#make $(DEB_MAKE_CHECK_TARGET)
<LocutusOfBorg> +	#rm -f node
<LocutusOfBorg> +	#rm -rf $(NODE_TEST_DIR)
<LocutusOfBorg> this didn't work
<LocutusOfBorg> I'm adding this: -DEB_MAKE_CHECK_TARGET = $(exp-relax-check) test-ci-js
<LocutusOfBorg> +#DEB_MAKE_CHECK_TARGET = $(exp-relax-check) test-ci-js
<teward> did you intend to use a pastebin there LocutusOfBorg or no?
<teward> just saying.
<LocutusOfBorg> yep :/
<LocutusOfBorg> bad copy-paste, lots of the lines were useless
<teward> cool cool.
<LocutusOfBorg> I just wanted to copy the -make +#make line :)
<teward> :)
<LocutusOfBorg> why cdbs sucks that much?
<LocutusOfBorg> :/ maybe its just me, but I feel lost everytime
<LocutusOfBorg> or maybe, debhelper, why you so simple?
<xnox> LocutusOfBorg, i didn't bother patching the sources, and i'm just inside a schroot shell. However, no builds yield.
<xnox> LocutusOfBorg, at the moment doing a stock rebuild in sid-amd64 fails. So I think it is now busted in Debian too.
<xnox> LocutusOfBorg, once this finishes I will file a FTBFS bug report.
<LocutusOfBorg> lol
<LocutusOfBorg> interesting
<LocutusOfBorg> http://debomatic-amd64.debian.net/distribution#unstable/nodejs/10.15.0~dfsg-8/buildlog
<LocutusOfBorg> lets see
<xnox> LocutusOfBorg, i also wonder if we should just wait for 10.15.1
<xnox> https://github.com/nodejs/node/commit/d3c07bd9a81f5ea45a26325be74c93a94b60b243
<LocutusOfBorg> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nodejs.html
<LocutusOfBorg> I scheduled new builds there, so you can use them in your bug report
<LocutusOfBorg> xnox, seems like there are no commits wrt our issue
<LocutusOfBorg> we had 58 failing tests, with acorn bootstrapped we are down to 3
<xnox> LocutusOfBorg, there are dozens of tests: commits
<LocutusOfBorg> and I already looked upstream with git log... nothing interesting wrt async
<LocutusOfBorg> and exceptions
<xnox> https://github.com/nodejs/node/pull/25346
<xnox> better overview of changes
<LocutusOfBorg> at least nothing obvious
<xnox> 155 "test:"
<LocutusOfBorg> and nothing with async :)
<LocutusOfBorg> something with assert is there...
<xnox> i'll try building that branch in a second.
<LocutusOfBorg> that would be awesome
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<LocutusOfBorg> s390x build is already there
<LocutusOfBorg> the notest one
<LocutusOfBorg> as soon as everything is published I upload the new one
<LocutusOfBorg> xnox, http://debomatic-amd64.debian.net/distribution#unstable/nodejs/10.15.0~dfsg-8/buildlog
<LocutusOfBorg> debian is good
<LocutusOfBorg> test-asser is ok
<LocutusOfBorg> it fails another test, fs related (maybe its DebOmatic to blame here)
<xnox> LocutusOfBorg, what is DebOmatic btw? never used it before.
<LocutusOfBorg> an sbuild instance for ubuntu/debian/arch
<LocutusOfBorg> you just ask an account and dput
<LocutusOfBorg> http://debomatic-amd64.debian.net/distribution#unstable/nodejs/10.15.0~dfsg-8/buildlog
<LocutusOfBorg> it does blhc, autopkgtest, publish
<LocutusOfBorg> for a lot of architectures
<LocutusOfBorg> (via qemu)
<LocutusOfBorg> you can also setup an instance locally btw
<LocutusOfBorg> https://packages.qa.debian.org/d/debomatic.html
<xnox> cute
<LocutusOfBorg> it is sbuild for dummies with a lot of javascript and automation via web interface :d
<xnox> LocutusOfBorg, so, to me the check target is bad.
<xnox> instead of testing just-built node, it tests system node, during normal package builds.
<LocutusOfBorg> it works in debian
<xnox> but that bit is added, for autopkgtests, where we do want to test the system node
<xnox> but it should be guarded with a test for $$AUTOPKGTEST_TMP
<xnox> variable for example.
<LocutusOfBorg> so my test disable/enable might work then?
<LocutusOfBorg> I see something wrt experimental in rules file
<xnox> and if you look further up in the debian/rules, you will see that test results are ignored when building for experimental or unreleased.
<LocutusOfBorg> different testsuite
<LocutusOfBorg> yes exactly
<xnox> it add '-i' to ignore results.
<LocutusOfBorg> -i
<LocutusOfBorg> that one yes
<LocutusOfBorg> I got it too
<LocutusOfBorg> I was going to add "disco" :)
<xnox> my premise, is that well the just compiled node is never tested, which is bad.
<LocutusOfBorg> but it would have been slower
<xnox> i'd want to fix that.
<LocutusOfBorg> xnox, sure, worth a bug, let me see if re-enabling and reuploading against this one works
<LocutusOfBorg> so we are sure about our claims
<LocutusOfBorg> it makes sense since the debian no-change rebuild on debomatic works well
<LocutusOfBorg> (modulo the fs error, that is unrelated)
<xnox> i wonder if my builds fail a lot more due to aggressive parallelism
 * xnox was building & testing with -j 120; trying with -j 80 now
<xnox> time for starbucks
<LocutusOfBorg> LOL
<teward> *sips his 6th cup of coffee*
<LocutusOfBorg> https://bileto.ubuntu.com/#/ticket/3599
<LocutusOfBorg> xnox, ^^
<xnox> i still don't want to upload like that. i really want for the just built node to be tested, rather than always testing the wrong node
<xnox> but i guess we want to build _a_ nodejs somehow
<LocutusOfBorg> but at least we can unblock a lot of stuff
<LocutusOfBorg> and then with some more time, fix it properly
<LocutusOfBorg> I'm pretty sure debian maintainer already tried this, and they might failed to implement for good reasons
<jbicha> it'll give autopkgtest something to do too :) :)
<Laney> be kind to the test infrastructure please
<Laney> don't queue pointless things at the moment
<Laney> you can run tests locally...
<LocutusOfBorg> Laney, this is why I'm using bileto
<Laney> what is?
<LocutusOfBorg> I did upload nodejs on silo so we don't run the testsuite twice
<smoser> xnox: around ? or maybe rharper knows.
<smoser> i want to make systemd-resolve search a network device tun0 for multiple domains
<smoser> (basically wanting to set a dns-search)
<smoser> but
<smoser>  systemd-resolve  --interface=tun0 "--set-domain=cisco.com insieme.local"
<xnox> smoser, sure. use resolvctl or the systemd-resolved command line.
<xnox> smoser, `cisco.com insieme.local` is not a valid search domain.
<smoser> but that then escapes the ' '
<xnox> (single)
<xnox> i think you want:
<xnox> systemd-resolve  --interface=tun0 --set-domain=cisco.com --set-domain=insieme.local
<xnox> but let me double check the code
<smoser> where does resolvectl come from ?
<xnox> new-ish replacement ofr systemd-resolve
<xnox> in more recent releases resolctl is the new world order.
<smoser> ah. /me no longer runs development release. back on 18.04
<smoser> multiple --set-domain does seem to work
<smoser> but i'm not sure that that is plugged correctly trhough network-manager settings for the vpn.
<xnox> smoser, network-manager is broken and sends literal "foo.com,example.com" instead of a /list/ of values.
<smoser> right
<xnox> smoser, i think this has been fixed in disco now, but needs an SRU.....
<smoser> oh nice.
<smoser> i think you're just trying to get me to go back to development release though
<smoser> :)
<juliank> Seems there is a bug in the unbound package, just installing it enables the apparmor profile, but the profile is enabled only after the service is started, meaning the service does not have an apparmor profile loaded on first start. hmm
<juliank> yup, reported to Debian :)
<cornfeedhobo> heeeyyy, i just found a broken line in the AMI released.txt
<cornfeedhobo> http://uec-images.ubuntu.com/query/trusty/server/released.txt
<cornfeedhobo> search for "paravirtualtrusty"
<cornfeedhobo> there is a missing new line
<sarnold> cornfeedhobo: heh, nice find
<sarnold> Odd_Bloke: /lastlog cornfeedhobo   -- http://uec-images.ubuntu.com/query/trusty/server/released.txt < cornfeedhobo> search for "paravirtualtrusty"
#ubuntu-devel 2019-01-17
<LocutusOfBorg> xnox, both our claims were wrong...
<LocutusOfBorg> nodejs still reproducible in debian, and the bootstrap I did failed badly
<Odd_Bloke> philroche: o/ Could you take a look at cornfeedhobo's issue above. please?
<rbasak> TIL: less relies on file extensions instead of a magic. Read a text file that happens to end in ".deb" and it fails invisibly :-/
<LocutusOfBorg> xnox, upload with testsuite disabled? do you have any news?
<LocutusOfBorg> :/ report upstream=
<LocutusOfBorg> ?
<LocutusOfBorg> I'm out of ideas
<xnox> LocutusOfBorg, i did open a bug in debian.
<xnox> LocutusOfBorg, i cannot rebuild successfully nodejs, in debian sid/unstable, on ubuntu host.
<xnox> LocutusOfBorg, i wonder if it is an ubuntu kernel bug; or like new kernel issue.
<teward> xnox: what's your build host?  ANd are yo just doing a bog-standard rebuild of an existing package? I can test on my 18.04 (and 16.04 older builder) infra.
<teward> (happy to loan cycles to test-build things)
<teward> s/existing package/nodejs
<teward> (in the off chance you need another kernel/testbed i have those cycles available)
<xnox> teward, this fails for me on disco host $ sbuild -A -d sid nodejs_10.15.0~dfsg-8
<xnox> on amd64 & ppc64el
<xnox> teward, it would be nice if you can check if this works for you, or also fails - $ sbuild -A -d sid nodejs_10.15.0~dfsg-8
<teward> xnox: i don't have a disco host but I do have an 18.04 host.  standby while I finish populating the sid chroot
<xnox> teward, yeah, 18.04 as a host is also interesting.
<teward> xnox: running now, standby
<teward> (god I love having 32GB of RAM heh)
<LocutusOfBorg> I'm building nodejs with pbuilder and sid environment on ubuntu amd64 18.04
<LocutusOfBorg> xnox, ^^
<LocutusOfBorg> and also a disco build on same host
<teward> i'm running a sid sbuild chroot on an amd64 18.04 host, but also spinning up a ppc64el qemu-static sbuild chroot as well.
<teward> xnox: looks like it's in the compilation steps now, will provide a copy of the logs once it's complete.
<teward> i am seeing warnings and such going by at blazing speeds though
<teward> but so far I haven't hit any critical build failures yet as far as I can tell
<xnox> teward, it's in the test-suite where it fails... it builds 'ok'
<xnox> teward, can take like 2h =)
<teward> xnox: i'd expect it to.  you are aware Debian triggers a lot of autotest regressions as well right?
<teward> even on their infra?
<teward> except on *every* arch
<xnox> teward, sure, but i'm not sure if they use e.g. stable kernel.
<teward> oops my bad, on multiple other node autopkgtests I mean on amd64
<teward> right
<teward> xnox: considering i'm stuck here until 17:00 at work (and it's 11:52 right now) 2 hours of a background task is nothing :P
<teward> though in theory 12 threads of CPU are probably going to increase the performance lol
<teward> looks like it's starting some of its tests now
<teward> and there's a few failures that i'm seeing in the parallel/* tests
<teward> xnox: i'm guessing the testsuites is what takes 2 hours :p
<teward> or do you want me to run the autopkgtests as well?
<teward> (which won't happen probably if it fails like this heh)
<teward> xnox: do we have examples of the current failing tests?
<teward> 'cause i'm getting http2 test errors at the moment :|
<LocutusOfBorg> testsuite is fine
<LocutusOfBorg> teward, grep for "not ok"
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/nodejs/10.15.0~dfsg-8/+build/16274528
<LocutusOfBorg> 3 tests
<teward> LocutusOfBorg: still running but there's a lot of STREAM_CANCEL errors on my tests here
<teward> so i'm getting a lot more failures
<teward> might be because of the env.
<LocutusOfBorg> teward, or because of $parallel
<teward> possibly.
<LocutusOfBorg> xnox, the bug you opened in debian has test-assert that is good
<LocutusOfBorg> so, something not kernel related since I assume the sbuild ran on the same machine=
<teward> LocutusOfBorg: let me rerun this with a higher parallel value.
<teward> wonder if that broke it.
<teward> (it had parallel=2 which was a holdover from my older sbuildrc when I didn't have the power this system has)
<teward> LocutusOfBorg: E:NOREPRO on errors, but getting *other* errors than you are in test case.  parallel/test-assert passes OK here.  any tests that're pulling localhost are failing getaddrinfo in my sbuild though not sure why that's the case.  parallel/test-crypto-verify-failure also fails on my system.
<teward> it's still running tests, only up to test 400 right now
<teward> on some errors so far*
<teward> odd that i'm getting different failures.
<teward> getaddrinfo EAI_AGAIN localhost  <-- these're the lookup failures, wonder if the sbuild chroots are being stupid.
<teward> xnox: ^ for your awareness as well, not sure why i'm getting those specific errors :|  but that throws a lot of failed test problems where it probably shouldn't be
<teward> (on my env_
<teward> though I think i know why those were erroring hang on
<LocutusOfBorg> teward, but debian chroot or ubuntu?
<teward> LocutusOfBorg: sid chroot
<LocutusOfBorg> exactly
<LocutusOfBorg> the same with disco chroot fails
<teward> LocutusOfBorg: on which, the localhost failures?
<teward> or the other ones?
<LocutusOfBorg> no the three ones
<teward> LocutusOfBorg: oh.
<teward> so far NOREPRO on the first one
<teward> still waiting for my system to catch up, and i wanted to fix the localhost failure problems which would've tainted the build
<teward> (third run, this time to try and fix the localhost resolve problems in the chroot)
<teward> LocutusOfBorg: the first failure you linked to was parallel/test-assert - that succeeded on my end
<teward> no errors there.
<teward> in the amd chroot of sid
<teward> the sid one is what xnox asked me to run :P
<teward> so :P
<teward> haven't run the disco one yeht
<LocutusOfBorg> same with pbuilder-dist
<teward> it never got to the next ones, and the 'results' would have been dirtied with the localhost lookup failure ones.
<LocutusOfBorg> pbuilder-dist sid amd64 build nodejs test-assert OK
<LocutusOfBorg> pbuilder-dist disco amd64 build nodejs test-assert NOT OK
<LocutusOfBorg> with pbuilder I think I have exactly the same failures as the archive
<teward> interesting.  i'm still letting the tests complete in sid right now to see if i can get the others
<teward> i'll run the disco one after this amd64 sid one runs
<LocutusOfBorg> sure I'm still running the two builds
<LocutusOfBorg> if you want to check it out
<LocutusOfBorg> pbuilder-dist sid amd64 create && pbuilder-dist sid amd64 build nodejs*.dsc
<LocutusOfBorg> s/sid/disco/g if you want the other one ^^
<teward> right.  i've already got the sid chroots built (I use sbuild)
<teward> i'm building the disco schroots now
<teward> yay my changes to the sid pristine tarball fixed the localhost crap
<teward> *makes a note that he probably should add a chroot build step to populate /etc/hosts with '127.0.0.1 localhost' in the roots*
<LocutusOfBorg> this is what pbuilder-dist does automagically :D
<teward> *shrugs*
<teward> oh that's odd, test 507 parallel/test-fs-error-messages fails here o.O
<teward> missing expected exception (validateError) o.O
<teward> so far all the other tests are succeeding on a sid chroot
<teward> xnox: do you have sbuild logs for this yourself?  I'm getting some errors which don't match the disco logs that LocutusOfBorg shared
<joelkraehemann> Give my tests more RAM, please.
<teward> LocutusOfBorg: xnox: should I be concerned these tests're still using Py2?
<teward> LocutusOfBorg: xnox: I have a 'failed' set of tests, but different issues it seems.  IPv6 related possibly.  But the tests that i was shown failing didn't match up with the ones failing on Disco, in the sid chroot.  my failures: https://paste.ubuntu.com/p/NVrbpNqvbj/   build logs: http://paste.ubuntu.com/p/tS7JZ6ByZg/
<teward> i'll run the disco chroot shortly
<teward> i'm wondering how much of the build failures are v6 related or other 'weird issues' because this system doesn't have v6 currently configured
<teward> LocutusOfBorg: xnox: oh and there is one 'crashed' test - a datagram v6 issue it seems.  Not sure why it died (maybe the system killed it?) but it did.
<teward> LocutusOfBorg: obvious stupid evil question, has this been tested targeting disco on Debomatic?  Just a thought, because that might provide yet another testbed. (And it seems they have 'disco' as an env on there0
<teward> or do you not have a build account there?
<teward> LocutusOfBorg: xnox: confirmed my computer does something weird with regards to udp6 datagrams in the env, I'll look into it later with some test packages to see why it explodes that way and whether it's local to nodejs or something environment-related, my guess is env-related but eh.
<teward> other tests seem to be 'running' still though, almost done with the disco test and I"ll compare
<teward> LocutusOfBorg: xnox: not sure what you're seeing but I"m seeing a lot of repl failures too in mine as well as some net failures, I have to assume those're local to me, but as for the tests failing on the ubuntu builders' logs, I can confirm that the same tests that fail in your log data i've seen match some of the test failures I"m seeing.
<teward> but i have a lot more so i'm wondering what about my sbuild the system doesn't like.
<teward> udp6 and IPv6 stuff aside.
<teward> LocutusOfBorg: xnox: disco failures: https://paste.ubuntu.com/p/qYcm8SFWyx/  full logs: http://paste.ubuntu.com/p/bP7cfcTbw4/
<teward> i obviously have some oddness in my envs, not sure what that's about
<teward> unless you guys have any ideas why i'm failing on repl stuff
<teward> LocutusOfBorg: xnox: from what I can tell the errors I"m getting with repl indicate something busted in my binary builds, wonder if something FTBFS but didn't cause a total failure.  Or if those warnings broke it.
<LocutusOfBorg> teward, I'm administrator of that machine :)
<LocutusOfBorg> strange results yours
<LocutusOfBorg> I still need to finish my pbuilder session
<LocutusOfBorg> I had my laptop on suspend :)
<teward> LocutusOfBorg: oh you are.  then you need to check your emails :P
<teward> LocutusOfBorg: i traced it back to some really oddball behavior in the nodejs binary
<teward> I have to presume that something in my system hates the REPL parts of the binary but i didn't dig.
<teward> but yes, strange results indeed.
<teward> LocutusOfBorg: fun fact you seem to be getting the same REPL errors on DebOMatic
#ubuntu-devel 2019-01-18
<Hi-Angel> Hi! I'm reading a vacancy at Ubuntu desktop development team, and there is a mandatory field "Code hosting". Any ideas what would that mean?
<wxl> e.g. github, gitlab, etc.
<wxl> examples of your code
<wxl> or that's how i'd read it
<Hi-Angel> Hmm, so, links to projects, I see. Thanks!
<wxl> np
<LocutusOfBorg> teward, xnox_ I blame my node-acorn bootstrap
<doko> xnox_: what is https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-legacy-390xx/390.87-4 ?
<tjaalton> yeah remove that
<doko> ok, and blacklisting
<tjaalton> thanks
<seb128> juliank, hey. Bug #1812174 might be interesting to you? It looks fine to me so I was going to sponsor it but I look at the state of things in Debian and saw your have a git with the sftp changes, so I'm pinging in case you want to review/maybe merge that in your version? Or is that ok if I just upload to disco?
<ubottu> bug 1812174 in dput (Ubuntu) "sftp method should support alternate port" [Wishlist,Confirmed] https://launchpad.net/bugs/1812174
<juliank> seb128: ack
<LocutusOfBorg> we need to understand e.g. why node-buble is not building
<LocutusOfBorg> same issue
<doko> infinity: fyi: https://launchpadlibrarian.net/406733858/buildlog_ubuntu-bionic-amd64.debian-installer_20101020ubuntu543.4_BUILDING.txt.gz (pure reference test rebuild)
<teward> LocutusOfBorg: so node-acorn is the reason of those REPL errors?
<teward> LocutusOfBorg: or the source of all the problems observed thus far?
<LocutusOfBorg> teward,
<LocutusOfBorg> rollup was badly bootstrapped
<LocutusOfBorg> and rollup injects code on lots of places
<LocutusOfBorg> rollup bootstrap itself in stage profiles
<LocutusOfBorg> but the first bootstrapped version was badly done, so it was badly propagating the exception issues
<LocutusOfBorg> and everything built with rollup was bad as consequence
<LocutusOfBorg> ginggs, ^^
<teward> aha!  makes sense.
<LocutusOfBorg> I did create two chroots, and melded usr/lib/nodejs
<LocutusOfBorg> once debian and one ubunut
<LocutusOfBorg> now the two directories are looking the same
<LocutusOfBorg> in fact a lot of stuff in -proposed right now was failing for exactly the same reason
<LocutusOfBorg> stuff that before didn't have any issue
<LocutusOfBorg> because the "bootstrap" was partial
<teward> that makes sense, and explains why things had been failing on a 'grander' scale.
<LocutusOfBorg> I copied the node_modules from debian chroot for rollup and used it :)
<LocutusOfBorg> debian folks uploaded a binary for the bootstrap
<LocutusOfBorg> now node-buble works, acorn too, rollup is correctly bootstrapped
<LocutusOfBorg> so I presume nodejs will be the next one to build correctly
<LocutusOfBorg> I didn't test it, but I'm pretty sure of what I'm saying :)
<LocutusOfBorg> we might need some publisher runs but meh
<LocutusOfBorg> now the only failed package is node-nan, requiring new nodejs and lots of dep-wait stuff
<LocutusOfBorg> also node-srs
<teward> LocutusOfBorg: let me know if you need me to test it. v6 datagram stuff will still most likely fail on my end and v6 related ones will fail likely because E:NOIPv6 but
<teward> still willing to help out :)
<infinity> doko: There are already newer versions of d-i in bionic-proposed that clearly build, so not too concerned about looking at that log. :P
<LocutusOfBorg> teward, just upgrade your chroot and try!
<teward> LocutusOfBorg: running my massibe sbuild-update calls now
<LocutusOfBorg> the archive might be still outdated
<teward> possibly but my chroots are all rebuilt for each run, i don't keep the chroots with each time.  we'll see what happens.
<teward> i still have to pull things regularly anyways so :p
<LocutusOfBorg> ahasenack, thanks for helping Ryan wrt openldap!
<LocutusOfBorg> I'm happy to give it to him
<LocutusOfBorg> I also want him to become DD or ubuntu PPU :)
<ahasenack> yeah, hopefully he can apply for ppu
<ahasenack> yep
<LocutusOfBorg> I really stopped double checking his openldap stuff a long while ago
<LocutusOfBorg> I just build&sign&upload :)
<ahasenack> it's good stuff
<LocutusOfBorg> I would be happy to advocate him for PPU if you want :)
<ahasenack> sure
<LocutusOfBorg> btw I have some nitpicks on his ubuntu upload
<LocutusOfBorg> now apparmor is a thing in debian too
<LocutusOfBorg> also ufw support is a thing
<LocutusOfBorg> so maybe he can upstream part of the delta to his debian packaging?
 * LocutusOfBorg didn't check the above
<ahasenack> that would be cool
<ahasenack> reduce the delta
<dckusr> is there any change to make python-opencv not install X windows ? tons of people use opencv to run some CV algorithms without GUI
<dckusr> maybe a python-opencv-gui package can be made for doing that...
<dckusr> I have dockers which apt install this package, and they are so bloated...
<sarnold> dckusr: you can use the equivs package to make fake debian packages to satisfy dependencies
<sarnold> dckusr: apt-rdepends python-opencv  output can help you determine which packages to fake
<sarnold> dckusr: I'm guessing that making a fake libopencv-highgui3.2 package would help, but that's probably not the only one you would need to fake
<dckusr> sarnold: why resort tofaking ?
<dckusr> most opencv uses are for non gui uses
<dckusr> so why not cater to the sane option first ?
<sarnold> dckusr: that might be a good idea too, but it will probably also take a while for any possible changes in debian packaging to filter back to ubuntu
<sparr> are questions about building debs on topic here?
<rlaager> Am I doing something wrong, or is packages.ubuntu.com missing a bunch of information? It seems to have no packages for Bionic, or possibly anything newer than Trusty.
<Faux> Heh, no, it seems broken here too.
<sparr> I saw the same
<TJ-> Is that broke again?
#ubuntu-devel 2019-01-19
<sarnold> I filed https://bugs.launchpad.net/pkg-website/+bug/1812455 hopefully that'll be enough
<ubottu> Launchpad bug 1812455 in pkg-website "some data missing" [Undecided,New]
<TJ-> I had that fixed about a month ago
<sarnold> aww :/
<TJ-> ahh, logs tell me it was Dec 3rd/ Rhonda was working on it
<TJ-> 2018-12-03 10:52:13     Rhonda  Hey there.  I have issues with debugging the packages.ubuntu.com issue on jubany, and I see in dmesg a fair amount of OOM kill
<TJ-> ers.  Somehow there seems to be some ressource issue, can anyone give me a helping hand?  moon127, around? :)
<TJ-> sarnold: Maybe worth adding that ^^ to the report for context?
<teward> sarnold: might prod #canonical-sysadmin for packages.u.c
<teward> this is the 6th poke I'd have had to give them on that
<teward> sarnold: ten bucks says it has something to do with the indexing process eating up the resources
<teward> because that's been the problem the last 5 times I prodded IS
<sarnold> teward: hehe, sounds like an unfair bet :)
<teward> probably because i'm partly right xD
<TJ-> Yeah, Rhonda said it was OOM
<alkisg> Hi all. I'm upstream for ltsp.org. We have a problem with the ltsp-client package on Ubuntu. It basically tweaks a system on boot, to allow it to netboot. Due to its nature, it's very sensitive to systemd, network-manager etc changes.
<alkisg> So uploading new LTSP releases before Ubuntu releases isn't enough; usually fixes are required later on too. For example, LTSP in 18.04 has been broken for 4-5 months ago when some update broke it, possibly systemd.
<alkisg> Issues are fixed upstream, usually before they even appear in Ubuntu, but since there's no Ubuntu LTSP maintainer, noone takes the time to cherrypick upstream fixes and release SRUs.
<alkisg> So my question is: LTSP currently doesn't work in bionic, so we direct our users to use our PPA. Noone is willing to cherrypick/SRU. Is there a process that would allow us to upload the newest, *working* version in bionic? Something similar to firefox, where new versions are allowed?
<alkisg> I'm not talking about "always upload new versions", as this may actually break things for some users; just for "upload the newest version when the existing version is broken for all users"
<alkisg> E.g. just a syncing from debian unstable now would be fine
<valorie> alkisg: it's always best to upload to Debian and ask for a sync
<alkisg> valorie: but is the sync allowed? E.g. now it is uploaded in debian, but there's no process in ubuntu for "sync release to lts version", just to the development ubuntu version...
<valorie> hmm, that I don't know
<valorie> bit early for the europeans to be here, and it's weekend now
<valorie> perhaps write to the devel list?
<alkisg> Sure I understand; I posted and I'll be around for days, no worries
<alkisg> It might be worth to bring it up, as it would probably require a change in policy...
<valorie> I'm not actually a devel, so don't have the answers
<ginggs> rbalint: your mercurial patch was effective, i see 'running 806 tests using 4 parallel processes', but the tests didn't run significantly faster :(
<edarfoc> Hi!
<edarfoc> is it allowed to link to a launchpad bug report here to see if anyone can help?
<tsimonq2> alkisg: "Noone is willing to cherrypick/SRU" if you do the paperwork, I'll volunteer to review your patches and upload.
<tsimonq2> alkisg: It's not that nobody cares, it just lacks attention.
<tsimonq2> alkisg: Regressions caused by updates are major and should be reported/escalated ASAP.
<tsimonq2> alkisg: https://wiki.ubuntu.com/StableReleaseUpdates should answer all of your other questions, let me know if you still have questions after reading that.
<alkisg> tsimonq2: the problem is that it's not patches, it's a whole new release
<alkisg> Noone wants to spend e.g. 2 hours to isolate only the bug fixes that happened between the old and the new release
<alkisg> And SRUs prohibit new features; they require just bug fixes
<alkisg> LTSP is hacky by its nature, so systemd updates that break it can't be reported as systemd regressions, they need to be fixed in ltsp
<alkisg> So I think I'm asking for a new process that isn't covered by the existing policy for SRUs and backports
<alkisg> "If a package doesn't work at all, allow synching a new version from debian", something like that
<tsimonq2> alkisg: I would highly recommend you discuss this with the SRU team, either via IRC or the ubuntu-devel mailing list, to get their input on this.
<tsimonq2> teward might also be interested in such a discussion. ;)
<alkisg> tsimonq2: thanks, do you mean in another channel or in this one?
<tsimonq2> alkisg: Some people would argue this channel, others #ubuntu-release.
<alkisg> Thanks :)
<tsimonq2> Anytime. :)
<teward> tsimonq2: i was pinged, context?
<teward> alkisg: in *some* cases a full version can be SRU'd, otherwise it'd need backported, but that process is currently nonfunctional (I made a proposal that i'm letting sit a bit before I poke it forward more)
<teward> (which would 'fix' backports to some extent)
<alkisg> teward: thanks, so I should't try to SRU the whole new version now for 18.04, but it might be doable in 20.04...
<alkisg> *shouldn't
<alkisg> Backports are harder because they require changes in the ltsp chroot as well, so they're not so easy for users
<teward> you could probably get it into 19.10 at the earliest, but I have not read the full backlog, so I'd upload to Debian and let that in there, then it'll automatically end up in the next autosync for the dev release
<alkisg> Yes, it always ends up in the newer releases, which is useless for lts users though
<alkisg> As it'll be broken again in the next lts
<teward> the SRU team can determine if it's SRUable
<teward> backports MAYBE but we have to wait for a determination on the best way to revive typical backports behavior.
<alkisg> So for the last 5 years or so we've been telling our users "don't use the ubuntu packages, they're broken, use the ones from the ppa"
<teward> s/typical/usual/
<JackFrost> Backports aren't currently a thing in Ubuntu, though.
<alkisg> Gotcha. Backports aren't useful in ltsp due to chroots, so no need to worry about that part
<teward> JackFrost: you mean backports via SRU, not the backports repository.  :p
<teward> alkisg: right.  again, SRU team is the one to make determinations
<teward> *returns to lurking because he's got a trillion things on his radar to get done by tomorrow*
<alkisg> teward: but that process isn't functional now, so there's no point in trying an sru now, correct?
<alkisg> np, thanks again
<JackFrost> teward: I mean backports aren't really a thing, nothing about SRU's.  A SRU tends to not be new versions though.
<teward> alkisg: i think you're confusing SRU and Backport
<alkisg> (11:14:53 Î¼Î¼) teward: alkisg: in *some* cases a full version can be SRU'd, otherwise it'd need backported, but that process is currently nonfunctional
<teward> alkisg: right, but again, that's not a determination I can make
<teward> SRU process and Backports process are different
<JackFrost> alkisg: Stable Release Updates are meant to be minimal changes, hence why he said that about *new versions*
<alkisg> I thought you said there that "new versions for sru's aren't functional"  - were you talking about backports only there?
<teward> alkisg: correct, i wasn't 100% clear
<teward> but SRU is beyond my purview to judge on
<alkisg> OK, I could try an SRU then, which would just mention "please sync from debian", along with the rationale etc
<alkisg> Including bug reports with the "it's not working at all" issues...
<teward> probably won't go anywhere per tsimonq2 but you can attempt :P
<teward> seriously, i need to get this thing working by tomorrow morning >.>
<teward> *returns to repairing servers*
<alkisg> Haha, nah, i have a million things too
<alkisg> If it's not going to fly,no point in wasting time there, the ppa will be enough
<alkisg> Thanks!
#ubuntu-devel 2019-01-20
<leafwiz> Hey. maybe I have misunderstood something, but it seems the regular command ls is broken on ubuntu https://pastebin.com/M8YHsgGV . Why does ls /etc/x* print out filenames that does not start with /etc/x ?
<leafwiz> Its seem to be that ls on ubuntu is broken https://pastebin.com/Red1QxgB
<leafwiz> If you are going to list files in sub directories it would be nice if you told me that you are listing from a subdir.. :)
<TJ-> leafwiz: you asked 'ls' for the sub-dir list when you did "ls /etc/x*" since the shell will expand 'x*' so the command becomes "ls /etc/xdg"
<tarzeau> when will ubuntu get the gnustep transition ?
#ubuntu-devel 2020-01-13
<tjaalton> vorlon: making libsdl2 tests cross-build happy broke it on non-cross-build ;)
<tjaalton> vorlon: cmake doesn't seem to be happy about passing empty strings to it, like 'cmake .. ""' in this case
<tjaalton> vorlon: I'll drop the quotes, seems to work here
<vorlon> tjaalton: ah, cheers, I hadn't had a chance yet to look at it
<tarzeau> is there anything i can do about https://bugs.launchpad.net/ubuntu/+source/cloudcompare/+bug/1855846 ?
<ubottu> Launchpad bug 1855846 in cloudcompare (Ubuntu) "Please update cloudcompare to 2.10.1-2" [Undecided,Confirmed]
<seb128> tarzeau, you could provide a debdiff for disco and mae the bug SRU compliant (https://wiki.ubuntu.com/StableReleaseUpdates)
<tarzeau> i guess that's not worth it for 19.04 getting no more support (soon or already)
<tarzeau> but thanks, i learnt something new (reading up anyways)
<seb128> right, I wouldn't bother about disco at this point
<seb128> is there some known issue with the armhf/arm64 autopkgtests instances?
<seb128> e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/p/pango1.0/20200112_120621_7c044@/log.gz
<seb128>   File "/usr/lib/python3/dist-packages/novaclient/v2/shell.py", line 655, in _poll_for_status
<seb128>     raise exceptions.ResourceInErrorState(obj)
<seb128> novaclient.exceptions.ResourceInErrorState: <Server: adt-focal-arm64-pango1.0-20200112-110205>
<seb128> juliank, Laney, vorlon, ^?
<seb128> half the world seems to be failing on those archs
<juliank> I haven't heard anything
<juliank> but arm64 runs on cloud, whereas armhf runs on lxd
<seb128> something is weird, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages has a stack of arm failing tests where it was clear on friday
<juliank> seb128: i see a few packages failing on arm64 like that, but most still seem to succeed
<juliank> seb128: No valid host was found. There are not enough hosts available.
<juliank> seb128: Seems we are running out of cloud resources
<seb128> so what's the solution? wait/retry?
<juliank> seb128: Decreasing the number of workers to its normal value again, it was doubled for the focal opening
<seb128> juliank, is that something you can do or should I open a RT/nag someone else?
<juliank> I'm on it
<seb128> great, thx
<seb128> (brb, changing location)
<juliank> on armhf, everything looks fine right now
<juliank> I rudely stopped half of the arm64 workers so we'll lose some time because the tests need to restart, but should be fine
 * Laney pats juliank 
<LocutusOfBorg> doko, hello, sorry for assigning you the bug, but looks like binutils is not yet fully fixed?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1859404
<ubottu> Launchpad bug 1859404 in binutils (Ubuntu) "binutils regressed llvm-toolchain-9 and llvm-toolchain-7 bootstrap on arm64" [Undecided,New]
<LocutusOfBorg> even golang-1.13 is FTBFS on arm64
<juliank> seb128: the poppler author is looking for reviews on the cairo/glib in https://lists.freedesktop.org/archives/poppler/2019-December/014101.html and nobody responded, so the glib/cairo sides of poppler are basically dead atm. Maybe that's something that someone in desktop can help with?
<doko> LocutusOfBorg: is llvm using clang itself for the bootstrap?
<doko>     /<<PKGBUILDDIR>>/build-llvm/./bin/clang  -fuse-ld=gold -fPIC -Wno-unused-command-line-argument -Wno-unknown-warning-option   -fuse-ld=gold -fPIC -Wno-unused-command-line-argument -Wno-unknown-warning-option -Wl,--build-id  CMakeFiles/cmTC_552db.dir/testCCompiler.c.o  -o cmTC_552db
<doko>     clang-9: error: unable to execute command: Illegal instruction (core dumped)
<doko>     clang-9: error: linker command failed due to signal (use -v to see invocation)
<juliank> heh there are three different merge requests dealing with correctly setting anti-aliasing in a cairo context
<seb128> juliank, I will have a look if there is anything we can do to help there, thx for pointing it out
<LocutusOfBorg> yes doko
<doko> LocutusOfBorg: well, then I'll remove llvm-9 from -proposed, and upload again
<LocutusOfBorg> doko, what llvm in proposed?
<LocutusOfBorg> doko, clang used by llvm is the one just built before, not the one in proposed
<LocutusOfBorg> its a self contained bootstrap
<LocutusOfBorg> btw looks like all of your rebuilds for libffi have SIGILL in arm64
<LocutusOfBorg> at least all the haskell related
<doko> LocutusOfBorg: but you just said, that llvm-9 uses llvm-9 for the build, didn't you?
<doko> LocutusOfBorg: are you fixing the llvm-8 python/python3 mess?
<LocutusOfBorg> doko, llvm-9 uses llvm-9 stage one built on the same build process
<LocutusOfBorg> built with gcc I would say
<LocutusOfBorg> not the one in release
<LocutusOfBorg> it depends on libllvm9 because of doxygen dependency, not because it needs it
<LocutusOfBorg> (at least I think)(
<LocutusOfBorg> for llvm-8, ack I can do it
<doko> ta
<LocutusOfBorg> but only after binutils is fixed I would say...
<doko> LocutusOfBorg: ugh, you "fixed" llvm by uploading a binary build?
<LocutusOfBorg> yes
<LocutusOfBorg> from bileto
<doko> tumbleweed: s/python/python2/ in b-d's for pypy/pypy3 please
<doko> smb: you seem to be uploader for the xen packages ... xen-hypervisor-4.6-armhf, xen-hypervisor-4.7-armhf, xen-hypervisor-4.8-armhf, xen-system-armhf, xen-utils-4.9  these need rebuilds for s/python/python2/, but ftbfs. can these be removed?
<smb> doko, focal? xen would need to moved to a newer Debian version and to universe but I cannot say when I will find time for that
<doko> `smb: yes
<doko> smb: https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1859432
<ubottu> Launchpad bug 1859432 in xen (Ubuntu) "xen needs to depend on python2 instead of python (or better python3)" [High,Confirmed]
<smb> doko, there is a xen upload in disco/proposed which allows to compile with gcc-9. This should get copied forward to eoan and focal. Problem is that when compiled with gcc-9 it produces a completely broken hypervisor. But it could give you a way to clean out the python2 parts more quickly than waiting on the new xen version
<gpiccoli> o/ rbasak, sil2100  - hope you had great EOY! Can you please take a look in LP #1847924 ?
<ubottu> Launchpad bug 1847924 in mdadm (Ubuntu Eoan) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/1847924
<gpiccoli> I've managed to implement the suggested changes, but I'd aprpeciate some review in order to validate it can be uploaded to -proposed
<tumbleweed> doko: sure. I was waiting for tooling to catch up on that
<seb128> juliank, bug #1859477 ... those python2 build-depends look like leftover since you removed the python2 support in 19.10?
<ubottu> bug 1859477 in aptdaemon (Ubuntu) "FTBFS in focal due to missing python-defer" [High,New] https://launchpad.net/bugs/1859477
<juliank> seb128: sounds like it
<juliank> seb128: I'll go remove them
<seb128> juliank, thanks!
<juliank> seb128: hmm, it does not build now because dh_auto_clean calls pyversions and that does not exist (doko ?)
<juliank> Maybe it needs porting away from debhelper compat 78
<juliank> *7
<juliank> I think most stuff can be removed from d/rules
<juliank> fixing ...
<juliank> switching it to pybuild and compat 12
<seb128> juliank, thx :)
<juliank> I even ran autopkgtests this time before uploading :)
<doko> juliank: yes, I usually only bump to v9
<juliank> 12 seems to work fine here, so I cleaned it up a bit and bumped it that far
<Laney> rafaeldtinoco: congrats on core-dev :-)
<rafaeldtinoco> thanks Laney!
 * RikMills watches the ubuntu-devel mailing list
<Eickmeyer[m]> Weird stuff on the ubuntu-devel mailing list.
<mdeslaur> someone need to get a life.
<mdeslaur> needs*
<bryce> mdeslaur, which they can get for the low price of 0.18367473287 bitcoins?
<mdeslaur> bryce: yes! :)
<coreycb> doko: thanks for the networkx upload. I was hitting some examples failures on Friday but maybe they went away.
<doko> coreycb: that was just to get rid off the component mismatches
<coreycb> doko: yes, was just hitting other issues when trying to fix the mismatches
<doko> coreycb: how is openstck going with 3.8? already asked james page
<coreycb> doko: we only have a gauge on unit tests so far and it's not bad. just a few test failures here and there. I plan to give a deployment a test soon.
<doko> jamespage: can we remove python-otherstuf?
<doko> jamespage: also python-stuf
<sarnold> is there any way to find out how much memory was available on a given build system? a friend is curious how we got firefox to build in a 32 bit environment, on bos02-arm64-047 -- https://launchpad.net/builders/bos02-arm64-047
<xnox> sarnold:  rebuid procenv and look at the build log
<xnox> MemTotal:        8170344 kB
<xnox> https://launchpadlibrarian.net/436053202/buildlog_ubuntu-eoan-arm64.procenv_0.50-1ubuntu2_BUILDING.txt.gz
<xnox> sarnold:  but note that we use arm64 kernel + armhf userspace.
<xnox> i believe we are using native toolchain
<sarnold> xnox: ah, not an armhf qemu?
<xnox> not sure how much shared vs built-in libraries we use
<xnox> sarnold:  i believe we do not do armhf qemu. As we still don't have images working with that, i think.
<xnox> Kernel version: Linux bos02-arm64-028 4.4.0-157-generic #185-Ubuntu SMP Tue Jul 23 09:17:28 UTC 2019 aarch64
<xnox> https://launchpadlibrarian.net/436053201/buildlog_ubuntu-eoan-armhf.procenv_0.50-1ubuntu2_BUILDING.txt.gzat the top of
<xnox> so yeah aarch64 kernel with chroots to build armhf code
<sarnold> xnox: cool cool. I had wondered how the heck we managed to fit firefox in armhf myself, but never looked into it until a friend asked :)
<doko> jamespage: is python-mock-services still needed?
<eoli3n_> Hi
<eoli3n_> defaultly allow users to set crontab seems to me a securty breach
<eoli3n_> a user shouldn't be allowed to run anything outside his main shell without superuser agreement
<eoli3n_> same for systemd timers
<eoli3n_> when setting a crontab with a user, using crontab -e write a file under /var/spool/cron/crontabs/*, which is owned by root
<infinity> How do you figure this is a security breach?
<infinity> Other than your arbitrary statement about what users should be allowed to do (which has never been true in the history of UNIX or Linux), I see no problem with cron and/or timers..
<eoli3n_> because a user is by definition a untrusted account. An untrusted account shouldnt be able to run something in background
<eoli3n_> so why isn't all users in docker account when installing docker for exemple ?
<infinity> Again, according to what/who?  I could say "a user shouldn't be allowed to play Solitaire", but that won't generate CVEs because I can play card games.
<infinity> Unprivileged users running things in the background is pretty much how most things get done.
<eoli3n_> running code in background should be root aggreed
<eoli3n_> most things ? like ?
<infinity> Like nearly all daemons?
<eoli3n_> huhu, daemons owned by users ?
<eoli3n_> just a test, please pgrep 'your user' while not connecting with it
<eoli3n_> and paste it here
<infinity> www-data isn't root.
<eoli3n_> www-data is a account managed by a package
<infinity> If you think human users are inherently different from system users, that's your call to not trust humans you know and restrict them, but that's not the system design.
<infinity> The short answer to your concern is "it's not a concern, that's how UNIX works".
<infinity> The long answer is "if you don't trust your users, lock them down more".
<eoli3n_> hm
<infinity> Despite your claims, there's no universal belief (and quite the opposite) that users shouldn't be able to run background processes.
<eoli3n_> why users need to be in audio group to use pulseaudio ? "docker" group for docker
<ogra> they dont
<eoli3n_> ogra: please explain
<ogra> the audio group has been obsolete since years ... device access for audio particulary is managed via ACLs
<eoli3n_> sorry "pulse" group
<eoli3n_> https://doc.ubuntu-fr.org/pulseaudio
<infinity> There are many groups still needed for raw device access, like dialout for serial TTYs and kvm for /dev/kvm, but I don't see how that relates to background processes.
<ogra> aslk the person that made this up ? on my ubuntu machines there is no pulse group
<eoli3n_> why not defaulty allow all users to acces thoses files
<eoli3n_> /dev/kvm 777 is like default crontab for users
<ogra> not really
<ogra> the user crontab runs as the user
<infinity> For serial, it's a lack of locking, so you need to trust everyone with access to play nice.
<ogra> it cant magically escalate privs
<infinity> /dev/kvm allows you to see into every VM running under it, ish.
<infinity> crontab has neither of those concerns.
<infinity> Hundreds of people can have crontabs, and other than memory/cpu pressure (which you can limit in other ways), they can't interfere with each other or see each others' data, and they all run as the user who created them.
<eoli3n_> that's exemples. user run crontab -e and it writes on a dir owned by root. afaik, that's not how unix works. privileges separation
<eoli3n_> infinity: they could run a cryptominer
<eoli3n_> i run 800 hosts in a university
<infinity> Yes, they could.  They could do that interactively too.
<infinity> If you're suggesting no one should be able to start a task, background it, and log off, you've destroyed the use-case for 99% of scientific users on university networks.
<eoli3n_> interactivly, that's not a problem, a user could do what he does, running things is the purpose of a shell. But when the shell is gone...
<eoli3n_> infinity: i work in a university and everybody makes everythings possible to not allow that
<infinity> And if you think interactive and background are somehow magically different, then I'll just run my crypto-miner interactively and never log off (with, say, screen, or something else to keep a controlling TTY)
<eoli3n_> nop screen is not installed by default
<eoli3n_> crontab is
<infinity> What you're looking for is CPU and memory quotas, not arbitrary limits on how a user can use UNIX.
<eoli3n_> we don't agree, not a problem. But i keep thinking that everythings outside main shell of a users shouldn't exist
<eoli3n_> defaultly i mean
<infinity> screen doesn't need to be installed by default to be usable to detach sessions...
<infinity> I mean, cryptominers aren't installed by default either, but you're concerned about their use.
<eoli3n_> downloading binary in user space ?
<infinity> A binary doesn't need to be "installed" or owned by root for me to run it.
<eoli3n_> you're right
<eoli3n_> does exist some keylogger working in userspace nop ?
<infinity> keyloggers need root.
<eoli3n_> ok
<infinity> Of course, almost every UNIX/Linux desktop has a root kelogger running.  We call it X11.
<eoli3n_> i'm thinking that as you said, a user could just open tty2 and run what he wants then back to tty7
<eoli3n_> infinity: huhu
<eoli3n_> nop i'm running wayland :)
<eoli3n_> but it's the same
<infinity> It's not the same, actually.  Wayland has strict privsep.
<eoli3n_> didn't know, cool
<infinity> X11 is leaky between applications, pretty much by design.
<eoli3n_> too old
<seb128> vorlon, hey, do you have any idea what's the issue with cheese/i386, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/c/cheese/20200113_162419_c6674@/log.gz ?
#ubuntu-devel 2020-01-14
<seb128> doko, hey, looks like python3-gi/arm64 is unhappy in focal-proposed, do you have about it?
<seb128> doko, it looks like maybe some problem with libffi
<seb128> testcase
<seb128> $ sudo apt install python3-goocalendar
<seb128> python3 -c "import goocalendar ; print(goocalendar.__version__)"
<seb128> -> segfaults
<seb128> #0  0x0000000000000000 in ?? ()
<seb128> #1  0x0000fffff7390ff8 in ffi_call_SYSV () at ../src/aarch64/sysv.S:114
<seb128> #2  0x0000fffff7390634 in ffi_call_int (cif=0xa12d78, fn=<optimized out>,
<seb128> Laney, ^ just as a fyi that's what is creating that stack of python/gi autopkgtest failures on arm64
<Laney> cool, thx for looking at that
<seb128> doko, I reported it as bug #1859610 , that's going to block lot of things since any gobject binding is segfaulting much makes the autopkgtest for most desktop components fail on arm64
<ubottu> bug 1859610 in libffi (Ubuntu) "python-gi/arm64 segfaults with the focal-proposed libffi version" [High,New] https://launchpad.net/bugs/1859610
<doko> seb128: yes, known, in the works
<seb128> doko, great, thx!
<ahasenack> rafaeldtinoco: we have python-tornado 6.0.3+really5.1.1-2 in focal, how does that change https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/pcs/+git/pcs/+merge/377171/comments/989992 now?
<ahasenack> we can keep requiring >=6 in d/control, like debian
<rafaeldtinoco> indeed
<rafaeldtinoco> but we didn't have it, right ? (just checking)
<ahasenack> rafaeldtinoco: yeah, it was sycned on the 10th
<ahasenack> https://launchpad.net/ubuntu/+source/python-tornado/+publishinghistory
<rafaeldtinoco> ok.. debian dropped the 5.1 patch, we should keep it
<ahasenack> by xnox
<rafaeldtinoco> ahasenack: i'll change the merge
<rafaeldtinoco> and re-push
<ahasenack> rafaeldtinoco: k
<ahasenack> rafaeldtinoco: debian dropped that work-with-tornado-5 patch, and yet their tests are passing with that tornado 6+really-5
<ahasenack> rafaeldtinoco: someone also added a badtest hint to pcs, so it migrated
<rafaeldtinoco> ...
<rafaeldtinoco> =)
<ahasenack> maybe they want to maintain these packages, since they keep racing us
<ahasenack> I'm not sure anymore where we stand now
<rafaeldtinoco> i'll have to review my merges
<rafaeldtinoco> for us to sync again
<cpaelzer> I have a segfault in a package build, but the build environments do not gather crash dumps (at least I found none)
<cpaelzer> did anyone ever create a snippet of some sort to configure storing the dump in e.g. sbuild where I could then chroot in and check what is going on
<cpaelzer> P.S. of course the issue only appears at the build on LP and sbuild, but works fine when chrooting into sbuild later or LXD or KVm based build envs
<doko> seb128: what to do wirh https://launchpad.net/ubuntu/+source/ubuntuone-dev-tools/13.10-0ubuntu7/+build/18549380 ?
<seb128> doko, no idea offhand, I will have a look
<doko> ta
<tjaalton> LocutusOfBorg: why does libsdl2 build-all test run cmake directly instead of with correct options like the package build?
<LocutusOfBorg> tjaalton, feel free to fix and commit :D
 * LocutusOfBorg checks
<tjaalton> I'll just disable gles1 from CMakeLists.txt
<tjaalton> it's getting enabled
<tjaalton> unconditionally, if autoconf isn't used
<seb128> tjaalton, webkit2gtk started ftbfsing with that error
<seb128> ../Source/WebKit/UIProcess/gtk/WaylandCompositor.cpp:134:116: error: âEGL_WAYLAND_BUFFER_WLâ was not declared in this scope
<seb128> do you know if that's a known issue?
<tjaalton> no
<LocutusOfBorg> tjaalton, yes, cmake needs a patch to allow disabling of opengles1
<tjaalton> seb128: seems to build in experimental
<tjaalton> seb128: EGL_WAYLAND_BUFFER_WL is defined in EGL/eglmesaext.h which is (still) shipped by libegl1-mesa-dev, so dunno why it's not working there
<LocutusOfBorg> tjaalton, is the gles1 change somehting I have to commit in Debian too=?
<tjaalton> LocutusOfBorg: it fails to build there, and i filed a bug about it
<tjaalton> needs gles1 disabled
<tjaalton> or the headers fixed, but that's upstream's headache
<cpaelzer> rbasak: are there better ways to chroot into an sbuild than sudo chroot /run/schroot/mount/${1} ?
<cpaelzer> just in case this might be important as well, $1 is the session ID
<cpaelzer> as we are hunting for environment details every little bit could matter
<LocutusOfBorg> tjaalton, committed on git
<ahasenack> smb: hi, is this on your radar? https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1859432
<ubottu> Launchpad bug 1859432 in xen (Ubuntu) "xen needs to depend on python2 instead of python (or better python3)" [High,Confirmed]
<ahasenack> hm, doko fixed that already
<doko> LocutusOfBorg: llvm-8: are you sure that scripts have a python2 shebang?
<seb128> doko, is the libffi no change rebuild fixing the arm64 segfault issue? (just to know if we can/should retry things)
<LocutusOfBorg> doko, they haven't
<LocutusOfBorg> but I enforce both python2 and python3 at runtime
<LocutusOfBorg> so meh
<LocutusOfBorg> I had to sed s/python2/python3 for llvm-9 and extract a patch
<LocutusOfBorg> I couldn't run dh_python3 to do its job properly and I don't care too much anymore about llvm-8
#ubuntu-devel 2020-01-15
<rafaeldtinoco> i would appreciate if anyone with go skills could take a look at LP: #1859685 and review the 2 golang workaround patches I have submitted at: https://github.com/google/cloud-print-connector/pull/477 as well.
<ubottu> Launchpad bug 1859685 in google-cloud-print-connector (Ubuntu) "google-cloud-print-connector FTBFS (focal)" [Medium,In progress] https://launchpad.net/bugs/1859685
<rafaeldtinoco> this will help unblocking net-snmp migration (rdepends on libsnmp35) and fix FTBFS for cloud-print-connector (with newer CUPs in Focal)
<seb128> vorlon, hey, any idea about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/p/parlatype/20200114_130829_2ece6@/log.gz ? it's blocking gst-plugins-base1.0
<smb> ahasenack, he told me about the first attempt failing to build. There is a 4.9.2-0ubuntu5 in disco proposed which I really would need in updates and copied forward into eoan
<smb> I hope this is still possible with the rushed out ubuntu6 for focal.
<doko> seb128: can you recheck #1859610 with all -proposed?
<seb128> doko, k
<doko> apw: could kernel team have a look at https://launchpad.net/ubuntu/+source/kpatch/0.5.0-0ubuntu3 ? and/or merge
<seb128> doko, is there a way to get https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191220-focal-focal.html refreshed with the current archive status? it still lists things that have been fixed
<doko> running ...
<seb128> doko, thx
<ahasenack> rafaeldtinoco: hi, you should ping tkamppeter about the ftbfs related to cups header
<seb128> juliank, any idea why trying to install python3-aptdaemon on focal wants to pull in gcc-9-base:i386 python3.8:i386 etc?
<seb128> doko, ^
<juliank> that sounds like fun
<juliank> pass -o Debug::pkgDepCache::Marker=1
<apw> doko, will figure out someone
<seb128> vorlon, any idea what should be done with afterstep/i386 (blocking fonts-freefont) https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/a/afterstep/20200115_130852_3a20c@/log.gz
<rafaeldtinoco> tkamppeter: do you think you can give a fast review on the 3 patches I made for bug 1859685 ?
<ubottu> bug 1859685 in google-cloud-print-connector (Ubuntu) "google-cloud-print-connector FTBFS (focal)" [Medium,In progress] https://launchpad.net/bugs/1859685
<rafaeldtinoco> dont want to add it to focal before someone +1 it.
<rafaeldtinoco> I'll add a debdiff to the bug!
<ahasenack> doko: I'm taking advantage of you reintroducing python-mako (py2), to build haproxy with it (not a runtime dep). Is that why you reintroduced it, or are other packages needing it?
<ahasenack> in other words, would you swear at me for doing that? :)
<ahasenack> I see just python2-scipy with a build-depends on it
<doko> ahasenack, ginggs: I just removed python2-scipy, so it's not needed for that anymore
<doko> if you want to help with server stuff, please fix the networkx triggered autopkg tests
<ahasenack> doko: no worries, I'm gonna try to switch haproxy to py3. I've got a plan
<ahasenack> hi, anybody hacking on debian-installer for focal? I need to do a no-change rebuild with new bind9 libs
<vorlon> seb128: parlatype just needed a badtest hint (which unfortunately means hinting pretty much every package which previously had test results on i386, one by one as they pop up, until someone has a chance to try to fix this centrally in britney).  Same for afterstep.  as for i386 autopkgtests installing build-essential:amd64: the way cross-testing is implemented, build-essential:amd64 must always be
<vorlon> installable, so anything having test deps which conflict with it is untestable
<ahasenack> oh, hm
<ahasenack> $ mklibs-copy
<ahasenack> -bash: /usr/bin/mklibs-copy: /usr/bin/python: bad interpreter: No such file or directory
<ahasenack> hmmÂ²
<ahasenack> $ dh_python2
<ahasenack> -bash: /usr/bin/dh_python2: /usr/bin/python: bad interpreter: No such file or directory
<ahasenack> doko: ^
<vorlon> haha
<doko> ahasenack: fixed in -proposed
<ahasenack> doko: dh_python2 and/or mklibs-copy?
<doko> dh_python2
<ahasenack> k
<doko> hmm, mklibs-copy builds for me
<ahasenack> the shebang is /usr/bin/python still
<ahasenack> in mklibs-copy, I mean
<ahasenack> https://pastebin.ubuntu.com/p/dxNxnpVwxV/ ?
<ahasenack> doko: ^ ok to upload that? Or are you working on it?
<ahasenack> it fixes the d-i build for me (after using python-defaults from proposed)
<doko> ahasenack: sure
<ahasenack> thx
<doko> LocutusOfBorg, Laney: I restored the old racket, but bustle and uuagc don't build in the old versions. ok to remove these?
<juliank> This is a PSA that I expect apt 1.9.6 to land tomorrow and it might break your apt(8) CLI muscle memory: Regular expressions and fnmatch style expressions will no longer be accepted, you'll have to use patterns instead.
<juliank> It's also lighter on the CPU when downloading, as it has hw-accelerated hashing courtesy of gcrypt; and 10-15% faster at generating a cache
 * juliank just waiting for CI to finish to merge the last feature branch, then add release commit, wait for CI, and then upload it to Debian, and then it needs syncing at some point :D
<sarnold> yay thanks juliank :)
<LocutusOfBorg> ok for me
<LocutusOfBorg> missing build on armhf: libsfcgal-dev, libsfcgal1 (from 1.3.7-2ubuntu1)
<LocutusOfBorg> doko, ^^ it has been removed in debian...
#ubuntu-devel 2020-01-16
<vicamo> hi, need sponsor for https://launchpad.net/~vicamo/+archive/ubuntu/ppa-upload, which contains new upstream release for backport-iwlwifi-dkms package for Focal :)
<vicamo> also https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1859389 for SRU for bug 1859389
<ubottu> bug 1859389 in backport-iwlwifi-dkms (Ubuntu Eoan) "[SRU] should disable DKMS build against kernel v5.0.0 or above" [Undecided,In progress] https://launchpad.net/bugs/1859389
<doko> locutus_: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/l/llvm-toolchain-8/20200115_224438_f9da4@/log.gz  not good enough
<Laney> doko: bustle has reverse-testsuite-triggers so probably not
<xnox> doko:  https://launchpad.net/ubuntu/+source/python3.8/3.8.1-2ubuntu2/+build/18570574 something got done to armhf toolchain?
<xnox> doko:  cause the upload just before that one, did build fine. And I only touched tests =/
<Skuggen> cpaelzer: Regarding #1858354, how can I tell exactly which version the stack trace listed in the error tracker is from?
<Skuggen> Nevermind, looks like it's just the version of the latest report
<juliank> apt in focal-proposed might have issues with realizing that automake Provides: automake-1.16
<juliank> so if there happen to be issues with that, that's the reason
<juliank> a fixed apt will appear later in the day
<juliank> That's bug 1859952
<ubottu> bug 1859952 in apt (Ubuntu) "apt 1.9.6 regression" [Critical,Fix committed] https://launchpad.net/bugs/1859952
<juliank> this also affects one other package, but I can't tell you which one
<juliank> because I don't know
<juliank> I only saw the number of virtual package names change by 2 :)
<doko> xnox: I'll have a look
<cpaelzer> Skuggen: when you go on the link it lists it in a table
<cpaelzer> at the bottom of the error.subuntu.com page
<cpaelzer> well, a table at the top and a list at the botto
<cpaelzer> but you need to let it load completely to see it
<Skuggen> cpaelzer: Right, but it listed a lot of different versions of MySQL, and the stack trace only matches the version in the last report (which isn't the latest version of MySQL)
<Skuggen> I didn't think to check that when I first got a stack trace to give to the dev, so they had some trouble matching it with the code :)
<Skuggen> One oddity: If I open an incident, it lists the various config files, but not the actual server config file. Do you know if that is intentional, or could it be significant for the issue?
<ahasenack> xnox: hi, are you working on the openssl migration?
<xnox> ahasenack:  yes....
<ahasenack> I have an incentive to help, since my bind9 upload is stuck because of that :)
<xnox> ahasenack:  it's all done. i.e. everything is in proposed now. However the are a couple of things that are external to me
<xnox> i.e. linux => is being fixed by kernel team (python2 fallout)
<ahasenack> the test failures on th other packages
<xnox> i.e. and i did not touch dpdk
<xnox> ahasenack:  all of them are fixed now
<xnox> in proposed.
<xnox> ahasenack:  what is the status with dpdk on ppc64el?
<ahasenack> nodejs, one openssl failure, both pythons , ruby2.5, are all sorted?
<ahasenack> xnox: I don't know, cpaelzer, do you know? ^
<xnox> 19.11-2ubuntu1 is green?
<xnox> let me try that.
<ahasenack> yeah, it's green
<xnox> ahasenack:  all of those are fixed in proposed, the openssl regressions are against versions in release pocket. I did schedule retries with proposed versions, but britney is very slow at the moment.
<ahasenack> ok
<xnox> i will need to reupload openssl to fix the :i386 dep, that is true. I am told perl:native will fix it all, but did not try it yet.
<xnox> ahasenack:  i think we will be waiting on linux anyway atm. It is in progress being fixed, as per emails i got this morning.
<ahasenack> ok
<ahasenack> that could take a while then
<xnox> ahasenack:  ruby2.7 is not fixed yet, but i think is low priority as it is brand new.
<ahasenack> xnox: about ruby2.7, I know someone :)
<ahasenack> kanashiro: ^
<xnox> ahasenack:  also bind9 is stuck only because d-i udebs do not know how to generate dependencies based on symbols versions, rather than "same as i was built against". udebs suck
<ahasenack> xnox: hm, last time I did a bind9 soname change, all I had to do was upload d-i again, which I did
<xnox> ahasenack:  yes, but at that time, there was no different openssl in -proposed pocket when bind9 was built.
<ahasenack> oh
<xnox> ahasenack:  hence the udebs got the dep >= libssl (version in -release)
<xnox> and migrated
<xnox> ahasenack:  i think we can rebuild bind in the release pocket only, in bileto ppa, and migrate it.
<ahasenack> Get:64 http://ftpmaster.internal/ubuntu focal-proposed/main/debian-installer amd64 libssl1.1-udeb amd64 1.1.1d-2ubuntu2 [190 kB]
<ahasenack> it used that one
<xnox> cause then all the udebs will be >= focal-release and not hold up the migration
<ahasenack> d-i, that is
<xnox> i.e.
<xnox>  Package: libdns-export1107-udeb
<xnox>  Depends: libc6-udeb (>= 2.30), libcrypto1.1-udeb (>= 1.1.1d), libisc-export1104-udeb
<xnox>  Package: libdns-export1107
<xnox>  Depends: libc6 (>= 2.14), libisc-export1104, libssl1.1 (>= 1.1.1)
<xnox> note how "-udeb" one rquires >= 1.1.1d; whisht proper per-symbol shlibdeps for the main package needs just any 1.1.1
<xnox> i can't wait for udebs to die
<xnox> ahasenack:  if bind9 is urgent to migrate => we can rebuild it against focal-release pocket only; otherwise just need to wait a bit for a few things to be resolved (python*/armhf ftbfs; linux testing)
<ahasenack> xnox: it's not urgent
<ahasenack> just a normal merge
<ahasenack> I will want 9.16 when it comes out later this month, though, it's their ESV ("lts") version, that's the one we want for 20.04
<ahasenack> I'll keep an eye on excuses
<xnox> ack
<seb128> vorlon, hey, i386 problem of the day. ubuntu-drivers-common is on the i386 whitelist and build-depends on python3-aptdaemon.test which depends on python3-aptdaemon which depends on gir1.2-packagekitglib-1.0 which is missing...should be bring back packagekit/i386? or skip tests on that arch rather?
<seb128> tseliot, ^
<ddstreet> Laney re: autopkgtest-cloud MP, should i rebase onto the revert, or do you want me to wait until that's sorted out before rebasing?
<cpaelzer> xnox: ahasenack: I did the restart of dpdk as now pytohn is back
<cpaelzer> it is good now no more blocking ssl
<ahasenack> cpaelzer: /usr/bin/python is back?
<cpaelzer> and I did an MP against salsa to make the test truly python3
<cpaelzer> ahasenack: the package "python" is  back and that was all it needed
<ahasenack> so we don't have to python -> python2 | python3 anymore?
<cpaelzer> for this special case, TBH - it could have been empty
<cpaelzer> ahasenack: this really was a special case
<cpaelzer> ahasenack: doko might outline how the next steps around py2/3 are to be done - don't take the special case of dpdk above as an indicator what generally works
<ahasenack> ok
<cpaelzer> ahasenack: the "python" that is back in focal is in universe btw
<xnox> cpaelzer:  i do not see python back. it is removed in focal-proposed, and has not been reintroduced.
<ricotz> hello :), I am running into "dh_builddeb: Sorry, but 10 is the highest compatibility level supported by this debhelper." building dh-autoreconf with debhelper 12 (backported to xenial) -- https://launchpad.net/~ricotz/+archive/ubuntu/toolchain/+build/18562470 -- could anyone point me to the cause of this?
<xnox> cpaelzer:  it is still available in focal-release, but we are working on migrating python-default to remove python in focal-release too.
<cpaelzer> that is good to know xnox
<cpaelzer> once that is happening I assume we are back to python2 | python3 dependencies and adapting the shebangs I guess
<xnox> ricotz:  well you are requiring 11
<xnox> --- dh-autoreconf-12~ubuntu16.04.1/debian/compat	2016-04-02 21:44:18.000000000 +0000
<xnox> +++ dh-autoreconf-19~ubuntu16.04.1/debian/compat	2018-05-19 19:33:40.000000000 +0000
<xnox> @@ -1 +1 @@
<udevbot> Error: "@" is not a valid command.
<xnox> -9
<xnox> +11
<xnox> ricotz:  and installing 12
<ricotz> xnox, correct, but the build is using debhelper 12.1.1
<cjwatson> I would assume that something is buggy in your debhelper backport then
<xnox> ricotz:  weird
<ricotz> xnox, https://launchpad.net/%7Ericotz/+archive/ubuntu/toolchain/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<xnox> cpaelzer:  one must use /usr/bin/python2 shebangs and those will work like trusty and up.
<cpaelzer> xnox: python 2.7.17-1 is in focal/universe right now, so the removal you mention is in 2.7.17-2ubuntu2 then I guess?
<xnox> cpaelzer:  ubuntu1 already had removal, but yes, ubuntu2 is currently in proposed and doesn't ship "python" package which provides "/usr/bin/python"
<cpaelzer> ahasenack: ^^ so "python -> python2 | python3" and shebang'ing still applies
<doko> or bang your head
<cpaelzer> doko: I'm sure you are doing that a lot for this transition
 * cpaelzer hugs doko
<ricotz> cjwatson, there is no-change compared to debhelper in bionic-backports (other than loosening the dh-autoreconf dep)
<ricotz> does debhelper adjust its features at buildtime somehow?
<cjwatson> I don't remember.  Take your backported .deb apart and look
<ricotz> maybe caused by the older perl :\
<tseliot> seb128, vorlon does anything need ubuntu-drivers-common on i386?
<seb128> tseliot, I don't know, Steve added it to the whitelist so I guess there a reason but let's wait on it to be around to comment on that
<tseliot> ok
<seb128> sil2100, hey, if you do your SRU shift could you review glib2.0/eoan? it's a follow up to fix a test regression from the SRU which is curently in proposed, it has been waiting for 1 month in the queue now :/
<sil2100> seb128: sure thing! Sorry I didn't get to it yet, I blame it on .4!
<ahasenack> cpaelzer: do you know why https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1847157 isn't showing up in https://people.canonical.com/~ubuntu-archive/pending-sru.html ?
<ubottu> Launchpad bug 1847157 in open-vm-tools (Ubuntu Disco) "memory leaks in open-vm-tools" [Medium,Fix committed]
<ahasenack> it's fix committed
<ahasenack> was it released perhaps?
<seb128> sil2100, no worry, I'm not going to bother you with the rest of the queue but since that one unblocks (hopefully) a SRU which is already in proposed it would be nice to see it moving
<seb128> sil2100, thx!
<cpaelzer> ahasenack: it got superseded by bug 1844834 and maybe due to that the tracking on the other oen got lost
<ubottu> bug 1844834 in open-vm-tools (Ubuntu) "open-vm-tools 11.0.0 released" [Medium,Fix released] https://launchpad.net/bugs/1844834
<cpaelzer> ahasenack: I'll update the old bug to be clear - it is fix released
<ahasenack> I just posted a comment asking for info
<ahasenack> thx
<cpaelzer> done
<cpaelzer> did that come up as 60/180 day idle case?
<ahasenack> no, normal triage
<ahasenack> let me see why
<ahasenack> cpaelzer: ah, ok
<ahasenack> cpaelzer: I'm doing my backlog of triages, from the holidays
<Laney> ddstreet: you'll want to do the same thing that commit is trying to fix, so you might as well wait
<Laney> or help Seth fix it :D
<Laney> ddstreet: oh maybe I'm wrong, it might have been fine all along
 * Laney likes a good old "Revert "Revert "...
<vorlon> seb128, tseliot: we only need dh-modaliases (which is Arch: all) from ubuntu-drivers-common on i386 as a build-dep of nvidia; this is a case we currently get wrong with germinate; I'll drop ubuntu-drivers-common from the whitelist
<ddstreet> Laney seems like it works for me, at least using python3 subprocess call from the cmdline, but i'll defer to sforshee
<tseliot> vorlon, ok, thanks
<Laney> ddstreet: I pushed, pls rebase and adjust to match what got changed there
<Laney> and then yeah, a review from a kernel person
<sforshee> Laney: yeah I should have explained the testing better in the first place, sorry about that
<Laney> np
<seb128> vorlon, thx
<seb128> vorlon, re the build-essential question/reply from yesterday, I'm unsure to understand why librsvg/i386 is failing, but maybe the build-essential part is a red herring and I looked at the wrong part of the log? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/libr/librsvg/20200116_093748_5be90@/log.gz
<seb128> 'The following packages have unmet dependencies:
<seb128>  builddeps:/tmp/autopkgtest.rC32CC/1-autopkgtest-satdep.dsc:i386 : Depends: build-essential:amd64
<seb128>  builddeps:essentials : Depends: build-essential but it is not going to be installed'
<vorlon> seb128: the libxml2-triggered failure I can explain, it's because libxml2:amd64 is in the base system so you have to trigger with all-proposed (due to the bug in the pinning) to get both libxml2:amd64 and libxml2:i386 installed from proposed
<vorlon> I'll look at the gobject-introspection-triggered one, but I have a meeting now
<seb128> vorlon, thx
<ahasenack> is there precedence in a package for not restarting services during a do-release-upgrade, in the case it's best to see the service restart later, in the new system, instead of during the upgrade, which aborts it?
<ahasenack> aborts the do-release-upgrade, I mean
<ahasenack> in other words, I was wondering if adding such a check to a postinst script would make sense: if we are in the middle of a do-release-upgrade, don't restart, or just ignore restart errors
<vorlon> seb128: can't reproduce the librsvg failure locally.  I suggest giving back all of the affected i386 failures with all-proposed and see if that takes care of it
<seb128> vorlon, will do, thx
<vorlon> ahasenack: I think you'd find some special-casing of the do-release-upgrade environment variables in the libpam code for restarting services, but I think it only controls whether we /prompt/ about restarting, not about whether we restart or not
<ahasenack> ok
<rbasak> xnox: your upload mysql-8.0 (8.0.18-0ubuntu5) is missing dep8 headers with an upstream bug link, etc. rafaeldtinoco's concurrent patch that was awaiting code review when you uploaded has all of that. How do you want me to resolve this?
<vorlon> seb128, xnox: big wtfs on these gobject-introspection-related autopkgtest failures; I've resorted to spinning up an autopkgtest vm and trying to install the deps, still can't reproduce it
<rafaeldtinoco> ahasenack: here ?
<ahasenack> rafaeldtinoco: here
<rafaeldtinoco> ahasenack: so.. STREAMS have been removed from glibc.. looks like linux doesn't support it for long time ago
<ahasenack> is that in the release notes too?
<rafaeldtinoco> in Changelog
<sarnold> TIL STREAMS was still in glibc :)
<rafaeldtinoco> and in NEWS
<rafaeldtinoco> sarnold: =)
<rafaeldtinoco> so this "windowmaker" applet
<rafaeldtinoco> is using the ioctl interface using streams
<rafaeldtinoco> and wont compile anymore
<rafaeldtinoco> i guess we should get rid of this package
<sarnold> holy moly, I haven't actually seen STREAMS in use in the wild before; which package? :)
<rafaeldtinoco> Dockapp monitoring network interfaces
<rafaeldtinoco> sarnold: wmnd
<sarnold> thanks
<rafaeldtinoco> it had to be a really really old thing =)
<rafaeldtinoco> src/drivers.c
<rafaeldtinoco> they have a "solaris/linux" driver
<rafaeldtinoco> to get consumption for pppd
<rafaeldtinoco> using ioctl
<ahasenack> man
<rafaeldtinoco> problem is that they're sharing code with solaris (since this is 2008)
<rafaeldtinoco> so they kept the solaris driver enabled to get information from a network device using streams (aka ioctl with streams structure as user pointer)
<ahasenack> hm
<sarnold> I wonder if you could just pop solaris_fpppd out of the debian/rules
<rafaeldtinoco> yep
<rafaeldtinoco> that was going to be my next move
<rafaeldtinoco> unsure if it will lose functionality
<rafaeldtinoco> but thats the way
<rafaeldtinoco> #ifdef USE_LINUX_PROC
<rafaeldtinoco>   {USE_LINUX_PROC, linux_proc_list, NULL,
<rafaeldtinoco>     linux_proc_get, NULL, NULL, 0},
<rafaeldtinoco> #endif
<rafaeldtinoco> hopefully this is enough
<ahasenack> yeah, we really don't want to spend too much time on this
<ahasenack> the threshold of fixing it vs dropping it isn't high
<rafaeldtinoco> ahasenack: came on! what about all those windowmaker uses
<rafaeldtinoco> users...
<rafaeldtinoco> or the afterstep ones
<ahasenack> NeXT
<rafaeldtinoco> lol
 * ahasenack used windowmaker on a 64Mb RAM K6 desktop
<rafaeldtinoco> i used windowmaker until .. ~2012
<rafaeldtinoco> kind of
<rafaeldtinoco> cant complain
<rafaeldtinoco> when they added freetype to it
<rafaeldtinoco> gave an extra life
<rafaeldtinoco> ahasenack: sarnold: yep
<rafaeldtinoco> that did the trick
<sarnold> yay
<rafaeldtinoco> just disabled the solaris plugin
<rafaeldtinoco> nice, let me patch this #)
<rafaeldtinoco> ahasenack: https://launchpadlibrarian.net/460915148/wmnd_0.4.17-3ubuntu1.debdiff
<rafaeldtinoco> quick +1
<rafaeldtinoco> so I can upload, pls
 * ahasenack checks
<ahasenack> rafaeldtinoco: just the changelog message, I don't understand the phrasing at all :)
<rafaeldtinoco> solaris_fpppd driver made it FTBFS as glibc disabled stropts
<rafaeldtinoco> better ?
<rafaeldtinoco> made wmnd FTBFS because recent glibc disabled streams ?
<ahasenack> "remove solaris_fpppd driver since it uses stropts.h which is gone with glibc 2.30 (#....)"
<rafaeldtinoco> :*
<rafaeldtinoco> perfect
<ahasenack> +1
<rafaeldtinoco> ill fix the )
<rafaeldtinoco> to align with \
<rafaeldtinoco> just saw that also
<rafaeldtinoco> thx!
<ahasenack> was just looking at that stray ) :)
<ahasenack> not a stray
<ahasenack> did you test this build? No changes needed in d/*.install files?
<rafaeldtinoco> yep
<ahasenack> ok
<ahasenack> go for it
<rafaeldtinoco> ill re-test now
<ahasenack> I'm gonna eod
<rafaeldtinoco> alright
<rafaeldtinoco> have a good one o/
<ahasenack> have to drive home still
<ahasenack> cya
<rafaeldtinoco> cya
<xnox> vorlon:  we have uncovered arm related issues in binutils/ffi and respun those between bug reported and today. So all of them should be simply retried with latest greatest toolchain in proposed.
<xnox> rbasak:  my code was simply written by me. And imho is better, as it pushes the deadline until 2037, rather than 2025. It will be resolved with new upstream release, when my patch will be dropped. And i don't think i actually care about fixing it in eoan.
#ubuntu-devel 2020-01-17
<jamespage> xnox: hello - I'm trying to figure out why ceph on armhf has suddenly decided it wants to link against libboost-random1.67.0 - all other archs don't which I find odd
<jamespage> any ideas?
<gpiccoli> Hi sil2100, vorlon - recently (~a month ago) mdadm was pushed to -proposed but it contains code that depends on kernel counter-part, from dannf. Kernel team is still figuring the proper solution to this raid0 layout stuff, so mdadm is block-proposed. Well...I need to release a mdadm version with a small patch, so discussed with dannf and kernel team, and we decided, if possible, to drop the current proposed and do my release first
<gpiccoli> So, can I ask you to drop the current mdadm from proposed? ddstreet uploaded my mdadm version, it's all explained in LP #1847924
<ubottu> Launchpad bug 1847924 in mdadm (Ubuntu Eoan) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/1847924
<gpiccoli> Tnx in advance sil2100 and vorlon
<LocutusOfBorg> jamespage, https://launchpadlibrarian.net/460565614/buildlog_ubuntu-focal-armhf.ceph_14.2.5-3ubuntu2_BUILDING.txt.gz
<LocutusOfBorg> "libboost_random" is used in some places
<LocutusOfBorg> e.g. ceph-mon
<LocutusOfBorg> ceph-dencoder
<jamespage> LocutusOfBorg: yeah that's what's puzzling me - because all of the other arch builds do the same thing but don't end up with that as a depends
<LocutusOfBorg> ldd /usr/bin/ceph-dencoder |grep random -> returns stuff on armhf
<sil2100> gpiccoli: hey! The mdadm upload that you have prepared, just to confirm - it's based on what was in updates rather than what was in -proposed, correct?
<gpiccoli> Hi sil2100 o/
<gpiccoli> Exactly, it's based on -updates
<gpiccoli> I've added an entry (as per ddstreet suggestion) related to dannf proposed stuff, and mentioned in my changelog that it was removed
<gpiccoli> This is in order to have users better clarified on what's happened
 * gpiccoli bbiab (~2h)
<jamespage> LocutusOfBorg: linking is wonky on that architecture - "lots of package could avoid a useless dependency"
<LocutusOfBorg> yes I came to the same conclusion
<LocutusOfBorg> linker is not stripping it
<LocutusOfBorg> because objdump on armhf and amd64 shows the same symbols used on both archs, and none related to random
<LocutusOfBorg> doko, ^^ this looks like more a binutils regression TBH
<jamespage> I checked the previous armhf build and it does not appear to have the same issue
<jamespage> looking into the logs now
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10936746/+listing-archive-extra
<LocutusOfBorg> jamespage, ^^
<jamespage> ack
<jamespage> only ref I can find in the source tree is to a test class so it might be needed for the build, but not for the binaries
<infinity> boost_random is being explicitly placed on the linker line, I'm not sure you can blame binutils for doing as asked.
<LocutusOfBorg> infinity, I blame binutils for not correctly stripping it with as-needed provided
<LocutusOfBorg> and I blame it for correctly removing it on everywhere except armhf...
<LocutusOfBorg> moreover, the last run on 22/12/2019 https://launchpad.net/ubuntu/+source/ceph/14.2.4-0ubuntu3/+build/18461332 had the same boost_random link, but no random library linked
<infinity> So, further WTF, why is armhf built with clang and arm64 with g++?
<infinity>   * [6eddb32] Build with clang(++) on armhf mipsel armel.
<LocutusOfBorg> #849657
<infinity> That's likely the cause of the behaviour difference.
<infinity> And it's not needed for Ubuntu, I imagine, where our armhf buildds are beefy.
<LocutusOfBorg> so clang is dumb?
<infinity> clang might indeed be dumb.  Even if it's not, it's really poor form to use different compilers on different arches, and a nightmare to debug the subtle binary differences.
<infinity> jamespage: I'd recommend backing out that g++ -> clang++ change and see if it magically loves you.
<infinity> (make it dependent on a dpkg-vendor is Debian check, if you want to upstream it and let Debian keep their braindead nonsense here)
<jamespage> infinity: good spot
<jamespage> thanks
<LocutusOfBorg> infinity, maybe if you want to upstream the change in Debian, you can ask them to keep gcc and reduce parallelism on arm?
<infinity> No idea if it was an OOM they were working around or hitting the 2G hard limit (but we don't build on 32-bit kernels, so our hard limit's a bit higher for individual userspace processes, or should be)
<infinity> Either way, if it works with g++ on Ubuntu, my carefactor for what Debian does it low.
<jamespage> I'll do the dpkg-vendor trick to exclude ubuntu
<infinity> s/it/is/
<jamespage> happy to push that back to Debian - I'm working with the new maintainer to get things back in sync and still have git commit permissions
<LocutusOfBorg> looks like they are already using max-parallel=2 on armhf
<infinity> Also unnecessary for us.
<infinity> Probably.
<jamespage> you'd be surprised - ceph can hit the ceiling
<infinity> Well, if it works with parallel=4 on other arches, it should on armhf too. :P
<jamespage> of the builder memory size easily with any level of parallel
<infinity> (note that armhf and arm64 buildds are literally identical VMs on identical hardware, and I refuse to believe the 64-bit builds use less RAM)
<jamespage> infinity: whats the memory size?
<jamespage> looking at notes I left myself in the past
<infinity> I believe they're all 4 vCPU, 8G.  I think.
<jamespage> https://www.irccloud.com/pastebin/MmppuWX8/
<LocutusOfBorg> https://salsa.debian.org/ceph-team/ceph/commit/6eddb32731f4edda764eb5f4cd634599a8487ca7
<LocutusOfBorg> I think this commit needs to be relegated to just armel and mipsel
<LocutusOfBorg> or probably only mipsel, I can't find any failure related to OOM in debian buildd logs
<LocutusOfBorg> btw why not package the new release?
<LocutusOfBorg> (funnily enough, all the mipsel hacks didn't work so far, the package still FTBFS there)
<infinity> mipsel probably just needs to die in a fire.
<infinity> Oh, but they're building it on shiny mips64 hardware/kernels now.  So, WTF.
<Laney> Drop it and see what happens. Worst case you have to revert, but yay for unstable being unstable. :)
<LocutusOfBorg> what is the situation for htslib on s390x? debian removed it...
<infinity> I am genuinely curious what horrifying things the ceph people are doing to OOM compilers like this.
<infinity> LocutusOfBorg: It's fascinating to me that the upstream "we think there are endian issues" bug has been open for years, but the massive regression only happened, like, last month.
<infinity> LocutusOfBorg: I'd suggest that bisecting where that went wrong would probably be trivial, but we can tear out the rdep stack too, whatever.
<tarzeau> will 20.04 have python2 or not?
<tarzeau> https://wiki.ubuntu.com/Python/3 not really up to date or?
<ogra> tarzeau, there is a removal discussion on the ubuntu-dvel ML IIRC
<ogra> *-devel
 * tarzeau looks for the ml archive
<gpiccoli> sil2100, I'm back if you have anything to discuss about mdadm =)
<tarzeau> https://lists.ubuntu.com/archives/ubuntu-devel/2020-January/thread.html
<JackFrost> Given the timeframe, there's not enough time for https://people.canonical.com/~ubuntu-archive/transitions/html/python2-rm.html
<JackFrost> https://ubottu.com/y/ff  is the release schedule, if you wondered.
<tarzeau> JackFrost: i'm aware of that still 40 days to get pkgs into 20.04 :)
<tarzeau> i just don't know if 20.04 will have this or not: https://tracker.debian.org/pkg/gmic
<JackFrost> It was already removed, so not if it isn't fixed.
<JackFrost> !info gmic focal
<ubottu> Package gmic does not exist in focal
<tarzeau> i have a fix, but i don't like making nmus
<tarzeau> you'll miss flowblade, sure you could make a snap of it
<JackFrost> The maintainer is lowNMU, fwiw.
<JackFrost> Did you see plugwash's work?
<tarzeau> i know i even asked if he'd mind, and he doesn't, still i hate NMU (personal preference)
<tarzeau> nope, where?
<JackFrost> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922582#18
<ubottu> Debian bug 922582 in src:gmic "FTBFS against opencv 4.0.1 (exp)" [Serious,Open]
<JackFrost> No I understand the distaste for NMUs.
<tarzeau> yeah that's what i applied and given credit to bug reporter (hah, must fix): http://phd-sid.ethz.ch/debian/gmic/
<tarzeau> but then i'm not a fan of just fixing gmic, which is one year old, i'd rather have the latest 2.8.2 (for the next five years)
<tarzeau> but oh well i run unreleased or sid anyways
<JackFrost> I mean, Ubuntu *could* jump ahead I'd imagine.
<tarzeau> i have never figured how to get something into ubuntu/or updated, still doing pkg into debian, waiting archive sync
<tarzeau> and new queue/ debian/copyright is worse than finding dd-who-sponsors-dsc-links
<JackFrost> If at all possible, Ubuntu hates to maintain deltas needlessly.
<tarzeau> yeah i figured, and that's also great!
<tarzeau> but now debian has fasttrack!
<tarzeau> ok ubuntu has frankenPPA
<JackFrost> Which...Isn't complete and doesn't precisely relate? :)
<tarzeau> true, /me will stick to his reprepro (well not me, but user friends)
<tarzeau> instead of deltas, what about allowing packages to circumvent debian new queue pkgs?
<JackFrost> Some have done that, I don't know how frowned upon that is.
<tarzeau> who is that some, and how did they do so?
<JackFrost> (Also, some DDs don't like a dsc?)
<tarzeau> because they prefer salsa git?
<JackFrost> Basically by being the maintainer in Debian too.  But they cheated with a 0build1 trick.
<JackFrost> Ah.  I like things being maintained in git, but dsc for sponsorship is nice.
<tarzeau> is canonical doing HPC stuff?
<tarzeau> (wrong channel to ask that?)
<JackFrost> I'm not a Canonicalite.
<JackFrost> tarzeau: https://salsa.debian.org/fasttrack-team/support/issues/10#note_123991 still isn't the most reassuring.
<rafaeldtinoco> quick question on migrations
<rafaeldtinoco> builddeps:/tmp/autopkgtest.9ZDytk/2-autopkgtest-satdep.dsc:i386 : Depends: wmnd-snmp:i386 but it is not installable
<rafaeldtinoco> is i386 avoiding migrations currently ?
<dannf> gpiccoli: thx!
<gpiccoli> Thank you dannf, for letting me slip my upload first hehe =)
<xnox> jamespage:  fun! build log? Most likely something somehwere is missing, and normally the boost from inside ceph is used, instead of system one. Note that cmake&boost have weird integration now, such that "findboost" might be defaulting to system stuff now.
<infinity> xnox: Check later context, his problem was almost certainy Debian switching armhf to clang, while other arches use gcc.
<xnox> infinity:  oh, ok.
<tdaitx> so, is there a service I can trust to tell me if a given TZ table is actually wrong? in bug 1859217 the user complains that openjdk-8 has regressed on Istanbul TZ, but in fact openjdk-11 was only "working" (as per user description) because upstream didn't update it from tzdata2019b to tzdata2019c (while openjdk-8 did)
<ubottu> bug 1859217 in openjdk-8 (Ubuntu) "openjdk8 update 8u232-b09-0ubuntu1~18.04.1 breaks Timestamp values for timezones that change DST observance" [Undecided,Confirmed] https://launchpad.net/bugs/1859217
<tdaitx> the latest security update for openjdk-11 now includes tzdata2019c and thus both openjdk-8 and openjdk-11 are now reporting the same values - which the user says that they are the wrong ones
<tdaitx> so I need to check if the alleged "right" values are in fact the right ones
<tdaitx> and yeah, I belive tzdata2019c is actually correct and the user is mistaken, but it would be good to check that somehow
<tdaitx> sbeattie: fiy ^
<infinity> tdaitx: I mean, tzdata is the only authority on the topic, other than local governments and mystic divination.
<infinity> tdaitx: On the other hand, 2019c didn't have changes to Istanbul AFAICT...
<tdaitx> infinity: it did: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/8560bc534080 (that's the openjdk commit for it, it's the same as openjdk-11 and I suppose the same for upstream)
<Laney> The announcement says it changed some historical data for Turkey
<infinity> tdaitx: Oh, yeah, deep in the past.
<tdaitx> yeah
<infinity> If you want to check if they're right, Paul gives references in the comments.
<infinity> But your user's bug is likely a non-bug.
<tdaitx> infinity: sorry, which bug are you referring to?
<infinity> tdaitx: The one you linked?
<tdaitx> infinity: I don't see any comments from Paul
<Laney> Paul is upstream of tzdata
<infinity> tdaitx: Your user's complaint of regression is more just business as usual for tzdata.  It's unfortunate that different Java versions will all disagree until they're all updated, but that's their own fault for bundling tzdata instead of using system zone files. :P
<infinity> tdaitx: Oh, "the comments" being the comments in the zone files.  Paul Eggert being Paul.  When he changes things, he leaves comments referencing why (usually URLs to papers on the topic, etc)
<infinity> tdaitx: But generally, I trust him to be right, as he's the de facto authority on timezones anyway.  The world all uses tzdata as their authoritative set, so even if it's wrong, it's right.  Until the next version, which is more right.
<tdaitx> right, found it (it was the link for the commit, not a bug report, that's why I got confused)
<tdaitx> ok, good to know
<tdaitx> Laney: infinity: thanks
<jamespage> xnox: figured it out - have an upload in testing atm
<tdaitx> infinity: as for 'checking' the results, I used a simply "date --date='TZ="Europe/Istanbul" 1943-01-01 12:01:01' '+%s'" which confirms the openjdk output
<rafaeldtinoco> ahasenack: ping
<ahasenack> rafaeldtinoco: hola
<rafaeldtinoco> ahasenack: if you have ~5 min, could u check if it makes sense to add wmnd i386 test to britney hints file ?
<rafaeldtinoco> both autopkgtests from it are mutual exclusive (wmnd and wmnd-snmp)... somehow autopkgtest can't handle test dependencies for i386
<rafaeldtinoco> not quite sure why
<rafaeldtinoco> but everything is ok for i386 as well, Im afraid it will block its migration, and that is the last for net-snmp I believe
<ahasenack>  builddeps:/tmp/autopkgtest.WFivWM/1-autopkgtest-satdep.dsc:i386 : Depends: wmnd:i386 but it is not installable
<ahasenack> have you tried installing that to see why it's uninstallable?
<rafaeldtinoco> Broken builddeps:/tmp/autopkgtest.WFivWM/2-autopkgtest-satdep.dsc:i386 Depends on wmnd-snmp:i386:any < none @un H >
<rafaeldtinoco> yep.. if I install locally generated .deb .. it passes test1
<ahasenack> well
<ahasenack> no
<ahasenack> I mean, on a amd64 host, add the i386 arch
<ahasenack> and then try to install wmnd-snmp:i386
<ahasenack> you have wmnd in a ppa somewhere?
 * rafaeldtinoco checks
<rafaeldtinoco> nope, will provide
<rafaeldtinoco> ahasenack: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1855943
 * ahasenack checks
<rafaeldtinoco> it does not work with add-architecture
<rafaeldtinoco> it depends on having a full i386 env
<rafaeldtinoco> it can't even find :i386 package
<ahasenack> well, that ppa didn't build i386
<rafaeldtinoco> oh, yep
<rafaeldtinoco>  Intel x86 (i386)
<ahasenack> https://launchpad.net/ubuntu/+source/wmnd/0.4.17-3ubuntu1 also didn't
<rafaeldtinoco> it had default
<rafaeldtinoco> yep
<rafaeldtinoco> i guess its "deactivated
<ahasenack> yes, not in the whitelist
<rafaeldtinoco> that explains
<ahasenack> vorlon: ping ^
<ahasenack> just a case for a badtest hint for wmnd/i386?
<rafaeldtinoco> i believe so
<rafaeldtinoco> its blocking net-snmp
<rafaeldtinoco> which is blocking pcs
<ahasenack> relax :)
<ahasenack> many things are blocking many things in the archive at any given time :)
<ahasenack> vor-lon might be mid-travel (sprint)
<rafaeldtinoco> oh, true
<rafaeldtinoco> https://media.giphy.com/media/5qoRdabXeT4GY/giphy.gif
<rafaeldtinoco> =)
<rafaeldtinoco> alright Ill shift context then
<rafaeldtinoco> this one is almost there
<ahasenack> you can propose an MP for the badtest, assuming that is the right thing
<rafaeldtinoco> ahasenack: yep, will do it
<rafaeldtinoco> tks
<vorlon> ahasenack: hinted
<ahasenack> rafaeldtinoco: ^
<ahasenack> vorlon: thanks!
<vorlon> ahasenack: and yes, this is the correct course of action for any source packages not in the list I posted to ubuntu-devel
<rafaeldtinoco> nice.. good to know
<ahasenack> seconded
<seb128> vorlon, https://launchpad.net/ubuntu/+source/glib2.0/2.63.3-2 added a depends from the libglib2.0-tests to xdg-desktop-portal which is blocking migration since xdg-desktop-portal isn't available on i386. What's the recommended solution there? changing glib to not build the -tests package on i386?
<ahasenack> vorlon: from https://pastebin.ubuntu.com/p/HmSd9xd7NN/, on an amd64 lxd with i386 added, I was able to install krb5-multidev:i386 libkrb5-dev:i386 and libkrad-dev:i386 just fine, but not build-essential. I don't even know why it's trying to install build-essential, the dep8 tests only require @ for the kinit test, and @, slapd, ldap-utils, libsasl2-modules-gssapi-mit for the slapd-gssapi test
<ahasenack> and this passed before, lemme get the link
<ahasenack> http://autopkgtest.ubuntu.com/packages/krb5/focal/i386
<ahasenack> build-essential amd64 was used the last time this i386 test passed
<ahasenack> hmm, same this time
<ahasenack> ah, if I enable proposed, then build-essential (amd64) becomes uninstallable
<ahasenack>  build-essential : Depends: libc6-dev but it is not going to be installed or
<ahasenack>                             libc-dev
<ahasenack>                    Depends: g++ (>= 4:9.2) but it is not going to be installed
<ahasenack> linux-libc-dev (src:linux) 5.4.0-11.14 is in focal-proposed according to rmadison, but  don't see it listed in https://launchpad.net/ubuntu/+source/linux (yet?)
<ahasenack> https://launchpad.net/ubuntu/+source/linux/5.4.0-11.14 is a 404
<ahasenack> oh, there is a linux-5.4 source
<ahasenack> https://launchpad.net/ubuntu/+source/linux-5.4 it tricks us
<ahasenack> focal-specific
<sarnold> ahasenack: I've found this helpful to try to keep track of the various kernel source packages https://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html
<ahasenack> thanks
<ahasenack> I'll wait for the kernel builds to settle a bit in proposed/migration
<LocutusOfBorg> infinity, https://github.com/samtools/htslib/commit/418a183ef842a966afb00e783c09ac7fd7eaeb62
<LocutusOfBorg> does this ring a bell?
<LocutusOfBorg> I git bisected it
<LocutusOfBorg> and that is the first commit with s390x failing
<vorlon> seb128: yes, I would say omit the glib-tests package
<seb128> vorlon, k, thanks
<vorlon> ahasenack: build-essential:amd64 is installed because the way we're installing cross test deps leverages apt-get build-dep; so build-essential:native is always required by apt
<ahasenack> I see
#ubuntu-devel 2020-01-18
<mitya57> RikMills: pymca's SIGILL on arm64 is a real issue, I can reproduce it on a porterbox. Retrying the autopkgtest won't help.
<RikMills> mitya57: yeah, I worked that out
<mitya57> I wonder if it can be related to Debian #948803
<ubottu> Debian bug 948803 in binutils "gcc-9: collect2: fatal error: ld terminated with signal 4 [Illegal instruction]" [Serious,Fixed] http://bugs.debian.org/948803
<RikMills> o_O https://launchpad.net/debian/+source/binutils/2.33.50.20200114-1
 * mitya57 tests a no-change rebuild
<mitya57> Yes, a no-change rebuild seems to help \o/
<RikMills> mitya57: \o/ indeed!
<doko> mitya57, tumbleweed: could we have python-ubuntutools back again for some time? ubuntu-archive-tools still relies on it
<mitya57> doko: I am not maintaining it, so not sure why you mentioned me. However, at least some tools from ubuntu-archive-tools support Python 3. Did you try just running them with right interpreter?
<doko> oops
