[02:43] <vincent_c> Noskcaj: pinging you here since you aren't in #debian-python right now
[02:43] <vincent_c> any plans on dealing with http://bugs.debian.org/746251 ?


[00:04] <guiverc> sudodus asked for a Lubuntu logo (scalable, svg?) on https://discourse.lubuntu.me/t/focal-fossa-20-04-lts-wallpaper-competition/566/38 ; I've looked and failed at finding one; anyone know a location easily?
[00:07] <wxl> guiverc: i *THINK* @kc2bez is on that one
[00:07] <wxl> btw guiverc does this describe you?
[00:07] <wxl> 0943 < lubot:#lubuntu-devel> <HMollerCl> Someone using nvida and dual monitors wit lubuntu lxqt? I'm having a hard time to configure it properly.
[00:09] <guiverc> i have "hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)"  with 2x 1920x1080
[00:09] <wxl> ^ @HMollerCl
[00:09] <guiverc> also hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600) though currently 'live' only (no disk space)
 @guiverc [<guiverc> i have "hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)"  with 2x 19 …], working ok?
 are you using propietary or nouveau?
[00:17] <guiverc> i only use them for qa-testing; dc7700 for installs; 8200 for 'live' so it'll be whatever is default (nouveau I'd suspect)  .. booting 7700 now
[00:17] <guiverc> yep nouveau
 aaaa, ok, nouveau works fine for me too, problem is with propietary. Default config doesn't work well and in the formus I read that I need to create xorg.conf but when I create that sddm fails to start
[00:25] <lynorian> I don't havea nvidia I kind of hate mounting gpus thouse and just got a new amd one
[00:26] <wxl> bug 1861465
[00:26] <wxl> ^ we could always have a shellprocess job that renames os-prober XD
[00:27] <wxl> ^^^ @tsimonq2 want to make you aware of this because it's pretty freaking critical.
[00:28] <guiverc> I may install lubuntu on 8200 next week ... loading nvidia-340 now on 7700  (ubuntu-drivers; 20.04), rebooting..   now driver=nvidia; the screen positioning appears default (doesn't match my screen setup) but otherwise looks normal..
[00:33] <guiverc> dc7700 was a ~clean install (i change wallpaper as sign of modifying config on qa-installs; this wallpaper was still default); logout; general play looks normal with minimal test since driver=nvidia on this box
[00:33] <guiverc> @HMollerCl ^
 @wxl [<wxl> guiverc: i *THINK* @kc2bez is on that one], Yeah, sorry I haven't replied yet. I will do that tonight.
 guiverc: trying to make it match your config is the problem
 in my case nvidia-settings only detected one big screen
[00:35] <guiverc> i changed screen positions to what I use, no issues, firefox stream local news etc. but it's minimal testing & not use..
[00:36] <guiverc> Thanks Dan (kc2bez)
 guiverc: in my case dpi wasn't detected correctly and the default was unified view
[00:39] <guiverc> it could be card specific.. i won't leave that box on though today (it's fan screams when ambient temperature is 30oC as it is today..)
 @wxl [<wxl> ^^^ @tsimonq2 want to make you aware of this because it's pretty freaking …], Understood. Glad you can reliably repro
 wxl: I updated copyright on the theme
[00:45] <wxl> saw that thx
 @guiverc [<guiverc> it could be card specific.. i won't leave that box on though today (it …], It has been really hot this summer in southern hemisphere...
[00:46] <wxl> @HMollerCl don't forget you need to update D71
 @wxl [<wxl> @HMollerCl don't forget you need to update D71], with qt5 vcl_plugin pdf problem, I think we should wait for that.
[00:49] <wxl> @HMollerCl i'm kind of of the opposite inclination since we're in a devel release.. let's get it in there and see what happens and revert it if we need to
[00:50] <guiverc> wxl sorry I've not got to testcases & to chase you up  (yet)
[00:50] <wxl> guiverc: np. you get your machine all back to normal?
 wxl: I'm on another computer now, how can I get the same "branch"?
[00:53] <wxl> @HMollerCl you mean get your branch?
 yes
[00:54] <wxl> arc patch D71 --nobranch
 but I git clone the repo as normal
[00:55] <guiverc> wxl my data is all there (outside anything .*), bzr issue remains (https://answers.launchpad.net/bzr/+question/688323)  or "brz: ERROR: A control directory already exists" which I've had before, but haven't resolved yet.
[00:56] <wxl> @HMollerCl yep
[00:56] <wxl> @HMollerCl think of arc as a git frontend
[00:56] <wxl> guiverc: try checking our your branch instead of lp:ubuntu-manual-tests, i.e. lp:~guiverc/ubuntu-manual-tests/lubuntu-calamares
[00:57] <wxl> guiverc: and don't forget about #launchpad
 wxl: how was that I use anorther user when cloning? seed is from launchpad....
[01:00] <guiverc> Thanks Walter, the lp:~guiverc gives a different issue, so I'll try there awhile..  (shortly)
[01:01] <wxl> @HMollerCl i'm not sure i understand?
[01:01] <wxl> guiverc: aw jeez. you really should check in at #launchpad
 git clone 'ssh://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu' … ... … Launchpad user 'hmoller' doesn't have a registered SSH key …<EMAIL_ADDRESS>Permission denied (publickey).
 because my launchpad user is "hmollercl" not hmoller
[01:02] <wxl> oh boy
[01:02] <wxl> that i'm not sure of
[01:02] <wxl> ask at #launchpad XD
 jaja, I've done that before, I don't remember
[01:03] <wxl> oh
[01:03] <wxl> change the uri to<EMAIL_ADDRESS>?
 facepalm
 wxl:done
[01:30] <kc2bez> wxl: since there is only one branch for cala settings I just `arc land` right?
[01:31] <wxl> right
[01:31] <wxl> not sure why there's only one branch tho....
[01:31] <kc2bez> thanks
[01:31] <kc2bez> I dunno
[01:32] -lugito:#lubuntu-devel- [rCALASETTINGS2cc0bed73bcf: Add shellprocess for i386 multiarch] kc2bez (Dan Simmons) committed: https://phab.lubuntu.me/rCALASETTINGS2cc0bed73bcf
[02:01] <wxl> guiverc: aw hell. good catch.
 @HMollerCl [git clone 'ssh://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu' … ... … L …], Modify your .ssh/config file. … I remember someone offering me a dollar to get that right.
 XD
[06:19] -lugito:#lubuntu-devel- [rMANUAL9cd46a2aa1a4: Split tab into own paragraph] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL9cd46a2aa1a4
[06:51] -lugito:#lubuntu-devel- [rMANUAL3b31af5fe444: Update kde partition manager summary] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL3b31af5fe444
 https://phab.lubuntu.me/D79
[11:09] -lugito:#lubuntu-devel- [Needs Review] Merge from Ubuntu Merge-o-Matic: https://phab.lubuntu.me/D79
 @The_LoudSpeaker [<The_LoudSpeaker> commit for l10n https://phab.lubuntu.me/rLXQTLTENNPACKAGING350 …], @tsimonq2 can you upload  this? also, we should add it in packageset since debian added it back?
[11:17] <kc2bez> @The_Loudspeaker did that patch in lxqt-config apply cleanly and build?
 yes it did.
 the problem was that manpages weren't installed anywhere.
 so I added a few lines in .install file.
[11:18] <kc2bez> That makes sense based on your paste yesterday.
 https://phab.lubuntu.me/P62 … ^ This one is from from MoM. it doesn't have those install file changes which I made just now. So gives the error I pasted yesterday.
[11:19] <kc2bez> wxl: take a look at the patch in that ^^ I think it may address an issue we found a while ago.
 which issue?
[11:21] <kc2bez> in the keyboard layout configuration and switching between different configurations
 link ploxx?
[11:26] <kc2bez> The link in the patch takes you to the github issue :)
 ow. yes.
[11:49] -lugito:#lubuntu-devel- [rLXQTOPENSSHASKPASSPACKAGING5b12c424f345: Merge from Ubuntu M-o-M] The_LoudSpeaker (Raman Sarda) committed: https://phab.lubuntu.me/rLXQTOPENSSHASKPASSPACKAGING5b12c424f345
 @The_LoudSpeaker ^
 haa?
 @The_LoudSpeaker [haa?], you put me as reviewer on the merge :P
 yeah that one is for config. I was facing some issues.
 https://paste.ubuntu.com/p/s7s4hdVHf7/
 ^ This one @RikMills
 But it is fixed in the revision I added you as a reviewer. Kindly review when free.
 side quest: once the package is out of proposed pocet, only then it disappears from Merge-o-Matic na?
 @The_LoudSpeaker [But it is fixed in the revision I added you as a reviewer. Kindly review when fr …], I just commented on the merge
 @The_LoudSpeaker [side quest: once the package is out of proposed pocet, only then it disappears f …], Correct
 @RikMills [I just commented on the merge], I did a debdiff between previous ubuntu version and the one created from the merge. Shouldn't it have the changes from debian and changelogs as provided by debian when making those changes?
 When you are doing the remaining changes section in the changelog, these are the differences between debian version and the result of your ubuntu merge.
 okay. So I need to be more verbose about those changes.
 @The_LoudSpeaker [okay. So I need to be more verbose about those changes.], Yes, as they are they to either remind you or inform someone else, what changes you kept and why. For example, 'update rules' doesn't tell anyone what was updated and why
 also, I don't see the debian/upstream/metadata in the merge so not there in the revision.
 @RikMills [Yes, as they are they to either remind you or inform someone else, what changes …], k.
 @The_LoudSpeaker [also, I don't see the debian/upstream/metadata in the merge so not there in the …], it is in debian
 But not in merge.
 how so?
 The merge was created by MoM I just fixed small errors and manpages thing.
 I don't know, but not merge tool is perfect. Which is why I usually try to do a manual check with meld/kompare to check things over.
 I found meld in software center but how do I install and use it via terminal? I have the work env in a container.
 I will make the other updates to the revision about changelog entries in a while. Time for snacks.
 You can do a ssh session where you can run a GUI app from the host. It lags, but it can work. I forget the option. … Or you could work locally. If you are not doing HUGE packages that is usually ok.
 Other workaround could be a gui container. I will try setting that up.
 You can also use sshfs-fuse to mount a remote file system
[14:51] <Tuxist> hi i'am testing pipewire 0.3 https://launchpad.net/~jan-koester/+archive/ubuntu/pipewiremaster but lxqt-panel chrashed with it https://pastebin.com/5Qg2UNQb
 @Tuxist [<Tuxist> hi i'am testing pipewire 0.3 https://launchpad.net/~jan-koester/+archiv …], I think better go directly upstream to lxqt and ask them.
 @RikMills can you explain `> - in debian control the Depends: sections have not been sorted and made a line per depend as in debian. This is a trivial difference, but IMO is a pointless delta to keep.`
 as you wrote in your comment
 (Photo, 1111x710) https://i.imgur.com/JFDOsAE.jpg
 @RikMills [<reply to image>], K. Understood
 same further down for depemds of Package: lxqt-config-l10n
 also, about the vcs part, I see you have the change highlighted there in the photo. But isn't the comaprison wrong? I am comparing between two ubuntu versions, one before merge(0.14.1-0ubuntu1) and other after merge(0.14.1-3ubuntu1). while you are comparing between 0.14.1(debian one) and 0.14.1-3ubuntu1(after merge)
 No, my comparison is correct as I am looking at the delta to debian you have after the merge
 To see if there is delta that is not needed, or unexplained
 In some parts like the debian/compat one, According to changelog, those changes are for 0.14.0 but shouldn't they be already there as we have 0.14.1 in our side?
 @The_LoudSpeaker [In some parts like the debian/compat one, According to changelog, those changes …], referring to the first 3 points of your comment
 @The_LoudSpeaker [also, about the vcs part, I see you have the change highlighted there in the pho …], in your comaprison, there will be some things highlighted which we already have in 0.14.1-0ubuntu1
 @The_LoudSpeaker [In some parts like the debian/compat one, According to changelog, those changes …], No, as no-one has merged with debian for a long time (well before that change)
 @The_LoudSpeaker [in your comaprison, there will be some things highlighted which we already have …], Just because it is highlighted does not mean it is wrong. It is highlighting the delta to debian. … In the case of the Vcs that delta is wanted in Ubuntu. The point is that no-where in your remaining changes did you mention it.
[18:06] <wxl> @kc2bez: re https://github.com/lxqt/lxqt-config/issues/445 do *WE* have a bug for this?
 @wxl [<wxl> @kc2bez: re https://github.com/lxqt/lxqt-config/issues/445 do *WE* have a …], good point. if there is, might want to add the LP bug to the changelog so it closes it.
[18:07] <wxl> @The_LoudSpeaker this time around are you trying to do the merge yourself or is this all trying to sync up phab?
 @wxl [<wxl> @The_LoudSpeaker this time around are you trying to do the merge yourself …], I am trying to merge myself
 @wxl [<wxl> @kc2bez: re https://github.com/lxqt/lxqt-config/issues/445 do *WE* have a …], I don't know but I vaguely remember that you and I were discussing it at some point.
 Maybe it was from discourse?
 @RikMills https://phab.lubuntu.me/D79#1705
[18:58] -lugito:#lubuntu-devel- [Needs Review] Merge from Ubuntu Merge-o-Matic: https://phab.lubuntu.me/D79#1705
[18:59] <wxl> @kc2bez: https://discourse.lubuntu.me/t/lubuntu-19-10-lxqt-cannot-change-keyboard-layout-shortcuts-not-working/507 ?
 @lugito [<lugito>  3[ Needs Review  3]  Merge from Ubuntu Merge-o-Matic:  2https://phab.l …], So you are not going to correct the debian/upstream/meta or investigate/explain why the lubuntu depends/suggests differ so much?
 @wxl [<wxl> @kc2bez: https://discourse.lubuntu.me/t/lubuntu-19-10-lxqt-cannot-change-k …], uff, I didn't follow up very well there. I think think that was what I was remembering.
 Since those were in previous version, I'd like to see what @tsimonq2 has to say about them. I will make the changes if needed.
 @RikMills [So you are not going to correct the debian/upstream/meta or investigate/explain …], ^
 @The_LoudSpeaker [^], rejecting then
 I will try merging again. After some reading.
 Thanks. I am being picky to try to help in the long run. :)
[19:18] <The_LoudSpeaker> As much as I understand, MoM merges upstream, debian and last ubuntu version into a post-merge-ubuntu version. When the merge is complete, it gets applied over last ubuntu version. correct? So why are we bothered about the differences between debain version and the post-merge-ubuntu version? The changes on our side should just reflect changes between last ubuntu version and the post-merge-ubuntu version.
[19:18] <The_LoudSpeaker> correct me if I am wrong anywhere.
[19:24] <The_LoudSpeaker> ^ @RikMills
 You are wrong because: … 'Remaining changes' means the difference between the debian version and your merged ubuntu version. IT DOES NOT mean the difference between the last ubuntu version and the new Ubuntu version as a normal changelog entry would. … It is important that it be this so that anyone doing another merge in the future,
[19:30] <wxl> @kc2bez can you follow up, make sure the patch works, and respond accordingly to the thread?
[19:35] <The_LoudSpeaker> @RikMills okay. Understood.
[19:36] <wxl> hey anyone want to help me sort through old bugs? e.g. https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta
[19:39] <wxl> so this popped up today which i've never seen before. anyways there might be some kernel changes we need to check out https://lists.ubuntu.com/archives/ubuntu-quality/2020-January/007184.html
 That caught my eye too, we should see who set that up
[19:41] <wxl> @tsimonq2 hey you so how's it going? you going to be joining us for 20.04? XD
 I'm uh, managing
 I keep a pulse on things, I just don't step in a lot of the time
[19:42] <wxl> well glad to hear you're still alive :)
 Barely XD
 qyestion is is that legit wxl
 question*
 *injects caffeine into Simon's veins*
 @teward001 [*injects caffeine into Simon's veins*], Hey if you're gonna do that, cure this cold I have
[19:44] <wxl> OH NO HE"S GOT CORONAVIRUS
[19:44] <wxl> ABI BREAK
[19:44] <wxl> ABI BREAK
[19:44] <wxl> ABI BREAK
[19:44] <The_LoudSpeaker> XD
 XD
 ack
 @wxl [<wxl> @kc2bez can you follow up, make sure the patch works, and respond accordin …], I will try to test that this weekend and reply.
[19:51] <wxl> danke
 sorry for dropping the ball.
[19:51] <wxl> oh no problem
[19:52] <wxl> i've caught a couple of those support things where they were autoclosed but still needed a response
[19:52] <wxl> if you want to generally take a look over those, that might be cool. ping me if anything needs help
 @tsimonq2 [Hey if you're gonna do that, cure this cold I have], i can't you has pootisvirus
 its incurable
[20:28] <wxl> can someone remind me what the deal is with https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1827501 ?
[20:28] <wxl> i think the difference with mate/us is because we're doing an encrypted /boot with cala, no?
 mate is different. grub is doing the unlocking for us. they are using lvm+luks. I think lvm does the unlocking for them.
 There is an upstream bug that should probably be tied in if it isn't already. https://github.com/calamares/calamares/issues/1203
[23:48] -lugito:#lubuntu-devel- [T104: Get translations going again] wxl (Walter Lapchynski) commented on the task: https://phab.lubuntu.me/T104#3078


 https://twitter.com/m_wimpress/status/1321422316568535043
 Hippo is here!
 What a hairy one.
 Hairy Hippo
 https://www.omgubuntu.co.uk/2020/10/ubuntu-21-04-development-open
 Hungry hippo would gave been better in my opinion. But maybe there is a trademark issue with that one.
 why hungry hippo...? (re @Swift110: Hungry hippo would gave been better in my opinion. But maybe there is a trademark issue with that one.)
 https://en.m.wikipedia.org/wiki/Hungry_Hungry_Hippos (re @Maik_aD: why hungry hippo...?)
 oh lol.... that has been ages ago, totally forgot about that game
 I used to love this game
 KEKW (re @Swift110: https://en.m.wikipedia.org/wiki/Hungry_Hungry_Hippos)
 I doubt it'll cause copyright issues
 Remember: OMG Ubuntu always jumps the gun
 HIRSUTE DEVELOPMENT HAS NOT OPENED YET. IT WILL BE OPEN WHEN A PACKAGE SUITE FOR IT GETS ADDED AT https://packages.ubuntu.com
 https://lists.ubuntu.com/archives/ubuntu-devel-announce/2020-October/001285.html (re @ItzSwirlz: HIRSUTE DEVELOPMENT HAS NOT OPENED YET. IT WILL BE OPEN WHEN A PACKAGE SUITE FOR IT GETS ADDED AT https://packages.ubuntu.com)
 Right.
 Technically it is; but you can't upload anything yet.
 You can to Launchpad though
[18:09] <luna_> it will open in an hour
 Do you really need to scream like that or can you show some more mature behaviour instead the next time. I for one would appreciate it. (re @ItzSwirlz: HIRSUTE DEVELOPMENT HAS NOT OPENED YET. IT WILL BE OPEN WHEN A PACKAGE SUITE FOR IT GETS ADDED AT https://packages.ubuntu.com)
 sorry, just a bad habit. I'm saying it more serious and notable to EVERYONE (re @Maik_aD: Do you really need to scream like that or can you show some more mature behaviour instead the next time. I for one would appreciate it.)
 Also this channel is logged so /shrug
[18:11] <luna_> sorry
 Do something about it and don't start to scream without even looking further or reading OMGUbuntu's article in which they linked to the mailing list announcement. ;) (re @ItzSwirlz: sorry, just a bad habit. I'm saying it more serious and notable to EVERYONE)
 🤣 (re @Maik_aD: Do something about it and don't start to scream without even looking further or reading OMGUbuntu's article in which they linked to the mailing list announcement. ;))
 Uploads to the main archive for hirsute have been possible since last Friday. Until now, they would get held in the unapproved queue, so only release team doing pre-opening uploads had things allowed in. (re @ItzSwirlz: Technically it is; but you can't upload anything yet.)
 not sure what's so funny about that (re @Swift110: 🤣)
 /shrug (re @RikMills: Uploads to the main archive for hirsute have been possible since last Friday. Until now, they would get held in the unapproved queue, so only release team doing pre-opening uploads had things allowed in.)
 A series getting added to that server has nothing to do with whether a release is open or not. It is a separate server for package info, that often lags in this things getting added (re @ItzSwirlz: HIRSUTE DEVELOPMENT HAS NOT OPENED YET. IT WILL BE OPEN WHEN A PACKAGE SUITE FOR IT GETS ADDED AT https://packages.ubuntu.com)
 I would just wait for packages.Ubuntu.com to be updated and tool chain
 ok ok sorry
 It's hilarious how you rip into people when they don't "behave". (re @Maik_aD: not sure what's so funny about that)
 Remember two wrongs don't make a right
 People, again. Logged channel.
 Ok. Obviously everyone here cares about what the current status of development and testing is. Sometimes people get it wrong, or read the wrong source. It happens :)
 Indeed it does. (re @RikMills: Ok. Obviously everyone here cares about what the current status of development and testing is. Sometimes people get it wrong, or read the wrong source. It happens :))
 Im still really disappointed that it wasnt named "hungry hippos". I have been waiting for this moment for years
 Lol
 rofl
 It is also disappointing we have to use the adjective rather than the animal in changelogs. hippo in those would be cool
[18:28] <valorie> lol
[18:30] <valorie> I can't wait for the animal image that Canonical does
 package (0.0.1) hippo; urgency=low (re @RikMills: It is also disappointing we have to use the adjective rather than the animal in changelogs. hippo in those would be cool)
 Lol, that seems so weird
 Yes, I was slightly surprised by the gorilla one (re @ubuntutesting_bot: [irc] <valorie> I can't wait for the animal image that Canonical does)
 Indeed (re @RikMills: Yes, I was slightly surprised by the gorilla one)
 Hoary hedgehog
 Indifferent ibis
[18:38] <valorie> we've always gone with the adjective and not the animal tho
[18:38] <valorie> oh well, it's just a code name


[11:17] <irgendwer4711> hi, how to put Firefox and Thunderbird on top of start menu again?
[11:19] <irgendwer4711> got it...
[12:09] <xu-irc84w> As a project on an uld laptop, Dell latitude C610 CPU speed 733Mhz with 256Mb RAM, I am trying to install and run a linux operating system.  To cut a very long story short, I can only install the mini version of Ubuntu 18.04.  It did install but it will not run, I gat as far as a page which say   Ubuntu 18.05  LTS Uuntu tty1 with ubuntu login
[12:09] <xu-irc84w> with flashing cursor on the next line.  The problem is that my keyboard and mouse are not responding.  How can I overcome this.  I am not very technically minded and can only think that increasing RAM, which can be done to 1GB might help.  What do you thtink?
[12:10] <xu-irc84w> BTW I will not be at my computer all the time so a reply might not be immediate, please be patient.
[12:16] <tomreyn> xu-irc84w: try one of those linux distros for old computers. xubuntu won't do well with those specifications.
[12:17] <tomreyn> if you want recommendations, ask in ##linux
[12:18] <diogenes_> xu-irc84w, antiX
[12:19] <diogenes_> try that ^
[12:22] <xu-irc84w> Sorry for the typing errors, I can spell quite well.  What is ##linux, is it another IRC page?   I may also have tried antiX but the specs were too high for this laptop.  BTW the laptop fired up after about 11 years of inactivity.
[12:23] <xu-irc84w> Off to the gym now to try and cool my brain lol.
[12:52] <tomreyn> xu-irc84w: ##linux is another IRC channel on this "Freenode" IRC network you're connected to. you can access it by typing, at the start of a line, without leading spaces: /join ##linux
[14:48] <xu-irc84w> :/join##linux
[15:16] <urehie> Hi! I have a problem with setting up the dual display in Xfce4 (Xubuntu 20). I cannot find clear instructions for this. My TV is plugged with HDMI.
[16:24] <aliakbar> Hi
[16:24] <aliakbar> I seem to have an issue with GTK Inspector on my XFCE Panel
[16:25] <aliakbar> When I issue the command "GTK_DEBUG=interactive xfce4-panel
[16:25] <aliakbar> " I get the following
[16:25] <aliakbar> (xfce4-panel:3069): xfce4-panel-CRITICAL **: 20:52:15.460: Name org.xfce.Panel lost on the message dbus, exiting.
[21:24] <irgendwer4711> hi, after updating to 21.04 plus and minus on keypad does not work any more for gthumb
[21:27] <irgendwer4711> got it, I had to reassign the keys.


[15:13] <whyzzyrd> afternoon. I'm having fun trying to configure an IR remote using the mythbuntu control centre. Is there any way to make it turn on remote support (so it works) without it overwriting the working lirc config I have? The IR is on a diskless frontend/slave backend.
[15:16] <whyzzyrd> I have the IR from an avermedia 761 (bttv ir) set up as devinput, using rc_keymaps and have keypresses successfully coming through from irw, have run mythbuntu-lirc-generator, have restarted the frontend, but have nothing happening in the frontend gui
[15:24] <whyzzyrd> actually, never mind. I've got to work out how to make keypresses context-specific in the lircrc
[15:25] <whyzzyrd> play stop etc work, but the arrow keys are shared with the number keys.
[20:00] <kth> hi - can anyone tell me how to disable auto restart of mythfrontend in case of kill/error ?
[20:13] <Seeker`> anyone tried the NOVA-HD-USB2 with mythtv? (Its a USB box that can recieve DVB-S2
[20:14] <kth> solved thanks


[00:04] <user392> Hi. A problem happened during the last update. A new kernel package is available, but it didn't install because update-initramfs failed
[00:04] <user392> I'm on Xubuntu 20.04
[00:06] <user392> It seems to be a bug. This is the tail log of the update process: https://pastebin.com/VBHgLgEv
[00:13] <Bashing-om> user392: This report: https://answers.launchpad.net/ubuntu/+question/689181 yours ?
[00:16] <Bashing-om> Info linux-image-generic focal
[00:17] <Bashing-om> !Info linux-image-generic focal
[00:17] <Bashing-om> !info linux-image-generic focal
[00:19] <Bashing-om> user392: Show the channel ' dpkg -l | grep linux- ' in a pastebin , see what might be missing.
[00:20] <user392> No. it is not mine.
[00:20] <Bashing-om> user392: Then we may have a real update bug !
[00:21] <user392> https://pastebin.com/9ecBTc25
[00:21] <user392> It seems so. Well, such is life on the edge.
[00:24] <Bashing-om> user392: Appears the kernel is fully installed - but just as a check - what shows ' df -h ' ?
[00:25] <user392> https://pastebin.com/kmZt7gCU
[00:28] <user392> I don't like the line
[00:28] <user392> /dev/loop3                   45M   45M     0 100% /snap/gtk-common-themes/1440
[00:29] <Bashing-om> user392: Also not a disk space issue, Snaps are confined and will be at 100%.
[00:30] <user392> I don't like it because the failure was in
[00:30] <user392> cp: cannot create regular file '/var/tmp/mkinitramfs_Qnycxn/usr/share/plymouth/themes/spinner/watermark.png': No such file or directory
[00:31] <user392> I'm doing a couple of things that shouldn't be
[00:32] <user392> The first are two packages related to gimp which I installed from 19.10, but I remove them before the upgrade
[00:32] <user392> The other is something about Wine, but that doesn't relate to the kernel
[00:35] <Bashing-om> user392: I will bow to others greater experience here - but looks to me like what we have is a race condition in that the file "watermark.png" has not been created in time. But way over my skilll set !
[00:36] <user392> It should be fixed soon. I am going to hold the packages with the old kernels, just in case
[00:39] <Bashing-om> user392: Also in the mean time add your self to that ups bug report to increase the heat to gain developer attention.
[00:41] <user392> Today is Friday, it will get on fire at Monday.
[00:41] <user392> Let's see...
[00:59] <user392> https://bugs.launchpad.net/ubuntu/+bug/1866425
[00:59] <user392> Done
[01:00] <Bashing-om> thanks :)
[01:24] <Haxxa> Hi Guys, How easy is it to downgrade from 20.04 to 18.04.3?
[01:31] <guiverc> Haxxa, upgrade tools are designed to automatically go to later packages, backwards is manual so no its not easy.
[01:32] <guiverc> (also 18.04.4 is the latest 18.04)
[01:32] <Bashing-om> Haxxa: There is no go-back button, The better course is a fresh clean install.
[01:32] <guiverc> or restore backups (why we have them)
[01:35] <Haxxa> lets say I by mistake upgraded a production machine which was meant to be a test vm and have no backups, and one of the repos is only available for 18.04 just a hypothetical ofc :| .
[01:36] <guiverc> Re-install using something-else/manual-partitioning and using existing partitions (ensuring you don't format) is the easiest solution; it'll note your packages, erase system dirs (so you need to restore apps that store data there, no desktop app should but server apps can), install, add back your additional packages then ask to reboot. No user files are touched (really great for desktop boxes; some server stuff will need restore)
[01:57] <Captain_Proton> Ubuntu Focal Fossa   Gnome 3.35.1 unable to open extensions settings, try both tweaks and gnome extensions web site
[02:22] <user392> Bashing-om: someone marked the bug as a duplicate, and there, a workaround was available; it fixed the issue.
[02:26] <Bashing-om> user392: looking :D
[02:33] <Bashing-om> user392: \o/ passed on to other affected too :D
[02:34] <user392> Of course
[02:45] <nt0> how's 20.04 for tinkering around?  i'm planning on creating a new VM to test out the linux version of matlab and also want to see how 20.04 looks.  don't care about rock-solid or doing any serious work.  so long as its stable enough to play around with as a casual user i'm good go go.  thoughts?
[03:17] <guiverc> nt0, i release-upgraded this box back in 2019-Oct and between then and now I've had few issues but it'll vary on what you do, what you use, and your hardware..
[03:22] <nt0> guiverc: that sounds good enough for me.  first gen ryzen and will be running in qemu/kvm.  so long as it works for the most part i'll be fine.  just want to test out MATLAB and play around a bit.
[03:23] <nt0> guiverc: thanks.
[14:41] <evils> repost from #ubuntu
[14:41] <evils> i'm having a display/graphics issue on 20.04, in chromium and firefox, after closing a menu, that area doesn't redraw correctly (mixed remnants of the menu remain, even when moving the mouse over them, sometimes flickers), resizing the window fixes it, seems to happen on X and wayland; this is on a ryzen 3400g (integrated graphics)
[14:41] <evils> takov751: you said something about the composer, can you expand on that?
[14:43] <takov751> compositor
[14:43] <evils> isn't that wayland specific?
[14:45] <takov751> if i recall correctly by default the gnome compositor is mutter.
[14:46] <takov751> But i haven't seen any settings that might be helpfull
[14:47] <evils> i don't suppose this is a replaceable component?
[15:15] <evils> i suppose i could try i3/sway, but it's not my machine, and it's in use...
[18:15] <otyugh> Hey there ; got a graphical problem (graphical glitches, artefacts) with an old PC under the latest ubuntu20, while having no issue using ubuntu18.04 ; I tried to use the kernel from 18.04 in ubuntu20, but got stuck on loading initramfs.
[18:15] <otyugh> Any idea why ?
[18:16] <otyugh> Under debian I could use a kernel from stretch in debian buster as if it was nothing ; what did change in Ubuntu so it's not possible anymore ?
[18:18] <takov751> otyugh: this is a new bug presumebly . If the build fails with the message  plymouth spinner theme watermark.png  can not be found while building
[18:18] <otyugh> takov751: well it goes stuck even when launching removing "splash" and adding "nomodeset"
[18:18] <otyugh> Ahm
[18:18] <otyugh> maybe uninstalling plymouth then ?
[18:19] <takov751> there is a dirty whttps://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1866372
[18:19] <otyugh> Argh
[18:20] <otyugh> takov751: update-initramfs didn't show any error though
[18:20] <takov751> whats your output when apt fails
[18:20] <takov751> ?
[18:21] <otyugh> apt does not fail
[18:21] <otyugh> The problem is at actually booting on the 3.4 kernel (If i remember correctly)
[18:22] <takov751> 3.4 is really old kernel
[18:22] <otyugh> Amh
[18:22] <otyugh> Maybe I'm not remembering staight
[18:22] <otyugh> I'll check
[18:22] <otyugh> It's the main 18.04 kernel version
[18:22] <otyugh> 5.4 ?
[18:22] <otyugh> Arh, gonna check
[18:24] <takov751> right so you have run a full-upgrade and error still there
[18:25] <otyugh> ...Now you mention it, I only did an apt upgrade
[18:26] <otyugh> What I did is simple : added the 18.04 source, installed the linux-image from there and header package, and rebooted on it, found an error, got stuck :o
[18:32] <takov751> why did you wanted to use the older kernel?
[18:34] <takov751> yelp he left


[00:57] <sambagirl> hi is lubuntu using gnome desktop? secondly is it still closely similar to 10.04 - 10.10 interface?
[00:57] <Unit193> The "L" in Lubuntu is for LXDE.
[01:01] <Unit193> As far as looking like 10.x: http://www.chrishaney.com/?linux&release=Lubuntu%2012.10
[01:02] <sambagirl> ohh
[01:03] <sambagirl> i need a uppper and lower panel that i can manipulate primarily
[01:04] <sambagirl> i've  been working for the last few days with a new os ultimate edition 3.5 based off precise but it's so out of control i cant do nothing with it and therei is zero support for it. so i have to move on
[02:27] <Ahmuck> sambagirl: what type of panel
[02:28] <Ahmuck> i need help with my mouse laptop pad.  i need to turn off the pad as it is getting in the way
[02:28] <sambagirl> to tell you the truth i don't even know anymore. :)
[02:33] <Ahmuck> sambagirl: what r u trying 2 do
[02:45] <sambagirl> i'm trying to maintain familiarity and by that i mean to have what gnome offered in 10.10/10.04 with top and bottom panels where you could add familiar applets that were functional and useful.
[02:46] <sambagirl> i haev on one laptop something called ultimate edition and it offers like 15 different desktops you can choose from. it's so messy i'm sick of it. but it gives you a chance to see everything you dont want to see on a regular basis.
[02:46] <sambagirl> i have tried the lxfe for lubuntu and it's complicated to manipulate when your used to gnome 2
[02:53] <Unit193> Simply because if you're expecting Gnome2, it's just not it, same with Xfce and Gnome2.
[02:54] <sambagirl> yeah
[02:55] <Unit193> If you're looking for something that has top and bottom by *default*, I think Unity kind of does, and Xubu.
[02:55] <Unit193> Did you try mate on whatever makes that?
[02:55] <sambagirl> xubu
[02:55] <sambagirl> unity makes me want to vomit
[02:55] <sambagirl> that is why i didnt use anything after 10.10 cause it had that unity
[02:56] <sambagirl> it's almost as awful as windows 8
[02:56] <Unit193> Xubuntu == Xubu.
[02:56] <sambagirl> ohh
[02:56] <Ahmuck> u can do this in lubuntu
[02:56] <Ahmuck> u can add a bar at the top and bottom and icons
[02:56] <Ahmuck> this is what i do
[02:57] <sambagirl> oh really
[02:57] <Unit193> So that's simple, Unity is out of the question.  You may be able to do that with lxpandl, and even if not there are other panels.  Tint2 is one good non-default.
[02:57] <sambagirl> they have lubuntu interface on this edition thingy and i had a chance to look at it.
[02:57] <Ahmuck> right click on the current bar and "create new panel"
[02:57] <sambagirl> brb and thanks i am looking online now
[02:57] <Unit193> Check the LXDE wiki.
[02:57]  * Ahmuck bumps sambagirl
[02:58] <Ahmuck> d@#$@#$ mouse
[02:58] <sambagirl> yes?
[02:58] <sambagirl> ok
[02:58] <Ahmuck> i can step you through it
[02:58] <sambagirl> also i would know that compiz works.
[02:58] <sambagirl> ok i have to cook at the momenet brb
[02:58] <Ahmuck> that i can't help you with
[02:58] <Ahmuck> mmm, what r u fixin
[02:59] <Unit193> sambagirl: http://lubuntublog.blogspot.com/search/label/eyecandy
[13:51] <smurfslover> hi there, first time user for lubuntu can someone point me in the right direction to install ati proprietary driver?
 in lubuntu  i try to open Unetbootin by right click and select the "run as program" but it is not there, helP?
[19:52] <holstein> kristoffer: in what os?
[19:52] <bioterror> sudo apt-get install unetbootin
[19:52] <bioterror> gksudo unetbootin
[19:52] <bioterror> usually unetbootin also asks password when run from the menu
[19:53] <kristoffer> holstein Lubuntu...
[19:53] <holstein> kristoffer: then enjoy bioterror 's excellent response
[19:54] <kristoffer> ok installing ii dident know it could be installed through terminal i always downloaded the file from website xd
[19:54] <bioterror> but unetbootin is hardly needed nowdays, unles you really really want to make a persistent usb pendrive
[19:54] <bioterror> !apt | kristoffer
[19:54] <bioterror> kristoffer, read, please
[20:00] <kristoffer> is there anything else i can use instead of unetbootin its freezez at  4% i also had that problem before
[20:01] <kristoffer> nvm it dident freeze anyway
[21:22] <intelgma> hi, i really need some help with onboard intel gma 3100 graphics (q35 chipset): playing videos in fullscreen (mplayer/gmplayer) just does not work correctly. i can either get fullscreen with audio/video getting more and more out of sync (with -vo gl) or using the default settings and the player will hang after a few settings, leaving the system unresponsive for some time.
[21:24] <intelgma> so far i tried updating the whole system, updating mplayer to a very recent version via repository, lubuntu 12.04/12.10 in i386 and amd64, linux mint but everywhere the same
[21:26] <intelgma> i know it does work, because i had it working some days ago but had to reinstall the whole system. now i don't know where to check. it has to be software related
[21:27] <bioterror> nothing new in launchpad
[21:28] <intelgma> is there some packet for intel onboard graphics that i am missing? xorg.log has no errors, dri is supposed to be enabled
[21:28] <bioterror> what if you use VLC
[21:28] <bioterror> does it work?
[21:29] <intelgma> will try that
[21:34] <intelgma> vlc plays some files with video okay, so it seems, but the audio is terribly distorted. other files that mplayer does play with a/v out of sync let's vlc hang or crash
[21:35] <bioterror> you're 100% sure your videos are okay? :D
[21:36] <intelgma> at first i thought it's the kernel, but after trying 2.6.xx, 3.2.xx,3.5.xx,3.6.xx i don't know where to look
[21:36] <intelgma> and yes, the files were playing fine before :)
[21:39] <intelgma> funny thing is: flash works fullscreen
[21:40] <Slayback> hi this is the secound time i install Lubuntu 12.04 today, after the first install wifi worked and after another restart the wifi wouldent work anymore, when turning on wifi by pressing Fn and wifi key it said only Dissconnected, i just reinstalled and this is the first time boot, is there anything i can do if the wifi wont work again after a secound reboot??
[21:41] <intelgma> ... i just downloaded some new files. they seem to be okay!
[21:42] <intelgma> and even the old ones are fine now .... what did vlc install that mplayer requires?
[21:42] <intelgma> i can't believe that
[21:42] <bioterror> Slayback, hard to say atm.
[21:43] <bioterror> Slayback, ifconfig, ifconfig device up
[21:43] <bioterror> maybe you might need to give rfkill
[21:43] <bioterror> who knows
[21:44] <Slayback> the wifi button was there the when the first install dident work after secound boot, but there was no connections showing and just said "Wired network dissconeccted"
[21:47] <intelgma> okay, no i am totally lost. all of a sudden both mplayer and vlc play any file just fine!
[21:47] <intelgma> and all after vlc hang/crashed on me
[22:41] <gajbooks> Is there any way to have Lubuntu (or any linux) use the pagefile for written things and temporary storage of read things until the system shuts down? Then it would write things to the disk?
[22:42] <gajbooks> I'm running Lubuntu off of a terrible slow USB 1.1 and I want things to have a cache on my faster firewire drive. (Computer doesn't boot from Firewire so I can't just do that)
[22:45] <intelgma> gajbooks: you could even use a ramdisk to do that
[22:46] <bioterror> he could install lubuntu on that firewire drive and use usb pendrive as a boot loader?
[22:47] <intelgma> even better
[22:48] <gajbooks> I also don't want to format the drive, so I'll try ramdisk.
[22:48] <gajbooks> How would one use a ram disk for that?
[22:51] <intelgma> http://www.tremende.com/ramlog/ this is an easy installation, but only for /var/log, IIRC.
[22:52] <intelgma> what kind of data are we talking about?
[22:56] <gajbooks> Anything the OS or a program wants.
[22:56] <intelgma> mount -t tmpfs -o size=300M tmpfs /path/to/ramdisk
[22:57] <intelgma> but you would have to point all the possible save-destinations to that path
[23:02] <intelgma> a good start would be to symlink /tmp to that dir, possibly /var/tmp and /var/log as well, like: mkdir /mnt/ramdisk/{tmp,var/log,var/tmp} && mount --bind /tmp /mnt/ramdisk/tmp
[23:02] <intelgma> and so on
[23:03] <intelgma> wait, that should probably be mount --move olddir newdir
[23:05] <intelgma> no, that applies to mountpoints only


[08:23] <FourDollars> Hi, I would like to make a patch for systemd on cosmic. Which branch should I target on? ubuntu/cosmic-proposed, ubuntu/cosmic-devel, applied/ubuntu/cosmic-devel, or applied/ubuntu/cosmic-proposed?
[08:23] <FourDollars> Regarding https://code.launchpad.net/ubuntu/+source/systemd
[10:18] <juliank> FourDollars: I think you want to submit a merge proposal against https://code.launchpad.net/~ubuntu-core-dev/+git/systemd/+ref/ubuntu-cosmic or just open a bug with a patch
[10:19] <juliank> the importer repo is not really being used
[10:22] <KOLANICH> Hello everybody. Can I speak to someone responsible for maintaining package archives?
[10:29] <KOLANICH> I see I can't. So, here is the question: could you start providing delta debs? https://wiki.debian.org/Teams/Dpkg/Spec/DeltaDebs not debdelta, but delta debs, another format. Because some users are unhappy that to update firefox they have to download whole package. I gjess keeping the deltas between 2 latest versions is enough.
[10:30] <juliank> Oh, KOLANICH
[10:30] <juliank> that was weird
[10:32]  * Laney smells a juliank sockpuppet :P
[10:34] <FourDollars> juliank: I would like to open a bug and append a patch or just make a merge proposal.
[10:34] <juliank> Laney: that does not seem very effective, but I'm happy to hear user interest
[10:34] <juliank> FourDollars: Well then, do it
[10:40] <FourDollars> juliank: ok thx
[11:57] <ahasenack> tjaalton: hey, I noticed the openldap package has a debian/tests directory with some scripts in it, but no debian/tests/control, do you know when those are run?
[11:58] <ahasenack> I don't see openldap listed in http://autopkgtest.ubuntu.com/testlist#index-o either
[12:12] <tjaalton> ahasenack: no idea..
[12:14] <tjaalton> ahasenack: looks like they just happen to share the same directory as autopkgtests
[12:16] <tjaalton> those haven't been touched since 2008
[13:31] <elektromacumba> hello, i'm under ubuntu 18.04.1 x86 and i'd like to customixe my initrd.img.*, but it's not in the usual format like in x64 version, the "file" command say "ASCII cpio archive (SVR4 with no CRC)" instead of classic gzip/cpio format. there is a way to unpack and customize it?
[13:41] <coreycb> sil2100: would you be able to review the bionic upload for bug 1778771 ?
[15:01] <rbasak> !dmb-ping
[15:45] <balsaq> i noticed ubuntu does not fully uninstall packages when you ask it to do so leaving bits of useless files in the filesystem
[15:46] <balsaq> the ubuntu software center should fully remove the package when the operator presses the remove button
[15:47] <TJ-> balsaq: give an example please
[15:47] <TJ-> balsaq: "remove" does not touch config files or files altered by the system administrator
[15:47] <wxl> ^^ yeah, you need to purge
[15:48] <balsaq> i noticed that , but i am saying there is no reason why u should have to do extra work to remove a package
[15:48] <balsaq> when u press "remove" it should remove, purge clean or any other step u might need.
[15:48] <wxl> you just need to use the right command and you won't have to
[15:49] <balsaq> i know that too thanks
[15:49] <TJ-> balsaq: no, the idea of "remove" is to keep config files in case the package is re-installed later
[15:49] <balsaq> but there is no reason to make things with extra work for no good reason
[15:49] <TJ-> balsaq: and the tools try to err on the side of caution
[15:49] <balsaq> tj - pardon me  but that is not a good reason
[15:49] <TJ-> balsaq: it is THE reason
[15:50] <xnox> balsaq, use $ apt purge foo  or $ apt remove --purge foo
[15:50] <balsaq> makes noi sense , because if  u want the package back it will put all thos files back
[15:50] <rbasak> Unfortunately "remove" or "uninstall" is a bit vague. Different people have different expectations about what that means. For example, if you remove a database package, do you expect the database to be destroyed? As TJ- says, it's erring on the side of caution.
[15:50] <rbasak> The same applies to local configuration customisations
[15:50] <rbasak> Which is why configuration files are left.
[15:50] <wxl> this is not new behavior............. not by any stretch of the imagination
[15:50] <rbasak> They are typically tiny anyway. Do you have a specific problem when they aren't removed?
[15:50] <balsaq> yes i do
[15:50] <xnox> balsaq, there a few false positives, as currently .postrm scripts cannot declare that they are in-fact no-ops for purge, and thus packages get stuck in rc state, despite being clean on the system.
[15:51] <balsaq> the problem i just told my OS to remove something and it did not do it comletely that is the problem
[15:51] <rbasak> That's not a problem.
[15:51] <wxl> it did exactly what you told it to do
[15:51] <balsaq> it took the head off and left all the guts laying around
[15:52] <wxl> no, it did an `apt-get remove`
[15:52] <balsaq> 99 percent of the time when i person shoosed to remove the software thats exactly what they want
[15:52] <rbasak> We know what it did, but I don't think you're going to get anyone to accept on this channel that it's actually a problem or that the behaviour should be different unless you can give us an actual broken use case.
[15:52] <balsaq> i realize it is not a broken system
[15:52] <rbasak> Please keep in mind that for every person who comes in asking the same thing as you, there are others who expect the complete opposite.
[15:53] <balsaq> but when you do something you may aas well do it right
[15:53] <rbasak> There will be someone who lost a database without expecting the system to do that, for example.
[15:53] <wxl> in fact, there are many more
[15:53] <rbasak> Ultimately the project has to make a decision on what the default behaviour should be for all users.
[15:53] <cjwatson> Can you take this to the bug tracker please?  There's at least an argument that it should be possible to purge packages easily in the Software UI app (although I agree with others here that it's best for it not to be the default removal action, as it's irreversible)
[15:53] <cjwatson> (There may well be a bug for this already - I haven't checked)
[15:53] <wxl> if a user knows nothing, assuming complete purging is a terrible assumption
[15:54] <balsaq> yes cjwatson thank you for that...i dont think it is a bug its just a bit of laziness
[15:54] <wxl> while doing the opposite has no critical effect at all
[15:54] <cjwatson> The bug tracker is where this sort of thing is tracked.
[15:55] <rbasak> If you want the default to be changed, you're going to have to come up with a more compelling reason than "I disagree". There's also little point in arguing for the known cons that were already taken into account when the decision was originally made.
[15:55] <balsaq> it could be developed like this instead:  when the operator presses REMOVE   a  pop up occurs   "do you want to remove this package completely" ?
[15:55] <cjwatson> -> bug tracker
[15:55] <cjwatson> IRC is not a bug reporting mechanism
[15:55] <cjwatson> Anything here will be lost, unless you happen to get lucky and the specific people responsible for the program in question happen to be around
[15:56] <wxl> i agree. this should go to the bug tracker. if a sound argument can be made there, i'm sure it could get resolved.
[15:56] <balsaq> ok if you think so could one of you with experience please report the bug
[15:56] <cjwatson> No, bugs should be reported by the person experiencing the problem
[15:56] <wxl> you have the direct experience with the "problem"
[15:57] <balsaq> well the simply install a snap package and then remove it and whoala you will be the man
[15:57] <cjwatson> Use "ubuntu-bug /path/to/whatever/software/app/you/are/using"
[15:57] <cjwatson> Haha you didn't even mention snaps earlier
[15:57] <cjwatson> The entire discussion above is predicated on the assumption that you were talking about debs
[15:58] <balsaq> well i  have a feeling this will happen using the software center no matter what
[15:58] <cjwatson> No details -> terrible discussion
[15:58] <balsaq> sorry but it came from the software center just as i said
[15:58] <cjwatson> Removing a .deb removes everything except a tiny number of config files
[15:58] <balsaq> all i am saying is if an OP installs from software center and removes from software center it should do it
[15:59] <rbasak> balsaq: I suggest you read: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html - then you might understand our perspective better.
[15:59] <cjwatson> Removing a snap, I don't honestly remember
[15:59] <wxl> beat me to it rbasak!!!
[15:59] <wxl> i literally had that in the clipboard
[16:00] <wxl> tbh i don't know about snaps either. that's something worth exploring at the very least. you should file a bug.
[16:00] <balsaq> i am saying that when a person removes any pkg from software center he should have the choice to fully remove it right at that moment no matter if it snap or deb thats all i meant
[16:01] <wxl> then write a bug report
[16:01] <cjwatson> You need to take this to the bug tracker, since as far as I know none of the people answering here work specifically on the software center UI.
[16:01] <rbasak> If you're not prepared to sort out a bug report that explains what you mean and provides a place where we can clarify details, track progress and make decisions, then what you're saying will be politely ignored.
[16:01] <sladen> balsaq: please repeat the process.  Taking a screenshot before, and after, after every step (eg. every mouse) click.  And attach all of these to a bug report
[16:02] <balsaq> i couldnt possibly explain any better
[16:02] <sladen> balsaq: (as politely as it can be said) at the moment, we haven't got *a clue* about the background, nor the details necessary to even start to look into this
[16:02] <balsaq> ok
[16:02] <balsaq> thanks
[16:02] <cjwatson> Also, the implementation of the software center has changed radically between different versions of Ubuntu, and you haven't mentioned which you are using; a bug report is a good place to capture this.  The ubuntu-bug program can help you file it.
[16:04] <balsaq> i am using the most current one i installed it clean yesterday  it is the lated LT 18 10 ubuntu desktop
[16:04] <wxl> bug tracker
[16:04] <cjwatson> I'm not asking you to tell us here :)
[16:04] <balsaq> oh ok
[16:04] <balsaq> sorry
[16:04] <cjwatson> One of the points of ubuntu-bug is to gather this sort of information automatically so that people don't have to play twenty questions on IRC
[16:19] <equinox> hi all... what's the policy/pattern used for the "-0ubuntu0.18.04" suffixes on package versions? (upstream maintainer working on packaging here)
[16:22] <cjwatson> equinox: As an upstream, you wouldn't normally use that kind of security-update versioning, though it depends slightly on the situation; that comes from https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[16:22] <equinox> cjwatson: i need to use /some/ suffix because the shlibs:Depends are different between 16.04 and 18.04 (libjson-c2 vs. libjson-c3)
[16:23] <cjwatson> Oh, well if you're maintaining for multiple series then pretending they're security updates or similar and using the scheme from the wiki page above is reasonable enough
[16:24] <cjwatson> This is presumably in a PPA or similar so you really just need to make sure that the version for the newer series is consistently >= the version in the older series so that upgrades are sensible
[16:24] <equinox> we're actually maintaining back to 12.04 on older branches :D
[16:24] <equinox> yeah
[16:25] <equinox> (how would this work if the package was upstreamed and still needed the suffixes because the build result is slightly different between ubuntu releases?)
[16:32] <cjwatson> It'd effectively be a downstream microbranch to do the backport
[16:33] <cjwatson> Or somebody upstream would continue maintaining a PPA or whatever
[16:33] <cjwatson> Packages in Ubuntu proper don't in general keep rolling to new versions in older series
[16:35] <equinox> true... though if ubuntu rolls over to a new release while our package doesn't, there's again a situation where the same source version ends up with different build output due to shlib version differences
[16:45] <xnox> equinox, we do not rebuild binaries.... each versioned binary is only compiled once, and is copied up. explicit uploads are required for rebuilds.
[16:46] <xnox> ah, but you figured that, hence your question, never mind me
[17:01] <balsaq> ok i have a ubuntu one account
[17:19] <balsaq> wow launchpad timed out after all thiws work thus it didnot sully take my bug report
[17:19] <balsaq> sheeesh
[17:19] <cjwatson> you should be able to go back and try again
[17:20] <cjwatson> it shouldn't have lost the text
[17:22] <balsaq> well i can tell some went thru becasue i saw a note in there that said "simliar problemreported before"
[17:23] <balsaq> apparantly noone knows how to integrte the purge command with the remove button in gnome-software
[17:25] <balsaq> but im glad i have the ubuntu one now i see bugs all the time
[17:29] <balsaq> in fact yesterday my icons from my icon launcher were "sticking" to my mouse pointer on screen as if they were magnetized...was very annoying on a fresh clean installation of ubuntu 18 10.
[17:30] <balsaq> for some reaon it seems to have stopped now...


[12:03] <codfection> knome, thanks for replying, yes I would to contribute in development (coding) area
[12:03] <codfection> like*
[13:11] <knome> codfection, have you read this? http://xubuntu.org/contribute/development/
[13:11] <knome> codfection, i know it's a bit scarce, but it gives an idea what we're ding
[13:11] <knome> *doing
[13:12] <knome> codfection, and you'll likely want to be in touch with bluesabre, ochosi and/or Unit193 - they can help you forward with development stuff
[13:13] <knome> or krytarik, whose client is not here right now
[14:26] <codfection> thanks a lot knome
[14:35] <knome> no worries
[14:35] <knome> and if you have any general questions, feel free to ask here
[14:36] <knome> and specific questions too - other people than those that i mentioned might be able to help as well
[14:36] <knome> (me included)
[17:31] <flocculant> knome: hopefully we'll get dates on burndown, release schedule had dates so I added them to roadmap
[19:45] <knome> flocculant, yes, that'll do it - thanks
[19:45] <flocculant> cool
[20:07] <flocculant> knome: though it doesn't - updated a short bit ago - does the tracker look for topic-foo-xubuntu - cos if so you called z xubuntu-z-roadmap, there being no topic-z
[20:11] <knome> no
[20:11] <knome> it looks for the umbrella blueprint
[20:11] <knome> which is set to xubuntu-z-roadmap (you can figure that out because it actually loads all the stuff)
[20:11] <knome> it just doesn't look at the blueprints all the time
[20:12] <knome> i don't remember how scarcely it checks this - it might be once a day or once a week
[20:13] <knome> this is the main reason i'd like to steer away from using blueprints as the source - if we had all the information in an internal database, we wouldn't need to do "expensive" API calls
[20:13] <knome> or figure out when we need to do the calls..
[20:25] <flocculant> so why not do it when the cache updates?
[20:25] <knome> because we have no idea when the launchpad cache updates
[20:25] <knome> that's the problem
[20:26] <flocculant> mmm
[20:26] <flocculant> obviously not making sense here :)
[20:26] <knome> probably not ;)
[20:26] <flocculant> Work item data from Launchpad. The cache was last updated at Mon, 28 Nov 2016 20:00:12 +0000.
[20:26] <knome> right.
[20:26] <flocculant> it says
[20:26] <knome> that's the work items cache
[20:26] <knome> that's updated hourly
[20:26] <knome> ...but it's a different API call
[20:27] <flocculant> right - so why not check that different call?
[20:27] <knome> because it "costs"
[20:27] <flocculant> who?
[20:27] <knome> time
[20:27] <knome> and processing power
[20:28] <flocculant> of something owned by canonical?
[20:28] <knome> so if we did that hourly, then the site would be sluggish hourly
[20:28] <knome> something paid by canonical, but that's not the point
[20:28] <flocculant> do it less often then
[20:28] <knome> ...i am ;)
[20:28] <ochosi> codfection: hey! if you need any pointers lemme know. best starting place is usually a small bug that annoys you and that you are consequently motivated to fix. anyway, feel free to get in touch
[20:28] <flocculant> just more often than it is at the moment :p
[20:28] <knome> hah
[20:29] <knome> well, i'd rather just make the switch to internally-managed stuff
[20:29] <knome> there is some code for that ready, but time has been scarce
[20:29] <flocculant> and how do you intend to manage internally - and how will it work with lp stuff it needs to read?
[20:29] <knome> anyway, it just doesn't make sense to check something more than once a day that changes maybe twice a cycle
[20:29] <flocculant> like bugs for instance
[20:30] <knome> those will still be updated with cronjobs, but at least then there's less to update
[20:30] <knome> and since at that point we need some authorization, we can let authorized people press a button that updates the bug on request
[20:30] <knome> authorized probably bound to ~xubuntu-team
[20:31] <flocculant> so - more work for people so that machines don't need to?
[20:31] <knome> nope.
[20:31] <knome> the same work - you need to add the work items to launchpad now
[20:31] <knome> in the future, you'd just add them to the tracker
[20:31] <flocculant> anyway
[20:32] <flocculant> this is probably something that the team should have some input on
[20:32] <flocculant> personally I don't see a gain :)
[20:33] <flocculant> I really don't see the point I guess :)
[20:33] <knome> i don't understand why the team would be opposed to something that makes things work more smoothly
[20:33] <flocculant> not sure how this makes it more smooth?
[20:33] <knome> for example, the dates on the burndown would be updated instantly
[20:34] <flocculant> well
[20:34] <knome> and there could be a more user-friendly form to add the dates
[20:34] <knome> and the work items
[20:34] <knome> etc.
[20:34] <knome> (and tbh that's what i'm going to do)
[20:34] <flocculant> well whatever
[20:35] <flocculant> obviously my input is wasted as you appear to have made up your mind that we'll change something again
[20:35] <knome> it's not whatever - i see what you're saying, and i can see that it's hard to see how things could be better, but i know
[20:35] <flocculant> the tracker is awesome
[20:36] <flocculant> love it - actually makes something easier
[20:36] <knome> people in the team have agreed for a long time that launchpad is slow etc. - not only related to the tracker-related thigns - so why not steer away from it?
[20:37] <knome> again, the process to add work items and dates and whatever would be very similar - but everything would be handled internally in the tracker
[20:37] <flocculant> yea
[20:37] <knome> eg. no more work for you, but you get benefits
[20:37] <flocculant> I'd love to know how re-inventing the wheel here AND linking to lp bugs is going to work
[20:38] <knome> we're not reinventing the wheel
[20:38] <flocculant> yes you are
[20:38] <knome> the launchpad work items feature is not really a work items feature
[20:38] <knome> it's a text box you can edit
[20:38] <knome> all the work item handling stuff is done by our tracker and the ubuntu tracker
[20:38] <flocculant> that's one small facet of it isn't it
[20:39] <flocculant> if the bug bp works like it does now - then that's my only argument :)
[20:40] <knome> in the first stage of the migration, probably so
[20:40] <flocculant> if your argument is based on making canonical infrastructure work more - then I don't care about that :)
[20:40] <knome> the biggest problem with launchpad managing the work items data is that it doesn't make a difference between the different work items
[20:40] <flocculant> first stage?
[20:41] <knome> what that means is that once it's "validated" that the user and work item status is an approved user/state, it's just text
[20:41] <flocculant> is this actually written down anywhere for team to read?
[20:41] <knome> so we have no way to track what happens to that exact work item
[20:41] <knome> so we have to load and parse all of the data again and again
[20:42] <knome> no, but so far nobody has been interested in reading such documents
[20:42] <flocculant> but that doesn't actually hurt us does it?
[20:42] <knome> it does.
[20:42] <flocculant> how?
[20:43] <knome> for example, on the burndown, there are sometimes those obviously wrong days
[20:43] <flocculant> knome: also - I'm not arguing for the sake of it here - I really want to understand what we'd gain :)
[20:43] <knome> that's just one of the symptoms
[20:43] <knome> if we had the data in our own DB, we could store the daily data about every single item
[20:43] <flocculant> see this is where I get confused
[20:43] <knome> on the history tab, the dates when the items are completed are the best guesses
[20:44] <knome> if we had the data in our own DB, we could tell people something is closed 3 times but (re)opened 4, to know it's a recurring issue
[20:44] <flocculant> because all of the real data IS on launchpad surely? the bugs, the package changes etc etc
[20:44] <knome> there is no way to ask launchpad to tell what the work item status was yesterday
[20:45] <knome> or if a bug status was open or closed any given day
[20:45] <knome> we know the *last* day when a bug was closed, but if it has been reopened and reclosed, we again only know the last day
[20:45] <flocculant> so you are looking purely at the data that we physically input on any given blueprint currently?
[20:46] <knome> mostly, yes
[20:46] <knome> we want to be linked to launchpad with the bugs anyway
[20:46] <knome> but again, that's a lot less API calls than what we are doing now
[20:46] <knome> (and having less API calls isn't the only reason - it's also simpler code to run if we have most of the data internally)
[20:46] <flocculant> which is what's confusing me I suspect - as I'm looking more 'globally' - not just what we input, but what occurs on bugs/packages ...
[20:47] <knome> that we'll still have to fetch from launchpad
[20:47] <knome> well, not "have to" but "want to"
[20:48] <flocculant> for example - the blueprints don't really get updated promptly - just when someone remembers something is DONE or POSTPONED
[20:48] <flocculant> consequently anything on the tracker about 'that' is wrong
[20:48] <knome> yes
[20:49] <flocculant> as far as the Timeline goes - does it actually matter if it's not precise?
[20:49] <knome> but what if changing the status was two clicks on the tracker instead of going to launchpad and manually editing the work item box - then wait an hour for it to be updated on the tracker - instead of being instant?
[20:49] <flocculant> still people would do it eventually
[20:49] <flocculant> :)
[20:50] <knome> in that case the question is do we need the timeline anyway?
[20:50] <knome> let me give you another example
[20:50] <knome> on how it's stupid that launchpad doesn't track work items as items but a textbox
[20:50] <knome> consider we'd have an item [flocculant] Pick noce: DONE
[20:50] <knome> (typo intentional)
[20:50] <flocculant> :)
[20:50] <knome> now, it's done today
[20:50] <knome> one week from now
[20:51] <knome> you go to fix the typo
[20:51] <knome> the second you do that, we have no way of knowing it's the same work item
[20:51] <knome> because items aren't items, they are just text
[20:51] <flocculant> on the tracker
[20:51] <knome> no, on launchpad
[20:51] <knome> on the tracker, they are actually items
[20:51] <flocculant> obviously if you subscribe you could follow the change
[20:52] <knome> ...but as they are not items on LP, they aren't "really" items on the tracker either
[20:52] <knome> yes, for humans that's easy
[20:52] <knome> but the tracker has no way to verify that
[20:52] <knome> it can't know that it's the same item, ever
[20:52] <flocculant> ok
[20:52] <flocculant> I can understand that point
[20:52] <knome> so basically if we track items on the tracker internally
[20:52] <knome> we could then change anything to anything
[20:52] <knome> and all of the items' history would follow along
[20:53] <flocculant> yep
[20:53] <knome> as it would have an internal ID that was always the same
[20:53] <flocculant> I get that
[20:53] <knome> that's one more symptom of getting the work item data from LP
[20:53] <knome> bugs are a bit easier as they have bug numbers that act as consistent ID's
[20:54] <flocculant> ok - but QA uses the tracker in a more global way - not just what's written - but changes to status for example
[20:54] <flocculant> how do we intend to keep that if the bug bp is some internal thing?
[20:55] <knome> there are (at least) two ways to go about that, and i have no idea which one we're going to use, but they are (in a simple form):
[20:55] <knome> 1) keep doing the bug blueprint as we do now, and getting the bug statuses as we do now
[20:55] <knome> simple, right?
[20:55] <flocculant> mmm
[20:56] <knome> so one concept in between: tags
[20:56] <knome> currently, work items are either development, qa, bugs, artwork or whatever
[20:56] <knome> if we save data internally, one work item can have multiple tags, concerning both artwork and qa for example
[20:56] <knome> so now:
[20:56] <knome> 2) add a work item within a tag (or two) and tell the tracker it's a bug #N
[20:57] <knome> the tracker keeps updating the bug data from LP periodically
[20:57] <knome> so in essence, just remove the bug blueprint handling and move it to the tracker - but keep on reading the bug DATA from LP
[20:58] <flocculant> at which point we are surely back at the reason you want to move away? calls to the lp api thing
[20:59] <knome> in version 1), we first need to do one API call to launchpad to ask which bugs are attached to the bugs blueprint (or any blueprint, tbh)
[20:59] <knome> then we need to make another API call to ask what's up with those bugs
[20:59] <knome> if the bug numbers were saved internally, we'd do with one API call for *all* bugs in *any* blueprints
[20:59] <knome> or in our case, in any *tags* really, as we wouldn't have the blueprints
[21:00] <flocculant> the whole thing just sounds like robbing peter to pay paul to me :p
[21:00] <knome> nah. the "less API calls" is just a side-benefit really
[21:00] <knome> and it makes the code much more clean - eg. less prone to errors and network failures and what not
[21:01] <flocculant> so what's the main benefit to us as a team then?
[21:01] <knome> in our discussion, i've pointed out several
[21:01] <knome> one more that we haven't talked a lot yet is the UI
[21:01] <flocculant> mmm - none of those sound like big things to me though :)
[21:01] <knome> the new UI will let you change statues with a few clicks instead of typing text manually as i said
[21:01] <flocculant> knome: well the UI I'm sure we're likely to agree :D
[21:02] <knome> it also lets you add work items to *any* tag (currently: blueprint) from the same URL
[21:02] <knome> basically just type the work item description, select a tag and assignee and you're done
[21:04] <knome> none of the benefits alone are huge - but combined, they make a difference
[21:06] <flocculant> knome: right
[21:06] <flocculant> sorry for hassling you :)
[21:06] <knome> no worries
[21:07] <flocculant> as you know - I'm not good with change for change sake :p
[21:07] <knome> sure
[21:07] <flocculant> akxwi-dave: something I forgot to mention - 16.04.2 hits mid January
[21:09] <knome> flocculant, http://temp.knome.fi/xubuntu/.tracker/tracker-new-items.png
[21:10] <knome> flocculant, when you click "new": http://temp.knome.fi/xubuntu/.tracker/tracker-new-items-edit.png
[21:10] <flocculant> knome: that looks pretty much how I expected it too look :)
[21:10] <knome> http://temp.knome.fi/xubuntu/.tracker/tracker-new-items-tags.png
[21:10] <flocculant> :D
[21:11] <knome> multiple tags - clickable - so click on one of them and you see all items for that tag
[21:12] <flocculant> knome: so ... start of a cycle, someone has to start a new cycle blueprint currently
[21:12] <knome> yes
[21:12] <knome> and all sub-blueprints
[21:12] <flocculant> they can copy paste pretty much the base from the last one - edit a few lines and bob's your uncle
[21:12] <knome> with internal stuff, you just add a row in the "releases" tab (similar to this) and we're set
[21:13] <flocculant> now they'll need to input each one - leave kbd, click buttons
[21:13] <knome> we can write a code snippet that copies all not-finished work items from release X to Y
[21:13] <knome> that's actually really easy with the all internal stuff...
[21:14] <flocculant> without actually doing one - I can't tell which would be quicker
[21:14] <flocculant> but I'm not convinced from what I do from cycle to cycle :)
[21:14] <flocculant> s/with what
[21:14] <knome> the code snippet would allow you to do it by selecting source and destination cycles, then click "go"
[21:14] <flocculant> ok
[21:15] <knome> it would *totally* be faster
[21:15] <knome> and less prone to human errors
[21:15] <flocculant> Decide on milestone participation
[21:15] <knome> right, so things you always want to do even if they are done
[21:15] <flocculant> gets' copied and changed from done to todo
[21:15] <knome> hmm.
[21:15] <knome> we could allow a batch input of work items
[21:16] <flocculant> how would having to type the whole thing out each time be quicker?
[21:16] <flocculant> obv things from dev perspective are different cycle to cycle
[21:16] <knome> similar to the textbox in LP, but once entered, tracked like real work items
[21:16] <flocculant> but artwork for instance - do the wallpaper - same for every cycle
[21:16] <knome> fwiw, i basically type that out every cycle :P
[21:17] <knome> but i can see QA being a bit more draggy with that
[21:17] <flocculant> hah - well I copy/paste and edit done to todo :)
[21:17] <knome> so we'll just allow some sort of CSV input, no worries with that
[21:17] <flocculant> well
[21:17] <knome> one more cool thing we can do at some point is to add a feature that takes a meeting minute url
[21:18] <flocculant> on the other hand there are tasks that the only change is x to y to z and flopping done/todo back and forth
[21:18] <knome> and greps all the action items there
[21:18] <knome> and saves them as work items :P
[21:18] <flocculant> could there be a set of always have these items?
[21:18] <flocculant> ha ha
[21:18] <knome> i'd probably do that with the CSV input
[21:18] <knome> so basically just keep a wikipage with the items you want
[21:19] <knome> and do one copy-paste per cycle
[21:19] <flocculant> and then things we put in whiteboard - where will they live?
[21:19] <knome> that's a good question with no good answer yet
[21:19] <flocculant> yea - that would work - csv doodah
[21:19] <knome> but there are definitely ways to save that kind of information
[21:20] <knome> say, every tag can have a description = blueprint can have a whiteboard
[21:20] <knome> then just show them nicely somewhere
[21:20] <knome> eg. a "tag summary page"
[21:21] <knome> i've used the whiteboard mostly for adding stuff that is related to a specific work item
[21:21] <knome> so for me, it would be much more useful if every WORK ITEM could have an extendable description
[21:21] <knome> (and that's doable...)
[21:22] <knome> but again, we can allow tag-based descriptions too
[21:22] <flocculant> I tend to use it for things that 'are' work items which get repeated that necessarily finish at the same time as we publish the final announcement
[21:22] <knome> so maybe those could be in the wiki or sth too
[21:23] <flocculant> so wouldn't ever get DONE - what would be the point :0
[21:23] <flocculant> :0
[21:23] <flocculant> oh boo
[21:23] <flocculant> :)
[21:23] <knome> well, what i mean is basically anywhere that is within the same domain/UI as the tracker
[21:23] <knome> but they STILL can be in the tag description :P
[21:23] <flocculant> because the wiki's a nightmare and the xubuntu one I don't like :p
[21:24] <knome> why don't you like the xubuntu one?
[21:24] <flocculant> can't remember offhand
[21:24] <knome> sigh :)=
[21:24] <flocculant> I tend to shy away from it lol
[21:24] <knome> well, we're moving towards it :P
[21:25] <knome> so if you don't like it, open the mouth now and we can potentially do something about it :P
[21:25] <flocculant> why do you think most of the qa stuff is on dev pages ....
[21:26] <knome> i have no idea ;P
[21:26] <flocculant> knome: there are obviously differences between the 2 wiki's - quirks if you like - but I was having trouble doing things last time
[21:26] <knome> if it's related to media management - i understand :P
[21:26] <flocculant> can't remember exactly what - some plugin needed or something
[21:26] <knome> aha
[21:26] <knome> well, the next time you bump into it, let me know...
[21:27] <flocculant> yup
[21:27] <flocculant> won't be 2016 ...
[21:28] <flocculant> I know I was doing the release note - or trying to
[21:28] <knome> right, some includes...
[21:28] <knome> maybe
[21:28] <knome> we'll figure it out
[21:28] <flocculant> nah - that doesn't work on the u.w either :p
[21:29] <knome> it does... but it's wonky :P
[21:29] <flocculant> too wonky for me to worry about :)
[21:29] <knome> maybe
[21:29] <knome> but i guess the thing i'm trying to do with all this tracker work is make things that are too wonky less wonky so people can access them and thus enable things that weren't possible before
[21:30] <flocculant> yup
[21:30] <flocculant> I know that :)
[21:30] <knome> (along with doing fun/educative projects)
[21:30] <knome> educative for me that is :P
[21:30] <flocculant> I suspect what we're really talking about *here* are the corner-cases
[21:31] <knome> nothing is better than doing something in FOSS first, with time and thought, then scoring a work project to do the same and almost copy-paste the solution and take the money :P
[21:31] <flocculant> yea - always good to keep the head working for sure :)
[21:31] <flocculant> ha ha ha
[21:31] <knome> (especially when it's accidental - and yes, that has happened)
[21:32] <flocculant> well - as always good to talk to you about something like this - but I only sat here for 5 minutes 90 minutes ago lol
[21:33]  * flocculant wanders off for the night
[21:35] <knome> ;)
[21:35] <knome> nighty


[01:47] <mhall119> tgm4883: that testcard app is fantastic
[03:36] <Jagst3r15> hi. so I am guessing with ubuntu tv there will be a netflix-ish type store of some sort
[03:36] <Jagst3r15> right?
[05:00] <tgm4883> mhall119, thanks. I just need to throw a GPL license in it and get it packaged, although I'd like to wait until I can test the work Saviq has done on remotes


[12:56] <ubotu> New bug: #145853 in soyuz "Visibly reject FTP uploads done with unrecognized keys" [Low,Triaged]  https://launchpad.net/bugs/145853
[12:57] <cprov> kiko, elmo: do you really think that the users will be able to track their own failures ? i doubt it.
[12:58] <cprov> we can add the source IP  and the changesfile name (maybe content) if it helps.
[12:59] <kiko> cprov, key-id, source IP and changesfile name would be okay
[01:01] <cprov> kiko: or we can forward the log output to a mailing list (!) instead of keep it in the local mbox only
[01:01] <kiko> cprov, hmmm, filtered, that would not be a bad idea.
[01:02] <kiko> cprov, do you know how the partner archive work is going?
[01:02] <cprov> kiko: yes, this morning opera got uploaded and built
[01:03] <cprov> https://edge.launchpad.net/ubuntu/gutsy/+source/opera
[01:03] <kiko> cprov, wow! that's very awesome.
[01:03] <kiko> cprov, I hear that we will need to make changes to the buildds?
[01:03] <cprov> kiko: julian has a branch for you with last-minute fixes ...
[01:03] <cprov> kiko: to the chroots, to be precise
[01:04] <kiko> cprov, I haven't seen it -- does it need cherry-picking?
[01:04] <cprov> kiko: but we haven't decided what exactly we will do.
[01:04] <cprov> kiko: yes, let me check the wip queue
[01:05] <ubotu> New bug: #145861 in malone ""Latest Bugs touched" should not list just created bugs" [Undecided,New]  https://launchpad.net/bugs/145861
[01:05] <cprov> kiko: it's not there, but it contains fixes in the ogre-model code and the NoMoreAF indexes perms, IIRC
[01:05] <kiko> yeah, I had assumed that
[01:06] <cprov> kiko: apart from the chroot problem, we have to run gina from a.c.c to production
[01:06] <cprov> kiko: shall I call you ?
[01:07] <kiko> cprov, gina? not before gutsy, right?
[01:07] <kiko> cprov, well, my phone is dead and I have no charger!
[01:07] <cprov> kiko: where are you ?
[01:07] <kiko> in bsb
[01:08] <cprov> kiko: uhm ... well, not I believe fabio's plan is to get gutsy stuff from a.c.c into production via gina
[01:08] <Daviey> Hey, are any LP dev's about who have access to the DB?
[01:09] <cprov> kiko: but I might be mistaken :(
[01:09] <kiko> cprov, AFAIK fabbione is going to upload straight to launchpad -- any reason why he wouldn't?
[01:09] <kiko> cprov, anyway, you can do a dogfood gina run, I guess?
[01:09] <cprov> kiko: no, a.c.c has no gutsy yet
[01:09] <kiko> cprov, ah, then it's cool.
[01:10] <kiko> Daviey, Tom's on leave, so I'm waiting for him to be back in office
[01:10] <cprov> kiko: yes, gina on dogfood worked correctly, AFAIK
[01:10] <Daviey> kiko: well won't matter after Sunday.. just a nuisance :(
[01:11] <kiko> cprov, oh, beautiful to hear
[01:12] <Daviey> Canonical employee's should not be allowed leave.. *fact*
[01:12] <cprov> kiko: so, the only problem we have is the chroot
[01:12] <kiko> Daviey, I tried to tell him that
[01:12] <Daviey> :)
[01:13] <cprov> kiko: the feisty-release chroot is not able to install the new version of pkgbinarymangler (that supports partner componenent correctly) uploaded to feisty-updates
[01:14] <kiko> cprov, hmm, that's terrible
[01:14] <kiko> but why?
[01:14] <cprov> kiko: that's the inconsistency cause by the assumption that 'release' pockets will be opened in partner.
[01:14] <cprov> archive
[01:15] <cprov> kiko: we keep partner consistent with the rest of soyuz and upload/import packages into post-release pocket of old distroseries.
[01:15] <cprov> kiko: but I don
[01:15] <cprov> 't think I have any chance in this battle :(
[01:15] <kiko> I think we already lost that one
[01:16] <cprov> ok, let's deal with the side-effect
[01:17] <cprov> release chroots have to be modified to allow installation of packages coming from post-release pockets (the extra deb lines are passed by the buildmaster when the job is dispatched)
[01:19] <kiko> cprov, for /all/ archives, not just for partner?
[01:19] <kiko> that's evil
[01:19] <cprov> kiko: a horrible hack that work is to simply override -release chroots with the respective -updates ... nobody will notice since after release the -release chroot is not used anymore
[01:19] <ajmitch> cprov: did you mean for realplay to end up on feisty-changes? :)
[01:19] <kiko> ajmitch, can I see that email?
[01:19] <ajmitch> sure, where shall I bounce it to?
[01:20] <cprov> ajmitch: no, it was a test from dogfood ...
[01:20] <cprov> ajmitch: it was a *mistake* on our side.
[01:20] <ajmitch> cprov: that's what I hoped, rather than a bug
[01:21] <cprov> kiko: chroot as shared between archives, they are categorized only by (arch, series, pocket) atm.
[01:22] <cprov> ajmitch: I'm really sorry for that, it might have caused a huge confusion for the readers.
[01:23] <cprov> kiko: errm, sorry,  s\as\are in my previous comment.
[01:23] <ajmitch> I don't think too many people will worry a lot
[01:23] <kiko> cprov, well, the pocket is different, right?
[01:24] <cprov> kiko: no, component
[01:24] <kiko> doh.
[01:24] <kiko> right.
[01:24] <kiko> do we need per-archive chroots, now?
[01:24] <cprov> kiko: it sounds like the best solution
[01:25] <cprov> it should fallback to the primary archive chroot on lookup failures ...
[01:25] <cprov> would it be too nasty ?
[01:25] <kiko> that sounds kinda evil
[01:25] <ubotu> New bug: #145867 in malone "Oops for apt source package page" [Undecided,New]  https://launchpad.net/bugs/145867
[01:25] <ubotu> New bug: #145868 in malone "bug indexing/searching unable to deal with 'cron.daily'" [Undecided,New]  https://launchpad.net/bugs/145868
[01:26] <cprov> yeah, I noticed :(
[01:26] <kiko> both dupes, gar.
[01:36] <kiko> cprov, mpt: where are our approved bug tags listed?
[01:40] <cprov> kiko: https://help.launchpad.net/TaggingLaunchpadBugs
[01:41] <cprov> help  ?!? it took ages to find :(
[01:41] <kiko> thanks
[01:43] <cprov> kiko: before I forget, 10s socket timeouts on buildmaster gives us 1 failure per day
[01:44] <cprov> kiko: each time a different builder ... there is no other explanation than network hiccups.
[01:44] <kiko> cprov, okay, that's cool, though -- can we try 20s now?
[01:44] <cprov> kiko: I will keep watching.
[01:44] <kiko> I think we're close to seeing zero failures per day
[01:44] <cprov> kiko: really ?
[01:44] <cprov> kiko: okay, aiming for zero failures
[01:45] <cprov> kiko: done, 20s
[01:47] <cprov> kiko: I have to go, I will connect on IRC tomorrow morning as soon as get in the hotel. Call if you need.
[01:47] <cprov> g'night all.
[02:02] <jkakar> How do I create a team for my project in Launchpad?  There doesn't seem to be an obvious 'Create Team' action anywhere.
[02:03] <stdin> jkakar: https://launchpad.net/people/+newteam   got that link from https://launchpad.net/people
[02:04] <kiko> yeah.
[02:04] <kiko> jkakar, where could we put that link, though?
[02:05] <jkakar> kiko: I expected to find it on the launchpad.net/<project> page actions, visible only if I'm the owner of the Team I guess.
[02:05] <jkakar> stdin: Thanks!
[02:06] <kiko> jkakar, but teams are orthogonal to projects!
[02:08] <jkakar> kiko: Well.  Yeah, I can see how that's true, but it also seems that often teams represent the people working on a project.
[02:09] <jkakar> kiko: At least, the few teams I'm a part of work like that.  In fact, 'Create project team' would be nice on the project page.  It would create a team and set it as the maintainer for the project in one go.
[02:10] <jkakar> I guess you can already do that from the 'Change maintainer' page, though.
[03:01] <ubotu> New bug: #145894 in launchpad-bazaar ""Fault 8002" when pushing a branch to an unregistered project" [Undecided,New]  https://launchpad.net/bugs/145894
[03:07] <kiko> jkakar, tricky, isn't it?
[05:02] <mpt> Gooooooooooooooooooooood afternoon Launchpadders!
[05:02] <lifeless> where!
[05:14] <mpt> "Anyone Has a Fisherman" would be a great name for a band
[05:25] <fabbione> kiko: ping?
[06:49] <poolie> hi
[06:49] <poolie> i'm again getting a page loading for many minutes, without an oops timeout
[06:49] <poolie> this time it is https://bugs.edge.launchpad.net/bzr/+bug/128456/nominations/1474/+editstatus
[06:49] <ubotu> Launchpad bug 128456 in bzr "bzr+https is not a supported protocol" [Low,Triaged]
[09:35] <ubotu> New bug: #146193 in launchpad "wish: wikitext for homepage" [Undecided,New]  https://launchpad.net/bugs/146193
[12:20] <ubotu> New bug: #146237 in launchpad "Not accepting additional spaces in string" [Undecided,New]  https://launchpad.net/bugs/146237
[12:27] <iwj> BjornT: Thanks for your investigations about those lost mails.
[12:35] <stub> kiko: It is not totally doom and gloom - if we had a catastrophic failure of the db on jubany right now we could recover - it would involve surgery on the database dumps and some consulting fees but the information is still there. But I still think the backups are a top priority.
[12:41] <boggle> how can I see the diff between a revision in a branch and it's parent branch in LP?
[12:42] <mwh> boggle: give me an example?
[12:43] <boggle> mwh: for merge proposal, see https://code.edge.launchpad.net/~canonical-training/ubuntu-desktop-course/ubuntu-desktop-course-beta
[12:44] <mwh> ah well
[12:44] <mwh> i think the answer here is "wait a couple of releases"
[12:46] <kiko> mwh, no, it's more like "pull the parent branch, merge your code into it and diff." :-/
[12:46] <boggle> he he
[12:46] <mwh> kiko: that hardly satisfies the "in LP" part
[12:46] <mwh> but yes, for now that's what you need to do
[12:46] <kiko> its parent branch is in LP! :)
[12:47] <mwh> well
[12:47] <mwh> when the code review thing is all done and dusted, this will be very slick and all lp based
[12:48] <mwh> (though somehow i doubt we'll be able to duplicate meld in a web browser...)
[01:17] <slytherin> Is it possible to request removal of a package form ppa?
[01:22] <kiko> slytherin, not at the moment, but it will be for the next release. you can upload a new version and the old one gets automatically superseded and removed, though.
[01:23] <slytherin> kiko: that is my problem, I choose wrong version for the old package I created. And now after I have created package by merging with debian package, old one supersedes new one. :-(
[01:24] <slytherin> kiko: Anyway, I have hosted the package somewhere else for the moment.
[01:24] <kiko> slytherin, maybe you could use an epoch. warning: I don't know what I am talkiing about.
[01:24] <kiko> could he use an epoch?
[01:25] <Hobbsee> kiko: yes, he could use an epoch
[01:25] <kiko> thanks Hobbsee
[01:25] <Hobbsee> kiko: it's still somewhat evil, though
[01:25] <Hobbsee> kiko: as in, makes it harder to merge each time, as debian's will always appear lower
[01:26] <kiko> right, it will require some manual effort.
[01:26] <Hobbsee> slytherin: what you could do is your-version+really-debian-version-etc
[01:26] <Hobbsee> slytherin: which only makes you do it until upstream releases a new version, so that debian then supercedes your botched version.
[01:27] <slytherin> Hobbsee: Ok. Thanks for the info. Anyway, I just wanted the latets package to be available somewhere for discussion among developers and google page creator came to rescue. :-D
[01:32] <Hobbsee> slytherin: ah, cool
[03:10] <ubotu> New bug: #146289 in kde-i18n "Translations for non main packages are discarded" [Undecided,New]  https://launchpad.net/bugs/146289
[04:00] <ubotu> New bug: #146302 in launchpad "Clean up ProductSeries naming properties" [Undecided,New]  https://launchpad.net/bugs/146302
[04:46] <ubotu> New bug: #146334 in launchpad "Firefox decompresses tarballs from launchpad (dup-of: 102652)" [Undecided,New]  https://launchpad.net/bugs/146334
[05:27] <AlexLatchford> Howdy guys, I am currently leaving for a few months. I wish to not be notified through email about bugs and code I am involved in, is there a way to do this without changing my default email address or not?
[05:29] <intellectronica> AlexLatchford: i think your best bet is to filter the email
[06:43] <bdmurray> Is there a +text for blueprints?
[06:50] <kiko> bdmurray, nope, but you can ask for one
[06:51] <bdmurray> kiko: okay, I recall using the "api" tag but what product should that bug be filed about?
[06:52] <kiko> bdmurray, blueprint :)
[06:53] <bdmurray> kiko: I was hoping for a cool code name like malone or . . .
[07:01] <gnomefreak> does LP handle the shipit site?
[07:06] <ubotu> New bug: #146384 in soyuz "germinate for hppa" [Undecided,New]  https://launchpad.net/bugs/146384
[07:11] <kiko> gnomefreak, yes, it does.
[07:12] <gnomefreak> kiko: ShipIt is currently closed while we prepare for the Ubuntu 7.04 (Feisty Fawn) release. We'll be back in a few days.  should read 7.10 gutsy gibbon maybe?
[07:12] <kiko> gnomefreak, yeah, it's a bug, but I think salgado has it nailed :)
[07:13] <gnomefreak> kiko: ok ty :)
[07:14] <salgado> gnomefreak, kiko, yeah, it's fixed already. we only need a cherry pick
[07:15] <gnomefreak> salgado: ty just figured it was a typo not so much a bug
[07:15] <kiko> salgado, I approved, right?
[07:16] <salgado> kiko, you did, but we'll have to wait for tom
[07:16] <ubotu> New bug: #146382 in postgresql-8.2 "A tsvector can make database dumps unrestorable" [Undecided,New]  https://launchpad.net/bugs/146382
[07:16] <ubotu> New bug: #146389 in blueprint "api for blueprint tracker" [Undecided,New]  https://launchpad.net/bugs/146389
[07:17] <kiko> bright
[10:00] <ubotu> New bug: #146441 in malone "Cancel a build queue in ppa" [Undecided,New]  https://launchpad.net/bugs/146441
[10:05] <ubotu> New bug: #146444 in malone "remove file from PPA" [Undecided,New]  https://launchpad.net/bugs/146444
[11:24] <stdin> is there something up with the PPA build system?: http://launchpadlibrarian.net/9553072/buildlog_ubuntu-gutsy-i386.kde-style-qtcurve_0.54.0-0%7Eppa1_CHROOTWAIT.txt.gz
[12:07] <Daviey> Any LP admins around?
[12:07] <Daviey> *urgent*
[12:07] <Daviey> -- well semi
[12:11] <MadMan2k> Hi, Ive got some questions regading PPA
[12:11] <MadMan2k> are there some kind of stats available, so I can see which of my packages are popular?
[12:12] <MadMan2k> and is there a way to create my own sections?
[12:12] <MadMan2k> I want to backport xserver1.4 and seperate it from the less dangerous stuff
[12:13] <Daviey> jamesh_: are you about?
[12:14] <Daviey> or BjornT
[12:14] <bastian> hello
[12:15] <jkakar_> Is there a way to specify the e-mail address that receives PPA-related notifications?  It's currently set to our team address which has our mailing list address as it's e-mail address.
[12:15] <bastian> I have found a problem with eog but I'm not sure wether to call it a bug
[12:15] <Daviey> bastian: raise it anyway and let others decide :)
[12:16] <bastian> If I open an image with eog, which is in a folder together with a very big image, eog will fill up my ram, that ubuntu will freeze if I don't react quickly enough
[12:16] <Daviey> how can that not be a bug?
[12:17] <bastian> hmm, might be a feature that other images are loaded
[12:17] <Daviey> "ubuntu will freeze" ... sounds like a bug
[12:17] <soren> Anything that might cause your machine to freeze is a bug.
[12:18] <soren> Badly implemented or not well thought out features can very easily constitute a bug.
[12:18] <bastian> It "freezes", because my ram gets filled up
[12:18] <soren> Just because it's easy to figure out why  it
[12:18] <soren> 's breaking doesn't make it any less of a bug :)
[12:19] <bastian> Is there a tutorial, how to report bugs correctly in launchpad?
[12:19] <soren> No. Launchpad helps you a bit, though.
[12:19] <Daviey> https://help.ubuntu.com/community/ReportingBugs
[12:19] <bastian> thx
[12:20] <soren> https://bugs.edge.launchpad.net/ubuntu/+source/eog/+filebug
[12:20] <soren> Daviey: wow, I had no idea there was such a document. Go figure :)
[12:20] <Daviey> soren: ftw -> http://www.google.co.uk/search?hl=en&safe=off&q=launchpad+report+a+bug+wiki&btnG=Search&meta=
[12:28] <Daviey> thumper: ping
[12:43] <Daviey> jamesh_: ping


[02:14] <hyperair> hi. the ~ubuntu-sg team has been idle for a couple of years, and our team administrator (ziroday) has gone missing and is uncontactable. is there anything we can do to give administrative access to more people of the team?
[02:14] <hyperair> sorry, that's ~ubuntu-sg-team
[02:15] <wgrant> hyperair: File a request at https://answers.launchpad.net/launchpad and we'll sort something out.
[02:15] <hyperair> alright, thanks
[02:16] <hyperair> wgrant: is there a difference between team owner and team administator?
[02:17] <wgrant> hyperair: Mostly that the owner can't be kicked out by an administrator
[02:17] <wgrant> So they can always regain control of the team if an admin goes rogue
[02:17] <hyperair> okay, sure.
[02:18] <hyperair> can team ownership change?
[02:18] <wgrant> Yep
[02:18] <wgrant> The owner can reassign it, or we can if the owner is missing
[02:20] <hyperair> okay
[02:20] <hyperair> thanks
[08:50] <mpt> "You have been subscribed to a public bug" -- yes, Launchpad, I know, I was the one who did it
[09:29] <lifeless> mpt: Have you turned off 'notify my about my own actions' ?
[10:22] <mpt> lifeless, no, I don't mind getting the message, I just mind getting two of them, one of them as if it was someone else
[10:26] <lifeless> ah
[10:26] <lifeless> There may be a bug for that.
[12:27] <clue_h> Hi all, during project setup for Launchpad, I chose GPL v3, but on my summary page I see I have a 30 day commercial trial. I can't see a way to remove that
[12:27] <clue_h> is it possible to do so?
[14:15] <eric_tux> hi
[14:16] <eric_tux> I've done a mistake when uploading a ppa. I'd like to re-upload it with the same 'project-source' version (orig.tar.gz) but with a different content, and update the version to -2. But when I upload, I've got an error that file already exists with a different content
[14:17] <eric_tux> I've read https://help.launchpad.net/Packaging/PPA/Deleting
[14:17] <eric_tux> How can I manage this problem ?
[14:26] <dobey> eric_tux: you will have to upload it as a different version. if the contents are not the same, then the version must be different
[14:27] <dobey> also, test everything locally before uploading to a PPA, to prevent making such mistakes in the future
[16:24] <eric_tux> dobey: ok thanks