[00:01] <rexbron> where would be the appropreate place to document this sort of decision?
[00:02] <rexbron> (that last question is open to all)
[00:03] <LaserJock> rexbron: probably first ubuntu-motu/ubuntu-devel ML
[00:03] <rexbron> LaserJock, this package is not in the repos yet, but I will do so
[00:08] <persia> rexbron: I'm not really here, but my concern is that while openlibraries uses rpath entirely internally within itself, open libraries is intended to be used for building other applications, and I'm not convinced that there won't be odd follow-on behaviour once other packages dynamically load the libraries, possibly with RPATH set, nor am I sure those packages won't run against policy.  I may be completely mistaken, and expect your research to hav
[00:10] <rexbron> ouch buffered
[00:11] <rexbron> I would think that any libraries that use openlibs would not use rparth, hense preserving upgrade sanity
[00:11]  * rexbron will definately take it to the ML
[00:20] <RAOF> rexbron: But if the openlibraries itself uses rpath, then anything using it...
[00:21] <rexbron> RAOF, if only internally?
[00:22] <RAOF> rexbron: But the OL libraries are installed into a non-ld-config-known path, right?  Anything linking against them will need to do annoying stuff.
[00:22] <rexbron> Basically, openlibraries is a collection (five main ones, with in each there is a C++ lib and a python binding) and a bunch of compiled plugins for those libs
[00:23] <rexbron> RAOF, by nonstandard I mean /usr/lib/openlibraries-<foo>
[00:23] <rexbron> which is how upstream is installing it
[00:23] <RAOF> Ok.  So the libraries themselves are in /usr/lib, and the plugins are in /usr/lib/openlibraries type thing?
[00:23] <rexbron> no,
[00:23] <rexbron> currently everything is in /usr/lib/openlibraries-0.5.0
[00:24] <RAOF> That sounds like a really annoying idea.
[00:24] <rexbron> RAOF, I was striping the rpath out of the libs that had it (not all of them do)
[00:24] <rexbron> but that completely broke the python bindings
[00:24] <rexbron> due to the non-standard location
[00:25] <rexbron> it is possible though that I mangle it in  the .install files
[00:25] <RAOF> This non-standard location isn't build-time configurable?
[00:25] <rexbron> afaict, no
[00:25] <rexbron> beyond a prefix
[00:25] <RAOF> rexbron: For details of why installing libraries in /usr/lib/foo is really annoying, see *anything* which embeds gecko.
[00:25] <rexbron> :P
[00:25] <RAOF> That's annoying.
[00:26] <RAOF> Whine upstream :P
[00:26] <crimsun> nenolod: pong
[00:26] <crimsun> RAOF: pong
[00:26] <rexbron> RAOF, upstream just revived itself
[00:26] <rexbron> RAOF, it might have to do with the devs being Mac and Windows peps
[00:27] <RAOF> crimsun: Hi.  Trying to hack in multiarch _sucks_ :(
[00:27] <crimsun> heh, it's nice and comfy down here in hell, isn't it?
[00:27] <rexbron> I wonder if I strip rpath and install everything to /usr/lib if the problems would allivate themselves
[00:28] <RAOF> rexbron: Worth a try :)
[00:28] <rexbron> I am unsure if ld.so.conf is getting updated by debhelper...
[00:29] <RAOF> crimsun: My final problem is trying to make the bi-arch build not build plugins that it can't, but pkg-config thinks it can.
[00:30] <rexbron> RAOF, the dir structure is like this: usr/lib/openlibraries-0.5.0/openeffectslib/plugins/
[00:30] <rexbron> or usr/lib/openlibraries-0.5.0/openeffectslib/lib
[00:31] <RAOF> rexbron: Hit upstream with a big "what the hell are you doing" stick.
[00:31] <rexbron> "Bash upstream with the libtool handbook.."
[00:32] <RAOF> It makes sense to have the plugins in /usr/lib/<my_plugin_dir>, but that looks mad.
[00:37] <crimsun> RAOF: did you mean to follow up that last one?
[00:48] <RAOF> crimsun: By "last one" did you mean the "stopping it building the plugins it can't, but pkg-config makes it think it can"?
[00:48] <crimsun> RAOF: yes
[00:48] <RAOF> Ah.
[00:49] <RAOF> I can explain the problem: configure checks pkg-config for libpulse, jack, ald dbus-1, and sets "HAVE_foo".
[00:50] <RAOF> However, pkg-config is returning results for the native bitness libraries.  So it tries to build all of these plugins.
[00:51] <RAOF> I can partially work around this by telling pkg-config to look in /usr/lib$)bi)/pkgconfig (which is empty) and manually specifying the right libs & cflags.
[00:52] <RAOF> That builds the basic plugins, with no external dependencies.  However, since they use a [if found] and a [if not found] custom action for their PKG_CHECK_MODULE configure calls, libpulse & dbus-1 (which exist in ia32-libs) don't get built.
[00:53] <kdub> anyone have program that needs packaging that they've been saving for a newbie :-)?
[00:53] <RAOF> crimsun: Given that what *I* want out of lib32asound2-plugins is a 32bit pulse plugin, this isn't very useful behaviour for me :(
[00:53] <RAOF> crimsun: Any ideas?
[00:55] <crimsun> RAOF: do your basic debian/rules modifications follow alsa-lib's?
[00:56] <RAOF> crimsun: Yes, they do.  I can post them, if you like.
[00:57] <crimsun> sure, though my attention is diverted to a PA security issue ATM, so I'll be slow in responding.
[00:58] <RAOF> crimsun: That's fine.  It's at http://www.cooperteam.net/rules
[01:11] <LaserJock> anybody know how to tell tracker what to index?
[01:13] <_MMA_> LaserJock: Isnt there a place where to tell it what *not* to index?
[01:13] <LaserJock> bah
[01:13] <LaserJock> I killed it
[01:13] <LaserJock> I want it to index my pdfs
[01:13] <StevenK> That isn't hard
[01:13] <LaserJock> and it doesn't seem to do it
[01:13] <LaserJock> does it not index .pdf files?
[01:13]  * _MMA_ only thought there was a blacklist.
[01:13] <ScottK> LaserJock: It'll index your ISO images too.
[01:14] <LaserJock> ScottK: hah, that's smart
[01:14] <LaserJock> I saw it also indexes vmware images
[01:14] <_MMA_> :)
[01:14] <LaserJock> but they're gonna blacklist that
[01:14] <LaserJock> so far the only thing I found it *can* do is index my email
[01:14] <ScottK> Well I think Tracker is one of the best advertisements Kubuntu has has in a long time.
[01:15] <LaserJock> which I can already do from evo
[01:15] <LaserJock> ScottK: you use strigi?
[01:15] <ScottK> LaserJock: Actually not, but I understand it's better behaved.
[01:15] <ScottK> My main desktop (where it'd be useful) is still Dapper.
[01:16] <LaserJock> I know there's been some cool work with strigi and chemistry indexing
[01:18] <nenolod> crimsun, would ALSA plugin chains cause problems with DMA writes in libalsa?
[01:18] <ScottK> LaserJock: BTW, so far so good the mass clamav backport.  Thanks again.
[01:19] <LaserJock> ScottK: great
[01:21] <crimsun> nenolod: quite probably, particularly if dmix and/or dsnoop are in the mix.
[01:26] <LaserJock> bah, I give up >:(
[01:28] <emgent> heya people
[01:50] <bddebian> Heya gang
[02:38] <bddebian> ScottK: I think you have been hanging around Debian too much already.. ;-P
[02:44] <ScottK2> bddebian: Not yet.  I didn't curse at you.
[02:52] <nenolod> crimsun, fantastic. thanks (:
[02:55] <bddebian> ScottK2: Heh, touche :-)
[03:37]  * emgent night.
[03:37] <bddebian> ScottK2: Wanna help with a bug instead? :-)
[03:38] <ScottK2> What bug?
[03:38] <bddebian> testresources FTBFS
[03:39] <ScottK2> And?
[03:39] <bddebian> And I don't know how to fix it :-)
[03:40] <ScottK2> Point me at a build log?
[03:40] <LucidFox> I read that as "testosterone FTBFS" :/
[03:41] <bddebian> ScottK2: http://paste.debian.net/47576
[03:41] <bddebian> LucidFox: :)
[03:43] <ScottK2> bddebian: Is the the Debian package or the Ubuntu one?
[03:44] <bddebian> I just updated the debian one so they are pretty similar but same issue
[03:45] <ScottK2> I'll have a look.
[03:46] <bddebian> You ROCK :)
[03:46] <bddebian> I need to improve my python.. :-(
[03:47] <bddebian> Well, and everything else.. :)
[03:47] <RAOF> Cue bddebian suckage rant?
[03:47] <RAOF> :)
[03:50] <bddebian> Yeah, he does suck doesn't he..
[03:51] <ScottK2> Well the ubuntu package doesn't even get that far right now.
[03:52] <bddebian> Ah, I used python support
[03:53] <ScottK2> doko would kill me if I changed it in Ubuntu.
[03:53] <bddebian> heh
[04:01] <ScottK2> bddebian: I got it to build in Ubuntu.
[04:01] <ScottK2> I made two changes.  I'm not sure which it was.  Testing.
[04:01] <bddebian> What did you change... Oh :)
[04:04] <ScottK2> The problem in Ubuntu was that python2.4 wasn't present
[04:04] <ScottK2> So I changed python-dev to python-all-dev
[04:04] <ScottK2> Also moved it from build-dep-indep to build-dep since it's needed in clean according to Lintian.
[04:05] <ScottK2> So it'll build now and the current Ubuntu package that hasn't been built since python2.4 was default (I think) will now built.
[04:05] <ScottK2> built/build
[04:06] <bddebian> Hmm I have both of those.. weird
[04:06] <bddebian> Do you have a sid pbuilder?
[04:07] <ScottK2> I do.
[04:08] <ScottK2> I just uploaded to Ubuntu so it'll at least build.
[04:08] <ScottK2> I've got to run here in a minute.
[04:08] <ScottK2> I kicked off my sid pbuilder and we'll see what happens
[04:08] <bddebian> OK, thanks
[04:10] <ScottK2> bddebian: Builds fine in my sid pbuilder.  Feel free to steal it for Debian.  ;-)
[04:11] <ScottK2> It could use more work.  Lintian is happier, but not satisfied.
[04:11] <bddebian> Grr, wtf
[04:22] <tonyyarusso> Hey, would anyone be willing to throw together a _very_ simple package for me?  My personal life has taken a turn for the insane and I'm becoming unsure of whether I can get it done before freeze, although an experienced person could probably do it in a matter of minutes.
[04:23] <ScottK> I just fixed bddebian's bug for him, so he's got free time.
[04:24] <bddebian> I find it hard to believe that it's actually fixed with that :)
[04:24] <bddebian> tonyyarusso: What/where is it?
[04:24] <tonyyarusso> It has been proposed that a package with the name of 'nvu' be added to the Hardy repos in the same vein as the 'mozilla-thunderbird' package, just as a transitionary package depending on 'kompozer' (already in the archives), so that Dapper users have a clean LTS->LTS upgrade path.
[04:24] <tonyyarusso> bddebian: ^
[04:24] <ScottK2> tonyyarusso: Make it an additional binary package of your kompozer package.  Not a whole new package.
[04:25] <bddebian> Aye, can't you even just make it Provides: ?
[04:25] <tonyyarusso> ScottK2: That makes sense...
[04:25] <tonyyarusso> bddebian: I'm not sure?  Probably?
[04:25] <ScottK2> bddebian: We'll see.
[04:26] <tonyyarusso> bddebian: So I just add a Provides: line much like Depends:, and if a user has nvu installed on Dapper, and upgrades to Hardy, they'll get the new kompozer package installed?
[04:26] <StevenK> You could just ask mvo to add an hint to update-manager
[04:27] <tonyyarusso> a hint?
[04:27]  * tonyyarusso looks for documentation on Provides
[04:27] <bddebian> tonyyarusso: Should.  You might also need a conflicts/replaces if you do that??
[04:27] <RAOF> tonyyarusso, bddebian: Does provides: work properly accross package renames & upgrades?  I remember being asked to provide a proper package for Miro.
[04:27] <bddebian> RAOF: It may not
[04:27] <StevenK> tonyyarusso: I'd suggest asking pitti when he turns up
[04:28] <bddebian> ScottK2: Can you throw a source package up somewhere or are you leaving?
[04:28] <tonyyarusso> "For some types of packages where there are multiple alternatives virtual names have been defined. You can get the full list in the /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz file. Use this if your program provides a function of an existing virtual package."
[04:28] <StevenK> tonyyarusso: Ignore that
[04:28] <tonyyarusso> StevenK: heh, all right.  Didn't know what it meant anyway!
[04:28]  * Hobbsee would just use conflicts and replaces nvu
[04:29] <StevenK> It has no reason to Conflict
[04:29] <tonyyarusso> Hobbsee: I know that would properly replace nvu if they did it manually, but I'm confused about upgrade-specific behavior.
[04:29] <StevenK> Replaces and Provides, sure.
[04:29] <Hobbsee> StevenK: ah right, is that it.
[04:29] <Hobbsee> StevenK: assuming none of the files wer ethe same
[04:30] <StevenK> Wait, no reason to Replaces either
[04:30] <tonyyarusso> It is possible to have both packages installed simultaneously.  It would just be a tad silly, and not what an upgrader would expect.
[04:31] <tonyyarusso> AFAIK they have different paths for all files.
[04:31] <StevenK> I think this should documented
[04:31] <StevenK> Sigh
[04:31] <tonyyarusso> I think I need a clone.
[04:32] <tonyyarusso> (Full time student and managed to find myself doing three jobs too - stupid, but they're good jobs, so hey - just a wee bit busy between now and June)
[04:33] <tonyyarusso> So pitti or mvo eh?  I forget; what times are they usually around?
[04:34] <ScottK> tonyyarusso: European work day.
[04:34] <tonyyarusso> ScottK: 'k
[04:34] <bddebian> Damn Europeons
[04:34]  * bddebian ducks
[04:35] <ScottK> tonyyarusso: Any chance you could look into making the publish function work with SFTP and not just FTP.
[04:35] <ScottK> That's be really handy.
[04:35] <tonyyarusso> ScottK: Make it work, no.  Mention the desire to the guy who could, yes.  (I just put it in the archives; someone else wrote the code.)
[04:36] <tonyyarusso> ScottK: Meanwhile, you wanna add scp as an option to sbackup?  :P
[04:36] <tonyyarusso> (Just while we're talking about transfer methods in random packages on our wishlist)
[04:36] <ScottK2> tonyyarusso: Mentioning would be great.
[04:37] <tonyyarusso> ScottK2: on the todo list
[04:38] <ScottK2> Great.
[04:40] <ScottK> Good night all.
[04:40] <bddebian> Gnight ScottK, thanks for looking at that
[04:42] <bddebian> Even if it does fail on sid for me... ;-)
[06:06] <crimsun> keescook: I've filed and attached the appropriate info to bug 185534.
[06:06] <ubotu> Launchpad bug 185534 in pulseaudio "[SECURITY] Fix unchecked setuid() return values (feisty-security, gutsy)" [High,Fix released] https://launchpad.net/bugs/185534
[06:39] <warp10> heya all
[07:32] <Aloha> how do i build tarballs to create source packages from? like a source package to install wallpapers
[07:41] <RAOF> Aloha: By taking a directory with all the stuff you want in it and going "tar czvf wallpapers_0.1.orig.tar.gz"
[07:41] <Aloha> RAOF, i want to make a bonary package though
[07:41] <Aloha> binary
[07:42] <RAOF> Which will be built from a source package, which will start with a .orig.tar.gz?
[07:43] <Aloha> RAOF, how do i get it to install the files?
[07:43] <RAOF> Any way you like.  dh_install is probably a good way.
[07:44]  * Aloha needs to grok dh_install
[07:45] <RAOF> It's pretty easy; you have a 2 column list.  The first column is the file you want to work on, the second is where it should go.
[07:46] <Aloha> RAOF, then i put dh_install in debian/rules?
[07:46] <RAOF> Yup.  Probably in the install-indep target.
[07:46]  * Aloha needs to grok install-indep
[07:46] <Aloha> RAOF, thnx for the help
[07:47] <RAOF> Heh.  debian/rules is just a makefile with a bunch of specified targets :)
[07:47] <Aloha> gotcha
[07:47] <RAOF> It helps to have a basic understanding of Makefile syntax.  Which is also pretty easy :).
[07:47]  * Aloha needs to grok Makefile ;)
[07:48] <Aloha> only Makefile work I usually do is typing make heh
[07:55] <Aloha> what targets does the installer call in the Makefile when the package is installed?
[08:05] <RAOF> Aloha: You'd want to check Debian policy; there's a list of all the targets there.
[08:05] <Aloha> RAOF, thnx
[08:05] <RAOF> In particular: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[08:07] <Aloha> RAOF, whats the advantage of using dh_install over a simple cp?
[08:08] <RAOF> It's more debianic, for a start.
[08:09] <RAOF> If you weren't going to use dh_install you'd probably want to use install anyway, so you can control the permissions, for a start.
[08:09] <RAOF> And if you're installing a bunch of wallpapers it can be more obvious to have them listed in debian/foo.install rather than having a bunch of cp lines.
[08:10] <Aloha> RAOF, gotcha, how does dh_install how which .install file to look in?
[08:10] <Aloha> or do i dh_install file.install?
[08:10] <RAOF> It either looks for debian/install, or debian/<packagename>.install
[08:11] <RAOF> This is common behaviour for debhelper programs
[08:11] <Aloha> where dh_name looks for debian/name?
[08:12] <RAOF> Or debian/<packagename>.name, yes.
[08:12] <Aloha> RAOF, thnx you're a BIG help
[08:29] <Aloha> dpkg-buildpackage --rfakeroot doesn't execute binary-arch?
[08:36] <wallyweek> g'morning all!
[08:39] <Aloha> wallyweek, morning
[08:42] <\sh> hmm..how can I stop gnome/nautilus/whatever to show dynamically mounted lvm devices?
[08:45] <huats> morning everyone
[08:51] <norsetto> morning folks
[08:51] <gaspa> norsetto: ue'.
[08:51] <norsetto> ué gaspa - ron
[08:51] <gaspa> ue' == "tipical american greeting" :D
[08:52] <norsetto> gaspa: gasparon = typical american nickname
[08:53] <gaspa> :D
[08:53] <gaspa> norsetto: how are you?
[08:53] <norsetto> gaspa: surviving, and you?
[08:55] <gaspa> norsetto: very <yaaAAwn> good!!
[08:55] <Aloha> when i do dpkg -c packagename.deb it lists /usr/bin and /usr/sbin how do i get rid of that?
[08:56] <gaspa> norsetto: i've a little monst... ehm... daughter that makes hard to sleep well. :D
[08:56] <norsetto> gaspa: he, the pleasures of parenthood .... you going to Pisa this week-end btw?
[08:56] <gaspa> siena, you mean...
[08:57] <norsetto> Aloha: most probably you used dh_make and that automatically includes those in debian/dirs I guess
[08:57] <norsetto> gaspa: yes, somewhere in Tuscany anyhow ;-)
[08:57] <gaspa> lol
[08:57] <Aloha> norsetto, oh gotcha. is there a better way to build non compile source packages?
[08:58] <norsetto> aloha: to build not compile!? Sorry, don't follow you ... you mean to make a tarball and attach it a deb label?
[08:58] <gaspa> norsetto: i don't know, there's not so much developers, and i don't like 'organization meetings'
[08:59] <Aloha> norsetto, i just have dh_install in my package and not anything else. no software gets compiled
[08:59] <norsetto> gaspa: yeah, I can undersatnd, its a good excuse to have fun together though
[09:00] <norsetto> aloha: well, just make a very simple rules then, but you still need copyright, control and changelog
[09:00] <gaspa> of course. and you? what will you do?
[09:00]  * wallyweek welcomes norsetto in non-sleeping fathers club :p
[09:00] <norsetto> aloha: also, some target needs to be there (don't remember the list by heart) even though they are used, you should check the debian policy for that
[09:01] <norsetto> aloha: read that "even though they are not used"
[09:01] <Aloha> norsetto, ok thnx alot :)
[09:01] <norsetto> wallyweek: hey, its gaspa the lucky parent ;-)
[09:02] <gaspa> wallyweek: yes, i'm the one
[09:02] <TheMuso> Hey folks.
[09:02] <mok0> Hey, TheMuso
[09:02] <norsetto> aloha: you could also check some similar package to give you an idea, there are few which only ships bash scripts for instance
[09:02] <wallyweek> oh I see... this online client is a nightmare :)
[09:02] <norsetto> ué TheMuso
[09:03] <norsetto> ops, morning TheMuso
[09:03] <gaspa> norsetto: so, will you go to siena?
[09:03] <norsetto> gaspa: nope
[09:03] <gaspa> i see.
[09:04] <gaspa> norsetto: well, i think i'll go to fosdem, anyhow...
[09:05] <wallyweek> gaspa: siena?! why?
[09:07] <gaspa> wallyweek: there's the ubuntu-it meeting, this weekend.
[09:09] <wallyweek> gaspa: I can't go either but it's nice to know, thanx! :)
[09:10] <gaspa> wallyweek: uh. are you italian? or in italy?
[09:11] <wallyweek> gaspa: yes to both
[09:11] <gaspa> i see.
[10:27] <amarillion> Hey there, would anybody like to review http://revu.tauware.de/details.py?package=speed-game ? It's a very simple package and I've addressed all previously reported issues. It's been 10 days since the last review.
[10:32] <foolano> ScottK: r u around?
[11:01] <slytherin> Can anyone please review this debdiff before I actually attach it to a bug. http://paste.ubuntu.com/3827/
[11:02] <persia> slytherin: What level of review do you seek?
[11:03] <man-di> slytherin: BTW: have you had time to look into that axis bug?
[11:04] <slytherin> persia: I was not sure how to set a variable's value with command substitution in rules file and then use that variable. So I have used command substitution twice where needed.
[11:05] <slytherin> man-di: Nope. Couldn't find what exactly the reason was. I will have to take a detailed look in the error.
[11:05] <man-di> slytherin: from what I saw the bug was filed because GCJ ICEd on building
[11:06] <persia> slytherin: At a base level, I think you want $(shell <command>) rather than `<command>` in a makefile, and I don't believe in minor standard version bumps when updating Debian packages: this is only worthwhile if you get the ancient-standards-version report, and feel like cleaning all the cruft.  3.7.2 -> 3.7.3 just adds noise to the patch and confuses MoM.
[11:06] <man-di> slytherin: when you can build the package that is fixed already
[11:06] <slytherin> man-di: I will try today
[11:06] <persia> slytherin: For setting a variable, just use $(shell ...).  Whether to use = or := depends on whether the result changes during the interpretation.
[11:07] <man-di> slytherin: thanks, I think that bug can just get closed
[11:07] <slytherin> persia: Ok. Will remove version bump. And also use $(shell command). But then how to use that variable? $(var)?
[11:09] <persia> slytherin: OK.  Assuming you want to set the variable once at parse time (to avoid multiple calls), you'd use MY_VAR := $(shell <shell command>).  You can also use curly braces if you find that less confusing.
[11:09] <slytherin> persia: Done that. And then how to use that variable where the value needs to be substituted?
[11:10] <persia> Then, you can use $(MY_VAR) later in the makefile to call it.  If you use :=, be sure to define before using.  If you use =, it is less strict (but produces multiple calls).
[11:10] <persia> slytherin: Sorry.  I'm not the fastest typist :)
[11:10] <slytherin> persia: oops, sorry. I thought you didn't understand my question
[11:12] <\sh> soren, any clue why bochs ftbfs at configure stage with checking for default gui on this platform... x11
[11:12] <\sh> ERROR: X windows gui was selected, but X windows libraries were not found.
[11:13] <persia> slytherin: I just tend to be wordy, and there's this annoying 256 character limit imposed by freenode that often keeps me from using paragraphs properly.
[11:13] <persia> (or maybe it's 255 characters: I never actually counted)
[11:14] <slytherin> persia: By the way, I am not sure if the patch actually fixed the bug. It just installed extension at proper place. I have not actually tried the package to check if there are any ABI compatibility problems.
[11:15] <persia> slytherin: Good to test things before uploading :)  Also, please shift to $(shell).  Using escape characters to convince make to run shell scripts is less than ideal.
[11:15] <slytherin> persia: Do you have hardy running at this point of time? I am in office and can't test the package. :-(
[11:16] <warp10> I was looking at http://packages.qa.debian.org/d/dialign-t-doc.html . This package is not in Ubuntu and I would like to request a sync. It is in non-free, but I don't understand why, since it is under LGPL. Any idea?
[11:16] <persia> slytherin: Yes, but I've a larger queue that I am confident I can process before I next sleep.  You'll have better luck with another tester.
[11:18] <slytherin> persia: Ok. If I don't find anyone I will test it tonight at home and then submit the fix tomorrow.
[11:19]  * pochu wonders whether Hobbsee plans to write something regarding her application to the MC...
[11:21] <slytherin> Is anyone willing to test a fix for nautilus-open-terminal? I don't have access to a hardy system at present.
[11:23]  * DaveMorris asks persia nicely if he'd have time to review his OpenSG package again some time soon
[11:24] <persia> DaveMorris: I'll start a build overnight, and try to take a look tomorrow.  Has nobody else reviewed it?
[11:25] <DaveMorris> no
[11:25] <DaveMorris> people tend to pick the smaller packages
[11:25]  * persia encourages someone else to review opensg, as only one reviewer doesn't tend to make the best quality package
[11:27] <norsetto> warp10: I didn't check it but it could [build-]depend on something in non-free
[11:27] <persia> DaveMorris: You've not the biggest.  Take a look at the urbanterror candidate :)
[11:27] <soren> \sh: Just a wild guess: Because you don't have x11 development packages installed?
[11:28] <DaveMorris> persia: that looks like it has a sane build system though :)
[11:28] <\sh> soren, libx11-dev is in b-d :)
[11:28] <warp10> norsetto: I checked it before asking here: it just build-depends on debhelper, depends on ${misc:Depends} and suggests dialign-t (in main and universe).
[11:28] <\sh> soren, well, it's the new debian upstream package...where your changes are applied :)
[11:29] <soren> \sh: Ah, nice.
[11:30] <\sh> soren, but the problem occured now..
[11:30]  * soren is looking
[11:31] <\sh> soren, cool thx
[11:32] <persia> warp10: I'd guess it's considered non-free because there doesn't appear to be any source file for the PDF/ps/html docs.  Just a wild guess, though.
[11:33] <soren> \sh: Builds fine in my sbuild.
[11:33] <soren> \sh: Are you on amd64 or i386?
[11:33] <warp10> persia: mmm... maybe that's the issue. I'll try to contact the maintainer, he should know about that
[11:33]  * soren high-fives dholbach
[11:34] <\sh> soren, amd64
[11:34] <soren> \sh: Me too.
[11:35] <persia> warp10: Check the changelog.  I suspect that it would make sense to drop the package, and restore the upstream tarball in dialign-t, rather than just moving to universe.  Of course, this is only worthwhile if you plan to maintain the fork.  If you just want to be a user, bests to leave in multiverse.
[11:35] <\sh> soren, oh fun...what could that be
[11:35] <dholbach> soren: what about? :)
[11:35] <soren> dholbach: Because everything is *awesome*!
[11:36] <soren> \sh: Are you building in pbuilder or sbuild?
[11:36] <\sh> soren, sbuild
[11:36] <dholbach> soren: OK, I think I can agree with you :))
[11:36] <proppy> hi
[11:36] <\sh> soren, I can check against pbuilder
[11:36] <soren> To be fair, my sbuild is slightly out of date.
[11:36] <soren> Well, my chroots are.
[11:37] <soren> Dear TeX-maintainers. Please use triggers. kthxbye
[11:38] <warp10> persia: well, I don't like to increase our delta with debian, but that could be a good idea, since I am greatly interested in having that package in good shape in Ubuntu.
[11:38] <\sh> soren, update ;)
[11:39] <soren> It's running, it's running, I've just got... erm... let's just say "a few" schroots.
[11:39] <\sh> soren, are you using local archive mirrors, just as I do?
[11:40] <soren> \sh: apt-cacher
[11:40] <persia> warp10: Keeping close to Debian is largely a way to reduce the amount of work that MOTU needs to do.  If you want to commit coordination for that package, you might split it.  On the other hand, I don't think we allow non-built-from-source docs in universe either: check with an archive admin.
[11:41] <soren> \sh: rebuilding with fresh chroot.
[11:42] <\sh> ah
[11:43] <\sh> well libx11-dev should be enough for with-x11
[11:44] <warp10> persia: I'll surely do that, but I would like to ask to debian first, maybe there are additional reasons for putting that package in non-free.
[11:44] <soren> \sh: It still builds fine here.
[11:45] <\sh> hmmm
[11:45] <\sh> I just recreated the chroot this morning
[11:47] <\sh> soren, can you send me your build log please?
[11:47] <\sh> I wonder what's wrong here
[11:50] <norsetto> hey proppy!
[11:50] <norsetto> heya dholbach ...
[11:50] <dholbach> hey norsetto
[11:51]  * proppy hugs norsetto
[11:51]  * proppy hugs dholbach
[11:51] <norsetto> whats up dholbach? You seem unusually depressed!?
[11:51] <norsetto> proppy: any new spec in preparation? Any linux-unfriendly software being packed? :-)
[11:52] <dholbach> norsetto: errrrr? :)
[11:52] <dholbach> norsetto: not really :-)
[11:52]  * dholbach hugs norsetto and proppy
[11:52] <norsetto> dholbach: good ... you had me worried
[11:52] <proppy> norsetto: was in a big hole that poped up just today :)
[11:52] <dholbach> norsetto: why? what happened?
[11:53] <norsetto> dholbach: I mean, that you seemeed not ok
[11:53] <proppy> norsetto: I'm happy our spec got implemented :)
[11:53] <proppy> norsetto: and juce packaging still waiting for upstream feedback
[11:53] <norsetto> proppy: a hole? ok, your company discovered you and got rid of you even before it disapperead?
[11:55]  * Kmos hugs norsetto & dholbach
[11:55] <proppy> norsetto: kinda like that, we've setup specifications and meetings for a no budget response in the end :)
[11:55] <soren> \sh: I kind of killed it before it finished. You said it died during configure..
[11:55] <dholbach> hey Kmos
[11:55] <\sh> soren, yepp
[11:55] <norsetto> hi kmos
[11:56] <Kmos> norsetto: won't you candidate to motu council member?
[11:56] <norsetto> kmos: nope
[11:57] <\sh> soren, trying with an i386 chroot now
[11:57] <Kmos> norsetto: i think you have a good place there :)
[11:58] <norsetto> kmos: there are much better people than me for that, believe me ;-)
[11:58] <Kmos> norsetto: and one is you :) hehe
[11:59] <\sh> soren, the same...checking for X ... no and then failing at checking for default gui on this platform... x11
[11:59] <\sh> ERROR: X windows gui was selected, but X windows libraries were not found.
[12:01] <persia> \sh: Have you tried using debuild under schroot -c foo?  You may find that you can more easily understand the issue when you are exploring the existing build.  There's also the --purge=never argument to sbuild if you like.
[12:02] <\sh> persia, I'm checking against pbuilder now, and push a testpackage to my ppa...
[12:03] <persia> \sh: You can get a pretty close simulation of the PPA if you download the buildd chroot tarball from launchpad, and use that to prep your schroot.
[12:04] <soren> \sh: What version of bochs are you building?
[12:04] <soren> 2.3.6-2 ?
[12:04] <\sh> persia, -1
[12:05] <\sh> soren, the last one which is in sids Sources.gz
[12:05] <persia> \sh: ?
[12:05] <soren> 2.3.6-2 ?
[12:05] <soren> (!)
[12:05] <\sh> nope 2.3.6-2
[12:05] <\sh> aehm
[12:05] <\sh> nope 2.3.6-1
[12:05] <soren> That's not the last on in sids Sources.gz.
[12:05] <\sh> it's sids Sources.gz from this morning actually
[12:06] <soren> quit living in the past already! :)
[12:06] <\sh> getsid.sh --update ;()
[12:08] <\sh>   * Try to use pkg-config before AC_PATH_XTRA (fixes a FTBFS). Add pkg-config
[12:08] <\sh>     to Build-Depends.
[12:08] <\sh>     - debian/patches/patches/20_use_pkg-config.patch: New file.
[12:09] <\sh> soren, YAY
[12:09] <zul> morning
[12:10] <\sh> those buggers
[12:11] <\sh> moins zul
[12:14] <\sh> ifneq ($(DEB_HOST_ARCH_CPU),i386)
[12:14] <\sh>         $(error "build-indep will only succeed on any-i386")
[12:14] <\sh> endif
[12:14] <\sh>
[12:15] <\sh> WAAA?
[12:18] <soren> That's not really unexpected.
[12:19] <\sh> soren, sure...
[12:19] <\sh> soren, I wonder what's the magic in our buildds to build at least the main bochs package
[12:20]  * persia points at bug #183495 for one way to deal with building bios packages sanely
[12:20] <ubotu> Launchpad bug 183495 in openbios-sparc "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy" [Medium,New] https://launchpad.net/bugs/183495
[12:23] <\sh> persia, I like infinities idea...
[12:24] <persia> \sh: You might want to also hit openbios then, as the person who was chasing that issue is no longer encouraged to follow up...
[12:25]  * norsetto --> lunch
[12:27] <\sh> persia, it means to introduce more packages
[12:28] <persia> \sh: Only has to be a binary package: you can leverage the existing source package.  As they are mostly dummy packages, not so much pain, no?
[12:28] <persia> Of course, how one gets an arch-all package to build-dep on a package only built on an architecture different than that of the buildd is a more interesting question...
[12:29] <\sh> persia, actually right now I'm trying to understand what it involves to get this hack ready ;)
[12:30] <\sh> persia, infinity mentions to use another (new)  source package which build-dep on the resulted binary arch dep package
[12:30] <persia> \sh: Worst case you can do something like ia32-libs, but that's non-ideal.
[12:30] <persia> \sh: Oh right.  I managed to ignore the fact that packages build-depending on themselves was bad :)
[12:32] <\sh> persia, na...what adam means is this: Package: -sparcbios Arch: sparc ... build the package on the needed archs...and introduce a new source package which generates an arch:all package . the Arch:all can actually only be generated on the sparc arch because of the build-dep on the arch dep bianry package
[12:32] <\sh> now I need some crack
[12:32] <persia> \sh: That doesn't solve the problem.  The arch:all package needs to be able to be generated on an arbitraty arch, or else it still needs handholding.
[12:33] <persia> I suspect that's the same sort of issue you're encountering with bochsbios, that you're not using the same architecture for building the arch:all package as Soyuz, but that shouldn't break the build.
[12:33] <\sh> persia, so how can a i386 buildd include a _sparc.deb
[12:33] <persia> \sh: Without internet access?  That's the hackish bit...
[12:34] <persia> ia32-libs chose to do this with internet access at packaging time, but I'm not convinced that's really a source package.  I don't know the right solution.
[12:34] <\sh> persia, I mean more, that the i386 arch needs to overwrite the behaviour apt of pulling in .deb packages for the build arch
[12:35] <persia> \sh: That's not so hard.  The hard part is getting the sparc apt-cache on i386.
[12:35] <\sh> persia, that's what I mean...or you switch for this special occasion the -A switch of sbuild on ;)
[12:36] <persia> You might check in #launchpad to see what "no internet access" really means.  There might be a way to access an archive via the network, even if not the normal archive.  You could try archive.ubuntu.com, and if that failed, fall back to the internal archive.
[12:36] <\sh> persia, and let the sparc buildd create the Arch: all package at all...it means just cp the binary of _sparc.deb build-dep to the Arch: all package
[12:36] <persia> \sh: That's significantly less trivial within wanna-build, and I suspect even more so within Soyuz.
[12:36] <pochu> Hobbsee: will you write something regarding your MC application?
[12:37] <Hobbsee> pochu: probably, when i get inspired.  if getting inspired doesn't become before the end of the voting, then no :P
[12:37]  * persia suspects Hobbsee of having a secret alien agenda, which is hard to describe in mere human languages
[12:38] <\sh> persia, I think I'll talk to adam because he knows a lot about his buildd ... well I could also ask lamont...
[12:39] <Hobbsee> persia: or involving a lot of beeping
[12:39] <persia> \sh: That works too.  I suggest #launchpad, as I believe in teams, and someone else might know too.
[12:39] <persia> Hobbsee: heh
[12:42] <psicus78> hello!
[12:43] <\sh> persia, see #launchpad ;)
[12:43] <psicus78> I'v tried to compile glib2.0 2.15.3 for gutsy in using PPA, everything worked fine and I was able to install but now I have this weird situation:
[12:43] <psicus78> gabriele@nicholas:/var/cache/apt$ apt-cache policy libglib2.0-0
[12:43] <psicus78> libglib2.0-0:
[12:43] <psicus78>   Installato: 2.15.3-0ubuntu1~psicus2
[12:43] <psicus78>   Candidato: 2.15.3-0ubuntu1~psicus2
[12:43] <psicus78>   Tabella versione:
[12:43] <psicus78>      2.15.3-0ubuntu1~psicus2 0
[12:43] <psicus78>         500 http://ppa.launchpad.net gutsy/main Packages
[12:43] <psicus78>  *** 2.15.3-0ubuntu1~psicus2 0
[12:43] <psicus78>         100 /var/lib/dpkg/status
[12:43] <persia> !pastebin
[12:43] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[12:43] <psicus78>      2.14.1-1ubuntu1 0
[12:43] <psicus78>         500 http://it.archive.ubuntu.com gutsy/main Packages
[12:44] <psicus78> and the update manager keeps asking me to update it!
[12:44] <psicus78> ops, sorry about that
[12:45] <psicus78> http://paste.ubuntu-nl.org/53299/
[12:45] <persia> psicus78: Usually indicates an issue with keys or repos.  Since you signed it, check to make sure you trust your PPA.  If not, ask in #launchpad (we don't really handle either glib or PPAs here)
[12:46] <psicus78> ok, thanks
[12:46] <zul> Hobbsee: if your write-up has a lot of click sounds like the bushmen do then I would vote for you
[12:46] <slytherin> persia: Just FYI ... I tested the package with the help of another user and attached the debdiff to bug 185435
[12:46] <persia> \sh: Maybe lunchtime?
[12:46] <ubotu> Launchpad bug 185435 in nautilus-open-terminal "nautilus-open-terminal no longer works in Hardy" [Low,Confirmed] https://launchpad.net/bugs/185435
[12:46] <persia> slytherin: Excellent.
[12:47] <persia> zul: Do you think there are sufficient devs who read !Kung?
[12:47] <\sh> persia, well, irc backlogs are nice :) need to re-enable them in my dircproxy
[12:47] <zul> persia: probably :)
[12:47]  * persia tends to wait for the turn of the hour, and rely on irclogs.ubuntu.com
[12:48] <Hobbsee> persia: that's a launchpad bug.
[12:48] <Hobbsee> psicus78: you'll have to wait for launchpad to fix their bug - it's known
[12:48] <persia> Hobbsee: poor support for !Kung, or the key issue?
[12:48] <Hobbsee> persia: glibc probably has a predepend
[12:48] <Hobbsee> persia: which makes it forever try to reinstall
[12:49] <StevenK> libc6 itself doesn't
[12:50] <psicus78> Hobbsee: do you know the bug #?
[12:51] <Hobbsee> psicus78: https://bugs.edge.launchpad.net/soyuz/+bug/165230
[12:51] <ubotu> Launchpad bug 165230 in mythbuntu "PPA generates an endlessly upgrading package" [Low,Confirmed]
[12:51] <psicus78> Hobbsee: thanks
[12:52] <Hobbsee> ...apparently that's a low bug now.
[12:52] <Hobbsee> oh, in myth.  right
[12:53] <\sh> moins ivoks
[12:53] <StevenK> The fix is commited. Maybe it was rolled out with 1.2.1?
[12:55] <Hobbsee> hm, yeah, should be now
[12:56] <Hobbsee> but i'd imagine it only works for packages that have been built and published and all that after the rollout
[12:56] <StevenK> So they probably just need to be re-uploaded?
[13:00] <Hobbsee> yeah
[13:01] <psicus78> I built my package yesterday
[13:01] <psicus78> when was 1.2.1 released?
[13:02] <StevenK> Today
[13:02] <StevenK> About six hours ago
[13:07] <psicus78> great! :)
[13:10] <effie_jayx> I get this 404 when I try to do a uscan for a watchfile uscan warning: In watchfile debian/watch, reading webpage
[13:10] <effie_jayx>   http://qa.debian.org/watch/sf.php/medit/ failed: 404 Not Found
[13:10]  * effie_jayx is doing the recipe
[13:11] <Kmos> effie_jayx: try just http://sf.net/projects/medit/
[13:11] <effie_jayx> ok
[13:12] <effie_jayx> uscan warning: Filename pattern missing version delimiters ()
[13:12] <Kmos> effie_jayx: man uscan
[13:13] <persia> effie_jayx: You need to specify a perl-style regex to search for the version.  While the sf.net shorycut is handy, it is not alone sufficient.
[13:13]  * persia feeds Soyuz
[13:14] <effie_jayx> well at first I did try http://sf.net/medit/mooedit-(.*).tar.bz2, like the recipe said... and it just gave me an error
[13:14] <persia> What error?
[13:14] <effie_jayx> persia,  the first one I pasted
[13:15] <persia> effie_jayx: Maybe the debian mirror doesn't handle that package :(  You might need to try something else.  I'm not sure.
[13:15] <effie_jayx> persia,  shall try
[13:16] <psicus78> it was probably due to Binary::Breaks field in control file
[13:16] <psicus78> I'll check
[13:17] <ScottK> foolano: Here now.
[13:29] <\sh> soren, what do you think of changing bochs src package to something like this: Package: bochsbios-i386 Arch: i386 so it builds on a i386 and generates a deb, and creating a new source package named bochbios, which creates a Package: bochsbios Arch: all?
[13:30] <\sh> soren, which means we are using a similiar way like ia32-libs
[13:30] <emgent> heya
[13:32] <mruiz> hi all
[13:33] <soren> \sh: Why?
[13:33] <effie_jayx> I am trying to find a real case for me to work on http://qa.ubuntuwire.com/uehs/no_watch.php.  I take it for granted I must use apt-get source package... https://wiki.ubuntu.com/PackagingGuide/Howtos/DebianWatch only mentions downloading by hand
[13:33] <\sh> soren, because right now, the package will FTBFS on all other archs then i386
[13:33] <soren> \sh: I've been thinking about doing something along those lines for openhackware, but why for bochs? We build arch-all packages on i386 anyway
[13:34] <soren> \sh: No.
[13:34] <soren> \sh: binary-indep will fail. That's fine.
[13:34] <soren> \sh: Well, it would be better if it didn't, but make your proposed change doesn't fix anything for anyone
[13:34] <\sh> soren, so the buildds are ignoring this and creating the other packages for Arch: any?
[13:35] <soren> \sh: Er.. Yes. That's how it works.
[13:35] <soren> \sh: We only pass -A to sbuild on i386.
[13:35] <soren> \sh: ..so on non-i386 binary-indep never gets invoked.
[13:37] <\sh> soren, ok...so only openbios-sparc is special in this case
[13:37] <soren> \sh: How so?
[13:37] <\sh> https://bugs.edge.launchpad.net/ubuntu/+source/openbios-sparc/+bug/183495
[13:37] <ubotu> Launchpad bug 183495 in openbios-sparc "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy" [Medium,New]
[13:38]  * persia thinks it's a bug if an arch:all package only builds on one architecture, even if it happens to be the one Soyuz uses to build arch-all today.
[13:38] <soren> It has never built.
[13:38] <soren> persia: Suggestions?
[13:38] <soren> \sh: And it's the same for openhackware.
[13:38] <\sh> soren, right
[13:39] <soren> \sh: So not "only openbios-sparc".
[13:39] <persia> soren: There's the hackish source-in-binary used by e.g. palo or ia32-libs.  I hoped there was an internal archive that the build might be able to access via a specially coded failover for a wget call.  Maybe Soyuz could grow a special arch-hint file for packages that need be built on specific architectures.  Nothing clean.
[13:40] <slangasek> soren: because it's an arch: all package that can only be built with the sparc toolchain
[13:40] <soren> slangasek: What question are you answering?
[13:40] <persia> s/source-in-binary/binary-in-source/
[13:40] <slangasek> soren: the "how is openbios-sparc special", sorry if I'm late to the party :)
[13:41] <soren> slangasek: I was just curious why -- since I had only moments before mentioned openhackware -- this problem was an "only openbios-sparc" thing.
[13:41] <slangasek> right
[13:41] <soren> Which it wasn't.
[13:41]  * slangasek nods
[13:42] <\sh> now, slangasek joined our party, we can work on a solution for these packages in general ;)
[13:42] <slangasek> none of the solutions are very good
[13:43] <soren> An ia32-libs sort of approach is the best bet without changing stuff in the policy and on the buildd's.
[13:43] <slangasek> you can cheat and build an arch: all package in the binary-arch target of a package that has other arch: any packages
[13:43] <slangasek> you can shove binaries in your source <bleurgh>
[13:43] <slangasek> you can build-depend on a cross-compiler
[13:45] <slangasek> you can get someone to hotwire launchpad to allow weird affinities for particular arch: all packages
[13:45] <\sh> I like the cross-compiler approach ;)
[13:45] <slangasek> we don't currently package those
[13:45] <soren> The correctest solution involves adding a hint to debian/control about where to build it and make the soyuz "get it".
[13:46] <\sh> slangasek, yeah..that's the fun part ...
[13:46] <\sh> soren, you mean to give soyuz a hint where to switch to -A mode
[13:48] <soren> Something like that, yes.
[13:48] <soren> Maybe a hint in PAS?
[13:48] <persia> I really like the cheating solution: building the arch:all package in the binary-arch target, and relying on P-a-s to keep it off the FTBFS page (along with a bug against Soyuz to do something more intelligent).
[13:49]  * \sh wonders what the new-to-me abbreviation of PAS/P-a-s  means?
[13:49]  * persia notes that one could cheat further, and call it arch: sparc in debian/control, yet nonetheless produce an _all.deb (although this breaks the policy about debian/control actually describing the package).
[13:50]  * soren shudders
[13:50] <StevenK> \sh: Packages-arch-specific
[13:50] <StevenK> \sh: Don't build packages on arch x
[13:50] <persia> \sh: It's the hints file to explain to the buildds which packages shouldn't be built on which architectures
[13:50] <slangasek> soren: not currently supported as part of the P-a-s file format; I don't see the value of extending that, vs. making it a soyuz-specific thing or putting it in the source package
[13:51] <slangasek> soren: in particular, since this problem affects Ubuntu && !Debian, and Debian shares P-a-s with Ubuntu
[13:51] <soren> slangasek: P-a-s is not covered by Debian Policy, is it?
[13:51] <slangasek> no, but you lose the benefit of being able to share the file between the two dists if only the tools in one dist are upgraded to cope with your format changes
[13:52] <soren> slangasek: Er... We'd have to make changes to *other* tools to do it the other way.
[13:52] <soren> slangasek: Same difference, AFAICs.
[13:52] <ScottK2> slangasek: Which would be a lot easier to deal with if one distro didn't use a proprietary tool set.
[13:52] <persia> slangasek: We currently can't share the source, due to it working fine in Debian (the equivalant Debian bug was rejected)
[13:52] <slangasek> persia: note that cheating requires that there *be* some other arch: any package built from the same source, otherwise it'll never get seen on the (e.g.) sparc buildd
[13:53] <persia> slangasek: Depends on how much one cheats, and whether one lies in debian/control.
[13:53] <slangasek> soren: eh, no; it *is* different, because one involves making changes to core Debian infrastructure as a precondition of continuing to be able to share data
[13:53] <slangasek> soren: and the other involves either a soyuz-local override file, or Ubuntu-local changes for the small set of affected source packages
[13:53] <soren> slangasek: Would maintaining a tiny delta to that file really be so completely awful that we're willing to do massively nasty things basically everywhere else than there?
[13:54] <soren> slangasek: Well, yes, it could be in a separate file, I guess.
[13:54] <slangasek> soren: yes - it doubles the work required for every update, because every update would become a merge
[13:54] <soren> slangasek: ...which wouldn't require changes to the source packages.
[13:54]  * Hobbsee celebrates the deletion in ppas
[13:54] <soren> slangasek: Yes.. That would be the case for dpkg updates, too, if this were to become a field in debian/control.
[13:55] <soren> dpkg is already a merge every time, though.
[13:55] <soren> ...but that's a bit beside the point
[13:55] <slangasek> it's not beside the point
[13:55] <slangasek> that *is* the point
[13:55] <StevenK> Hobbsee: You'll celebrate by deleting a package?
[13:55] <Hobbsee> yeah
[13:55] <persia> Hobbsee: Can we delete other people's packages yet?
[13:56] <Hobbsee> persia: doubt it
[13:56] <TheMuso> I thought that PPA UI for deleting packages was only on staging... Or has that now changed?
[13:56] <soren> slangasek: Maybe I'm underestimating the amount of changes to P-a-s.
[13:56] <ScottK2> Can any team member delete team PPA packages?
[13:56] <soren> slangasek: How often does it change?
[13:56] <StevenK> ScottK2: Yup
[13:56] <StevenK> ScottK2: I was able to select ubuntu-mobile packages to delete. I didn't actually try, though
[13:56] <ScottK2> Excellent.
[13:57] <slangasek> soren: I'd estimate an average of 4-5 changes per month
[13:57]  * ScottK2 goes to look for teams to join he doesn't like.
[13:57] <TheMuso> lol
[13:57] <slangasek> soren: and it's maintained in CVS, so merges == death :)
[13:57] <soren> slangasek: The complexity of the delta in question is also quite relevant.
[13:57] <soren> Oh.
[13:57] <soren> I didn't realise.
[14:00]  * slytherin is happy to be finally able to clean up his PPA. :-)
[14:00]  * persia is glad to finally be able to use a PPA without significant fear
[14:00] <TheMuso> yaaay! Its on edge.
[14:01] <StevenK> TheMuso: I said that about five minutes ago
[14:01] <persia> StevenK: You didn't say "yaaay!".  Without the magic words, meaning is less clear :)
[14:01] <StevenK> Haha
[14:02] <\sh> somehow my gnome is now scking more then ever
[14:02] <persia> \sh: scary nautilus change maybe?
[14:02] <\sh> for every sbuild start it shows me the dynamically created lvm device on my screen
[14:03] <\sh> the same for everything else what involves lvm appearing
[14:03] <persia> \sh: Open more windows in the forground, and maybe you won't notice :)
[14:03] <\sh> persia, lol
[14:03] <slytherin> Can anyone tell me if anyone is working on bug 184278. There are at least 3 packages in depwait state in multiverse due to this.
[14:03] <ubotu> Launchpad bug 184278 in ubuntu "[Sync request] Please sync aspectwerkz2 2.0.dfsg.1-2 (universe) from Debian unstable (contrib)" [Wishlist,Confirmed] https://launchpad.net/bugs/184278
[14:04] <\sh> what are lvm devices? hotplug or change media?
[14:04] <persia> slytherin: It's in all the right queues.  Just waiting for an archive admin to get to it.
[14:04] <slytherin> persia: Ok. Thanks for info. :-)
[14:05] <\sh> damn...gnome's broken
[14:06] <\sh> I can't work like that ;)
[14:07] <TheMuso> Although I seem to be getting the something went wrong message/.
[14:10] <\sh> bddebian <--- Da God is in da house
[14:10] <StevenK> \sh: Must you?
[14:10] <StevenK> :-P
[14:10] <vorian> ScottK: just 2.3- ?   :)
[14:11] <bddebian> Heya gang
[14:11] <bddebian> Heh, heya \sh
[14:11] <ScottK> vorian: Yes.
[14:11] <vorian> thanks
[14:11] <\sh> StevenK, why not for gods sake ;)
[14:11] <ScottK> vorian: FYI for the future, pysupport and pycentral have different pyversions syntax.
[14:11] <ScottK> bddebian: Heya.
[14:11] <bddebian> Hi ScottK
[14:12] <vorian> ah, that's something i'll keep an eye on.
[14:12] <ScottK> bddebian: Please note that my fix built just fine for Ubuntu.  How's Debian going?
[14:12] <bddebian> ScottK: Well your's failed for me in Debian too but I have gotten it to work.  Though I'm not totally sure why
[14:12] <\sh> StevenK, anything against pushing octave3.0 into ubuntu? :)
[14:12] <StevenK> \sh: ENOCLUE
[14:12] <ScottK> bddebian: You built my package or made some of the same changes?
[14:13]  * persia remembers something about a missing "octave" package due to un-epoch'ing that may require special handling
[14:13] <ScottK> bddebian: Some of the stuff we were dealing with is processed differently pysupport/pycentral.
[14:13] <Hobbsee> imbrandon: ping
[14:13] <bddebian> ScottK: I built yours first and it still failed for me. :-(  I went back to mine and change the post-install call in rules to use $(MAKE) check instead of the PYTHONPATH=lib ./test_all.py
[14:14] <ScottK> Weird.
[14:14] <ScottK> Since mine built just find in my Sid pbuilder.
[14:14] <bddebian> Totally
[14:15] <ScottK> I'll just drop all your changes when the merge hits ;-)
[14:15] <bddebian> :-)
[14:16] <TheMuso> 99/c
[14:17] <\sh> StevenK, I thought asking the last uploader of plplot ;)
[14:17] <StevenK> Yeah, not gonna help
[14:18] <Hobbsee> siretart: ping
[14:26] <\sh> oh mk-sbuild-lv needs also more love
[14:26] <\sh> itdoesn't work by default for debian
[14:32]  * siretart goes and fetches table tennis equipment
[14:34]  * siretart gives Hobbsee a racket and plays a service
[14:34] <Hobbsee> hehe :)
[14:34]  * Hobbsee hits the ball back
[14:34] <foolano> ScottK: regarding the libtree-perl package. I can't manage to build the package and get the /usr/lib/perl5/auto/Tree  directory that you told me shouldn't be there
[14:34] <siretart> \sh: oh yes, it would be great if someone could fix that. until then I'm using that: http://wiki.tauware.de/misc:create-chroot
[14:35] <ScottK> foolano: I'll look at it again.
[14:36] <foolano> my build is clean and doesn't have that
[14:36] <\sh> siretart, why not replacing it with mk-sbuild-lv?
[14:36] <ScottK2> foolano: How are you building it?
[14:36] <ScottK2> foolano: It's definitely there in the .deb that I built.
[14:36] <foolano> ScottK: dpkg-buildpackage
[14:37] <\sh> siretart, adding some more love to /etc/schroot/schroot.conf and all is fine ;)
[14:37] <ScottK2> foolano: I'm building it in a hardy pbuilder.
[14:37] <foolano> ok
[14:37] <foolano> gonna try that
[14:37] <siretart> \sh: a) it still needs work, b) it does not preserve the same semantics as mk-sbuild-lv. I don't want to break other ppls systems
[14:39] <\sh> siretart, do you know if this what I'm trying in http://pastebin.ubuntu.com/3831/ is possible?
[14:39] <DaveMorris> hmm, PPA now has a delete package but you can't remove whats in the published archive :/
[14:39] <\sh> argl..old version
[14:40] <\sh> siretart, anyways...forget it...I'm trying to exaplain...I'm generating a string RELEASE with all releases of debootstrap/scripts/ ... and add a "|" in between the release names..to have something I can feed to case $foo in
[14:41] <\sh> siretart, now case $foo in ; $RELEASE ) echo "match" ;; *) ;; esac should work...but it doesn't
[14:41] <siretart> \sh: use python? ;)
[14:42] <\sh> siretart, hehe...
[14:42] <Adri2000> Hobbsee: where is your MC application wiki page?
[14:42] <\sh> siretart, pbuilder-dist replacement, because our version is totally borked
[14:42] <Hobbsee> Adri2000: on mars.
[14:43]  * siretart is an sbuild fanboy. so any pbuilder rants are welcome here :)
[14:43] <Adri2000> Hobbsee: is there a planned return to Earth?
[14:44]  * Hobbsee resides on jupiter, so
[14:44] <zul> isnt it a bit hot there?
[14:45]  * Hobbsee is a green alien, and doesn't feel heat.
[14:47] <Adri2000> Hobbsee: more seriously, are you going to write one?
[14:47] <Hobbsee> Adri2000: unsure yet.
[14:48] <pochu> It would help us to decide who to vote :)
[14:48] <Hobbsee> don't vote for me :P
[14:49] <ScottK2> Hobbsee has a strong base in the grumpy motu faction.
[14:49] <\sh> how many MC members do we need? 2 or 3?
[14:49] <pochu> \sh: 2
[14:50] <pochu> \sh: If they were 3, a poll would be a bit useless ;)
[14:50] <DaveMorris> pochu: would you appoint someone with no votes?
[14:51] <StevenK> ScottK2: Which is you, and who else?
[14:51] <foolano> ScottK2: regarding the license. Upstream just says that it can be distributed under the same terms as perl itself. So do you really think that I should include the GPLv1 license in the copyright file?
[14:51] <StevenK> bddebian doesn't count, he's only grumpy at himself
[14:51] <\sh> pochu, well it doesn't make sense if you can vote for all three, then...and this is possible by now ;)
[14:51] <pochu> DaveMorris: or with a negative count? ;)
[14:51] <ScottK2> foolano: Yes, because Perl is GPL v1 and later.
[14:52] <foolano> ScottK2: alright then :)
[14:52] <ScottK2> foolano: I suspect your empty dir problem is Perl tool chain related.  I built your package in my Dapper pbuilder and didn't get the empty dir.
[14:52] <bddebian> I can be grumpy :-)
[14:52] <ScottK2> Excellent
[14:53] <gaspa> StevenK: who's supposed to create vboxusers group?
[14:53] <StevenK> The virtualbox-ose package itself
[14:53] <foolano> ScottK2: i'm creating the a Hardy pbuilder
[14:53] <gaspa> mmm
[14:55] <gaspa> StevenK: ah, ok. it just don't work in the installing shell.
[14:56] <ScottK2> foolano: The problem is that your new rule to remove .packlist removes the file, but leaves the directory it was in.
[14:56] <foolano> yeah. I see.  Though I think its a sync ...
[15:18] <vorian> ScottK: same result
[15:18] <vorian> :)
[15:18] <\sh> hellboy195, do it :)
[15:18] <ScottK> vorian: OK.  Now how about man page that's actually useful (as in tells how to use the program).
[15:18] <hellboy195> \sh: k, thx :)
[15:19] <ScottK> pkern: Good afternoon.
[15:19] <ScottK> vorian: Why did you change the build-dep version on Python?
[15:19] <\sh> hellboy195, just pin a "building or working" next to it, so I don't catch it...after you finished and determine what it is, just pin the bug number or uploaded behind it on DaD please :)
[15:19] <vorian> ScottK: all-dev?
[15:20] <ScottK> vorian: Yes.  It was 2.3 something and you changed it to 2.5?
[15:20] <vorian> ah, mistake
[15:20] <vorian> sorry about that
[15:20] <hellboy195> \sh: yes. np
[15:20] <\sh> pkern, would you like to merge new network-manager-openvpn ? :)
[15:21]  * pkern hates n-m.  Especially because the Ubuntean n-m maintainers refused some changes to improve the openvpn experience.
[15:22] <\sh> pkern, just asking because you were the last uploader :)
[15:23] <doko> pkern: ?
[15:24] <pkern> doko: You reused the version already in the archive, but you already got notified.  Any reason why you did not file a bug about it?  I could have merged it upstream and fixed in Debian, too.  Like this I only got to know that there might be an issue (I still don't know the patch) because your upload got rejected.
[15:25] <doko> pkern: sure, you can fix it
[15:26] <pkern> I don't even know the problem.  I would have responded promptly to a bug report or a Trac entry.  Like this the Ubuntu delta got increased.   I write the bug number with the "bug #xxxxx" syntax in the comment field but if I leave the site and return the comment field is cleared
[15:31] <\sh> hellboy195, press enter after you wrote it ;)
[15:32] <hellboy195> \sh: omg. thx.   A build-dep on python appears to be sufficient.
[15:39] <vorian> alrighty ScottK :)
[15:39]  * vorian is typing away on the manpage
[15:43] <pkern> doko: Your gobby package, not your patch itself.
[15:45] <jdong> anyone heard any news if there's people packaging "tovid"?
[15:47] <LucidFox> jdong> well, I just learned about its existence
[15:47] <LucidFox> but searching Launchpad, Debian and debian-multimedia.org turns nothing
[15:48] <LucidFox> the official site has debs, but no source package
[15:57] <jdong> LucidFox: 2 years ago, I  once pseudo debianized the package for upstream. I wonder if they're using that, or checkinstall...
[15:57] <jdong> LucidFox: I mean it certainly wasn't up to the quality standards of us, but it at least wouldn't break APT :D
[15:58] <\sh> I wonder how packages are getting build in debian, which such enormous FTBFS rate because of not using newer API of special libs
[15:59] <LucidFox> I could package tovid myself
[16:01] <jdong> LucidFox: the only thing I'm not sure of right now are its dependencies
[16:01] <jdong> LucidFox: it has flags for using both mjpegtools and ffmpeg as encoding backends...
[16:02] <jdong> might be a package for medibuntu at this rate :)
[16:02] <jdong> but yeah, if you're willing to take a look at packaging it, that'd be sweet and I'm sure upstream would appreciate it
[16:02] <LucidFox> The GUI needs python-wxgtk2.6
[16:03] <LucidFox> And mjpegtools is in the archive, it's ffmpeg that could pose problem because the Ubuntu version is castrated :)
[16:04] <jdong> LucidFox: fortunately the ffmpeg backend isn't default, and we could nudge people in README.Debian to go towards the right repos ;-)
[16:08] <RainCT> Hi :)
[16:10] <RainCT> \sh: About the problem you had yesterday, the #bash guys told me to either use [[ =~ ]] or use a real programming language...
[16:10] <jdong> ha
[16:11] <\sh> RainCT, [[ =~ ]] in the case loop?
[16:11] <RainCT> \sh: yes
[16:11]  * jdong tries his luck advertising http://revu.tauware.de/details.py?package=clutch one last time before leaving for house shopping :)
[16:11] <emgent> argh! Angela Merkel e Bill Gats, for microsoft in Germany (PA)
[16:11] <emgent> s/e/and/
[16:12] <\sh> RainCT, something like $RELEASES =~ <what>?  ;)
[16:12] <\sh> RainCT, I don't know the syntax...never saw it
[16:13] <RainCT> \sh: [[ $1 =~ $REL ]]
[16:13] <RainCT> (2008-01-23 22:36:38) greybot: Binary operator, uses the expression on the right hand side as an extended regular expression and returns true if the expression on the left hand side matches the pattern. USE A VARIABLE to hold your regexes. eg: [[ $var =~ $r ]] && echo Match || echo 'No match'
[16:13] <\sh> RainCT, ah so it's outside the case
[16:14] <\sh> RainCT, well let's see if I have the energy to work on it today :)
[16:14] <RainCT> \sh: yes.. either put it before it or inside the *) block
[16:14] <RainCT> heh
[16:14] <\sh> RainCT, yeah, that was my other idea to use * ) for that
[16:15] <foolano> ScottK2: I've uploaded a new libtree-perl. GPL added. And it builds cleanly in my hardy pbuild
[16:15] <ScottK2> foolano: Great.  I'll have a look at it in a bit.
[16:15] <lifeless> where is the vote ?
[16:15] <foolano> ScottK2: thanks
[16:16] <LucidFox> Okay, if anyone seriously mentions Tk as the future of the Linux desktop again, I'll buy them a time machine so they can join us in 2008.
[16:17] <zul> but but but
[16:17] <Hobbsee> lifeless: for the MC?
[16:18] <\sh> lifeless, https://edge.launchpad.net/~ubuntu-dev/+polls
[16:20] <zul> are the "platforms" up for the MC election (other than Hobbsee)
[16:21] <Hobbsee> zul: platforms?
[16:21] <zul> basically what they are going to do if they are elected
[16:22] <Hobbsee> the toher 2 have
[16:22] <\sh> For me the vote system doesn't make sense...we need to elect 2 people...but a person can make 3 votes...now think about everyone is doing that...
[16:23] <ScottK> \sh: It's the first time we've had some competition, so the vote system may not really support it well.
[16:23] <Hobbsee> \sh: yeah...presumably it'll have to come out close
[16:23] <\sh> ScottK, yeah...it's more a technical problem :)
[16:24] <pkern> It's just LP...
[16:24] <ScottK> So the suckage should be a given
[16:25] <\sh> I don't file a bug for now...I want that the launchpadders are working on an xmlrpc interface ;)
[16:27] <ScottK2> Competitive elections probably need a spec to get the design right.  Ideally it's be some kind of concordance system.
[16:27] <pkern> Condorcet, yay yay.
[16:27] <Spec> competitive elections? ie: i'm a dictator?
[16:28] <ScottK> pkern: Yes.  It that other guy using my nick could spell ;-)
[16:28] <\sh> Spec,  not possible...we have sabdfl :)
[16:28] <Spec> oh, right. job filled. ;)
[16:41] <\sh> ok enough for today
[16:45] <\sh> doko, gcc toolchain 4.3 will it be for hardy+1 ?
[16:54] <LucidFox> Hmm... I seem to magnetically attract weird upstream build systems :/
[16:55] <LucidFox> now it's a Python package using automake to build and install
[16:55] <DaveMorris> LucidFox: prog created by a C/C++ programmer
[16:55] <DaveMorris> s/prog/prob
[16:56] <LucidFox> the question is what to with it... do I need python-support/python-central at all?
[16:57] <LucidFox> it installs a library into /usr/lib/python2.5/site-packages and some scripts into /usr/bin
[16:57] <ScottK2> LucidFox: Is the library in C or Python?
[16:57] <LucidFox> in Python
[16:58] <ScottK2> Then it doesn't go in site packages and you need python-support or python-central.
[16:58] <ScottK2> Version specific site-packages are only for C extensions under the new python policy.
[16:59] <LucidFox> I see.
[16:59] <LucidFox> But how do I use python-support with automake?
[16:59] <ScottK2> Dunno.  I haven't had to do it.
[17:00] <ScottK2> It may be easier to point automake at installing in the right places.
[17:00] <ScottK2> It might also be easier to write your own setup.py, slap it in the debian/dir and use that instead.
[17:12] <LucidFox> ScottK2> Using automake.mk and manually inserting a dh_pysupport call seems to have done the jub
[17:12] <ScottK2> LucidFox: Excellent.
[17:12] <LucidFox> it moved the library to /usr/share/python-support
[17:13] <ScottK2> Which is where you want it.
[17:13] <ScottK2> Does the binary package have egg-info in it?
[17:14] <LucidFox> What is egg-info, and how can I check if it does?
[17:18] <ScottK> LucidFox: Egg info is something used outside Debian to track depenencies.  Look in the .deb and see if there's an egg info file in /usr/share/pyhthon-support/packagename.
[17:18] <ScottK> foolano: libtree-perl is advocated by me.
[17:19] <ScottK> soren: libtree-perl is looking for a second advocate (ebox depends).
[17:19] <foolano>  ScottK: thx
[17:21]  * soren looks
[17:21] <LucidFox> ScottK> No, there's only .version and files installed by upstream. Grepping for egg returns nothing either.
[17:21] <ScottK> LucidFox: OK.  That's fine then.  If you have it you need a versioned depend on python-support, so that's not a concern for your package.
[17:22] <soren> ScottK: GPL1? Seriously?
[17:22] <ScottK> soren: Yes.  Perl is GPL v1 and later.
[17:22] <ScottK> soren: I got a package rejected for the lack of that.
[17:24] <soren> ScottK: "the full text of the license is in the code,"? Where?
[17:25]  * ScottK2 looks
[17:25] <foolano> I had intially looked at perl, perl-base and other perl modules...
[17:26] <soren> foolano: Where did you find it? The copyright file doesn't say (which it should :) )?
[17:27] <foolano> soren: cpan
[17:27] <ScottK2> soren: lib/Tree.pm for example.
[17:27] <foolano> i'm gonna add it then
[17:27] <ScottK2> lib/Tree/Binary.pm and lib/Tree/Fast.pm too
[17:27] <soren> ScottK2: Oh, it's got the perl snippet.
[17:28] <soren> ScottK2: Not quite "full text of the license" :)
[17:28] <ScottK2> I think it is
[17:28] <ScottK2> If Perl suddenly relicensed GPLv3 only, then that's the only terms you could distribute this with that Perl with.
[17:29] <ScottK2> Maybe I'm wrong.
[17:30] <ScottK2> soren: I'm off looking for the specific package I got burned on to see how I resolved it and got it uploaded.
[17:31] <soren> ScottK2: Grab libperl6-junction-perl.
[17:31] <soren> ScottK2: That's my preferred way to do it.
[17:31] <ScottK2> soren: You're right and I'm wrong.  I had to repack the tarball
[17:31] <ScottK2> https://launchpad.net/ubuntu/feisty/+source/libnet-dns-resolver-programmable-perl/0.002.2-0ubuntu1
[17:32] <soren> ScottK2: Let me guess: pitti was the one who reviewed it? :)
[17:32] <ScottK2> Yes.
[17:33] <soren> ScottK2: Heh..
[17:33] <ScottK2> It was my first package uploaded to Ubuntu too.
[17:34] <soren> ScottK2: Well, repacking it is ok. I wouldn't require it, but it's ok.
[17:34] <soren> foolano: You can take a peek at libperl6-junction-perl's debian/changelog.
[17:35] <foolano> alright
[17:35] <soren> foolano: I'd have accepted something like that. Well, of course I would. I made it :)
[17:35] <foolano> :P
[17:37] <foolano> should i change the copyright file and add what libperl6-junction-perl has?
[17:38] <ion_> The map <http://heh.fi/tmp/lightmap> gnome’s clock thing displays nowadays is depressing. It reminds how scarcely we get sunlight. :-)
[17:45] <soren> foolano: I would, yes.
[17:53] <pochu> Am I the only one receiving a lot of copies of the same message from motu-reviewers@ ?
[18:07] <hellboy195> mr_pouit: ping
[18:07] <ScottK2> vorian: Your upstream says pdftk is no longer required.
[18:13] <foolano> soren, ScottK2: i've just uploaded a new package. copyright is based on libperl6-junction-perl
[18:18] <\sh> oh wow...
[18:18] <\sh> we have so much to fix ;)
[18:19] <vorian> thanks ScottK :)
[18:20] <geser> \sh: what did you break? :)
[18:20] <\sh> geser, nothing...I'm fixing stuff finally ;) gcc4.3 bugs and some build system bugs like setup.py with shebang against 2.4 ,-)
[18:23] <LucidFox> jdong> I've uploaded a preliminary tovid package, it's still a WIP because there are lintian warnings; will continue tomorrow
[18:23] <jdong> LucidFox: wow
[18:23] <jdong> LucidFox: nice :)
[18:24] <LucidFox> in the meantime, while I'm asleep, could you look at the avidemux upgrade bug? :)
[18:24] <jdong> LucidFox: if I get a chance sure, I've got a doctor appointment and I don't know how long that'll take
[18:24] <LucidFox> ah
[18:25] <mr_pouit> hellboy195: pong ?
[18:26] <hellboy195> mr_pouit: do you mind 'm going the qmail merge? *asking like the guidelines tell*
[18:26] <hellboy195> *doing
[18:27] <\sh> hellboy195, I think at this time of the release cycle you don't have to ask anymore...but this is just me ;)
[18:27] <mr_pouit> hellboy195: it'll ftbfs in the buildds, but go ahead if you want ;)
[18:27] <mr_pouit> hellboy195: thanks for asking ;p
[18:28] <ScottK2> I'd say asking is stil nice, but waiting a long time isn't needed.
[18:29] <hellboy195> ok ^^, it's written on DaD and also my mentor told me to do but i'll keep that in mind
[18:29] <hellboy195> mr_pouit: ftbfs? because?
[18:29] <ScottK2> hellboy195: It's a source only package due to qmail licensing.  Up until very recently binary distribution wasn't allowed.
[18:30] <hellboy195> ah, k
[18:30] <\sh> ScottK2, should this not be worth a change?
[18:31] <ScottK2> \sh: You mean qmail?
[18:31] <\sh> ScottK, yepp
[18:32] <ScottK2> Personally, I think it's not worth the effort to mess with, but if someone want to fix up 9 year old code and make it work like a modern mail system (e.g. reject, don't bounce), it's now free software, so they should have at it.
[18:39] <\sh> ScottK2, well qmail was known because it was fast...in the 90ties I crashed a sparc sendmail system with it :) (that was the sendmail running on sun os at DENIC (the german domain registrar))
[18:40] <\sh> hey this is so annoying...sbuild start and woops..there is a new window
[18:44] <hellboy195> ScottK \sh : so. no merge/sync. What to do? leave a comment?
[18:45] <pochu> vorian: lol, I've got your comment on revu six times :)
[18:46] <vorian> pochu: yes, lesson learned *don't refresh revu*
[18:46] <vorian> :P
[18:46] <vorian> I am sorry about that
[18:46] <pochu> heh, that sounds like something to change in revu :)
[18:46] <vorian> It wont happen any more
[18:46] <somerville32> Yea, that is a bug.
[18:46] <somerville32> Does anyone know if it is already reported?
[18:46] <pochu> vorian: you aren't the first, and won't be the last one...
[18:46] <ScottK2> vorian: REVU code in on launchpad.  Patches gratefully accepted.
[18:47] <vorian> ScottK: I'll take a look see :)
[18:47] <vorian> ScottK2: the package is finished too
[18:47] <ScottK2> I'm just running out for a bit.  I'll try and have a look later.
[18:48] <vorian> ok, thanks for your guidance
[18:51] <\sh> hellboy195, even if it FTBFS .. it's a merge because the new package didn't have the fakeroot call which was added in ubuntu
[18:52] <hellboy195> \sh: so I should do the merge/LP thouch it FTBFS?
[18:52] <\sh> hellboy195, yepp..just add the debdiff to the LP bug then :)
[18:53] <\sh> hellboy195, and subscribe ubuntu-universe-sponsors
[18:53] <hellboy195> \sh: yeah I know ^^, I'll do that later. thx
[18:54] <\sh> siretart, ping
[18:54]  * siretart damaged
[18:55] <\sh> siretart, you are running gnome (on hardy) and sbuild with snapshot chroots eventually?
[18:55] <siretart> \sh: s/hardy/gutsy/, but yes
[18:56] <\sh> siretart, well...I need you running hardy and latest gnome...and snapshot chroots ... right now, I#m getting annoyed by popup windows of newly mounted LVMs (session stuff)
[18:56] <\sh> siretart, and it looks like i'm the  only one...(amd64 ;))
[18:56] <\sh> siretart, but I think it's not me alone ;)
[18:56] <siretart> \sh: oh, hardy's hal (finally) knows about LVM? neat
[18:57] <\sh> siretart, well...annoyingly yes ;)
[18:57] <siretart> \sh: in that case, gnome-volume-manager should be told to ignore lvm snapshots detected by hal
[18:57] <\sh> siretart, how?
[18:58] <\sh> siretart, I see dbus sending out messages to gvfs about it
[18:58] <\sh> siretart, and I switched off all automounting/autoshowing up of removable and hotplug media
[18:58] <siretart> \sh: please tell pitti. I think he knows enough about hal for that. maybe there is already a bugreport here?
[18:59] <\sh> let's see
[19:00] <\sh> siretart, I don't see any bugreport against hal, but the "lvm missing in hal" one...
[19:00] <\sh> but lshal gives me this:
[19:00] <\sh> shermann@home-emt64:~/packages/gcc4.3/acpitool$ lshal |grep LVM
[19:00] <\sh>   info.product = 'Volume (LVM2_member)'  (string)
[19:00] <\sh>   volume.fstype = 'LVM2_member'  (string)
[19:00] <\sh>   volume.fsversion = 'LVM2 001'  (string)
[19:01] <\sh> and points directly to my LVM enabled harddrive
[19:02] <siretart> no snapshot listed here?
[19:03] <\sh> nope
[19:04] <\sh> siretart, but I see dbus sending out messages about the snapshots...I wonder where that comes from
[19:05] <\sh> siretart, http://pastebin.ubuntu.com/3838/
[19:05] <jdong> who do I talk to in order to make my account on REVU a MOTU account?
[19:07] <ScottK> jdong: REVU admin of some kind
[19:07] <siretart> who is sender=:1.17?
[19:08] <\sh> siretart, -EDUNNO
[19:08] <\sh> siretart, but I think that's the point why hte windows are popping up like mad...
[19:09] <tuxmaniac> will pdebuild -sa include original source (it doesnt seem to)
[19:09] <siretart> jdong: done
[19:10] <jdong> siretart: thanks
[19:11] <hellboy195> Can I change a sentence in debian/changelog so that it looks better (meaning is the same) ?
[19:12] <siretart> that question is confusing
[19:13] <RainCT> \sh: btw, better use [ -z "$VAR" ] instead of [ -z $VAR ] :)
[19:13] <tuxmaniac> hellboy195, if you have used dch -i then your changelog should look beautiul by default :-)
[19:13] <hellboy195> siretart: ^^, For Example: remaining ubuntu change in ubuntu : + Adhere to DebianMaintainerField.  <-- in my mind - Modify Maintainer value to match Debian-Maintainer-Field Spec looks better ^^ Am I allowed to change it?
[19:14] <\sh> RainCT, k
[19:14]  * ScottK always just writes change maintainer to MOTU.
[19:15] <hellboy195> ScottK: ^^, yeah but do I have the RIGHT to change it if you want?
[19:15] <hellboy195> *if I want
[19:15] <\sh> siretart, any possibility to find sender 1.17?
[19:15] <ScottK> hellboy195: If it's your changelog entry, yes.  If it's a previous one, no.
[19:16] <siretart> \sh: /me no dbus guru. sorry
[19:16] <hellboy195> ScottK: that's what I wanted to know :) thx
[19:16] <ScottK> siretart: But you answered him. so by the FOSS laws of tech support, you have to solve his problem now. ;-)
[19:16] <siretart> dammit :)
[19:16] <\sh> *eg*
[19:16] <\sh> nope
[19:17] <\sh> I want to know what's happening at all.../me is no dbus/hal/whathaveyouforcorbainfrastructurehandy expert
[19:18] <siretart> hellboy195: technically, you are allowed. However, I doubt that this is a good idea and worth bothering
[19:18] <hellboy195> siretart: k ^^
[19:21] <\sh> lol googling for sender 1.17 gives me the maemo irc log snippet
[19:23] <RainCT> Can new versions of programs still get into universe after FeatureFreeze (without an exception)?
[19:25]  * RainCT thought that's an easy question :P
[19:26] <geser> RainCT: sort of, native packages with only small changes (bug fixes) doesn't necessarily need an exception
[19:26] <RainCT> geser: and non-native packages?
[19:27] <jdong> RainCT: and there's often blanketed exceptions for a bunch of core system stuff :)
[19:27] <jdong> i.e. the entire GNOME stack
[19:27] <jpatrick> and KDE stuff
[19:27] <jdong> RainCT: everything else needs a UVFe bug
[19:27] <jdong> or whatever tehy're called now
[19:28] <geser> RainCT: for non-native packages you need an exception but I don't know how the new motu-ff team will handle minor (bugfix) releases
[19:28] <superm1> jdong, and the mythbuntu stuff has a blanket too :0
[19:29] <Kano> hi, could somebody add to openscenegraph Build-Depends: libxine-dev
[19:29] <Kano> then osgmovie builds
[19:29] <Kano> with is very cool...
[19:29] <jdong> superm1: ok ok fine a lot of desktop stuff
[19:30] <jdong> superm1: now all that's missing is somerville32 telling me that xubuntu has a blanket too
[19:30] <superm1> has motu-ff been completely assigned?
[19:30] <jdong> :D
[19:30] <Kano> osgmovie dvd://1.xine --interactive
[19:30] <RainCT> okay, thanks all :)
[19:30] <jdong> lps openscengraph
[19:30] <Kano> would play first dvd movie in 3d mode and you can move, rotate, zoom it..
[19:32] <jdong> whoa why does it have like 6 control files?
[19:33] <Kano> sample files for other distros
[19:33] <Kano> you only need to change the the standard control
[19:33] <jdong> yeah, I see
[19:33] <Kano> if you like i give you a mod to compile it much faster
[19:34] <Kano> optimized rules..
[19:34] <jdong> Kano: what is the nature of the mod?
[19:34] <Kano> wait, will make a diff
[19:35] <Kano> it will fully use all cores
[19:36] <\sh> ??
[19:36] <\sh> make -m<howmany> is set in the buildd definition..DEB_MAKE_options or so
[19:37] <\sh> -m+j
[19:37] <\sh> make -j<howmany>
[19:37] <Kano> http://paste.debian.net/47617
[19:37] <zul> *sigh*
[19:37] <Kano> that counts for cores
[19:38] <jdong> I'm personally uninterested in applying that patch
[19:38] <\sh> lol
[19:38] <Kano> single core user ;)
[19:38] <\sh> wow
[19:38] <jdong> Kano: nah, dual with HT on this machine :)
[19:38] <jdong> Kano: I don't believe you counted logical processors ;-)
[19:39] <Kano> well osg really compiles very long
[19:39] <Kano> because of introspection
[19:39] <\sh> Kano, na
[19:39] <Kano> on i386 introspection is active
[19:40] <\sh> Kano, well, for the buildds is time not a problem
[19:40] <Kano> when you optimizie it fully you could compile it in 10 min with dual core..
[19:40] <\sh> Kano, just for the tester
[19:40] <jdong> the last i386 buildd took 3h40m to build it
[19:40] <Kano> if you want to test it faster disable introspection
[19:40] <jdong> nah I'm paranoid, I'll test build it as-is with libxine-dev added
[19:41] <Kano> RelWithDebInfo -> Release will give the rest of speed
[19:41] <\sh> I wonder why debian didn't add xine then
[19:41] <Kano> i dont know, i mailed the maintainer
[19:42] <Kano> maybe they dislike osgmovie *g*
[19:43] <\sh> Kano, xine was at some time already enabled
[19:44] <jdong>   * Restrict compilation of introspection and xine
[19:44] <jdong>     plugin to i386 because Introspection breaks the compiler (gcc-3.3)
[19:44] <jdong>     and xine contains i386 assembly that cannot be rewrote right
[19:44] <jdong>     away.
[19:44] <jdong> long time ago, 0.9.9 or so
[19:45] <Kano> \sh: right, the old 1.2.0 package had it
[19:46] <jdong> ooh cool, cmake  shows percentages
[19:46] <Kano> yes one of the cool things ;)
[19:46] <Kano> so the 4h will not be that boring *g*
[19:46] <jdong> I'm already up to 10%... how many stages are there?
[19:46] <Kano> introspection takes long...
[19:47] <jdong> perfect time to do laundry then :)
[19:47] <Kano> as i said, you can tune it down to 10 min compile time on dual core
[19:47] <jdong> meanwhile, someone please REVU clutch for me ;-)
[19:49] <hellboy195> \sh: qmail merged :)
[19:57] <somerville32> jdong: Since when has Xubuntu adhered to a number of policies? :P
[20:00] <Elly> wait, ubuntu has policies?
[20:00] <pochu> a lot
[20:00] <pochu> PolicyKit
[20:00] <pochu> ;)
[20:04] <Elly> :O
[20:04] <Elly> does it have selinux policies?
[20:06] <jdong> Elly: uh oh don't start Apparmor vs SELinux again ;-)
[20:06] <Elly> I thought apparmor relied on selinux
[20:06] <Elly> o_O
[20:06] <Elly> I didn't know they were opposed
[20:07] <jdong> no
[20:07] <jdong> they are "competing" technologies
[20:16] <\sh> siretart, it looks like that I'm trapped in a behaviour of gnome-volume-manager to start always a filemanager when something is mounted with an <insert fs here> system ;)
[20:16] <ion_> Ditto
[20:32] <\sh> oh damn
[20:32] <\sh> it's nautilus
[20:33] <\sh> ion_, gconf-editor search for nautilus -> preferences -> media_automount <- checked -> media_automount_open <- also checked...uncheck this media_automount_open
[20:35] <ion_> Thanks
[20:36] <\sh> ion_, well...no...this is wrong
[20:56] <yamal> reviewers wanted for http://revu.tauware.de/details.py?package=sabnzbdplus - thanks
[21:04] <\sh> ok...going off...cu tomorrow
[22:07] <schierbeck> what would be the reason that my newly built package only contains /usr/share/doc/<pkg>/<stuff>?
[22:07] <schierbeck> when i extract the source package, everything is there
[22:07] <schierbeck> and i can install just fine with ./configure, make and sudo make install
[22:09] <persia> schierbeck: The install files aren't going in to one of debian/tmp/... or debian/<package>/... at build time.
[22:09] <persia> jdong: Can you review yet, or are you still waiting for promotion?
[22:10] <ScottK> persia: He's taken care of.
[22:10] <persia> ScottK: great.  I missed it in backscroll.  Thanks for the update.
[22:13] <schierbeck> persia: but i use $(MAKE) prefix=$(CURDIR)/debian/$(package)/usr install in the rules file
[22:13] <schierbeck> and the package var is set correctly
[22:14] <persia> schierbeck: Does the upsteam Makefile parse prefix when passed like that?  Try using debuild in a chroot and check the contents of debian/$(package)/ after the build.
[22:15]  * persia notes that packaging tends to expose subtle bugs in upstream build systems
[22:18] <schierbeck> persia: i've tried running make install manually, with prefix=./debian/<pkg>/usr, but it doesn't create the directories
[22:19] <schierbeck> should i add a flag to /usr/bin/install?
[22:19] <schierbeck> -D seems to be the right one
[22:20] <mok0> schierbeck: install -D only copies one file at a time
[22:20] <persia> schierbeck: You could try putting them in debian/package.dirs and calling dh_installdirs.  If that doesn't work, patching the upstream Makefile could do it.  The first is easier to handle for updates, as you won't have to merge a patch (although you will need to check to make sure they are still correct).
[22:21] <persia> schierbeck: Whichever path you choose, best to tell upstream that it doesn't work, and they might appreciate a patch to make sure their software can be installed on systems that are missing the install directories.
[22:21] <schierbeck> persia: it's my own project, so i can easily change the Makefile
[22:21] <persia> schierbeck: It's handy when working with upstream only means talking to oneself, although it can be confusing sometimes :)
[22:22] <schierbeck> indeed :)
[22:22] <schierbeck> i use autotools -- is there something simple i can just put in?
[22:23] <mok0> schierbeck: make DESTDIR=debian/tmp install
[22:23] <schierbeck> mok0: i'll try that, thanks
[22:24]  * persia notes that for autotools make DESTDIR=debian/$(package)/ ought work as well
[22:25] <schierbeck> should i remove the prefix, mandir and infodir declarations from the make install line?
[22:25] <mok0> schierbeck: Actualle there are 2 strategies: either have the buildsystem install things directly into the relevant debian/<package> directories, or
[22:26] <mok0> schierbeck: let the build system make a complete installation into the debian/tmp tree, and then let <package>.install files put them into their right place for packaging
[22:26] <schierbeck> i'll try with DESTDIR first :)
[22:26] <mok0> schierbeck: I recommend that
[22:27] <mok0> schierbeck: and then your rules only needs to be a 4 line cdbs script
[22:27] <schierbeck> god damn it, all that work and i could've just put in 4 lines!!
[22:28] <mok0> schierbeck: which means you don't need to quarrel with the MOTUs about debhelper details :-)
[22:28] <persia> schierbeck: Think of it as a learning exercise.  If you learn the 4-line way, you'd get stuck for something more complex.  This way, you learn how it works, and then refactor the code.
[22:28] <mok0> schierbeck: if your build is only a straight "configure; make; make install" idiom, cdbs is _much_ simpler
[22:29] <schierbeck> hehe
[22:29] <persia> mok0: see the sendmail rules file for a counterexample (although I tend to agree with you when no overrides are required)
[22:29] <schierbeck> i'm still pissed
[22:29] <mok0> schierbeck: learning is hard :-)
[22:30] <mok0> schierbeck: check out https://wiki.ubuntu.com/PackagingGuide/Howtos/CDBS?highlight=%28CDBS%29
[22:30] <schierbeck> tell me about it, i only started using autotools a few weeks ago, and now this whole packaging thing is nagging me
[22:31] <mok0> schierbeck: spending time on autotools is *good*
[22:31] <mok0> it saves you time later on
[22:31] <schierbeck> yeah, i know
[22:32] <schierbeck> crap, still not working
[22:32] <schierbeck> i'll use that cdbs stuff instead
[22:32] <mok0> schierbeck: save your old rules file :-)
[22:33] <schierbeck> mok0: using bzr :)
[22:33] <ion_> Naturally, it’s in the VCS history.
[22:33] <mok0> schierbeck: cool
[22:34] <schierbeck> i'm co-developing bzr-gtk on the side, so i kind of have to :)
[22:34] <mok0> schierbeck: respect
[22:34] <schierbeck> gracias
[22:34] <schierbeck> hmm, i'm getting "E: mips_0.1.2-1_source.changes: bad-distribution-in-changes-file gutsy"
[22:35] <schierbeck> when running debuild -S
[22:35] <schierbeck> (still using the old rules file)
[22:35] <schierbeck> perhaps that's the reason?
[22:35] <mok0> schierbeck: ignore it
[22:35] <schierbeck> okay
[22:36] <mok0> schierbeck: lintian is a debian tool, it trips on Ubuntu releases
[22:36] <schierbeck> k
[22:36] <persia> schierbeck: You're getting that because of your version.  Pleaes use either 0.1.2-0ubuntu1 if you are targeting Ubuntu.
[22:37] <persia> s/Pleaes use either/Please use/
[22:37] <schierbeck> ohh
[22:37] <schierbeck> on it
[22:37] <persia> More generally, when you use a Debian revision number, lintian expects you plan to upload to Debian, and complains that Debian doesn't have hardy.
[22:40] <mok0> persia: ok, didn't know that
[22:41] <mok0> I only installed hardy yesterday on my new quadcore :-P
[22:41] <persia> mok0: Please share.  I see that question a lot, and "ignore it" tends to result in REVU rejections, or difficulties upgrading from privately released early versions to the official version once it gets accepted.
[22:42] <jdong> persia: I just got the powers earlier today
[22:42] <jdong> oh nvm scott already answered that
[22:42] <persia> jdong: Perfect.  Now, how many packages can you reject in 24 hours?
[22:42] <jdong> persia: haha
[22:43] <jdong> persia: I should ask you to rip apart the package I put up yesterday ;-)
[22:43]  * persia has reached 33, but thinks 50 ought be possible, with a little concentration.
[22:43] <schierbeck> if i use the autotools cdbs commands, do i still need to run autogen.sh before debuild?
[22:43] <mok0> persia: I understand. But when struggling with getting the right files into the right packages, I think the problem can be dealt with at a later polishing stage
[22:43] <persia> mok0: Agreed.
[22:44] <persia> jdong: I REVU in mostly FIFO order, although I try to have reviewed every package that passes through REVU at least once.  Best way to get me to review your package is to review all the packages ahead in the queue.
[22:44] <mok0> schierbeck: you should generate your tarball with a "make dist"
[22:45] <schierbeck> ok
[22:45] <mok0> schierbeck: then it will contain a correct configure etc.
[22:45] <mok0> schierbeck: doing autogen.sh in packaging is frowned upon (.i.e. don't do it unless absolutely necessary)
[22:46] <mok0> schierbeck: ... and since you are upstream it should be avoided
[22:46] <schierbeck> okay
[22:46] <jdong> persia: cool, that's awesome, I shall wait patiently then :)
[22:47] <jdong> persia: is there anything that you don't do? :D
[22:47] <mok0> jdong: back in line, dude :-)
[22:47] <schierbeck> ... but i need to run my autogen.sh and configure before i even have a Makefile...
[22:47] <schierbeck> but that's okay, right?
[22:47] <persia> jdong: Lots.  Let me know if you're looking for something :)
[22:48] <mok0> schierbeck: if you pack your tarball with "make dist" autotools make sure that everything needed is up to date. It will package a configure script + makefiles
[22:48] <pochu> jdong: don't wait, review instead! :-)
[22:48] <persia> jdong: And please don't wait patiently.  The more you can knock off as failing lintian or having something just plain wrong, the better hardy will be.
[22:48] <jdong> persia: true
[22:48] <mok0> schierbeck: then all you need to do is "configure; make; make install" which cdbs does automagically
[22:48] <jdong> well I'll go eat and then try playing REVU night ;-)
[22:49] <jdong> hopefully I won't get addicted :)
[22:49] <schierbeck> okay
[22:49] <pochu> jdong: you will end like persia if you do ;)
[22:49] <mok0> schierbeck: when upstream does his/her work, packaging is sooooo much easier :-)
[22:49]  * pochu hides from persia :)
[22:50] <persia> pochu: Why does REVU show a bulb when I add a rejection to a package that someone else advocated?
[22:50] <schierbeck> mok0: i shout at myself *all* the time :)
[22:51] <pochu> persia: because it has > 0 advocates
[22:51] <pochu> persia: what should I show instead?
[22:51] <pochu> Would be trivial to fix
[22:51] <persia> pochu: Hrm.  But it got rejected.  Can we add a test to make sure it wasn't rejected as well as having been advocated before granting a lightbulb?
[22:51] <vorian> it knocked it from the top of the list
[22:51] <mok0> schierbeck: I have to say: this forum has taught me humility
[22:52] <emgent> hyea people
[22:52] <pochu> persia: it's an if/elif/elif... block, so it's just moving the rejected thing before the "advocates > 0" :)
[22:52] <pochu> persia: I'll do it in an hour, have to go right now.
[22:52] <pochu> persia: let me know if you find something else!
[22:53] <persia> pochu: No huge rush.  Thanks a lot for helping.
[22:53] <mok0> Ah, a MOTU can skip queue none-the-less
[22:55] <schierbeck> okay, switched to cdvs
[22:55] <schierbeck> *cdbs
[22:56] <schierbeck> crap, now i need autotools as a build-dep
[22:57] <mok0> schierbeck: only if you use "autoconf" or "automake" which you should not
[22:58] <schierbeck> okay
[22:58] <schierbeck> i just copied from the packaging guide, but i guess i don't need them
[22:58] <mok0> schierbeck: like I said above, package your distribution tarball with "make dist" , it will generate a configure file that cdbs will call
[22:59] <schierbeck> okay
[22:59] <mok0> schierbeck: then your only dependency is cdbs and debhelper
[23:00] <mok0> schierbeck: in other words: you are upstream, make those changes in .orig.tar.gz
[23:01] <schierbeck> okay
[23:02] <schierbeck> building...
[23:09] <RainCT> good nightç
[23:15] <mohammad> Is there any restriction on the size of a deb package?
[23:15] <RAOF> Not that I know of.  There are extremely large debs (for game data, for example).
[23:16] <RAOF> Smaller is generally better, though :)
[23:16] <persia> mohammad: technically, making them larger than 2GB (compressed) might have issues on some architectures.  From a policy perspective, large packages need to justify their use of archive space (this tends to trigger around 50MB or so).
[23:18] <mohammad> Thank you persia & RAOF
[23:31] <schierbeck> persia, mok0: found a few bugs in my project's Makefile.am's, had to fix them before proceeding
[23:31] <mok0> schierbeck: great!
[23:33] <schierbeck> OMG! it's working!
[23:33] <schierbeck> i thought i'd never see the day!!
[23:33] <mok0> schierbeck: :-)
[23:33] <schierbeck> :D
[23:33] <schierbeck> thanks for all the help, guys!
[23:33] <schierbeck> wouldn't have made it without you
[23:33] <mok0> schierbeck: glad to help, I received a lot of help here myself...
[23:34] <schierbeck> :)
[23:40] <schierbeck> mok0: you're Danish?
[23:40] <mok0> schierbeck: yes
[23:41] <mok0> schierbeck: but don't hold it against me :-)
[23:41] <schierbeck> :)
[23:41] <schierbeck> i live in Østerbro -- what about you?
[23:42] <mok0> schierbeck: I live in Aarhus
[23:43] <mok0> schierbeck: if you like, there's often a nice crowd on ubuntu-dk
[23:43] <schierbeck> cool
[23:43] <mok0> we can speak danish there :-)
[23:43] <jdong> whee! I revu'ed a package! I feel so happy :)
[23:44] <mok0> jdong: way to go! (hope it was mine)
[23:44] <ajmitch> jdong: congratulations, you get a gold star & a warm fuzzy feeling
[23:45] <jdong> ajmitch: just like swimming camp!
[23:45] <jdong> mok0: nah, with the todo list you hope it wasn't yours ;-)
[23:46] <mok0> jdong: swimming camp? that would be more like, at cold shivering feeling...
[23:46] <mok0> jdong: :)
[23:56] <pochu> ENOENT means "No such file or directory", right? But is it an acronym? Or is there a reason for those letters?
[23:56] <Seveas> E for error NO for no ENT for entry or entity oslt
[23:58] <pochu> Seveas: ah, thanks :)


[20:24] <Bashing-om> UWN: Issue780 up for review and final edits: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue780 :D
[20:37] <krytarik> Bashing-om: We should be specific in that bandali was made "Ubuntu Contributing Developer"
[20:38] <Bashing-om> krytarik: Ack - making it so :D
[20:40] <krytarik> Uhm, why do we feature general pages on Discourse about the Community Council and the Technical Board? O_o
[20:44] <Bashing-om> krytarik: Came from Discourse - want to move em ?
[20:47] <krytarik> I mean sure, maybe they were added there only recently, but our general aim is to feature news, not institution descriptions.
[20:49] <Bashing-om> krytarik: Good point ! will remove :D
[21:33] <Eickmeyer> Is the CPC team requesting more of a say in releases from the release team really a newsworthy item? To me it seems like an internal discussion the release team needs to have and not really something the public can and should weigh in on, and reporting it would give optics that they should.
[21:34] <Bashing-om> Eickmeyer: re-reading ^ with your point in mind :D
[21:39] <Bashing-om> Yup Eickmeyer is correct >> "What are the release teams' thoughts". The article is not directed to the general public !
[21:41] <Eickmeyer> Most things to #ubuntu-release aren't, just for future reference. That's what #ubuntu-announce is for. #ubuntu-release is stuff to direct toward the release team.
[21:43] <Eickmeyer> Rather, the Ubuntu Release ML.
[21:43] <Bashing-om> Eickmeyer: Uh Huh ^ - so noted - thanks !
[21:44] <Bashing-om> A 2nd to pull the "Canonical Public Cloud (CPC) ...: article ?
[22:19] -SwissBot:#ubuntu-news- ::Planet:: David Mohammed: New edge tiling introduced in 23.04 @ https://ubuntubudgie.org/2023/01/new-edge-tiling-introduced-in-23-04/
[22:19] -SwissBot:#ubuntu-news- ::Planet:: David Mohammed: New hotcorners feature introduced in 23.04 @ https://ubuntubudgie.org/2023/02/new-hotcorners-feature-introduced-in-23-04/
[22:19] -SwissBot:#ubuntu-news- ::Planet:: Aaron Rainbolt: A brief history of my experience with Linux @ https://arraybolt3.substack.com/p/a-brief-history-of-my-experience
[22:19] -SwissBot:#ubuntu-news- ::Planet:: Aaron Rainbolt: An In-depth Review of the Kubuntu Focus XE Gen 1 @ https://arraybolt3.substack.com/p/an-in-depth-review-of-the-kubuntu
[22:19] -SwissBot:#ubuntu-news- ::Planet:: Scott Moser: Fixing the qemu serial console terminal size. @ https://smoser.github.io//2023/03/21/qemu-serial-window-size.html
[22:22] <krytarik> Bashing-om: Yeah, after reading that ML post, it does like kicking off a discussion about improving internal processes which apart from assumedly being of minor interest to the wider public, doesn't have any bearing yet anyway.
[22:23] <Bashing-om> krytarik: Pulling that one too :P


[09:50] <xypron_> sergiodj: EDK II for riscv64 will require QEMU 8.1. Do you expect that release to go into mantic?
[15:00] <sergiodj> xypron_: I'll coordinate with the Debian maintainer to check, but I think it's doable until FF
[15:00] <xypron_> sergiodj: Thanks. EDK II is maintained by dannf.
[15:01] <sergiodj> xypron_: ACK, thanks
[15:07] <sergiodj> xypron_: the Debian maintainer told me that 8.1 still has issues which are impacting/hurting debian infra, so I'm not sure that we'll have it ready before FF anymore...