[12:45] <enyc> I have changed the. status tags on bugs 78005 77485 ... was this right for me to do this as per the new MOTU-SRU policy?
[12:45] <ubotu> Malone bug 78005 in qpsmtpd "[SRU]  request: dapper:qpsmtpd fix for bug #72602" [Undecided,Fix committed]  https://launchpad.net/bugs/78005
[12:45] <enyc> I'm a little confused whom is now supposed to do the release- upload.... or how I do it....
[12:45] <enyc> Please let me know what todo ?? [??]
[12:46] <enyc> (note that both bugs have now passed the ">=7 days aging and >=2 'worksforme' requirements!
[12:46] <enyc> )
[12:46] <enyc> next-step suggestion needed please ;-)
[01:51] <andre_pl_> i seem to still be plagued by this bug: https://launchpad.net/ubuntu/+source/udev/+bug/53923 with the tifm 5-in-1 media card reader.
[01:51] <ubotu> Malone bug 53923 in udev "Texas Instruments Card reader (8039) not working" [Medium,Confirmed]
[01:51] <andre_pl_> but its apparently fixed.
[01:52] <andre_pl_> wait, no its not. Lol.
[01:52] <andre_pl_> how can I help to fix it?
[01:54] <Chipzz> andre_pl_: I guess most developers are asleep now; but you may get more response on #ubuntu-kernel (just a wild gues without looking at the bug)
[01:54] <sladen> andre_pl_: confirm your experiences in the bug report
[01:54] <sladen> andre_pl_: they'll get recorded there, but will just scroll past here :)
[01:55] <andre_pl_> sladen: thanks
[01:55] <Chipzz> sladen: you can disregard my last comment about hal and the nvidia driver and suspend btw :)
[01:55] <sladen> andre_pl_: when it comes to eventually doing a test it's important to know who can test the result
[01:55] <sladen> Chipzz: I didn't see it in IRC hilights, was it on launchpad?
[01:55] <Chipzz> yeah, launchpad
[01:56] <Chipzz> made it last week
[01:56] <sladen> Chipzz: okay, I'll get to it in-time, but if the comment isn't correct/is now out of date, can you comment again so that we know what the status quo is
[01:56] <Chipzz> sladen: thanx for the comments and hints in that bugreport btw :)
[01:57] <Chipzz> I will, but not now ;)
[06:09] <fabbione> morning
[06:10] <sladen> just, getting, light
[06:15] <thoreauputic> Just wanted to say - Feisty is looking great! Congrats to all ... :-)
[08:23] <Mithrandir> lifeless: is there any reason why opensync is a few versions behind upstream?
[08:33] <ajmitch> hi Mithrandir
[08:35] <manchicken__> Anybody know what "ubuntu-linux.withishow.com" is all about?
[08:35] <ajmitch> yet another planet ripoff?
[08:36] <ajmitch> there are a couple I've seen
[08:36] <manchicken__> It looks like they're trying to syndicate stuff from the ubuntu planet, and then comment on blogs to attract people to their advertising.
[08:36] <ajmitch> back later
[08:37] <Mithrandir> hiya Andrew.
[09:01] <pitti> Mithrandir: FF-wise, would you be ok with me adding a --confirm switch to debcommit? (see mdz's mail re bzr package maintenance)
[09:04] <Mithrandir> pitti: sure
[09:06] <pitti> Mithrandir: hmm, if I touch the package anyway, I guess I'll also include requestsync, to get rid of another long-standing low-priority TODO item
[09:09] <Mithrandir> sure
[09:38] <tuxcrafter> good day eveyone
[09:39] <lifeless> Mithrandir: I suck ?
[09:40] <lifeless> or azeem does. Or we both do.
[09:40] <lifeless> the theory is that azeem and I are co-maintaining the suite. However it seems to have panned out that I maintain libopensync* and he maintains the plugins and gui.
[09:40] <Mithrandir> ook
[09:41] <Mithrandir> I have a personal interest in getting my phone to sync with evo, you see, and I think the newer upstream versions fixes that.
[09:43] <Mithrandir> tepsipakki: regarding the ndiswrapper UVFe.. it's a fairly big diff which is hard to review due to the traceexit => exit changes (and other similar ones).  Do you have any reports from people running your latest package and where it works for them?
[09:48] <lifeless> Mithrandir: I have a 'anyone can NMU' policy on all my packages.
[09:48] <lifeless> Mithrandir: so if you ahve the time, upload away. It will want an ABI change though, I'm pretty sure upstream fucked the current release of the plugins et all across the recent version releases.
[09:49] <Mithrandir> lifeless: it'd require a motu-uvf exception too, so I'm trying to get somebody else to do it.
[09:49] <lifeless> Mithrandir: haha
[09:52] <tepsipakki> Mithrandir: not yet, but as you can see, most of the changes are in driver/ which isn't used in ubuntu
[09:52] <tepsipakki> the driver is in our kernel
[09:52] <Mithrandir> tepsipakki: point.
[09:52] <tepsipakki> and that is already 1.38, it's just a matter of updating the utils
[09:53] <Mithrandir> hurrah, I get to review somebody else's perl code.
[09:54] <carlos> pitti: Hi, would you like to try latest fesity export?
[09:54] <azeem> lifeless: there's the problem that opensync-0.22 or so has some different database format, so users need to remove parts of their ~/.opensync
[09:54] <carlos> pitti: it should have the weird new line chars removed completely
[09:54] <azeem> huh, opensync-0.22, my terminal is acting up
[09:54] <carlos> pitti: I did it also for the other distros
[09:54] <pitti> carlos: I already dist-upgraded today
[09:54] <carlos> dist-upgraded?
[09:55] <Mithrandir> azeem: just make the tools notice it and run opensync --reset (or the equivalent) when they detect the older database format?
[09:55] <pitti> carlos: current daily langpacks are from 20070327 timestamp
[09:55] <carlos> so you pushed yesterday tarball?
[09:55] <pitti> carlos: no, the daily ones on people
[09:55] <pitti> I didn't upload them to feisty yet, since you asked me to wait
[09:55] <seb128> hi carlos
[09:56] <seb128> carlos: did you do the french translations change yet? ;)
[09:56] <azeem> Mithrandir: that's the second problem, the GTK GUI "tool" currently in feisty is rotten and not really usable
[09:56] <azeem> a first step would be to use the one from unstable, but I wasn't sure whether this is still possible
[09:56] <carlos> seb128: no, I hadn't time, I was finishing the cleanup and run out of time to do that, but I plan to request it today
[09:56] <Mithrandir> azeem: kitchensync or multisync0.90 you mean?
[09:56] <pitti> carlos: oh, there's a 20070328 tarball from 2 o'clock today; that's the good one now?
[09:56] <carlos> pitti: would be possible to force a refresh now?
[09:56] <azeem> multisync0.09
[09:56] <Mithrandir> kitchensink is maybe the kde one?
[09:56] <carlos> pitti: yeah
[09:57] <carlos> I had to do some fixes so it was built later than expected
[09:57] <pitti> carlos: sure; I usually build them in the afternoon, but I'll crank up one now
[09:57] <azeem> Mithrandir: yes, and AFAIK nobody packaged an opensync-enabled kitchensync until now
[09:57] <carlos> pitti: thank you
[09:57] <seb128> carlos: ok, thank you, let me know when it's done
[09:57] <carlos> seb128: sure
[09:57] <seb128> cool
[09:57] <azeem> but maybe somebody from kubuntu did in the meantime, I haven't checked in a while
[09:57] <pitti> carlos: oh, in fact it's already running; I forgot, I build them at 0800 rookery time
[09:58] <carlos> but those are for Edgy, Hoary and Dapper, isn't them?
[09:58] <Mithrandir> azeem: http://www.in.fh-merseburg.de/~jahn/opensync-0.21/pool/main/o/opensync-integration-kitchensync/ isn't it?
[09:58] <pitti> carlos: no, I build dailies for feisty, too
[09:59] <carlos> oh, so you always use an old Feisty package
[09:59] <carlos> ?
[10:00] <azeem> Mithrandir: yes
[10:00] <lifeless> azeem: yeah
[10:00] <azeem> hrm right, Matthias did it in the meantime, could've guessed
[10:00] <lifeless> azeem: its why I haven't packaged it, I know it needs testing
[10:01] <lifeless> and doco and stuff
[10:10] <dholbach> hello
[10:10] <siretart> hallo dholbach
[10:14] <dholbach> hey siretart
[10:14] <dholbach> how's it going?
[10:14] <siretart> oh, thanks.
[10:20] <tuxcrafter> i got a very anoying bug here, i am testing openoffice 2.2 in feisty and my odt documents from v2.1 are not opened the same in 2.2 how does this come, i mean odt is a open standard and should be backwards compatible?! do you feisty users have the same problem?
[10:25] <tepsipakki> if someone would like to test the new upstream intel driver (1.9.93 aka 2.0rc3), here it is: http://users.tkk.fi/~tjaalton/xorg72/new/
[10:25] <tepsipakki> that's xserver-xorg-video-intel
[10:25] <tepsipakki> modesetting-branch merged in
[10:25] <StevenK> Mithrandir: When you have a sec, I'm curious why the 1.4-12build1 upload of imaze didn't register a build on amd64 or ia64.
[10:25] <tepsipakki> it needs the new server -3ubuntu6 I just uploaded, but a deb is available from the url
[10:25] <Mithrandir> StevenK: might be a fallout of yesterday's hiccups; I'm running the queue builder again and we can see if that helps.
[10:26] <Mithrandir> StevenK: ah, it's in PaS
[10:27] <Mithrandir> does it work and run on amd64/ia64?
[10:27] <StevenK> Hrm. I know it builds and installs fine.
[10:27] <tuxcrafter> bye
[10:27] <Mithrandir> mail infinity or lamont to get PaS updated in Debian and we'll pick it up.
[10:28] <StevenK> On amd64, anyway, since I'm too cheap to buy an Itanic :-P
[10:28] <Fujitsu> StevenK: I was going to ask how you'd tested that :P
[10:29] <StevenK> Fujitsu: There's always merkel.debian.org. For me, anyway.
[10:29] <Fujitsu> You and your evil uber-powers.
[10:29] <Mithrandir> hm, no, that's just imaze-xview.
[10:29] <Mithrandir> I can't read.
[10:30] <StevenK> Mithrandir: xview is in the archive for amd64.
[10:32] <Mithrandir> StevenK: I don't know, I'll have to ask cprov.
[10:33] <doko> ARGH!!! feisty shuts down my laptop way too often due to "critical" temparature
[10:34] <StevenK> doko: Where critical is it might make the desk slightly warm? :-P
[10:34] <Treenaks> doko: open it up,remove dust :)
[10:45] <Lure> azeem, Mithrandir: I can work on kitchensync update if you will do opensync upgrade
[10:46] <geser> StevenK: as you uploaded xview with amd64 support, does it work without the patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320155 ?
[10:46] <ubotu> Debian bug 320155 in xview "xview: amd64 support" [Wishlist,Open]
[10:46] <Mithrandir> Lure: opensync is in universe, so it'd require motu-uvf approval, not ubuntu-release approval, but I would be quite happy if somebody did the work to make it work.
[10:47] <Lure> Mithrandir: afair, we need to package it as debian is not on latest, right?
[10:47] <Mithrandir> yes.
[10:48] <Mithrandir> Lure: but you'd be better off starting talking to motu-uvf to see if they think it's worth it.
[10:49] <Lure> Mithrandir: will check this first, the problem is it is hard to discuss it as nobody has tried it to confirm the benefits
[10:49] <Lure> Mithrandir: I can probably try it now, that bluetooth is fixed in kubuntu ;-)
[10:50] <_ion> pitti: "Yo inicie efectos del escritorio y me marco que no tengo el composite habilitado y luego marco el error."  yeah, thanks a lot for the bug report! ;-)
[10:51] <pitti> _ion: comprehende, amigos?
[10:52] <Mithrandir> "Tango and Composite makes my Luggage report an error".
[10:53] <pochu> _ion: I started desktop-effects and it told me I don't have composite enabled, and after that there was an error ;)
[10:55] <_ion> pochu: Hehe, thanks. The bug report *did* contain apport info, which explained everything, though, so i was just joking.
[10:55] <pochu> _ion: you could told it before :p
[10:55] <pochu> however, it wasn't a great effort, since my spanish is great :)
[10:56] <tepsipakki> eh, why do we have ndiswrapper-1.1 in main?
[10:56] <pitti> tepsipakki: it's on the kill list
[10:56] <tepsipakki> pitti: groovy
[10:56] <pochu> well, it was a great effort, because my enghish isn't :(
[10:56] <pitti> tepsipakki: bug 92622
[10:56] <ubotu> Malone bug 92622 in ndiswrapper-1.1 "[REMOVE]  Please remove ndiswrapper-1.1 from archives" [Undecided,Confirmed]  https://launchpad.net/bugs/92622
[10:56] <tepsipakki> pochu: new, working intel driver available
[10:56] <_ion> pochu: Sorry for causing extra work. :-)
[10:56] <pitti> tepsipakki: I just wante to wait for the last reverse dependency to be fixed
[10:56] <tepsipakki> pitti: ok
[10:57] <tepsipakki> just looking at the list of ndiswrapper bugs
[10:57] <pochu> tepsipakki: cool! :)
[10:57] <tepsipakki> removing -1.1 would fix bug 59983, I think
[10:57] <ubotu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Low,Confirmed]  https://launchpad.net/bugs/59983
[10:58] <Mithrandir> pitti: there doesn't seem to be any reverse deps on ndiswrapper-1.1's binaries?
[10:59] <pitti> Mithrandir: right, because it was fixed recently (see bug trail)
[10:59] <tepsipakki> no low hanging fruits left there, it seems
[10:59] <Mithrandir> ahkay.
[10:59] <Mithrandir> tepsipakki: 59983 is one of those where I think we'll just have to work around in the update manager
[10:59] <tepsipakki> guess so
[11:37] <janimo> pitti: hi, is there a guideline in naming locales, in particular in the mozilla-firefox-locale packages? When is it recommenede to us lo_LO vs lo ?
[11:37] <janimo> pitti: as there are locales which are specific to a single country but still use the longer form (hu_HU, ro_RO) while other the simpler (sk, af)
[11:38] <pitti> janimo: the longer ones are mainly for hysterical raisins
[11:38] <janimo> pitti: what I am confronted with is, that there's a ro.xpi for ff 2.0 and it uses the ro locale all over, but teh current packaging stub have ro_RO
[11:38] <pitti> janimo: just to save us from renaming the existing packages yet again
[11:39] <pitti> janimo: for new languages, we should use whatever upstream uses
[11:39] <janimo> pitti: ok, I file a bug on mozilla-firefox-locales-all and attach the ro.xpi, is that the procedure?
[11:40] <pitti> janimo: you don't need to attach it if upstream has it
[11:40] <pitti> asac: ^ we should update m-f-local-all to <IP_ADDRESS>, right?
[11:40] <pitti> janimo: ^ or just file a general bug about that
[11:40] <pitti> ugh, it's still at .1
[11:41] <janimo> pitti: I am not sure it's in upstream firefox, I think it's provided asa separate extension. I'll check though
[11:41] <pitti> janimo: in this case, attaching it is fine
[11:53] <dholbach> ogra: will we get dia 0.96-final?
[11:54] <dholbach> ogra: it seems to fix bug 93303
[11:54] <ubotu> Malone bug 93303 in dia "Program Dia crashes when deleting a diagram object" [Medium,Confirmed]  https://launchpad.net/bugs/93303
[12:12] <pitti> _ion: hm, did you see bug 93209? yet another missing ID
[12:12] <ubotu> Malone bug 93209 in restricted-manager "Fails to detect Nvidia 3D driver" [Medium,In progress]  https://launchpad.net/bugs/93209
[12:13] <pitti> _ion: hm, current package does not have 'manual' lists any more, does it?
[12:16] <opi> guys, can you point me to the person who owns ubuntu-*.org DNS servers? We're moving our servers and need small change in IN A records. :)
[12:17] <opi> Smurfix was the BOHF in 2004, but I renember his server went down and the DNS moved somewhere
[12:17] <highvoltage> opi: you can reach the admins on #canonical-sysadmin
[12:17] <opi> highvoltage: oh! Thanks!
[12:17] <highvoltage> opi: any time
[12:18] <kwwii> dholbach: btw. I commited another session splash last night (fixed a small problem)
[12:21] <dholbach> kwwii: uploaded
[12:21] <kwwii> dholbach: excellent, thanks :-)
[12:22] <dholbach> de rien
[12:24] <_ion> pitti: % modinfo -F alias nvidia | grep 01D8
[12:24] <_ion> pci:v000010DEd000001D8sv*sd*bc03sc*i*
[12:24] <_ion> pitti: Perhaps that was one of the IDs the amd64 port doesn't support, or something.
[12:24] <pitti> _ion: hmm, that's with your new l-r-m patch-of-doom?
[12:24] <pitti> _ion: aah, that's entirely possible; I generated it on amd64
[12:24] <pitti> _ion: thanks
[12:25] <_ion> pitti: Yeah, but the list is exactly the same as the modules.alias.override list generated from the 9631 x86 driver.
[12:25] <ajmitch> hi
[12:26] <_ion> pitti: Yeah, the amd64 port indeed doesn't list 01D8, whereas the x86 port of both 96xx and 97xx list that.
[12:27] <pitti> _ion: I changed the bug accordingly
[12:27] <_ion> pitti: It would be a huge pain to maintain both x86 and amd64 lists in the restricted-manager package. We probably should just wait until l-r-m generates the listings.
[12:27] <pitti> _ion: right, that's what I wrote in the bug
[12:28] <_ion> pitti: Btw, if it's ever needed to add manual entries, they would go to something like /usr/share/restricted-manager/modalias_override/nvidia.manual. The filename doesn't matter, but i think it's good to add '.manual' to manually edited files.
[12:29] <pitti> ah, great
[12:29] <pitti> well, I hope that this entire crack will soon disappear at all from r-m ;)
[12:30] <_ion> Yeah. :-)
[12:30] <_ion> /usr/share/restricted-manager/modalias_override/ipw3945.manual probably needs to stay, though.
[12:30] <_ion> since it doesn't seem to be a kernel module, but some kind of a daemon.
[12:31] <pitti> ah, right
[12:36] <ogra> dholbach, yes, i'm on it, the documentation is horribly broken, wroking on a patch here
[12:36] <dholbach> ogra: ok
[12:36] <ogra> somehow the xml is messed up
[12:42] <pochu> if any archive-admin can take a look at bug 98532 :)
[12:42] <ubotu> Malone bug 98532 in liferea "[UVFe]  Liferea 1.2.10b" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98532
[12:44] <pitti> pochu: nothing to do for archive admin
[12:45] <pochu> sorry, release-admin :)
[12:45] <pitti> pochu: if you want a sync, please turn this into a sync request and get UVF exception approval from Mithrandir
[12:45] <pochu> it's not a sync, since it's not in debian
[12:45] <pitti> ah, ok
[12:45] <pochu> but an uvf exception, yes :)
[12:46] <Mithrandir> pochu: that's not "admin" at all, it's "ubuntu-release" or "the release team". :-P
[12:46] <pochu> hehe
[12:47] <Mithrandir> anyway, looks sane, approved
[12:47] <pochu> so you or cjwatson should look at it, as the LP team page says :)
[12:47] <pochu> Mithrandir: cool, thanks :)
[12:47] <azeem> Mithrandir: I filed https://bugs.launchpad.net/ubuntu/+source/multisync0.90/+bug/98545 now for multisync0.90
[12:47] <ubotu> Malone bug 98545 in multisync0.90 "[UVFe Sync Request]  multisync0.90 0.91.0-3" [Undecided,Unconfirmed]
[12:49] <Mithrandir> azeem: cheers.  I think it would make sense to get an approval for the whole suite, not just multisync.
[12:49] <azeem> Mithrandir: well, the rest isn't packaged yet, this one has been in unstable for a while
[12:59] <dholbach> ogra: dia 0.96.1 is out
[12:59] <dholbach> ogra: brown paper bag release
[01:02] <ogra> meh
[01:03] <ogra> ok
[01:03] <ogra> thanks dholbach
[01:03] <dholbach> de rien ogra
[01:13] <_lemsx1_> in Feisty when i choose to switch to another user (local) the computer goes to a black screen and the switch never happens
[01:14] <_lemsx1_> this is an ATI card running fglrx driver. i'll try in another computer to see if there is a difference
[01:15] <pitti> lemsx1|gone: I noticed the same on nvidia
[01:15] <pitti> lemsx1|gone: one user had compiz, the other didn't
[01:15] <lemsx1|gone> pitti: ahh, so it's not the card
[01:15] <pitti> probably a composite bug in X.org
[01:15] <lemsx1|gone> pitti: no compiz used here
[01:16] <lemsx1|gone> pitti: did you try turning off composite? in my case it's explicitly off since fglrx doesn't support it
[01:16] <pitti> lemsx1|gone: no, I didn't
[01:16] <lemsx1|gone> pitti: i wonder under what package this bug should be filed
[01:16] <pitti> lemsx1|gone: xorg-server AFAICS
[01:17] <lemsx1|gone> pitti: ok. i see that there are two X processes running. one on :0 and another on :20
[01:17] <john> Hello. I am running Feisty, and i would like to report a bug again "Disk Usage Analyzer" aka baobab. Launchpad doesn't allow me to report said bug on the gnome-utils section. So where can i do that?
[01:17] <lemsx1|gone> pitti: if you login via ssh and kill gdm and the X processes, the machine hard-locks and you have to press the button to reset it
[01:17] <lemsx1|gone> john: try #ubuntu-bugs
[01:18] <cjwatson> pitti: should bug 71560 be milestoned for 7.04 final? even just some kind of "this crash will take a while to process - do you want to proceed" heuristic might help, if that's what it takes
[01:18] <ubotu> Malone bug 71560 in apport "Crash information collection depletes resources, clogs up and crashes system" [Medium,Confirmed]  https://launchpad.net/bugs/71560
[01:18] <john> thanks
[01:19] <pitti> cjwatson: it already has that jumping progress bar; it usually should take less than a minute, but for the guy in the last comment it took 40 minutes or so; I don't have an idea how to predict that
[01:20] <cjwatson> size of core dump?
[01:21] <pitti> cjwatson: I could just limit the core dump to, let's say, 500 MB; that should help already
[01:21] <pitti> cjwatson: but TBH I'm rather inclined to disable crash interception for the final release completely
[01:22] <pitti> we neither have the retracing nor the triaging capacity for the flood of crashes in feisty stable, nor will we fix most of the crasher bugs in stables
[01:22] <Keybuk> really?
[01:22] <cjwatson> mm, somebody asked about that on the QA call last night
[01:22] <Keybuk> I would strongly advocate having it enabled
[01:22] <pitti> and for high-prio bugs we can still ask users to enable it again locally
[01:22] <Keybuk> a friend has been much happier with feisty simply because apps don't just vanish, and she at least sees that dialog
[01:23] <Keybuk> (she nearly always clicks "No")
[01:23] <cjwatson> if it's easy to switch back on, I'd be in favour of disabling it by default
[01:23] <pitti> it's on today's meeting agenda
[01:23] <Keybuk> not to mention that sometimes you don't know there's been a crash
[01:23] <pitti> cjwatson: it's changing /etc/default/apport back to enabled ATM
[01:23] <cjwatson> I don't see why we can't say "an application crashed; do you want to do something about it?" without expensive core processing
[01:23] <pitti> in feisty+1 we might have automatic dup detection and better malone handling and all that
[01:24] <cjwatson> even in the typical case, what is it doing for that less-than-a-minute before it says "something crashed"?
[01:24] <pitti> cjwatson: would be theoretically possible
[01:25] <cjwatson> it should be SIGSEGV -> kernel writes core -> inotify -> dialog surey
[01:25] <cjwatson> surely
[01:25] <pitti> cjwatson: it reads the report and unpacks the core along with that; I know that this is suboptimal, but takes some invasive code changes to fix
[01:25] <pitti> oh, the 'less than a minute' I alluded to was the gdb/dpkg processing
[01:26] <pitti> for displaying the initial notification it just needs to read the file in /var/crash
[01:27] <pitti> this entire process could do with some optimization and some rewriting of the lower-level classes, but that's not something I would do for feisty final
[01:27] <cjwatson> perhaps a quick approach would be to simply notice that the file is there and (by default) display a notification before spending time reading it
[01:27] <cjwatson> presumably even just reading (and parsing?) it can be pretty slow and memory-intensive for large core dumps
[01:27] <pitti> right
[01:28] <pitti> but in that case I like the idea of limiting the core dump size better
[01:28] <pitti> if even merely writing/compressing the dump lasts 10 minutes on that user's machine
[01:28] <cjwatson> that would have the benefit of simplicity, although I'd have thought that 500MB is too big
[01:29] <pitti> since at that time we cannot really display any UI
[01:29] <cjwatson> can it be related heuristically to free memory available?
[01:29] <cjwatson> I suspect that in that user's case apport is running into swap trying to parse the crash dump and then the system starts thrashing
[01:29] <pitti> cjwatson: certainly, yes
[01:30] <cjwatson> and in that case, we're turning the situation from the random user's perspective from "it crashed. bugger. ok, restart it and worry about it later" to "it crashed. bugger. oh, now my system is unresponsive."
[01:30] <cjwatson> which is suboptimal :)
[01:30] <Keybuk> pitti: why does it need to "read" the file?
[01:30] <Keybuk> can't it just mmap it?
[01:31] <pitti> Keybuk: it's RFC822/base64 encoded
[01:31] <Keybuk> heh
[01:31] <pitti> however, due to the way we sort the fields, it would be enough to just read the top
[01:31] <pitti> Keybuk: but as I said, merely writing the crash report when the crash itself happens already triggers that trashing problem
[01:32] <Keybuk> sure, but at that point, they've clicked "Report Problem" so they're gonna expect some work
[01:32] <Keybuk> no?
[01:32] <cjwatson> it's three minutes from the crash to the initial dialog, not 10
[01:32] <Keybuk> the computer is visibly playing pong
[01:32] <pitti> Keybuk: no, when the crash happens, not when the UI pops up
[01:32] <Keybuk> why does it do it then?
[01:33] <cjwatson> oh, sorry, apparently nobody said it was 10 and I just misread something
[01:33] <pitti> Keybuk: it needs to turn the kernel's stdin into a compressed report in /var/crash
[01:34] <cjwatson> Keybuk: I think it's building it all in memory and then writing it out
[01:34] <pitti> so, I think from all the optimizations that would be possible, the only thing that would be reasonable for feisty is to cap the core size to the free memory
[01:34] <cjwatson> the core dump size limit would have to be in kernel_hook
[01:34] <pitti> right
[01:35] <cjwatson> can we notify the user that the crash happened, but that they didn't have enough free memory to deal with the crash?
[01:35] <cjwatson> at least for Keybuk's "you don't know there's been a crash" thing
[01:36] <pitti> cjwatson: yes, we could make the UI check for that case (no CoreDump in /var/crash/foo.crash)
[01:36] <cjwatson> perhaps a CoreDumpSuppressed key in the report or something, and then teach frontends to avoid filing bugs about that
[01:36] <cjwatson> can't just be lack-of-CoreDump because python crashes don't have that
[01:36] <cjwatson> CoreDumpTooBig
[01:37] <pitti> cjwatson: right, that's already taken care of; I meant lack of core dump for signal crashes
[01:37] <cjwatson> ok
[01:37] <cjwatson> so, going back, can I milestone this bug for 7.04 and summarise this conversation?
[01:37] <cjwatson> ah, you're doing it
[01:38] <cjwatson> thanks
[01:38] <pitti> thanks for the discussion
[01:41] <pitti> cjwatson: done; I'll file a separate bug about the optimization steps mentioned above (for feisty+1)
[01:57] <Keybuk> rofl
[02:21] <_ion> pitti: :-)
[02:26] <jwendell> any openoffice maintainer here?
[02:27] <Seveas> doko is :)
[02:31] <jwendell> doko, could you take a looh at bug 75478? It seems to be trivial to fix
[02:31] <ubotu> Malone bug 75478 in openoffice.org "No shortcut to OpenOffice::Draw" [Medium,Confirmed]  https://launchpad.net/bugs/75478
[02:33] <doko> jwendell: no, works as designed. https://wiki.ubuntu.com/MenusRevisited
[02:36] <jwendell> doko, i don't understand why we have shortcuts for calc, write, etc... but none for draw. That wiki page does not explain this
[02:41] <kwwii> my guess would be that nobody uses the paint program to draw pics except for those needed in  the other OO apps
[02:42] <sn-> my guess is as openoffice is a office clone, it acts similar to the way ms office used to
[02:43] <sn-> which i believe didn't have a seperate shortcut for the draw package, instead opened through whichever app you were using
[02:51] <lemsx1> hello all. just wanted to add that switching users works perfectly fine on Intel graphic cards
[02:51] <lemsx1> maybe the issue has something to do with ATI's and nvidia's only
[02:52] <jsgotangco> lemsx1: pretty much
[02:52] <pitti> lemsx1: it usually works for me as well, I just saw it once, ever
[02:52] <jsgotangco> pitti!
[02:52] <pitti> hi jsgotangco
[02:53] <pitti> seb128, carlos: there, fresh new feisty langpacks, candidate for an official upload; wanna test?
[02:53] <carlos> pitti: sure!
[02:54] <carlos> pitti: daily snapshot repositories?
[02:54] <seb128> without the french changes then? :/
[02:54] <pitti> carlos: yep
[02:54] <seb128> pitti: will test sure
[02:54] <carlos> seb128: no, sorry
[02:54] <pitti> seb128: -v ?
[02:54] <carlos> seb128: but I will try to get a new tarball with that for tomorrow, not sure whether pitti would be able to use that, though
[02:54] <pitti> seb128: I can mangle the french ones manually
[02:55] <seb128> pitti: GNOME translator complained that they work go to /dev/null so carlos is going to do some rosetta magic to use upstream translations when available
[02:55] <carlos> pitti: it depends on Rosetta export data
[02:55] <carlos> maybe we could delay the French one until tomorrow
[02:55] <pitti> seb128: ah, so it's not something I could fix by changing a couple of po files in the source?
[02:55] <pitti> carlos: we can also update the French one tomorrow again
[02:55] <seb128> pitti: no, it's "rosetta taking over nice translated with outdated broken ones"
[02:55] <seb128> pitti: ok, let's do that
[02:55] <seb128> update french again tomorrow
[02:55] <pitti> seb128: updating four packages won't hurt anyone tomorrow
[02:56] <pitti> seb128: and I'll update them again at least once, don't worry
[02:56] <seb128> pitti: ok, cool
[02:56] <carlos> ok
[02:57] <carlos> I will handle everything to get it done today
[02:58] <seb128> thank you
[03:03] <lemsx1> pitti: usually works but lately is not working? that used to work for me on Dapper/Edgy
[03:09] <izi_> pitti: i just uploaded a new patch for bug #97726 (you're martin right ?)
[03:09] <ubotu> Malone bug 97726 in restricted-manager "Restricted Drivers Manager's "computer restart" icon is not consistent with other restart icons" [Low,Confirmed]  https://launchpad.net/bugs/97726
[03:09] <pitti> izi_: splendid! thanks
[03:09] <pitti> izi_: yes, I am Martin Pitt
[03:09] <izi_> pitti, ok :)
[03:09] <_ion> (There's the 'whois' command in your IRC client, too. :-) )
[03:09] <izi_> sure
[03:56] <bddebian> Heya
[04:07] <_ion> benc: Any comments about the third patch? :-) I realized that i should have put the change_module_aliases script under debian/. Should i send a new patch to change its location?
[04:10] <mvo> Riddell: my modification to make the kde dist-upgrader use kde debconf seems to work. we just need to ensure that libqt-perl is installed (is that default?)
[04:11] <Hobbsee> mvo: it appears that...if a user upgrades while the proposed updates repository is enabled, they'll end up with an orphaned copy of app-install-data-commercial because edgy 6.3 > feisty 6
[04:11] <Hobbsee> mvo: known?
[04:11] <mvo> Hobbsee: no, good that you report it!
[04:12] <StevenK> It's still probably an issue because 6.2 is in edgy-updates
[04:13] <Hobbsee> mvo: right.  getting the original person to report it :)
[04:20] <Hobbsee> mvo: will you just bump the version number, or do you have other stuff to add?
[04:20] <Hobbsee> mvo: if it's just bumping the version number, i could probably do it, and give StevenK something to do with his new shiny upload powers
[04:20] <Hobbsee> (to give you time to focus on other, mroe complicated stuff)
[04:20] <Keybuk> Holy X Crash! Nvidia Man!
[05:12] <seb128> dholbach: do you know why Tango theme inherit on crystalsvg?
[05:12] <pitti> hey, it's not long any more until we will get the 100.000th bug report
[05:12] <dholbach> seb128: because that's the 'desktop independent thing' - you can use it in kde too
[05:12] <dholbach> so it can fall back to crystal
[05:12] <dholbach> (for them)
[05:14] <seb128> dholbach: it breaks the evolution icon
[05:14] <dholbach> oh?
[05:14] <dholbach> how so?
[05:14] <seb128> dholbach: upstream install its own to hicolor
[05:15] <seb128> and crystal is used before
[05:15] <seb128> so we get the crystal one on the Human theme
[05:15] <seb128> which is ugly
[05:15] <dholbach> if you have crystal installed
[05:15] <iwj> siretart: See my comment on bug 75681.  Aurelien managed to get some informative but unfortunately not sufficient debug info.  I've asked him and you for some more.
[05:15] <ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
[05:15] <dholbach> seb128: hm, what do you suggest?
[05:16] <seb128> dholbach: get a nice evolution icon to Human or Tangerine? ;)
[05:16] <dholbach> seb128: ok, which icon is that?
[05:16] <seb128> evolution
[05:16] <tkamppeter> Anyone here who has a printer from HP?
[05:17] <seb128> tkamppeter: I've an HP deskjet
[05:17] <seb128> dholbach: dpkg -L evolution-common | grep icon
[05:17] <tkamppeter> If so, please go to bug 98520 and follow the steps in my "CALL FOR TESTING" (2nd posting).
[05:17] <ubotu> Malone bug 98520 in hplip "Feisty UVF ER: New HPLIP 1.7.3 release fixes lots of bugs" [Medium,Needs info]  https://launchpad.net/bugs/98520
[05:17] <seb128> ok
[05:18] <tkamppeter> seb128, thanks in advance.
[05:18] <tkamppeter> Any other volunteers?
[05:22] <siretart> iwj: sorry, I was on a buisness trip on monday and tuesday, and have managed to keep up with the mail backlog this morning. I'll test and provide the info this evening
[05:22] <siretart> I had to deal with a lawer regarding REVU as well, but at least he was pretty kind
[05:25] <siretart> iwj: you might be interested that since some weeks I don't obseve my raid devices coming up in degraded mode anymore (this was rather sporadic that time as well, though). what I'm rather observing is that only one of four raid devices "come up" automatically. `udevtrigger` does fix things for me however, and I can continue booting with CTRL-d
[05:26] <Hobbsee> siretart:  a lawyer regarding REVU?
[05:26] <Mithrandir> hiya Hobbsee
[05:26] <Hobbsee> hey Mithrandir!!!!
[05:27] <siretart> Hobbsee: yes, someone uploaded a package with a cracked licence key inside
[05:27] <siretart> Hobbsee: they asked me to have it removed from revu + google cache
[05:28] <Hobbsee> siretart: fun.....
[05:28] <pitti> siretart: hm, maybe REVU should have a robots.txt
[05:29] <siretart> pitti: it does have now
[05:29] <jcapote> anyone know where i can get the gnome.applet module for python?
[05:29] <Hobbsee> siretart: that person now got banned from REVU?
[05:29] <siretart> Hobbsee: I'm still waiting for him to answer my email
[05:30] <lamont> pitti: is langpack stuff you or doko?
[05:30] <pitti> lamont: me
[05:30] <pitti> lamont: hello!
[05:30] <lamont> oo.o/ia64 is giving ia64 livecd fits
[05:30] <lamont> rather, the lack of oo.o binaries,  which get sucked in by task:ubuntu-desktop
[05:31] <pitti> lamont: I cannot parse that, sorry
[05:31] <lamont> task ubuntu-desktop pulls in oo.o pieces (lang pack depends on oo.o english help or some such??) and so the livecdfs build fails
[05:32] <doko> lamont: get a bigger CD ;-P
[05:32] <lamont> the longterm fix is to actually port oo.o to ia64, but the trampolines require someone with painfully intense knowledge of C++ vs C calling conventions, and assembly for the architecture in question...
[05:33] <lamont> The following packages have unmet dependencies:
[05:33] <lamont>   openoffice.org-help-en-us: Depends: openoffice.org-writer but it is not installable
[05:33] <lamont> actually.... WHY IN THE HELL DOES oo.o-help DEPEND on OO.O binaries?
[05:33] <lamont> doko: ^^???
[05:34] <doko> lamont: because you need -writer to get it working
[05:35] <lamont> vi doesn't work?
[05:35] <siretart> isn't the -help package just data?
[05:35] <doko> lamont: it's a db4.x database
[05:35] <lamont> dropping that depends would allow ia64 to have a livecd (without oo.o, mind  you)
[05:36] <lamont> and oo.o-writer is in task ubuntu-desktop itself, no?
[05:36] <siretart> I had the impression that it was common practice to have -data packages to recommend the 'base' package rather than depend in order to break circular dependencies
[05:36] <lamont> Task: ubuntu-desktop, kubuntu-desktop, edubuntu-desktop
[05:36] <pitti> Keybuk: wrt. apport core dump size limit, do you agree that MemFree+Cached-Writeback (in /proc/meminfo) is a reasonable size?
[05:37] <doko> siretart: but then people complain that help is broken, if -writer is not installed
[05:37] <lamont> siretart: oo.o-help-en-us isn't a dep of -writer
[05:37] <pitti> lamont: we could just drop language-support-en from the ia64 seed
[05:37] <lamont> that means making it and the oo.o-help packages arch-any instead of arch-all
[05:37] <lamont> otherwise the task install cataches them
[05:37] <lamont> catches, even
[05:38] <pitti> lamont: ah, true that
[05:38] <pitti> lamont: erm, it is already
[05:38] <siretart> doko: that's why there is the recommends. we have a spec to have 'Recommends' to be installed by default, after all
[05:38] <pitti> lamont: ubuntu-meta produces arch:any binaries for that reason
[05:39] <Keybuk> pitti: yeah
[05:39] <lamont> pitti: any arch_all package that is in Task ubuntu-desktop makes us lose
[05:39] <siretart> doko: if people are deliberatly not installing recommends, they shouldn't complain here, imo
[05:40] <lamont> rather, in task: ubuntu-live
[05:40] <lamont> see oo.o-h-e-us
[05:40] <Lutin> glatzor: ping
[05:42] <lamont> Mithrandir: any objections to me creating an oo.o-writer dummy package that is Arch: ia64?
[05:42] <lamont> iz big huge crowbar
[05:43] <doko> pitti: install language-support-xx doesn't create the C locales; wasn't this fixed sometime?
[05:43] <doko> lamont: the dummy package seems to be the best solution IMO
[05:43] <pitti> doko: urgh, no, seems to have slipped
[05:43] <lamont> doko: anything besides oo.o-writer that you know I need?
[05:44] <pitti> some java maybe?
[05:44] <cjwatson> Mithrandir,seb128,pitti: FYI, I'm reviewing the glassfish/glassfish-bin/netbeans/imq/sunwderby cluster in NEW - feel free to ignore it
[05:45] <pitti> ah, nice
[05:46] <cjwatson> I assumed it was sun-dub-ill-yew-dar-bee
[05:46] <cjwatson> or der-bee, I guess, since they're USian
[05:47] <doko> cjwatson: dholbach will happily assist ;-p
[05:48] <thom> ew, derby
[05:49] <doko> lamont: need for what?
[05:49] <lamont> to satisfy other *^*^80 oo.o-$mumble  dependencies that are in my way. :0)
[05:52] <doko> lamont: I don't know of any other.
[05:59] <dholbach> doko: ?
[06:01] <iwj> siretart: Only one of four raid devices come up ?  Err, but surely you only need one to boot from.  Or do you mean one of the four components ?
[06:02] <iwj> siretart: Anyway, thanks for your effort to provide info.
[06:02] <Riddell> mvo: libqt-perl isn't default in edgy no
[06:10] <LaserJock> I need an archive admin, there's a problem with a broken SRU in edgy-updates
[06:12] <pitti> LaserJock: in the queue, or released?
[06:12] <LaserJock> released
[06:13] <pitti> LaserJock: how broken?
[06:13] <pitti> LaserJock: there's little that an archive admin can do, apart from waving through an updated package
[06:13] <LaserJock> well, as far as I can tell it's an archive issue
[06:13] <LaserJock> I did an SRU for python-imaging
[06:14] <LaserJock> but I got a couple reports of people not being able to upgrade
[06:14] <LaserJock> I *think* the issue is that one of the binaries moved from Universe to Main for feisty
[06:15] <Mithrandir> lamont: feel free.
[06:15] <Mithrandir> cjwatson: yay, thanks.
[06:15] <LaserJock> the bug reports I got so far are bug #96729 and bug #98550
[06:15] <ubotu> Malone bug 96729 in python-imaging "updating asks to install python-imaging which would break the system." [Undecided,Needs info]  https://launchpad.net/bugs/96729
[06:15] <ubotu> Malone bug 98550 in python-imaging "python-imaging-tk dependency problems in kubuntu-edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98550
[06:15] <pitti> LaserJock: hm, the package has always been in main
[06:16] <LaserJock> pitti: source package yes, but I think python-imaging-tk was in Universe for dapper/edgy
[06:16] <LaserJock> but it's in Main for Feisty
[06:17] <pitti> python-imaging-tk | 1.1.5-10build1 | edgy/universe | amd64, i386, ia64, powerpc, sparc
[06:17] <pitti> python-imaging-tk | 1.1.5-10ubuntu1 | edgy-updates/universe | amd64, i386, ia64, powerpc, sparc
[06:17] <pitti> python-imaging-tk | 1.1.5-10ubuntu1~prop1 | edgy-proposed/universe | amd64, i386, ia64, powerpc, sparc
[06:17] <lamont> openoffice.org-ia64-dummy_1.0_source.changes uploaded
[06:17] <pitti> LaserJock: it seems fine within edgy
[06:17] <LaserJock> ok
[06:18] <pitti> LaserJock: maybe broken apt-get or so? e. g. md5sum mismatch on edgy-updates/universe or so?
[06:19] <LaserJock> pitti: well, one guy was using dselect, the other looks like he was using aptitude
[06:20] <mvo> Riddell: hm, not ideal
[06:20] <pitti> $ dpkg -I python-imaging-tk_1.1.5-10ubuntu1_i386.deb|grep Depends:
[06:20] <pitti>  Depends: python-imaging (= 1.1.5-10ubuntu1), [...]
[06:20] <pitti> hmm
[06:20] <pitti> LaserJock: apt-cache policy python-imaging-tk would be interesting to see from those guys
[06:21] <LaserJock> pitti: ohhhh, I think I found something
[06:21] <LaserJock> pitti: one of the guys has edgy-updates turned on for Main but not Universe
[06:21] <pitti> that would be it
[06:21] <mvo> Riddell: well, if libqt-perl is installed it will use the proper kde frontend now
[06:22] <LaserJock> pitti: phew, I thought I somehow busted Edgy
[06:22] <LaserJock> I did test installs/upgrades and rechecked the deps and I just couldn't figure out what was going on
[06:26] <bddebian> suuuuure ;-)
[06:29] <bddebian> :-(
[06:29] <LaserJock> yeah, you better be :-(
[06:29] <LaserJock> ;-)
[06:31] <bddebian> :) Hi poningru
[06:31] <poningru> yarr
[06:31] <bddebian> back in a bit..
[06:31] <bddebian> Freakin' meetings :-(
[06:32] <poningru> thesaltydog: where are you from?
[06:32] <thesaltydog> rome- italy
[06:32] <poningru> there is a local 'pub' here called ' the salty dog'
[06:32] <poningru> nm
[06:32] <thesaltydog> nm = New Mexico?
[06:32] <poningru> hehe never mind
[06:32] <poningru> but I am in gainesville florida
[06:33] <thesaltydog> gimme the wensite of that pub!
[06:33] <thesaltydog> s/wensite/website
[06:33] <poningru> not sure they have one
[06:33] <poningru> but let me look
[06:33] <poningru> its a hole in the wall where all the grad students go
[06:33] <poningru> dirty hole in the wall
[06:33] <thesaltydog> :-)
[06:34] <poningru> http://www.saltydogsaloon.com/
[06:34] <thesaltydog> thank you! bye
[06:34] <poningru> hehe cya
[06:45] <Lutin> glatzor: is there a reason to make webboard depend on python2.4 rather than 2.5 in feisty ?
[07:17] <Lure> Mithrandir: should this be milestoned for release - bug 91009?
[07:17] <ubotu> Malone bug 91009 in wireless-tools "wireless-tools / wireless extension version mismatch" [Undecided,Confirmed]  https://launchpad.net/bugs/91009
[07:19] <Mithrandir> Lure: quite possibly.
[07:19] <kwwii> dholbach: did you see https://launchpad.net/ubuntu/+source/human-icon-theme/+bug/96497
[07:19] <ubotu> Malone bug 96497 in human-icon-theme "Evolution icons are wrong" [Wishlist,Unconfirmed]
[07:19] <kwwii> dholbach: I have absolutely no idea why it is looking/finding a file in crystalsvg
[07:20] <dholbach> kwwii: yes, that's cause because tango falls back to crystal and gnome
[07:20] <kwwii> I think that the problem is that before it used the "email" icon from tango
[07:20] <kwwii> ahhhh, now I get it
[07:20] <dholbach> it's the "desktop environment independent thing" of tango
[07:21] <dholbach> we'd probably need a nice icon in human or something
[07:21] <dholbach> that'd just fix it
[07:21] <dholbach> evo ships its own in hicolor
[07:21] <kwwii> dholbach: and which one is better/which one do we want to use?
[07:21] <dholbach> but normal icon themes are considered before hicolor
[07:21] <kwwii> the tango email icon seems to be the one we were using in edgy
[07:22] <kwwii> at least, that is the one that I saw
[07:22] <kwwii> well, I'll pick one and perhaps touch it up a bit and add it to the human theme
[07:22] <kwwii> dholbach: thanks for the info
[07:22] <dholbach> that's probably the easiest
[07:22] <dholbach> kwwii: i only know because seb128 asked me about it earlier already
[07:22] <kwwii> ;-)
[07:38] <carlos> pitti: I just started a new lang pack export with the French changes asked by seb
[08:01] <MisterN> hi. may i ask some question about SSP and its use in Ubuntu?
[08:01] <pitti> carlos: ah, great
[08:03] <MisterN> i'll just ask and see if i get ignored :D
[08:03] <MisterN> is stack-protector/SSP really necessary when you have NX?
[08:04] <kylem> most people don't have NX.
[08:05] <MisterN> well SSP is default on x86-64, too. there, all processors should have it. right?
[08:06] <kylem> istr no.
[08:07] <MisterN> "istr"?
[08:07] <kylem> i think a few revs of Pentium 4 with em64t are missing it.
[08:07] <kylem> 'i seem to recall'
[08:07] <MisterN> :/
[08:09] <keescook> MisterN: it's all about making things harder.
[08:09] <keescook> MisterN: without SSP, an attacker could still leverage an attack that doesn't execute the stack
[08:10] <keescook> MisterN: imagine them using code snippets from the running program to setup system calls via a long chain of stack return locations.
[08:10] <MisterN> the question is whether it is worth it
[08:11] <MisterN> but i understand that systems without NX need to be supported
[08:11] <keescook> I think it's worth it even with NX processors.  :)
[08:12] <MisterN> i was not so pleasantly surprised when i learned about an hour ago that all my programs are compiled with ssp enabled by default
[08:12] <Mithrandir> MisterN: why not?
[08:12] <MisterN> because that makes benchmarking my own programs harder
[08:13] <MisterN> i don't, for example, fear buffer overflow attacks in some obscure coding contest entry :)
[08:14] <Mithrandir> then use -fno-stack-protector.
[08:14] <wick2o> afternoon
[08:14] <MisterN> well i think that NX alone would be good enough. but as it's not portable...
[08:16] <keescook> MisterN: if you're curious about why SSP is still needed with NX, I recommend reading through http://www.suse.de/~krahmer/no-nx.pdf
[08:17] <MisterN> keescook: well the safest is just not having buffer overflows :)
[08:17] <Mithrandir> sure, and I would like to get rid of global warming too.
[08:18] <MisterN> well i suspect that my own code has any buffer overflows :)
[08:18] <LaserJock> Mithrandir: really? it's kinda chilly here right now ;-)
[08:21] <_ion> benc: Online? :-)
[08:22] <BenC> _ion: always :)
[08:22] <_ion> benc: Sorry to bug you, but is there something in the third patch i sent that i should fix?
[08:23] <BenC> _ion: Haven't looked yet, I think I'll get back to nvidia in a few hours
[08:23] <_ion> benc: Alright.
[08:23] <_ion> benc: I probably should have put the change_module_aliases under the debian directory.
[08:24] <_ion> s/under/script under/
[08:27] <mjg59> Hm. The lists.ubuntu.com archives don't seem to be updating?
[08:28] <pochu> they're laggy :)
[08:33] <mjg59> 3 days laggy?
[08:35] <carlos> pitti: do you have 5 minutes?
[08:39] <Adri2000> Mithrandir, doko: is it possible to fix MoM please? it's not been updated for ages...
[08:39] <Mithrandir> Adri2000: can you ask me during my workday, please?  Or just send me an email.
[08:40] <LaserJock> Adri2000: you need MoM output?
[08:40] <Adri2000> LaserJock: yes
[08:42] <Adri2000> Mithrandir: I already asked Keybuk a while ago, he said it was a problem with some debian mirror... so he should be aware of that, but I can send a mail if you want
[08:43] <Mithrandir> Adri2000: thanks.
[08:44] <david> anyone use gspca for webcam?
[08:46] <elmo> mjg59: yes, 3 days laggy.  pipermail is a hideous evil piece of crap
[08:47] <Mithrandir> david: yes, why?
[08:47] <elmo> the stupid thing has a 2.4Ghz opteron dedicated to just doing archiving and it can't keep up right now - we're look at options, but I'm probably going to disable ubuntu-bugs archiving soon
[08:47] <Mithrandir> fsvo use, at least.
[08:47] <david> I can't get the controls to work. driver works and I can see image.
[08:47] <Mithrandir> elmo: ouch; is it doing it on demand or out of cron?
[08:47] <david> in kopete the autobright option does nothing as the other bright,cnt,color ctls...
[08:47] <elmo> Mithrandir: it's a daemon
[08:48] <Mithrandir> elmo: you can try turning that off and just having it deliver to mboxes which you generate nightly or every four hours or something; pipermail supports that with just minimal changes.
[08:48] <Mithrandir> (until you switch to lurker or mhonarc or whatever)
[08:48] <elmo> Mithrandir: I don't want to break archiving for the entire site
[08:48] <elmo> and transitioning is non-trivial
[08:49] <Mithrandir> ok
[08:49] <david> the only control that works is the automatic color correction checkbox.
[08:51] <Mithrandir> david: let me see that mine still works; which tool are you using to capture?
[08:52] <david> kopete
[08:52] <david> or camorama
[08:57] <Mithrandir> the color/hue/white balance ones doesn't work for me, but constrast and brightness work just fine
[08:57] <Mithrandir> (using camorama)
[08:59] <david> can you tell me what your cat /sys/module/gspca/parameters/autoexpo show
[09:05] <glatzor> Lutin: No, I don't think so. I am surprised that it was actually used by somebody :)
[09:05] <david> Mithrandir: can you tell me what your cat /sys/module/gspca/parameters/autoexpo shows
[09:06] <Mithrandir> david: 1
[09:07] <glatzor> Lutin: I haven't found the time to look at for quite some time or release a later version - although there are many changes for it in my local bzr tree
[09:07] <david> Mithrandir: Do you know how to send params to the module?
[09:09] <Lutin> glatzor: ok, so it should work with python2.5 as is ? (look at bug #96842 and bug #844)
[09:09] <ubotu> Malone bug 96842 in webboard "[apport]  webboard-applet crashed with ImportError in <module>()" [Undecided,Confirmed]  https://launchpad.net/bugs/96842
[09:09] <ubotu> Malone bug 844 in rosetta "WordPress  export MO is not working (dup-of: 214)" [Medium,Fix released]  https://launchpad.net/bugs/844
[09:09] <ubotu> Malone bug 214 in rosetta "Getting system error while generating .mo file" [Medium,Fix released]  https://launchpad.net/bugs/214
[09:09] <Lutin> err bug #96844
[09:09] <ubotu> Malone bug 96844 in webboard "[apport]  webboard crashed with ImportError in <module>()" [Undecided,Confirmed]  https://launchpad.net/bugs/96844
[09:10] <Lutin> glatzor: this can be fix by either stick to python2.4 or moving to python2.5, so I wanted to know what you think is the best
[09:14] <Mithrandir> david: what do you want me to do?
[09:20] <david> Mithrandir: Just wanted to know if you knew how to send parms to the module. Sort of manual config the driver.
[09:20] <siretart> iwj: I hope https://beta.launchpad.net/ubuntu/+source/mdadm/+bug/75681/comments/79 contains all information you need
[09:20] <ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]
[09:21] <iwj> siretart: Thanks must go have food talk to you later
[09:22] <siretart> iwj: enjoy your meal!
[09:23] <sladen> BenC: what was that commit you did a while back for i965 DRM?  I've just noticed that on this i915 I have no direct rendering rendering or Xv
[09:23] <Lutin> glatzor: still here ?
[09:24] <glatzor> Lutin: yes, had to make a phone call :)
[09:24] <glatzor> wait, I will look at those bugs
[09:25] <glatzor> Lutin: hm. I think I will reply tomorrow.
[09:25] <glatzor> You are subscribed to the bugs?
[09:25] <BenC> sladen: userspace or kernel side problem?
[09:27] <Lutin> glatzor: basically the bugs are caused by dependancies on python2.4 whereas it's executed with python2.5
[09:27] <sladen> BenC: should I expect to be seeing some mention of 'dri' or 'drm' in lsmod?
[09:27] <mjg59> Yes
[09:27] <glatzor> Lutin: basically there should be no reason against using python2.5
[09:28] <Lutin> glatzor: ok, cool
[09:29] <Lutin> glatzor: if you want to fix the package the package when you have some time, feel free to do it (and un-assign me ;) )
[09:31] <Lutin> glatzor: otherwise, just tell me and I'll fix it
[09:36] <pitti> carlos: pong
[09:36] <carlos> pitti: hi
[09:36] <carlos> pitti: did you see any error like with previous language packs related to the weird new line char?
[09:37] <pitti> carlos: not yet, but it's been a while since I saw such an error
[09:37] <carlos> I think you said it was in Feisty
[09:37] <pitti> right, maybe two weeks ago or so
[09:38] <carlos> pitti: would be helpful if you could try to reproduce it with new language packs
[09:38] <kwwii> pitti: just added a comment to bug #96510 , we are using the wrong icon in the menus for apport I think
[09:38] <ubotu> Malone bug 96510 in ubuntu-artwork "Report a problem icon doesn't match other icons" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96510
[09:41] <pitti> carlos: I can just grep for those characters
[09:41] <pitti> kwwii: oh, thanks
[09:41] <carlos> pitti: don't worry, I can do it myself
[09:42] <kwwii> pitti: does that seem right to you?
[09:42] <kwwii> pitti: although sabdfl liked the one we are using now
[09:44] <pitti> kwwii: in fact, the icon in the context menu is not the apport one, but the stock gnome warning
[09:44] <kwwii> ;-)
[09:44] <pitti> kwwii: anyway, this is a bug against apport, so reassinging it with some guidance where I should change what is appreciated
[09:44] <kwwii> pitti: hrm, then let's wait to change it
[09:45] <pitti> kwwii: in today's meeting we'll discuss about entirely removing it from the final release anyway
[09:45] <kwwii> pitti: hehe, that would solve the problem very well indeed :-)
[09:46] <carlos> pitti: btw, The spanish language pack doesn't seem to be broken
[09:46] <carlos> good night!
[09:46] <MisterN> n8
[09:47] <pitti> bye carlos
[10:11] <Lutin> seb128: could you have a look to the debdiff attached to bug #92538 when you have some time ?
[10:11] <ubotu> Malone bug 92538 in libgpod "python-gpod should depend on python-eyed3" [Undecided,In progress]  https://launchpad.net/bugs/92538
[10:15] <seb128> Lutin: I'll have a look, not now though, I'm in the middle of a meeting
[10:18] <Lutin> seb128: ok, np. thanks
[10:23] <ajmitch> morning
[10:23] <dholbach> hi ajmitch
[10:29] <siretart> is bug #98739 for acpi-support or for the kernel?
[10:29] <ubotu> Malone bug 98739 in Ubuntu "Module acerhk is not loaded" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98739
[10:29] <_ion> seb128: A couple months back, we had a short discussion about the compiz/beryl 'state' plugin allowing one to create rules that define the default brightness for various windows. Here's a screenshot that should demonstrate what it's good for: http://johan.kiviniemi.name/pictures/screenshots/beryl_per_window_brightness/original
[10:31] <seb128> _ion: either I'm using my windows and want them with a normal light or I'm watching a movie and not doing something else
[10:31] <seb128> that's doesn't look something we need
[10:31] <mjg59> siretart: Right now there's no good way to fix that
[10:31] <mjg59> It's certainly not an acpi-support issue
[10:33] <seb128> _ion: I get what it's doing though ;)
[10:33] <siretart> mjg59: oh? I thought acpi-support had some infrastructure to do notebook specific fixes
[10:34] <siretart> mjg59: actually, I told nobse to file that bug. the actual fix looks rather easy to me
[10:36] <mjg59> siretart: acpi-support handles acpi. acerhk bangs hardware directly.
[10:37] <siretart> mjg59: just to understand the issue, why is ibm-acpi loaded automatically on thinkpads?
[10:39] <mjg59> Because it can precisely determine whether something is a Thinkpad or not
[10:44] <sladen> siretart: the default of acerhk is to assume it Acer type XYZ.  Which is wrong.  The default should be to fail loading without a definite positive match
[10:45] <sladen> siretart: so it's not even possible to "try attempting to load acerhk regardlessly", as it'll just end up screwing the hardware
[10:56] <siretart> sladen: any idea how to have this fixed in the mid-term?
[10:57] <fabbione> Mithrandir: rm something is ok for who knows what to look for.. that's not disabling a service in a nice way..
[10:57] <Mithrandir> fabbione: people who have configured IPv6 statically are power users.
[10:58] <Mithrandir> if you want to provide patches which add IPv6 support to NM, please, but it's not a blocker in any way.
[10:58] <fabbione> Mithrandir: not necessarely..
[10:58] <fabbione> Mithrandir: it might not be a blocker.. it's still a regression..
[10:59] <Mithrandir> fabbione: I haven't said it's not a regression, I've said it's not something I care about for the release.
[11:00] <sladen> siretart: needs to be done in the kernel module, and have the module exit instead of default (actually a fairly small change)
[11:00] <Keybuk> we have hundreds of thousands of regressions every time we make a release
[11:00] <Keybuk> we only care about breaking those things we previously cared about
[11:00] <Keybuk> (ie supported)
[11:00] <Keybuk> we have never supported ipv6
[11:00] <fabbione> Keybuk: FYI: ipv6 is in main and therefor supported
[11:00] <Keybuk> (if we did, we would have high-level tools to configure it and use it!)
[11:00] <siretart> sladen: so this bug should be reassigned to the kernel, then?
[11:00] <fabbione> Mithrandir: right.. it's still a regression
[11:00] <Keybuk> fabbione: that means it's security supported
[11:01] <cjwatson> "regression" is something to pay attention to but it is not a big stick that trumps everything else. The release manager still has discretion
[11:01] <Keybuk> not that we care about it
[11:01] <sladen> siretart: yes, bit if you do that, can you mark it low-priority, it's not a regression in any way
[11:01] <fabbione> Keybuk: also.. if we were introducing that many regressions we wouldn't be here at the Nth release
[11:01] <Keybuk> see the number of bugs with launcher icon paths changing
[11:01] <sladen> *blink*
[11:02] <Mithrandir> fabbione: I feel like I'm repeating myself.  Yes, it's a regression.  No, it's not something which will be fixed for the release.  If you want to fix it, please send patches for it.
[11:02] <Mithrandir> and with that, I'm off to bed.
[11:03] <fabbione> Mithrandir: sure.. good night..
[11:03] <sladen> WONTFIX
[11:03] <maswan> fabbione: if you want to fix it, please look at my recent bugs on the trouble I've had in actually getting a statically configured ipv6 working. :)
[11:03] <cjwatson> wontfix is wrong
[11:03] <cjwatson> wontfix != not-for-this-release
[11:03] <Keybuk> fabbione: seriously, I'm sure NM upstream would welcome IPv6 patches
[11:04] <sladen> (I'm with Mithrandir on this one)
[11:04] <fabbione> maswan: i removed NM.. problem solved..
[11:04] <maswan> fabbione: I had a really hard time getting it to not autoconf on bootup
[11:04] <Lure> Mithrandir: it would make sense to make network-manager-gnome only Recommends (already done for kubuntu-desktop and knetworkmanager)
[11:05] <Lure> Mithrandir: this will allow removal
[11:05] <Mithrandir> Lure: yes, it would.  Feel free to fix.
[11:05] <Lure> Mithrandir: do not know how (Riddell does this for me in Kubuntu) ;-)
[11:06] <fabbione> maswan: i am talking about NM messing up my ipv6 setup... what are you talking about?
[11:06] <cjwatson> mm, I wasn wondering that earlier too
[11:06] <cjwatson> was
[11:06] <heno> tkamppeter: I posted a request for printer testing in the forums: http://www.ubuntuforums.org/showthread.php?t=396588
[11:06] <heno> quite a few feisty users there
[11:06] <maswan> fabbione: Oh, sorry, perhaps you don't read comments on your old bugs.
[11:06] <cjwatson> any core dev can do that by changing "network-manager-gnome" to "(network-manager-gnome)" in the ubuntu.feisty seeds
[11:06] <fabbione> maswan: give me a reference please :)
[11:06] <Keybuk> tkamppeter: random Q; HPLIP doesn't do anything for my HP printer, is that deliberate?
[11:06] <fabbione> maswan: i can't possibly remember everything
[11:07] <Keybuk> it's a HP LaserJet 1018
[11:07] <maswan> fabbione: I will, digging it up.
[11:09] <maswan> (... if only I can manage to navigate)
[11:10] <maswan> fabbione: https://launchpad.net/ubuntu/+bug/7091 is mostly what I was talking about
[11:10] <ubotu> Malone bug 7091 in Ubuntu "IPv6 module is not loaded early enough" [Low,Needs info]
[11:11] <sladen> cjwatson: s/ \* network-manager-gnome/ * (network-manager-gnome)/ ?
[11:11] <fabbione> maswan: ehhe ok.. now i understand..
[11:12] <Keybuk> maswan: it's a bug that it's automatically loaded at all
[11:12] <Keybuk> it should be blacklisted by default until people want it
[11:12] <Keybuk> since it breaks nastily for people without ipv6
[11:13] <fabbione> Keybuk: no it breaks only for people with broken hardware
[11:13] <maswan> Keybuk: Oh? I've never had any problems with it though.
[11:13] <Keybuk> fabbione: which is most of the world
[11:13] <cjwatson> fabbione: considerably more people than those who actually use IPv6
[11:13] <Keybuk> cheap DSL routers that most people use can't do IPv6
[11:13] <Keybuk> and since there are only 2 goats that have a direct IPv6 connection, we care more about the real world
[11:14] <fabbione> Keybuk: cheap DL routers that don't follow RFC
[11:14] <fabbione> s/DL/DSL
[11:14] <fabbione> not even for ipv4
[11:14] <fabbione> that's why ipv6 break
[11:14] <Keybuk> who cares?
[11:14] <maswan> Keybuk: the ammounts of hits I get for updates via ipv6 says slightly more than 2 goats
[11:15] <maswan> but yeah, it's less than 10%
[11:15] <fabbione> Keybuk: we do.. given some recent movements towards IPv6 from some big fat govs
[11:15] <maswan> less than 1% I mean
[11:15] <Keybuk> we seriously don't
[11:15] <Keybuk> if someone pays us to do ipv6, we'll care
[11:15] <cjwatson> it doesn't seem at all inconceivable that we could avoid ipv6 being loaded for people without IPv6 addresses while still loading it for those who do
[11:15] <Keybuk> if someone joins core-dev and patches everything for ipv6, and fixes all the bugs, we'll care
[11:16] <fabbione> Keybuk: do you realize that 99.9% of the stuff in main already support ipv6?
[11:16] <cjwatson> I don't think "ipv6 loaded for everyone" is necessary to satisfy fabbione's requests
[11:16] <fabbione> cjwatson: no i don't need everybody to load ipv6 at all
[11:16] <Keybuk> fabbione: apparently a major feature of feisty doesn't support ipv6
[11:16] <maswan> cjwatson: Yeah. Like if I have typed in an inet6 section into interfaces.
[11:16] <Keybuk> and our resident ipv6 expert on staff doesn't appear to have fixed it
[11:16] <fabbione> Keybuk: it's not a matter that supports.. but that it break
[11:17] <cjwatson> maswan: right
[11:17] <fabbione> Keybuk: if NM didn't care.. i wouldn't have minded at all.. that it breaks a working setup.. then yes i do care
[11:17] <tormod> (didn't see the whole discussion, but) can NM - ipv6 trouble be related to bug #92299 (not only ipv6)?
[11:17] <cjwatson> do you care enough to fix it? :-)
[11:17] <ubotu> Malone bug 92299 in network-manager "network-manager breaks static configuration" [Undecided,Confirmed]  https://launchpad.net/bugs/92299
[11:17] <Keybuk> fabbione: fix it then :)
[11:18] <Keybuk> care = fix
[11:18] <fabbione> cjwatson: i don't care about NM because on a fixed workstation doesn't make any sense to me..
[11:18] <Keybuk> fabbione: you care about NM because it's part of our default installation
[11:18] <Keybuk> unless, of course, you don't care about our default installation?
[11:18] <maswan> Anyway, I'll poke around at these bugs that I've reported after feisty, I think caring about them _right now_ is a misdirection of effort.
[11:18] <cjwatson> fabbione: <fabbione> [...]  yes i do care
 i don't care
[11:18] <fabbione> Keybuk: the reason why i am arguing is because i do care of our default installation
[11:18] <Keybuk> fabbione: so fix NM then
[11:18] <Keybuk> care = fix
[11:18] <Keybuk> not bitch
[11:20] <fabbione> cjwatson: i said that i care because it breaks.. i don't care about NM as an application itself.. slightly different thing
[11:20] <fabbione> cjwatson: because i don't find it of any use on something != laptop
[11:21] <Keybuk> so you're saying that IPv6 isn't useful on a laptop? :p
[11:21] <fabbione> Keybuk: not yet no.. i am being realistic
[11:21] <cjwatson> so should the bugs about it be assigned to you or not?
[11:21] <cjwatson> (I'm assuming there is a bug about n-m vs. ipv6 - haven't looked)
[11:22] <fabbione> cjwatson: i filed it...
[11:22] <ubotu> Malone bug 93636 in network-manager "[regression]  breaks static ipv6 setup" [High,Unconfirmed]  https://launchpad.net/bugs/93636
[11:22] <cjwatson> bug 93636
[11:23] <cjwatson> fabbione: I think it would be appropriate to assign that bug to you. Do you disage??
[11:23] <cjwatson> er, disagree?
[11:24] <maswan> Some other day I can provide relative numbers on the ipv6 usage on the users that hit se.archive for package updates. But now sleep. :)
[11:24] <fabbione> cjwatson: i don't know NM code base.. you are welcome to reassign.. just no idea how to fix it
[11:25] <cjwatson> I'm sure somebody can help with that
[11:25] <pitti> cjwatson: 'disage' is an interesting concept, though
[11:25] <cjwatson> AFAIK there are no other core devs with the breadth of IPv6 experience you have
[11:25] <fabbione> cjwatson: probably not, who can i bitch about NM code base then?
[11:26] <neuralis> fabbione: if this is present in upstream, i can almost certainly get it fixed
[11:26] <Keybuk> upstream would be a good bet
[11:26] <Keybuk> they're GNOME guys, so they hang out on IRC and e-mail, etc.
[11:26] <pitti> cjwatson: I emailed upstream a while ago, and he was quite responsive
[11:26] <Keybuk> and are pretty responsive
[11:26] <Burgwork> fabbione: one of NMs upstream is currently on irc right now
[11:26] <pitti> erm, fabbione ^
[11:26] <pitti> cjwatson: sorry, wrong address; it's getting late...
[11:26] <fabbione> Keybuk: i am asking in our team.. not upstream :)
[11:26] <Keybuk> fabbione: you don't need help from somebody in our team
[11:26] <Keybuk> upstream will provide the help you need
[11:27] <fabbione> neuralis: i am pretty sure it's upstream too
[11:27] <Lure> Keybuk: not really if it is in debian backend (filtering out static interfaces)
[11:28] <Keybuk> Lure: they'd help him fix the backend
[11:28] <Keybuk> but I suspect the bug is more that it's tearing down configured IPv6 interfaces
[11:28] <Keybuk> which will be more internal than that
[11:33] <fabbione> it's actually only the backend
[11:33] <fabbione> it seems also pretty simple to fix
[11:33] <fabbione> given the way backends work
[11:38] <fabbione> cjwatson: bug #98764 looks to me like we are missing modules in the installer (ide*) ?
[11:38] <ubotu> Malone bug 98764 in Ubuntu "Installation of Feisty beta cannot detect disk drive on Gigabyte 965G-DS3" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98764
[11:40] <fabbione> actually it might be another one of those jmcron thingy
[11:40] <cjwatson> fabbione: we're certainly not missing them or I'd have way more people screaming at me, but it probably can't detect his hardware
[11:40] <cjwatson> fabbione: I'll look at it tomorrow
[11:40] <fabbione> cjwatson: ok thanks
[11:40] <fabbione> BenC: ^^^ this might be your...
[11:41] <BenC> fabbione: 70% possibility that bug is fixed by -13 kernel in repo, 99.9% possibility that it's fixed by current git
[11:42] <fabbione> BenC: ok.. i will ask cr3 to test a daily
[11:42] <BenC> fabbione: No chance of us missing modules for storage, since we just copy drivers/ata/ drivers/scsi/ and drivers/ide/ now
[11:43] <fabbione> BenC: yes.. there is a message from d-i that's misleading.. the modprobe happens a bunch of lines above that
[11:43] <fabbione> cjwatson: nevermind. that's definetely not for you
[11:44] <pitti> cjwatson: FYI, I implemented that heuristic coredump capping, testsuited and uploaded now
[11:45] <cjwatson> fabbione: ok, thanks
[11:45] <cjwatson> pitti: neat, thanks
[11:52] <tkamppeter> Keybuk: There are some HP printers which are not supported by HPLIP, especially the HP LaserJet 1000, 1005, 1018, 1020, Color LaserJet 1500, 2600n
[11:53] <tkamppeter> Keybuk, more are listed on http://hplip.sf.net/
[12:06] <firephoto> tepsipakki: I commented on bug 90213 and attached my xorg.log about those new intel drivers.
[12:06] <ubotu> Malone bug 90213 in xserver-xorg-video-i810-modesetting "xf86-video-intel 1.9.91 (2.0 RC1) is out, and would be nice to have as the source for the xserver-xorg-video-i810-modesetting package" [Undecided,Needs info]  https://launchpad.net/bugs/90213
[12:09] <tepsipakki> firephoto: oh, it was still using i2c debugging..
[12:09] <tepsipakki> I'll build a new one
[12:10] <firephoto> tepsipakki: ok. that explains all those messages then.
[12:10] <tepsipakki> yes, I needed those


[00:27] <dinda> what is the best mailing address for this project?  the LP one?
[01:30] <bodhizazen> yes dinda
[01:31] <bodhizazen> dinda: do we have an official response re licensing ?
[01:31] <bodhizazen> thank you doctormo
[01:31] <pleia2> no, the lists.ubuntu.com one is the official one
[01:31] <bodhizazen> I appreciate that
[01:31] <pleia2> the LP one needs to be shut down
[01:31] <bodhizazen> it is ???
[01:31] <bodhizazen> lol
[01:31] <pleia2> yes
[01:32] <pleia2> we were only using the LP one until we got the lists.ubuntu.com one sorted (it is now)
[01:32] <bodhizazen> doctormo: I have been checking licensing issues with other sources (no offense to anyone on this channel)
[01:53] <dinda> bodhizazen: was trying to find the official project mailing list so I can send the referral info for legal advice from the SFLC
[02:12] <bodhizazen> thank you dinda
[02:13] <dinda> pleia2: so which is the project mailing list?
[02:15] <pleia2> the one linked on the wiki page, sec
[02:15] <pleia2> https://lists.ubuntu.com/mailman/listinfo/ubuntu-learning
[02:16] <dinda> ack - I gotta figure out which folder these are being filtered to on Tbird as I've not seen these posts
[02:17] <pleia2> oh, and it shouldnt make the From: address be UCLP anymore ;) I fisehd that
[02:17] <pleia2> fixed too
[02:18] <pleia2> ok, heading off for the evening
[02:53] <dinda> just got directed to this site from the Sugar group:  http://www.linux-for-education.org/
[02:53] <dinda> yet another Moodle Open source learning site
[03:00] <doctormo> dinda: Thanks! it's CC-BY-SA too :-D good for remixing and stuff. I'll add it to the wiki page
[15:41] <cprofitt> hello doctormo dthacker pleia2 greg-g popey
[15:42] <popey> hi
[15:42] <doctormo> Hello cprofitt, popey
[15:42] <pleia2> morning
[15:51] <cprofitt> popey
[15:52] <cprofitt> do you have time to talk about a LoCo related item
[15:52] <popey> go for i
[15:52] <popey> *it
[15:52] <cprofitt> The NY team will be applying again in July...
[15:52] <cprofitt> this the format I am going to use - https://wiki.ubuntu.com/NewYorkTeam/ApprovalApplicationDraft
[15:53] <cprofitt> for the application -- does that look good (information needs to be added)
[15:53] <popey> sure
[15:54] <popey> the information is more important than the format :)
[15:54] <doctormo> cprofitt: I thought the NY team was approved already
[15:54] <cprofitt> and the second to that is how to consolidate the following -- https://wiki.ubuntu.com/NewYorkTeam/Events
[15:54] <cprofitt> doctormo, no we were turned down in March
[15:54] <cprofitt> and turned down the year before
[15:54] <popey> i like that events page
[15:54] <cprofitt> should I just link to the event and meeting lists popey ?
[15:54] <doctormo> cprofitt: hmm, not enough events or some red tape glitch?
[15:55] <cprofitt> I had those events on our last app in March and it seemed to confuse the council
[15:55] <cprofitt> doctormo, back in March we were told we did not have enough sustained activity
[15:55] <cprofitt> https://wiki.ubuntu.com/NewYorkTeam/Events/Past
[15:56] <cprofitt> the nature of the LoCos events has changed since I got more involved in scheduling them as well...
[15:57] <cprofitt> popey, we have a sep. page for meetings - https://wiki.ubuntu.com/NewYorkTeam/Meetings/Past
[15:57] <cprofitt> so I am thinking of listing a summary of event totals over the last 12 months, meetings over the last twelve months... with a highlight on a few key events...
[15:57] <popey> nice and comprehensive
[15:57] <cprofitt> then linking to the full archive pages
[15:57] <popey> yeah
[15:58] <cprofitt> popey, should I repackage the What We Do and Goals section (bottom of page) from here as well -- https://wiki.ubuntu.com/NewYorkTeam/ ?
[15:59] <popey> if a few of the "what we do" lines linked to supporting logs/photos/blogs/etc that might be useful
[16:00] <doctormo> cprofitt: If ever your up in Massachusetts, come and see what we do at community centers, every week we teach Ubuntu Desktop.
[16:00] <cprofitt> ok... sounds good.
[16:00] <cprofitt> doctormo, we are looking to try and get the ability to teach - but so far we do not have any 'centers' that have computers that have interest
[16:01] <cprofitt> the two I know of are 'blue' with Microsoft and have no interest from changing, but I do communicate with them
[16:01] <cprofitt> I am currently searching out (have found two) teachers who use Linux at the K-12 level
[16:01] <cprofitt> and looking to support them... and help them 'sway' others
[16:02] <cprofitt> popey, do you feel we have enough activity? the right mix of activities?
[16:02] <popey> looks good to me :)
[16:02] <doctormo> cprofitt: We've found it's good to teach techies to teach first and then people will get confortable, to be honest the SETC has acted like a weekly beacon and people come even to not teach but just to hang and talk and think about Ubuntu.
[16:03] <cprofitt> popey, thanks... I really want to nail this one down... to avoid any negative feelings like we had the last time...
[16:03] <doctormo> core members mostly do the teaching.
[16:03] <popey> sure
[16:03] <cprofitt> so I want to work with you guys to make sure I present the information in the best possible manner
[16:56] <greg-g> morning all
[17:33] <cprofitt> hey greg-g
[20:45] <tidd> I feel like I have a really stupid question. ioctl, what package installs it? I cannot seem to find it, running jaunty
[23:09] <bodhi_zazen> playpen us up ;)
[23:09] <bodhi_zazen> *is
[23:14] <doctormo> bodhi_zazen: thanks
[23:16] <bodhi_zazen> it will be at learn.bodhizazen.net
[23:17] <bodhi_zazen> I need to configure my router , can not access from work
[23:43] <bodhi_zazen> I was wrong, it is up now
[23:43] <bodhi_zazen> http://learn.bodhizazen.net/moodle/


[20:32] <ibeardslee> morning
[20:35] <snail> morning
[20:44] <ojwb> morning
[20:51] <ajmitch> morning
[21:23] <ajmitch> how annoying, it's bright & sunny this morning :)
[21:26] <olly> ajmitch: come visit wellington...
[21:27] <ajmitch> nah, I think I'll just put up with the monitor glare for now
[21:37] <ibeardslee> olly: there is blue sky here
[21:38] <ibeardslee> or maybe that's just a funny shade of grey
[22:36] <ojwb> hmm, if network manager brings the network up when the router isn't connected to the internet, it doesn't add any name servers to /etc/resolv.conf
[22:36] <ojwb> and when the internet comes up, it doesn't fix that
[22:36] <ojwb> so you have to bounce the network (or go and fix it by hand)
[22:37] <ojwb> is that really the intended behaviour?
[22:39]  * ajmitch thought it was dhclient that was adding the resolv.conf entries
[22:39] <ojwb> $ head -n1 /etc/resolv.conf
[22:39] <ojwb> # Generated by NetworkManager
[22:39] <ajmitch> is the problem that it's getting an address via dhcp which has no name servers in the dhcp offer?
[22:40] <ojwb> presumably
[22:40] <ojwb> if the internet is up, I get two name servers at the ISP in there
[22:40] <ajmitch> I don't know if there'd be a sane way around that rather than it renewing the DHCP lease more often
[22:40] <ojwb> at least if there are no nameservers...
[22:41] <ojwb> without a nameserver, your internet experience is going to be somewhat reduced
[22:41] <ajmitch> marginally so, yes
[22:42]  * ojwb spots a neat hack
[22:42] <ojwb> set resolv.conf to point to a dummy local nameserver
[22:42] <ojwb> if that gets a request, then check for connectivity, and if it's there, force a dhcp lease expiry
[22:43] <ajmitch> & avoid resolv.conf from being clobbered
[22:43] <ojwb> alternatively, just stick <IP_ADDRESS> and <IP_ADDRESS> in there if you've nothing else
[22:43] <ojwb> though there are privacy implications there which some might not like
[22:44] <ojwb> (those are google's public dns servers)
[22:44] <ajmitch> & they can have bad effects on CDNs that do geo-location based on DNS lookups
[22:46] <ojwb> that's really a flaw in such CDNs I'd say
[22:46] <ojwb> though it's the user who'll feel it directly
[22:46] <ojwb> handy way around geo-restrictions though!
[22:47] <ajmitch> though the ones that do restrictions tend to look up the requesting IP address rather than relying on DNS :)
[22:47] <ojwb> indeed
[22:47] <ajmitch> ssh tunnel to a linode vps running squid tends to help me there
[23:42] <Atamira> mornin
[23:43] <Atamira> we have beautiful blue sky and sun !


[03:21] <hathor008> so wtf is this supposed to mean? 'NoneType' object has no attribute 'lstrip'
[03:42] <sethj> hi hathor008. I see you are having no more luck than I am lol
[03:43] <hathor008> https://gist.github.com/anonymous/0cb3931924b497dad9c73d597716bd74
[03:43] <hathor008> yeah i mean this process is really confusing
[03:47] <hathor008> http://askubuntu.com/questions/779315/how-do-i-create-a-snap-for-a-monogame-application
[04:07] <sethj> I'll take a look at your case tomorrow if I can find some time.
[04:07] <hathor008> thanks
[06:51] <tptr> hi, I'd like to ask a question about publishing. If I build a snap package but I cannot make it public is there a way, like a private repo, to publish it only in my team or for my IoT devices?
[08:48] <zyga> o/
[08:50] <hathor008> hi
[09:15] <pedronis> tptr: yes, there's a concept of private snaps (that can be shared with a selected group)
[09:20] <tptr> pedronis: ok thanks, I will keep digging then.
[10:39] <AndroUser> Whoami
[10:40] <AndroUser> http://askubuntu.com/questions/779267/snapcraft-snap-failing-because-python-modules-are-missing?noredirect=1#comment1165744_779267
[10:40] <AndroUser> Hey people, could someone take a look here?
[10:41] <ogra_> heh ... fun that people always start packaging with the hardest tasks :)
[10:41] <AndroUser> Yeah, I thought that too
[10:42] <ogra_> looks like you want some additional python packages there
[10:42] <AndroUser> But I just couldn't reproduce the error that OP filled in to
[10:42] <ogra_> pythoon-apport comes to mind seeing the error
[10:43] <ogra_> or rather python3-apport ... (not sure if that one is still needed though, py3 should be the default)
[10:43] <AndroUser> I don't know too
[10:43] <ogra_> same goes for python-dbus ...
[10:44] <AndroUser> Why is that dependencies listed by setup.py are not getting installed and require being listed apart in the yaml file?
[10:45] <ogra_> thats a question for sergiusens :)
[10:45] <AndroUser> I am not Seth, just was very curious. If you happen to try anything, please answer in this thread ok?
[10:46] <ogra_> what i see is that the OP is using python3-* packages everywhere ... could well be that in 16.04 these are just empty transitional packages ...
[10:46] <AndroUser> I tried a lot of different stuff last night with Seth and we couldn't trace back the cause of errors
[10:46] <ogra_> and python-apport is clearly missing
[10:46] <AndroUser> Uhm, that's a great idea, I didn't checked to see what python3 packages were indeed installing
[10:47] <ogra_> even if you get it packaged though ... you will need a lot of interface work still ... we dont have a way yet to attach to the system fonts ot themes from a snap ... you will only be able to run it in devmode for now
[10:48] <AndroUser> I went to the ubuntuforums.org and couldn't find a topic for discussion on Snaps, where can I suggest a dedicated forum there?
[10:48] <AndroUser> I see, so it wouldn't be able to change themes and unity options like usual?
[10:56] <ogra_> well, you can suggest the snapcraft mailing list (at https://lists.ubuntu.com/mailman/listinfo/snapcraft )
[10:56] <ogra_> and this IRC channel here
[10:57] <ogra_> i dont think any developer actually monitors forums much
[11:11] <AndroUser> Thanks. I will enter the mailing list :)
[13:05] <sergiusens> ogra_ I don't see AndroUser on anymore nor did I see a mailinglist question so if he comes by, tell him that install_requires in setup.py is automatically taken care of.
[13:06] <ogra_> sergiusens, well, the askubuntu thing seems to not find some deps (python-dbus, python-apport namely)
[13:06] <ogra_> http://askubuntu.com/questions/779267/snapcraft-snap-failing-because-python-modules-are-missing?noredirect=1#comment1165744_779267
[13:12] <sergiusens> ogra_ I bet python-apport is not on pypi or has a different name there
[13:13] <ogra_> yeah
[13:13] <sergiusens> it has already sort of been answered
[16:59] <sborovkov> Hi. I have a python code running on snappy. It basically just accesses SNAP_USER_DATA. And some networking stuff. But I get a lot of apparmor warnings - any ideas what could be wrong? https://paste.kde.org/pawrdt7xc
[17:23] <sergiusens> sborovkov seems you installed with devmode
[17:23] <sergiusens> Not much of a problem if so. It all says ALLOWED
[17:25] <sborovkov> sergiusens: yeah, I did. Thought that what's allowed in devmode would be forbidden without it :-)
[17:26] <sborovkov> is that not the case?
[17:51] <sabdfl> sborovkov, if you don't specify --devmode then the snap runs confined
[17:51] <sabdfl> once your confinement description is correct, then you can drop the --devmode
[17:51] <sabdfl> which is a good thing :)
[17:53] <sabdfl> the point of --devmode is that it is sometimes hard to get the confinement description complete up front
[17:53] <sabdfl> so --devmode lets you put things into "log only" mode (well, mostly, some things still shoot you in --devmode :))
[17:54] <sabdfl> sergiusens, around?
[17:59] <sergiusens> sabdfl yes I am
[18:00] <sergiusens> sborovkov let me open your paste again
[18:00] <sergiusens> sborovkov was mislead by the mention of "warnings"
[18:01] <sergiusens> sborovkov is ldconfig run by the snap by any chance?
[18:04] <sabdfl> sergiusens, would this work:
[18:04] <sabdfl> ah
[18:56] <sborovkov> sergiusens: sabdfl: I understand that devmode allows everything. But I thought any apparmor "allowed" message mean that it would not work without devmode.
[18:58] <sborovkov> sergiusens: >is ldconfig run by the snap by any chance - that's relatively simple python program. So I don't understand where ldconfig is coming from at the moment. Thought that may be python is running it...
[19:01] <sergiusens> sborovkov line 3 indicates this, not sure what your simple program is (or maybe a wrapper script you have going around)
[19:05] <tyhicks> sborovkov, sergiusens: ldconfig is being ran and that is the cause of nearly all the AppArmor denials
[19:06] <sergiusens> tyhicks it seems so from line 3. Trying to find out where :-)
[19:06] <sergiusens> the /proc/.../mounts one isn't much of a problem
[19:06] <tyhicks> sergiusens: the mount-observe interface allows reading /proc/PID/mounts
[19:07] <sergiusens> tyhicks but do we need it? I was thinking of it as a harmless error
[19:07] <sergiusens> for the python runtime case
[19:08] <sborovkov> sergiusens: tyhicks: I have custom ld.so file. exec "$VIEWER_APP_PATH/lib/ld-linux-armhf.so.3" --inhibit-cache $@ This is how another part of snap is run... But this messages come from python part which is run as usual
[19:08] <sborovkov> if this is relevant...
[19:08] <tyhicks> sergiusens: I'm not sure if python will croak if it can't read /proc/PID/mounts - I'd be surprised if it was treated as a fatal error but I'm just not 100% sure
[19:10] <sborovkov> sergiusens: tyhicks: also do you know if snap installed in --devmode can drop devmode somehow without manual interaction on snap upgrade let's say?
[19:10] <sergiusens> tyhicks it has been fine so far
[19:14] <tyhicks> sborovkov: I don't believe we have defined a way for a snap to automatically promote itself from devmode to non-devmode on an upgrade
[19:16] <sborovkov> tyhicks: understood, thanks. Would using custom ld.so cause any apparmor issues? I have my application built in buildroot and for some reason it does not work without it.
[19:16] <sergiusens> tyhicks we discussed this with nessita and niemeyer. IIRC going from "production" to devmode would trigger an alert. The other way around wasn't covered but it should be sort of fine, right?
[19:18] <tyhicks> sergiusens: It should be fine as long as the user is using the snap as it was intended to be used by the snap packager
[19:19] <tyhicks> sergiusens: it would have the potential to break the user if, for example, he/she is specifying file paths that don't jive with confinement
[19:19] <tyhicks> that's not really something that we can protect against
[19:19] <sergiusens> tyhicks right, the "product" would need to be solid to move from devmode to production mode for starters
[19:20] <nessita> sergiusens, correct, the transition from strict to devmode is not automatic but devmode to strict is
[19:21] <tyhicks> oh, cool
[19:22] <tyhicks> sborovkov: regarding a custom ld.so> I think you should be able to get away with doing that within confinement since you're using --inhibit-cache
[19:22] <sborovkov> wait, so how does automatic transition from from devmode to strict can be triggered?
[19:23] <sborovkov> tyhicks: ok, thanks.
[19:28] <sborovkov> nessita: do you know how that automatic transition could be triggered?
[19:29] <nessita> sborovkov, when running snap refresh, if the store reports a newer revision, the snap will upgrade
[19:29] <nessita> and the newer revision can be strict (even if the reported revision is devmode)
[19:30] <sborovkov> nessita: thanks.
[19:31] <nessita> sborovkov, you are welcome! I hope my answer made sense
[19:33] <sborovkov> nessita: yes. I was just wondering because the application we are developing has some blockers on snappy side (/dev/vchiq inaccessible is the main thing). So was thinking if it would be possible to make images with snap installed in --devmode for alpha version and then later upgrade to proper mode without having people reflash the SD cards
[19:34] <nessita> sborovkov, right, in that scenario you would push a new revision of your snap without devmode, and you need to make sure you publish that snap in the alpha channel
[19:34] <nessita> sborovkov, then all your clients will get that revision on manuel or automatic "snap refresh"
[19:37] <sborovkov> nessita: so it's a flag in the store then? whether it's devmode or not?
[19:41] <nessita> sborovkov, nopes, is a flag inside each snap binary, so basically when you want to leave devmode and migrate to strict confinementn you need to do a new build and push to the store
[19:41] <nessita> sborovkov, and release that new build in the same channel as the one that had the devmode revision published
[19:41] <nessita> does that make sense?
[19:42] <sborovkov> Yeah, I just did not know about the flag (or how to set it when building the snap) . Since I though that it's enabled when installing using `--devmode`.
[19:45] <nessita> sborovkov, ah, right. So latest snapcraft allows you to define a confinement: devmode in your snapcraft.yaml that will make the confinement checks be treated as INFO instead of erroing
[19:46] <sborovkov> nessita: thanks again. Now everything's clear :-)
[19:47] <nessita> great!
[19:54] <sborovkov> Are config interfaces still gone?
[20:23] <qengho> This might be a 2.0.3->2.0.5 xenial-proposed regression. Not sure. https://bugs.launchpad.net/snappy/+bug/1587175


[07:32] <lordievader> Good morning.
[15:34] <ubuntu023> Hi every one
[15:34] <ubuntu023> I would like to ask about web chat for ubuntu
[15:34] <ubuntu023> any suggestion what should i use?
[15:35] <ubuntu023> i have ubuntu server with nginx and php5-fpm and mysql
[15:39] <rypervenche> ubuntu023: You could set up something like Kiki IRC and have it connect to an IRC channel.
[15:40] <rypervenche> ubuntu023: Kiwi IRC*
[15:40] <ubuntu023> i see, how about private chat server one?
[15:40] <Amm0n> ubuntu023, https://www.ejabberd.im/jwchat-localserver
[15:42] <ubuntu023> i think that one can do it
[15:45] <ubuntu023> btw does this ejabberd open source?
[15:47] <Amm0n> yep
[15:47] <Amm0n> it's under gpl
[15:51] <ubuntu023> i just saw that there are jwchat on ubuntu repository
[15:51] <ubuntu023> http://packages.ubuntu.com/hu/lucid/web/jwchat
[15:51] <ubuntu023> is this same one
[15:59] <ObrienDave> lucid is fairly old
[16:02] <ubuntu023> i have try web chat call shoutbox
[16:03] <ubuntu023> it use socket.io but i am stuck with the installation of shoutbox so i am looking to alternative one
[16:03] <ubuntu023> shoutbox have less documentation


[12:13] <cmaloney> morning
[12:38] <_stink__> yo
[12:38] <_stink__> boy am i glad it's 90 degrees still
[12:38] <_stink__> not
[12:58] <cmaloney> Yeah, no joke
[12:58] <cmaloney> I want to go back out to the patio and play with computers
[12:58] <cmaloney> not in this heat
[15:49] <cmaloney> morning-ish
[19:33] <rick_h> yea :/ but looked at a house on a lake today and went hmmmm
[19:56] <cmaloney> heh


[01:04] <KGB-X> librsvg signed tags 03dbab1 Jeremy Bicha upstream/2.58.0+dfsg * Upstream version 2.58.0+dfsg * https://salsa.debian.org/gnome-team/librsvg/tags/upstream/2.58.0+dfsg
[01:05] <KGB-X> librsvg upstream/latest 201bf08 Jeremy Bicha * pushed 8 commits (first 5 follow) * https://salsa.debian.org/gnome-team/librsvg/compare/54a2cd4...201bf08
[01:05] <KGB-X> librsvg upstream/latest e9ff726 Federico Mena Quintero rsvg/ src/filters/turbulence.rs tests/render_crash.rs tests/fixtures/render-crash/bug1062-feTurbulence-limit-numOctaves.svg * (#1062): Limit numOctaves in feTurbulence to avoid unbounded CPU consumption * https://salsa.debian.org/gnome-team/librsvg/-/commit/e9ff726
[01:05] -ubottu:#ubuntu-desktop- Commit e9ff726 in gnome-team/librsvg "(#1062): Limit numOctaves in feTurbulence to avoid unbounded CPU consumption"
[01:05] <KGB-X> librsvg upstream/latest 33e76df Federico Mena Quintero rsvg/ src/filters/turbulence.rs tests/render_crash.rs tests/fixtures/render-crash/bug1062-feTurbulence-limit-numOctaves.svg * Merge branch 'limit-numoctaves-2.58' into 'librsvg-2.58' * https://salsa.debian.org/gnome-team/librsvg/-/commit/33e76df
[01:05] -ubottu:#ubuntu-desktop- Commit 33e76df in gnome-team/librsvg "Merge branch 'limit-numoctaves-2.58' into 'librsvg-2.58'"
[01:05] <KGB-X> librsvg upstream/latest 1060724 Federico Mena Quintero devel-docs/security.rst * devel-docs/security.rst: We don't use gdk-pixbuf anymore, just image-rs * https://salsa.debian.org/gnome-team/librsvg/-/commit/1060724
[01:05] -ubottu:#ubuntu-desktop- Commit 1060724 in gnome-team/librsvg "devel-docs/security.rst: We don't use gdk-pixbuf anymore, just image-rs"
[01:05] <KGB-X> librsvg upstream/latest ebf5f31 Lukáš Tyrychtr rsvg/ src/css.rs tests/loading_crash.rs tests/fixtures/crash/bug1064-private-lang-tag-in-lang-selector.svg * https://salsa.debian.org/gnome-team/librsvg/-/commit/ebf5f31
[01:05] -ubottu:#ubuntu-desktop- Commit ebf5f31 in gnome-team/librsvg "css: Don't crash when the lang selector wants to verify a match for"
[01:05] <KGB-X> css: Don't crash when the lang selector wants to verify a match for
[01:05] <KGB-X> something which is not a language range
[01:06] <KGB-X> librsvg upstream/latest 1983da9 Federico Mena Quintero NEWS * Update NEWS * https://salsa.debian.org/gnome-team/librsvg/-/commit/1983da9
[01:06] -ubottu:#ubuntu-desktop- Commit 1983da9 in gnome-team/librsvg "Update NEWS"
[01:06] <KGB-X> librsvg pristine-tar c09e6a4 Jeremy Bícha librsvg_2.58.0+dfsg.orig.tar.xz.delta librsvg_2.58.0+dfsg.orig.tar.xz.id * pristine-tar data for librsvg_2.58.0+dfsg.orig.tar.xz * https://salsa.debian.org/gnome-team/librsvg/-/commit/c09e6a4
[01:06] -ubottu:#ubuntu-desktop- Commit c09e6a4 in gnome-team/librsvg "pristine-tar data for librsvg_2.58.0+dfsg.orig.tar.xz"
[18:47] <KGB-X> gnome-usage signed tags 6380fa8 Jeremy Bicha upstream/46.0 * Upstream version 46.0 * https://salsa.debian.org/gnome-team/gnome-usage/tags/upstream/46.0
[18:48] <KGB-X> gnome-usage upstream/latest a9e4697 Jeremy Bicha * pushed 100 commits (first 5 follow) * https://salsa.debian.org/gnome-team/gnome-usage/compare/76bf544...a9e4697
[18:48] <KGB-X> gnome-usage upstream/latest 94f2646 Balázs Úr po/hu.po * Update Hungarian translation * https://salsa.debian.org/gnome-team/gnome-usage/-/commit/94f2646
[18:48] -ubottu:#ubuntu-desktop- Commit 94f2646 in gnome-team/gnome-usage "Update Hungarian translation"
[18:48] <KGB-X> gnome-usage upstream/latest dab87ab Anders Jonsson po/sv.po * Update Swedish translation * https://salsa.debian.org/gnome-team/gnome-usage/-/commit/dab87ab
[18:48] -ubottu:#ubuntu-desktop- Commit dab87ab in gnome-team/gnome-usage "Update Swedish translation"
[18:48] <KGB-X> gnome-usage upstream/latest c872fbb Ekaterine Papava po/ka.po * Update Georgian translation * https://salsa.debian.org/gnome-team/gnome-usage/-/commit/c872fbb
[18:48] -ubottu:#ubuntu-desktop- Commit c872fbb in gnome-team/gnome-usage "Update Georgian translation"
[18:48] <KGB-X> gnome-usage upstream/latest 3700305 Daniel Mustieles po/es.po * Updated Spanish translation * https://salsa.debian.org/gnome-team/gnome-usage/-/commit/3700305
[18:48] -ubottu:#ubuntu-desktop- Commit 3700305 in gnome-team/gnome-usage "Updated Spanish translation"
[18:48] <KGB-X> gnome-usage upstream/latest 4d302cb Sergej A. po/ru.po * Update Russian translation * https://salsa.debian.org/gnome-team/gnome-usage/-/commit/4d302cb
[18:48] -ubottu:#ubuntu-desktop- Commit 4d302cb in gnome-team/gnome-usage "Update Russian translation"
[18:49] <KGB-X> gnome-usage pristine-tar 7941afe Jeremy Bícha gnome-usage_46.0.orig.tar.xz.delta gnome-usage_46.0.orig.tar.xz.id * pristine-tar data for gnome-usage_46.0.orig.tar.xz * https://salsa.debian.org/gnome-team/gnome-usage/-/commit/7941afe
[18:49] -ubottu:#ubuntu-desktop- Commit 7941afe in gnome-team/gnome-usage "pristine-tar data for gnome-usage_46.0.orig.tar.xz"
[18:52] <KGB-X> gnome-software Sid 478252 * commented commit 76510ec * https://salsa.debian.org/gnome-team/gnome-software/-/commit/76510ec#note_478252
[18:52] -ubottu:#ubuntu-desktop- Commit 76510ec in gnome-team/gnome-software "Split deb support into separate gnome-software-plugin-deb package"
[18:52] <KGB-X> gnome-software Sid 478253 * commented commit 76510ec * https://salsa.debian.org/gnome-team/gnome-software/-/commit/76510ec#note_478253
[19:10] <KGB-X> gucharmap signed tags 8e6d6c4 Jeremy Bicha upstream/15.1.3 * Upstream version 15.1.3 * https://salsa.debian.org/gnome-team/gucharmap/tags/upstream/15.1.3
[19:11] <KGB-X> gucharmap upstream/latest 32ce408 Jeremy Bicha * pushed 7 commits (first 5 follow) * https://salsa.debian.org/gnome-team/gucharmap/compare/ac86815...32ce408
[19:11] <KGB-X> gucharmap upstream/latest b1cc202 Christian Persch meson.build * build: Post release version bump * https://salsa.debian.org/gnome-team/gucharmap/-/commit/b1cc202
[19:11] <KGB-X> gucharmap upstream/latest 504e124 Florentina Mușat po/ro.po * Update Romanian translation * https://salsa.debian.org/gnome-team/gucharmap/-/commit/504e124
[19:11] <KGB-X> gucharmap upstream/latest 2002035 DaeHyun Sung po/ko.po * Update Korean translation * https://salsa.debian.org/gnome-team/gucharmap/-/commit/2002035
[19:11] -ubottu:#ubuntu-desktop- Commit b1cc202 in gnome-team/gucharmap "build: Post release version bump"
[19:11] -ubottu:#ubuntu-desktop- Commit 504e124 in gnome-team/gucharmap "Update Romanian translation"
[19:11] <KGB-X> gucharmap upstream/latest de79234 Rafael Fontenelle po/pt_BR.po * Update Brazilian Portuguese translation * https://salsa.debian.org/gnome-team/gucharmap/-/commit/de79234
[19:12] -ubottu:#ubuntu-desktop- Commit 2002035 in gnome-team/gucharmap "Update Korean translation"
[19:12] <KGB-X> gucharmap upstream/latest 4053af4 Rafael Fontenelle help/pt_BR/figures/gucharmap_window.png * Update application Brazilian Portuguese screenshot to version 15 * https://salsa.debian.org/gnome-team/gucharmap/-/commit/4053af4
[19:12] -ubottu:#ubuntu-desktop- Commit de79234 in gnome-team/gucharmap "Update Brazilian Portuguese translation"
[19:12] -ubottu:#ubuntu-desktop- Commit 4053af4 in gnome-team/gucharmap "Update application Brazilian Portuguese screenshot to version 15"
[19:12] <KGB-X> gucharmap pristine-tar 2eab02a Jeremy Bícha gucharmap_15.1.3.orig.tar.bz2.delta gucharmap_15.1.3.orig.tar.bz2.id * pristine-tar data for gucharmap_15.1.3.orig.tar.bz2 * https://salsa.debian.org/gnome-team/gucharmap/-/commit/2eab02a
[19:12] -ubottu:#ubuntu-desktop- Commit 2eab02a in gnome-team/gucharmap "pristine-tar data for gucharmap_15.1.3.orig.tar.bz2"
[20:21] <KGB-X> gtranslator signed tags f24d43d Jeremy Bicha upstream/46.0 * Upstream version 46.0 * https://salsa.debian.org/gnome-team/gtranslator/tags/upstream/46.0
[20:21] <KGB-X> gtranslator upstream/latest bd6046b Jeremy Bicha * pushed 220 commits (first 5 follow) * https://salsa.debian.org/gnome-team/gtranslator/compare/47043c9...bd6046b
[20:22] <KGB-X> gtranslator upstream/latest c8cb912 Ekaterine Papava po/ka.po * Update Georgian translation * https://salsa.debian.org/gnome-team/gtranslator/-/commit/c8cb912
[20:22] -ubottu:#ubuntu-desktop- Commit c8cb912 in gnome-team/gtranslator "Update Georgian translation"
[20:22] <KGB-X> gtranslator upstream/latest fb7070d Luming Zh po/zh_CN.po * Update Chinese (China) translation * https://salsa.debian.org/gnome-team/gtranslator/-/commit/fb7070d
[20:22] -ubottu:#ubuntu-desktop- Commit fb7070d in gnome-team/gtranslator "Update Chinese (China) translation"
[20:22] <KGB-X> gtranslator upstream/latest 5aec214 Sabri Ünal po/tr.po * Update Turkish translation * https://salsa.debian.org/gnome-team/gtranslator/-/commit/5aec214
[20:22] -ubottu:#ubuntu-desktop- Commit 5aec214 in gnome-team/gtranslator "Update Turkish translation"
[20:22] <KGB-X> gtranslator upstream/latest 2bd2556 Yaron Shahrabani po/he.po * Update Hebrew translation * https://salsa.debian.org/gnome-team/gtranslator/-/commit/2bd2556
[20:22] -ubottu:#ubuntu-desktop- Commit 2bd2556 in gnome-team/gtranslator "Update Hebrew translation"
[20:22] <KGB-X> gtranslator upstream/latest 98807de Jürgen Benvenuti po/de.po * Update German translation * https://salsa.debian.org/gnome-team/gtranslator/-/commit/98807de
[20:22] -ubottu:#ubuntu-desktop- Commit 98807de in gnome-team/gtranslator "Update German translation"
[20:22] <KGB-X> gtranslator pristine-tar 91c882a Jeremy Bícha gtranslator_46.0.orig.tar.xz.delta gtranslator_46.0.orig.tar.xz.id * pristine-tar data for gtranslator_46.0.orig.tar.xz * https://salsa.debian.org/gnome-team/gtranslator/-/commit/91c882a
[20:22] -ubottu:#ubuntu-desktop- Commit 91c882a in gnome-team/gtranslator "pristine-tar data for gtranslator_46.0.orig.tar.xz"