[00:01] <infinity>  3767 root      20   0  2140  332  256 R 35.0  0.0  10763:24 udevd
[00:02] <infinity> ^-- That seems less than ideal.
[00:04] <Laney> I have definitely SRUed pidgin for ICQ protocol changes in the past
[00:04] <Laney> but they were cherry pickable IIRC, indeed
[00:10] <lamont> cjwatson: alt-drag ftw
[00:24] <broder> lamont: alt-middle also resizes
[06:26] <pitti> Good morning
[06:26] <pitti> 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] <pitti> dupondje: oh, papyon take III?
[07:02] <broder> 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:09] <pitti> broder: TBH I'm not that concerned about SRUing 0.9.16/.17
[07:10] <pitti> 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] <broder> 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] <broder> well, that's not true - they actually indicate them differently in the changelog, but they don't keep the new features out
[07:12] <pitti> yeah; but I guess most games are like that
[07:12] <broder> 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] <RAOF> 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] <broder> 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] <pitti> that was discussed in the context of ubuntuone stuff
[07:14] <pitti> but in general SRU exceptions are granted for these kinds of software
[07:14] <pitti> as changing server protocols obviously breaks the current version in the archive
[07:14] <pitti> which clearly falls under the "regression" SRU policy
[07:15]  * broder nods
[07:15] <pitti> that said, focussed patches there are still preferred
[07:15] <tumbleweed> OTOH updating it means any local servers need to be updated too
[07:15] <pitti> and we usually require them for stuff like empathy plugins or server-ish stuff
[07:15] <pitti> but for games I think we don't need to be as strict
[07:16] <pitti> tumbleweed: if we have the local server software packaged, yes; that usually doesn't apply to things like "msn is broken"
[07:16] <pitti> (a current SRU which we have right now)
[07:17] <tumbleweed> pitti: of course. And I think in hedgewars, there are many public servers that run the latest version
[07:20] <tumbleweed> 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] <broder> on the plus side, hedgewars in lucid is only several "point releases" behind - no minor releases even
[07:40] <pitti> 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] <pitti> that's for picking up and reporting crashes
[07:56] <dholbach> good morning
[07:58] <lag> dholbach: Yo! GM. :)
[07:58] <lag> Daviey: What are you on about?
[07:58] <dholbach> hey lag
[07:58] <dholbach> how's life over there?
[07:59] <sladen> dholbach: hallo
[08:00] <dholbach> hey sladen :)
[08:01] <lag> dholbach: Cold and drab, and there?
[08:01] <dholbach> cold as well, but here the sun is shining
[08:09] <sladen> somebody painted all the Millbank windows white
[08:11] <tsdgeos> tkamppeter_: ping
[08:51] <tkamppeter_> tsdgeos, hi
[08:52] <tsdgeos> tkamppeter: you opened a bug about "Okular should print PDF instead of Ghostscript"
[08:52] <tsdgeos> rgiht?
[08:53] <tkamppeter> tsdgeos, I asked someone to open it. We must do s/Ghostscript/PostScript/ in the title.
[08:54] <tkamppeter> tsdgeos, can you post the number of the bug here?
[08:54] <tsdgeos> tkamppeter: https://bugs.kde.org/show_bug.cgi?id=286825 https://bugs.launchpad.net/ubuntu/+source/okular/+bug/891199
[08:54] <tsdgeos> tkamppeter: i disagree totally this is a bug
[08:55] <tsdgeos> and if ubuntu is failing to print the ps files we generate, well, then that's an ubuntu bug
[08:57] <tkamppeter> 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] <tsdgeos> "generally agreed" by who?
[08:57] <tsdgeos> and even if it was "generally agreed"
[08:58] <tsdgeos> does that "general agreement" also include the clause "and while we do that let's make printing PS fail"
[08:58] <tsdgeos> 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] <tkamppeter> 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] <tsdgeos> so?
[08:59] <tsdgeos> i am sending a file with .ps extension
[08:59] <tsdgeos> cups started being stupid and decides to treat it as a pdf?
[09:00] <pitti> I thought cups had a ps2pdf filter for that case?
[09:00] <tkamppeter> 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] <tsdgeos> tkamppeter: good, then don't make it seem like if it is Okular having a bug ;)
[09:01] <tkamppeter> tsdgeos, the PostScript printing bug mentioned here got fixed in upstream Ghostscript today and I will prepare an SRU for Oneiric.
[09:01] <tsdgeos> awesome :)
[09:01] <pitti> well, okular should still send PDF
[09:02] <tsdgeos> sure
[09:02] <tsdgeos> but that's a wish
[09:02] <tsdgeos> not a bug
[09:02] <pitti> okular converting PDF to PS, and then cups PS back to PDF is a bit pointless?
[09:02] <pitti> tsdgeos: right
[09:02] <tkamppeter> 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] <pitti> tkamppeter: nice
[09:02] <tsdgeos> 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] <Chipzz> 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] <tkamppeter> 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] <tsdgeos> tkamppeter: while we are on this, do you know how can know if cups is "pdf aware" ?
[09:03] <pitti> Chipzz: that's not what we said, though?
[09:04] <pitti> Chipzz: if you are viewing a PDF document, it should be sent as PDF instead of being converted twice
[09:04] <tsdgeos> Chipzz: the thing is we (Okular) convert PDF to PS for printing, this could be "shortcircuited" with the "new" cups
[09:04] <tkamppeter> tsdgeos, CUPS is always PDF-aware as it has a pdftops filter.
[09:05] <tsdgeos> 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] <tsdgeos> which otoh sounds nice since i can just forward all printing bugs to cups :D
[09:06] <pitti> well, in an ideal world all of these flows should work, so if they differ, there certainly is a bug
[09:06] <pitti> 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] <pitti> (well, "cups" in a wide sense -- bug in anything in the filter chain)
[09:07] <Chipzz> pitti: right. I'm not sure what makes pdf a better format for printing than ps though
[09:09] <pitti> Chipzz: in general scaling, printing 4-on-1 etc. works a lot more robustly with PDF
[09:10] <tkamppeter> 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] <tkamppeter> 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] <tsdgeos> tkamppeter: the other side of the equation is systems without cups, i guess there you still need to print to ps
[09:10] <tkamppeter> tsdgeos, with the configurable setting no problem. Let it default to PS if there is no libcups available.
[09:10] <tsdgeos> asking to the user if he wants to print to ps or pdf seems like an over-configuration setting
[09:10] <tsdgeos> 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] <pitti> tsdgeos: it's not configuration at all indeed, it's an internal implementation detail
[09:11] <pitti> tsdgeos: this only makes sense for printing into a file
[09:12] <tkamppeter> 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] <tkamppeter> s/afterwards/otherwise/
[09:13] <tkamppeter> tsdgeos, in addition a ./configure option allows the distro packager to change the default.
[09:14] <tsdgeos> yeah, i'll think about it
[09:15] <tsdgeos> otoh it's kind of a lot of work to make something that works, work :D
[09:17] <pitti> I think it'd be easier to send PS as PS and PDF as PDF
[09:17] <pitti> but anyway, let's just unbreak PS, then it doesn't matter much
[09:18] <tsdgeos> sure, if you would not have to account for systems where printing PDF is not a feature
[09:19] <tkamppeter> tsdgeos, see also http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
[09:20] <tsdgeos> 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] <pitti> isn't that more a question of the printer spooler than the kernel?
[09:21] <tsdgeos> yes
[09:21] <pitti> cups works just as well on BSD, given that it's developed by Apple
[09:21] <tkamppeter> tsdgeos, so it should decide on the presence of Linux and libcups at build time.
[09:21] <Chipzz> tkamppeter: tbh that doesn't make much sense to me
[09:21] <Chipzz> tkamppeter: a distro could choose always to compile against libcups
[09:22] <Chipzz> while the user can choose not to install cups
[09:22] <Chipzz> can you "detect" if there's sth at the other end of the line with libcups?
[09:22] <tsdgeos> afaik not
[09:22] <tkamppeter> Chipzz, and if the distro compiles against CUPS, the app could get built so that it sends PDF.
[09:22] <tsdgeos> everyone just installs something called "lpr"
[09:23] <Chipzz> tkamppeter: you... are missing the point
[09:23] <tsdgeos> and there's not even a way to run lpr -v or something to know who you are talking to
[09:24] <tkamppeter> 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] <Chipzz> yes
[09:25] <pitti> the LP protocol doesn't have anything like "supported formats"?
[09:25] <Chipzz> tkamppeter: *compiling* against libcups is a distro choice. installing cups itself is a user choice
[09:25] <cjwatson> pitti: I don't have any particular blocker for re-enabling apport
[09:25] <tkamppeter> 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] <tsdgeos> 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] <tkamppeter> 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] <tsdgeos> 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] <tkamppeter> 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] <tsdgeos> yep
[09:31] <tsdgeos> as said looks like a sane idea
[09:31] <tsdgeos> just need to get the time to implement it :-)
[10:12] <tsdgeos> is it me or is it libtiff4-dev uninstallable?
[10:13] <pitti> works fine here (current precise)
[10:13] <tsdgeos> in oneric it seems to want libjpeg-dev that seems to not exist
[10:14] <tsdgeos> probably asking in the wrong channel :D
[10:14] <pitti> tsdgeos: libjpeg6b-dev
[10:15] <pitti> libjpeg-dev is a virtual packate that libjpeg6b-dev provides
[10:15] <pitti> in precise it's provided by libjpeg8-dev
[10:15] <tsdgeos> i see
[10:16] <tsdgeos> much better now
[10:16] <tsdgeos> tx
[10:18] <dholbach> 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] <agateau> 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] <cjwatson> yes, although IMO that's the bare minimum for a manual page rather than something that's actually good
[10:29] <cjwatson> (help2man that is; no experience with pandoc or asciidoc)
[10:29] <tumbleweed> 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] <cjwatson> it's certainly fine to generate manual pages from other formats in general
[10:31] <agateau> I thought help2man was a formatting tool, now that I see what it does, I realize it would not be appropriate
[10:32] <agateau> 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] <azeem> loads of them
[10:34]  * tumbleweed greps thtrough the source packages on his working directories, and finds namebench, springpython, tweepy
[10:34] <agateau> tumbleweed: azeem: thanks
[10:38] <cjwatson> POD is a good format to generate these from too
[10:38] <cjwatson> since we've already gone through the process of making sure its output is actually of decent quality
[10:38] <cjwatson> (i.e. pod2man)
[10:39] <cjwatson> I think I would advise that by preference over tools where we haven't yet gone through that process
[10:43] <azeem> isn't the docbook2man thing which dh_make puts as template quite ok as well?
[10:58] <cjwatson> 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] <tjaalton> jelmer: hey, the symbol versioning of libldb doesn't seem to work, since sssd needs a rebuild every time ldb is updated..
[11:15] <jelmer> tjaalton: it works for libary users, not for plugins IIRC
[11:15] <tjaalton> jelmer: hmm right
[11:16] <tjaalton> i'll modify the package to depend on the libldb1 version that it was built against..
[11:26] <xruud> 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] <xruud> 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] <Chipzz> xruud: please pretty please read the topic
[11:29] <Chipzz> (and not just in this channel, but in ANY channel you join)
[11:32] <dholbach> thanks jelmer
[11:32] <brendand> xruud - #ubuntu-app-devel please
[12:04] <dantti|2> 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] <xruud> Chipzz
[12:06] <xruud> Chipzz: sorry, irc is new to me, believe it or not.
[12:06] <xruud> brendand: thanks
[12:37] <ockham_> 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] <didrocks> ockham_: this will go in precise with the new u-l-a release rather
[12:38] <jelmer> 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] <ockham_> didrocks: sry, i'm not exactly aware of the sync'ing workflow for ubuntu-native packages. so this will happen automatically?
[12:40] <tjaalton> jelmer: that would be great
[12:40] <didrocks> ockham_: well, not automatically, but it will as soon as we release a tarball :)
[12:40] <fish_> hi
[12:40] <ockham_> didrocks: ok. and what about oneiric-updates?
[12:42] <didrocks> ockham_: I'm not sure it qualifies for a SRU
[12:43] <ockham_> didrocks: well, neither am i. i was just hoping it does...
[12:43] <seb128> ockham_, seems like a backport thing rather
[12:43] <ockham_> seb128: ok. how is that done within ubuntu?
[12:43] <tjaalton> jelmer: and bump the so when the plugin api changes ;)
[12:45] <fish_> 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] <seb128> ockham_, https://wiki.ubuntu.com/UbuntuBackports
[12:45] <fish_> just want to know if this is supposed to be like that? or if I might be doing something wrong
[13:06] <fish_> could somebody confirm that there is no amr support in ffmpeg, not in multiverse, not in a ppa and not in medibuntu?
[13:07] <fish_> looks like ffmpeg dropped the support for those old, binary libamr* codecs and uses opencore codecs now
[13:07] <fish_> but using them is disabled in the ubuntu packages ffmpeg
[13:07] <fish_> at least in 10.04
[13:08] <fish_> the opencore codecs are there, but no ffmpeg version with enabled support for them
[13:08] <fish_> https://help.ubuntu.com/community/FFMpeg#Medibuntu <- this wiki page tells it should be possible with medibuntu but there is no ffmpeg for lucid
[13:25] <cjwatson> sorry, mirroring was fixed ages ago, but I forgot to remove that from the topic
[13:36] <zyga> any upstart developers around? I need some advice (no answer on #upstart)
[13:38] <soren> zyga: See man init(5), search for "kill signal"
[13:39] <soren> zyga: (init(5) is a treasure trove of information about upstart, by the way)
[13:39] <zyga> soren, looking
[13:40] <zyga> ah
[13:40] <zyga> lovely
[13:40] <zyga> why is this not in the cookbook then :)?
[13:43] <jhunt_> zyga: it will be on the next update. If you find errors and omissions, you are more than welcome to provide patches :)
[13:47] <cjwatson> infinity: I've fixed that debootstrap bug with perl-modules upstream
[14:11] <ogra_> Waiting for network configuration...
[14:11] <ogra_> Waiting up to 60 more seconds for network configuration...
[14:11] <ogra_> hrm
[14:12] <stgraber> 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] <zyga> jhunt_, is the cookbook somewhere in lp ?
[14:16] <ogra_> stgraber, its an omap4 based tablet for which we dont have the right kernel
[14:16] <ogra_> stgraber, so there are currently no network devices
[14:17] <stgraber> 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] <jhunt_> 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] <ogra_> ubuntu@ubuntu:~$ cat /etc/network/interfaces
[14:17] <ogra_> cat: /etc/network/interfaces: No such file or directory
[14:17] <ogra_> no /e/n/i
[14:17] <stgraber> oh, is that legal? :)
[14:17] <ogra_> no idea
[14:17] <ogra_> i got a lo interface
[14:25] <Riddell> ubuntu doesn't do armhf right?  only armel?
[14:26] <pitti> I thought we were working on a port for this?
[14:26] <juliank> Isn't it currently bootstrapping?
[14:27]  * micahg thought he saw somewhere that is coming very soon :)
[14:28] <infinity> cjwatson: \o/
[14:31] <Riddell> ok I'll make packages assuming it's coming
[14:33] <ogra_> Riddell, it is still in the buildd bootstrap phase but will happen soon
[14:33] <ogra_> we will decide by FF if we support it or not
[14:34] <agateau> 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] <agateau> any opinion?
[14:37] <tumbleweed> 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] <Riddell> 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] <agateau> tumbleweed: no it's not in the README, would have been simpler that way, indeed
[14:39] <agateau> 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] <cjwatson> that paragraph isn't an assertion of copyright, and it also isn't mandatory
[14:40] <cjwatson> 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] <cjwatson> if the paragraph makes you uncomfortable, omit it
[14:41] <agateau> 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] <agateau> maybe I am just too much of a nitpicker
[14:43] <agateau> that project is a license party :)
[14:43] <Riddell> agateau: if it's copy and pasted from elsewhere then you can't claim it's all yours no
[14:44] <agateau> Riddell: I did some proofreading and reformatting obviously, but that's basically it
[14:45] <agateau> I should have ignored the lintian warning :)
[14:47] <Riddell> agateau: Milian is usually pretty responsive on IRC
[14:47] <agateau> Riddell: haven't had much luck lately, but will give it a try
[14:49] <Riddell> agateau: really we should get projects.kde.org to have a standard licence for its contents
[14:49] <agateau> Riddell: indeed
[14:51] <agateau> Riddell: have you already been in a similar situation with projects.kde.org?
[14:51] <Riddell> nope
[14:51] <agateau> Riddell: actually, we should get projects.kde.org to use the content of README files for the Overview page
[14:52] <agateau> 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] <Riddell> ah well that's more fiddly, I'm sure kde sysadmin would be happy for your help though :)
[14:53] <agateau> Riddell: heh, all of this for a manpage :)
[14:56] <cnd> dantti|2, it might
[14:57] <cnd> I have xcode installed
[15:07] <apw> 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] <pitti> ev: ^ FYI :)
[15:22] <ev> yay!
[15:23] <ev> 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] <pitti> ev: ah, good luck with this! I'm sure they appreciate any extra hand they can get
[15:23] <ev> cheers
[15:36] <slangasek> 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] <slangasek> apw: so it looks like we have to fully implement what we discussed at UDS to make any proress
[15:37] <slangasek> pitti: yeah, I don't kno anything that should hold up apport re-enabling
[15:37] <apw> slangasek, hopefully the systemd stuff will help us there
[15:37] <slangasek> apw: uh?
[15:37] <apw> 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] <slangasek> ah
[15:38] <slangasek> yes, should do
[15:38] <apw> slangasek, ok so for now, you are the man (if not yet making progress), if you need help yelp
[15:38] <slangasek> apw: will do, thanks :)
[15:57] <tumbleweed> 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] <agateau> reportbug cannot connect to Debian BTS, is it a known issue or is there something wrong in my setup?
[16:07] <cjwatson> 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] <roaksoax> @pilot in
[16:15] <tgall_foo> doko, any questions or would you like me to start over ?
[16:16] <doko> 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] <tgall_foo> doko, yes I've already opened up a quick on launchpad to request an increase in PPA
[16:16] <doko> tgall_foo, are the few build failures related to libjpeg-turbo?
[16:16] <tgall_foo> s/quick/question
[16:18] <tgall_foo> if you look at : https://launchpad.net/~tom-gall/+archive/libjpeg-turbo,  there haven't been any failures
[16:19] <wendar> 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] <tgall_foo> 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] <wendar> dholbach: will try to make a clearer action item
[16:20] <tgall_foo> 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] <dholbach> 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] <dholbach> wendar, I can bring it up on the CC list and CC you in
[16:21] <dholbach> so we can document it
[16:22] <wendar> 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] <dholbach> great
[16:25] <An-iSociaL> 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] <An-iSociaL> for the purpose of running ubuntu, of course
[16:27] <doko> tgall_foo, yes, I would prefer to finish the rebuild before doing the rebuild in the main archive
[16:27] <tgall_foo> doko, just to validate, you do want everything with libjpeg-dev deps validated from universe as well right ?
[16:27] <doko> tgall_foo, well, we'll have to fix these too ...
[16:27] <tgall_foo> np :-)
[16:28] <tgall_foo> I noted the pkgswith libjpeg62 deps yet ..  I presume some "fixes" to move those to libjpeg8 would be welcome ?
[16:28] <cjwatson> um, if it's ABI-compatible, why can't libjpeg-turbo just deliver a libjpeg8 pabinary package?
[16:28] <cjwatson> I'm not happy about doing another transition just as we're most of the way through the first one
[16:28] <An-iSociaL> hm
[16:28] <cjwatson> s/pabinary/binary/ what happened there
[16:29] <SpamapS> cjwatson: Ok to start the libmysqlclient transition today?
[16:29] <tgall_foo> cjwatson, it does, but it it's good to validate
[16:29] <cjwatson> tgall_foo: then why do we need a rebuild in the main archive?
[16:29] <cjwatson> SpamapS: yes
[16:29] <SpamapS> cjwatson: ty
[16:30] <tgall_foo> cjwatson, in theory you wouldn't
[16:30] <cjwatson> let's make that in practice, then
[16:30] <cjwatson> tgall_foo: anything that build-depends: libjpeg62-dev or libjpeg62-dev | libjpeg-dev should be changed to build-depends: libjpeg-dev alone
[16:30] <tgall_foo> cjwatson, and from what I've tested locally I haven't had issues replacing libjpeg8 with -turbo
[16:30] <cjwatson> patches for that are fine; it's gradually happening in Debian
[16:31] <tgall_foo> cjwatson, good to hear,  needs to be done and I'm happy to do it
[16:31] <cjwatson> I've been working my way through slowly as well
[16:31] <cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/libjpeg.html
[16:33] <tgall_foo> ah cool :-)
[16:35] <hrw> can someone tell me how often Packages.gz on ddebs.ubuntu.com are refreshed?
[16:36] <pitti> hrw: 41 3,8,11,15,19,23 * * * for precise
[16:36] <hrw> pitti: thanks
[16:36] <pitti> 10 2,10,18 * * *  for stables
[16:37] <pitti> that's UTC
[16:41] <Sweetshark> cjwatson: I dont quit eget the question. the last upload was 3.4.4 for oneiric-proposed ...
[16:43] <cjwatson> Sweetshark: I'm asking when you plan the next upload directly to precise, built against precise libraries
[16:44] <cjwatson> perhaps I should say the first upload directly to precise, but even so :-)
[16:46] <Sweetshark> http://wiki.documentfoundation.org/ReleasePlan/3.5#3.5.0_release <- I aim for beta0 as first release ...
[16:51] <cjwatson> Sweetshark: OK, that's close enough for comfort I think; thanks
[16:51] <cjwatson> I just want to make sure that we don't keep dragging around old libraries that only libreoffice depends on
[16:52] <Sweetshark> cjwatson: ahhh, ok.
[17:00] <\sh> mdeslaur, pingeling tomcat6 security update
[17:10] <micahg> 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] <arges> tgall_foo, howdy
[17:23] <Sweetshark> 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] <micahg> Sweetshark: 3.4.4 isn't published in precise
[17:25] <cjwatson> 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] <cjwatson> I could copy 1:3.4.4-0ubuntu1 to precise if that's the only blocker to that update moving to -updates
[17:25] <cjwatson> but that doesn't help with getting it weaned off NBS libraries
[17:25] <micahg> 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] <cjwatson> yes, but I think that was after the upload of 1:3.4.4-0ubuntu1 :-)
[17:26] <cjwatson> oh, perhaps not
[17:27] <micahg> well, either way, it can still be properly resolved :)
[17:27] <cjwatson> right
[17:27] <cjwatson> 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
[18:44] <ppetraki> 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:49] <jdstrand> 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] <jdstrand> 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] <mterry> 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] <jdstrand> 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] <jdstrand> mterry: I don't want people to be afraid to use them. They are well supported
[19:04] <mterry> 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] <jdstrand> well, yes, but these are leaf applications
[19:05] <jdstrand> (excepting python-libapparmor)
[19:08] <jdstrand> (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] <jdstrand> doko, mterry: ok, I filled a bug: 893266
[19:22] <Thetawaves> is there a way to get a kernel with DEBUG config options set without compiling my own?
[19:24] <seb128> jdstrand, mterry: no need of a bug to promote binaries
[19:25] <seb128> jdstrand, mterry: things are demoted when they show on componentmismatch, i.e when nothing pull them in main
[19:25] <seb128> jdstrand, mterry: you basically need something in main to depends or recommends on those binary (source or seed)
[19:28] <jdstrand> 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] <jdstrand> seb128: similar to the "don't process your own uploads" rule
[19:29] <jdstrand> I'm looking for permission to seed them basically :)
[19:30] <mterry> 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] <seb128> mterry, ok, fair enough, usually we just promote or demote binaries without extra paper work I think
[19:30] <seb128> but that makes sense
[19:31] <seb128> 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] <jdstrand> well
[19:31] <jdstrand> we don't always do that
[19:31] <dobey> slangasek, SpamapS: could one of you accept ubuntuone-client 0ubuntu2.2 into oneiric-proposed? thanks
[19:32] <mterry> 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] <jdstrand> 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] <jdstrand> (eg, when processing NEW)
[19:32] <seb128> jdstrand, define "we"? ;-) I guess the practice is one of those which is not consistent between members of a team there
[19:32] <jdstrand> if it is a daemon or something, I leave it in universe
[19:32] <cjwatson> 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] <cjwatson> 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] <jdstrand> that is what I do, unless it looks iffy
[19:33] <cjwatson> I've always consistently said that people don't need permission to promote new binaries
[19:33] <jdstrand> cjwatson: no, this isn't about my team
[19:33] <jdstrand> that last bit is what I wasn't clear on
[19:33] <cjwatson> well, if *anyone* is relying on us to not do that
[19:33] <cjwatson> MIR team more than security team I suppose
[19:34] <jdstrand> this is slightly different-- these aren't new binaries
[19:34] <jdstrand> I am trying to clean things up-- they should be in main, they are already supported as if they were
[19:34] <seb128> well same difference, usually when something starts pulling an universe binary from a source in main we promote it
[19:34] <cjwatson> jdstrand: doesn't matter
[19:35] <jdstrand> hey, I'm happy to 'just do it' :)
[19:35] <An-iSociaL> snicker
[19:35] <cjwatson> 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] <seb128> 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] <cjwatson> right.  seed/depend first
[19:36] <jdstrand> yes, I would seed it
[19:36] <mterry> 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] <cjwatson> 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] <cjwatson> I suppose we could use the !-seeding facility in the supported seed or something, but it would require some investigation
[19:37] <cjwatson> problem is, you guys started doing this without ensuring that it fit into archive workflows ...
[19:37] <cjwatson> I think there's only a handful of such cases?
[19:38] <mterry> Probably, and I doubt apparmor's are part of them
[19:38] <cjwatson> 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] <jdstrand> tbh, the split of main/universe within a package is quite confusing a lot of times
[19:39] <cjwatson> I do think we need to sort out this blacklisting thing
[19:39] <dobey> mterry: btw, care to help me understand how to get my avahi changes into debian, at some point? :)
[19:39] <jdstrand> there are cases, of course-- where we don't want the crazy daemon but we do want the lib
[19:40] <cjwatson> it might be easier to do it in component-mismatches itself rather than trying to express even more complex concepts in seeds
[19:40] <jdstrand> (and that is coming from a member of the security team ;)
[19:40] <mterry> jdstrand, what's this apparmor pam module do?
[19:40] <cjwatson> I have a near-term work item to move component-mismatches off ftpmaster and into ubuntu-archive-tools, which ought to make it easier to work on in this kind of way
[19:41] <mterry> nm, found the readme
[19:41] <cjwatson> I very much want the archive admins not to have to search through MIR bugs, think about security policy, etc.
[19:41] <mterry> cjwatson, makes sense :)
[19:42] <jdstrand> mterry: it allows you to transition to roles based on your id. it makes things like MLS possible: http://wiki.apparmor.net/index.php/Pam_apparmor_example
[19:42] <jdstrand> cjwatson: that sounds wonderful
[19:45] <mterry> jdstrand, so I approved the bug.    Full MIRs should still be double-checked, but it seems the rest of Ubuntu isn't as concerned about binary promotions as I thought they were.  :)
[19:46] <jdstrand> mterry: works for me. I didn't want to do anything untoward is all :)
[19:46] <jdstrand> mterry: thanks!
[20:57] <hallyn> hey, i'm looking at bug 793070, which is fix released for dialog;  but dialog on my precise boxes still shows up in universe
[20:58] <hallyn> I assume I shouldn't file a new MIR (as I was just about to do), but is there something else I should do, or will this happen automatically now?
[21:06] <dobey> hallyn: i guess with the next upload to the archive, it will end up in main rather than universe when published?
[21:07] <hallyn> dobey, ididn't realize it had to wait for that.  Is there some way to *verify* where it will go on next update?
[21:08] <dobey> hallyn: well, the last comment in that bug suggests that it will go into main
[21:09] <jelmer> FWIW, the MIR for subunit was accepted and marked fixreleased too, but it never made it into main (not even after a new upload)
[21:11] <hallyn> dobey, ok, thanks.
[21:11] <micahg> jelmer: something needs to depend on it to bring it in (this + MIR usually prompts the promotion)
[21:16] <jelmer> micahg: ahh, thanks
[21:16] <micahg> jelmer: and if you don't need the explicit depends, it should be added to the supported seed
[21:16] <jelmer> micahg: and here I was, not wanting to build-depend on it until it made it into main.. :-)
[21:16] <micahg> ah, yeah, build-depends will do it :)
[21:17] <micahg> jelmer: without it being used/seeded, it shows up on one of the reports as a candidate for demotion
[21:20] <hallyn> yes, that's good to know, i would've been waiting too :)
[22:13] <broder> slangasek: fyi, just noticed that nthykier added a data.tar.xz-member-without-dpkg-pre-depends tag to lintian, so we'll pick that up next time i do a full lintian run (probably in a week or two)
[23:18] <roaksoax> @pilot out
[23:56] <SpamapS> Daviey: --disable-debug dropped 9k ... down to 133k for the udeb ..


[00:24] <bluesabre> brainwash: bug marked fixed
[00:24] <bluesabre> the ppa sounds like its missing our AccountsService patch
[00:24] <bluesabre> Unit193: yup, now I can send my next request(s)
[00:25] <bluesabre> Unit193: probably just going to merge the debian xfpm
[00:25] <bluesabre> with the version number jump, need to poke -release anyway
[00:30] <Unit193> I'm sure you know this release supports 0.7.0 too.
[00:30] <bluesabre> indeed
[00:30] <bluesabre> :)
[02:01] <bluesabre> gathering a list of xfce packages we cannot directly upload, am I missing anything? http://paste.ubuntu.com/8354635/
[02:09] <bluesabre> xfpm pushed to utopic
[02:24] <bluesabre> ochosi, forestpiskie, feel free to comment on #ubuntu-release
[02:28] <skellat> bluesabre: The points being brought up by ScottK should have been brought up *months* ago
[02:28] <skellat> GNOME should've talked to us about things
[02:28] <skellat> Going off wildcat with Jackson along for the ride is not playing nice socially
[02:34] <bluesabre> thanks for commenting skellat
[02:34] <skellat> bluesabre: You know, I think I'm the only one in Xubuntu Team who doesn't actually have a defined role
[02:35] <bluesabre> have one in mind? :)
[02:36] <skellat> Don't know.  There are rumblings from work about recall.  I have to wait to see how this week plays out.
[02:37] <bluesabre> Seems like, from your various g+ posts, that your work is... unpredictable
[02:38] <Unit193> skellat: What are mica.hg, lder.an, Nos.kcaj, and jj.frv8's roles?
[02:39] <bluesabre> the first is a DMB, so there's that
[02:39] <Unit193> bluesabre: Does that count in Xubuntu?
[02:39] <bluesabre> not specifically :)
[02:39] <skellat> The first is still DMB and thereby owns the xubuntu-dev group, the second is meeting.ology wrangler, the third does packaging, and the fourth is emeritus
[02:49] <skellat> virtualbox is in the list so multiverse is probably included as "unsupported"
[08:45] <brainwash> bluesabre: but it's the package from the ubuntu repo
[08:46] <brainwash> bluesabre: xfdesktop4
[08:47] <brainwash> https://bugzilla.xfce.org/show_bug.cgi?id=11165
[08:47] <brainwash> any idea what else could be broken here?
[08:50] <ochosi> morning everyone
[08:50] <ochosi> i guess there's lots and lots of backlog
[08:51] <ochosi> if any of you have a news-digest in mind for me, that'd be a great time-saver :)
[08:57] <elfy> a few bugs, a few uploads, a few updates and someone expecting everyone to bend over backwards for them - but you know about the last one :)
[11:02] <bluesabre> brainwash: aha, never backported our fix http://changelogs.ubuntu.com/changelogs/pool/universe/x/xfdesktop4/xfdesktop4_4.11.8-0ubuntu1/changelog http://changelogs.ubuntu.com/changelogs/pool/universe/x/xfdesktop4/xfdesktop4_4.11.6-1ubuntu1/changelog
[11:02] <bluesabre> debian/patches/xubuntu_set-accountsservice-user-bg.patch: update
[11:02] <bluesabre>     patch to only update on first workspace filename change (LP: #1318307)
[11:02] <bluesabre> we can do that when we push 4.11.8 to trusty
[11:03] <bluesabre> oh wait, that might not be it
[11:03] <brainwash> sure, but how does this patch help?
[11:03] <bluesabre> the problem might be that he is using a personal wallpaper, right?
[11:04] <bluesabre> the login bg is only updated if it is system-readable, if I recall
[11:06] <brainwash> maybe
[11:06] <brainwash> but why would adding a PPA break this?
[11:08] <brainwash> sadly I have no clue
[11:09] <brainwash> on top of that, it's not an upstream bug :/
[11:09] <bluesabre> it probably didn't... he clearly changed his background after adding the ppa, and we don't have a huge selection, so it is likely its something in his home folder
[11:10] <bluesabre> xubuntu default wp -> xubuntu rocks -> ppa -> /home/user/furry-kittens.jpg
[11:12] <bluesabre> just confirm the location of the file he is selecting, and that will probably reveal itself
[11:36] <bluesabre> work time, bbl
[11:38] <elfy> brainwash bluesabre "the login bg is only updated if it is system-readable" that'd be why it works for me then - I copy bg's into /usr/blah
[11:39] <elfy> commenting
[12:03] <brainwash> elfy: thanks for commenting
[12:04] <brainwash> I thought that accountsservice would just create a copy of the wallpaper to prevent permission issues
[12:05] <brainwash> it works like this for profile pictures
[12:17] <bluesabre> brainwash: accountsservice updates the path to the selected wallpaper instead of copying.  So it has to be readable by the lightdm user, permissions 644 or higher
[12:17] <bluesabre> gotta run, bbl
[15:42] <ochosi> elfy: heh, right, thanks :)
[15:42] <ochosi> had a lot to catch up with today but i'll hopefully be around more tomorrow and tday
[15:50] <elfy> ochosi: :)
[19:34] <Unit193> bluesabre: Reminder, 'systemd-services' only exists as a virtual package.
[19:36] <Unit193> (Hopefully that's helpful.) Updated ppa version numbering.
[20:14] <Noskcaj> skellat, I think my job in xubuntu is actually "Packaging everything that unit, sean, and corsac don't want to"
[20:15] <skellat> :-)
[20:15] <skellat> That works
[20:15] <Unit193> Heh, you just get to some of them first.
[20:15] <Unit193> (That and we pretend we don't see them. :P )
[20:15] <Noskcaj> :)
[20:16] <Noskcaj> problem ricotz just noticed "it seems tumbler is using the wrong thumbails folders which break the native retrieval of the thumbnail-path with gio"
[20:16] <Unit193> https://bugzilla.xfce.org/show_bug.cgi?id=10613
[20:16] <Noskcaj> thanks
[20:17] <Unit193> Sure.
[20:17] <Unit193> skellat: I'd presume you saw there was a new apt-offline?
[20:17] <elfy> hi skellat Noskcaj
[20:17] <Noskcaj> hey elfy
[20:17] <skellat> Unit193: 5 W's?
[20:18] <Unit193> 1.5
[20:18] <skellat> Oooh
[20:18] <skellat> Did it tumble into testing yet?
[20:18] <Unit193> 0 of 5.
[20:18] <skellat> Ah
[20:19]  * skellat has split attention trying to do online bill payments as well as watch IRC and ponder what is happening in the House of Representatives over his employing agency having funding past October 1st.
[20:21] <skellat> Unit193: Nothing too major in changelog other than the Debian BTS module
[20:21] <Unit193> Yep.
[20:21] <skellat> I wonder if there would be any interest in adding support for LP to that mix
[20:21] <Unit193> What for?
[20:33] <skellat> Download LP bugs lists
[23:44] <bluesabre> Unit193: does this seem like a reasonable request? http://paste.ubuntu.com/8361317/
[23:45] <bluesabre> (including a mention that these go to ~xubuntu-uploaders and not myself)
[23:47] <Unit193> bluesabre: This is for you rather than adding to the packageset?  Also, not sure if you want to put it in there or not, but still not sure I get the reasoning if it's not seeded or part of Xubuntu.
[23:47] <bluesabre> I think packageset is auto-generated based on what we ship
[23:48] <Unit193> Something like that, yeah.
[23:48] <bluesabre> The benefit is being able to fix issues with xfce packages that we don't ship, but would need maintenance
[23:49]  * Unit193 shrugs.
[23:49] <knome> well, yeah
[23:49] <knome> i guess a good question would be:
[23:49] <knome> how many of those packages are maintained upstream?
[23:49] <Unit193> Properly in Debian or Xfce. :P
[23:49] <bluesabre> well, its xfce, so probably not many :)
[23:51] <bluesabre> this request is mainly coming from a few packages affected by the gdmflexiserver bug, and finding a sponsor for a package that affects nobody can be a hassle
[23:52] <bluesabre> (ofc, wasting time on a bug that doesn't affect our install is another issue altogether)
[23:52] <Unit193> It's OK, we know you get bored too. ;)
[23:53] <bluesabre> not often, brainwash is always bugging me with bugs
[23:53] <bluesabre> :D
[23:54] <Unit193> Thought about tossing the gmb link at him, those mostly seem dead.


[13:49] <apw> ht85 (N,BFTL), how was it installed, as that sounds a lot like modules-extra did not get installed.


[08:33] <asanchez> hi all!
[08:33] <asanchez> hola nubae
[08:53] <nubae> hola asanchez
[08:55] <asanchez> are you planning to flight to Spain?
[08:55] <nubae> yup, el 30 tengo entrevista en Sevilla
[08:55] <nubae> espero que vaya todo bien
[09:40] <asanchez> nubae, be ready for 40ºC
[09:47] <nubae> gah
[09:47] <nubae> bueno, I'm used to it
[09:47] <nubae> at least its not 50c
[20:50] <LaserJock> nubae: ping
[20:51] <Lns> Hey all
[20:52] <Lns> LaserJock: haha, looks like you gave nubae the ping of death
[20:52] <LaserJock> Lns: heh
[20:52] <Lns> LaserJock: I really like the idea of the script repo
[20:52] <Lns> that's one thing that would be really nice to build up
[20:52] <LaserJock> I thought you might
[20:53] <LaserJock> I was talking with highvoltage about it this morning
[20:53] <alkisg> Hey Lns, LaserJock.... LaserJock, a question please, how could I try to get an "ltsp-server-dnsmasq" package to universe, that only satisfies the dependencies to use dnsmasq instead of the usual dhcp3-server that ubuntu uses? - no code whatsoever?
[20:53] <LaserJock> I think it could easy to implement, give something easy people can contribute to
[20:53] <Lns> it's the lack of automation that makes linux hard for schools right now..they have processes during the year that could be easily automated but no tools exist for it
[20:53] <alkisg> script repo??? I'm in!!! :)
[20:53] <LaserJock> and I think it would help us get feedback on what's lacking
[20:54] <alkisg> I've just finished the school-scripts for Greek schools using ubuntu/ltsp
[20:54] <LaserJock> Lns: I think it would be good to generalize and document these scripts
[20:54] <LaserJock> Lns: people often have a good idea, but they have a specific itch to scratch. A collaborative repo would help to make scripts more useful to the whole community, IMO
[20:55] <LaserJock> alkisg: well, you'll want to upload the package to REVU
[20:55] <highvoltage> alkisg: nice
[20:55] <Lns> exactly
[20:55]  * alkisg googles about REVU
[20:55] <LaserJock> alkisg: it's a tad overkill for a simple metapackage, but that's the usual  place to put packages up for review
[20:56] <Lns> And what's nice, too, would be that these scripts can take many different forms - for instance, we can take the ideas of some of these things and put them into what i'm developing (the thin-client-manager gui)
[20:56] <LaserJock> alkisg: basically you need 2 MOTU to approve the package
[20:56] <LaserJock> alkisg: you could maybe get stgraber and myself to do it
[20:56] <alkisg> OK, LaserJock & stgraber? :P :D
[20:56] <alkisg> Heh!!! :D
[20:56] <LaserJock> heh
[20:56] <LaserJock> alkisg: if you put it up on REVU and let me know the URL I'll review it
[20:56] <alkisg> Thanks man, I'll do that.
[20:57] <LaserJock> Lns: yeah, I sort of see it as an incubation area as well
[20:57] <Lns> Totally
[20:57] <bencrisford> hey LaserJock
[20:57] <LaserJock> Lns: if scripts turn out to be really useful, etc. then they can get picked up by Edubuntu/LTSP proper I think
[20:57] <LaserJock> bencrisford: hi
[20:57] <LaserJock> bencrisford: did you send out the meeting minutes?
[20:58] <alkisg> Where did you talk about the scripts? In the meeting?
[20:58] <bencrisford> LaserJock: =S, No, sorry, I thought you were gonna?
[20:58] <bencrisford> shall i send em now?
[20:58] <LaserJock> bencrisford: I sent you an email with revisions
[20:58] <Lns> alkisg: on the list
[20:58] <LaserJock> bencrisford: but it's your deal dude, send 'em off when you think they're ready :-)
[20:59]  * LaserJock is kickin' back and letting everybody else do the work ;-p
[20:59]  * alkisg curses his slow mail... just got it
[20:59] <bencrisford> LaserJock: Haaaang on, I have the minutes for the 5th june meeting
[20:59] <bencrisford> wasnt there one on the 11th?
[21:00] <LaserJock> hmm
[21:00] <bencrisford> i wouldnt of been here that night
[21:00] <LaserJock> it might have been canceled, I don't remember
[21:00] <bencrisford> k
[21:00] <LaserJock> so on a technical level here's what I think might work:
[21:00] <LaserJock> 1) create an LP project, edubuntu-community-tools
[21:01] <LaserJock> 2) make ~edubuntu-members the driver
[21:01] <LaserJock> the LP Project will allow people to just bzr branch lp:edubuntu-community-tools to get the scripts
[21:01] <LaserJock> and allows people to file bugs against them
[21:02]  * Lns loves that idea
[21:02] <LaserJock> ~edubuntu-members gives some QA, a little perk to being a member, and some incentive to becoming a Member
[21:02] <bencrisford> what scripts?
[21:02]  * bencrisford scrolls up
[21:02] <LaserJock> *eventually* if this works out we could even package it up
[21:02] <LaserJock> bencrisford: read your edubuntu email
[21:03] <Lns> bencrisford: the ones that mostly aren't created yet ;)
[21:03] <bencrisford> cool :)
[21:03] <bencrisford> ill send those minutes now?
[21:03] <bencrisford> thats why i cant read my inbox :P
[21:03] <LaserJock> bencrisford: sure
[21:03] <alkisg> Lns: https://launchpad.net/~ts.sch.gr/+archive/ppa => sch-scripts package. The interface is in Greek, but the code comments are in English, so I think you'll be able to reuse some code. E.g. for locking down firefox settings, for adding applets to the panel for all users, for initial configuration of chroot & updating later on etc.
[21:03] <alkisg> ncurses driven, I want to improve the interface in the summer.
[21:04] <bencrisford> hmm
[21:04] <bencrisford> LaserJock: Scripts that do like what?
[21:04] <Lns> alkisg: wow
[21:04] <alkisg> Basically I took my 100 pages UbuntuLTSP installation/configuration manual and turned it into scripts
[21:05] <alkisg> (still halfway there, though)
[21:05] <bencrisford> ah
[21:05] <bencrisford> back in an hour or so
[21:05] <bencrisford> minutes sent
[21:08] <LaserJock> alkisg: right, that's the kind of stuff I'm thinking of
[21:08] <alkisg> I'm totally in for this! :)
[21:09] <alkisg> ...and if we could get sbalneav or some other good dev with a little spare time to organize us (=define the "framework" of the scripts - not the implementation), we'd get a good start
[21:10] <LaserJock> exactly
[21:19] <Lns> I might have a dev resource for helping out with that
[21:21] <alkisg> Hmmm... that's a nice idea
[21:26] <alkisg> Lns, ask him if it would be possible to have a python GUI with an "embedded terminal" for the scripts to run in.
[21:26] <alkisg> E.g. I would go to a menu (or a search dialog), locate the "update-chroot" script, and then the script would run inside the embedded terminal - so if user input was needed, it would be asked in a usual way inside the program interface...
[21:27] <Lns> alkisg: that's a novel idea, i'm sure some generic terminal could be created as a plugin or some such
[21:27] <Lns> to make scripts run inside the gui easier
[21:28] <Lns> that aren't gui based that is
[21:28] <alkisg> I think the update-manager does that, it has an "expand to see the terminal" button somewhere
[21:28] <yanqui> alkisg: it's very easy to embed ipython into an app
[21:29] <LaserJock> well
[21:30] <LaserJock> in general it would be good to separate frontend and backend
[21:30] <Lns> ah, there he is ;)
[21:30] <LaserJock> so scripts do their thing
[21:30] <LaserJock> but shouldn't make assumptions about frontend necessarily
[21:31] <LaserJock> then a GUI can be placed to feed the backend scripts the parameters they need
[21:31] <yanqui> yeah, it would probably be better to use whiptail/gdialog/xdialog for user input from scripts
[21:31] <yanqui> then the python program just has to system() the script
[21:31] <alkisg> yanqui: that's what I use now (whiptail), and I don't really like the result
[21:32] <yanqui> I've never used whiptail, I used zenity before I started just doing everything in python
[21:32] <alkisg> Because if I didn't take into account something when I execute e.g. apt-get update, and user input is needed, then it's not nice to drop from whiptail to plain terminal
[21:33] <LaserJock> alkisg: the idea is to not need a terminal
[21:34] <yanqui> alkisg: how does update manager and the add/remove thing do it in Ubuntu?
[21:34]  * yanqui kind of agrees with LaserJock
[21:35] <alkisg> Do you think we'll have as experienced programmers involved as update-manager does?
[21:35] <yanqui> and I'd lean toward having plugins be written in python with maybe something to run bash scripts...
[21:35] <LaserJock> update-manager does some funky stuff, not huge
[21:36] <yanqui> alkisg: well if we can just snag that part out then we don't need anything else
[21:36] <LaserJock> but having the terminal there is considered bad usability
[21:36]  * Lns hasn't ever seen update-manager require user input *from* it's terminal interface
[21:36] <LaserJock> and people have wanted to get rid of it forever
[21:36]  * yanqui has
[21:36] <LaserJock> Lns: yes, generally you get a GUI
[21:36] <yanqui> yeah, I agree with LaserJock
[21:36] <LaserJock> it's an implementation detail of Debian packages
[21:36] <Lns> ah
[21:36] <LaserJock> *most* packages use debconf
[21:36] <alkisg> Well, if it's gonna be all-gui, then it should be python programs, not shell scripts...
[21:36] <LaserJock> which has a number of frontends depending on what you're using
[21:37] <LaserJock> however, Debian Policy didn't strictly say you have to use debconf
[21:37] <LaserJock> some some older packages actually just use stdin
[21:37] <LaserJock> hence the need for the terminal there
[21:38] <LaserJock> well, generally I'd see it as
[21:38] <Lns> well who is forcing the use of the terminal? aren't we talking about plugins for a gui to allow extended functionality?
[21:38] <Lns> as in, not in the core code of the gui
[21:38] <LaserJock> 1) start out with bash/perl/python/whatever people used
[21:38] <LaserJock> 2) as the tools become generalized and improved move towards a more standard framework
[21:39] <LaserJock> 3) apply an appropriate UI (not always GUI) and make sure it's consistent with the rest of the tools
[21:39] <LaserJock> Lns: I was just saying why Update Manager has the terminal
[21:39] <Lns> oh gotcha
[21:40] <LaserJock> in terms of usability for our target users (who may or may not be familiar with terminals) I think it's good to shoot for GUI when possible
[21:40] <yanqui> we could just use .desktop files for our script plugin system
[21:41] <yanqui> but python will be what's primarily supported, everything else will be secondary
[21:41] <Lns> yeah
[21:42] <LaserJock> python/bash
[21:42] <LaserJock> sometimes a shell script makes a lot of sense
[21:42] <LaserJock> and it's easily callable from a python GUI
[21:42] <LaserJock> in any case, this is somewhat getting the cart before the horse
[21:43] <LaserJock> there is not repository or code exactly yet :-)
[21:43] <yanqui> well...there is a repo and code, but it's just....embryonic
[21:43] <yanqui> or maybe more of a zygote
[21:43] <alkisg> I don't think .desktop files would be enough, a framework would be needed. E.g. some scripts may be able to "act" on files, others on users... So the "framework" would know which scripts to show when right-clicking on a users list. (ok I now that's not gonna be implemented really soon :D)
[21:44] <Lns> yanqui: i think he's talking about the edubuntu script repo
[21:45] <LaserJock> alkisg: well, what you would have is a .desktop file that points to a wrapper
[21:45] <alkisg> I mean: the python gui shows a groups list, the admin selects two groups, and then goes to the menu that activates a script that does something with the users that belong to these 2 groups
[21:45] <alkisg> The "responsibility" to get the users that belong to these scripts would be on the framework, not on the script
[21:45] <LaserJock> so you have a <plugin>.desktop file that points to a <plugin>_wrapper.py file that defines input/output
[21:46] <yanqui> LaserJock: or we could put some of that stuff into enviornmental vars
[21:46] <yanqui> before exec() a couple of vars get set and there you go
[21:46] <LaserJock> first though I'd focus on the actual scripts
[21:47] <yanqui> first we need something that works
[21:47] <alkisg> I mean something like this (*one* of the front-ends, the users one): http://users.sch.gr/alkisg/temp/users-manager.png
[21:49] <yanqui> well, we'll see... right now we're still trying to get up to the level we were before we started clearning the code
[21:49] <LaserJock> I like alkisg's stuff
[21:49] <LaserJock> I'm wondering if it needs maybe more generalization or something
[21:49] <Lns> alkisg: wow, that looks slick =)
[21:49] <alkisg> There are scripts that just run without needing any parameters, scripts that run on users, scripts that run on groups, scripts that run on files etc
[21:50] <LaserJock> for the "do X to user Y" it's good
[21:50] <alkisg> LaserJock: see on the bottom, there are 3 tabs
[21:50] <alkisg> There should be more there
[21:50] <yanqui> alkisg: what is this?
[21:50] <alkisg> But the idea is that the "admin" could switch to the file view and call a script that acts on a file (e.g.)
[21:51] <LaserJock> well, I just wonder about more generalization and thinking about what we're trying to accomplish
[21:51] <LaserJock> I'm not convinced it should all be in 1 GUI
[21:51] <alkisg> yanqui: a prototype I started making, but I left if for the summer due to lack of time
[21:51] <Lns> alkisg: I'd love it if you would work with us on our tcm project
[21:51] <yanqui> what's it written in?
[21:51] <alkisg> python/gtk
[21:51] <Lns> a lot of these goals seem to overlap
[21:51] <yanqui> do you have a repo I could look at?
[21:52] <alkisg> Lns, sure, I'd like that.
[21:52] <alkisg> yanqui: I could send you the code, but it's not much - it's just the prototype
[21:52]  * Lns invites alkisg to #lns if he'd like to collaborate
[21:52] <alkisg> Lns - gimme a few weeks to finish the things I've started - I'll dive into tcm in July
[21:53] <yanqui> alkisg: can you send it to hex [at] neg9.org?
[21:53] <alkisg> Anyway, as LaserJock says, I think we should start with defining what we're trying to accomplish
[21:53] <alkisg> yanqui: will do
[21:53] <yanqui> well we actually have a roadmap
[21:53] <LaserJock> I'm envisioning something more like an "Education Control Panel"
[21:54] <yanqui> education control panel isn't general enough
[21:54] <LaserJock> where you can install education software, manage LTSP tasks, or do lock-down
[21:54] <yanqui> LaserJock: this could be used in biz too
[21:54] <LaserJock> well, I don't want to generalize too much
[21:54] <LaserJock> as we then lose educational focus
[21:55] <yanqui> one of the major faults of TCM was that it was focused too much on education
[21:55] <LaserJock> I thought it's major fault was it focused too much on LTSP :-)
[21:55] <LaserJock> I want something LTSP-agnostic
[21:56] <Lns> the commonground here is that it should be able to be used for *everything*
[21:56] <yanqui> LaserJock: ltsp agnostic?
[21:56] <Lns> the LTSP parts can be used for ltsp, the user/group/file parts can be used for other stuff...it can all be easily separated in sections/plugins/what have you
[21:57] <LaserJock> Lns: I don't know about *everything*
[21:57] <LaserJock> but it can be developed without lock-in yes
[21:57] <LaserJock> yanqui: LTSP neutral
[21:57] <yanqui> LaserJock: I mean, you want something that focuses more on user management or what?
[21:57] <LaserJock> but for Edubuntu the obvious focus is Education
[21:57] <LaserJock> I mean anything to do with Education on Ubuntu
[21:58] <LaserJock> so I'd like to see an Educational Software installer
[21:58] <LaserJock> I'd like to see Content Management
[21:58] <yanqui> that's far outside the focus of this porject
[21:58] <LaserJock> User Management
[21:58] <yanqui> project
[21:58] <LaserJock> Thin Client Managmenet
[21:58] <Lns> i think we've got some wires crossed =D
[21:58] <LaserJock> those are the things that people need
[21:59] <yanqui> we're focused on thin client managment and user management, if someone wants an educational install I'd be glad to have that as a plugin
[21:59] <Lns> LaserJock: what we're talking about is the TCM project we're reviving.. it can definitely be used for things other than education. I think you're talking about the scripts repo for educational use, which is different
[21:59] <LaserJock> oh, yes
[21:59] <Lns> but both projects can share all sorts of stuff
[21:59] <LaserJock> but I see them as all sort of the same deal
[21:59] <Lns> because the goals overlap
[22:00] <Lns> sure
[22:00] <LaserJock> TCM is the Thin Client Managmenet component
[22:00] <Lns> but they should be maintained separately
[22:00] <LaserJock> but I want to see a whole Education Control Panel thingy
[22:00] <Lns> sure
[22:00] <Lns> that can be its own project
[22:00] <yanqui> well wait here for a sec
[22:00] <LaserJock> well
[22:00] <LaserJock> sub-projects of a larger I think
[22:01] <LaserJock> I don't think TCM is in a vacuum neccesarily
[22:01] <yanqui> we want to have tcm and user managment merged into a single control panel, but they're sort of different at the same time
[22:01] <LaserJock> then need to be separate
[22:01] <LaserJock> *they
[22:01] <LaserJock> because a lot of people don't use LTSP but need user managment
[22:02] <yanqui> but there are overlapping parts that need to be interoperable
[22:02] <LaserJock> exactly
[22:02] <LaserJock> so that's why I'm saying sub-projects of a larger goal
[22:02] <LaserJock> integrated, but distinct programs
[22:02] <Lns> hmmmm
[22:02] <LaserJock> the Education Control Panel just pull them together into a easy-to-get-at interface
[22:02] <yanqui> LaserJock: modular so they could be plugged into a central console but also separated from eachother
[22:03] <LaserJock> so like take the Gnome Control Center
[22:03] <Lns> +1 yanqui
[22:03] <yanqui> right
[22:03] <LaserJock> it's a single interface to get you where you need to go
[22:03] <Lns> gnome-system-tools
[22:03] <LaserJock> but the apps are separate
[22:03] <LaserJock> right
[22:03] <Lns> maybe we can integrate with that project??
[22:03] <yanqui> ok, yeah
[22:03] <LaserJock> Lns: it's dead, that's why I'm trying to get this going
[22:03] <Lns> wha? gnome-system-tools is dead?
[22:04] <LaserJock> yes
[22:04]  * Lns gasps
[22:04]  * yanqui raises an eyebrow
[22:04] <yanqui> how?
[22:04] <LaserJock> all of it is being ripped out but Users and Groups for Karmic
[22:04] <LaserJock> and Users and Groups will be replace as soon as possible
[22:04] <Lns> LaserJock: replaced with what?
[22:05] <LaserJock> so perhaps by the next LTS gnome-system-tools will be completely gone from Ubuntu
[22:05] <LaserJock> Lns: nobody knows yet
[22:05] <Lns> ....
[22:05] <LaserJock> hence why I'm trying to get stuff going
[22:05] <Lns> so it's dead, but they don't know what its successor will be
[22:05] <LaserJock> it's dead because nobody cared to continue it
[22:05] <LaserJock> so there's nobody to replace it
[22:05] <LaserJock> ...
[22:05] <Lns> hmmmmm
[22:05] <LaserJock> the problem was that each of the distros made their own tools
[22:05] <LaserJock> Fedora, Mandriva, openSUSE
[22:06] <Lns> not even distros, GUIs, etc
[22:06] <LaserJock> so nobody cared for g-s-t
[22:06] <Lns> i don't get it though, network-admin is a huge tool used in ubuntu
[22:06] <Lns> how is that just gonna be replaced
[22:06] <LaserJock> no, that's been long gone
[22:06] <LaserJock> replaced by Network Manager
[22:06] <alkisg> I think there was talk about getting the fedora's user management tool to ubuntu
[22:06] <LaserJock> well, maybe not *long* gone
[22:06] <Lns> oh..they kinda look the same =D
[22:07] <LaserJock> I think it was removed for 8.10
[22:07] <LaserJock> alkisg: right, yes
[22:07] <LaserJock> alkisg: but apparently it's pretty fedora-specific so will take a lot of work
[22:07] <yanqui> is the system tools backend still going to be around?
[22:07] <Lns> alkisg: not fds .. ?
[22:07] <LaserJock> yanqui: I'm guessing no
[22:07] <alkisg> yanqui: no, I've heard they're leaving, too :)
[22:08] <LaserJock> g-s-t-backend is mostly perl and nobody wanted to work on it
[22:08] <yanqui> well.... if it's perl
[22:08] <yanqui> that's a good reason
[22:08] <alkisg> A C front-end for a perl back-end... terrific :P
[22:08] <alkisg> It's usually the other way around
[22:09] <LaserJock> well, at least it's not mono :p
[22:09] <yanqui> it should be a C backend and a python frontend
[22:09] <Lns> hahhaa
[22:09]  * yanqui nods
[22:09] <Lns> LaserJock: don't tell that to the easy-ltsp maintainer ;) wel lactually she's porting it to python as well
[22:09] <yanqui> oh yeah, I need to talk to her
[22:09] <Lns> what if *we* pick up the project?
[22:09]  * yanqui opens up his notes
[22:09] <Lns> at least the parts that make sense to us?
[22:09] <LaserJock> Lns: what project?
[22:10] <Lns> LaserJock: gst
[22:10] <alkisg> Lns, which one, easy-ltsp?
[22:10] <Lns> nono
[22:10] <alkisg> Lns: nononono
[22:10]  * yanqui is going to head out for a smoke
[22:10] <yanqui> brb
[22:10] <LaserJock> Lns: I honestly think we're better off starting from scratch
[22:10] <Lns> alkisg: well, what if we rewrite in pygtk?
[22:10] <LaserJock> in python probably
[22:10] <Lns> well yeah..i guess that's whta i meant
[22:10] <alkisg> Lns, yup, that's fedora's tool
[22:10] <alkisg> A good base in pygtk
[22:10] <Lns> hrm
[22:11]  * Lns goes to look at fedora
[22:11] <LaserJock> I mean, nobody really like Users and Groups that much for educational purposes
[22:11] <LaserJock> I kinda think this is our chance to design something that really works well for our users
[22:11]  * alkisg wishes KDE and Gnome were _one_, and we could use kuser :)
[22:11] <Lns> +1 laserjock
[22:12] <Lns> alkisg: you can use kuser outside of kde, i do it all the time
[22:12] <Lns> diversity is the spice of life
[22:12] <Lns> err...variety =p
[22:12] <LaserJock> right, but that's clearly not optimal
[22:12] <alkisg> I think it even supports NIS and LDAP, doesn't it?
[22:12] <Lns> alkisg: yeah, ldap at least
[22:12] <LaserJock> additionally, I'd like to see an Educational Software Manager of some kind
[22:13] <LaserJock> as we're going to DVD I don't think it's really going to be possible for us to just drop every app on the user's machine
[22:13] <alkisg> LaserJock: like the add-remove-programs but only for educational software?
[22:13] <LaserJock> kinda yea
[22:13] <LaserJock> as a first iteration we can use Add/Remove with a custom menu
[22:14] <LaserJock> I think Add/Remove is on it's way out too
[22:14] <LaserJock> not sure how long that will take
[22:14] <bencrisford> back
[22:14] <LaserJock> but something we'll probably have to keep in mind eventually
[22:15] <Ahmuck> hows the project going?
[22:16] <Ahmuck> i've often wondered why linuxes don't offer a basic os and then a add/remove program.  OEM windows loads their computers up with software that "clutters" the drive and requires removal
[22:17] <LaserJock> Ahmuck: I guess you answered your question
[22:17] <LaserJock> well
[22:18] <LaserJock> Linux does offer that, almost every distro
[22:18] <LaserJock> hence why Ubuntu is one 1 CD
[22:18] <LaserJock> but if you consider having to download 1GB of software post-install, who wants that? :-)
[22:22] <yanqui> LaserJock: so whats wrong with using add/remove programs for educational progs?
[22:22] <yanqui> why a special manager?
[22:23]  * alkisg gotta go... Goodnight all
[22:23] <yanqui> alkisg: later
[22:24] <LaserJock> yanqui: well, because Add/Remove just has a flat "Education" menu
[22:24] <Ahmuck> LaserJock: how's the disertation?
[22:24] <LaserJock> yanqui: and many of the apps that we want to give people are scattered in other categories
[22:24] <LaserJock> Ahmuck: pretty good
[22:24] <yanqui> ahh
[22:24] <LaserJock> Ahmuck: getting close to done I think
[22:25] <yanqui> LaserJock: what about using metapackages?
[22:25] <Ahmuck> so, last i knew, edubuntu was trying to "find itself".  Has it found itself yet?
[22:26] <LaserJock> yanqui: well, we already do
[22:26] <LaserJock> yanqui: but again, you have to find them, etc.
[22:26] <LaserJock> and meta-packages don't offer a very clear view of the broader stuff
[22:26] <LaserJock> we can define core sets, etc.
[22:26]  * yanqui nods
[22:26] <LaserJock> but beyond that meta-packages become sort of tricky
[22:27] <LaserJock> because you have hard dependencies and somebody is bound to  not like something
[22:27] <yanqui> right
[22:27] <LaserJock> and even if you go with Recommends instead of Depends it's you still end up having to install a bunch of stuff you may-or-may-not want
[22:27] <LaserJock> Ahmuck: I think it's getting there yes
[22:28] <LaserJock> Ahmuck: there's been a fair amount of activity
[22:28] <LaserJock> Ahmuck: for instance, we talked to the Technical Board and they were fine with us going to a full distro and DVD
[22:28] <LaserJock> and also using Universe packages
[22:32] <bencrisford> !info kino
[22:32] <bencrisford> LaserJock: How come kino is in the edubunut bugsquad packages
[22:33] <LaserJock> because it was a part of Edubuntu
[22:33] <bencrisford> oh
[22:33] <bencrisford> im'a get some sleep
[22:33] <bencrisford> night LaserJock
[22:34] <LaserJock> bencrisford: night
[22:36] <nubae> btw... cinelerra is a really good video editing suite, rivaling kino in many ways... should defintely be carried by edubuntu (at least as universe app)
[22:36] <nubae> btw... u guys see teh site I just launched.... linux for education
[22:36] <Lns> I think we need to do something about the GST suite going away..this would be perfect for us to cater to larger installations and do other neat tasks with other tools
[22:37] <yanqui> Lns: we need to think about the scope of our goals and the resources we have avaliable
[22:37] <nubae> I know it might seem opensuse centric at the moment, but its meant to be for all distros...
[22:37] <nubae> is there anyone here who't like to be an admin and hlep edubuntize it a bit?
[22:37] <Lns> yanqui: yeah... :) well at least we should be keeping in touch with whoever is going to take over the project so we can contribute and hopefully get some of our stuff out there that way too
[22:37] <nubae> that doesnt mean replacing all opensuse terms with edubuntu, but to make sure its distro-agnostic
[22:37] <Lns> nubae: i saw your post, good work! =)
[22:38] <yanqui> Lns: I agree, lets talk about this in the lns channel for a moment
[22:38] <LaserJock> nubae: yeah, I took a look
[22:38] <Lns> yanqui: k
[22:38] <nubae> Ive already got a couple of folks helping out, but would like to have the site carrying at least 100 courses by end of the month
[22:38] <LaserJock> nubae: interestingly we've got similar opportunities with the Ubuntu Learning Project
[22:39] <LaserJock> I'm not sure how to deal with the possibility of having 2 different places for similar content
[22:39] <nubae> well, lets not try to redevlop the wheel, lets cooperate and get a damn good portal for education
[22:39] <nubae> well, how is it similar
[22:39] <nubae> is ubuntu learning project moodle?
[22:40] <nubae> the main thing we are working on right now is restring moodle courses from open university
[22:40] <nubae> all of which are creative commons
[22:42] <LaserJock> yes, it's moodle
[22:42] <LaserJock> the Ubuntu Learning Project is primarily about learning how to use Ubuntu
[22:43] <LaserJock> but they consider learning about how to use Ubuntu in learning a part of that as well
[22:44] <LaserJock> linux-for-education seems much more specific to the subject
[22:46] <LaserJock> nubae: who's hosting this project?
[22:46] <nubae> cool so its like a subsection of linux for education... can we export the courses and put them under the Ubuntu based courses?
[22:47] <nubae> an individual heavily involved with openSuse... but I'd like to create mirrors
[22:47] <nubae> currently though, I do believe its private... ie, not direclty affiliated to any one company
[22:47] <LaserJock> it would be awesome to have it co-sponsored by the main Edu distros
[22:48] <nubae> You can see we filled up the IT courses
[22:48] <LaserJock> RichEd was wanting to do this a couple years ago
[22:48] <LaserJock> as a part of his Ubuntu in Education thing
[22:48] <nubae> 25 courses just on IT
[22:48] <LaserJock> but it never really got off the ground
[22:48] <nubae> then we platform specific stuff
[22:49] <nubae> well, its about putting ones nose to the grindstone
[22:49] <nubae> which I did for a week
[22:49] <nubae> check out the perfect suse desktop
[22:49] <nubae> that ook me a good 12 hours to do
[22:50] <nubae> but its abolutely great now, easily adaptable when needed
[22:50] <nubae> anyway, one could easily adapt that to edubuntu
[22:50] <LaserJock> nubae: did you get the emails about the Technical Board meeting?
[22:50] <nubae> ie.... its a guide to expand the base edubuntu/opensuse-edu
[22:51] <nubae> yes... but how do they affect me? wasnt quite sure about that
[22:53] <LaserJock> nubae: well, we got the go-ahead for a DVD and to use Universe to build it
[22:54] <nubae> oh that yes, that was great, was really happy about that
[22:54] <nubae> has anything been decided re: user management?
[22:54] <LaserJock> not sure
[22:54] <nubae> that seems like an ultra urgent thing
[22:54] <LaserJock> resources
[22:55] <LaserJock> somebody (several somebodies) needs to put time into user management
[22:55] <nubae> other distros have such good mechanisms and ours looks like it 10 years behind (literllay)
[22:55] <LaserJock> nubae: well, we relied on upstream, trying to be a bit more "pure"
[22:55] <LaserJock> but as other distros just did their own thing anyway, upstream eventually seems to have died out
[22:56] <nubae> well see, this is the problem... thats why things stagnate
[22:56] <nubae> yeah exactly...
[22:56] <nubae> so... then lets just get to it
[22:57] <nubae> copy what somoene else has done or straight off hck at what we already gitt
[22:59] <LaserJock> well, somebody's got to do it, sounds like Lns and alkisg might be interested
[23:03] <LaserJock> we really need to find a way to get some developer time
[23:04] <Lns> LaserJock: right now i couldn't imagine being able to handle such a big project for ubuntu, but again our own little tool might be something good to focus on
[23:06] <LaserJock> baby steps for sure
[23:09] <Lns> because things like mass-user addition is a must for schools during the new school year start
[23:10] <Lns> the scripts i saw, iirc had something with a CSV file parser that did this kind of thing..that'd be neat, and very universal
[23:12] <LaserJock> there are also gobs of python libraries for these things
[23:12] <LaserJock> CSV input, I think there's a library for interacting with /etc/group and /etc/passwd
[23:19] <Lns> well that makes it easier i guess =)
[23:55] <Lns> now that i remember system-config-* in fedora/redhat, i'm all for *buntu merging with that... =) Those utils are way cool
[23:55] <Lns> The userlist sorts, for one ;)