[00:11] <infinity> ScottK: Use deborphan, and tell it to keep ubuntu-standard, perhaps?
[04:53] <tjaalton> any sru-team members around?
[07:25] <dholbach> good morning
[11:09] <slomo> infinity: gstreamer1.0 should build fine now (just uploaded -2)
[11:36] <infinity> slomo: Thanks!
[12:10] <rbasak> How does one switch a package conffile from conffile to manually managed in maintainer scripts? Just doing it makes dpkg think that the file is obsolete after upgrade. dpkg-maintscript-helper seems relevant and mentions this case, but it doesn't seem to fit "removing a conffile" nor "moving a conffile" which seem to be the only two cases documented.
[12:15] <Sweetshark> seb128: for bug 1034558 and bug 1034560 we need to prepare an LO upload soon.
[12:18] <seb128> Sweetshark, don't you plan to upload 3.6 soon anyway? :-)
[12:22] <Sweetshark> seb128: yes, I have that one ready. Should I just give you one for uploading? the components mismatch will go crazy, but better now than two days before ff, right?
[12:25] <seb128> Sweetshark, how come we won those depends between rc3 and stable?
[12:56] <Sweetshark> seb128: bug 992232
[12:57] <seb128> Sweetshark, seems like we could do longer without it and should not block 3.6 on that?
[12:58] <Sweetshark> seb128: you mean no reportbuilder in quantal main?
[12:58] <seb128> Sweetshark, was it in precise main?
[13:00] <Sweetshark> seb128: no but they bitched me in doing an extra ppa rebuilding full LibreOffice only for this small extension
[13:00] <seb128> Sweetshark, well, it's not a regression then, I would recommend you keep it off until the MIRs are resolved
[13:01] <seb128> or check with the MIR team if they can review,approve that stack soon
[13:02] <Sweetshark> IIRC there was at least on of those packages needlessly using crappy maven ...
[13:03] <seb128> Sweetshark, so please keep that off
[13:05] <Sweetshark> seb128: k
[13:06] <Sweetshark> seb128: I dropped a note in the bug.
[13:07] <seb128> Sweetshark, thanks
[14:11] <stokachu> stgraber: i got that mp updated with changelog and posted rdeps testing to bug, if you get a chance today could you give it a lookover?
[14:13] <xnox> micahg: http://people.canonical.com/~ubuntu-archive/transitions/sqlite.html
[14:14] <xnox> micahg: 37 packages should drop build-deps? 245 are still to fix?
[14:19] <stgraber> stokachu: can you paste me that URL again?
[14:19] <stokachu> sure
[14:20] <stokachu> stgraber: https://code.launchpad.net/~adam-stokes/ubuntu/quantal/gnome-vfs/lp977940-multiarch/+merge/114258
[14:27] <rbasak> How does one switch a package conffile from conffile to manually managed in maintainer scripts? Just doing it makes dpkg think that the file is obsolete after upgrade. dpkg-maintscript-helper seems relevant and mentions this case, but it doesn't seem to fit "removing a conffile" nor "moving a conffile" which seem to be the only two cases documented.
[14:45] <Peace-> hi
[14:46] <Peace-> why in the world if i install ffmpeg i get ffmpeg from libav that is deprecated?
[14:46] <rbasak> ogra_: ping
[14:46] <Peace-> my software are all messed up
[14:46] <ogra_> rbasak, on the phone atm ...
[14:47] <rbasak> ogra_: ok, np
[14:47] <rbasak> ogra_: for when you're done... I think your recent flash-kernel changes might have caused a regression
[14:47] <infinity> Peace-: Since when is libav deprecated...?
[14:47] <Peace-> infinity:
[14:47] <Peace-> ffmpeg version 0.8.3-4:0.8.3-0ubuntu3, Copyright (c) 2000-2012 the Libav developers
[14:47] <Peace->   built on Jul 30 2012 22:10:17 with gcc 4.7.1
[14:47] <Peace-> *** THIS PROGRAM IS DEPRECATED ***
[14:47] <Peace-> This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.
[14:48] <infinity> Peace-: Yes...   And please keep the anger and profanity to a minimum.
[14:52] <Peace-> infinity: ffmpeg is developed
[14:52] <Peace-> so it's not a ffmpeg issue
[14:52] <Peace-> but a distro issue
[14:52] <Peace-> and there is no way to get the real ffmpeg on ubuntu right now
[14:52] <Peace-> you have to git clone and compile it
[14:53] <rbasak> Isn't that decision made by debian and not ubuntu?
[14:54] <Peace-> debian is ubuntu  ?
[14:54] <Peace-> at least someone should provide a ffmpeg version on ubuntu
[14:54] <rbasak> ubuntu is derived from debian.
[14:55] <Peace-> so it's not debian
[14:55] <Peace-> i use ubuntu , so i ask in the ubuntu channel
[14:55] <Peace-> really i use kubuntu but this is a shell program btw
[14:56] <rbasak> Your request to do something different in Ubuntu than Debian is valid, but I'm not sure it's worth maintaining such a big difference from Debian over this.
[14:56] <ScottK> Peace-: When I suggested you ask here, I was anticipating you'd do it more politely and productively.
[14:56] <rbasak> Since any difference needs to be supported and maintained.
[14:56] <Peace-> ScottK: i have lost hours to do my software
[14:57] <ScottK> And since the people who do the maintenance work on both distros are the same people, it'd be really odd for them to change.
[14:57] <Peace-> and now i find out that there is no way for users to get the ffmpeg
[14:57] <Peace-> and here they are saying to ask to debian ?
[14:57] <Peace-> bah
[14:57] <ScottK> Peace-: I understand frustration, but incivility is not productive.  It doesn't help solve your problem.
[14:57] <rbasak> You'd need to achieve consensus about this kind of change before it'll happen. The people with the biggest voices are the people who actually do the maintenance work.
[14:58] <ScottK> Peace-: I think what you ought to do is figure out how to support both libav and ffmpeg.  The reason I suggested talking to siretart is he might have a suggestion on how to go about that.
[14:58] <Peace-> ScottK: incivility is to say it's not an ubuntu issue
[14:59] <Peace-> or if i have a problem i should ask to debian devel
[14:59] <ScottK> It's not an area we're likely to diverge from Debian on.
[14:59] <rbasak> I did not say that it's not an Ubuntu issue. I said that the primary decision is made on Debian, and for Ubuntu to diverge is exceptional.
[14:59] <rbasak> (and unlikely)
[14:59] <Peace-> you have not to diverge , there is ffmpeg => install ffmpeg , you wann avconv install avconv
[15:00] <Peace-> but here if you install ffmpeg you get avconv 0_0
[15:00] <infinity> It's not that simple, with the switch to libav as a backend provider.
[15:01] <infinity> Though, I'm sure there are ways to make ffmpeg and libav coexist in peaceful harmony, no one's put that work in, that I know of.
[15:01] <Chipzz> Peace-: from the looks of it you get a malfunctioning ffmpeg, but you don't get avconv?
[15:01] <rbasak> I understand your frustration, but the primary place to fix it on Debian, since most changes on Debian propogate to Ubuntu (and I think this would), and we try to stay as close to what Debian do as possible.
[15:01] <siretart> Peace-: the 'ffmpeg' package in ubuntu exists only for transitional to help programs that are already in ubuntu. it will go away in the near future
[15:02] <Chipzz> siretart: was there a transitional period were ffmpeg simply emitted a warning instead of not working? or is that what it currently does?
[15:02] <Peace-> rbasak: i don't think i can get any support in debian btw
[15:03] <Peace-> Chipzz: it works but doesn't recognize some options
[15:03] <Peace-> it's a complete mess
[15:03] <siretart> Chipzz: no, it does not.
[15:03] <Chipzz> Peace-: I don't know how it was lately, but ffmpeg has never been known for their stable API. maybe this is a problem with upstream instead of with ubuntu?
[15:04] <siretart> Chipzz: it simply did not receive any updates. this was done to ensure that *existing*, packaged programs break
[15:04] <Chipzz> siretart: wait, am I reading this right? you want to ENSURE breakage?
[15:04] <vibhav> Are there any *easy* "C oriented" bugs that one can help in Ubuntu?
[15:04] <siretart> Chipzz: the ffmpeg program nowadays received a number of command line updates that requires changes to existing programs that we package. it's all about compatibility
[15:05] <siretart> sorry
[15:05] <Peace-> siretart:  Chipzz [mpeg2video @ 0x8558e60] Unable to parse option value "mv0"
[15:05] <siretart> Chipzz: it simply did not receive any updates. this was done to ensure that *existing*, packaged programs *do not* break
[15:05] <Peace-> and that string worked before
[15:05] <Chipzz> ah, ensuring breakage would be quite baffling
[15:05] <Peace-> anyway
[15:05] <siretart> Peace-: this is not the best place to discuss individual bugs.
[15:06] <Chipzz> Peace-: the ffmpeg maintainers were infamous for breaking stuff in the past. who's to say the problem isn't upstream?
[15:06] <Peace-> Chipzz: the main stuff has always worked
[15:07] <Chipzz> Peace-: from what I understand of this discussion, there's 2 issues: a) ffmpeg breaking some command line options and b) ffmpeg being deprecated and ubuntu *WARNING* about that
[15:07] <mpt> vibhav, <https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize> is a list of bugs that have been marked as easy. I don't know of any simple way of telling which packages are written in C and which aren't.
[15:07] <Peace-> no the issue it's that i want ffmpeg instead i get another stuff
[15:07] <Chipzz> Peace-: not 100% sure I'm getting this right, but I don't think the warning causes the breakage
[15:08] <Chipzz> Peace-: no you didn't. you got a version of ffmpeg where a couple of options have been broken
[15:08] <Peace-> you can joke as you want
[15:09] <vibhav> mpt: let me see
[15:09] <Chipzz> I'm not joking. you however are misstating the facts
[15:09] <Peace-> but the stuff it's this change in this section is a very mess
[15:09] <mpt> vibhav, but once you have bzr installed, "bzr branch lp:ubuntu/name-of-package" will get you a copy of the package to look for yourself.
[15:09] <vibhav> mpt: yeah, I know that :)
[15:09] <mpt> ok :-)
[15:09] <ogra_> rbasak, hrm, you dont use normal server images i guess ... good catch, the diversion should actually only show up when live installer is used ... seems it doesnt
[15:10] <rbasak> ogra_: thanks, shall I leave it with you?
[15:10] <rbasak> ogra_: you can reproduce on highbank in our lab
[15:11] <rbasak> ogra_: or me or mahmoh can test for you if you like
[15:11] <ogra_> rbasak, err, wait, flash-kernel-installer actually removes the diversion before running
[15:11] <cjwatson> ogra_: the diversion ought to work with or without live-installer - that was certainly my intention when I suggested this approach
[15:11] <ogra_> (and i see it doing that properly in your syslog
[15:11] <ogra_> )
[15:11] <rbasak> I can't figure out why update-initramfs does nothing, or whether the kernel postinst ends up not calling it
[15:11] <ogra_> cjwatson, yeah, i was mislead, its all fine on the flash-kernel side
[15:11] <rbasak> Either way, it doesn't seem to end up running
[15:12] <ogra_> Aug 10 14:34:06 in-target: Can't find /boot/vmlinuz-3.5.0-9-highbank or /boot/initrd.img-3.5.0-9-highbank
[15:12] <ogra_> Aug 10 14:34:06 flash-kernel-installer: error: flash-kernel failed
[15:12] <cjwatson> rbasak: the intention is for it to do nothing until the installer is ready for it to do something
[15:12] <ogra_> i would assume this is the reason
[15:12] <rbasak> ogra_: the reason is far above that
[15:12] <cjwatson> rbasak: no
[15:12] <rbasak> no?
[15:12] <rbasak> At the stage that flash-kernel runs, the initrd doesn't exist
[15:12] <cjwatson> rbasak: the behaviour at the base system installation step is intentional
[15:12] <cjwatson> the initramfs is supposed to be generated later
[15:13] <rbasak> cjwatson: ok, understood
[15:13] <rbasak> at what point should it be generated?
[15:13] <ogra_> i guess f-k-i should run update-initramfs before running flash-kernel here
[15:13] <cjwatson> right about the point that it's failing
[15:13] <ogra_> (or not run f-k at all and just raly on the trigger)
[15:13] <ogra_> *rely
[15:13] <cjwatson> ogra_: agreed, it should run update-initramfs I think
[15:13] <rbasak> So it's still a bug in flash-kernel?
[15:13] <cjwatson> rbasak: yes
[15:14] <ogra_> rbasak, right, just in a different place
[15:14] <cjwatson> ogra_: well, it may need to think a bit to work out which kernel to run u-i for
[15:14] <cjwatson> since I suspect -u won't work, as there's no initramfs yet
[15:14] <ogra_> right, but there will only be one kernel
[15:14] <rbasak> Yes - I tried -u manually after the install failed, IIRC.
[15:14] <ogra_> and it has version detection code
[15:14] <cjwatson> ah, of course, I had seen
[15:15] <cjwatson>                 in-target update-initramfs -u || true
[15:15] <ogra_> update-initramfs -c && flash-kernel i guess ...
[15:15] <cjwatson> and forgotten that that would now be insufficient
[15:15] <cjwatson> I think you should amend that line to check for the no-initramfs-yet case
[15:15] <ogra_> (-c doesnt call the hook (upstream decision))
[15:15] <rbasak> I'm at the failure point now, I can easily test something
[15:15] <rbasak> One question: can I get in-target to print output to the console? It redirects to syslog it seems right now
[15:16] <cjwatson> flash-kernel-installer.postinst already takes care of running flash-kernel later, so I don't think you need to worry about whether the hook is called or not
[15:16] <ogra_> ah, yeah
[15:16] <cjwatson> rbasak: for all the stuff here, you can just run chroot /target ...
[15:16] <ogra_> (the above was from top of my head)
[15:16] <rbasak> cjwatson: that's what I did but then it complains about /sys, so I had to bind mount that
[15:16] <rbasak> I'll do that :)
[15:16] <cjwatson> rbasak: although you can use in-target --pass-stdout
[15:16] <cjwatson> which is the direct answer to your question
[15:17] <rbasak> in-target --pass-stdout update-initramfs -u returns nothing
[15:17] <rbasak> but doesn't create the initrd
[15:17] <cjwatson> I wouldn't expect it to
[15:17] <ogra_> you need -c and the version
[15:17] <rbasak> right
[15:17] <ogra_> in-target --pass-stdout update-initramfs -c $(uname -r)
[15:18] <cjwatson> With -v, it would say "Nothing to do, exiting."
[15:18] <mahmoh> well, a link to the non-existent initrd is created
[15:18] <rbasak> http://paste.ubuntu.com/1139416/
[15:18] <arges> micahg, hello. I think I have a backport bug properly formatted, was wondering if you could take a look at pad.lv/943502 to see if this can be put into the queue. thanks
[15:18] <ogra_> rbasak, try -c -v
[15:19] <rbasak> ogra_: no joy: http://paste.ubuntu.com/1139424/
[15:20] <cjwatson> think you need -k $(uname -r)
[15:20] <ogra_> oh ... yeah
[15:21] <ogra_> or -k all
[15:21] <rbasak> in-target --pass-stdout update-initramfs -c -v -k $(uname -r) worked
[15:21] <ogra_> -k all should actually be fine so we dont need to rely on versions in that call and leave it to u-i
[15:22] <rbasak> Agreed - but to test I'll want to redo the test from scratch
[15:22] <ogra_> do that :)
[15:22] <rbasak> I'm on it :)
[15:23] <ogra_> though its really intresting that apparently -u behavior changed
[15:23] <ogra_> in the past it just created one as if you had called -c
[15:24] <rbasak> It was news to me that -u even existed, but I might be misremembering
[15:24] <ogra_> -u is used since forever
[15:24] <rbasak> IIRC I just ran update-initramfs and it updated it as per the name
[15:24] <cjwatson> update-initramfs -u has been there forever, and I'm not sure I agree with ogra_'s recollection :)
[15:24] <ogra_> cjwatson, i know i could use it with just -u in lucid at least
[15:24] <ogra_> it behaved like -c -k all
[15:25]  * rbasak clearly doesn't run update-initramfs very often
[15:25] <ogra_> (that was always my workaround for upstream refusing to call triggers from -c)
[15:25] <cjwatson> just looking at the oldest version I can find and I don't see this
[15:25] <cjwatson> are you absolutely sure that in such cases an initramfs didn't exist already?
[15:26] <ogra_> not absolutely, no
[15:27] <cjwatson> update-initramfs -u has always picked one of the currently-existing initramfses to update if not told explicitly (exactly which one it picks has changed), but I don't see that it ever updated all of them
[15:28] <mahmoh> cjwatson: quick ?: do you know of a way to force patman's last partition to a fixed size - avoid filling the disk?
[15:29] <cjwatson> mahmoh: you must create a dummy partition at the end, and then remove it in a manner of your choice at the end of install (preseed/late_command or whatever)
[15:29] <cjwatson> there is no way to do this natively in partman, I'm afraid
[15:29] <cjwatson> I mean, without such a hack
[15:29] <ogra_> cjwatson, oh, i didnt say that, i said it created one if there wasnt one
[15:29] <cjwatson> ogra_: I looked at the version in lucid and don't see that :)
[15:29] <mahmoh> cjwatson: thx, just confirming the hack I guess :) :(
[15:30] <ogra_> cjwatson, hmm, that one has set_initramfs() ?
[15:30] <cjwatson> ogra_: after the [ -z "${version}" ]
[15:30] <ogra_> it might have been a bug that it did create them but i'm pretty sure i used -u to create one for ac100
[15:31]  * ogra_ also remembers that he was wondering for years why -c exists
[15:34] <mahmoh> cjwatson: what's a reliable way to remove a partition from the installer env?
[15:35] <rbasak> parted /dev/sda rm 4? But it's not in the installer and I'm not sure sfdisk is either
[15:35] <cjwatson> yeah it is
[15:35] <cjwatson> anna-install parted-udeb
[15:36] <cjwatson> and then, yes, you probably want to use parted for this; it will involve accurately predicting the disk name and partition number I'm afraid
[15:37] <mahmoh> cjwatson: thx
[15:38] <rbasak> parse /target/etc/fstab, perhaps?
[15:38] <rbasak> But a bit horrible to detect UUID= and LABEL= and I have no idea if /dev/disk/by-uuid will exist
[15:38] <cjwatson> You probably don't want the dummy partition to be in /target/etc/fstab
[15:38] <cjwatson> Since you wouldn't want to give it a mountpoint
[15:39] <rbasak> I was going to look for another partition that is mounted on the same target disk
[15:39] <cjwatson> Ah, yeah, could do.  /dev/disk/by-uuid/ will exist
[15:39] <cjwatson> Might be easier to just df /target or something
[15:39] <rbasak> Good point
[15:39] <cjwatson> Or grep ' /target ' /proc/mounts
[15:40] <mahmoh> if by-label exists I can just use that
[15:40] <cjwatson> Whatever the syntax is
[15:40] <cjwatson> by-label exists
[15:40] <mahmoh> sweet
[15:41] <cjwatson> Er, I'm not sure partman lets you assign labels though?
[15:41] <mahmoh> it does
[15:42] <mahmoh> label{ DELETEME }
[15:42] <cjwatson> Ah yes
[15:42] <cjwatson> Hidden off in the per-fs code so I didn't notice it
[15:43] <rbasak> Good news, everyone! http://paste.ubuntu.com/1139467/ - "in-target --pass-stdout update-initramfs -c -k all" works as expected.
[15:45] <cjwatson> Lose the --pass-stdout for production code of course
[15:45] <cjwatson> Is it intentional that there's no suffix on the initramfs there?
[15:45]  * cjwatson doesn't know the subarch configuration here
[15:46] <rbasak> I'm not sure what you mean. But something didn't work. I see an initrd in /target/boot, but the installer still fails, which it didn't do last time
[15:47] <rbasak> Err, no it didn't create an initrd. I saw the vmlinuz-... and assumed
[15:47] <rbasak> It does return exit status 0 though
[15:47] <arges> hello. whats the process to get a new package added? looking to get a version of libhugetlbfs in lucid. i see its in natty onwards (and it cleanly can be built with backportpackage)
[15:48] <rbasak> With -v, "Nothing to do, exiting."
[15:48] <rbasak> So the only known way right now is with -k $(uname -r)
[15:49] <rbasak> "The use of "all" for the version string specifies update-initramfs to execute the  chosen  action  for all kernel versions, that are already known to update-initramfs.". I suppose update-initramfs doesn't yet know about this kernel, so we do need to use -k $(uname -r)?
[15:50] <rbasak> arges: do you know about https://wiki.ubuntu.com/UbuntuBackports?
[15:50] <arges> rbasak, yea I was going to do a backport... but the package doesn't exist in lucid at all... wasn't sure of the right path
[15:51] <arges> looks like the code hasn't changed in a while, as all version from natty->quantal are the same
[15:51] <rbasak> I think that's OK but I'm not sure
[15:51] <stgraber> stokachu: your branch is based on the wrong bzr branch. As that's a desktop package, the base is lp:~ubuntu-desktop/gnome-vfs/ubuntu
[15:51] <stgraber> stokachu: the diff applies cleanly on it, so I'm just going to merge it into that one for you
[15:51] <rbasak> ogra_: ^^
[15:52] <ogra_> rbasak, hmpf, i just uploaded with -k all
[15:52] <rbasak> ogra_: sorry
[15:53] <ogra_> rbasak, did you start the install from scratch fixing f-k-i before you did hit the error ?
[15:54] <ogra_> i know sometimes there are bindmounts of dev sys and proc in /target after an error occured that can make the installer fall over
[15:54] <rbasak> ogra_: I reinstalled from scratch, hit the error, and then -k all doesn't create the initrd even though I said it did earlier because I didn't look carefully (sorry).
[15:54] <rbasak> I did only in-target --pass-stdout update-initramfs -c -k all
[15:54] <rbasak> Last time, it did work with -k $(uname -r)
[15:55] <rbasak> I can reinstall from scratch again if you like to verify and make certain? It's all scripted so isn't any trouble, just takes half an hour
[15:55] <ogra_> rbasak, if you could inject the fix before it errors, that would be good
[15:56] <rbasak> ogra_: at what stage exactly?
[15:56] <ogra_> i dont see a reason why all wouldnt work
[15:56] <rbasak> We did just enable ssh so I can do that
[15:56] <ogra_> any stage before f-k-i gets called
[15:56] <ogra_> just to avoid it hitting the error
[15:56] <rbasak> OK but after the kernel gets installed I presume
[15:57] <rbasak> We have remote syslog working too so I should be able to manage that
[15:57] <ogra_> indeed :)
[15:57] <rbasak> Just to be sure, you mean to ssh and try "in-target update-initramfs -c -k all" after kernel install and before f-k-i?
[15:57] <ogra_> well, you will just edit f-k-i.postinst i guess
[15:57] <ogra_> you shoudl be able to do that at any time once the f-k-i.udeb is in place
[15:58] <rbasak> With -k all or -k $(uname -r)?
[15:58] <stgraber> stokachu: uploaded to quantal
[15:58] <ogra_> doesnt matter if teher is a kernel already ... as long as the fix and kernel are there if it gets executred :)
[15:58] <ogra_> rbasak, -k all please
[15:59] <rbasak> ogra_: any particular place in the postinst?
[15:59] <ogra_> we know that $(uname -r) works, but update-initramfs has its own version detection logic i would like to use instead of hardcoding for the boot kernel d-i uses
[15:59] <stokachu> stgraber: thanks
[15:59] <ogra_> rbasak, http://paste.ubuntu.com/1139494/
[15:59] <rbasak> ogra_: right
[16:00] <ogra_> rbasak, in the fs you will find it in /var/lib/dpkg/info/flash-kernel-installer.postinst
[16:00] <rbasak> ogra_: thanks
[16:00] <ogra_> (and you have to use nano, no vi in d-i)
[16:00] <rbasak> aargh
[16:00] <rbasak> That might be tricky
[16:00]  * rbasak will see what he can do :-)
[16:01] <ogra_> haha, nano isnt that bad :)
[16:01] <ogra_> (i agree its not fun either)
[16:02] <stokachu> stgraber: https://bugs.launchpad.net/ubuntu/precise/+source/libart-lgpl/+bug/977964 i think this one is ready to go as well
[16:03]  * rbasak considers submitting a vi udeb
[16:05] <stgraber> stokachu: ok. I'll push gnome-vfs and that one to precise-proposed then
[16:05] <stgraber> stokachu: gnome-vfs should be identical to the quantal upload I just did right? (except for the release and pocket)
[16:05] <stokachu> stgraber: exactly
[16:06] <stgraber> stokachu: ok, gnome-vfs uploaded to precise-proposed then
[16:06] <ogra_> rbasak, i would be surprised if cjwatson didnt acutally have a vi.udeb given he is an extensive user ;)
[16:06] <stokachu> stgraber: sweet :D
[16:08] <cjwatson> ogra_: you'd be surprised, then :)
[16:08] <cjwatson> I do use vi extensively but I have to cope with minimal environments often enough that I've learned to (barely) tolerate nano
[16:09] <ogra_> heh
[16:09] <rbasak> So my first nano problem isi that I didn't know how to jump to line 71, so I hope I've applied ogra's patch in the right place :)
[16:09]  * rbasak grepped the file afterwards to make sure
[16:09] <rbasak> Change injected, now waiting for the install to finish
[16:09] <ogra_> there is only one actual update-initramfs call in the script
[16:09] <ogra_> (the second mentioning is a comment)
[16:10] <ogra_> as long as the line you changed ends in || true ... all is fine
[16:10] <rbasak> Yeah that what the grep was for - to check :)
[16:10] <rbasak> http://paste.ubuntu.com/1139512/
[16:10] <cjwatson> I occasionally use extremely obscure sed invocations instead of nano
[16:10]  * rbasak did consider that just now
[16:11] <rbasak> I wonder if there's a patch to sed converter
[16:12] <stgraber> stokachu: debdiff in the libart bug isn't up to date. Can you attach one with the bug reference?
[16:13] <stokachu> stgraber: instead of the MP?
[16:13] <stokachu> ill do whatever you prefer
[16:14] <stgraber> stokachu: oh, I missed that it had a MP
[16:14] <stgraber> stokachu: sorry, will use that then
[16:14] <stokachu> stgraber: thats cool i just linked the related branch a min ago into the bug
[16:14] <ScottK> cyphermox: re Bug #1030316 - Postfix upstream has already decided it's the client's responsibility to convert the domain to punycode, so if it stays a postfix but, I'll have to mark it wontfix.  I think it should stay with evolution, but didn't want to just revert your change without discussing.
[16:14] <ogra_> rbasak, heh so instead of changing the existing call you added an update-initramfs call
[16:14] <ogra_> shouldnt do any harm though
[16:15] <rbasak> ogra_: really?
[16:15] <rbasak> ogra_: I don't see it
[16:15] <ogra_> you seem to have edited around line 30
[16:15] <stokachu> stgraber: shit i didnt update my maintainer email for that changelog
[16:15] <stokachu> lol
[16:15] <ogra_> the actual call is around line 74
[16:15] <stgraber> stokachu: that's fine, I fixed it ;)
[16:16] <stgraber> stokachu: you also forgot to run update-maintainer and the version should have been ubuntu0.1
[16:16] <ogra_> or your serial output simply messed it up or so
[16:16] <stokachu> stgraber: or update-maintainer
[16:16] <stokachu> stgraber: err yea you got it faster than me
[16:16] <rbasak> I did it via ssh
[16:16] <rbasak> http://paste.ubuntu.com/1139512/
[16:16] <stgraber> stokachu: resulting debdiff, let me know if that looks good: http://paste.ubuntu.com/1139518/
[16:16] <stokachu> stgraber: lol thanks i rushed it
[16:17] <stokachu> stgraber: looks good
[16:17] <stgraber> uploaded
[16:17] <stokachu> you da man
[16:17] <stokachu> stgraber: do these MP's automatically get flagged as uploaded
[16:17] <stokachu> or is it still a manual process
[16:18] <rbasak> ogra_: AFAICT the edit I intended is consistent with the grep output
[16:18] <rbasak> Though I admit I have no idea what line number I edited since I presume ^G doesn't work in nano!
[16:19] <cjwatson> ^C
[16:19] <rbasak> thanks
[16:19] <rbasak> Line 74 then
[16:19] <ogra_> oh
[16:19] <stgraber> stokachu: hmm, nope. Let me mark it as merged
[16:20] <ogra_> sorry, blind me i didnt get thats a grep
[16:20] <ogra_> i cought that was a copy/paste from your nano session
[16:20] <rbasak> Ah
[16:20] <stgraber> stokachu: they get marked as merged automatically when they are actually merged. Which isn't the case for these ubuntu-desktop branches or for SRUs
[16:20] <ogra_> so it looked pretty weird how the functions were suddenly merged into one :P
[16:20] <rbasak> No - I just did the grep to make sure there weren't any other similar occurrences because I didn't know what line number I was on
[16:21] <rbasak> tell you what:
[16:21] <rbasak> f5cbd5a8ff6202eca1a28187138d9e96  flash-kernel-installer.postinst
[16:21] <rbasak> :)
[16:21] <ogra_> heh
[16:22] <rbasak> "Making the system bootable"
[16:22] <ogra_> ogra@anubis:~/Devel/packages/flash-kernel-3.0~rc.4ubuntu18$ md5sum debian/flash-kernel-installer.postinst
[16:22] <ogra_> f5cbd5a8ff6202eca1a28187138d9e96  debian/flash-kernel-installer.postinst
[16:22] <ogra_> :)
[16:22] <rbasak> 33%
[16:22] <rbasak> !! ERROR: Installation step failed
[16:22] <rbasak> :-(
[16:23] <ogra_> rbasak, syslog please
[16:23] <rbasak> on its way
[16:24] <ogra_> thx
[16:25] <stokachu> stgraber: ok cool
[16:25] <rbasak> ogra_: http://paste.ubuntu.com/1139531/
[16:26] <bkerensa> bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.
[16:26] <bkerensa> No branches have diverged?
[16:26] <ogra_> rbasak, i dont see it running at all
[16:27] <rbasak> ogra_: line 3017?
[16:27] <ogra_> thats the fallout
[16:27] <rbasak> well with -k all, it doesn't produce any output
[16:27] <rbasak> since it considers there to be nothing to do
[16:28] <rbasak> which we see if we add -v. Is this what you mean?
[16:28] <ogra_> hmpf, ok, i'll switch to $(uname -r)
[16:28] <rbasak> ok
[16:30] <ogra_> uploaded
[16:30] <rbasak> ogra_: thanks! sorry for the extra upload
[16:31] <ogra_> well, i still would like to have -k all working ... but thats for later :)
[16:34] <stokachu> cjwatson: any feedback on latest comment on https://bugs.launchpad.net/ubuntu/+source/netcf/+bug/904014
[16:34] <rbasak> OK :)
[16:34] <rbasak> EOD
[16:37] <cjwatson> stokachu: I've followed up
[16:38] <cjwatson> stokachu: make sense?
[16:39] <stokachu> cjwatson: i think so :)
[16:40] <stokachu> cjwatson: i think there is a huge user base that would benefit from having precise updated , at least by this bug https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/520386
[16:44] <cjwatson> stokachu: although I'm on ubuntu-sru, I don't do a whole lot of SRU processing in practice, so in this case I'm probably not the one you need to convince
[16:44] <cjwatson> stokachu: for the purpose of this bug I'm basically the archive robot
[16:45] <cjwatson> stokachu: have a look through https://wiki.ubuntu.com/StableReleaseUpdates and see if you can come up with a justification that matches the "When" section there
[16:47] <cyphermox> ScottK: np.
[16:47] <ScottK> cyphermox: I'll switch it back then.
[16:47] <cyphermox> I'll ship that upstream
[16:47] <ScottK> Upstream evolution, right?
[16:47] <cyphermox> yeah
[16:47] <ScottK> cyphermox: Here's a reference: http://tech.groups.yahoo.com/group/postfix-users/message/266018
[16:48] <ScottK> The poster is one of the two main postfix devs.
[16:48] <cyphermox> alright
[16:49] <ScottK> Thanks.
[16:50] <cyphermox> ScottK: are you switching it back to evolution?
[16:50] <ScottK> I will.
[16:51] <ScottK> cyphermox: Done
[17:02] <stokachu> cjwatson: ok will do, thanks for the tip
[17:22] <micahg> arges: you can't backport from quantal straight to oneiric, you can to backport through precise
[17:22] <micahg> arges: requestbackport in ubuntu-dev-tools will tell you what you need to do if you pass it the proper options
[17:22] <arges> micahg, ok with this particular package i had to fix something with the debian/rules file upstream. that was fixed and put into quantal
[17:23] <arges> micahg, so do I need to apply that fix to precise, then backport to oneiric?
[17:24] <micahg> arges: you can backport to precise and then oneiric, or SRU to precise if appropriate and backport that to oneiric
[17:27] <arges> micahg, the change, btw, is to debian/rules because this package likes to check the version string and fail if it doesn't match. so I 'm guessing this is an SRU to precise to fix debain/rules rather than a backport
[17:32] <micahg> arges: right, I remember that
[17:33] <micahg> arges: so, the package currently in precise won't build if updated without this fix?
[17:34] <arges> micahg, we can only backport from quantal because that version has the proper debian/rules version regexp
[17:34] <micahg> arges: right, but for oneiric, you can only backport from a pocket in precise, so, you have to get it there one way or another
[17:35] <arges> micahg, ok so if i backport from quantal to precise. then i can backport the backport? : )
[17:35] <micahg> right :)
[17:35] <arges> okey dokey
[17:36] <micahg> arges: well, it ends up a no change backport from quantal, but you have to keep the upgrade path, that's the concept
[17:36] <arges> should i make a new bug for this? or just use the existing one?
[17:36] <micahg> arges: 'requestbackport -d oneiric -s quantal whois'  might make it clearer what work needs to be done
[17:37] <arges> micahg, also. the version string is 'whois_5.0.17' in quantal. the backportpackage appends ~series1  but shouldn't it append -ubuntu1~series1 ?
[17:37] <micahg> arges: it'll now be ~ubuntuXX.XX
[17:38] <arges> micahg, ok i'll get that going then. thanks
[17:38] <micahg> arges: you can use backportpackage to test what the version will be
[17:38] <micahg> arges: actually, quantal has 5.0.18
[17:41] <arges> micahg,  whois_5.0.18~precise1 is what it does
[17:42] <micahg> arges: you have an old version :)
[17:42] <arges> micahg, i'm on my precise desktop... will move to quantal laptop
[17:42] <micahg> arges: I use the u-d-t PPA
[17:42]  * micahg is still on precise
[17:42] <arges> micahg, cool adding ppa now thanks
[17:58] <arges> micahg, so there is a new naming convention for backports? the version regex i changed assumed the form -ubuntuX~series1  vs ~ubuntu12.04.1 ... so should I ask upstream guy to change the version string again (or ask that it be removed)? or is there a way I can patch debian/rules for  ubuntu?
[17:59] <cjwatson> the new naming convention is ~ubuntu12.04.1 tc.
[17:59] <cjwatson> *etc.
[17:59] <micahg> arges: I thought we discussed making it more generic...
[17:59] <cjwatson> use quantal's requestbackport
[17:59] <cjwatson> or backportpackage or whatever it is
[17:59] <micahg> arges: if it's that fragile, it's still broke IMHO
[17:59] <arges> cjwatson, yes normally it would work, but for this particular package it has a regex that checks for the version string
[18:00] <arges> micahg, yea I agree
[18:00] <arges> time to submit a patch
[18:00] <cjwatson> what I mean is that if it's assuming the form ~ubuntu12.04.1 then it's correct (modulo fragility)
[18:00] <cjwatson> it's not clear which side of your "versus" is which :)
[18:00]  * cjwatson -> dinner
[18:22] <Sweetshark> cjwatson: what was that magic source again I needed for async binary package copies?
[18:39] <cjwatson> Sweetshark: join the ~launchpad-beta-testers team and you can do it in the web UI
[18:39] <cjwatson> Sweetshark: https://blog.launchpad.net/general/beta-test-asynchronous-ppa-package-copies
[18:39] <Sweetshark> cjwatson: done, thanks!
[18:40] <cjwatson> just another couple of bugs to fix (which shouldn't affect you) and I think we can roll that out to everyone
[18:40] <Sweetshark> cjwatson: /me mumbles the inofficial libreoffice motto: "LibreOffice -- based on code breaking your toolchain since 1985"
[18:41] <Sweetshark> cjwatson: lets see what injuries we can do to launchpad with this ultimate testcase.
[18:41] <cjwatson> the bugs I know about only happen if the copies fail for some other reason :)
[18:49] <shadeslayer> cjwatson: kudos to the guys who implemented async copy
[18:51] <cjwatson> shadeslayer: does it work well for you then
[18:51] <cjwatson> ?
[18:51] <shadeslayer> cjwatson: yep
[18:52] <shadeslayer> I need to try copying the entire kde binaries though ...
[18:52] <cjwatson> oh good.  now if only I could reproduce the last bit of bug 1031092 in the test suite
[18:52] <cjwatson> I can make it happen in production, but ...
[18:52] <shadeslayer> cjwatson: before async copying, the kubuntu team wrote scripts to copy entire releases from one ppa to another
[18:53] <shadeslayer> just because lp went, "No, you're doing that wrong, it's 5 packages at a time"
[18:53] <cjwatson> yeah
[18:53] <cjwatson> you can still use copy-package in lp:ubuntu-archive-tools if you prefer scripting to the web
[18:53] <cjwatson> or indeed the Archive.copyPackage API call directly
[18:54] <shadeslayer> uh ok, I don't think anyone of us knew about copy-package ....
[18:54]  * shadeslayer looks
[18:54] <cjwatson> it's relatively new
[18:54] <shadeslayer> probably why
[18:54] <cjwatson> in fact part of the work in exposing this was to make Archive.copyPackage / copy-package work when the target archive is a PPA - that was previously disabled
[18:54] <shadeslayer> we've had kcopypackage for about a year now I think
[18:54] <shadeslayer> ah
[18:54] <cjwatson> does it use Archive.syncSource then?
[18:54] <shadeslayer> don't know, I'll have to look
[18:54] <cjwatson> no google hits for kcopypackage
[18:55] <shadeslayer> it's in kubuntu-dev-tools
[18:55] <shadeslayer> ah it's kopypackages
[18:55] <shadeslayer> cjwatson: http://paste.kde.org/532178
[18:56] <cjwatson> Right, syncSource.  That used to be the only option
[18:56] <shadeslayer>  target.syncSource, yeah, syncSource it is
[18:56] <cjwatson> That's the old synchronous interface
[18:57] <shadeslayer> ah
[18:57] <shadeslayer> I guess we should just use copy-packages now
[18:57] <cjwatson> You can basically s/syncSource/copyPackage/ to get the async version of the API, though if you're happy with the web UI / other tools then you may not want to bother maintaining that script
[18:58] <cjwatson> syncSource is vulnerable to timeouts on large packages, which you've probably noticed
[18:58] <cjwatson> or possibly uploads that close lots of bugs, I forget
[18:58] <lifeless> the latter
[18:58] <shadeslayer> cjwatson: the problem with the web ui is that it's not viable when you want to copy an entire PPA
[18:58] <shadeslayer> so if the webui has a "Copy everything from this ppa to target ppa"
[18:58] <shadeslayer> that would be awesome
[18:59] <shadeslayer> ( that usually happens for every KDE release that we test build and backport )
[19:00] <cjwatson> yeah, it would; I suggest filing a bug, as my work on this has largely been because it was getting in my way for other work :)
[19:00] <cjwatson> in the meantime, that's totally scriptable
[19:00] <shadeslayer> we just scripted it because we didn't expect it to be fixed soon enough
[19:00] <shadeslayer> for that matter, querying lp for recipes times out as well
[19:00] <cjwatson> I don't think anyone's filed this bug, so it's not on anyone's to-do list afai
[19:00] <cjwatson> k
[19:01] <shadeslayer> ( and a bug was filed for that as well )
[19:01] <cjwatson> perhaps because the mere notion of copying an entire PPA was utterly blocked on bug 575450
[19:01] <shadeslayer> hmm .. will do tomorrow, too tired to do right now :)
[19:01] <shadeslayer> :D
[19:01] <shadeslayer> "This bug affects you and 13 other people "
[19:01] <shadeslayer> xD
[19:01] <cjwatson> the recipes timeout is presumably bug 1009787
[19:02] <shadeslayer> yep, that's the one
[19:02] <cjwatson> which is probably beyond my SQL ability
[19:14] <sveinse> When preparing a new patch with quilt, do I always have to pre-declare (quilt add) which files I am about to change? It just feels so... cumbersome. I'd rather make quilt discover what I've done. (I'm a complete quilt noob)
[19:17] <cjwatson> sveinse: 'quilt shell'
[19:17] <jtaylor> sveinse: use a proper vcs for that
[19:18] <jtaylor> or that
[19:18] <jtaylor> I always forget quilt has that command
[19:18] <cjwatson> quilt fold is handy too if you're integrating a patch from elsewhere
[19:18] <sveinse> jtaylor: yeah, I'm preparing a patch for an existing package, so vcs isn't really an option here
[19:19] <cjwatson> but quilt shell is the swiss army knife
[19:19] <sveinse> and I can emacs in it I guess then :P
[19:20] <cjwatson> if your perversions lie in that direction
[19:21] <sveinse> lol, yeah
[19:42] <sveinse> Are there any resources available to determine if a command name is available? Beyond apt-file which lists everything?
[19:46] <roadmr> Hello! I need my application to somehow get notified when the user logs out, so it can clean up appropriately. What's the recommended way to do this?
[19:49] <infinity> roadmr: Trap SIGTERM and exit cleanly?
[19:51] <roadmr> infinity: oh so I *do* get SIGTERM on logout? that's what I was expecting but a quick experiment (trap the signal, write a file) didn't turn out anything. I must be doing it wrong...
[19:51]  * roadmr goes back to the drawing board
[19:53] <infinity> roadmr: Well, I don't know a ton about session management in the wonderful GUI world, but I assume all your children get a TERM, I can't see any other sensible way to do it.
[19:53] <slangasek> it depends
[19:53] <slangasek> you might get TERM, you might get HUP
[19:53] <slangasek> you certainly get a signal
[19:53] <infinity> slangasek: Randomly?  The application got SIGHUP when I closed the session. Sorry :/ now I know what i need to handle
[21:00] <SpamapS> slangasek: yeah looks identical really. I think the workaround we came up with is pretty decent considering.
[21:01]  * slangasek nods
[22:32] <xnox> micahg: thanks for fixing up the sqlite tracker
[22:33] <micahg> xnox: no problem, that list scared me :)
[22:33] <xnox> micahg: yeah it was scary to me as well. So did the regexp catch sqlite3 as well as sqlite, before you changed it?
[22:33] <micahg> xnox: yes
[22:33] <xnox> micahg: nice to know....
[22:34] <micahg> ~ /sqlite/   matches anything with sqlite in it
[22:34]  * micahg guesses his python-sqlite entry is redundant then :)
[22:35] <micahg> I'm glad to know negative lookaheads work :)
[22:36]  * xnox 's head takes a few human seconds to parse lookaheads though
[22:38] <micahg> xnox: there's a performance penalty in general with them, but it seemed to make sense here
[22:39] <xnox> micahg: it's only a tracker =) but the green ones - means that it's spurious dependencies that can/should/must be dropped
[22:39] <xnox> ?
[22:39] <xnox> (which verb do you choose?)
[22:39] <micahg> xnox: green is because good == true
[22:39] <xnox> micahg: but the package is affected.
[22:40] <xnox> micahg: so why is it still listing sqlite2 build-deps
[22:40] <micahg> no, most likely if it's green, it means it's an alternate build dependency or not built on that arch
[22:40] <xnox> ok
[22:40] <micahg> xnox: hrm?  not understanding the question...
[22:41] <xnox> it needs checking, in case if it's not an alternate build-dep, and we want to remove sqlite2 from the archive
[22:41] <xnox> it will need fixing.
[22:43] <micahg> let me make it not show green...
[22:47] <micahg> xnox: ok, the next refresh should get rid of the green
[22:48] <xnox> micahg: great it will be unknown instead, perfect =)
[22:48] <micahg> grr...silly redundancy, we
[22:48] <micahg> *we'll just call it clarity :)
[23:40] <cjwatson> Sweetshark: so did your libreoffice copies work out?  I'm not seeing a record of them in the logs ...
[23:46] <xnox> micahg: but now we have a split between green and unknown! more information =)
[23:47] <micahg> xnox: hrm? looks fine to me
[23:48] <micahg> xnox: unknown stuff means no binary bad stuff, but possible build-depends bad
[23:48] <xnox> micahg: well gentle has alternative build deps and ends up build against sqlite3
[23:48] <xnox> micahg: the rest, yes as you said
[23:48] <micahg> xnox: which is why it's good :)
[23:48] <xnox> previously we had 6 green =) now we have 1 green and 5 investigations ;-)
[23:49] <xnox> hence the comment "more information!" =)
[23:49] <micahg> which probably just means that --as-needed is doing its job and the build dependencies need to be updated
[23:52]  * micahg -> off now until Sat night
[23:54] <jocarter> have a good weekend micahg


[01:03] <fta> jdstrand, bug 641699
[01:03] <ubot2> Launchpad bug 641699 in chromium-browser (Ubuntu Maverick) (and 2 other projects) "6.0.472.59~r59126 -> 6.0.472.62~r59676 upgrade (affects: 1) (heat: 260)" [Critical,In progress] https://launchpad.net/bugs/641699
[04:29] <jdstrand> fta: ack. if you get me a lucid package, I'll get it building and into -proposed over the weekend
[17:36] <gnomefreak> i cant get thunderbird to move junk to junk folder when i mark as juck. it is set to move them
[17:38] <gnomefreak> as incoming messages are marked as junk and moved to junk folder
[17:39] <gnomefreak> only add-ons is enigmail
[18:02] <fta> jdstrand, just uploaded to maverick. for lucid, do you want the 3 releases piled up, or only 1 collapsed?
[18:53] <jdstrand> fta: well, .55 is in lucid-proposed now, so we need it but can collapse .59
[19:38] <fta> jdstrand, http://people.ubuntu.com/~fta/chromium/6.0.472.62~r59676-0ubuntu<IP_ADDRESS>/
[20:03] <fta> jcastro, i use chromium --app flag to have my preferred webapps on my desktop, i don't see why it won't work with unity


[00:03] <nhaines> I didn't get around to the meeting reminder last night.  I can do it later, but if someone wants to do it before I do...
[01:41] <ianorlin> I ended up busy and can't really head out taking a car in for service getting groceries
[15:29] <Roguehorse> good morning
[16:33] <pleia2> nhaines: how did your talk go? :)
[18:11] <Roguehorse> oh, yes...please...do tell? =)


[02:58] <oscalation> hello
[04:24] <holstein> oscalation: hey
[04:24] <holstein> welcome to the channel :)


[21:58] <Nukien> Why are only sata drives populated in /dev/disk/by-id and not scsi drives ?  Having issues in vmware/virtualbox with scsi type drives not being in /dev/disk/by-id
[22:01] <valorie> in artful?
[22:01] <valorie> this chan is for artful -- see the /topic
[22:05] <Nukien> Doh - sorry, didn't see the +1.  For 16.04 (and others as I'm discovering)
[22:06] <valorie> for released, see #ubuntu
[22:06] <valorie> or the flavor channels, such as #kubuntu
[22:06] <valorie> for vms, #ubuntu is appropriate


 Still feeling great about that guy that we helped the other day
[19:29] <itnet7> govatent: Yeah, that was really cool!!
[19:30] <govatent> Hey can you send me the picture late of the guy taking the picture of my eye
[19:30] <itnet7> I didn't remember, but Hannya mentioned that he too was from Ecuador
[19:30] <govatent> yup he was
[19:30] <govatent> I told Jorge the story and it made his day
[19:31] <govatent> later*
[19:33] <itnet7> Yeah, It was really a good thing, I was glad to see everything when it worked out well
[19:34] <govatent> It was also good for me to figure out how to work with people in order to meet all their needs in ubuntu. So I will know how to handle people who come to the cafe from the windows/mac world
[19:36] <mhall119> itnet7: getting ready for some vacation time
[19:37] <itnet7> mhall119: Sweet, You guys deserve a break! Going to see snow?
[19:37] <mhall119> no, we went to Tennessee last month
[19:37] <itnet7> Awesome!
[19:37] <mhall119> this is just vacation from work/school
[19:37] <itnet7> unplug
[19:38] <itnet7> :-)
[19:38] <mhall119> me?
[19:38] <mhall119> not likely
[19:38] <itnet7> ROFL
[19:38] <mhall119> going to spend time working on Qimo I hope
[19:38] <govatent> lol
[19:38] <govatent> that's cool
[19:38] <itnet7> govatent: yeah, to be honest I thought that you were taking on a pretty difficult task, and I was proud of you for accomplishing it
[19:40] <govatent> thanks
[19:40] <govatent> i did not think it was that bad. Just dealing with Microsoft Virtual PC thing was annoying.
[19:41] <itnet7> Yeah, not really difficult, but you showed a really great confidence. I would have not deleted his windows drive until I was sure, the new solution met his needs, even though he was more than willing ;-)
[19:42] <balloons> this sounds like an interesting story :-)
[19:42] <itnet7> balloons: It was pretty cool
[19:42] <itnet7> Was he an opthomalogist
[19:46] <govatent> Well the only reason he was going to keep 7 is because he thought the virt software for XP was made just for 7 and he would not be able to use it. Being a virt i knew i could just move it into any virt solution.
[19:46] <govatent> he uses his computer mostly for web surfing and that xp software
[19:46] <govatent> so now he will be safer online too
[19:50] <maxolasersquad> You know that good feeling when you delete a couple hundred lines of code?
[19:53] <govatent> I can only imagine it
[19:55] <maxolasersquad> govatent: It works like this, "Good day to you sir!  You are unneeded as I have found code a fraction of your size that will do what you did, but more efficiently."
  My wife was getting pretty annoyed.
[19:56] <maxolasersquad> I was looking for a wall clock with Kanji.
[19:56] <govatent> did you find one?
[19:56] <maxolasersquad> Yes
[19:56] <govatent> that sounds like a pretty cool clock.
[19:57] <govatent> hum....*thinks*
[19:57] <itnet7> gonna grab some agua, brb
[19:57] <govatent> ok enjoy itnet7
[19:57] <maxolasersquad> http://www.amazon.com/South-Wind-Clear-Silent-Clock/dp/B004TMEBFU/ref=sr_1_fkmr0_1?ie=UTF8&qid=1324324634&sr=8-1-fkmr0
[19:57] <govatent> that's a very nice clock
[19:58] <maxolasersquad> And it's a lot cheaper than $50.
[19:58] <govatent> lol very much so
[19:58] <govatent> but it does not get to annoy you :P
[19:58] <maxolasersquad> We went to an Asian seafood market and practiced reading the Japanese labels.  The kids where pretty pumped.
[19:59] <govatent> nice
[19:59] <govatent> that's really cool!
[19:59] <govatent> btw, i finally learned to work with VI. better late than never. Man i was missing out.
[19:59] <maxolasersquad> They where able to make out genmai ocha (Green Tea) and tofu miso
[19:59] <govatent> That's great
[20:00] <govatent> You guys should check out the Japanese Garden and Museum in West Palm Beach. It's pretty sweet and I think worth the drive. I have yet to go as I have never have time and its a slight drive even for me
[20:01] <govatent> maxolasersquad: http://www.morikami.org/
[20:01] <govatent> I think you and the family would enjoy it
[20:01] <maxolasersquad> Ichimura Japanese Garden?
[20:01] <maxolasersquad> Cool
[20:02] <govatent> and if you guys do go there you must inform me! :P
[20:02] <govatent> its like an hour from me . give or take with traffic
[20:03] <maxolasersquad> It'll probably be a while before I'm that way again.  My brother-in-law lives in Pompano Beach, so one day we'll be back for sure.
[20:05] <govatent> cool
[20:05] <govatent> how have you been?
[20:06] <maxolasersquad> Alright.  Gearing up for a major software release, about two years of work coming out the gates.
[20:09] <govatent> nice
[20:09] <maxolasersquad> The toughest part is fighting all those who wish to creep scope unnecessarily.
[20:09] <maxolasersquad> I call them "creepers"
[20:16] <itnet7> +1 maxolasersquad
[20:16] <itnet7> that seems to be the hardest part
[20:16] <itnet7> during a project
[20:17] <maxolasersquad> It's hard enough to keep myself from doing it.  Lord knows hindset shows me so many better ways to do things than the way I originally engineered them.
[20:17] <maxolasersquad> hindisght too.
[20:18] <maxolasersquad> spelling fail
[20:19] <itnet7> Sure
[20:21] <itnet7> Not sure how bad it is to rethink the engineering so much as having someone always trying to creep in new value added features that will only take a few minutes ;-)
[20:49] <amouge> hello everybody :)
[20:49] <amouge> any active users in the Jacksonville area?
[20:52] <mhall119> amouge: we have some further south, and we've had some in J-ville in the past
[21:03] <amouge> mhall119: hmm ok. I moved up here from tampa, I use to be semi active in this channel. But since I moved up here I have joined up with jaxlug and started a hackerspace up here too. So just looking to meet up with others like minded around here
[21:04] <mhall119> amouge: cool, I'm surprised we don't have more active people in Jax, but hopefully that'll change
[21:04] <mhall119> having a hackerspace is nice
[21:04] <amouge> well our monthly meetings for jax lug usually have around 30+ people.. and we opened our hackerspace 3 weeks ago and had 27 people at the open tuesday meeting last week
[21:05] <amouge> we have 8400 square feet :-D
[21:06] <amouge> I will have to see how many of them are interested in ubuntu group here, I've heard many of the users mention that they use ubuntu at the meetings
[21:07] <amouge> most of them think irc is dead.. lol
[21:09] <govatent> I'll have to check it out next time I am up there.
[21:09] <amouge> definately :)
[21:10] <amouge> jaxhax.org :)
[21:11] <mhall119> dead? I've got 40 channels on 5 networks
[21:11] <amouge> lol I agree
[21:14] <amouge> I will have our arduino door done tonight.. had a heck of a time trying to figure out why the rfid was blocking the exit button from communicating.. Then members wanted more and more features and the code isnt going to fit on one so we are doing a dual arduino which talk to each other.. eventually i will learn to program directly onto the atmega chips lol
[21:21] <govatent> lol
[21:23] <govatent> My friend built a IP based door opener using arduino to unlock the door
[21:24] <amouge> heh, ours will be unlockable via a login system on our internal wifi only if you forget your key..
[21:24] <amouge> eventually it will fully talk to our membership website that hasnt been built lol
[22:57] <cjohnston> itnet7: uggh.. city teams :-P
[23:04] <mhall119> no city teams
[23:04] <cjohnston> mhall119: look at the ML
[23:05] <mhall119> I saw it
[23:05] <mhall119> but city teams are going away
[23:05] <mhall119> even Vancouver is getting rolled up into a larger team
[23:06] <cjohnston> reply to the ml and say that
[23:06] <cjohnston> 183 is gone
[23:12] <mhall119> itnet7 already replied to the ML, there's no need to add more
[23:22] <Guest63388> hi


[00:19] <Maik> !discuss | linux-fuer-einst
[00:19] <Maik> #kubuntu-offtopic is also an option
 MPT. Sometimes when I plug in my phone it loads up in Cantata music player with the phone music library and I can click an artist or album and send it to the phone. Sometimes I can access the Android files through Dolphin. I can never do both and it is random on which function will work! argh! I mostly sync music but of course I need Dolphin access at times also. How can I have consistent access to Cantata AND Dolphin?
[05:07] <Guest99291> Hello?
 @Anarchotaoist, The issue seems to be Dolphin will not share! If I close out Dolphin and reboot, I can then open Cantata and sync if I do not mount the phone in Dolphin - and vice versa! There is no unmount option. I am sure you could unmount from either Cantata or Dolphin in the terminal and then load the other instead of rebooting but this REALLY should be a lot simpler!
 @Anarchotaoist, I submitted a bug report.
[06:26] <BlackMouse> Greetings everyone
 https://live.fosdem.org/watch/kfosdem
[08:25] <alessandro_> ciaooo
[08:44] <rainer> Hallo
 Hey
[11:41] <Nobun> I have a problem in kubuntu 20.04. I see a strange icon in the application bar, near to the icon of the application that notifies you have updates
[11:42] <Nobun> It is a terminal-like icon with an esclamation mark and if I put the mouse near it says java. That is quite strange and it seems a malicious thing
[11:42] <Nobun> I'd like to know how to remove it
 @Nobun, provide a screenshot link please
[11:42] <Nobun> IrcsomeBot: sure... wait a moment
[11:44] <Nobun> I am making two shots.... one with normal screenshot and one with phone. I need a bit of time to upload them and I provide links
[11:48] <Nobun> first shot: https://imgur.com/a/QgsBiLw
[11:49] <Nobun> the icon is that one with esclamation mark in the notify bar near to update icon (hour of time etc)... I will upload the phone shot to show that "java" thing (since it is a notify can't be shotted with standard screenshot)
 @Nobun, yes I saw
[11:51] <Nobun> https://imgur.com/a/hPs4414
[11:52] <Nobun> this is where it says "Java, eseguibile" "eseguibile" is an italian word to say "executable"
[11:52] <Nobun> sorry for the bad photo but the notify couldn't be taken with standard screenshot
 @Nobun, is it persistent ?
[11:53] <Nobun> Yeah. I tried to shutdown and re-enter kubuntu and it is still there
[11:53] <Nobun> I noticed tomorrow so it should be a recent thing
[11:53] <Nobun> today *
[11:53] <Nobun> sorry
 @Nobun, what were you doing or something else before this started appearing in your tray.
[12:00] <Nobun> Don't remember because today I noticed this icon as soon as I launched the system. The only thing I can think of is some bad things (a worm, trojan or something similar) comed somehow from the net. But can't figure an actual reason why it happened
[12:04] <Nobun> not sure if it helps but usually I am used to use Firefox and not Chrome, even if Firefox is less suggested in recent days
[12:04] <Nobun> I use chrome only in sites where chrome is actually suggested (like if you need to use google services like meet or you need to join a microsoft teams link)
[12:05] <Nobun> but for standard researches or reading I use Firefox
 @Nobun, yes, I also can't find any answer/solution to your prob 😅🤔
[12:07] <Nobun> IrcsomeBot: I figure it can be solved through KDE but don't know exactly how to access (since I am pretty new on KDE I was used to Ubuntu unity) apptrays. Probably there is a directory where there is a sort of applauncher I can simply remove
[12:16] <Nobun> currently I am trying to profile all *.desktop files in my system and see if there is something strange with "find / -name *.desktop > file.txt"
[12:16] <Nobun> since all the things in trailers should be desktop file I assume...
 @Nobun, trailers ?
[12:17] <Nobun> application tray sorry xD
 @Nobun, I don't why are you saying desktop file in your last message but the that area is called "System Tray" and it is a widget.
[12:22] <Nobun> IrcsomeBot: as far as I know in system tray resides (like Kde menu) desktop files wich works as launchers of applications
[12:23] <Nobun> now I will try to reboot system. I found a strange thing at: /home/user/.config/autostart/teams.desktop
[12:24] <Nobun> I tried teams but I removed it uninstalling it. And it is strange since I did several time ago. So I don't think it is the issue, but I will try to reboot after removing it
[12:25] <Nobun> IrcsomeBot: obliouvsly if you have a better idea to track the problem I am glad to hear you. For the moment this is the only thing I could think of
[12:25] <Nobun> I will return soon... trying reboot
[12:30] <Nobun> I confirm that doesn't solve anything, but since I had no other idea it worth a try
[12:49] <BluesKaj> howdy all
[13:10] <rainer> Hi
[13:12] <allon-M> Hi everybody, my name is Emmanuel, I am one of the developper of GCompris and before yesterday I broke my Kubuntu development environment, so for now I can not develop anymore
[13:12] <allon-M> The problem lies with xserver-xorg-legacy
[13:13] <allon-M> it tells me that it can not create regular file XWrapper.config.dpkg-new. I tryed to purge everything I could purge
[13:14] <allon-M> reinstalled kubuntu-desktop, but always bump on this  xserver-xorg-legacy  problem
[13:15] <allon-M> is this canal the place to discuss a solution or should I rather see with xorg forums?
[13:28] <BluesKaj> allon-M, try the #kubuntu-devel chat
[13:29] <allon-M> thanks a lot
[13:29] <BluesKaj> np
 can a root Partition be logical ?
[13:34] <BluesKaj> yes if you're in legacy bios mode then you're restricted to 4 primary partitions
[13:36] <BluesKaj> @ri5h46h, https://askubuntu.com/questions/464402/choosing-partition-types-for-swap-and-root-and-choosing-device-for-bootloader-in
 @BluesKaj, BluesKaj, is it necessary that we need to use mbr disk only with Legacy systems ?  … as I read somewhere that we can create a bios-mbr Partition on a gpt and select that for installating bootloader ?
[13:58] <kmart> hi
[13:58] <kmart> can someone tell me if there is a chance latest amdgpu drivers could work on kubuntu?
[13:59] <kmart> like some drivers _are_ installed already, came with 20.04LTS I guess
[13:59] <kmart> but those drivers dont work with VMWare
[13:59] <kmart> so I either need to downgrade or update
 @kmart, did you try 20.10 ?
[14:09] <kmart> no, but isnt 20.04 supposed to be the stable one
 @kmart, yes, but 20.10 is also stable
[14:10] <kmart> i cant risk damaging this workstation by upgrading to non LTS version
[14:12] <kmart> i'd rather jsut try to downgrade the drivers
[14:12] <BluesKaj> @ri5h46h, https://superuser.com/questions/1245299/if-my-motherboard-does-not-support-uefi-bios-can-i-still-use-gpt-for-non-boot-d
[14:13] <BluesKaj> kmart, amd gpu is supported on kubuntu, justn make sure you use the correct driver by checking in driver manager
[14:19] <Nobun> IrcsomeBot: one of the most important thing is that the /boot partition will be NOT a lxc container, but a real partition (logical or phisical not important)
[14:20] <Nobun> if you plan to use lvm (sorry not lxc I said wrong) it is suggested to have an extra partition for /boot
[14:20] <Nobun> in order to avoid problems with grub or similar boot managers
[14:21] <Nobun> so if you plan to use lvm you can do it, but make sure to save an actual (not-lvm) partition for /boot
[14:21] <kmart> BluesKaj, one would think that a driver "Radeon™ Software for Linux® version 20.20 for Ubuntu 20.04" released in June last year, specifically for the Ubuntu 20.04, which is the counterpart for kubuntu 20.04, would work
[14:21] <kmart> but it does not even install
[14:22] <Nobun> kmart: probably you could need some gtk components? As far as I know the main difference from kubuntu and ubuntu is having KDE instead of Gtk
[14:23] <Nobun> strange that depencies are not tracked in .deb package however
[14:23] <kmart> https://pastebin.com/aVhmx3Tf
 @Nobun, thank you.
 @Nobun, Qt you should say instead of LDE
[14:25] <Nobun> @ri5h46h actually KDE is an extension of Qt so imho is more correct saying KDE
[14:25] <Nobun> or better a derived library
[14:26] <Nobun> so having installed KDE means you have qt installed. But the Gui is KDE
[14:26] <Nobun> while Gtk is both libraries and Gui
 @Nobun, what ? Extension?
[14:26] <Nobun> ri5: yeah I said in improper word
[14:27] <Nobun> but it is like talking about ubuntu vs debian. Ubuntu is devian derived. Kde derives from qt
[14:27] <kmart> https://pastebin.com/LtBQE3Ni
[14:27] <Nobun> Ubuntu is debian derived *
[14:27] <Nobun> but KDE extends Qt with other things that are kde-specific
[14:28] <Nobun> for exmample KImageIO extends QImage
 @Nobun, KDE Plasma is a desktop environment made using the Qt framework
[14:28] <Nobun> esactly that is why I say KDE and not Qt
[14:29] <Nobun> KDE implies having qt but not vice versa
[14:29] <Nobun> kde is a framework that extends qt in a lot of things
 @Nobun, so that way you should say GNOME instead of GTK here
[14:30] <Nobun> ri5: yeah good point.
[14:32] <Nobun> however probably the requirements he can need to Radeon software could be (but it is a speculation) gtk libraries not the entire gnome desktop
[14:33] <Nobun> kmart: are you compling from source?
[14:34] <Nobun> this error is tied to -Werror linker flag which could be omitted (but i would suggest not)
[14:35] <Nobun> probably there is a bug or you are using a different c/c++ standard then expected one?
[14:35] <kmart> i read that recent dkms changes made the drivers incompatible with the system
[14:35] <kmart> so i should update kernel to mainline
[14:35] <kmart> is that safe to do on kubuntu?
[14:36] <kmart> i ahve 5.4.x and it has to be 5.6.x or higher
[14:36] <Nobun> kmart: unfortunately I am not so expert, so wait for a more informed person.
[14:37] <Nobun> I think you could update kernel safetly, but it is an assumption I can't give you gurantees since I don't know how to configure kernel
[14:38] <Nobun> perhaps the most simplier solution is to try to update from Kubuntu LTS to Kubuntu 20.10 that should be released (6 monts releases usually has more recent things)
[14:39] <Nobun> but wait for a person who can help you more. I can't provide you actual help to this particular problem. Sorry
[14:40] <BluesKaj> afaik the latest kernel is 5.8 for 20,04 LTS, https://9to5linux.com/ubuntu-20-04-2-lts-released-with-linux-kernel-5-8-from-ubuntu-20-10-download-now
[14:41] <Nobun> BluesKaj: also my system has kernel 5.4 but my last update was some made some weeks ago
[14:43] <BluesKaj> Nobun, there have been a few problems with 5,8 kernel a while back, but it seems fine now, since I haven't seen any complaints for the last week or so.
[14:45] <Nobun> I simply apt update + apt dist-upgrade... so I let upgrade kernels when the system says so xD
[20:22] <viewer|46> hello
[20:23] <viewer|46> any Kubuntu developers in here now?
[20:26] <viewer|46> I have a question about iso download
[23:21] <mparillo> Getting late on a weekend, but you can simply ask. If anybody knows, you will get an answer, but you may need to hang around.
[23:52] <krytarik> I quite regularly see wasted effort here in trying to help somebody who in this case left already 3 hours ago and 2 minutes after indicating they got a question.. >_<