[00:01] 3767 root 20 0 2140 332 256 R 35.0 0.0 10763:24 udevd [00:02] ^-- That seems less than ideal. [00:04] I have definitely SRUed pidgin for ICQ protocol changes in the past [00:04] but they were cherry pickable IIRC, indeed [00:10] cjwatson: alt-drag ftw [00:24] lamont: alt-middle also resizes === JackyAlcine is now known as SaintJackyAlcine === SaintJackyAlcine is now known as JackyAlcine === dendrobates is now known as dendro-afk === EvilJackyAlcine is now known as JackyAlcine === dendro-afk is now known as dendrobates [06:26] Good morning [06:26] slangasek: black/white screen> it's there as a work item, but I don't recall who wanted to look into it; it's assigned to me for now, and I can test it on my two laptops [06:26] dupondje: oh, papyon take III? [07:02] pitti: any thoughts on bug #852603? part of me wants to advocate an sru since it would fix network compatibility for the game, but the rest of me can't get over how terrible of an idea that is [07:02] Launchpad bug 852603 in Oneiric Backports "Please backport hedgewars (0.9.16-1) from precise to oneiric" [Undecided,Incomplete] https://launchpad.net/bugs/852603 [07:09] broder: TBH I'm not that concerned about SRUing 0.9.16/.17 [07:10] it's a leaf app, it needs to be kept up to date with the online network version, and there's not much regression potential, or is it? [07:11] i don't think there's a whole lot of regression potential, but it doesn't really seem like they make a separation between bugfixes/features in their point releases [07:12] well, that's not true - they actually indicate them differently in the changelog, but they don't keep the new features out [07:12] yeah; but I guess most games are like that [07:12] ok. well, if you're ok with it, i'll arrange an sru once 0.9.17 lands in precise [07:12] * RAOF wonders if there should be a standing SRU exception for games of all kinds. [07:12] * micahg thinks that sounds like trouble [07:13] Possibly on the “lots of work for us” front, yes. [07:13] * micahg thinks of someone wanting gnome-games 3.2 in lucid :-/ [07:13] i thought we had been working on a standing exception for "things that broke because of changes in other systems on the internet" or some such, but i didn't remember it actually getting settled [07:14] that was discussed in the context of ubuntuone stuff [07:14] but in general SRU exceptions are granted for these kinds of software [07:14] as changing server protocols obviously breaks the current version in the archive [07:14] which clearly falls under the "regression" SRU policy [07:15] * broder nods [07:15] that said, focussed patches there are still preferred [07:15] OTOH updating it means any local servers need to be updated too [07:15] and we usually require them for stuff like empathy plugins or server-ish stuff [07:15] but for games I think we don't need to be as strict [07:16] tumbleweed: if we have the local server software packaged, yes; that usually doesn't apply to things like "msn is broken" [07:16] (a current SRU which we have right now) [07:17] pitti: of course. And I think in hedgewars, there are many public servers that run the latest version [07:20] I seem to recall my university's hedgewars-playing group distributing their own version of the game that matched their server (which was certainly newer than the lucid in the labs) [07:22] on the plus side, hedgewars in lucid is only several "point releases" behind - no minor releases even [07:40] cjwatson, Daviey, slangasek: from the desktop team POV we'd like to re-enable apport in precise soon; when would be a good time for foundations/server? [07:41] that's for picking up and reporting crashes [07:56] good morning [07:58] dholbach: Yo! GM. :) [07:58] Daviey: What are you on about? [07:58] hey lag [07:58] how's life over there? [07:59] dholbach: hallo [08:00] hey sladen :) [08:01] dholbach: Cold and drab, and there? [08:01] cold as well, but here the sun is shining [08:09] somebody painted all the Millbank windows white [08:11] tkamppeter_: ping === smb` is now known as smb [08:51] tsdgeos, hi === tkamppeter_ is now known as tkamppeter [08:52] tkamppeter: you opened a bug about "Okular should print PDF instead of Ghostscript" [08:52] rgiht? [08:53] tsdgeos, I asked someone to open it. We must do s/Ghostscript/PostScript/ in the title. [08:54] tsdgeos, can you post the number of the bug here? [08:54] tkamppeter: https://bugs.kde.org/show_bug.cgi?id=286825 https://bugs.launchpad.net/ubuntu/+source/okular/+bug/891199 [08:54] KDE bug 286825 in general "Okular should generate PDFs when printing instead of GhostScript" [Wishlist,Unconfirmed] [08:54] Launchpad bug 891199 in okular (Ubuntu) "Okular sends print jobs in PostScript format" [Medium,Confirmed] [08:54] tkamppeter: i disagree totally this is a bug [08:55] and if ubuntu is failing to print the ps files we generate, well, then that's an ubuntu bug [08:57] tsdgeos, it was generally agreed on to send print jobs in PDF format, especially all GTK applications, LibreOffice, Firefox, Thunderbird, and all the other KDE/Qt applications send PDF. [08:57] "generally agreed" by who? [08:57] and even if it was "generally agreed" [08:58] does that "general agreement" also include the clause "and while we do that let's make printing PS fail" [08:58] because if i read correctly the ubuntu bug, the problem is more like that "ps printing fails" not that "okular does not print to pdf" [08:59] tsdgeos, CUPS in Debian and Ubuntu does PDF-based printing for years and from CUPS 1.6 on PDF-based filtering will be upstream standard. [08:59] so? [08:59] i am sending a file with .ps extension [08:59] cups started being stupid and decides to treat it as a pdf? [09:00] I thought cups had a ps2pdf filter for that case? [09:00] tsdgeos, no one made PS printing fail intendedly, and I amm all the time working with the Ghostscript people to fix bugs in any PDF->PS, PS->PDF, PS/PDF->CUPS-Raster conversion. [09:00] tkamppeter: good, then don't make it seem like if it is Okular having a bug ;) [09:01] tsdgeos, the PostScript printing bug mentioned here got fixed in upstream Ghostscript today and I will prepare an SRU for Oneiric. [09:01] awesome :) [09:01] well, okular should still send PDF [09:02] sure [09:02] but that's a wish [09:02] not a bug [09:02] okular converting PDF to PS, and then cups PS back to PDF is a bit pointless? [09:02] tsdgeos: right [09:02] pitt, CUPS has the filter, but there was a Ghostscript bug which prevented correct conversions of files with certain fonts. This is fixed now and will get SRUed to Oneiric. [09:02] tkamppeter: nice [09:02] i.e. if people complains Okular prints wrong, is not because we do not print to pdf, it's because lpr stopped knowing how to print PS [09:03] tkamppeter: I'm... totally baffled. are you aware there are these tnings called postscript printers? why would a viewer which supports PS convert that .ps to a pdf when printing to a postscript printer? that's MADNESS [09:03] tsdgeos, the upstream report on Okular is not done by me, perhaps the user did not know how to mark it as feature request. [09:03] tkamppeter: while we are on this, do you know how can know if cups is "pdf aware" ? [09:03] Chipzz: that's not what we said, though? [09:04] Chipzz: if you are viewing a PDF document, it should be sent as PDF instead of being converted twice [09:04] Chipzz: the thing is we (Okular) convert PDF to PS for printing, this could be "shortcircuited" with the "new" cups [09:04] tsdgeos, CUPS is always PDF-aware as it has a pdftops filter. [09:05] tkamppeter: i don't want it going through a filter, because if it goes through a filter, and the output is different from the things in screen, people will blame me, not cups [09:05] which otoh sounds nice since i can just forward all printing bugs to cups :D [09:06] well, in an ideal world all of these flows should work, so if they differ, there certainly is a bug [09:06] so if you convert PDF to PS, and they both look identical, but print wrongly, that's a cups bug no matter which format it prefers internally [09:07] (well, "cups" in a wide sense -- bug in anything in the filter chain) [09:07] pitti: right. I'm not sure what makes pdf a better format for printing than ps though [09:09] Chipzz: in general scaling, printing 4-on-1 etc. works a lot more robustly with PDF [09:10] tsdgeos, all conversions specific to the printer should be done by CUPS, not by the apps, so the app does not need to know whether a printer is PS or not. So let the PDF viewer simply send PDF and if the printer is actually PostScript CUPS does the needed conversion. [09:10] tsdgeos, one could add a comfigurable setting to Okular, to decide whether it sends PS or PDF. In the Debian and Ubuntu packages one lets default it to PDF, from CUPS 1.6.x on one default generally to PDF. [09:10] tkamppeter: the other side of the equation is systems without cups, i guess there you still need to print to ps [09:10] tsdgeos, with the configurable setting no problem. Let it default to PS if there is no libcups available. [09:10] asking to the user if he wants to print to ps or pdf seems like an over-configuration setting [09:10] my father would not know what to do with it [09:11] * Chipzz wonders if anyone has ever done 'cat foo.ps > /dev/lpr' :) [09:11] tsdgeos: it's not configuration at all indeed, it's an internal implementation detail [09:11] tsdgeos: this only makes sense for printing into a file === popey_ is now known as popey [09:12] tsdgeos, it must have a reasonable default. Perhaps it does not even need to be in the user settings. As far as I know there is already such a switch as build time switch for other Qt apps, making Qt send PDF in case of CUPS (libcups from a certain version on) being present and PS afterwards. [09:12] s/afterwards/otherwise/ [09:13] tsdgeos, in addition a ./configure option allows the distro packager to change the default. [09:14] yeah, i'll think about it [09:15] otoh it's kind of a lot of work to make something that works, work :D [09:17] I think it'd be easier to send PS as PS and PDF as PDF [09:17] but anyway, let's just unbreak PS, then it doesn't matter much [09:18] sure, if you would not have to account for systems where printing PDF is not a feature [09:19] tsdgeos, see also http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format [09:20] tkamppeter: yes, Okular works on "non linux systems", so telling me the linux foundation decided something, is not a reason good enough to punish freebsd users [09:21] isn't that more a question of the printer spooler than the kernel? [09:21] yes [09:21] cups works just as well on BSD, given that it's developed by Apple [09:21] tsdgeos, so it should decide on the presence of Linux and libcups at build time. [09:21] tkamppeter: tbh that doesn't make much sense to me [09:21] tkamppeter: a distro could choose always to compile against libcups [09:22] while the user can choose not to install cups [09:22] can you "detect" if there's sth at the other end of the line with libcups? [09:22] afaik not [09:22] Chipzz, and if the distro compiles against CUPS, the app could get built so that it sends PDF. [09:22] everyone just installs something called "lpr" [09:23] tkamppeter: you... are missing the point [09:23] and there's not even a way to run lpr -v or something to know who you are talking to [09:24] Chipzz, you mean auto-detecting whether the local system runs a CUPS daemon, an LPD daemon or whatever and then decide at run time which format to send? [09:24] yes [09:25] the LP protocol doesn't have anything like "supported formats"? [09:25] tkamppeter: *compiling* against libcups is a distro choice. installing cups itself is a user choice [09:25] pitti: I don't have any particular blocker for re-enabling apport [09:25] Chipzz, the print dialog of Okular shows the CUPS queues, so it has recognized that we use CUPS, so we could send PDF in such a case. [09:26] tkamppeter: if you convince the Qt people to expose all that information they have so i can use it, you'll be my hero [09:27] tsdgeos, once somehow it works for the other KDE/Qt apps, and second, if there is no way for the app to find out whether it is used with CUPS or not, let us at least support the distros which ship with CUPS by adding a build-time option so that packagers can easily make Okular sending PDF. [09:29] tkamppeter: Okular is not the "typical" KDE/Qt application in the sense we can't use QPrinter since it does not expose lots of stuff (and that's why you'd be my hero if you get Qt dudes to expose it) [09:31] tsdgeos, so let us do the build-time option, so the packagers of the CUPS distros can simply do something like "./configure --with-pdf-printing" and Okular perfectly integrates with these distros. [09:31] yep [09:31] as said looks like a sane idea [09:31] just need to get the time to implement it :-) [10:12] is it me or is it libtiff4-dev uninstallable? [10:13] works fine here (current precise) [10:13] in oneric it seems to want libjpeg-dev that seems to not exist [10:14] probably asking in the wrong channel :D [10:14] tsdgeos: libjpeg6b-dev [10:15] libjpeg-dev is a virtual packate that libjpeg6b-dev provides [10:15] in precise it's provided by libjpeg8-dev [10:15] i see [10:16] much better now [10:16] tx [10:18] hey wendar - do you think you can clarify my action in https://blueprints.launchpad.net/ubuntu/+spec/community-p-app-review-board? I'm not quite sure what I'm supposed to do :) [10:28] hey, I am working on a package for massif-visualizer and would like to provide a man page for it, is it acceptable to generate the manpage using a tool like help2man, pandoc or asciidoc? [10:28] yes, although IMO that's the bare minimum for a manual page rather than something that's actually good [10:29] (help2man that is; no experience with pandoc or asciidoc) [10:29] help2man really just gives a good starting point for a manpage, but yeah, maintaining a manpage in rst can be easier than nroff (and harder for tricking formatting) [10:29] it's certainly fine to generate manual pages from other formats in general [10:31] I thought help2man was a formatting tool, now that I see what it does, I realize it would not be appropriate [10:32] tumbleweed: are there example of debian packages which maintain generated man pages? (I mean man pages provided by the packager, not by upstream) [10:33] loads of them [10:34] * tumbleweed greps thtrough the source packages on his working directories, and finds namebench, springpython, tweepy [10:34] tumbleweed: azeem: thanks [10:38] POD is a good format to generate these from too [10:38] since we've already gone through the process of making sure its output is actually of decent quality [10:38] (i.e. pod2man) [10:39] I think I would advise that by preference over tools where we haven't yet gone through that process [10:43] isn't the docbook2man thing which dh_make puts as template quite ok as well? [10:58] azeem: it's had fairly bad problems in the past, although I think most of them got sorted out. Still, I can't recommend something that involves humans writing XML [11:11] jelmer: hey, the symbol versioning of libldb doesn't seem to work, since sssd needs a rebuild every time ldb is updated.. [11:15] tjaalton: it works for libary users, not for plugins IIRC [11:15] jelmer: hmm right [11:16] i'll modify the package to depend on the libldb1 version that it was built against.. === _salem is now known as salem_ [11:26] Can someone point me in the direction of an development program I should use to develop a single linux program I will run on a machine with ubuntu installed? The program displays images from the internet, very much alike a photoframe. Except it has no user interface on the device [11:27] The linux machine will have to boot and start the program. It needs to do nothing else (except when I need to access it for maintenance) [11:29] xruud: please pretty please read the topic [11:29] (and not just in this channel, but in ANY channel you join) [11:32] thanks jelmer [11:32] xruud - #ubuntu-app-devel please === dholbach_ is now known as dholbach [12:04] cnd: around? the way to look for hid messages is using an application called PackageLogger? if so does it come in xcode package? [12:06] Chipzz [12:06] Chipzz: sorry, irc is new to me, believe it or not. [12:06] brendand: thanks [12:37] didrocks: my branch for fixing bug 785101 has just been merged into unity-lens-applications, would you consider pulling it into ubuntu/u-l-a? [12:37] Launchpad bug 785101 in unity (Ubuntu) "unable to remove the "Apps Available for Download" section from Applications Lens" [Undecided,Fix committed] https://launchpad.net/bugs/785101 [12:37] ockham_: this will go in precise with the new u-l-a release rather [12:38] tjaalton: actually, looking at that again I wonder if, as an upstream, we should drop that strict dependency between ldb modules and the version of ldb they can use [12:39] didrocks: sry, i'm not exactly aware of the sync'ing workflow for ubuntu-native packages. so this will happen automatically? [12:40] jelmer: that would be great [12:40] ockham_: well, not automatically, but it will as soon as we release a tarball :) [12:40] hi [12:40] didrocks: ok. and what about oneiric-updates? [12:42] ockham_: I'm not sure it qualifies for a SRU [12:43] didrocks: well, neither am i. i was just hoping it does... [12:43] ockham_, seems like a backport thing rather [12:43] seb128: ok. how is that done within ubuntu? [12:43] jelmer: and bump the so when the plugin api changes ;) === MacSlow is now known as MacSlow|lunch [12:45] I'm a bit confused by ffmpeg packaging. I just want to get this: looks like ffmpeg dropped support for the binary/old amr codecs and uses opencore codecs now. but it looks like ffmpeg was packaged without support for this (-> installing libopencore-amr* doesn't provide support for amr transcoding) [12:45] ockham_, https://wiki.ubuntu.com/UbuntuBackports [12:45] just want to know if this is supposed to be like that? or if I might be doing something wrong [13:06] could somebody confirm that there is no amr support in ffmpeg, not in multiverse, not in a ppa and not in medibuntu? [13:07] looks like ffmpeg dropped the support for those old, binary libamr* codecs and uses opencore codecs now [13:07] but using them is disabled in the ubuntu packages ffmpeg [13:07] at least in 10.04 [13:08] the opencore codecs are there, but no ffmpeg version with enabled support for them [13:08] https://help.ubuntu.com/community/FFMpeg#Medibuntu <- this wiki page tells it should be possible with medibuntu but there is no ffmpeg for lucid === Quintasan_ is now known as Quintasan === cjwatson changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev [13:25] sorry, mirroring was fixed ages ago, but I forgot to remove that from the topic [13:36] any upstart developers around? I need some advice (no answer on #upstart) [13:38] zyga: See man init(5), search for "kill signal" [13:39] zyga: (init(5) is a treasure trove of information about upstart, by the way) [13:39] soren, looking [13:40] ah [13:40] lovely [13:40] why is this not in the cookbook then :)? [13:43] zyga: it will be on the next update. If you find errors and omissions, you are more than welcome to provide patches :) [13:47] infinity: I've fixed that debootstrap bug with perl-modules upstream === MacSlow|lunch is now known as MacSlow [14:11] Waiting for network configuration... [14:11] Waiting up to 60 more seconds for network configuration... [14:11] hrm [14:12] ogra_: what kind of system and environment is that on and what do you have in your /etc/network/interfaces? (that's the new upstart magic implemented in Oneiric) [14:15] jhunt_, is the cookbook somewhere in lp ? [14:16] stgraber, its an omap4 based tablet for which we dont have the right kernel [14:16] stgraber, so there are currently no network devices [14:17] ogra_: could it be that your /etc/network/interfaces contains an entry for eth0 but it never comes up as eth0 doesn't exist? [14:17] zyga: sure is - https://launchpad.net/upstart-cookbook. Expect a large update in the next week or so, but feel free to raise bugs, etc. [14:17] ubuntu@ubuntu:~$ cat /etc/network/interfaces [14:17] cat: /etc/network/interfaces: No such file or directory [14:17] no /e/n/i === mterry_ is now known as mterry [14:17] oh, is that legal? :) [14:17] no idea [14:17] i got a lo interface [14:25] ubuntu doesn't do armhf right? only armel? [14:26] I thought we were working on a port for this? [14:26] Isn't it currently bootstrapping? [14:27] * micahg thought he saw somewhere that is coming very soon :) [14:28] cjwatson: \o/ [14:31] ok I'll make packages assuming it's coming [14:33] Riddell, it is still in the buildd bootstrap phase but will happen soon [14:33] we will decide by FF if we support it or not [14:34] hi again, thanks to your suggestions I was able to produce a man-page for massif-visualizer. I created it partly by copying content from https://projects.kde.org/projects/extragear/sdk/massif-visualizer . I added the standard "man page created for the Debian project" paragraph, but actually I am wondering if I am allowed to do so since roughly 75% of the man page comes from the site description (which has neither license nor author) [14:35] any opinion? [14:37] is that text not also present in a readme or something? You can always mail the maintainer and ask for clarification. In fact, you should offer them the manpage, anyway. [14:37] agateau: well the man page is created for ubuntu so you can say that, you probably want to clarify the licence with upstrem (Milian Wolff) [14:38] tumbleweed: no it's not in the README, would have been simpler that way, indeed [14:39] Riddell: yes I can say the page has been created for Ubuntu, but can I say that it has been written by me and define its license myself? [14:40] that paragraph isn't an assertion of copyright, and it also isn't mandatory [14:40] the man page should have the same licence as the program; there is honestly no excuse for a program and its documentation having different licences, the GFDL madness notwithstanding :) [14:40] if the paragraph makes you uncomfortable, omit it [14:41] actually it's about whether I can claim copyright for it: the man page is also covered by debian/copyright if I am not mistaken [14:41] maybe I am just too much of a nitpicker [14:43] that project is a license party :) [14:43] agateau: if it's copy and pasted from elsewhere then you can't claim it's all yours no [14:44] Riddell: I did some proofreading and reformatting obviously, but that's basically it [14:45] I should have ignored the lintian warning :) [14:47] agateau: Milian is usually pretty responsive on IRC [14:47] Riddell: haven't had much luck lately, but will give it a try [14:49] agateau: really we should get projects.kde.org to have a standard licence for its contents [14:49] Riddell: indeed [14:51] Riddell: have you already been in a similar situation with projects.kde.org? [14:51] nope [14:51] Riddell: actually, we should get projects.kde.org to use the content of README files for the Overview page [14:52] Riddell: that way we get proper licence and ownership and we don't even have to care because the content is in the tarball [14:52] ah well that's more fiddly, I'm sure kde sysadmin would be happy for your help though :) [14:53] Riddell: heh, all of this for a manpage :) === yofel_ is now known as yofel [14:56] dantti|2, it might [14:57] I have xcode installed [15:07] slangasek, just wondering where if anywhere we are on that udev race stuff, triggered by the bnx2 firmware load, are you on point for that one?? [15:21] * pitti exports first shot of http://people.canonical.com/~ubuntu-archive/apport-duplicates/ and gets his first client-side detected crash duplicate [15:21] ev: ^ FYI :) [15:22] yay! [15:23] pitti: for what it's worth, I'm helping the DX team this week at Rick's request, so I'll only be working on the crash database in the evenings - if that time isn't absorbed by the DX work :) [15:23] ev: ah, good luck with this! I'm sure they appreciate any extra hand they can get === dendrobates is now known as dendro-afk [15:23] cheers === dendro-afk is now known as dendrobates [15:36] apw: I think I'm on point for that one, but I haven't made much progress; the partial fix I was hoping to apply that could be SRUed quickly failed because it leaves the udev in the initramfs blocking the socket thereby preventing startup of the process on the rootfs [15:36] apw: so it looks like we have to fully implement what we discussed at UDS to make any proress [15:37] pitti: yeah, I don't kno anything that should hold up apport re-enabling [15:37] slangasek, hopefully the systemd stuff will help us there [15:37] apw: uh? [15:37] slangasek, the hooks in udev to allow passing of sockets in (which is there for systemd) ought to help us pass the ones we have over [15:37] ah [15:38] yes, should do [15:38] slangasek, ok so for now, you are the man (if not yet making progress), if you need help yelp [15:38] apw: will do, thanks :) [15:57] just ran into a situation where the recovery partition overwrote the partition table as soon as it was booted, before asking any questions. /me wonders if we should really be showing those things in the default grub menu [16:07] reportbug cannot connect to Debian BTS, is it a known issue or is there something wrong in my setup? [16:07] Sweetshark: when do you plan the next libreoffice upload? it's involved in three library transitions so far; I don't like to upload libreoffice frivolously, but it would be good to know roughly how long those need to wait [16:10] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: roaksoax, ev [16:15] doko, any questions or would you like me to start over ? [16:16] tgall_foo, please could you open a question in the launchpad project to increase the size of your PPA, and finish the rebuild? [16:16] doko, yes I've already opened up a quick on launchpad to request an increase in PPA [16:16] tgall_foo, are the few build failures related to libjpeg-turbo? [16:16] s/quick/question [16:18] if you look at : https://launchpad.net/~tom-gall/+archive/libjpeg-turbo, there haven't been any failures [16:19] dholbach: you're our CC liason for figuring out how to run elections where the number of candidates matches the number of slots [16:19] between imlib, imagemagick, koffice, gimp, ghostscript, v4l, webkit and so on? there's a good number of heavy weights built against the new libjpeg-turbo thus far [16:19] dholbach: will try to make a clearer action item [16:20] but as noted there's a couple more left to complete a rebuild of all packages that have deps against libjpeg-dev that are located in the main archive ? with the additional ppa space I should be able to complete that and then get on to universe [16:20] wendar, ah, in that case, we often just set up a poll in LP for every person that's to be elected and did a confirmation poll - person X - yes? - no? [16:21] wendar, I can bring it up on the CC list and CC you in [16:21] so we can document it [16:22] dholbach: good idea. I've tweaked your workitem to be clearer, and added one for me to document the results, so we have it captured for the next ARB election [16:23] * dholbach hugs wendar [16:23] great [16:25] do i understand correctly this would be a good place to talk about a kernel developed for ARM Tegra on a Stingray board? [16:25] for the purpose of running ubuntu, of course === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [16:27] tgall_foo, yes, I would prefer to finish the rebuild before doing the rebuild in the main archive [16:27] doko, just to validate, you do want everything with libjpeg-dev deps validated from universe as well right ? [16:27] tgall_foo, well, we'll have to fix these too ... [16:27] np :-) [16:28] I noted the pkgswith libjpeg62 deps yet .. I presume some "fixes" to move those to libjpeg8 would be welcome ? [16:28] um, if it's ABI-compatible, why can't libjpeg-turbo just deliver a libjpeg8 pabinary package? [16:28] I'm not happy about doing another transition just as we're most of the way through the first one [16:28] hm [16:28] s/pabinary/binary/ what happened there [16:29] cjwatson: Ok to start the libmysqlclient transition today? [16:29] cjwatson, it does, but it it's good to validate [16:29] tgall_foo: then why do we need a rebuild in the main archive? [16:29] SpamapS: yes [16:29] cjwatson: ty [16:30] cjwatson, in theory you wouldn't [16:30] let's make that in practice, then [16:30] tgall_foo: anything that build-depends: libjpeg62-dev or libjpeg62-dev | libjpeg-dev should be changed to build-depends: libjpeg-dev alone [16:30] cjwatson, and from what I've tested locally I haven't had issues replacing libjpeg8 with -turbo [16:30] patches for that are fine; it's gradually happening in Debian [16:31] cjwatson, good to hear, needs to be done and I'm happy to do it [16:31] I've been working my way through slowly as well [16:31] http://people.canonical.com/~ubuntu-archive/transitions/libjpeg.html [16:33] ah cool :-) [16:35] can someone tell me how often Packages.gz on ddebs.ubuntu.com are refreshed? [16:36] hrw: 41 3,8,11,15,19,23 * * * for precise [16:36] pitti: thanks [16:36] 10 2,10,18 * * * for stables [16:37] that's UTC [16:41] cjwatson: I dont quit eget the question. the last upload was 3.4.4 for oneiric-proposed ... [16:43] Sweetshark: I'm asking when you plan the next upload directly to precise, built against precise libraries [16:44] perhaps I should say the first upload directly to precise, but even so :-) [16:46] http://wiki.documentfoundation.org/ReleasePlan/3.5#3.5.0_release <- I aim for beta0 as first release ... [16:51] Sweetshark: OK, that's close enough for comfort I think; thanks [16:51] I just want to make sure that we don't keep dragging around old libraries that only libreoffice depends on [16:52] cjwatson: ahhh, ok. [17:00] <\sh> mdeslaur, pingeling tomcat6 security update === dendrobates is now known as dendro-afk === negronjl_mobile is now known as negronjl === beuno is now known as beuno-lunch [17:10] Sweetshark: you're aware that the oneiric update moving to -updates is blocked on something being uploaded to precise, right? [17:12] * tgall_foo waves to arges [17:12] tgall_foo, howdy === negronjl_mobile_ is now known as negronjl [17:23] micahg: well, there 3.4.4-0ubuntu1 is uploaded to precise. however, by the time a 3.4.5 is coming around, there will be a 3.5.X release in precise, so do I still need to (forwardport) the outdated release? [17:23] Sweetshark: 3.4.4 isn't published in precise [17:25] micahg: well, normally that would happen after copying to -updates, in cases where the earlier -proposed has gone first; but in this case it would actually be quite nice to have a 1:3.4.4-0ubuntu2 that's actually built in precise rather than just copied in [17:25] I could copy 1:3.4.4-0ubuntu1 to precise if that's the only blocker to that update moving to -updates [17:25] but that doesn't help with getting it weaned off NBS libraries [17:25] cjwatson: I thought the new policy was uploads must be to the devel release per: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-November/000908.html [17:26] yes, but I think that was after the upload of 1:3.4.4-0ubuntu1 :-) [17:26] oh, perhaps not [17:27] well, either way, it can still be properly resolved :) [17:27] right [17:27] so we should really get a 1:3.4.4-0ubuntu2 in precise, in advance of 3.5.x, so that it can help with QAing the oneiric update === jtr__ is now known as jtr__|away === skaet_ is now known as skaet === beuno-lunch is now known as beuno === ]reed[ is now known as [reed] [18:44] Can someone triage this and get it assigned to a distro series? mterry has already reproduced/verified it but I need someone with more authority to move it to the next level: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/891707 [18:44] Launchpad bug 891707 in firefox (Ubuntu) "java webstart creates infinite open windows, desktop DoS" [Undecided,Confirmed] [18:49] doko, mterry: what is the MIR procedure for things that are mostly in main, but have a couple of binaries in universe, when we want to have them promoted. I am looking at apparmor-- there are several binaries in universe for no particularly good reason anyore: apparmor-notify, apparmor-profiles, libpam-apparmor, libapache2-mod-apparmor and python-libapparmor [18:51] doko, mterry: none of these are servers, need security review, etc. apparmor is a canonical maintained project these days and we support those as if they were in main anyway [19:00] jdstrand, I believe just file a MIR and mention the situation, which binaries you want to promote, etc. What's the motivation here? Does anything want to use those binaries? [19:03] mterry: I just thought their placement should correctly repesent their level of support. python-libapparmor will likely need to be promoted for some upcoming tools [19:03] mterry: I don't want people to be afraid to use them. They are well supported [19:04] jdstrand, I think the general idea is to not promote something until it's going to be used, but doko would know more about that policy [19:05] well, yes, but these are leaf applications [19:05] (excepting python-libapparmor) [19:08] (and apparmor itself is of course extensively used in Ubuntu-- ie, if the MIR were to happen today, these would all go to main as there is no reason why they should not) [19:21] doko, mterry: ok, I filled a bug: 893266 [19:21] Launchpad bug 893266 in apparmor (Ubuntu) "[MIR] move all apparmor binaries to main" [Undecided,New] https://launchpad.net/bugs/893266 [19:22] is there a way to get a kernel with DEBUG config options set without compiling my own? === bregma is now known as bregma|afk [19:24] jdstrand, mterry: no need of a bug to promote binaries [19:25] jdstrand, mterry: things are demoted when they show on componentmismatch, i.e when nothing pull them in main [19:25] jdstrand, mterry: you basically need something in main to depends or recommends on those binary (source or seed) === dendro-afk is now known as dendrobates [19:28] seb128: I'm happy to seed them. Since I am requesting it and I am on the mir team, I thought I should ask someone about it [19:29] seb128: similar to the "don't process your own uploads" rule [19:29] I'm looking for permission to seed them basically :) [19:30] jdstrand, seb128: bug is required if the last MIR for the source package ignored the code for those binaries. but if they've been signed off on, then yah, no bug required. i'd have to look at history [19:30] mterry, ok, fair enough, usually we just promote or demote binaries without extra paper work I think [19:30] but that makes sense [19:31] if the source is in main it's supported anyway, it doesn't make a real difference where the binaries are I think [19:31] well [19:31] we don't always do that [19:31] slangasek, SpamapS: could one of you accept ubuntuone-client 0ubuntu2.2 into oneiric-proposed? thanks [19:32] in theory, these binaries could be crazy daemons and all sorts of stuff. so they just need a quick MIR review to confirm. jdstrand, I'll do that review right now [19:32] eg, if a new binary comes in with a new upstream version, what is the decision to be made? I've generally adjusted the override for main if it isn't security sensitive [19:32] (eg, when processing NEW) [19:32] jdstrand, define "we"? ;-) I guess the practice is one of those which is not consistent between members of a team there [19:32] if it is a daemon or something, I leave it in universe [19:32] jdstrand: in practice, ubuntu-archive is going to promote binaries when the source is already in main without particular consultation [19:32] * jdstrand nods [19:32] jdstrand: if the security team is relying on us to not do that, this needs new infrastructure, rather than assuming that some process will be interposed [19:33] that is what I do, unless it looks iffy [19:33] I've always consistently said that people don't need permission to promote new binaries [19:33] cjwatson: no, this isn't about my team [19:33] that last bit is what I wasn't clear on [19:33] well, if *anyone* is relying on us to not do that [19:33] MIR team more than security team I suppose [19:34] this is slightly different-- these aren't new binaries [19:34] I am trying to clean things up-- they should be in main, they are already supported as if they were [19:34] well same difference, usually when something starts pulling an universe binary from a source in main we promote it [19:34] jdstrand: doesn't matter [19:35] hey, I'm happy to 'just do it' :) [19:35] snicker [19:35] what I meant was "I've always consistently said that people don't need permission to promote binaries from sources that are already in main" [19:35] jdstrand, well if you just promote it but nothing in main "is pulling it in" it will be demoted again because it will show up on the component mismatch list [19:36] right. seed/depend first [19:36] yes, I would seed it [19:36] cjwatson, is there a blacklist somewhere? Because if I'm not mistaken, sometimes we promote certain binaries and intentionally don't want to promote others. A blacklist would prevent mistakes in the process you outlined [19:36] mterry: there is a theoretical blacklist in the heads of members of the MIR team ;-) [19:36] * mterry isn't thrilled with that answer :) [19:37] I suppose we could use the !-seeding facility in the supported seed or something, but it would require some investigation [19:37] problem is, you guys started doing this without ensuring that it fit into archive workflows ... [19:37] I think there's only a handful of such cases? [19:38] Probably, and I doubt apparmor's are part of them [19:38] demotion> FWIW at least I tend to be not particularly trigger-happy about demotions, because I know that they're often just about to be depended on by something, or similar [19:39]