[16:13] <littlegirl> Hey there, shaunm, there's a bug report that looks like it might want to have you on it. (:
[16:56] <shaunm> littlegirl: link?
[16:57] <littlegirl> shaunm: https://bugs.launchpad.net/ubuntu-docs/+bug/1232708
[16:57] <ubot2> Launchpad bug 1232708 in Ubuntu Documentation "Some GNOME only help showing up in Unity help (13.10)" [Undecided,Confirmed]
[16:57] <littlegirl> shaunm: I've been beating my head on this one. I've tried every possible way I can think of to do conditionals on it and get it to work, but it either displays nothing or displays the wrong text (I use KDE and I see the Unity text when I see any text at all during my tests). It's a stumper. (:
[16:59] <littlegirl> shaunm: I'm not sure if it's mentioned in that report, but the file you want to edit is color-assignprofiles.page and the file that displays it is color.page.
[17:01] <shaunm> littlegirl: so I did notice when testing something else that universal-access-menu.png and view-fullscreen-16.png are missing
[17:03] <littlegirl> shaunm: Oh! In that document?
[17:04] <shaunm> yes, they're both referenced from pages, and not inside conditionals
[17:04] <littlegirl> Ouch, that needs to be added to that bug or a new one needs to be made. I'll make a note of it right now and look into it, and if there's no bug and I can't fix it right away, I'll write it up as a bug. (:
[17:05] <shaunm> it is noted in that bug
[17:05] <shaunm> comments on that bug seem to mention a lot of issues. not sure what the root issue is
[17:09] <littlegirl> Ah, okay. Well, the one I was working on that would interest you is the conditional inside the <info> tag. I can't get it to behave properly no matter how I code it (whether I do it inside the <desc> tag or outside of it or whether I toss some of the code outside of the <info> tag entirely.
[17:09] <shaunm> "The if:choose element can occur in any general block context"
[17:09] <shaunm> http://projectmallard.org/if/1.0/if_choose
[17:09] <littlegirl> Yep, and I'm not sure if <info> qualifies as a block or not. (:
[17:09] <shaunm> it does not
[17:09] <shaunm> a block context is somewhere you could put a paragraph
[17:09] <littlegirl> Ah, okay, so is there a way to do a conditional inside an <info> tag?
[17:10] <shaunm> not at this time
[17:10] <littlegirl> Yeah, that's what I was starting to figure, and since <info> is invisible, it can't hold a paragraph.
[17:10] <littlegirl> shaunm: Could it be hacked by doing the conditional outside of the <info> tag entirely making the conditional point to two <info> tags, one of which gets chosen if the condition is satisfied?
[17:11] <littlegirl> I know that would be a sloppy hack, but it would get the job done if it's allowed. (:
[17:15] <shaunm> that won't work either
[17:15] <shaunm> I'm afraid there's just currently no way to do what you're trying to do
[17:15] <shaunm> do you actually use the same set of page files when users are running under gnome?
[17:17] <littlegirl> I think so. I didn't write the page, and I'd have to study it thoroughly to see what can be done. I'm sure it can just be rewritten to tell the user what would have been automated by the conditional. I'll take a good look at it and see if I can at least sort that part out. Then I'll go after that bug and see if I can't get whoever put all the sloppy additions into it into separate bug reports. (:
[17:23] <shaunm> it would probably help to start using version attributes and strict validation in yelp-check
[17:23] <shaunm> unfortunately, there are some road blocks to doing that
[17:24] <shaunm> I've solved those road blocks, but you won't see the solution until my patch is accepted in libxml2 and a new version is packaged :(
[17:25] <shaunm> you can always still use the version attribute without strict validation to get better validation of your conditionals. you just won't have anything tell you when you forgot the version attribute
[17:25] <littlegirl> It's currently pretty common to use the command (or a variant of the command) in the check_validation.sh file, which uses xmllint. Nobody on the doc team has ever suggested using yelp-check to validate the files. I tried it in the Ubuntu docs the other day and there are some issues that will need attention, and as soon as I get another issue sorted out I'll go after them with yelp-check. (:
[17:26] <littlegirl> Does that mean in your new version (which sounds exciting!) there will be a way for those conditionals to happen?
[17:26] <littlegirl> Or just that there will be a way to find out that a bad conditional was written?
[17:28] <shaunm> you'll just know when the conditionals were written wrong
[17:28] <shaunm> for those sorts of conditionals to work, we'll need a new version of conditionals on projectmallard.org
[17:28] <shaunm> which can happen
[17:29] <littlegirl> Cool. No hurry, though. I love your work, and would never want to do anything to make you frustrated with it. (:
[17:29] <shaunm> for validation, the core mallard schema is intentionally very forgiving whenever it sees anything outside of the normal namespace. so when you use an if:when element just about anywhere, the schema basically says "I don't know what this is, so I'll just assume it's right"
[17:30] <shaunm> that's the schema that's used by yelp-check if you don't use a version attribute, and almost certainly what your validation script uses
[17:31] <littlegirl> Yep. All of those just get quietly ignored. At least all the variants I tried when I was doing if:choose, if:when, if: test, etc., etc., etc. in an attempt to get it to do it. I finally gave up and hunted you down. (:
[17:31] <shaunm> but you can set the version attribute on the page element to tell the validator to load in schema plug-ins. if you load the plug-in for conditionals, then when the schema sees if:when, it does know what it is, and it actually checks if it's correct
[17:33] <littlegirl> I'm not that advanced in the use of Mallard yet to fully understand that, but I'll do my best to learn those. I'm still digging through all the documentation I can find on Mallard and writing up my own personal reference, and I'm not up to plug-ins yet. (:
[17:33] <shaunm> here's a good example: yelp-check validate color-assignprofiles.page
[17:34] <shaunm> that passes, even though the conditionals are wrong
[17:34] <shaunm> edit that file and put the attribute version="1.0 if/1.0" on the page element
[17:34] <shaunm> re-run the command. witness the glory of validation errors
[17:35] <littlegirl> Interesting. yelp-check validate *.page doesn't turn up any issues, either.
[17:36] <shaunm> that's good. that means that everything that's in the normal namespace is correct
[17:36] <shaunm> but it's not checking anything in if/1.0 or ui/1.0 or experimental or experimental/ui
[17:37] <littlegirl> Ooooh, then I get: color-assignprofilestwo.page:5: element page: Relax-NG validity error : Expecting element title, got info
[17:37] <littlegirl> color-assignprofilestwo.page:5: element page: Relax-NG validity error : Element page failed to validate content
[17:37] <littlegirl> color-assignprofilestwo.page fails to validate
[17:37] <littlegirl> Oh, I forgot to mention that I created a color-assignprofilestwo.page so I could leave the original one alone, and the two page is the one I put the version attribute into. (:
[17:38] <littlegirl> So if I add that version attribute to all the pages they can be tested with yelp-check from now on?
[17:39] <shaunm> they'll be tested much more strictly with yelp-check, yes
[17:39] <shaunm> there's no need to do it on pages that don't use conditionals
[17:39] <shaunm> though it doesn't hurt
[17:40] <shaunm> files-copy.page uses the ui extension, so you could use version="1.0 ui/1.0" there
[17:40] <shaunm> or even version="1.0 if/1.0 ui/1.0"
[17:40] <littlegirl> These are the ones that are currently used, with line 7 being the one in the check_validation.sh file, but I prefer the last one: http://paste.ubuntu.com/6348233/
[17:41] <shaunm> oh, one caveat: unless you've installed local copies of the schema and done black magic with xml catalog files, yelp-check will hit the internet to put together the schema for validation
[17:41] <littlegirl> It slips right past all of those, though.
[17:42] <littlegirl> That's okay. This is for the Ubuntu docs, and it should do that so that it's always up-to-date. On my local documentation, in which I'm converting all my personal documents to Mallard, I'll stick with xmllint.
[17:43] <shaunm> there is a package you can install that gives you a local copy of the 1.0 schema and does the xml catalog black magic for you. but it only contains finalized specs, and conditionals isn't finalized yet
[17:43] <shaunm> and I don't know if it's packaged for ubuntu
[17:43] <shaunm> we should finalize conditionals soon
[17:44] <littlegirl> It is, but I didn't install it.
[17:44] <littlegirl> Will  version="1.0 if/1.0 ui/1.0" cover all eventualities and be a blanket attribute I can just add to all the docs to make it possible to yelp-check them all?
[17:45] <shaunm> it covers everything ubuntu is using now *except* experimental features and embedded ITS
[17:45] <shaunm> there will never be schemas for experimental features, and there's not currently a mallard schema plug-in for ITS
[17:45] <littlegirl> I'm kind of surprised Ubuntu uses experimental features. That's not usually the Ubuntu way. (:
[17:46] <shaunm> gnome does too
[17:46] <littlegirl> Maybe that's why, then.
[17:47] <shaunm> but I kind of need gnome to use them, or else they won't get tested. and the whole point of experimental features is to give them some real-world testing before they get put in a formal specification and I have to support them forever and ever
[17:47] <littlegirl> True.
[17:48] <littlegirl> So the 1.0 in that version attribute will coincide with the 1.0 in xmlns="http://projectmallard.org/1.0/" right? So if the Mallard version changes, the version attribute should follow suit, right?
[17:48] <littlegirl> I'm testing the heck out of links right now. (:
[17:49] <shaunm> if the Mallard version changes, you'd change the version attribute, but not the xmlns
[17:49] <shaunm> unless it changes to a backwards-incompatible 2.0, which I have no plans on any time soon
[17:50] <littlegirl> So you just leave the xmlns at 1.0?
[17:50] <shaunm> yeah, I probably should have named the namespaces just 1 or even 1.x
[17:51] <shaunm> if you change namespaces, you basically have to rewrite all the tools
[17:51] <littlegirl> There are all kinds of philosophical discussions out on the internet on how to number software. I think it's six of one, half a dozen of the other when it comes to which way is best. (:
[17:52] <shaunm> I followed soname naming conventions, which was probably a mistake because only C programmers understand it
[17:52] <littlegirl> For my personal uses, I'll use it "out of the box" rather than bolting anything onto it. For Ubuntu, hopefully there are others who know how to do the fancy stuff so that can be updated properly. I've already seen some neat stuff (like mouse-over actions) that I don't yet know how to do, let alone maintain. (:
[21:15] <moewe11> neither chrome nor firefox let me edit the following wiki entry
[21:15] <moewe11> https://help.ubuntu.com/community/Howto%3A%20Custom%20keyboard%20layout%20definitions
[21:15] <moewe11> All I get is: "The address wasn't understood". Seems to be the colon in the URL which throws off the browsers


[12:41] <Kopfgeldjaeger> n8
[01:10] <pkern> So should we actually suggest users with ATI graphics to upgrade to Gutsy?
[01:15] <persia> pkern: Not yet :)
[01:16] <imbrandon> ok i'm off to dinner, if pochu comes back arround the upload is done
[01:16] <pkern> persia: Not even after the release I am afraid, at least not on laptops.
[01:22] <Joe_CoT> persia: got the updated changelog deb diff for LP #149050. Would you be able to sponsor it? Should i subscribe to sponsors instead?
[01:22] <ubotu> Launchpad bug 149050 in deluge-torrent "Deluge torrent client: Cannot set file priority, as it continually claims that Full Allocation is not set" [Undecided,In progress]  https://launchpad.net/bugs/149050
[01:24] <persia> Joe_CoT: You'll always want to subscribe to sponsors when you have something ready, rather than looking for individuals.  I'm not sure I'll be sponsoring anything else for gutsy, but if I do, and nobody else has already uploaded it, I may.
[01:24] <Joe_CoT> persia: ok, thanks, i'll subscribe it
[01:33] <superm1> pkern, why not?
[01:34] <pkern> superm1: Decide: Which one do you like most: suspend or 3d acceleration?
[01:35] <superm1> pkern, ah :)  wasn't sure if suspending was the thing to accuse this time around :)
[01:35] <superm1> i'm on the beta team and suspending has been broken for some time for me, so i've just learned to not suspend, wasn't sure if it was still broke :)
[01:36] <pkern> I'm used to suspend ever since I used an iBook.
[01:50] <bluefoxicy> is vmware-server not coming for gutsy?
[01:51] <bluefoxicy> vmware-player and virtualbox lack kernel modules ...
[01:51] <pkern> There was a recent article on planet.u.c about the vbox modules.
[01:52] <bluefoxicy> u.c?
[01:52] <pkern> ubuntu.com
[01:53] <bluefoxicy> oh
[02:00] <pkern> ScottK: python-debian supports Version objects (and changelog objects) so that would be a no-brainer. ;)
[02:01] <pkern> ScottK: But maybe we should talk with pitti *first* to confirm if the format still holds.
[03:33] <LaserJock> so did I miss something? why have I got ~350 updates today?
[03:34] <imbrandon> slow mail server ?
[03:34] <LaserJock> imbrandon?
[03:34] <imbrandon> no idea, was a wild guess
[03:35] <LaserJock> it just seemed odd for an RC freeze
[03:35] <imbrandon> i only made one upload and it was a approved , sponsored upload
[03:35] <imbrandon> heh
[03:36] <LaserJock> I've gotta upload edubuntu-docs tonight
[03:36] <imbrandon> ;)
[03:38] <crimsun> pfft.  It's no fun if there aren't hourly multi-hundred MiB updates!
[03:39] <imbrandon> crimsun: hehe yea
[03:39] <LaserJock> crimsun: hello
[03:40] <crimsun> hi
[03:44] <LaserJock> crimsun: how's Washington?
[03:45] <crimsun> it's capitol-y.
[03:50] <imbrandon> nice word :)
[03:53] <LaserJock> I spent a week staying out by Arlington for an American Chemical Society meeting
[03:53] <LaserJock> it was fairly nice
[04:53] <bddebian> whoa, crimsun!
[04:53] <crimsun> (where?!)
[04:54] <bddebian> ^--- there :-)
[04:55] <bddebian> OK I'm working with the Debian games team now and I'm still not convinced that svn doesn't SUCK for package management :-)
[04:56] <imbrandon> s/svr/RCS/g
[04:57] <imbrandon> svn* damn
[04:57] <bddebian> I knew what you meant :-)
[04:57] <imbrandon> hehe
[04:57] <tonyyarusso> rcs?
[04:58] <imbrandon> revision control systems, svn,cvs,bzr
[04:58] <tonyyarusso> ah
[04:59] <imbrandon> great for code, sucks for package management, imho, package mnagement seems to be much more a "one man job"
[04:59] <bddebian> Heh, go for it
[04:59] <bddebian> Fujitsu: Just mark them all won't fix after Gutsy releases ;-P
[05:00] <bddebian> We'll just start fresh after every release from now on..
[05:03] <Hobbsee> imbrandon: get to it : )
[05:03] <Hobbsee> Fujitsu: sounds good.
[05:03] <imbrandon> heya Hobbsee
[05:03] <Hobbsee> hiya!
[05:04] <bddebian> Hi Hobbsee
[05:04] <Hobbsee> hi bddebian
[05:07] <white> anyone wants (or is) subscribed to
[05:07] <white><EMAIL_ADDRESS>[05:07] <white> or at least checking
[05:07] <white><EMAIL_ADDRESS>[05:07] <Fujitsu> white: Aha, I'll subscribe.
[05:07] <bddebian> More spam.. :)
[05:08] <white> Fujitsu: is the universe security team active?
[05:08] <white> it would be nice to get cooperation done :)
[05:08] <bddebian> Is there a universe security team?
[05:09] <white> i could do some randon checking now :)
[05:09] <white> !info util-linux gutsy
[05:09] <ubotu> util-linux: Miscellaneous system utilities. In component main, is required. Version 2.13-8ubuntu1 (gutsy), package size 426 kB, installed size 1364 kB
[05:09] <tonyyarusso> bddebian: motu-swat, iirc
[05:11] <white> or easier, someone could check, if the security fixes from http://security-tracker.debian.net/tracker/status/dtsa-candidates are included in gutsy
[05:12] <Amaranth> white: You probably want to talk to pitti or keescook
[05:13] <white> Amaranth: apparently they are doing main
[05:13] <white> Amaranth: i was offering something for univers
[05:13] <white> e
[05:13] <Amaranth> white: util-linux is in main
[05:15] <white> the version 2.13-8ubuntu1 looks fixed to me
[05:15] <LaserJock> security-tracker.debian.net is so awesome
[05:16] <white> Amaranth: and i am bringing it up, because i forget to theck here and it would be nice to get an ubuntu person to do it
[05:16] <white> LaserJock: indeed :)
[05:16] <LaserJock> saved me loads of time doing the moodle MIR
[05:16] <Amaranth> moodle? isn't that an edubuntu thing?
[05:16] <Amaranth> oh right, you're an edubuntu guy :P
[05:19] <LaserJock> Amaranth: pfft
[05:19] <LaserJock> hmm, still need to get that interview up :/
[05:28] <tonyyarusso> Hobbsee: Do you have a shortcut for that phrase?
[05:33] <ScottK> tonyyarusso: Did you see my comments on the kompozer backport request?
[05:33] <tonyyarusso> ScottK: I saw one, to the effect of "sounds like a good idea - test?"
[05:34] <ScottK> That one.
[05:34] <ScottK> Please test.
[05:34] <tonyyarusso> well, um, it's installed on my feisty system right now, does that count?
[05:34] <ScottK> Yes. it does.
[05:35] <ScottK> Just say in the bug that you've built and installed it on Feisty and it works.
[05:35] <tonyyarusso> Okay.  It builds both in a local pbuilder and on LP PPA.
[05:36] <ScottK> I need it in the bug.
[05:37] <tonyyarusso> done
[05:38] <ScottK> tonyyarusso: Acked to the archive.  They usually do backports about once a week.
[05:39] <tonyyarusso> ScottK: neat.  Any thoughts on whether we should try for Edgy/Dapper as well?
[05:40] <ScottK> Hobbsee: Would you please ack Bug #148548.  We updated gnucash, we really ought to do the docs too.
[05:40] <ubotu> Launchpad bug 148548 in gnucash-docs "Gnucash-docs is 2.0.1 while it should be 2.2.0" [Undecided,New]  https://launchpad.net/bugs/148548
[05:40] <ScottK> tonyyarusso: Can you test on Edgy/Dapper?
[05:49] <tonyyarusso> ScottK: If I take the time to read some pbuilder docs, yeah.  There's already a PPA build for Edgy as well.
[05:50] <ScottK> tonyyarusso: It's not just building.  I need you to say it installs and runs.
[05:51] <tonyyarusso> ScottK: I can test that for Dapper for sure; not sure where I'll find an Edgy installation.
[05:51] <tonyyarusso> I'm sure if I ping enough people I could.
[05:52] <LaserJock> vmware/virtualbox?
[05:52] <tonyyarusso> no experience in that department..
[05:52] <tonyyarusso> Live CD could work I suppose
[05:54] <imbrandon> or "pbuilder-edgy login' then install and test it
[05:54] <imbrandon> ;)
[05:54] <tonyyarusso> what now?
[05:55] <imbrandon> as in ?
[05:56] <tonyyarusso> pbuilder-edgy login would just let you log into the command line system of the base.tgz, I take it?
[05:56] <tonyyarusso> How would I test a graphical app in that environment?
[05:57] <ScottK> LiveCD would do it.  Dunno about the rest.
[05:58] <LaserJock> tonyyarusso: install it and launch it?
[05:59] <tonyyarusso> LaserJock: would it use my feisty's X?
[05:59] <nenolod> probably
[05:59] <LaserJock> I suppose
[05:59] <nenolod> X is X. it doesn't really change ABI very often
[05:59] <nenolod> (Xlib, that is)
[06:00] <imbrandon> you might need to allow X connections from localhost, like 'xhost +` prior to pbuilder login
[06:01] <imbrandon> tonyyarusso: ^ but other than that should work fine
[06:01] <tonyyarusso> interesting
[06:01] <jdong> imbrandon: xhost + is a big more than localhost if the system is not properly configured though ;-)
[06:02] <nenolod> oh, use X inside a pbuilder?
[06:02] <imbrandon> yea if you dont setup your router correctly it can be a security bug, man xhost for more indepth info
[06:02] <nenolod> he just needs to do xhost +localhost
[06:02] <nenolod> it'll work provided that your debian/rules sets DISPLAY=:0
[06:02] <jdong> nenolod: right, I was gonna say xhost +localhost is more cautious
[06:02] <nenolod> (probably in configuration phase, right?)
[06:03] <imbrandon> shouldent matter, should default to 0
[06:03] <imbrandon> err :0
[06:04] <imbrandon> e.g. the following should work fine , `xhost +localhost` `pbuilder-edgy login` `apt-get install amarok` `amarok`
[06:04] <nenolod> no
[06:04] <nenolod> DISPLAY must be set, otherwise Xlib will not connect to the X server
[06:04] <nenolod> there is no defaults in Xlib
[06:05] <nenolod> (and thus any toolkits ontop of Xlib, e.g. Qt)
[06:05] <imbrandon> e.g. the following should work fine , `xhost +localhost` `pbuilder-edgy login` `apt-get install amarok` `export DISPLAY=:0` `amarok`
[06:05] <imbrandon> :)
[06:05] <nenolod> :)
[06:05] <imbrandon> no source changes
[06:05] <LaserJock> well, I used to use a chroot and bindmount ~/ and it's work fine for that kind of thing
[06:05] <LaserJock> *it'd
[06:05] <imbrandon> LaserJock: esentialy the same thing
[06:06] <imbrandon> pbuilder is just a self cleaning [sic]  chroot
[06:06] <LaserJock> right, but I believe that getting ~/ and hence .Xauthority into the chroot was the key thig
[06:07] <imbrandon> ahh
[06:08] <jdong> imbrandon: for X /tmp needs bindmounting too; that's where the sockets usually are
[06:14] <imbrandon> nah there should be a tmp in the chroot, you dont want to nessesarly give it access
[06:19] <nenolod> just do xhost +localhost and export DISPLAY=:0
[06:19] <nenolod> ;p
[06:30] <Hobbsee> tonyyarusso: perhaps.
[06:30] <Hobbsee> ScottK: please do it.
[06:31] <ScottK> Hobbsee: OK.
[06:31] <Hobbsee> tonyyarusso: there are ways to test grapical bits in a chroot.
[06:31] <ScottK> Hobbsee: I already test built it, so I'll turn it into a sync request.
[06:31] <Hobbsee> ah, you found it
[06:31] <Hobbsee> ScottK: great
[06:32] <Hobbsee> ScottK: will leave you to handle it then
[06:38] <LaserJock> crap
[06:42] <bddebian> not here please :-)
[06:44] <ScottK> Hobbsee: Done.
[06:44] <ScottK> jdong: You still around.
[06:44] <jdong> ScottK: half-awake, but yeah
[06:45] <ScottK> jdong: What happened to all the backports testing people?
[06:45] <ScottK> jdong: I think you need to rustle up some more ...
[06:45] <jdong> ScottK: I'm not sure myself, seems like a lot of them are mysteriously idle
[06:45] <ScottK> Hobbsee: Yummy?
[06:45] <Hobbsee> indeed!
[06:45] <jdong> ScottK: I'll send out an e-mail to the backports testing folk and see if I can whip em back
[06:45] <ScottK> jdong: Then Hobbsee's explaination fits...
[06:46] <jdong> ScottK: lol they're nutritious :)
[06:46] <ScottK> Or however you spell that word.
[06:46] <Hobbsee> explanation
[06:46] <ScottK> jdong: Remember: Sleep is for the weak.
[06:46] <ScottK> Yeah, that.
[06:46] <jdong> lol, but I am weak :)
[06:48] <ScottK> LaserJock: I'm not sure, but that may be a CoC violation, so don't do it on IRC.
[06:48] <LaserJock> hehe
[06:53] <LaserJock> wahoo, it works
[06:53] <LaserJock> now all those non-English speaking people can read the docs
[06:55] <Hobbsee> heh
[06:55] <LaserJock> I've spent the last 3 hrs working on the translations for edubuntu-docs
[06:56] <LaserJock> had to build several scripts
[06:56] <LaserJock> and rewrite debian/rules
[07:07] <bddebian> Gnight gang
[07:20] <LaserJock> \o/, uploaded
[07:20] <LaserJock> hopefully that's my last upload for gutsy
[07:20] <Hobbsee> aww
[07:21] <LaserJock> now hopefully slangasek or pitti lets it threw
[07:21] <LaserJock> hmm, *through
[07:21] <Hobbsee> LaserJock: we have more than 2 people in the release team, fortunately :P
[07:22] <LaserJock> I thought one of those two had to approve an RC freeze exception
[08:11] <LaserJock> shesh, the gutsy branch of doc team svn repo is ~550MB
[08:12] <ScottK> LaserJock: That's nothing.  I remember some guy talking about doing a checking of the Debian LaTex tree and it being huge.
[08:13] <LaserJock> umm, that was me
[08:13] <LaserJock> and it was 20GB
[08:13] <tonyyarusso> oof
[08:13] <ScottK> I know.  I just thought it was kind of funny that way.
[08:13] <LaserJock> heh, right
[08:14] <LaserJock> but we're supposed to move the doc team repo to bzr
[08:14] <LaserJock> which makes 500MB a bit more troublesome to me
[08:15] <ScottK> But bzr is wonderful.  Everyone here says so.
[08:15] <LaserJock> heh, I haven't really gotten that impression exactly
[08:15] <LaserJock> it's great for local stuff
[08:15] <LaserJock> but the remote stuff is still so slow
[08:17] <LaserJock> but the doc team repo is the last Canonical svn repo
[08:17] <LaserJock> so the sysadmins don't want to maintain it anymore
[08:22] <ScottK> Well good luck.  I'm off to bed.
[08:22] <LaserJock> cya ScottK
[09:39] <slangasek> imbrandon: packages don't have to be acked by the release team before being uploaded, if they're uploads to main and they don't fit the freeze rules they can just be rejected :)
[09:41] <AnAnt> Hello, if I am making a package for a work that is under LPPL license, the complete text for this license is not in /usr/share/common-licenses/, should I then include the complete text in the debian/copyright file  ? or is it enough to have something like this statement: http://pastebin.com/m16fc5080  ?
[09:44] <persia> AnAnt: The complete text of the license should be in debian/copyright.  The URL may not be available to a user (perhaps they are offline) when they check.
[09:44] <AnAnt> ok
[09:46] <AnAnt> persia: how about installing it in /usr/share/common-licenses/ ?!
[09:46] <Fujitsu> AnAnt: Is it a particularly common license?
[09:47] <AnAnt> Fujitsu: for those using LaTeX, I think so
[09:47] <persia> AnAnt: That directory is reserved for common licenses, for which large numbers of programs are using.  As an example of the threshold, the ISC license is not included, and we've heaps of ISC code.  Similarly, none of the CC licenses, although that is fairly prevalent.
[09:48] <AnAnt> k
[09:49] <persia> AnAnt: If you think it's common enough, feel free to post a bug against base-files to include it: be sure to list all the packages that use it in the bug, to demonstrate that it would save significant space on a user's system.
[09:50] <AnAnt> ok, how can I indent several lines with 4 spaces in vim ?!
[09:56] <AnAnt> nevermind about the last question
[09:56] <AnAnt> thanks
[10:04] <Fujitsu> Hobbsee: Are you still around?
[10:04] <Hobbsee> Fujitsu: fsvo around, what's up?
[10:05] <Fujitsu> Hobbsee: Just wondering if I'm going to be killed for uploading a new upstream version, the UVFe for which was filed by somebody else, and approved a month ago.
[10:06] <Hobbsee> Fujitsu: unlikely
[10:06] <Hobbsee> although why wasnt it uploaded then?
[10:06] <Hobbsee> that's a good question, actually
[10:06] <Fujitsu> Hobbsee: REVU was down, and the reporter isn't a MOTU.
[10:07] <Fujitsu> So it got lost.
[10:07] <Hobbsee> ah yes
[10:07] <Hobbsee> no idea if archive admins will get time to review it
[10:07] <Fujitsu> Are they meant to be reviewing things at this point?
[10:07] <Fujitsu> I thought they were just giving them a glance and letting them through.
[10:11] <Hobbsee> Fujitsu: for new packages?  dream on.
[10:12] <Fujitsu> Hobbsee: `a new upstream version'
[10:25] <nenolod> slangasek, yay for auto-rejections :P
[10:27] <nenolod> Fujitsu, a new upstream version won't be approved until gutsy ISOs are built. if you're shooting for gutsy +1 and your package is OK, then it will probably pass through reviewers at that time
[10:27] <nenolod> but... uploads targeted at gutsy itself will likely be auto-rejected :P
[10:28] <persia> auto-rejected?  I don't think that's the case for packages not destined for ISO inclusion (or, really, anything in universe).
[10:29] <nenolod> well ISO building also includes gutsy archive finalization too
[10:29] <nenolod> and even the topic says universe is frozen for upstream versions and new packages
[10:29] <nenolod> ;p
[10:30] <Fujitsu> nenolod: Erm, what? ISOs have very little to do with anything, it has already been approved, and I'm a MOTU so it doesn't need review.
[10:31] <nenolod> Fujitsu, well ok :P
[10:32] <persia> nenolod:  That seems to contradict https://lists.ubuntu.com/archives/ubuntu-motu/2007-October/002411.html.  Are you sure?  Why?
[10:32] <nenolod> persia, i'm going by what is implied by the text in the topic
[10:32] <Fujitsu> nenolod: Right, UVF and NPF in effect. I have an exception, although it is old.
[10:33] <persia> nenolod: Ah.  Yes.  New upstreams are frozen.  There is a freeze exception process, and so some (very few) things can be approved.
[10:33] <nenolod> persia, yes i understand that.
[10:33] <nenolod> Fujitsu, yes. i understood that point. hince the "well, ok"
[10:35] <sladen> two week folks, then we can upload whatever we want!
[10:35] <Fujitsu> sladen: Two weeks + UDS + toolchain settling.
[10:36] <nenolod> i do hope that gutsy will ship with audacious-plugins that are not built with SSE2
[10:36] <Fujitsu> nenolod: Why?
[10:36] <DarkMageZ> cause some of us don't have sse2
[10:36] <nenolod> Fujitsu, because not everyone has SSE2 ;)
[10:36] <persia> nenolod: If it doesn't detect at runtime, that's a bug (and should be reported).
[10:37] <nenolod> it has been reported
[10:37] <nenolod> upstream anyway
[10:37] <Fujitsu> I don't see the bug in Ubuntu..
[10:37] <nenolod> yeah, i'll check
[10:38] <nenolod> ah. it's debbugs
[10:38] <persia> nenolod: It's a good idea to get the bug in both places, if it's verified an issue in Ubuntu: upstream may have a different threshhold ("I cannot imagine why anyone would want to not use optimisation" is something I recently saw on a different upstream mailing list).
[10:39] <nenolod> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423833
[10:39] <ubotu> Debian bug 423833 in audacious "audacious: Crash (illegal instruction) when playing MP3 file" [Normal,Fixed]
[10:39] <nenolod> of ypi want, o
[10:39] <nenolod> lets try that again
[10:39] <nenolod> if you want, i'll clone it in LP
[10:40] <Fujitsu> nenolod: If you could file a bug in LP, and add a Debian task linked to that bug, it'd be nice.
[10:41] <nenolod> (it's fixed in debian)
[10:41] <nenolod> ah.
[10:41] <nenolod> gutsy has it already
[10:42] <Fujitsu> nenolod: Yeah, we have that version.
[10:44] <nenolod> great :P
[10:44] <nenolod> because some people have flamed over that already
[10:44] <Fujitsu> Heh.
[10:46] <nenolod> i need to report a bug in NetworkManager, but I think I will wait until morning for that
[10:46] <nenolod> i'm not awake enough to think right now ;)
[10:47] <nenolod> i'm also not yet convinced that it is not a bug in madwifi too ;)
[11:51] <pkern> LongPointyStick: Thanks. ;)
[01:11] <pkern> Haha@everybody loves the Debian cabal.
[01:17] <DEVIUS> hi all
[01:18] <AlinuxOS> Hello All ;)
[01:21] <DEVIUS> I'm about to take www.ubuntu-ge.org domain and make it Ubuntu official support for georgian users
[01:21] <AlinuxOS> + setup Ubuntu LOCO team.
[01:23] <AlinuxOS> DEVIUS, let's try on #ubuntu-locoteams
[01:24] <AlinuxOS> maybe someone is alive :)
[01:33] <persia> Would anyone with a i386 and working GL be willing to test something for me?
[01:33] <Fujitsu> persia: Sure.
[01:34] <persia> Fujitsu: Thanks.  launch torcs, make sure your audio backend is set to openal, get around the first curve of the default course, and hit something (another car, the wall, etc.).
[01:35] <persia> It crashes on AMD64 due to differences in MMX compilation from gcc3.x to gcc4.x, and upstream's fix is really intrusive: I'm just not sure whether to disable the offending file for only AMD64 or for everything.
[01:35] <StevenK> Yay, torcs!
[01:35] <Fujitsu> Wow, torcs is fairly big.
[01:35] <StevenK> ... but MMX is just register fildding, how would amd64 kill it?
[01:36] <Fujitsu> StevenK: What would that be?
[01:36] <persia> StevenK: From what I can tell, there's a difference in the way that SIMD detection works with gcc 4.0 and optimisation, such that you need to have different #ifdef statements for newer compilers.
[01:36] <StevenK> % head -n 1 debian/control
[01:36] <StevenK> Source: virtualbox-ose-modules
[01:36] <StevenK> Fujitsu: ^
[01:37] <Fujitsu> StevenK: Aha.
[01:37] <StevenK> persia: But SIMD isn't MMX.
[01:37] <persia> StevenK: Huh?  MMX is one of many SIMD APIs.  Lead me...
[01:38] <StevenK> persia: MMX came first - SSE came after.
[01:38] <persia> StevenK: Yes.
[01:38] <StevenK> persia: I don't know much more than that, though. :-)
[01:40] <persia> StevenK: Ah.  From what I can tell looking at upstream CVS and the intel docs on MMX, MMX can be SISD or SIMD, but is usually SIMD, using packed registers (4 16-bits in a 64-bit).  It seems that newer gccs use a different set of controls to decide how to optimise.  If the code is written to the old MMX target, and doesn't have good runtime detection, it may get incorrectly optimised.
[01:40] <Fujitsu> persia: I've gone a fair way around the track, and managed to run into a lot of walls (I'm *so* great at such games), no crashing.
[01:41] <persia> Fujitsu: And this is with the openal audio backend, and with working sound?
[01:41] <Fujitsu> Yep.
[01:42] <persia> Fujitsu: Excellent.  Thanks for testing that.  I'll only disable MMX for x86_64 targets then,
[01:42] <Fujitsu> More `vroom, crash, skid, spin, oh look at that car that has lapped me for the second time'
[01:43] <persia> Fujitsu: You can choose everyone's cars if you want.  It's a little easier if you have a F1 and they have dune buggies.
[01:44] <Fujitsu> persia: I'm sure I'd still lose.
[01:44] <persia> Fujitsu: Then you have special skills :)
[01:44] <Fujitsu> Haha.
[01:45] <persia> StevenK: As the master of all library transitions: could you suggest any means to make sure that a modified libopenal0 works with all the rdepends without finding a way to expose the MMX issue in each game?
[01:46] <rexbron> persia: how goes it?
[01:46] <persia> rexbron: It appears that I've found an issue upstream fixed last march, but somehow never got merged.  If only it were earlier in the dev cycle...
[01:48] <rexbron> :(
[01:48] <rexbron> but it will be fixed upstream for hardy correct?
[01:49] <persia> rexbron: Depends.  Upstream hasn't actually had a release in a while, and is sponsored by Creative and Apple, so most of the development has been targeted towards Windows and Mac OS X.
[01:51] <rexbron> persia: best of luck (and lots of good work) then
[01:52] <persia> rexbron: Thanks.
[02:23] <persia> Anyone feel like packaging a 1-line SRU for Dapper?  #86212.
[02:25] <DktrKranz> hi persia, welcome back :)
[02:26] <persia> DktrKranz: Thanks.
[02:26] <DktrKranz> I looked at that bug, a user already provided a patch
[02:26] <DktrKranz> maybe he could do the job
[02:26] <DktrKranz> if not, I will be happy to manage myself
[02:26] <persia> DktrKranz: Right.  Someone just needs to make a Dapper debdiff, and go through the SRU process.  It's easy, but needs someone to watch it.
[02:27] <persia> (and verify the problem & solution in Dapper).
[02:27] <DktrKranz> no proble to verify it
[02:28] <persia> DktrKranz: Great.  Thanks.
[02:29] <DktrKranz> give me ten minutes, I have to finish a couple of things before...
[02:29] <persia> DktrKranz: No big rush.  The bug has been around for a while :)
[02:30] <DktrKranz> I see :)
[02:30] <DktrKranz> is it relevant for edgy too?
[02:31] <persia> DktrKranz: I'm not sure.
[02:31] <DktrKranz> ok, I'll check for edgy too
[02:51] <persia> rexbron: I've just taken a quick look at the genpo package.  You'll want to run the lintian and linda commands recommended in w.u.c/MOTU/Contributing on .dsc, and then on the .changes when you build it.  Remember to use `bzr export` :)
[02:53] <DktrKranz> persia, confirmed on Dapper, Edgy is affected too, could you please add a task?
[02:54] <persia> DktrKranz: added.
[02:54] <DktrKranz> that patch needs additional love
[02:54] <persia> DktrKranz: Yes it does :)
[02:55] <DktrKranz> at least, it requires an if clause to check if /var/run/smokeping is already present
[02:55] <DktrKranz> otherwise, it will raise an error
[02:56] <DktrKranz> I will report this to the user, asking if he want to manage those SRUs
[02:56] <persia> DktrKranz: I thought the -p took care of that.  Does it not work for the final directory?
[02:57] <DktrKranz> persia, IIRC it creates parent directories, not sure if it checks if the final one exists
[02:57] <persia> DktrKranz: I can't replicate any issues with breaking on existing directories with -p (even in dash)
[02:58] <DktrKranz> yes, it works
[03:40] <DarkMageZ> is there a way to get pbuilder to automatically generate -dbgsym packages of anything it builds?
[03:42] <DktrKranz> DarkMageZ, IIRC you can install pkg-create-dbgsym
[03:43] <DktrKranz> if you insert it into the default set, you should get them automatically
[03:43] <persia> DarkMageZ: Install pkg-create-dbgsym in the pbuilder chroot
[03:43] <DarkMageZ> ah, great :) ty
[04:21] <persia> Anyone with i386 and working GL willing to test the patch from bug #149806?  The test case is to compile and install a new libopenal0, start torcs, turn around the first bend, and crash into something.
[04:21] <ubotu> Launchpad bug 149806 in openal "OpenAL has unsafe MMX support on AMD64" [Undecided,New]  https://launchpad.net/bugs/149806
[04:23] <DarkMageZ> persia, i'll give it a shot
[04:23] <persia> DarkMageZ: Thanks.
[04:26] <DarkMageZ> persia, i've pulled the orig.tar.gz & diff.gz & .dsc, but how do i apply a debdiff? patch -p0 file didn't seem to be happy
[04:27] <persia> DarkMageZ: No?  Hmm.  Let me check that again...
[04:29] <DarkMageZ> persia, nvm. noob error on my part
[04:29] <persia> DarkMageZ: OK.  I was worried there :)
[04:31] <DarkMageZ> what was create the diff & dsc without signing again? it was something like debuild -us -uc
[04:31] <persia> DarkMageZ: exactly
[04:32] <persia> DarkMageZ: Alternately, you can use a pbuilder or sbuild (or deb-o-matic :) )
[04:32] <DarkMageZ> trippy. it says my system doesn't have the dependencies. i thought that command wasn't going to try and build it.
[04:32] <pkern> DarkMageZ: -S
[04:33] <persia> DarkMageZ: That command doesn't sign it.  -S doesn't build it.
[04:33] <pkern> DarkMageZ: Well it's called de*build*
[04:33] <DarkMageZ> ah, there it goes :) building.
[04:50] <DktrKranz> persia, deb-o-matic? did you use it in the past?
[04:51] <persia> DktrKranz: I remember looking at it a couple months ago, but I'm fairly fixed on sbuild for now.
[04:52] <jdong> bug 150130
[04:52] <ubotu> Launchpad bug 150130 in xserver-xgl "Xgl causes noise when scrolling" [Undecided,New]  https://launchpad.net/bugs/150130
[04:52] <DktrKranz> well, I started to write it just because I don't like wanna-build
[04:54] <persia> DktrKranz: Makes sense.  I don't have enough local package needs to get much beyond just building things, although I'll probably become more interested if I ever get more than one supported architecture working at once.
[04:55] <DktrKranz> it's a wanted feature, waiting for qemubuilder to became more stable
[04:55] <persia> DktrKranz: Now that's an interesting way to do it :)
[04:56] <DktrKranz> (I should have said waiting for qemubuilder AND qemu to become more stable, especially on sparc)
[04:57] <DktrKranz> I have kernel panics each time :(
[04:57] <persia> heh
[04:58] <pkern> What does deb-o-matic do?
[05:00] <DktrKranz> pkern, it's an automatic package builder. it uses pbuilder as engine. users upload source packages on a given directory with dput (or similar) and it gets them built
[05:01] <DktrKranz> it has some good features, others will come
[05:02] <pkern> Well I use reprepro for repository management. How does it determine what needs to be built?
[05:02] <DktrKranz> it has an "incoming queue"
[05:03] <DktrKranz> it scans it on a regular basis (by default every 60 seconds), determines which package should be built (based on priority)
[05:04] <DktrKranz> and, after updating pbuilder (if there is need to do so), it starts build process as pbuilder does
[05:04] <pkern> And update the chroot beforehand to grok updated builddeps?
[05:04] <pkern> Hm.
[05:04] <DktrKranz> it does only if archives has changed since last build
[05:05] <pkern> How does it "interface" with "archives"?
[05:06] <DktrKranz> when fetching packages or when checking if update is required?
[05:08] <pkern> I guess I'll look at the source next week. I want to get an amd64 autobuilder for our archive.
[05:09] <DktrKranz> well, it's not a professional tool now, just a toy for someone who has not time to wait for pbuilder to finish long builds :)
[05:11] <pkern> Well I need something asynchronous. I would be able to register new builds in reprepro hooks but here I would need to copy the package somewhere and get the result imported into reprepro again. (The latter could be solved if the built packages are placed into a seperate queue directory and the possiblity to call a script after each build to import it.)
[05:12] <pkern> And although we use PostgreSQL I still don't want to install dak and/or wanna-build ;)
[05:13] <pkern> Currently at 110 binary packages, more to come as Etch gets older.
[05:14] <DarkMageZ> persia, done. no odd results. cept for sound stuttering
[05:14] <DktrKranz> pkern, you can set a "incoming" directory as you wish, you will need source packages and related sources.changes file
[05:15] <DktrKranz> so, it won't bother reprepro
[05:15] <pkern> I don't have _source.changes currently.
[05:16] <pkern> That's another point. ;)
[05:16] <persia> pkern: No _source.changes?  How does that happen?
[05:16] <pkern> persia: It's Debian. We build it for i386.
[05:17] <pkern> Point is that we don't want the second step of shelling on another box and doing a -B build.
[05:17] <persia> DarkMageZ: Sound stuttering?  Does it do that with the libopenal0a from the repositories?
[05:17] <DarkMageZ> persia, yup. so that's not a regression :)
[05:17] <DktrKranz> pkern, you may want use a older release, when it used .dsc files to start build process
[05:18] <persia> DarkMageZ: OK.  Thanks.
[05:18] <pkern> DktrKranz: _<somerandomarch>.changes aren't that different ;) But I would have to dig into the code if that would be a solution for me.
[05:19] <pkern> It's a pity that Julien wrote rebuildd specific for the task of rebuilding packages.
[05:19] <DktrKranz> right, I would have used that
[05:19] <DktrKranz> instead of writing a buggy, unuseful, redundant piece of code :)
[05:20] <pkern> I mean probably that would be solved with a wrapper around apt-get source to apt-get update first.
[05:20] <pkern> And then enqueue the jobs after they got imported into the archive (and after an export of the lists obviously).
[05:21] <minghua> WTF is bug 150205
[05:21] <ubotu> Launchpad bug 150205 in baltix "Make menu items labels more consistent and clear" [Undecided,Invalid]  https://launchpad.net/bugs/150205
[05:22] <persia> minghua: Someone didn7t read the HIG, but noticed that it's not implemented 100%
[05:22] <pkern> minghua: Just a bit late?
[05:22] <pkern> persia: s/didn7t/did/?
[05:23] <persia> pkern: Ah.  ' is shift-7 on my keyboard layout, and I broke my finger this morning, so my typing's a bit funny.
[05:23] <pkern> I could still kill the Gnome devs for having merged Font into Appearance. /me grumbles.
[05:23] <minghua> persia: I wouldn't mind if he submit bugs to each package, but just one bug and subscribe everyone?
[05:23] <pkern> persia: There was also a change in the meaning in my question.
[05:23] <persia> minghua: I'd agree with that.  It's a per-package issue.
[05:24] <persia> pkern: Right.  The bug submitter's suggestions are closer to HIG, but not HIG compliant.
[05:24] <minghua> pkern: I personally like the new appearance dialog.
[05:24] <pkern> persia: k ;)
[05:24] <pkern> minghua: I use different Gnome versions.
[05:24] <pkern> (Yeah with that argument no change would be possible.)
[05:25] <minghua> heh.
[05:25] <pkern> Currently I'm on 2.14 ;)
[05:25] <minghua> persia: The bug reporter apparently doesn't realize those strings appear in other places as well, such as KDE and Xfce.
[05:26] <persia> minghua: I thought Xfce preferred HIG-compliant naming.  I don't know about KDE.
[05:27] <minghua> There is no FreeDesktop HIG as far as I know.
[05:29] <persia> Hrm.  There ought to be an abstraction of shared data.  http://developer.kde.org/documentation/standards/kde/style/basics/ and http://developer.gnome.org/projects/gup/hig/2.0/ really don't seem to match that closely.
[05:30] <minghua> That's exactly my point.
[05:31] <persia> From what I can tell, there'll be something new from KDE as part of KDE4 development (but I would think at least a draft would be somewhere by now...)
[05:31] <minghua> IMHO this is just lazy bug reporting, pointing out problems and hope others will do the hard work to fix it.
[05:32] <persia> minghua: Well, yes, but sometimes that's useful too.  There's quite a few things I've fixed only because someone complained.  On the other hand "won't fix" or "upstream" seem appropriate responses for the busy maintainer.
[05:33] <persia> (especially for such a badly filed bug)
[05:33] <minghua> I'm just attempted.  I'm not going to change it to "won't fix".
[05:34] <minghua> persia: Generally I don't mind lazy bug reporting, but this one makes me quite angry.
[05:34] <persia> minghua: You mean because the reporter didn't even bother to really firmly suggest alternatives, just whined about it?
[05:34] <minghua> If I change the scim part to "wishlist", and add comment about what should be done, I'll be spamming other maintainer.
[05:35] <persia> Ah, yes, making it useless for discussion.
[05:36] <minghua> persia: No, mainly the "throw everything in one report because it's easy for me" attitude.
[05:36] <proppy> hi
[05:37] <persia> Interestingly enough, there's a lot of traffic on the mailing lists, etc. that would imply that we prefer fewer bugs (we have too many to process), and there are several people who would start leaving "don't mass-file" comments if someone were to open a series of similar bugs, but for actual bug management, a targeted bug is much more useful.
[05:39] <pkern> Probably LP should support such meta bugs to easily track issues belonging together. \:
[05:40] <minghua> pkern: There isn't really much point about a meta bug.  Many other .desktop files don't have HIG-compliant name either, he reported those just because those are installed by default.
[05:40] <persia> pkern: Right, but how does one handle subscriptions?  I like to be subscribed to bugs I might fix, bugs I know how to fix that I might pass to someone, bugs in the packages I watch, and bugs I have on my system.  I have little interest in other bugs, and don't want to get discussion traffic in my mailbox for those.
[05:40] <minghua> persia: I skipped the whole thread about bug management. :-)
[05:41] <persia> minghua: That's probably for the best :)  Anyway, it was more about LP bug statuses than about few/many or meta/targeted.
[05:42] <minghua> Same with persia, especially since I put scim bugmails at a very high priority among my mailboxes, getting irrelevant discussions there really pisses me off.
[05:43] <minghua> persia: Yes, I know it starts from ScottK's "LP people shouldn't tell MOTUs what is the correct way to use LP". :-P
[05:43] <minghua> s/starts/started/
[05:44] <persia> minghua: I'd say it's more complicated than that, but it's not an important distinction.
[05:45] <minghua> I know I was over-simplifying.  Thus the smiley.
[05:46] <minghua> Hey, isn't Japan _the_ country of smileys?
[05:47] <minghua> ...on a second thought, that's probably why it's possible to enroll in a "graduate emoticon course". :-)
[05:48] <persia> minghua: Yep.  There's a heap of interesting examples in http://www.2chan.net/
[05:49] <persia> Or, better, http://2ch.net/
[05:52] <pkern> That looks so Japanese-ish.
[05:52] <persia> pkern: The best bit is that 90% of users are on 320x240 or less.
[05:57] <pkern> bigon: Is there anything particular in the aiccu updates that you want to see in Gutsy?
[06:05] <pkern> People continue to run into the fglrx+suspend issue. /me ponders to write a planet.u.c post.
[06:08] <persia> pkern: I believe an updated package has been prepared, and is waiting for merge (unless I completely fail to understand the issue: a distinct possibility)
[06:09] <pkern> persia: Uh, where what how?
[06:09] <pkern> persia: The only heared won't fix from various sides.
[06:09] <pkern> i.e. that gutsy will ship like that.
[06:09] <superm1> updated package, with what driver?  8.41 breaks any workstation cards
[06:09] <superm1> eg firegl
[06:10] <superm1> and it says in the release note for maintainers not to ship it
[06:11] <pkern> So it will be downgraded? I don't think that solves *that* issue I am talking about.
[06:12] <bigon> pkern: not really
[06:13] <pkern> 8.37.6 is in Gutsy
[06:13] <pkern> bigon: Aye, because I tend to NACK it. Simply because there isn't really a benefit and the risk of breakage at this point.
[06:13] <persia> pkern: Ah.  Nevermind.  I'm completely mistaken (xorg ati vs. ati frglx)
[06:15] <pkern> That issue I talk about is obviously not even considered release notes-worthy.
[06:15] <pkern> Bah.
[06:15] <pkern> But a post would probably be phrased too harsh.
[06:40] <pkern> How would I betatest Gutsy if I weren't at university... fetched one day full of updates (30M) in 5s. o_O
[07:36] <jdong> is the APSL or whatever license Apple Darwin's userspace is under considered kosher for Universe?
[07:37] <jdong> I'm considering packaging a bit of the HFS+ utils (namely fsck_hfs and newfs_hfs)...
[07:37] <jdong> as our current ones are nearly useless with Macpods and modern HFS volumes
[07:44] <pkern> bigon: The configuration/init script problem is not a regression.
[07:45] <pkern> Fun, I guess I need to revamp the debconf scripts next week. ;)
[08:12] <ScottK> jdong: Do you have a link to the license?
[08:13] <jdong> ScottK: http://www.opensource.apple.com/apsl/2.0.txt
[08:13] <jdong> APSL 2.0 AFAIK
[08:18] <ScottK> jdong: I think the patent provisions may be problematic.  The rest seems fine.  Not sure.
[08:19] <jdong> ScottK: interesting...
[08:19] <jdong> ScottK: I'll play around with the code a bit more; it's all BSD makefiles too.... gonna be "fun" to get it to build under Ubuntu :)
[09:07] <mssever> I'm developing a program that depends on libdaemonize-ruby. Someone recently complained that there is no such package in Gutsy. Since I'm not yet running Gutsy, can someone verify this and/or find the proper name for the gutsy package?
[09:08] <pkern> There's libdaemons-ruby...
[09:09] <pkern> Daemons provides an easy way to wrap existing ruby scripts (for example a self-written server) to be run as a daemon and to be controlled by simpl start/stop/restart commands. daemons can also run and control blocks of Ruby code in a daemon process.
[09:09] <mssever> Is that the same lib as libdaemonize?
[09:09] <pkern> That's what I ask you :-P
[09:09] <pkern> Don't know, at least there's no libdaemonize
[09:10] <mssever> pkern: hmm I'll look onto that
[09:12] <pkern> I don't find s.th. like daemonize on rubygems.
[09:12] <pkern> Just `daemons'.
[09:14] <mssever> Well, it appears that libdaemons-ruby isn't the same as libdaemonize-ruby--which is in feisty
[09:14] <mssever> Any chance of getting libdaemonize-ruby back in Gutsy?
[09:15] <pkern> mssever: See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428979
[09:15] <ubotu> Debian bug 428979 in ftp.debian.org "RM: libdaemonize-ruby -- RoM; superseded by libdaemons-ruby" [Normal,Open]
[09:17] <mssever> Thanks for that link. I guess I'll update the depends field of my package and see if I get bug reports...
[09:17] <pkern> Uh oh.
[10:51] <Kmos> bug 144258
[10:51] <ubotu> Launchpad bug 144258 in scribes "[UVFe]  Please sync scribes (universe) <IP_ADDRESS>-1 from Debian Unstable (main)" [Medium,New]  https://launchpad.net/bugs/144258
[10:51] <Kmos> need another ack and subscribe to ubuntu archive


[00:04] <Scary_Guy> nope, thanks!
[00:08] <Scary_Guy> also you can hear some great stuff on http://stream.laut.fm/panorama80
[00:19] <jrwren> your station?
[00:31] <Scary_Guy> no, just awesome
[00:32] <Scary_Guy> I consider VOIP about as useless as POTS, but yeah I meant VOIP
[00:33] <Scary_Guy> WOW is a great service, but I can't use my own cable modem if I'm using their VOIP service
[00:34] <Scary_Guy> the one they provide only does DOCSIS 2.0
[00:35] <Scary_Guy> I should probably call them but I hate talking to people, but the slow speed is getting to me
[00:55] <jrwren> that is pretty terrible.
[17:43] <cmaloney> Good morning... um... dammit.
[17:43] <cmaloney> Afternoon
[17:43] <greg-g> g'morning :)
[17:43] <_stink_> zing!
[18:17] <cmaloney> heh
[20:03] <cmaloney> ARe we having fun yet?
[20:05] <Scary_Guy> no, never
[20:05] <Scary_Guy> only moments where life sucks less
[20:07] <Scary_Guy> that said, bbl, I need to move my computer to a better spot because I actually need to burn about 20 disks, so I will need it in arms reach where I don't have to get up, ugh
[20:51] <greg-g> I'm digging https://www.mixcloud.com/BLACKYOGA/ lately
[20:51] <greg-g> "BLACK YO)))GA is vinyasa style yoga set to drone, noise, stoner metal, ambient, industrial, space doom, and other traditional meditation music."
[20:52] <greg-g> best. tagline. ever.
[20:52] <greg-g> (ok, maybe not ever, I just like it)
[20:53] <greg-g> oh right, it's quitting time for ya'll now
[21:09] <cmaloney> https://steveroach.bandcamp.com/album/vortex-immersion-zone-2 <- what I'm on right now
[21:10] <jrwren> steve roach still puts out albums eh?
[21:10] <cmaloney> Yep
[21:11] <jrwren> cool.
[21:11] <jrwren> i ahven't listened to him in 20yrs.
[21:11] <cmaloney> I'm a recent follower
[21:11] <jrwren> well, maybe slightly less.
[21:11] <cmaloney> he's been heavy in helping out soma.fm
[21:11] <jrwren> 99 or 00 ish I had a good friend really into him.
[21:13] <cmaloney> I can see the allure
[21:14] <cmaloney> Though I'm not a huge ambient fan
[21:16] <jrwren> yeah, I never really got into it.
[22:49] <jrwren> https://www.kickstarter.com/projects/1479338853/latitude-90-the-origin  best game evar?
[23:12] <greg-g> NP https://arcademessiah.bandcamp.com/album/ii
[23:13] <greg-g>  tags: experimental rock ambient doom metal instrumental metal post-metal post-rock progressive progressive metal stoner Hastings
[23:13] <cmaloney> That got onto my wishlist.


[00:31] -queuebot:#ubuntu-release- Unapproved: gnome-nettool (jammy-proposed/universe) [3.8.1-3build1 => 42.0-1] (no packageset) (sync)
[00:32] -queuebot:#ubuntu-release- Unapproved: accepted gnome-nettool [sync] (jammy-proposed) [42.0-1]
[01:27] -queuebot:#ubuntu-release- Unapproved: glibc (focal-proposed/main) [2.31-0ubuntu9.8 => 2.31-0ubuntu9.9] (core, i386-whitelist)
[01:55] <vorlon> jbicha: fyi because the old wpewebkit binaries didn't get removed before the source migrated, now britney is in an angry weird state and wants the binaries removed from the release pocket before it will migrate.  So, the revdeps all need to be sorted
[01:57] -queuebot:#ubuntu-release- Unapproved: cloud-init (jammy-proposed/main) [22.1-14-g2e17a0d6-0ubuntu1~22.04.4 => 22.1-14-g2e17a0d6-0ubuntu1~22.04.5] (core, ubuntu-cloud)
[02:05] -queuebot:#ubuntu-release- New binary: python-loompy [amd64] (jammy-proposed/universe) [3.0.6+dfsg-5] (no packageset)
[02:05] -queuebot:#ubuntu-release- New binary: python-loompy [s390x] (jammy-proposed/universe) [3.0.6+dfsg-5] (no packageset)
[02:06] -queuebot:#ubuntu-release- New: accepted python-loompy [amd64] (jammy-proposed) [3.0.6+dfsg-5]
[02:06] -queuebot:#ubuntu-release- New binary: python-loompy [ppc64el] (jammy-proposed/universe) [3.0.6+dfsg-5] (no packageset)
[02:06] -queuebot:#ubuntu-release- New: accepted python-loompy [s390x] (jammy-proposed) [3.0.6+dfsg-5]
[02:07] -queuebot:#ubuntu-release- New binary: python-epimodels [amd64] (jammy-proposed/universe) [0.3.20-1] (no packageset)
[02:07] -queuebot:#ubuntu-release- New: accepted python-epimodels [amd64] (jammy-proposed) [0.3.20-1]
[02:07] -queuebot:#ubuntu-release- New: accepted python-loompy [ppc64el] (jammy-proposed) [3.0.6+dfsg-5]
[02:08] -queuebot:#ubuntu-release- New binary: python-loompy [arm64] (jammy-proposed/universe) [3.0.6+dfsg-5] (no packageset)
[02:09] -queuebot:#ubuntu-release- New: accepted python-loompy [arm64] (jammy-proposed) [3.0.6+dfsg-5]
[02:36] <jbicha> vorlon: I don't understand. I guess you'll need to force out the 1.1 API binaries though
[02:37] <vorlon> jbicha: you are fixing the reverse-dependencies to build-depend on the new -dev package name?
[02:38] <jbicha> no, there isn't a new -dev package name any more. package names should match between https://launchpad.net/ubuntu/+source/wpewebkit/2.36.0-2ubuntu3 and https://launchpad.net/ubuntu/+source/wpewebkit/2.34.6-1
[02:38] <vorlon> hmm
[02:38] -queuebot:#ubuntu-release- Unapproved: xubuntu-artwork (jammy-proposed/universe) [22.04 => 22.04.1] (xubuntu)
[02:39] <vorlon> ok
[02:39] <vorlon> then maybe this will be fine as soon as the package is built on all archs
[02:39] <jbicha> I mean this looks very weird but hopefully temporary: wpewebkit-driver/amd64 has unsatisfiable dependency
[02:42] <vorlon> that may be because I misread something and removed the wrong binaries.  I'll restore them, but will wait until all the builds finish
[06:46] -queuebot:#ubuntu-release- Unapproved: wpewebkit (jammy-proposed/universe) [2.36.0-2ubuntu3 => 2.36.0-2ubuntu3] (no packageset) (sync)
[06:46] -queuebot:#ubuntu-release- Unapproved: accepted wpewebkit [sync] (jammy-proposed) [2.36.0-2ubuntu3]
[06:50] <vorlon> sergiodj: do you know why bind9-libs needs libnghttp2-14 (an implementation of HTTP/2)?  It's in https://people.canonical.com/~ubuntu-archive/priority-mismatches.html for promotion to 'standard', and this gives me doubts
[07:00] <cpaelzer> vorlon: the "why" is because since 1:9.17.10-1 it was added to build-dependencies. But I guess you probably ask more "what does it use it for" right?
[07:01] <cpaelzer> the feature this is for is called "doh"
[07:01] <cpaelzer> from configure "enable DNS over HTTPS, requires libnghttp2"
[07:02] -queuebot:#ubuntu-release- Unapproved: udisks2 (jammy-proposed/main) [2.9.4-1build1 => 2.9.4-1ubuntu1] (core, i386-whitelist)
[07:58] -queuebot:#ubuntu-release- New sync: bettercap (jammy-proposed/primary) [2.32.0-1]
[07:58] <LocutusOfBorg> leaf package ^^ really nice
[08:39] -queuebot:#ubuntu-release- Unapproved: budgie-desktop-environment (jammy-proposed/universe) [0.17.13 => 0.17.14] (personal-fossfreedom, ubuntu-budgie)
[09:16] -queuebot:#ubuntu-release- Unapproved: ubiquity (jammy-proposed/main) [22.04.12 => 22.04.13] (ubuntu-desktop)
[10:19] -queuebot:#ubuntu-release- New source: nullboot (focal-proposed/primary) [0.2.2-0ubuntu<IP_ADDRESS>]
[10:21] -queuebot:#ubuntu-release- New source: nullboot (focal-proposed/primary) [0.2.2-0ubuntu<IP_ADDRESS>]
[10:35] -queuebot:#ubuntu-release- Unapproved: cups-filters (jammy-proposed/main) [1.28.13-0ubuntu1 => 1.28.14-1] (desktop-core, ubuntu-server) (sync)
[11:00] -queuebot:#ubuntu-release- Unapproved: phpliteadmin (jammy-proposed/universe) [<IP_ADDRESS>-1 => <IP_ADDRESS>-2] (no packageset) (sync)
[11:00] -queuebot:#ubuntu-release- Unapproved: accepted phpliteadmin [sync] (jammy-proposed) [<IP_ADDRESS>-2]
[11:07] <mdeslaur> phpliteadmin fixes a security issue ^
[11:13] <amurray> fyi udisks2 (2.9.4-1ubuntu1) fixes the most prevalent crasher on https://errors.ubuntu.com/?release=Ubuntu%2022.04&period=day for jammy
[11:32] -queuebot:#ubuntu-release- Unapproved: libarchive (jammy-proposed/main) [3.5.2-1ubuntu1 => 3.6.0-1ubuntu1] (core, i386-whitelist)
[11:37] <sil2100> o/
[11:39] -queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal-gnome [source] (jammy-proposed) [42.0.1-1ubuntu2]
[11:47] <tobhe> Hey everyone! A new package I submitted was accepted into debian sid yesterday and I was wondering if it would be ok to sync to jammy
[11:48] <tobhe> the package in question is https://packages.debian.org/sid/opencu
[11:52] -queuebot:#ubuntu-release- New sync: mptcpd (jammy-proposed/primary) [0.9-1]
[11:54] <ginggs> tobhe: that sounds fine
[11:58] <mdeslaur> Could someone from the release team please ack tobhe and ginggs, and I'll sync it ^
[12:02] <ginggs> mdeslaur: i don't believe you need a release team ack before doing a sync
[12:02] <ginggs> (in this case)
[12:03] <mdeslaur> ginggs: I'm being polite :)
[12:03] <mdeslaur> ok, synced for approval then :)
[12:03] <mdeslaur> thanks ginggs
[12:03] <tobhe> ginggs mdeslaur: awesome, thanks!
[12:03] -queuebot:#ubuntu-release- New sync: opencu (jammy-proposed/primary) [3-2]
[12:08] -queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (jammy-proposed/universe) [22.04.12 => 22.04.13] (ubuntu-mate)
[12:09] -queuebot:#ubuntu-release- Unapproved: mate-desktop-environment (jammy-proposed/universe) [1.26.0+1ubuntu4 => 1.26.0+1ubuntu5] (ubuntu-mate)
[12:26] -queuebot:#ubuntu-release- Unapproved: golang-github-openshift-imagebuilder (focal-proposed/universe) [1.1.0-2 => 1.1.0-2ubuntu<IP_ADDRESS>] (no packageset)
[12:27] -queuebot:#ubuntu-release- Unapproved: golang-github-fsouza-go-dockerclient (focal-proposed/universe) [1.6.0-2 => 1.6.0-2ubuntu<IP_ADDRESS>] (no packageset)
[12:56] -queuebot:#ubuntu-release- Unapproved: xf86-input-wacom (jammy-proposed/main) [1:0.39.0-0ubuntu3 => 1:1.0.0-3ubuntu1] (desktop-core, xorg)
[12:56] <tjaalton> vorlon: ^ bug 1968167
[13:08] -queuebot:#ubuntu-release- Unapproved: python-biom-format (jammy-proposed/universe) [2.1.10-3build1 => 2.1.10-3ubuntu1] (no packageset)
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted python-biom-format [source] (jammy-proposed) [2.1.10-3ubuntu1]
[13:17] <juliank> sil2100: so we can either reject the nullboot focal SRU (first one in any case), or accept it and fix the lintian error later, but I think it's blocking the MIR, but maybe there are more bugs to fix anyway, and we can move ahead with prepping the MIR (or should we MIR first?)
[13:17] <juliank> sil2100: I think the error would block the MIR, but also not sure
[13:21] <sil2100> juliank: I guess the copyright-not-using-common-license-for-gpl fix should be rather quick and straightforward, no?
[13:23] <sil2100> vorlon, amurray: hey! You both pushed udisks2 into the jammy queue with the same version number and overwriting your own changes - I'll accept vorlon's version first as it was first
[13:23] <sil2100> amurray: can you rebase on top of it?
[13:23] <amurray> bah can ubuntu-archive or a release team member? please delete/reject or whatnot my udisks2 2.9.4-1ubuntu1 (id 28340500) from the unapproved queue - I hadn't realised vorlon already had one of the same version there ahead of me - thanks
[13:24] <sil2100> Did that just now!
[13:24] -queuebot:#ubuntu-release- Unapproved: accepted udisks2 [source] (jammy-proposed) [2.9.4-1ubuntu1]
[13:24] <sil2100> ^
[13:24] -queuebot:#ubuntu-release- Unapproved: rejected udisks2 [source] (jammy-proposed) [2.9.4-1ubuntu1]
[13:24] <amurray> sil2100: heh I just saw your message as I typed that now
[13:24] <sil2100> :)
[13:24] <amurray> thanks
[13:25] -queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop-environment [source] (jammy-proposed) [0.17.14]
[13:25] -queuebot:#ubuntu-release- Unapproved: accepted libadwaita-1 [source] (jammy-proposed) [1.1.0-1ubuntu2]
[13:25] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (jammy-proposed) [22.1-14-g2e17a0d6-0ubuntu1~22.04.5]
[13:25] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-artwork [source] (jammy-proposed) [22.04.1]
[13:25] -queuebot:#ubuntu-release- Unapproved: accepted cups-filters [sync] (jammy-proposed) [1.28.14-1]
[13:26] -queuebot:#ubuntu-release- Unapproved: accepted mate-desktop-environment [source] (jammy-proposed) [1.26.0+1ubuntu5]
[13:26] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-settings [source] (jammy-proposed) [22.04.13]
[13:28] -queuebot:#ubuntu-release- Unapproved: accepted libarchive [source] (jammy-proposed) [3.6.0-1ubuntu1]
[13:30] <sil2100> hmmmm, this libwacom thing, I always am a bit worried when I see a bump from 0.x to 1.0
[13:31] <sil2100> Let me take a look at what changed
[13:45] <tjaalton> sil2100: look at the bug
[13:51] <tjaalton> the new maintainer seems to like pristine-tar, so the diff has autoconf crap all over
[13:52] <tjaalton> (debian maintainer)
[14:24] -queuebot:#ubuntu-release- Unapproved: evince (jammy-proposed/main) [42.1-1 => 42.1-2] (ubuntu-desktop) (sync)
[14:33] <vorlon> cpaelzer: thanks.  And I assume you (/server team) consider DNS over HTTPS an important feature to have enabled here, even though it's not the common case?
[14:33] <athos> Hi, would anyone mind taking a look at this FFe https://bugs.launchpad.net/ubuntu/+source/cl-plus-ssl/+bug/1960615 ? It introduces a few upstream patches to support OpenSSL 3
[14:41] <rbasak> sil2100: o/ I'm going to look at mysql-8.0 in the SRU queues as I only managed to get half way through during my shift yesterday and I'd like to finish it off. Unless you're already doing it
[14:41] <cpaelzer> vorlon: a feature that we want to be "possible" yes
[15:00] <vorlon> cpaelzer: thanks, no further questions and priority-mismatches is now cleaned up for jammy release
[15:08] -queuebot:#ubuntu-release- Unapproved: swtpm (jammy-proposed/main) [0.6.3-0ubuntu1 => 0.6.3-0ubuntu2] (no packageset)
[15:09] -queuebot:#ubuntu-release- Unapproved: accepted swtpm [source] (jammy-proposed) [0.6.3-0ubuntu2]
[15:58] -queuebot:#ubuntu-release- Unapproved: v4l2loopback (jammy-proposed/universe) [0.12.5-1ubuntu3 => 0.12.5-1ubuntu4] (kernel-dkms, ubuntustudio)
[16:07] -queuebot:#ubuntu-release- Unapproved: accepted mysql-8.0 [source] (impish-proposed) [8.0.28-0ubuntu<IP_ADDRESS>]
[16:08] -queuebot:#ubuntu-release- Unapproved: accepted mysql-8.0 [source] (focal-proposed) [8.0.28-0ubuntu<IP_ADDRESS>]
[16:10] <vorlon> doko: you synced a new upstream version of mercurial from Debian post-FF and it FTBFS everywhere?
[16:15] -queuebot:#ubuntu-release- Unapproved: rnp (jammy-proposed/universe) [0.15.2-6 => 0.15.2-6build1] (no packageset)
[16:16] -queuebot:#ubuntu-release- Unapproved: accepted rnp [source] (jammy-proposed) [0.15.2-6build1]
[16:19] <vorlon>  libsbig     | 4.9.9-1 | jammy-proposed/multiverse | source
[16:19] <vorlon>  libsbig-dev | 4.9.9-1 | jammy-proposed/multiverse | amd64, armhf, ppc64el, riscv64, s390x
[16:19] <vorlon>  libsbig4    | 4.9.9-1 | jammy-proposed/multiverse | amd64, armhf
[16:19] <vorlon> ... wut
[16:26] <vorlon> and similar behavior from libinovasdk!  what the what
[16:27] <vorlon> ... same maintainer
[16:27] <Eickmeyer> Holup... a devlib that can't install the actual bin on a certain architecture?
[16:27]  * Eickmeyer facepalms hard
[16:33] -queuebot:#ubuntu-release- Unapproved: freeipa-healthcheck (jammy-proposed/universe) [0.9-1 => 0.10-1] (no packageset) (sync)
[16:33] -queuebot:#ubuntu-release- Unapproved: accepted freeipa-healthcheck [sync] (jammy-proposed) [0.10-1]
[16:37] -queuebot:#ubuntu-release- New source: rpiboot (jammy-proposed/primary) [0~20220315+git6fa2ec0+nowin-0ubuntu1]
[17:27] -queuebot:#ubuntu-release- Unapproved: neutron (jammy-proposed/main) [2:20.0.0-0ubuntu2 => 2:20.0.0-0ubuntu3] (openstack)
[18:56] <Eickmeyer> Would somebody be so kind as to trigger a rebuild of the Ubuntu Studio image and hope it doesn't fail this time?
[19:01] <vorlon> I tried to look at references to 'unsatisfiable dependency' in update_excuses, and it's 90% rust, so now I'm just going to go drink my sorrows
[19:01] <vorlon> Eickmeyer: do you have access to retrigger through the ISO tracker?
[19:02] -queuebot:#ubuntu-release- New sync: rust-xkbcommon-sys (jammy-proposed/primary) [0.7.5-1]
[19:04] -queuebot:#ubuntu-release- New: accepted rust-xkbcommon-sys [sync] (jammy-proposed) [0.7.5-1]
[19:04] <Eickmeyer> vorlon: I do, but not if my last retrigger failed.
[19:05] <vorlon> huh
[19:05] <seb128> could we get a late ffe review on bug #1968215
[19:06] <seb128> it's an important part of the firefox migration to the snap we planned to land since the begin of the cycle
[19:06] <seb128> we just have been struggling with the resources we have to get ready earlier
[19:07] <cjwatson> I proposed a change earlier today that would make builders fail to reset rather than coming up with broken metadata and thus producing failing livefs builds.  Given the reset failure rate I suspect this will merely make a different set of people unhappy, but maybe ...
[19:07] -queuebot:#ubuntu-release- New binary: rust-xkbcommon-sys [amd64] (jammy-proposed/universe) [0.7.5-1] (no packageset)
[19:07] -queuebot:#ubuntu-release- New binary: rust-xkbcommon-sys [s390x] (jammy-proposed/universe) [0.7.5-1] (no packageset)
[19:08] -queuebot:#ubuntu-release- New binary: rust-xkbcommon-sys [ppc64el] (jammy-proposed/universe) [0.7.5-1] (no packageset)
[19:10] -queuebot:#ubuntu-release- Unapproved: gnome-session (jammy-proposed/main) [42.0-1ubuntu1 => 42.0-1ubuntu2] (ubuntu-desktop)
[19:14] -queuebot:#ubuntu-release- New binary: rust-xkbcommon-sys [armhf] (jammy-proposed/universe) [0.7.5-1] (no packageset)
[19:15] -queuebot:#ubuntu-release- New: accepted rust-xkbcommon-sys [amd64] (jammy-proposed) [0.7.5-1]
[19:15] -queuebot:#ubuntu-release- New: accepted rust-xkbcommon-sys [ppc64el] (jammy-proposed) [0.7.5-1]
[19:15] -queuebot:#ubuntu-release- New binary: rust-xkbcommon-sys [arm64] (jammy-proposed/universe) [0.7.5-1] (no packageset)
[19:15] -queuebot:#ubuntu-release- New: accepted rust-xkbcommon-sys [armhf] (jammy-proposed) [0.7.5-1]
[19:15] -queuebot:#ubuntu-release- New: accepted rust-xkbcommon-sys [s390x] (jammy-proposed) [0.7.5-1]
[19:47] -queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (jammy-proposed/universe) [22.04.14 => 22.04.15] (ubuntu-mate)
[20:12] -queuebot:#ubuntu-release- Unapproved: booth (jammy-proposed/universe) [1.0-237-gdd88847-4ubuntu1 => 1.0-237-gdd88847-4ubuntu2] (no packageset)
[20:13] -queuebot:#ubuntu-release- Unapproved: accepted booth [source] (jammy-proposed) [1.0-237-gdd88847-4ubuntu2]
[20:48] -queuebot:#ubuntu-release- Unapproved: crmsh (jammy-proposed/main) [4.3.1-1ubuntu1 => 4.3.1-1ubuntu2] (ubuntu-server)
[20:57] -queuebot:#ubuntu-release- Unapproved: pcs (jammy-proposed/universe) [0.10.11-2ubuntu2 => 0.10.11-2ubuntu3] (no packageset)
[20:58] -queuebot:#ubuntu-release- Unapproved: accepted pcs [source] (jammy-proposed) [0.10.11-2ubuntu3]
[21:30] -queuebot:#ubuntu-release- Unapproved: udisks2 (jammy-proposed/main) [2.9.4-1ubuntu1 => 2.9.4-1ubuntu2] (core, i386-whitelist)
[21:37] <amurray> ^^^ udisks2 upload fixes the current most frequent error report on errors.ubuntu.com for jammy - can this please be approved? thanks
[22:07] <vorlon>  python3-mlpack : Depends: 3.10 but it is not installable
[22:07] <vorlon> folks
[22:07] <vorlon> srsly
[22:55] -queuebot:#ubuntu-release- Unapproved: lorene (jammy-proposed/universe) [0.0.0~cvs20161116+dfsg-1ubuntu8 => 0.0.0~cvs20161116+dfsg-1ubuntu9] (no packageset)
[22:56] -queuebot:#ubuntu-release- Unapproved: accepted lorene [source] (jammy-proposed) [0.0.0~cvs20161116+dfsg-1ubuntu9]
[22:57] -queuebot:#ubuntu-release- New source: mlpack (jammy-proposed/primary) [3.4.2-5build1]
[23:02] -queuebot:#ubuntu-release- New: accepted mlpack [source] (jammy-proposed) [3.4.2-5build1]
[23:34] <vorlon> seb128: fyi the i386 seed (like all seeds) works on binary package names, not source package names; updated to list libjxr0 instead of jxrlib, so that this doesn't accidentally get redemoted
[23:44] -queuebot:#ubuntu-release- Unapproved: systemd (jammy-proposed/main) [249.11-0ubuntu2 => 249.11-0ubuntu3] (core, i386-whitelist)
[23:54] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (jammy-proposed) [249.11-0ubuntu3]


[05:09] -queuebot:#ubuntu-release- New binary: yazpp [amd64] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
[05:09] -queuebot:#ubuntu-release- New binary: yazpp [ppc64el] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
[05:09] -queuebot:#ubuntu-release- New binary: yazpp [i386] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
[05:09] -queuebot:#ubuntu-release- New binary: yazpp [s390x] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
[05:10] -queuebot:#ubuntu-release- New binary: yazpp [arm64] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
[05:10] -queuebot:#ubuntu-release- New binary: yazpp [armhf] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
[06:14] <infinity> slangasek: That's almost sure to be linux-libc-dev.
[06:16] <infinity> slangasek: Possibly a missing CONFIG_KEXEC_FILE
[06:16] <infinity> Though, that seems to be enabled.
[06:20] <infinity> slangasek: Oh, no.  Other way around.  4.11 wired up that syscall, so linux-libc-dev exposes it, but the testsuite assumes the running kernel should also have it.
[06:20] <infinity> slangasek: I think.
[15:23] -queuebot:#ubuntu-release- Unapproved: gjs (zesty-proposed/universe) [1.48.3-0ubuntu0.1 => 1.48.4-0ubuntu0.1] (desktop-extra, mozilla, ubuntugnome)
[17:28] <infinity> slangasek: Fix uploaded.
[17:31] <infinity> slangasek: And forwarded.
[21:36] <slangasek> infinity: cheers!
[23:27] <slangasek> looks like someone's been retrying neutron/s390x autopkgtest a fair bit; any reason to believe this is eventually going to pass?  (also, why is the test against the -proposed version of neutron?)
[23:28] <slangasek> the autopkgtest could certainly do with more useful output than 'see journalctl -xe for details'
[23:50] <slangasek> right, passed now with the artful neutron (by hinting to install iptables from -proposed)


[13:02] <jrwren> "LXD 3.1 will only be made available as a snap package. We will not be uploading it as a deb to Ubuntu 18.10 or through backports to previous releases."
[13:03] <jrwren> Well, then does it really exist then?  :)
[13:06] <cmaloney> jrwren: They still have some backports
[13:07] <cmaloney> but yeah,if they wanted to kill LXD this would be the way to do it
[13:07] <cmaloney> but w/e.
[13:46] <jrwren> yeah, its dead. it is snap only from this point forward.
[13:47] <jrwren> I'm sure it will continue because some canonical customer is using it, but its not a growth product.
[13:47] <rick_h_> I don't know, it has a large user base outside of ubuntu
[13:47] <jrwren> Its true. I only mean that it is dead to me. :)
[13:48] <jrwren> People will do ANYTHING to get their spotify on the desktop.
[13:48] <rick_h_> lol
[13:48] <rick_h_> I meant lxd vs snaps
[13:48] <rick_h_> lxd is used outside of ubuntu
[13:48] <jrwren> oh! duh.
[13:48] <jrwren> lol. I should go back to bed :)
[13:48] <rick_h_> snaps, yea I guess that's getting some outside ubuntu traction
[13:49] <jrwren> I can only barely imagine LXD being the right solution for things. I think it is because it is a little niche and I have poor imagination.
[13:50] <jrwren> I'm just bitter becasue I really like LXD but I really dislike snap. I feel like they are taking it away from me.
[13:50] <rick_h_> actually with the gpu pass through and such it's big in HPC atm
[13:51] <rick_h_> we've got several folks poking at it as a lot faster than VMs for scale but more useful than a docker container
[13:51] <jrwren> Makes sense.
[14:21] <brousch> We use LXC, but not LXD
[14:32] <cmaloney> LXD is really nice. I like LXD a lot
[14:32] <cmaloney> It's the quickest way for me to spin up a "what does this do" machine
[14:32] <cmaloney> but if LXC / LXD weren't available I'd probably switch to Vagrant
[14:35] <cmaloney> Thing is by making it snaps only they've essentially told the world "you have to be all-in to the Ubuntu way of doing things"
[14:35] <cmaloney> and that hasn't worked well in the past
[14:36] <cmaloney> It might have worked had Docker not completely changed how folks think about containers
[14:36] <cmaloney> And by changed I mean become synonymous with
[17:46] <jrwren> https://www.gnu.org/software/guix/blog/2018/tarballs-the-ultimate-container-image-format/ lol
[17:55] <cmaloney> jrwren: Search your feelings. You know it to be true
[17:58] <jrwren> its pretty close to true.