[12:13] <LaserJock> Were the Hoary pre-release cd's called Array?
[12:17] <Kamion> LaserJock: yes
[12:17] <Kamion> Warty => Sounder, Hoary => Array, Breezy => Colony, Dapper => Flight
[12:18] <LaserJock> Kamion: aww, thanks
[12:26] <Kamion> anyone here speak any of: Arabic, Czech, Esperanto, Estonian, Farsi, Hindi, Croatian, Korean, Punjabi, Slovak?
[12:33] <mdke> Kamion, maybe i18n on gimpnet?
[12:33] <mdke> or some such channel
[12:34] <Kamion> not bothered enough to join even more channels :)
[12:34] <mdke> heh
[12:34] <mdke> Kamion, in that case you can use babelfish!
[12:34] <Kamion> no, I'm looking for conjugations of "Ubuntu" in those languages
[12:34] <mdke> ah
[12:35] <mdke> has anyone who is quite good at linux got a checkout of the docteam svn repo handy?
[12:36] <azeem> mdke: "quite good at linux" is a pretty unspecific qualification for -devel chans
[12:36] <mdke> azeem, tbh the main qualification was the second bit
[12:36] <mdke> for the first bit, anything better than me will suffice
[12:46] <Kamion> Riddell: how are your merges going? I think you hold the record for most assigned at the moment
[12:46] <Kamion> do you need somebody to help with them?
[12:47] <floam> daniels: sorry to keep bugging you, but have you gotten anywhere with the input issues on xorg 7.0? (bug #20052)
[12:48] <ajmitch> night mvo
[12:48] <mvo> night ajmitch
[12:48] <Kamion> floam: he's on vacation this week
[12:48] <sistpoty> mdke: he, i just did a checkout... but I don't know if I'm "quite good at linux" ;)
[12:50] <mdke> sistpoty, yeah you are...
[12:50] <mdke> sistpoty, ok perhaps best if you come to #ubuntu-doc
[12:50] <mdke> sistpoty, have you got a spare 10 minutes btw?
[12:50] <sistpoty> mdke: sure
[12:55] <mhz_dinner> mako: ping?
[12:56] <azeem> mhz_dinner: maybe write him a mail, if he is not watching irc
[12:58] <mhz_dinner> azeem: okis
[01:34] <Kamion> woo, one merge to go
[01:34] <Kamion> (for me)
[01:35] <mdke> night
[01:36] <sistpoty> elmo: pleasy sync labplot from unstable, ubuntu override ok. thx.
[01:56] <floam> Kamion: heh great
[02:03] <mdke> the mailing lists are pretty slow, i think they are about 3 hours behind
[02:05] <mhz_dinner> mdke: r u there?
[02:05] <mdke> yes I am
[02:06] <mhz_dinner> mdke: can I intrrupt you idling or anything you are doing?
[02:06] <mdke> mhz_dinner, shoot
[02:06] <mhz_dinner> I have created 2 teams in LP
[02:06] <mhz_dinner> both seem to be ok
[02:06] <mhz_dinner> except by the fact that I am requested to get email confirmation
[02:07] <mhz_dinner> and when I try to follow the process, I get error
[02:07] <mhz_dinner> yes, I am in #launchpad as well
[02:07] <mdke> i think that only they can help you
[02:07] <mhz_dinner> so my only doubt arises...
[02:08] <mhz_dinner> to create teams, do i have to be 100% aproved ubuntu member?
[02:08] <mhz_dinner> afaik, i am 99% only
[02:08] <mdke> mhz_dinner, no, i wouldn't have thought so. Anyone can create a team.
[02:08] <mhz_dinner> oh, ok.
[02:10] <mhz> mdke: thx for eliminating variables :D
[02:13] <dilinger> totem's little popping noises are so incredibly annoying
[02:14] <crimsun> default totem-gstreamer or totem-xine?
[02:14] <dilinger> hm, actually, this is gnome's little noises.  good, that means i should be able to shut it up
[02:14] <crimsun> ah.
[02:14] <dilinger> ah, much better
[02:17] <mdke> mhz, what email address are you using?
[02:18] <mdke> speaking of noises, has the Ubuntu login sound changed between breezy and dapper?
[02:18] <floam> not yet
[02:19] <crimsun> not according to the timestamp ,no.
[02:19] <mdke> well it sounds a lot better on my laptop
[02:19] <mdke> guess that means the hardware support has improved
[02:20] <crimsun> running 2.6.12-{9,10} or 2.6.15-4?
[02:21] <mdke> 2.6.12-9
[02:21] <mdke> same as the old breezy kernel
[02:21] <nekohayo> is there a Matthew Paul Thomas around? :)
[02:22] <mhz> mdke<EMAIL_ADDRESS>[02:22] <nekohayo> or someone having his email
[02:22] <mhz> mdke: i tried<EMAIL_ADDRESS>but it only let me used the gmail one
[02:22] <mdke> nekohayo, he is on holiday or away i think
[02:23] <mdke> nekohayo, you can get him at mpt at myrealbox dot com
[02:23] <mdke> mhz, you've verified the email address?
[02:24] <nekohayo> thank you mdke (because I started putting together http://start.nanokron.info and just discovered his wiki entry on that matter)
[02:25] <mdke> nekohayo, ah cool
[02:38] <mhz> mdke: what yo mean?
[03:12] <moquist> I'm looking at creating a .deb for the vnc-ltsp-config package that is available as an RPM for K12LTSP, and I'm wondering how to handle the extra services that need to be added (e.g., "vnc-1024x768x16 5900/tcp").  I don't see a way to add these services other than by appending to /etc/services, which really doesn't seem like the right thing to do (since this .deb certainly doesn't own /etc/services).  Any advice or ...
[03:12] <moquist> ... pointers?
[03:14] <infinity> moquist : It can't work without the extra services entries, or you just want them there for completeness?
[03:15] <infinity> moquist : If they're required, file a bug on 'netbase', it owns the service database.
[03:16] <sistpoty> infinity: is nvtv p-a-s?
[03:16] <infinity> Probably.
[03:17] <infinity> (base)adconrad@lucifer:~/build/dak/srcdep$ grep nvtv Packages-arch-specific
[03:17] <infinity> %nvtv: i386 amd64                                                     # [?]  ANAIS, <sys/io.h>
[03:17] <sistpoty> hm... strange it didn't build on amd64 yet
[03:17] <moquist> wow; so the right thing to do is get those service officially added into /etc/services by netbase?  5900 is the starting point for vnc server ports, so handing it over to vnc-ltsp-whatever doesn't seem like a good thing to do unless that package is installed.
[03:18] <sistpoty> infinity: could you please kick at it for amd64?
[03:19] <infinity> sistpoty : Hrm, not registered on amd64.
[03:19] <elmo> I've updated p-a-s
[03:19] <infinity> elmo : Please sync Packages-arch-specific from ... Oh..  For publishing to a remote branch and doing merge checks and permission checks?
[05:45] <elmo> akurashy: please turn the public away off
[07:04] <wasabi> Grrr. udevstart is now locking me up
[07:04] <wasabi> i just can't win today
[07:26] <dholbach> good morning
[07:27] <janimo> dholbach, morning
[07:28] <dholbach> hey janimo :)
[07:28] <janimo> hey :)
[07:28] <magnon> morning :)
[07:29] <dholbach> hi magnon
[07:29] <dholbach> you're up early guys :)
[07:29] <magnon> I never went to bed
[07:29] <magnon> or, I slept from about 2 to midnight yesterday
[07:29] <magnon> then went down to the office and worked
[07:30] <dholbach> i see... :)
[07:47] <janimo> elmo, please sync, override ok : dbh, libxfce4util, libxfcegui4, libxfce4mcs, xfce-mcs-plugins, xfce4-utils, xfce4-panel, xfce4-session, xfce4-appfinder, xfprint4, xfce4-mixer, xfcalendar,xfwm4, xfwm4-themes, xfce4-iconbox, xfce4-systray, xfce4-trigger-launcher
[07:47] <janimo> thank you
[07:48] <crimsun> excellent.
[07:49] <dholbach> xubuntu team strikes again :)
[07:49] <magnon> good, good :)
[07:50] <janimo> elmo, also xfce4-icon-theme, gtk2-engines-xfce, thanks
[07:50] <janimo> since it seems people like syncs being asked for ;)
[07:51] <janimo> crimsun, hi, debian xfce say that there is no need for autotools-dev in build-dep, and no xinerama either
[07:51] <janimo> let's see if these will build on ubuntu w/o them
[07:52] <janimo> although they require autotools-dev be present on the debian packager's box at build time
[07:53] <crimsun> janimo: they upload debs, though, we don't
[07:53] <janimo> I know, I hope I'll be able to convince them
[07:54] <crimsun> janimo: I'm not particularly worried about removing autotools-dev; it's amd64 that may ftbfs
[07:54] <janimo> anyway xfce4.2.3 is supposed to have new config.sub &guess
[07:54] <crimsun> yeah, if that's the case, then most likely we can strip autotools-dev
[07:54] <janimo> and if there's no autotools-dev the rules file is still valid
[07:54] <crimsun> right
[07:54] <janimo> yeah, that's why I asked for override everything
[07:55] <janimo> they picked up most of our non FTBS ubuntu pacthes
[07:55] <janimo> let's cross our fingers ::)
[07:55] <crimsun> rockin' :))
[07:57] <janimo> too bad we have epochs on some packages which will likely req manual intervention for now on
[07:57] <crimsun> yeah, that's a pain
[08:16] <pitti> Good morning
[08:19] <dholbach> morning pitti
[08:19] <pitti> Hey dholbach
[08:19] <Mithrandir> pitti: did you have a chance to look at sane-backends yesterday?
[08:20] <pitti> Mithrandir: no, sorry; let's do it right now, where was the diff again?
[08:21] <sivang> Good morning
[08:21] <pitti> Hi sivang
[08:21] <Mithrandir> pitti: http://people.ubuntu.com/~tfheen/sane-backends/
[08:21] <Mithrandir> pitti: and thanks
[08:21] <pitti> Mithrandir: the new package generates udev rules on the fly?
[08:23] <pitti> Mithrandir: libgphoto2 is a similar case; I merged it but hold back the upload since the new udev is not yet there
[08:23] <Mithrandir> pitti: no, they're created in the debian/rules file?
[08:23] <pitti> Mithrandir: since libsane uses libgphoto-port which in turn uses libusb, which depends on the newer dev naming scheme of our future udev
[08:24] <pitti> Mithrandir: so did the merged version already work for you?
[08:24] <Mithrandir> pitti: haven't tried it, since I need to patch sane for my driver to work anyway.
[08:25] <Mithrandir> but I don't think uploading a random experimental CVS snapshot of a driver is a good idea, so I'm not going to do that for the packages in dapper
[08:25] <pitti> Mithrandir: uh, ok; then we should better wait until Keybuk uploads udev
[08:25] <Mithrandir> pitti: that's tomorrow, I think, so ok.
[08:25] <pitti> Mithrandir: libusb expects the device in /dev/bus/usb/x/y or /proc/bus/usb/x/y
[08:26] <pitti> Mithrandir: but the current udev creates /dev/usbdevx.y
[08:27] <Mithrandir> ah
[08:31] <infinity> pitti / Mithrandir : The new udev will be uploaded as soon as I upload lrm and linux-meta.
[08:33] <pitti> Mithrandir: you still install /etc/hotplug/usb
[08:33] <Mithrandir> pitti: Is that wrong?
[08:33] <pitti> Mithrandir: can you please drop these files (script and usermap)?
[08:33] <pitti> mom, telephone
[08:33] <pitti> brb
[08:33] <Mithrandir> pitti: yes, sure.  Is there a policy on how to do hotplugging and udev support those days?
[08:39] <infinity> Mithrandir : You may find changelogs (and packages) helpful from here: http://people.ubuntu.com/~scott/packages/new-udev/
[08:40] <pitti> back
[08:40] <pitti> Mithrandir: your postinst purges the usermap and script for both /etc/hotplug/usb and /etc/hotplug.d
[08:40] <pitti> Mithrandir: so it hardly makes sense to install them in the postinst
[08:41] <pitti> Mithrandir: the udev rules should be very simple: if vendor and product ID matches, you should assign OWNER, GROUP and MODE
[08:41] <pitti> Mithrandir: so you don't need any additional maps and scripts any more
[08:42] <pitti> Mithrandir: so apart from the two superfluous install commands in debian/rules, the diff looks good (and it's very small)
[08:42] <pitti> Mithrandir: one nitpick would be that the old hotplug.d/hotplug files shuold be removed in preinst, not in postinst
[08:42] <pitti> Mithrandir: otherwise dpkg registers them as removed conffiles, but they should go away entirely
[08:43] <pitti> Mithrandir: right now it is impossible to reintroduce the files again
[08:52] <Mithrandir> pitti: ok, I'll provide a fixed package
[08:53] <pitti> Mithrandir: how do the udev rules look like?
[08:54] <dholbach> hey vuntz_
[08:55] <vuntz_> hi all
[08:55] <zakame> hey vuntz_
[09:06] <\sh> moins
[09:16] <mdke> elmo, Znarl, would love it if you could chase up rt #917 (docteam commit access)
[09:22] <\sh> infinity: ping what are you thinking about this apache2 error message: (75)Value too large for defined data type: access to /mirror/isos/ubuntu/breezy-dvd-i386.iso failed
[09:22] <Mithrandir> \sh: apache 2.0 doesn't support large files.
[09:23] <\sh> Mithrandir: well..this should be changed :)
[09:23] <Mithrandir> \sh: no, it shouldn't.  It breaks a lot of stuff.
[09:23] <Mithrandir> it's fixed in 2.1
[09:24] <infinity> \sh : You  can rebuild locally with the patches I've included in the source, but it WILL break ABI, and may break some stuff you choose to rebuild against it.
[09:24] <infinity> \sh : Poke in debian/rules for the commented out CFLAGS, and in debian/patches/to-review for the LFS patches.
[09:24] <fabbione> infinity: while you are around, do you mind to babysite devmapper and lvm2 uploads? lvm2 should go dep-wait on the new devmapper
[09:24] <infinity> \sh : And don't come crying to me if it breaks.  You've been warned. :)
[09:25] <\sh> infinity: hmmm...do you think we will get it for dapper server flavour. Because largefile should be supported somehow
[09:25] <fabbione> infinity: it should do it automatically.. but you may never know
[09:25] <\sh> infinity: i will never cry, when I break things....
[09:25] <infinity> fabbione : if it has a versioned build-dep, there's nothing I need to babysit.
[09:25] <Mithrandir> \sh: dapper might get 2.1.
[09:25] <fabbione> it does...
[09:25] <\sh> Mithrandir: cool
[09:25] <fabbione> infinity: it still doesn't ensure i didn't mess it up :P
[09:25] <infinity> dapper won't get 2.1 without a miracle.
[09:25] <Mithrandir> infinity: it won't?  I thought 2.1 was supposed to be released around now?
[09:26] <infinity> Even if it was (and it's not close), I wouldn't trust it for a fe wmonths.  That makes a pretty tight schedule for dapper.
[09:26] <infinity> Especially for a "supported for 5 years" release.
[09:26] <sivang> mornig \sh
[09:26] <infinity> I could probably be talked into doing pre-release 2.1/2.2 stuff for dapper+1 and supporting it for 18 months.
[09:27] <\sh> infinity: alternative is "switching back to apache1"?
[09:27] <fabbione> \sh: there is no alternative
[09:27] <infinity> \sh : Which also doesn't have proper LFS.
[09:28] <infinity> \sh : The alternative is "run on amd64, alpha, or ia64, where all file operations are large by definition"
[09:28] <infinity> \sh : LFS on i386/powerpc just won't happen until apache 2.2 is stable.
[09:28] <Mithrandir> you could probably do it with a CGI script?
[09:28] <\sh> ok then...I'll try to steal one of the ds15 alphas here :)
[09:29] <infinity> If you never told apache how large the stream was, and just shoved it out?... Maybe.  But 4.5 gigs of CGI output sounds sketchy.
[09:29] <infinity> (very)
[09:29] <\sh> well...yes...dvd iso streaming...directly into k3b .. let's code this crack asap
[09:29] <Mithrandir> infinity: you could write the Content-Size header yourself and ask apache to stay away from understanding it?
[09:30] <Mithrandir> I guess you could do it from php, even. *shudder*
[09:30] <infinity> Content-Length, even.  And apache will have a poke at it.
[09:30] <\sh> I wonder what sort of weed I have to smoke...
[09:30] <infinity> You could do it with a module, though, and override that behaviour.
[09:30] <Mithrandir> infinity: nph could work around it.
[09:31] <Mithrandir> fabbione: haha. :-)
[09:31] <\sh> @if test "$(DESTDIR)$(bindir)" != "$(ROOT)/usr/bin" && test "$(DESTDIR)$(bindir)" != "$(ROOT)/usr/bin/"; then \
[09:31] <\sh>          echo "Making symbolic links in /usr/bin..."; \
[09:31] <\sh> the best Makefile.am rule ever
[09:31] <\sh> it's so useless
[09:31] <ajmitch_> \sh: eh?
[09:31] <\sh> but break builds
[09:32] <\sh> ajmitch_: read very c a r e f u l l y...
[09:32] <fabbione> it checks the same thing twice
[09:32] <\sh> fabbione: ah no
[09:32] <fabbione> it does
[09:33] <\sh> fabbione: debian/rules defines in install: make ROOT=$(CURDIR)/debian/temp
[09:33] <magnon> it checks if the same thing really is the same thing :)
[09:33] <\sh> fabbione: but not destdir
[09:33] <\sh> fabbione: but even if you devine DESTDIR together with ROOT it fails
[09:33] <\sh> define even
[09:33] <fabbione> brb
[09:33] <magnon> kind of like failing if 2+2 != 4
[09:34] <\sh> magnon: well...as I said it's useless, and it's not working for a this package...so I have to patch :)
[09:34] <magnon> improve it rather, I mean, if that fails because it SHOULD fail, then something is really wrong :D
[09:37] <Mithrandir> mdz: hmm, on dappergoals, the network-authentication spec isn't there.  Is it, or is it not a dapper goal?
[09:37] <janimo> pitti, do main inclusion reports get reviewed only when prompted by anastacia output?
[09:37] <\sh> real life work...brb
[09:38] <pitti> janimo: no, I might do them earlier, but usually an immediate urge by anastacia speeds up the process :)
[09:39] <janimo> pitti, since the xfce packages I added to the queue are part of xubuntu seeds which are not build on canonical machines so they do not show up in anastacia
[09:40] <pitti> janimo: what do you mean by 'not built on canonical machines'?
[09:40] <janimo> on the Canonical CD building machines
[09:41] <janimo> not official that is
[09:41] <janimo> not by Kamion
[09:42] <janimo> the seed list for xubuntu is on my localhost
[09:45] <pitti> oh, ok; but the packages itself are built on an Ubuntu buildd
[09:45] <janimo> yes
[09:46] <janimo> standard universe packages
[09:46] <mdz> Mithrandir: it is, and I've added it to the page now
[09:46] <fabbione> hey mdz
[09:52] <Mithrandir> mdz: ok, thanks.
[10:00] <raphink> hi there
[10:00] <raphink> stuck in tty since I just upgraded to dapper again ...
[10:00] <raphink> and X won't start ...
[10:01] <raphink> fglrx doesn't install well it seems
[10:02] <infinity> raphink : SWitch to the ati driver for now.  fglrx will be fixed tonight.
[10:15] <fabbione> infinity: you should be able to give back lvm2
[10:15] <fabbione> new binaries are in the archive
[10:16] <fabbione> (for libdevmapper)
[10:54] <pitti> fabbione: yay, your sparc builder finally built sasl, so db4.1, krb4, and libmysqlclient-lgpl can now go to universe :)
[10:55] <fabbione> pitti: yes. it did it yesterday i think
[10:55] <fabbione> after a couple of main/* give-back
[10:55] <fabbione> there were B-D uninstallable for a while
[10:56] <ajmitch_> yay, more universe junk for us
[11:01] <sivang> ajmitch_: lol
[11:05] <pitti> Riddell: can you please build kdelibs4 against gamin instead of fam?
[11:06] <davyd> daniels: around?
[11:06] <pitti> davyd: he's on vacation until next week
[11:06] <davyd> is nvidia-glx in the queue to be rebuilt for dapper?
[11:14] <infinity> davyd : yes.
[11:15] <davyd> care to hazard a guess at how long the amd64 queue is? would it be faster to grab the source and rebuild it myself?
[11:16] <infinity> What source?
[11:16] <infinity> (hint: I still need to upload stuff to fix your issues)
[11:18] <davyd> ok, I can wait
[11:33] <ajmitch_> akurashy: please, turn off those away messages
[11:33] <Mithrandir> akurashy: oh please, turn of that public away.
[11:33] <akurashy> sorry
[11:48] <Kamion> BenC: I've mailed ubuntu-devel@ with some questions about update-initramfs use, FYI
[11:52] <seb128> Kamion: can you promote libgpod-dev/libgpod0 so rhythmbox can build? :)
[11:57] <seb128> s/can/could/
[11:58] <Kamion> seb128: need to rerun cron.sync first, doing that now
[11:58] <seb128> thanks
[12:01] <Kamion> seb128: it's still not showing up in anastacia output?
[12:03] <seb128> Kamion: ups, I've dropped the Build-Depends somewhere, uploading a new revision now with it
[12:03] <Kamion> seb128: I've promoted it for now anyway
[12:04] <seb128> and package uploaded
[12:04] <seb128> thanks
[12:08] <Kamion> Package alacarte has broken dep on smeg
[12:08] <Kamion>   Considering smeg 0 as a solution to alacarte 0
[12:08] <Kamion>   Holding Back alacarte rather than change smeg
[12:08] <Kamion> hmm, I wonder why dist-upgrade doesn't like this
[12:33] <slomo_> BenC: 2.6.15-5 boots fine on my ibook... (I'm currently using ext2 for /boot)... only problems are hardware clock access doesn't work because genrtc isn't loaded by default... and setting the brightness with the keys doesn't work too
[12:35] <slomo_> BenC: also for linux-headers asm/highmem.h is missing which is included by linux/highmem.h
[12:37] <Kamion> is anyone working on mozilla-firefox-locale-all?
[12:38] <Kamion> it needs an update for firefox 1.5 in order for language-support-* to be installable again
[12:39] <Kamion> looks relatively easy to update, I guess ...
[12:51] <slomo_> BenC: and evdev should be loaded by default to get brightness setting, etc
[12:53] <mvo> BenC: the at76c503 driver can't find it's firmware anymore
[12:53] <mvo> BenC: in the 2.6.15-5 kernel (k8)
[12:55] <lifeless> Diziet: ping
[12:56] <Diziet> Ah, hi.
[12:57] <lifeless> Diziet: ah excellent
[12:57] <Diziet> I don't know how much you wanted to talk about ?  Should we get a channel or will here do ?  It seems quite quiet here atm ...
[01:01] <lifeless> yah
[01:01] <lifeless> I've just been pulled into a discussion on #launchpad that I think I need to address quickly.
[01:01] <Diziet> Oh, OK.
[01:01] <lifeless> then I will be all eyes and fingers
[01:02] <Diziet> How alarming.
[01:10] <lifeless> Diziet: ok
[01:10] <lifeless> so, testing.
[01:10] <Diziet> Ah, hello again.  Good.
[01:11] <lifeless> what a whacky day.   But I only started an hour and a half ago so it's not had time to go really odd.
[01:11] <lifeless> :)
[01:12] <Diziet> But I have a lunch appointment elsewhere so we should try to have this conversation :-).
[01:12] <lifeless> ok
[01:12] <lifeless> so with the testing spec
[01:12] <Diziet> Right.
[01:13] <lifeless> there seem to be two maybe-three levels of goals
[01:13] <Diziet> Mmmhmm.
[01:13] <lifeless> the primary one roughly a more comprehensive lintian
[01:13] <lifeless> but driven by the package
[01:13] <lifeless> in that its focused on the packaging aspects of the package.
[01:13] <Diziet> Err, sort of.
[01:14] <lifeless> I know thats terribly handwavy
[01:14] <Diziet> Well packaging+functionality together.
[01:14] <Diziet> Do carry on.
[01:14] <mvo> ogra: did you requested the notification-daemon sync? are all our patches still in?
[01:14] <ogra> mvo, seb128 cared for it ... i guess they are
[01:14] <mvo> ogra: ok, thanks
[01:14] <lifeless> secondly to be able to run somewhat arbitrary code which is tests
[01:15] <lifeless> in an insulated manner
[01:15] <Diziet> Right, the virtualisation thing.
[01:15] <lifeless> that is allowed to do unpleasant things as part of testing
[01:15] <Diziet> That's essential to integrate the automated testing into launchpad.
[01:15] <lifeless> i.e. screw up a system so it can try to repair it, if thats something the package does
[01:15] <Diziet> It's not so important in the Debian context because there I think it'll be more ad-hoc.
[01:15] <seb128> mvo: yeah, they based the Debian upload on the previous Ubuntu packages
[01:16] <Diziet> lifeless: Right.
[01:16] <mvo> seb128: ok, thanks
[01:16] <lifeless> and what I'm seeing as a third goal is somewhat social, which is to encourage the testing of packages, and the running of their upstream test suites in a methodical manner
[01:16] <lifeless> so this isn' the 4 pieces needed to deliver the spec : I'm talking about the strategic outcomes
[01:16] <Diziet> Right.  One key thing that's needed is to provide a place and a way for everyone to put their test and document them.
[01:17] <lifeless> if that makes sense :)
[01:17] <Diziet> Absolutely.
[01:17] <lifeless> ok cool
[01:17] <sivang> Diziet: I think this is important for even "simple" out of pkg testing, as in TestPlans
[01:18] <sivang> (e.g. manual testing)
[01:18] <lifeless> so the things I'm thinking about at the moment are:
[01:18] <Diziet> sivang: Right, one of the things I'd like to be able to have is for something like TestPlans to say `now invoke the automated test-runner'.
[01:19] <lifeless>  * should there be a simpler-than-the-control-file API for a test runner
[01:19] <Diziet> simpler API> You mean, a simpler API for the _caller_ ?
[01:19] <lifeless>  where the control file and virtualisation regime interactions are implemented under that api
[01:19] <Diziet> Or a simpler interface to providing the tests ?
[01:19] <lifeless> uhm.
[01:20] <lifeless> an api with a lot less functionality that can collate the results from what you have described
[01:20] <Diziet> The test-runner is the thing that there really only needs to be one of.  The virtualisation regimes and test suites are the things there are lots of.
[01:20] <lifeless> which lets other test runner environments fit in more compactly
[01:20] <lifeless> i.e. move the test runner you have designed down a level.
[01:20] <Diziet> Oh, I see, you mean a common interface to (a) this test runner thing I have in AutomatedTesting (b) anything else you think of that doesn't need the virtualisation features and the per-package tests and what-have-you.
[01:21] <lifeless> prior art here: the xUnit infrastructure has a runner which can test one and only one test, but the test can report on many tests and do what-have-you as needed
[01:21] <Diziet> Lintian would be an example of (b).
[01:21] <lifeless> this is extremely flexible as long as the interface for *reporting* is comprehensive enough.
[01:21] <lifeless> yes, exactly.
[01:22] <lifeless> (lintian as an example)
[01:22] <Diziet> Right.  I think that sounds good but it would need designing.
[01:22] <Diziet> And my design in AutomatedTesting would certainly fit in to something like that.
[01:22] <lifeless> excellent
[01:22] <Diziet> You might have to change the `caller' interface to my test-runner to make it fit your new API but that's just a simple matter of a bit of glue.
[01:22] <sivang> lifeless: implementing such an api seems daunting, given amount of of differing functionalities the-control-file could expose, no?
[01:23] <lifeless> sivang: not at all, this is why you make it simple. then someone implements their own test to do whatever they need, or they build on the runner Diziet will be doing for the virtualised test regime etc
[01:23] <Diziet> OTOH I don't really want to get bogged down myself in designing that API just yet.  It's probably best just to see what AutomatedTesting turns out like and then think about what the commonality is between (eg) it and lintian.
[01:23] <lifeless> Diziet: I shall do up a straw man for you tomorrow and mail it.
[01:23] <Diziet> Sure, do.
[01:24] <sivang> lifeless: Could I ask you to include me in that email exchange as well please?
[01:24] <lifeless> some things that are extremely useful in running tests are:
[01:25] <lifeless>  * reporting tests that pass
[01:25] <lifeless>  * reporting tests that could not run (i.e. this xen is not installed to do nasty-tests with)
[01:25] <lifeless>  * reporting tests that were not run because they are disabled (i.e. its a buggy test)
[01:25] <lifeless>  * reporting tests that failed (the exact condition checked for was not found)
[01:26] <lifeless>  * reporting tests that errored (some random thing went wrong)
[01:26] <lifeless>  * asking for some subset of tests by a string pattern to run
[01:27] <lifeless> do they all seem relevant to you ? I'd like use to support them in the top level api for ease of access
[01:28] <Diziet> Right.  The interface provided by the test-runner will have to specify ways to deal with those things.
[01:28] <Diziet> I'm not sure that my current plan has support for all of those features.  For example, tests that error (as you say) will probably make the test runner error too.
[01:28] <sivang> lifeless: maybe it's beneficial to have another one, like test not supposed to pass yet (e.g. test written ahead of feature implementation)
[01:28] <lifeless> ah. So theres another point
[01:29] <lifeless>  * stop the test runner on the first failure | test all tests and report details at the end
[01:29] <lifeless> sivang: thats known as an expected failure, we're doing that for Bzr, I missed it above.
[01:30] <lifeless> sivang: but the key thing is putting in the idea that these sorts of things can occur, that we should be able to differentiate whats going on
[01:30] <lifeless> Diziet: right, we don't need to support all features on day one, but it would be nice to have in mind the sorts of things we'd like to do
[01:30] <Diziet> I'd be very interested to see your straw man for this.  Absolutely.
[01:30] <lifeless> ok.
[01:31] <lifeless> have you had a chance to eyeball subunit ?
[01:31] <Diziet> No.
[01:32] <Diziet> I don't know if you saw but one of the things some people on debian-* pointed out was that my original interface spec requires a fork/exec for each test which can be bad sometimes.  But a more sophisticated fork-and-run-to-do-many-tests needs a more sophisticated API and perhaps you'll pull one out of your back pocket for me :-).
[01:32] <lifeless> I plan to reread your spec another time in great detail, but at the moment I'm thinking of a shell (or suitable ?in-essential? language) implementation of subunit
[01:32] <lifeless> subunit happens to do much of this :)
[01:32] <lifeless> pmiller has written a C runner for the subunit protocol
[01:33] <Diziet> Cool.
[01:33] <lifeless> which aegis supports
[01:33] <lifeless> to save you digging it up ...
[01:33] <lifeless> the subunit protocol says that you run a program
[01:33] <Diziet> I should look up subunit.
[01:33] <lifeless> and the program reports tests like so:
[01:34] <Diziet> Oh, ah, yes, of course, aegis would need a protocol to speak to unit tests.
[01:34] <lifeless> TEST: test foo works
[01:34] <lifeless> SUCCESS: test foo works.
[01:34] <lifeless> TEST: tar a file.
[01:34] <lifeless> FAILURE: tar a file. [
[01:34] <lifeless> ..
[01:34] <lifeless>  ] ..  space is eaten.
[01:34] <lifeless> foo.c:34 WARNING foo is not defined.
[01:34] <lifeless> ]
[01:34] <lifeless> a writeln to stdout
[01:34] <lifeless> the idea is that the TEST: prefixed lines are eaten by the test runner and turned into whatever output its making
[01:35] <lifeless> the stuff in the [ ..\n..\n..\n ]  section is failure log for the failure, which the runner also eats and shows in whatever way it wants
[01:35] <lifeless> and the 'a writeln to stdout' is random output that was not part of the protocol and the runner just outputs to stdout
[01:36] <Diziet> Right.
[01:36] <Diziet> I should definitely take a look at it.  The less I have to invent the better.
[01:36] <lifeless> ok.
[01:36] <lifeless> google should find it just fine ;)
[01:36] <Diziet> :-)
[01:37] <sivang> lifeless: so everything after the TEST: are resting targets, and SUCCESS/FAILURE : are response snippets to cpmare against?
[01:37] <sivang> that is , resolved to response snippets, output
[01:37] <lifeless> sivang: everything after TEST: is the name of the test for the UI
[01:37] <lifeless> everything after SUCCESS and FAILURE is the matching test label
[01:37] <lifeless> so that a corrupt child process can be detected
[01:37] <Diziet> lifeless: Anything else you want to talk about ?
[01:38] <lifeless> Diziet: nup, I think we've covered the salient bits
[01:38] <Diziet> Excellent.  Right, well I'll rush off to my lunch appointment now then.
[01:38] <lifeless> I'm sure we'll find more to talk about as we explore, but I've offered all the suggestions at hand :)
[01:38] <lifeless> ciao
[01:39] <Diziet> :-).  Thanks a lot, that's very helpful.
[01:39] <Diziet> ttfn
[01:57] <doko> jordi, Keybuk, Diziet: can galeon and epiphany-browser handle plugins as well (i.e. the non-free java)?
[01:58] <ptlo> doko, epiphany-browser works nicely with non-free flash for me ....
[01:58] <seb128> doko: you didn't ask me but yeah they do
[01:58] <zakame> evening
[01:59] <jordi> doko: yes
[02:00] <jordi> doko: just put it in the ff/(moz plugins dir
[02:00] <jordi> it'll use whatever is installed for the main browser it's based on
[02:02] <doko> seb128: I'm so sorry that I didn't realize that it starts with g* *grin* ;-P
[02:03] <seb128> lol
[02:09] <Kamion> Seveas: you have about a 50% correctness hit rate at closing my bugs or saying they're fixed at the moment ;-)
[02:09] <Kamion> (thanks for the efforts, though)
[02:10] <ogra> GRRRR
[02:10] <ogra> gtk2-engines-gtk-qt is EVIL !
[02:12] <Seveas> Kamion, ah damn, please correct me where I'm wrong
[02:13] <Kamion> Seveas: have done
[02:13] <Seveas> merci
[02:13] <Seveas> Just trying to clean bugzilla cruft
[02:14] <Kamion> (in general it would be nice if enhancement bugs with a clear description and clear intent defaulted to being left open)
[02:15] <Seveas> gotcha
[02:16] <HiddenWolf> Kamion, Seveas, update the title to say [enhancement]  perhaps?
[02:17] <Seveas> HiddenWolf, no, the severity already says that :)
[02:17] <HiddenWolf> I never noticed that. :/
[02:17] <Kamion> HiddenWolf: subject line space is valuable and shouldn't be wasted on metadata
[02:18] <HiddenWolf> Kamion, it's wasted on ramblings mostly. :)
[02:35] <Seveas> Kamion, http://bugzilla.ubuntu.com/show_bug.cgi?id=2203 - should I close it due to inactivity (apart from the unrelated added bug report) or leave it open?
[02:36] <Kamion> Seveas: I'll ask if it's reproducible on breezy
[02:37] <Seveas> even better
[02:37] <Kamion> Seveas: it would certainly be highly unfair to close it due to inactivity since the reporter was never asked for any more information
[02:37] <Seveas> ack
[02:43] <dholbach> elmo: please sync glibmm2.4 from sid, ok to override
[02:46] <mjg59> elmo: vbetool has changed from arch:i386 to arch:any
[02:46] <mjg59> Does that need manual overriding?
[02:47] <Mithrandir> mjg59: PaS need updating, most likely.
[02:48] <elmo> Kinnison: no
[02:48] <elmo> mjg59: what tollef said
[02:48] <Kinnison> elmo: right
[02:48] <mjg59> elmo: I don't have access to PaS
[02:49] <elmo> mjg59: http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.595&root=dak&view=markup
[02:49] <elmo> mjg59: see comment at top
[02:50] <mjg59> Ah
[02:50] <mjg59> Wasn't it on chinstrap at some point?
[02:51] <elmo> no, never, it's always been a Debian thing
[02:51] <mjg59> Ok
[02:51] <ogra> i have an intresting error, if i try to build gtk-qt-engine in my pbuilder i get "config.status: error: cannot find input file: po/Makefile.in" which in fact is a lie ... if i login to my pbuilder and do all the steps manually its all working fine ...
[02:51] <ogra> has anybody a hint for me ?
[02:52] <Mithrandir> I guess pbuilder has good taste and refuses to build such a thing? :-)
[02:52] <ogra> heh
[02:52] <ogra> sadly it doesnt know my merge bugs :)
[02:53] <ogra> then it would probably more friendly ...
[02:53] <ogra> +be
[03:00] <\sh> Mithrandir: I hope you're not serious about gtk-qt-engine :)
[03:01] <\sh> ok..going home now...laters babes
[03:03] <infinity> mjg59 : Will vbetool actually build/work on anything other than i386/amd64?
[03:04] <mjg59> Should do, yeah
[03:04] <mjg59> x86emu is cross-platform
[03:04] <infinity> mjg59 : Right, I'll pull it from P-a-s, then.  Can you make sure Debian gets your crack?
[03:04] <mjg59> vbetool goes to debian and then gets synced
[03:04] <infinity> Perfect.
[03:05] <mjg59> (Of course, I may always have fucked up the upload)
[03:05] <infinity> elmo : P-a-s updated.
[03:07] <elmo> infinity: feel free to add yourself to the P-a-s contact list if you like, btw
[03:07] <elmo> updated in ubuntu, anyway
[03:07] <infinity> Will do now.
[03:15] <pitti> ogra: cdbs does not have bugs, just lots of features that aren't documented anywhere...
[03:16] <ogra> so i wonder if its a hidden feature ...
[03:16] <ogra> like --fail-with-silly-errors
[03:16] <pitti> Hi teuf
[03:17] <teuf> hi
[03:17] <teuf> pitti, I had a question about yesterday's discussion about malloc int overflows
[03:18] <teuf> can such bugs easily be exploited ?
[03:18] <pitti> teuf: yes, that's pretty much a standard pattern
[03:18] <pitti> teuf: there are lots of security holes in image processing software and the like
[03:18] <teuf> pitti, do you happen to have any link describing a concrete exploit of such an issue?
[03:19] <pitti> teuf: i. e. you trick somebody to open a malicious image, and if you craft the image properly, you can execute arbitrary code with the victim's privileges
[03:20] <pitti> teuf: e. g. https://www.ubuntulinux.org/usn/usn-214-1, a very recent one
[03:21] <pitti> teuf: well, that one isn't an int overflow, lemme search for another one
[03:23] <pitti> teuf: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3186, another recent one in GTK
[03:24] <pitti> teuf: see /msg for details
[03:25] <teuf> ok, what I need to learn about are heap-based buffer overflows ;)
[03:26] <pitti> teuf: the stack based ones are easier to exploit
[03:26] <Seveas> ogra, --fail-with-silly-errors is the default :)
[03:26] <ogra> yes, sadly ...
[03:26] <jbailey> teuf: AFAIK a heap based exploit is just as likely to give you as segfault as an actual exploit.
[03:26] <ogra> and i really have no idea how to compile this crap ...
[03:26] <teuf> pitti, yeah, I pretty much understand how a stack based overflow can be exploited
[03:26] <pitti> teuf: but due to the nature of virtual memory handling, heap management is/can be predictable, too, and exploited
[03:26] <teuf> these are the heap based ones that I have more troubles understanding how they can be exploited ;)
[03:27] <Seveas> ogra, is the source from dapper?
[03:27] <teuf> I'll google around for that later
[03:27] <pitti> teuf: memory management is not completely arbitrary; well the physical allocation is, but not the virtual one
[03:27] <pitti> teuf: yes, there are several papers about exploiting heap overflows
[03:27] <teuf> pitti, aren't there some patches to randomize a process address space or something like that?
[03:27] <teuf> I guess this helps avoiding these issues ?
[03:28] <pitti> teuf: yes, that's what e.g. grsecurity does
[03:28] <ogra> Seveas, nope, the debian and dapper sources produce a hard crash of gnome, i'm trying the upstream source package from freedesktop
[03:28] <mdke> planet.u.c rss feeds are broken again
[03:28] <pitti> teuf: randomization helps to turn arbitrary code execution into a simple crash
[03:28] <dholbach> ogra: what are you talking about=?
[03:28] <ogra> dholbach, our most evilpackage
[03:28] <dholbach> gcompris?
[03:28] <ogra> dholbach, gtk-qt-engine
[03:28] <pitti> teuf: but additionally you should have nonexecutable writable memory pages (exec-shield, PaX, etc.)
[03:28] <dholbach> ah i see :)
[03:29] <ogra> gcompris is only big, its not evil at all :)
[03:29] <jsgotangco> most evil haha
[03:29] <ogra> switching to QT in gnome makes *every* gtk app crash
[03:29] <pitti> teuf: with those, you are reasonably sure against all standard exploits; it's not 100% secure, though, but already helps a great deal
[03:29] <mdke> does quim gil come on here in irc?
[03:30] <Seveas> hmm, planet should send a charset...
[03:30] <ogra> mdke, i'm not sure, but if, then you might find him in #edubuntu
[03:30] <mdke> ogra, know his nick?
[03:30] <ogra> no idea
[03:30] <mdke> k
[03:30] <Seveas> I had the same problem on planet.ubuntulinux.nl which sent ISO-8859-1, while the content was ITF-8
[03:30] <Seveas> s/I/U
[03:30] <ogra> but he's active edubuntu member
[03:30] <teuf> pitti, thanks for all the details :)
[03:30] <Seveas> and p.u.c sends no charset at all (not in http header, not in xml)
[03:31] <pitti> teuf: you're welcome, if you are interested in that stuff and it helps you to write more secure software, then my job gets easier :)
[03:31] <mdke> Seveas, that is why the & breaks the rss i guess
[03:31] <teuf> pitti, I guess I'll be a bit more careful when doing mallocs now ;)
[03:32] <Seveas> mdke, hmm, if he uses a bare & his feed is wrong :)
[03:32] <mdke> elmo, dunno if you can fix the planet.u.c rss, it seems to break with the symbol "&" in post titles
[03:32] <Seveas> mdke, ah THAT is simply a planet misconfiguration
[03:32] <mdke> ah
[03:32] <mdke> i get the feeling that elmo can't access the planet configuration at the moment
[03:33] <Seveas> ping jdub to fix his rss20.xml.tmpl and let it properly escape the title :)
[03:33] <elmo> mdke: I don't maintain planet; jdub does
[03:34] <elmo> his/our baz tree is broken, so I can't update it get your feed or any other fixes.  jdub's working on moving planet to another box in the meantime
[03:34] <mdke> elmo, right, but i seem to remember you says that you had to sync it from his archive in order to get his changes
[03:34] <mdke> i'll mail him about this "&" problem
[03:41] <teuf> pitti, at least, you got me worried about rhythmbox daap code :-/
[03:42] <ogra> yippie :)
[03:42] <ogra> it works if i patch with latest CVS ....
[03:42] <ogra> bah, its sooo ugly ...
[03:44] <ogra> but doesnt crash :)
[03:48] <ogra> grrr ... this sucks ...
[03:49] <zakame> ogra: awww
[03:49] <ogra> why the heck is this crap in main ... even upstreams website states that it doesnt work
[03:58] <ogra> lamont !
[04:00] <lamont> OGRA!
[04:00] <lamont> :-)]
[04:01] <ogra> lamont, any news about my livefs ? :)
[04:01] <lamont> hrm... thought I'd done that.
[04:01] <lamont> ogra: I'll check on it momentarily
[04:01] <ogra> thanks :)
[04:07] <pitti> Hi zyga
[04:10] <trappist> mouse-drv.so and kbd-drv.so seem to be missing from the new xserver-xorg
[04:10] <zyga> pitti: hello
[04:13] <sivang> re zyga
[04:13] <Nafallo> trappist: that's probably a question for #ubuntu, but you might want to have a look at xserver-xorg-input-*
[04:13] <zyga> clueless work office drones suck...
[04:14] <zyga> arghhh
[04:14] <Diziet> http://lists.gnu.org/archive/html/bug-ghostscript/2005-11/msg00001.html> Hmm, GNU have decided to take a more aggressive approach to gs.  That'll be interesting to watch and see how it turns out.
[04:32] <carlos> seb128, ping
[04:33] <carlos> seb128, I know what's the problem with totem
[04:34] <davyd> infinity: did you end up uploading a new nvidia-glx?
[04:35] <janimo> elmo, when/if syncing the xfce related packages I asked earlier today, you can omit xfce4-icon-theme and xfce4-mixer (has epoch), thanks
[04:36] <trappist> Nafallo: I also reinstalled xserver-xorg-input-* and the files are missing from those as well
[04:39] <seb128> carlos: pong
[04:39] <seb128> carlos: ah, cool :)
[04:39] <carlos> seb128, the .pot is missing from the extracted tarballs
[04:40] <carlos> seb128, if you send me the latest .pot for the breezy's sourcepackage I will fix it manually
[04:41] <seb128> doko: I've reassigned poppler sync bug to you, your changes are directly to the diff.gz and quite a mess ...
[04:41] <seb128> carlos: http://people.ubuntu.com/~seb128/totem.pot
[04:43] <seb128> carlos: thanks
[04:44] <carlos> seb128, please, review dapper's sourcepackage to know what's wrong with totem 1.2
[04:44] <carlos> seb128, no worries
[04:44] <carlos> seb128, sorry for the delay
[04:44] <seb128> carlos: it doesn't generate a pot, that's all
[04:44] <mantiena> hi all
[04:44] <seb128> carlos: I'm not sure it did before, there is no mention of such change to the package changelog
[04:44] <seb128> carlos: you probably set this pot by hand first time
[04:45] <seb128> Hi mantiena
[04:45] <mantiena> I wanna talk about gksudo patch in .desktop files
[04:45] <mantiena> I think it's bad decision
[04:45] <carlos> seb128, I suppose the POTFILES.in has a reference to an unexisting file or something like that
[04:46] <zyga> carlos: hey
[04:46] <carlos> zyga, hi
[04:46] <zyga> carlos: I'll try to finish the importer today
[04:46] <seb128> carlos: no, the package doesn't use CDBS so it doesn't get the magic that's all
[04:46] <zyga> I'm so frelled up with my daily job I need ubuntu to fix my mind
[04:46] <carlos> seb128, oh, so that means that 1.2 removed the .pot file...
[04:46] <seb128> carlos: probably yep
[04:46] <carlos> zyga, ;-)
[04:46] <seb128> carlos: I'll add a call to intltool-update -p from the debian/rules
[04:47] <carlos> zyga, don't worry, next week I will be on holidays and I doubt I will be able to use your script this week so you have one extra week :-)
[04:47] <mantiena> now most software, which needs root privileges doesn't work from GNOME/KDE/XFCE menus if user enters root password during installation
[04:47] <carlos> seb128, ok
[04:48] <zyga> carlos: oh, good to know
[04:49] <Nafallo> trappist: really? I have them see...
[04:49] <Nafallo> nafallo@darkelf:~ $ dpkg -L xserver-xorg-input-mouse | grep so
[04:49] <Nafallo> /usr/lib/xorg/modules/input/mouse_drv.so
[04:50] <seb128> mantiena: entering a passwd doesnt prevent to use sudo
[04:50] <mantiena> mvo, it seems bug http://bugzilla.ubuntu.com/show_bug.cgi?id=8775 is assigned to you and I need to talk with you about removing gksudo patch ?
[04:50] <mantiena> seb128, look at bug http://bugzilla.ubuntu.com/show_bug.cgi?id=8775
[04:51] <doko> seb128: please check your email, I did send you the patches, did ask you before applying them, and you agreed to forward them upstream.
[04:51] <Kamion> mantiena: that's probably more an installer bug; we could change the installer to still give the first user sudo privileges by default even if you enter a root password during installation
[04:51] <seb128> doko: ups, forgot about that. But please use debian/patches for patches
[04:51] <mantiena> seb128, I'm talking about situation, when there are no user, which is added to admin group
[04:52] <Kamion> I did it that way because I reckoned people who wanted to set a root password might be the sort of people who'd want to disable sudo privileges for the first user
[04:52] <seb128> mantiena: add it
[04:53] <mantiena> Kamion, what add ?
[04:53] <mantiena> seb128, what add ?
[04:53] <seb128> mantiena: give sudo rights to your user and that's fixed
[04:54] <mantiena> Kamion, you did right decision
[04:54] <mantiena> seb128, please look at bug http://bugzilla.ubuntu.com/show_bug.cgi?id=8775
[04:54] <carlos> seb128, "64 files were queued for import from the tar file you uploaded."
[04:54] <carlos> seb128, latest tarball for totem uploaded. It should appear in next 24 hours
[04:54] <mantiena> seb128, bug is not in my system, there are lots of administrators, who don't want to use sudo
[04:54] <seb128> carlos: thanks
[04:54] <carlos> seb128, you are welcome
[04:55] <seb128> mantiena: this bug is clear enough
[04:55] <mantiena> seb128, there is better decision than replacing gksu with gksudo in .desktop files
[04:55] <seb128> mantiena: what else do you want to change?
[04:56] <Kamion> Seveas: in what universe is James Troup in charge of creating the ISOs? :-P
[04:56] <mantiena> A good solution to this is set "sudo-mode = yes" in /etc/gksu.conf and use gksu
[04:56] <mantiena> in the launchers. This will have the same effect of gksudo and will make the
[04:56] <mantiena>  life of some users "not so hard" giving the chance to disable sudo commenting 1 line in 1 file - /etc/gksu.conf
[04:56] <Seveas> Kamion, apparently in a parallel universe in my brain
[04:56] <seb128> mantiena: I know this bug, but you have some other idea or you just want to point it ?
[04:56] <maswan> Seveas: a parallel universe populated all by elmo clones?
[04:57] <Seveas> maswan, that would be scary
[04:57] <tseng> s/scary/dangerous
[04:57] <mantiena> seb128, I just wanna ask why this bug isn't solved until now
[04:57] <mantiena>  Additional Comment #1 From Matt Zimmerman  2005-04-07 23:37 UTC  [reply]  -------
[04:57] <mantiena> Sounds reasonable to me; we should probably do this for Breezy
[04:57] <mantiena> ------- Additional Comment #2 From Sebastien Bacher 2005-04-11 17:31 UTC [reply]  -------
[04:57] <mantiena> right, I'll change that for breezy
[04:58] <seb128> mantiena: because we have thousand and bugs and it's easy to forget one change
[04:58] <tseng> mantiena: seb has 100s of bugs fwiw
[04:58] <mantiena> will this be changed in dapper ?
[04:58] <Seveas> tseng, oh my, shouldn't he be in the hospital right now?
[04:58] <seb128> mantiena: if somebody take the time to do the change yep
[04:58] <Kamion> Seveas: see #2540 for my reply
[04:58] <seb128> mantiena: but better to ping on bugzilla than IRC
[04:59] <Seveas> Kamion, do I dare to watch?
[04:59] <mantiena> seb128, ok, I just wanna know if problem is in free time or not
[04:59] <Kamion> generally stuff assigned to me *is* actually my responsibility ;-)
[05:00] <seb128> as said before, thousand of bugs, easy to drop a wishlist
[05:00] <seb128> mantiena: I'll set the milestone to 6.04 for this one so we don't forget about it
[05:01] <wasabi> (WW) Couldn't load XKB keymap, falling back to pre-XKB keymap
[05:02] <mantiena> seb128, thans
[05:02] <seb128> mantiena: you're welcome
[05:03] <Seveas> Kamion, ok, I'm still learning and trying to make myself useful
[05:03] <Seveas> There was a suggestion a few weeks ago to create a list of Ubuntu developers and their responsibilities, is there any progress with that?
[05:03] <Seveas> (It would sure help me in my bugzilla raids)
[05:09] <ogra> grumble
[05:11] <mantiena> btw, I don't find any help or FAQ, or readme about laptop support in default Ubuntu Breezy installation :( agains which package should I report the bug?
[05:13] <wasabi> there is somethign totally messed up with the mouse prefs right now haha
[05:13] <wasabi> if I change it, my mouse gets Really Slow
[05:13] <wasabi> and the faster I move it, the slower it gets.
[05:13] <wasabi> Like acceleration is backwards.
[05:27] <carlos> seb128, the import is done, just in case you want to check it
[05:27] <seb128> carlos: will do, thanks again
[05:36] <mdke> seb128, are you absolutely sure that #20257 is a dup of #20134? the former bug does not happen when opening yelp, which works fine. it is only when opening xml files in yelp.
[05:36] <Seveas> bugs on libqt3 are for jriddell, right?
[05:37] <seb128> mdke: I'm sure of nothing without a backtrace
[05:37] <mdke> seb128, well can I reopen the bug and provide one then?
[05:38] <seb128> provide one, I'll reopen if required
[05:38] <seb128> but yelp doesn't work on dapper
[05:38] <seb128> that's due to firefox1.5
[05:38] <mdke> seb128, it works because firefox1.5 doesn't get installed on dapper, it get's held back
[05:38] <mdke> i can view html in it, but not xml
[05:38] <seb128> lack of this information to the bug
[05:39] <seb128> we should get a page "how to fill a bug" :)
[05:39] <mdke> they exist
[05:39] <seb128> ie: when you say "yelp crashes on latest dapper"
[05:39] <mdke> i thought i was being pretty clear when I said "yelp crashes on opening xml files"
[05:39] <seb128> that's not coherent with "firefox1.5 doesn't get installed"
[05:39] <mdke> ok i'll try again
[05:40] <seb128> I've read "yelp crash on dapper"
[05:40] <seb128> and dupped with the other
[05:40] <seb128> because yelp just crashes on startup on dapper
[05:40] <seb128> which is due to firefox1.5
[05:40] <mdke> seb128, no problem, i'm not gonna argue, i'll just reopen it
[05:41] <seb128> that's probably a gnome-doc-utils bug anyway
[05:41] <seb128> that's the piece which changed yesterday
[05:41] <mdke> possibly
[05:41] <mdke> the file it complains of is in yelp tho
[05:42] <seb128> I don't have a /usr/share/yelp/xslt/db2html.xst
[05:42] <mdke> .xsl ?
[05:43] <seb128> ups, typo
[05:43] <seb128> it didn't change for weeks this one
[05:43] <mdke> hmm
[05:43] <mdke> i'll do the backtrace
[05:44] <mantiena> I don't find any help or FAQ, or readme about laptop support in default Ubuntu Breezy installation :( agains which package should I report the bug?
[05:46] <dholbach> mantiena: we heard you on the first time, if nobody answers, that's a good sign to take it to the mailing list
[05:47] <seb128> mantiena: the question is not clear, what do you call "laptop support"
[05:50] <Kamion> elmo: could you sync rootskel 1.27 from incoming, please? our current version is broken
[05:51] <elmo> Kamion: done
[05:52] <Kamion> elmo: ta
[05:53] <ogra> pitti, its not even suitable for universe imho
[05:53] <dholbach> pitti: you're so mean... poor motus
[05:54] <pitti> dholbach: the MOTUs don't HAVE to care about all packages in universe..
[05:54] <elmo> should 2.6.15 be in main?
[05:54] <elmo> BenC/Kamion: ^-- ?
[05:54] <BenC> elmo: blah
[05:54] <Kamion> elmo: yes
[05:54] <pitti> ogra: no packages except kubuntu-desktop depend on it
[05:54] <Kamion> it won't be long before stuff is fixed to depend on it
[05:54] <BenC> elmo: yes, it should
[05:55] <elmo> BenC: .. why blah?
[05:55] <BenC> as soon as lrm is ready, linux-meta will be updated for 2.6.15
[05:55] <elmo> oh, never mind, cron.sync just ran before the latest ABI got  into main is all, that's why anastacia wants to demote it all
[05:55] <BenC> elmo: blah == ping this time of the day :)
[05:56] <ogra> pitti, but there must be a reason why Riddell  wants it (even if it had the same bug that crashes all of gnome since hoary apparently)
[05:56] <elmo> BenC: ah, heh
[05:56] <pitti> ogra: if it's helplessly broken, why bother?
[05:57] <ogra> because it works on the kde side if you dont use gnome apparently
[05:57] <ogra> (for single apps)
[05:58] <ogra> but using it in gnome makes your panel and the session manager crach hard ...
[05:58] <Seveas> then let it Conflicts: gnome-panel :)
[05:58] <mdke> seb128, my attempt at getting a trace has failed because the version I yelp I built crashes on startup ;) anything else I can do for that bug?
[06:00] <ogra> Seveas, that would mean installing kubuntu-desktop removes gnome-panel :p
[06:00] <Seveas> hmm
[06:02] <elmo> oh, ok, now anastcia only wants to demote all the 2.6.15 d-i stuff
[06:02] <elmo> kamion/benc: shall I just ignore it?
[06:02] <Kamion> elmo: please - I'll fix it up when we actually switch, fixing it now would be complicated and confusing for CD builds
[06:02] <elmo> ok, no prob, just checking
[06:03] <elmo> btw, I assume genromfs will just fix itself once sparc builds d-i?
[06:03] <BenC> I'll upload -6 abi with new linux-meta to make it easier
[06:03] <Kamion> elmo: yeah, should do, need to check what's up there
[06:04] <Kamion> boggle, I just sent SIGTERM to a vim process madly spinning in select(), and not only did the process not die, but it actually fixed itself and is still usable as an editor
[06:04] <mdke> seb128, ah, it is because build-dep installed firefox 1.5 lol. I'll have to wait until the other bug is fixed, and then provide a trace if my bug still exists
[06:08] <seb128> mdke: k, now you have the common situation :)
[06:09] <mdke> yeah, bummer
[06:09] <mdke> stupid build-dep
[06:10] <mdke> seb128, i suppose the common situation will take some time to fix?
[06:10] <mdke> or is it pending pretty soon?
[06:14] <seb128> mdke: yelp doesn't build with current firefox
[06:15] <seb128> epiphany upstream has some hack fixing it, but they don't know what exactly does this
[06:15] <seb128> so either we wait to get firefox fixed or patch yelp
[06:15] <seb128> anyway should be fixed this week
[06:16] <Kamion> jbailey: the grub merge is interestingly non-trivial actually - we never sent Nathaniel's nonaltoptions change to Debian, so now they've implemented the same option with a different name
[06:16] <Kamion> yay migration
[06:16] <mdke> Seveas, great
[06:16] <mdke> gah
[06:16] <jbailey> Kamion: Joy.
[06:16] <mdke> seb128, great
[06:16] <jbailey> Kamion: I inherited grub quite late.  I don't think I ever actually made an upload with it.
[06:17] <jbailey> Kamion: Tollef did send me a patch for supporting multiple initramfs', so if it's alot of work he might have looked at the internals more recently than anyone else.
[06:19] <zyga> does anyone remember bootchart package and gnome startup profiling?
[06:22] <pitti> jbailey: yay, 'copy' resolution works now :)
[06:22] <mdz> morning
[06:22] <pitti> Hi mdz
[06:22] <jbailey> pitti: Sweet!
[06:24] <ogra> hey mdz
[06:31] <ogra> Riddell, is there a real urgent need for gtk-qt-engine in kubuntu ? it causes heavy instabilities in gnome and seems pretty unusable from the gnome side ... i.e. #18210 but there are also many similar bugs in other distros, its not ubuntu specific
[06:31] <Riddell> ogra: there's not an urgent need no
[06:32] <ogra> could we demote it to universe ?
[06:32] <dholbach> to morgue please ;)
[06:32] <Riddell> I'll look at the problems and may well remove it for dapper if it's too much of an issue
[06:32] <Riddell> but it is really nice when it works
[06:32] <ogra> i dont think its even in alpha state ...
[06:32] <ogra> and for sure not something we want support for 5 years
[06:33] <ogra> (or even 3 for the desktop)
[06:44] <ogra> seb128, uuuh, what made debian decide to accept such a patch ... ?
[06:44] <ogra> (gdm)
[06:47] <dholbach> ogra: which one?
[06:47] <ogra> dholbach, see -devel
[06:47] <dholbach> nobody knows :)
[06:47] <ogra> i
[06:47] <dholbach> j
[06:48] <seb128> ogra: dunno if it has been "accepted", I guess it has been made by the maintainer
[06:48] <ogra> *shudder*
[06:48] <ogra> is it still ryan ?
[06:49] <seb128> yep :/
[06:50] <ogra> iirc he was asked in pre-ubuntu times already to give it to the gnome team ...
[06:50] <ogra> odd ...
[06:50] <seb128> he said he would not give it and not accept any NMU
[06:50] <ogra> pfft
[06:50] <seb128> upload with an epoch if required, etc
[06:51] <ogra> how about leaving the debian package alone completely and have our own gdm  ?
[06:51] <dholbach> haha... good idea :)
[06:51] <ogra> so you wont suffer from him
[06:52] <seb128> that's quite the case
[06:52] <seb128> I've switched it to cdbs
[06:52] <seb128> and I update it :p
[06:52] <ogra> heh, good ...
[06:52] <dholbach> cdbs to the rescue! :)
[06:52] <dholbach> seb128: two times a year should be enough
[06:53] <ogra> i mean, if we can go away from debian with wine, we can also do it with gdm :)
[06:54] <ogra> and if BenC finally follows mike hearns suggestion, we can all just "modprobe gnome" in the future :)
[06:54] <siretart> ogra: lol
[06:55] <siretart> ogra: this guy is so annoying.. unbelievable..
[06:55] <ogra> lol
[06:55] <BenC> ogra: atomic_dec(modprobe_gnome_idea)
[06:56] <ogra> *g*
[06:56] <ogra> siretart, see http://planet.autopackage.org/ if you want to know more about him :)
[06:57] <siretart> ogra: oh, he is one of the autopackage drivers?
[06:57] <ogra> he's THE autopackage drivers
[06:57] <ogra> -s
[06:57] <siretart> I see
[06:57] <siretart> bookmarked and on my way home
[06:57] <siretart> cu later guys!
[06:57] <dholbach> bye siretart
[06:58] <ogra> why do you think he wants gto get rid of distributors :=)
[06:58] <sivang> ogra: they have a planelt?
[06:58] <sivang> err, planet
[06:58] <ogra> sivang, check the url
[06:58] <sivang> ogra: checked, it's your freind there :)
[06:58] <ogra> :P
[06:58] <sivang> ah sorry
[06:59] <sivang> s/ogra/\sh/ freind :)
[06:59] <sivang> ogra: \sh_away keeps mentioning him :)
[06:59] <ogra> yes... see -devel over the last days :)
[07:00] <sivang> I don't have time for such LONG threads :)
[07:00] <ogra> from my experience you can be sure it becomes a loooong thread if a mail from him hits -devel
[07:00] <sivang> I accidently ^D's it
[07:00] <sivang> hehe
[07:00] <sivang> see my 2 last responses ^^
[07:01] <mdz> pitti: this postgresql 8.0 debconf note on every upgrade is very annoying; what is its purpose?
[07:02] <pitti> mdz: well, to be annoying :)
[07:03] <mdz> it's displayed twice on every upgrade; this seems excessive
[07:03] <pitti> mdz: I want to avoid that people run unsuported software
[07:03] <pitti> mdz: hm, it seems that it is displayed twice for everybody except me :(
[07:03] <mdz> pitti: do you propose that all universe packages should have such a note on every upgrade? ;-)
[07:03] <pitti> mdz: how do you upgrade?
[07:03] <mdz> apt-get
[07:04] <pitti> mdz: hm, I usually install with sudo dpkg -i, maybe that's the difference why I only see it once
[07:04] <fabbione> mdz: it's probably just a reminder to apt-get --purge remove pgsql && apt-get install mysql ;)
[07:04] <mdz> pitti: yes, the first one is during debconf preconfiguration
[07:04] <pitti> mdz: ah, ok, will fix that
[07:04] <mdz> fabbione: launchpad requires a real database
[07:04] <pitti> mdz: with some fiddling it should be possible to display it just once
[07:05] <fabbione> mdz: ehhe i know
[07:05] <mdz> pitti: once on every upgrade is still too much; it should at most be displayed once ever
[07:05] <pitti> mdz: I just need to display the same note for all unsupported versions (db_subst magic)
[07:05] <pitti> mdz: right, that's what I meant with my second 'once'
[07:05] <mdz> ok
[07:05] <elmo> mdz: ?? that's a bit of a turn-around from Mister Mysql
[07:06] <mdz> elmo: http://www.oracle.com/corporate/press/2005_oct/inno.html
[07:07] <elmo> ah, right
[07:07] <sivang> pitti: I apt-get dist-upgraded and it popped it up for me only once as well, so you're not alone.
 I'm hurt bad!
[07:09] <sivang> or port stuff from XE into it ,etc
[07:10] <seb128> mdke: k, I've figured what's wrong
[07:10] <mdke> seb128, rock
[07:10] <seb128> mdke: g-d-u has a CVS file which is not shipped with the tarball
[07:10] <seb128> yelp 2.13.1 doesn't crash but complain about /usr/share/xml/gnome/xslt/docbook/html/db2html-bibliography.xsl
[07:11] <seb128> elmo: gtk+2.0 2.8.8 sync from Debian incoming please
[07:12] <ogra> elmo, there must be a binary called kanagram stuck in NEW somewhere, its the renamed kmessedwords, could you process it ?
[07:13] <dholbach> elmo: and if you didn't do it yet, please sync glibmm2.4 from sid (override ok)
[07:13] <elmo> seb128: done
[07:13] <seb128> elmo: thanks
[07:15] <elmo> dholbach: done
[07:15] <dholbach> merci beaucoup
[07:15] <elmo> ogra: there's nothing in NEW
[07:15] <elmo> ogra: assuming you mean ubuntu
[07:15] <ogra> hmm, strange
[07:15] <ogra> yes
[07:15] <ogra> its build by kdeedu ... but doesnt appear in the archive
[07:16] <elmo>   kanagram | 4:3.5-rc2-0ubuntu1 | dapper/universe | amd64, i386, ia64, powerpc
[07:16] <elmo> ...
[07:16] <ogra> oh
[07:18] <ogra> elmo, thanks for the effort ... i'm to silly... i always look in main...
[07:20] <ogra> mdz, do you do anastacia currently ? if so, yould you promote kanagram (former kmessedwords) for edubuntu-desktop ?
[07:20] <ogra> s/yould/could/
[07:20] <janimo> elmo please sync override ok : dbh, libxfce4util, libxfcegui4, libxfce4mcs, xfce-mcs-plugins, xfce4-utils, xfce4-panel, xfce4-session, xfce4-appfinder, xfprint4,  xfcalendar,xfwm4, xfwm4-themes, xfce4-iconbox, xfce4-systray, xfce4-trigger-launcher, gtk2-engines-xfce, thank you
[07:21] <mdz> ogra: anastacia output is published every 15 minutes or so to http://people.ubuntu.com/~mdz/anastacia.txt
[07:21] <ogra> mdz, i know ...
[07:21] <ogra> mdz, i want the package in main again :)
[07:21] <ogra> they renamed it
[07:21] <mdz> ogra: ok, anastacia doesn't do that, but I can
[07:21] <ogra> thast what i mean :)
[07:22] <ogra> damn, my typing sucks today
[07:22] <mdz> Riddell: amarok is still uninstallable in main
[07:24] <tepsipakki> as is most of KDE
[07:25] <Riddell> mdz: looking at it now
[07:28] <Diziet> ROTFL.  firefox has just prompted me what I would like to do with a file, and is offering to open it with ... /usr/bin/firefox.
[07:30] <ogra> ivoks, whats the reason for not syncing kile the elmo way ?
[07:30] <pitti> Diziet: go MIME...
[07:31] <Diziet> Go firefox's completely batshit mime type handling.
[07:31] <Treenaks> Guano!
[07:33] <mjg59> siretart: Latest acpi-support on dapper should work out of the box for you
[07:33] <Diziet> Hrm, I think I should try stripping file extensions off too to see if I can separate out madness due to guessing the file type by looking at it from madness based on the filename.
[07:34] <elmo> janimo: done
[07:34] <janimo> elmo, thanks
[07:35] <ivoks> ogra: my mistake
[07:35] <pitti> elmo: please sync db4.1
[07:36] <elmo> pitti: ...
[07:36] <elmo> sync it from what?
[07:36] <ogra> ivoks, if you really made changes to the package you synced, -Xubuntu1 would have been the right versioning... if not, a sync from elmo would have been better than syncing manually ...
[07:36] <elmo> troup@spohr:~$ madison -s unstable db4.1
[07:36] <elmo> troup@spohr:~$
[07:36] <ogra> ivoks, dont forget we have to live for 3/5 years with the mistakes we make now :)
[07:37] <pitti> elmo: oh, I still have a merge bug open
[07:37] <pitti> elmo: we recently eliminated its usage in main
[07:37] <pitti> hm
[07:37] <elmo> yeah, and I just removed it
[07:37] <ivoks> ogra: i know :/
[07:37] <ivoks> ogra: there are no changes, only new build
[07:37] <elmo> pitti: so just close the bug ;)
[07:37] <ogra> oki
[07:37] <elmo> are we supporting hoary -> dapper?
[07:37] <pitti> elmo: cool, I thought some universe packages still used it, but so much the better :)
[07:38] <elmo> doko: if not, can openoffice.org-debian-files go?  the track-debian-removals script wants to kill it
[07:38] <elmo> pitti: they might; my script doesn't care
[07:38] <elmo> if it's been removed in Debian, we shouldn't have it in universe - if it breaks stuff, they get fixed
[07:38] <pitti> ah, ok:)
[07:41] <tepsipakki> pitti: there's a file conflict with libcupsys2 & libcupsys2-gnutls10 (/etc/cups/client.conf)
[07:42] <ivoks> ogra: i'm sorry :(
[07:42] <pitti> tepsipakki: hmm, I never encountered that; will look at it, can you please file a bug?
[07:42] <tepsipakki> sure
[07:42] <ogra> ivoks, its not the end of the world ...
[07:43] <ivoks> :)
[07:43] <pitti> elmo: can you please sync libpng?
[07:43] <ogra> and -build1 will be overridden anyway ...
[07:44] <ivoks> sure it will, thats why it is -Xbuild1
[07:44] <elmo> pitti: done
[07:44] <pitti> thanks
[07:44] <elmo> ivoks: ogra is right tho; if you can sync, always sync
[07:44] <elmo> rather than doing an upload
[07:45] <ivoks> elmo: i understand
[07:46] <Riddell> mdz: amarok will need libarts1-akode moving to main
[07:46] <pitti> doko: ping
[07:47] <seb128> elmo: please sync gnome-doc-utils from Debian incoming
[07:48] <Diziet> `We only sniff on something without a type or application/octet-stream.' `... the way
[07:48] <Diziet> the code triggers the downloading dialog is by pretending that a content type
[07:48] <Diziet> header wasn't sent
[07:48] <Diziet> '
[07:48] <Diziet> Urgh, sorry.
[07:50] <mdz> Riddell: if that's part of the problem, there are more.  see http://people.ubuntu.com/~mdz/anastacia.txt
[07:55] <janimo> Riddell, Ogra: kubuntu/edubuntu meta packages do not need minimal and standard seed handling. Is it there so the diff to ubuntu-meta stays minimal?
[07:57] <Riddell> janimo: how do you mean?  minimal and standard don't have any desktop stuff in them
[07:57] <janimo> I mean those seeds are handled in ubuntu-meta, but are still reffered to by kubuntu-meta/update
[07:57] <janimo> and the minimal-ARCH files are generated
[07:58] <slomo_> will we get mysql5 for dapper? or shall i adjust b-d to mysql4.1?
[08:05] <seth_k> is new xorg stuff safe to upgrade to, or will I break things?
[08:07] <tepsipakki> seth_k: works for me (ibm T22 w. savage)
[08:07] <seth_k> tepsipakki, using any binary drivers? (fglrx / nvidia-glx)
[08:07] <tepsipakki> no
[08:08] <Diziet> mdz: -v option> aimed at me too, no doubt.  Sorry.
[08:08] <mdz> Diziet: at no one in particular; I've just been seeing it a lot lately
[08:09] <Diziet> Right.  I meant me as one of a group of reprobates :-).
[08:10] <mjg59> Nobody's commented on the new usplash artwork yet
[08:10] <seth_k> oh right, sorry tepsipakki... didn't even notice you put "w. savage" in your reply :P thanks
[08:11] <Diziet> I think I should give up on understanding mozilla's mime type handling and start thinking about what can be done to make the situation less totally wrong.
[08:12] <ogra> mjg59, are you prepared to switch to gnome-screensaver with the acpi scripts ? i'll finish my merges this week (which includes xscreensaver) and will make the change directly after filght2
[08:13] <mdz> mjg59: that's because our framebuffers are broken with 2.6.15
[08:13] <Diziet> Hrm.  Or maybe I should file a bug report upstream, of the form `look! it's totally insane!' (only with more tact).
[08:14] <mdz> Diziet: did that XDG patch not work out?
[08:14] <mjg59> mdz: No, it was actually a usplash bug...
[08:14] <Diziet> I haven't looked at the patch yet.
[08:14] <mjg59> ogra: Sure, once stuff is in place in the session
[08:14] <mdz> mjg59: oh, fun
[08:14] <Diziet> But it almost certainly can't fix the problem properly without being very large.
[08:14] <mjg59> mdz: Should be working since the weekend
[08:14] <mdz> mjg59: reverting to 2.6.12 made it work again
[08:15] <mjg59> mdz: Yeah
[08:15] <Diziet> I think I'll track down that xdg-mime patch tomorrow and read it.
[08:15] <mdz> mjg59: which I had to do anyway because hibernate wasn't working for me with .15
[08:15] <Diziet> But the real problem is that the algorithms are (a) fundamentally incorrect and (b) confused and (c) in the wrong places.
[08:15] <mjg59> mdz: It was down to usplash no longer loading fbcon, which is now fixed
[08:15] <ogra> mjg59, i just wanted to warn because i thought about the dbus stuff ...
[08:15] <mjg59> /Why/ it failed in that way, I have no idea
[08:15] <Surak> Hello. Is there any motu responsible for flashplugin-nonfree pacakge?
[08:15] <mjg59> ogra: I seem to remember someone suggesting a better way of getting the DBUS thing, but I'm not sure
[08:15] <mjg59> mdz: Oh. Hibernate was broken? How?
[08:16] <Surak> I don't know where to look at it.
[08:16] <Diziet> Time for me to have some dinner.  TTFN all.
[08:16] <Kamion> janimo: minimal and standard are there because otherwise germinate will put everything from minimal and standard into desktop
[08:16] <ogra> mjg59, oki ... worst case we can go with the evil /proc/env hack :)
[08:16] <Kamion> janimo: (as the lowest thing it knows about) - at least I suspect it will, and it's much less brain-bending to do it this way
[08:18] <janimo> Kamion, I was told by mdz to not have those in xubuntu-meta before breezy but it seems either I misunderstood what he meant, or since xubuntu isn't using germinate it really was not needed
[08:18] <janimo> btw, germinate needs to Depend: python-apt :)
[08:18] <ogra> mdz, do we plan to support mixed etherboot/PXE networks (no idea if that works without MAC address mapped images), i got a user asking in #edubuntu
[08:19] <ogra> mdz, ltsp that is
[08:19] <Kamion> janimo: you shouldn't actually generate the packages, but you do need to process those seeds
[08:19] <janimo> aha,so the minimal-ARCH files were not needed?
[08:19] <Kamion> janimo: i.e. your control file should not include minimal or standard, and debian/rules should have 'for seed in desktop live; ...' or similar
[08:19] <Kamion> janimo: they're by-products of the computation
[08:20] <janimo> ok
[08:20] <Kamion> janimo: python-apt> good point; I'll fix that now, thanks
[08:21] <Surak> I'm asking because the flashplugin-nonfree no longer works on breezy anymore. No mirrors provide links for it for now. The flash binary must be downloaded directly from macromedia from now on.
[08:23] <mdz> mjg59: it would go through the motions, power down the LCD, then come straight back to a locked xscreensaver
[08:23] <mdz> mjg59: I didn't see anything useful in dmesg.  I'm installing -5 and new usplash now, and will re-test
[08:23] <mjg59> mdz: Ok, thanks
[08:24] <mdz> I had to leave on a trip and didn't have time to play with it
[08:25] <mdz> mjg59: nice artwork
[08:25] <dholbach> Surak: #ubuntu-motu is a better place to ask, and the bug is already filed
[08:26] <mdz> ogra: if it can be supported with a generic config file, sure
[08:26] <Surak> dholbach: the bug on launchpad is not the correct one. I've posted one after it.
[08:26] <ogra> mdz, thats what i doubt ...
[08:26] <mdz> ogra: speaking of which, we should add the architecture magic to load the right image
[08:26] <mdz> Diziet: how did your talk with lifeless go?
[08:26] <ogra> mdz, see my mail :)
[08:27] <ogra> mdz, i have an ltsp/multiarch branch to inspect
[08:27] <mdz> ogra: I am more responsive to emails with descriptive Subject headers :-)
[08:28] <ogra> heh, ok, will regard that in the future
[08:29] <mdz> mjg59: ok, it still does the same thing with 2.6.15
[08:30] <mdz> mjg59: mailed you a dmesg
[08:31] <Kamion> the only thing worse than merging packages that use patch systems is merging packages that use *both* patch systems and inline diffs.
[08:31] <mdz> mjg59: STR, otoh, seems to just ignore the event and not even try
[08:32] <mjg59> mdz: Get the latest acpi-support
[08:32] <mjg59> That won't fix STD, though
[08:33] <mjg59> Ok. What does /sys/power/state say?
[08:33] <mdz> a blank line
[08:33] <mjg59> Ah. That would explain it.
[08:34] <mdz> ok, with new acpi-support, STR and STD both behave similarly
[08:35] <dholbach> elmo: please sync libsigc++-2.0 from sid as well, thanks a lot (ok to override)
[08:35] <mjg59> mdz: Right, so iz kernel boog
[08:35] <janimo> elmo, please sync/override xfce-mcs-manager, thanks
[08:36] <seb128> elmo: please sync gnome-doc-utils from Debian incoming
[08:39] <Kamion> mjg59: hmm, grub upstream has implemented another workaround for broken BIOSes that pass the wrong boot drive. I wonder if it supersedes yours?
[08:40] <Kamion>          * This is a workaround for buggy BIOSes which don't pass boot
[08:40] <Kamion> +        * drive correctly. If GRUB is installed into a HDD, check if
[08:40] <Kamion> +        * DL is masked correctly. If not, assume that the BIOS passed
[08:40] <Kamion> +        * a bogus value and set DL to 0x80, since this is the only
[08:40] <Kamion> +        * possible boot drive. If GRUB is installed into a floppy,
[08:40] <Kamion> +        * this does nothing (only jump).
[08:40] <mjg59> Kamion: Yeah, sounds like it would supersede mine
[08:40] <mjg59> Drop mine, go with that, and I'll test it on the machine it breaks on?
[08:41] <Kamion> oh, if you still have it, even better
[08:44] <mjg59> mdz: It's an entirely blank line? Seriously?
[08:44] <mjg59> Grr
[08:46] <mdz> mjg59: potpal:[~]  od -c /sys/power/state
[08:46] <mdz> 0000000  \n
[08:46] <mdz> 0000001
[08:46] <mjg59> Tch
[08:46] <mjg59> Weird
[08:46] <Kamion> mjg59: (the upstream NEWS file says it was done for HP Vectras)
[08:47] <mjg59> It's fine on amd64
[08:47] <mjg59> mdz: Just let me upgrade an x86 here
[08:47] <mdz> mjg59: this is on my T42 fwiw
[08:54] <dholbach> Diziet: maybe we should just have followed: https://wiki.ubuntu.com/FirefoxNewVersion :)
[09:02] <dholbach>  #ubuntu-meeting ?
[09:05] <janimo> dholbach, there was nothing on the fridge about TB meeting today
[09:05] <dholbach> yes
[09:05] <dholbach> but there IS a meeting right now :)
[09:05] <seb128> it's on the fridge calendar
[09:05] <ogra> janimo, there is ...
[09:06] <janimo> yesterday there wasn't on the fridge
[09:06] <janimo> only edubuntu tomorrow
[09:07] <dholbach> the new usplash artwork ROCKs :)
[09:07] <ogra> grrr....
[09:18] <elmo> seb128/janimo/dholbach: done
[09:18] <seb128> thanks
[09:18] <dholbach> elmo: merci
[09:18] <janimo> thanks!
[09:24] <pitti> mjg59: 'Setting up usplash (0.1-24) ...
[09:24] <pitti> /boot/initrd.img-2.6.15-3-amd64-generic was been altered.  Cannot update.
[09:24] <pitti> '
[09:24] <pitti> mjg59: is that something to worry about?
[09:24] <mjg59> Unsure
[09:24] <mjg59> jbailey: ^ ?
[09:25] <ogra> update-initramfs has a force option :)
[09:26] <pitti> right, with -t it worked
[09:26] <seb128> pitti: Keybuk does a -t -u for the bootchart package
[09:26] <ogra> apparently we should use that now ...
[09:26] <ogra> *mail
[09:27] <pitti> but what is the definition of 'custom' initrd then? I certainly did not touch it manually
[09:32] <pitti> slomo_: we'll also kill esd so that gstreamer would output to alsa in the majority of cases; that should also help a/v sync
[09:34] <ajmitch_> elmo: please sync pingus from unstable, dropping ubuntu changes thanks
[09:36] <jdon1> hey, rhythmbox 0.9.2 in Dapper, deps needed on libgpod-dev
[09:36] <jdon1> build-deps that is
[09:37] <jdon1> maybe it's implicit under Dapper one way or another, but Breezy doesn't see it as obvious :)
[09:37] <Kamion> jdon1: already fixed earlier today
[09:37] <seb128> jdon1: it does
[09:37] <Kamion> 0.9.2-0ubuntu2
[09:37] <dholbach> jdon1: breezy?
[09:38] <jdon1> Kamion: I was unaware of that... sorry
[09:38] <seb128> dholbach: backport I guess
[09:38] <jdon1> dholbach: backports request
[09:38] <seb128> what version of the package do you use?
[09:40] <jdon1> seb128: what do you mean?
[09:40] <jdon1> seb128: 0.9.1 is currently backported already
[09:41] <jdon1> seb128: though today requests came in for 0.9.2
 hey, rhythmbox 0.9.2 in Dapper, deps needed on libgpod-dev
[09:42] <seb128> as mentionned by Kamion 0ubuntu2 should be fine
[09:42] <seb128> what version do you use ...
[09:42] <jdon1> sorry, that info was stale from this morning
[09:42] <jdon1> I apologize for not keeping my eyes so peeled on dapper changes :)
[09:42] <seb128> np ;)
[09:42] <jdon1> there was a mailing list thread on it earlier this morning
[09:42] <jdon1> and I was acting on that info
[09:43] <jdon1> is there any plans for bittorrent 4.x in Ubuntu? Can our mirrors meet the 6 month clause?
[09:44] <jdon1> we are really lacking a good BT implementation that supports multiple torrents
[09:44] <Burgwork> jdon1, 6 month clause?
[09:44] <jdon1> Burgwork: a new clause in the BT 4.x license is that mirrors must hold on to each version for a minimum of 6 months, I believe?
[09:44] <jdon1> which is why Debian refuses to package it
[09:44] <jdon1> DFSG stuff again
[09:45] <jdon1> Gnubuntu hasn't infiltrated us all already, has it? ;)
[09:45] <Burgwork> jdon1, what the heck?  So it seems like atm a backport of it isn't possible
[09:46] <jdon1> Kamion: yeah, I'm all for that too... but shad0w should REALLY get his ass off the couch and make his new GUI
[09:46] <jdon1> I no longer want to dedicate 400MB RAM to Azureus
[09:47] <mvo> jdon1: too much work?
[09:48] <jdon1> mvo: backports is not allowed to modify sources in any fashion
[09:48] <jdon1> mvo: currently we're only allowed to directly pull from Dapper
[09:48] <jdon1> mvo: and due to python-apt conflicts that cannot be done
[09:48] <mvo> jdon1: oh, I wasn't aware of that
[09:48] <jdon1> mvo: np, I am really looking forward to gdebi :)
[09:49] <jdon1> mvo: are you offering any people.ubuntu.com repos of gdebi under Breezy, or does that just not work?
[09:49] <mvo> jdon1: I'm considering it, I want to get as much testing as possible for it because it's a testbed for some python-apt enhancements as well
[09:50] <jdon1> mvo: cool, glad to hear... though how are you working around the python-apt dependencies?
[09:51] <mvo> jdon1: not at all, I will/would need to provide a updated python-apt as well
[09:51] <jdon1> mvo: ok, would that break any existing Breezy packages?
[09:51] <jdon1> jdon1: update/upgrade-manager and g-a-i come to mind
[09:52] <mvo> jdon1: no, I don't think so (the api is only extended, not changed). but that's something I will/would test before doing it :)
[09:52] <jdon1> mvo: cool, glad to hear
[09:53] <jdub> seb128: ping
[09:53] <seb128> wouah, a jdub here
[09:53] <seb128> jdub: pong :)
[09:53] <jdub> :-)
[09:53] <seb128> what's up? :)
[09:53] <jdon1> legal freaks: "The Source Code for any version of Licensed Product or Modifications that you distribute must remain available for as long as any executable or other form of the Licensed Product is distributed by you."
[09:53] <jdub> seb128: menu changes rock out - i think the totem test has proven itself lame :-)
[09:53] <jdon1> that's the line Debian devs had issues with
[09:53] <jdon1> though when I read it, it doesn't sound too bad
[09:54] <seb128> jdub: yeah, I said it was not a good idea, no? :)
[09:54] <jdub> seb128: yeah, but it was worth being handsome and bold for :-)
[09:54] <seb128> jdub: totem is to change back ... what about xsane?
[09:54] <jdub> seb128: what do you think about that one?
[09:55] <seb128> we had some comments about guys feeling that gimp is heavy to start for that and not really easy to find for users
[09:55] <seb128> I tend to agree
[09:55] <jdon1> oh yeah, you have to waive your right to a jury trial, apparently :)
[09:55] <jdub> last time i looked at xsane, it was horrific though
[09:55] <jdon1> all for a revamped BT GUI :)
[09:55] <jdub> plus we now have scanner support in g-v-m
[09:55] <seb128> graphical is not to crowded, I would revert the change
[09:55] <jdub> okay
[09:55] <seb128> yeah, it's ugly
[09:55] <seb128> but useful ...
[09:56] <mdke> having scanning only in gimp is crazy stuff
[09:56] <jdub> just like me!
[09:56] <slomo_> pitti: yes, imho a switch which was needed already long ago :)
[09:57] <jdub> seb128: i noticed there is more -desktop discussion on -devel turning up (though i have been too disconnected and swamped to reply to any of it as it comes up)
[09:58] <seb128> jdub: yeah, quite a bunch, and -desktop is not really active ... should point some people to it :)
[09:58] <jdub> yeah - please spread the smackings liberally ;-)
[09:58] <jdub> dholbach: you too :)
[09:59] <tseng> jdub: ubuntu-mono mailing list?
[09:59] <dholbach> jdub: yep :)
[09:59] <dholbach> jdub: ubuntu-* mailing list? :)
[09:59] <jdub> yeah man
[09:59] <jdub> it's all about ubuntu-*
[09:59] <dholbach> ;)
[09:59] <tseng> dude i asked you forever ago
[09:59] <jdub> i'll plough through the list now :-)
[10:00] <jdub> tseng: do you want admin address to be<EMAIL_ADDRESS>[10:00] <tseng> jdub: its<EMAIL_ADDRESS>please
[10:00] <jdub> ok
[10:01] <tseng> thanks!
[10:01] <jdub> tseng, dholbach: you guys are going to get some admin emails with the passwords, etc.
[10:01] <ogra> jdub, !
[10:01] <ogra> jdub, DSL back ?
[10:02] <tseng> jdub: pants^whats off
[10:02] <dholbach> jdub merci beaucoup
[10:02] <jdub> tseng, dholbach: log in and give the lists a nice info/description thingy, and then on the privacy page, make them public (that's very important)
[10:02] <jdub> ogra: just as i was leaving sydney, it came on
[10:02] <jdub> ogra: but atm i am in portland
[10:02] <dholbach> jdub: righto
[10:02] <ogra> oh, ok...
[10:02] <ogra> jdub, mhz is poking me all day about a edubuntu-es ML
[10:02] <jdub> really annoying :)
[10:03] <ogra> he said he mailed you ...
[10:03] <jdub> yeah, that's another on my list - was going to ask you about that
[10:03] <ogra> he's a member now
[10:03] <Treenaks> jdub: so I can start pimping my .torrent file tomorrrow morning (NL time, ~ 12 hrs from now)? :)
[10:03] <jdub> dholbach: erk, what's your ubuntu.com address?
[10:03] <jdub> dholbach: lbdb is full of malone bug addresses for you now - eeek!
[10:03] <dholbach> jdub: dholbach@ or daniel.holbach@
[10:04] <jdub> Treenaks: hrm, please wait for confirmation :)
[10:04] <Treenaks> jdub: sure :)
[10:05] <jdub> Treenaks: (reason being is that tonight's talk is going to be videoed, and is a more likely candidate for 'official' video, being much later and more fleshed out, despite amsterdam being 2 1/2 hours and having laptop/presentation stolen!)
[10:06] <Treenaks> jdub: Oh ok
[10:06] <Treenaks> jdub: sounds reasonable :)
[10:07] <mhz> jdub: ping
[10:08] <jdub> mhz: just talking to ogra about it
[10:08] <dholbach> zakame: -> #ubuntu-meeting
[10:08] <mhz> jdub: hehehe, thx, and i'm sorry to bug so much
[10:08] <jdub> 'sok, i've been hard to contact recently (travelling, moved house, yada0
[10:09] <zakame> dholbach: yup, on there now :)
[10:10] <tseng> jdub: all set up, thanks a bunch
[10:14] <mhz> #ubuntu-artwork
[10:24] <janimo> elmo, please sync/override xfce4-toys, thank you
[10:25] <mhz> mako: ping
[10:25] <mdke> mhz, mail him
[10:25] <mhz> mdke: thx, I have twice
[10:26] <mdke> mhz, then he will answer I'm sure
[10:27] <mhz> mdke: okis, no more pinging m a k o :)
[10:28] <mdke> mhz, you can, I think you'll have more luck by email tho
[10:37] <dholbach> good night guys
[10:37] <Mithrandir> night, Daniel
[10:37] <dholbach> night tollef
[10:44] <ardchoille> Any Ubuntu devs here?
[10:44] <ardchoille> I am damned impressed with Ubuntu 5.10. I have spent an entire 24 hours trying to break it and I can't. I did manage to mess up a package, but that was due to IUS and not Ubuntu;s fault.
[10:44] <ardchoille> The repos are huge, surprised the hell out of me
[10:45] <ardchoille> Kudos to the devs for this awesome distro!
[10:45] <ogra> ardchoille, we are all in a meeting currently, but thanks for the nice feedback :)
[10:45] <mhz> ardchoille: i'm sure all devels feel very gald you like it (/me is not a devel)
[10:46] <ardchoille> ogra: yw
[10:46] <ardchoille> mhz: I love it
[10:46] <mhz> ardchoille: me too :)
[10:47] <mhz> ardchoille: are you a devel?
[10:47] <ardchoille> No, just a very happy camper
[10:47] <mhz> he
[10:48] <ardchoille> I wanted to test Ubuntu 5.10 on one box to see if it was good enough to take what I could give it.  Still running and I am impressed.
[10:48] <ardchoille> I have 11 computers that I am going to install 5.10 on today. This is the first distro that just amazes me.
[10:49] <mhz> ardchoille: you could wiki your comments on users stories
[10:49] <ardchoille> mhz: really?
[10:49] <ardchoille> where?
[10:50] <mhz> let me get it for you, however, you gotta create an account on LaunchPad in order to edit pages on the wiki
[10:51] <mhz> ardchoille: https://launchpad.net/people/ubuntumembers/+login
[10:51] <ardchoille> awesome!
[10:51] <mhz> that account will give you access to all ubuntu wikis
[10:51] <ardchoille> Thank you
[10:52] <mhz> plus you'll be able to contribute with work if you like.
[10:52] <Kamion> ardchoille: thanks for the compliments. :-)
[10:53] <mhz> ardchoille: for success stories, https://wiki.ubuntu.com/SuccessStories
[10:54] <ardchoille> Kamion: The first distro that I have seen that just ROCKS!
[10:54] <ardchoille> mhz: Thanks again
[10:55] <mhz> np, thank you for giving it a try and share this with all
[10:55] <ardchoille> I have used 11 distros over the past three years
[10:55] <mhz> ardchoille: and if you get a bug, please submit it :)
[10:55] <ardchoille> as soon as I become confident with making .deb's for Ubuntu, I plan to become a packager, or help out in that area
[10:56] <mhz> ardchoille: cool! all help is very welcome
[10:56] <ardchoille> mhz: That's my whole point.. I have tried to break this distro and I have not seen any bugs.
[10:56] <mhz> hehe
[10:57] <ardchoille> literally, I _tried_ to break it.. that was easy with other distros (Fedora is crap) but I can't seem to do it with Breezy
[10:57] <ardchoille> I installed almost every package in the repos and all is well
[10:57] <ardchoille> I had one little problem due to IUS but that wasn't Ubuntu's fault.. and Ubuntu even fixed it for me.
[10:59] <mhz> wow
[11:00] <ardchoille> Well, whomever the devs are, you all did a fantastic job and other distros should take a lesson from you. I just wanted you to know that I appreciate your work.
[11:00] <ardchoille> Peace popcorn
[11:01] <ardchoille> :)
[11:14] <mdke> do the language pack exports from rosetta include updates to .desktop files from the relevant strings in the po files?
[11:17] <mdke> pitti ^ ?
[11:17] <pitti> not yet
[11:17] <mdke> pitti, thanks
[11:19] <wasabi> Silly ass X.
[11:19] <wasabi> Second monitor stopped working.
[11:24] <ogra> wasabi, great, so finally you can buy a second PC for it :)
[11:27] <wasabi> No, monitor is fine.
[11:27] <wasabi> X did it. ;0
[11:29] <ogra> no i meant to make use of the spare monitor you have now :)
[11:46] <pitti> good night everybody
[12:01] <zyga> mdke: hi
[12:01] <zyga> mdke: oh sorry, pitti already answered your question ;]


[00:38] <OvenWerks> Lubuntu comes without dialog, I can't believe it.
[03:03] <OvenWerks> actually so does server, which is even more amazing.
[03:03] <OvenWerks> anyway, feel free to look at:
[03:03] <OvenWerks> http://www.ovenwerks.net/UStudiodocs/metainstall.html
[03:20] <micahg> OvenWerks: ok, I'll have a look
[03:22] <OvenWerks> micahg: Thank you
[08:36] <zequence> OvenWerks: Why are you making a script to install Ubuntu Studio metas?
[22:09] <zequence> Noskcaj: about the sticker. madeinkobaia is our art lead. he could probably make one for you, if you asked him
[22:10] <zequence> he's not in right now, but if you want to email him, his email is<EMAIL_ADDRESS>[22:10] <Noskcaj> zequence, when the build is closer to done, i will.


[00:39] <rharper> ok, systemd_timesyncd and chrony done;
[00:39] <rharper> now I'm done, tomorrow fixing up py26 unittests
[00:39] <rharper> *sigh*
[01:38] <smoser> blackboxsw: i would probably not add the new depends into x, a
[01:39] <smoser> it probably *is* strictly required.
[01:39] <smoser> but because isc-dhcp-client is part of ubuntu-minimal
[01:40] <smoser> and you're really expected to create a ubuntu without 'ubuntu-minimal'
[01:40] <smoser> it is not likely that cloud-init is to be installed in such a place.
[01:43] <smoser> so.. i'd just leave it be.  additionally, adding depends or recommends like that to a stable can be problematic
[01:43] <smoser> see someone complaining about a similar add
[01:43] <smoser>  https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1633643
[01:44] <smoser> and then also the squashfuse bug (bug 1628289)
[01:53] <blackboxsw> +1 on dropping isc-dhcp-client depends
[01:53] <blackboxsw> will repost the MPs without that
[02:01] <blackboxsw> smoser: thanks for the reference to https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1756173
[02:03] <blackboxsw> I've added a card https://trello.com/c/OTYKbFEu/720-drop-squashfuse-install-logic-from-ccsnap-when-https-bugslaunchpadnet-ubuntu-source-snapd-bug-1756173-lands
[02:29] <blackboxsw> pushed ubuntu/xenial and ubuntu/artful without isc-dhcp-client explicit dependency
[13:53] <rharper> smoser: ./tools/run-centos is super handy =)
[13:55] <smoser> yeah. we need to make it work for suse too
[13:56] <smoser> and actually.. i've even wnated it to work for ubuntu
[13:56] <smoser> when there was some bug trhat didnt reproduce on my desktoip, but c-i saw.
[14:05] <rharper> interesting
[17:01] <smoser> blackboxsw: ok... can you give qa-scripts/new-upstream-snapshot a try ?
[17:01] <smoser> you can see the last commit message there.
[17:02] <smoser> i think i have addressed most of the pain in it.
[17:02] <blackboxsw> checking/updating now
[17:02] <blackboxsw> and thanks!
[17:03] <blackboxsw> smoser: we'll drop new-upstream-snapshot script after the SRU or as part of the SRU?
[17:03] <blackboxsw> in the ubuntu/xenial|artful branches
[17:03] <smoser> i think no hurry to drop it.
[17:03] <smoser> so i'd say after.
[17:03] <smoser> but if you want to drop it we can.
[17:06]  * blackboxsw checks out the refresh patches logic. that was a surprise
[17:07] <smoser> thats why your xenial didnt work
[17:07] <smoser> because the patch would only apply with fuzz
[17:07] <smoser> as we'd changed ds-identify aroudn the xenial patches
[17:09] <blackboxsw> gotcha, yeah I just didn't expect to see a separate commit message for it, and changelog entry. Both make sense as separate items, I just wanted to understand the quilt magic
[17:13] <blackboxsw> smoser: pushed just ubuntu/xenial branch again
[17:13] <blackboxsw> shall I push artful again?
[17:14] <blackboxsw> new-upstream-snapshot works like a charm
[17:15] <smoser> blackboxsw: i uploaded artful all ready.
[17:15] <blackboxsw> ahh hadn't checked, thx
[17:15] <smoser> i don tthink any reason to re-do it.
[17:16] <blackboxsw> changelog didn't end up changing anything, so good there on artful anyway
[17:26] <ihre> I'd like to test some changes in user-data after applying some changes to user-data. So far, I've mostly used cloud-init w/ qemu and genisoimage for testing, but I think there should be an easier way. I've tested w/ manual changes to cloud-config.txt/user-data.txt/user-data.txt.1 in /var/lib/cloud/instances/$instance-id/, and by reattaching the cdrom through the qemu monitor, yet changes aren't picked up.
[17:26] <ihre> Which file on disk should I modify to be able to rerun cloud-init without having to go through the qemu/genisoimage steps?
[17:26] <blackboxsw> ihre: there are several semaphores that block re-running specific cloud-init modules across reboots
[17:27] <blackboxsw> you can clear out those semaphores by running "sudo cloud-init clean --logs --reboot"
[17:27] <blackboxsw> it'll remove all cloud-init former run logs and reboot the machine so cloud-init can re-run "fresh" with any user data you've provided
[17:28] <blackboxsw> I generally iterate using lxc on ubuntu
[17:28] <blackboxsw> via lxc launch ubuntu-daily:bionic myb1
[17:29] <blackboxsw> lxc exec myb1 bash   # then manipulate user-data in /var/lib/cloud/seed/nocloud-net/user-data
[17:30] <blackboxsw> in lxcs, the  no-cloud/seed directory is kept across reboots.    I'll check how the qemu image detected  re-run to better answer your question
[17:31] <blackboxsw> hrm, I actually have to run on an errand, will get back to that in ~45 mins
[17:32] <ihre> blackboxsw: Thanks, didnt think of using a container to test it, that seems a nice alternative as well.
[17:32] <ihre> Previously, I just removed a/the semaphore(s) by hand and reran cloud-init modules --mode final.
[17:33] <blackboxsw> it's at least the fastest iterative method I've found for dev-test cycles.
[17:33]  * blackboxsw heads out
[17:33] <ihre> No rush on my end, the current way works fine though, it just feels a little cumbersome at times, anyways, thanks for taking the time to look into it :)
[17:39] <smoser> blackboxsw: your quilt refrsh differs in behavior from mine.
[17:40] <nacc> blackboxsw: smoser: it's sensitive to ~/.quiltrc
[17:40] <nacc> use --quiltrc -
[17:40] <nacc> (just a guess)
[17:42] <smoser> yeah.
[17:44] <nacc> we have to do that in git-ubuntu
[17:44] <nacc> smoser: i'm guessing this is about reproducibility?
[17:49] <smoser> blackboxsw: grab tip of qa-scripts and try again, would you ?
[17:50] <smoser> nacc: well, yeah.
[17:50] <smoser>
[17:50] <smoser> http://paste.ubuntu.com/p/3BwC5n3v4P/
[17:50] <nacc> smoser: yeah
[17:50] <smoser> we run 'new-upstream-snapshot' to create a new upstream snapshot of cloud-init.
[17:50] <smoser> and that is a run here versus on chad's system.
[17:50] <nacc> yeah, you want your snapshot to be the same as chad
[17:51] <nacc> similar idea for us, we want our same-argument builds to be contentfully the same
[18:33] <blackboxsw> smoser: just pushed https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+ref/ubuntu/xenial
[18:36] <smoser> blackboxsw: woot.
[18:36] <smoser> mine to yours : http://paste.ubuntu.com/p/spBd2CCrKg/
[18:36] <smoser> new feature there to strip bug numbers on sru
[18:36] <smoser> and make you give an SRU bug
[18:53] <blackboxsw> ahh right I totally forgot to strip bug#'s on artful
[18:56] <blackboxsw> smoser: what should I do w.r.t. devel/arful
[18:56] <blackboxsw> smoser: what should I do w.r.t. devel/artful. should we strip bug#'s
[18:58] <smoser> blackboxsw: oh. shoot. yeah i guess we should. right ?
[18:58] <smoser> we are supposed to.
[18:58] <smoser> we can just re-upload
[18:58] <blackboxsw> yeah, I think so, yeah I'll repropose and do that right.
[18:58] <blackboxsw> forgot that part of the process obviously
[18:59] <smoser> well now the script does the right thing
[18:59] <smoser> you forgot, i forgot too.
[19:11] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/342329 just --forced a new-upstream-release for artful
[19:12] <blackboxsw> merge conflicts against existing ubuntu/artful.
[19:13] <blackboxsw> for all the bug comment drops
[19:13] <smoser> blackboxsw: how bout this..
[19:16] <smoser> git checkout ubuntu/artful
[19:16] <smoser> git reset --hard ubuntu/17.2-35-gf576b2a2-0ubuntu1_17.10.2
[19:16] <smoser> new-upstream-snapshot
[19:16] <smoser> dch --release --distribution=artful
[19:16] <smoser> git push chad.smith HEAD --force
[19:16] <smoser> basically,  lets just re-do it.
[19:16] <blackboxsw> yeah I did basically that.
[19:16] <blackboxsw>  git checkout -b ubuntu/artful a2ce41af52c619c13da66f84ee2a789b9df8f3a2
[19:16] <blackboxsw> and re-ran everything
[19:16] <blackboxsw> I'll use your git-fu here and try again
[19:17] <smoser> yours is probably ok now.
[19:17] <smoser> let me see. i thought you were saying it wasnt
[19:17] <blackboxsw> In the UI I see merge conflicts
[19:17] <blackboxsw> in debian/changelog
[19:17] <blackboxsw> but all the other content is good
[19:19] <smoser> yours is good.
[19:19] <smoser> k. i'll just build and push and push over upstream
[19:21] <blackboxsw> excellent. and the moral if this story is: Chad don't push branches late in the evening
[19:22] <smoser> i'm quite happy with those changes to that script.
[19:22] <smoser> i think we have covered most of the pain poitns of it.
[19:23] <blackboxsw> smoser: I love it. though I throw eggs at any shell script.
[19:23]  * blackboxsw will become better versed in shell someday.
[19:26] <smoser> blackboxsw: fair enough. it is lots of variables and such in there. definitely "shell script"
[19:26] <blackboxsw> smoser: right so although you pushed the upload, nothing showed in artful-proposed  yet so we're safe to re-push right?
[19:27] <blackboxsw> I'm looking for the proposed  build queue in launchpad again
[19:27] <blackboxsw> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=cloud-init
[19:27] <blackboxsw> or https://launchpad.net/ubuntu/artful/+queue?queue_state=1&queue_text=cloud-init rather
[19:28] <smoser> i just uploaded artful
[19:29] <blackboxsw> ok great so that list tells me you just re-submitted same unapproved upload 30 seconds ago
[19:29] <smoser> yep
[19:29] <blackboxsw> now do we ping in ubuntu-release for attention on artful/xenial?
[19:30] <smoser> we can, yeah.
[19:30] <blackboxsw> will do.
[19:43] <blackboxsw> ok smoser I'm going to get to work on updating out manual cloud test scripts for this SRU https://hackmd.io/jlq3C4qbSgurZ_DZ5GTiuw?both
[20:25] <blackboxsw> smoser: I hadn't tested review-mps yet on non-master branches. I didn't want to automatically botch the merges
[20:26] <blackboxsw> all 3 branches are approved
[20:26] <blackboxsw> I can use review-mps to land them later if you don't land them now
[20:58] <ihre> thanks for the tip re: lxc/lxd blackboxsw, that is definitely an easier workflow than using qemu :)
[20:59] <blackboxsw> good to hear ihre, I'll probably write up a blog post about it (and use of other cloud-init CLI commands=)
[21:03] <ihre> i'll keep an eye out for it!
[21:51] <blackboxsw> ok smoser landed your ubuntu/(artful|xenial) mps and fixed up qa-scripts:review-mps tool to properly handle --upstream-branch origin/ubuntu/*
[22:09] <blackboxsw> thanks for the cloud-init release email  BTW https://lists.launchpad.net/cloud-init/msg00145.html