[08:33] <jin_> dpm: ping
[08:33] <dpm> hi jin_, please, feel free to ask directly, no need to ping first
[08:34] <jin_> dpm: thanks for your comment in the MP I raised
[08:34] <jin_> I left some comments there and need you to take a look ;)
[08:34] <jin_> sending you the link:
[08:34] <jin_> dpm: https://code.launchpad.net/~libqtelegram-team/telegram-app/remove-po-files-from-version-control/+merge/288883
[08:35] <jin_> dpm: any comments from you will be welcomed, thanks!
[08:36] <dpm> jin_, oh, why do you want to remove the po files from bzr?
[08:36] <jin_> dpm: I just removed those .po files from only "bzr record"
[08:36] <jin_> no effects to the real *.po files we have in the branch/trunk
[08:37] <dpm> jin_, what's bzr record?
[08:37] <jin_> so that leave all *.po files updated by Launchpad itself
[08:37] <jin_> = bzr version control
[08:38] <jin_> since main trunk already tracked (means record these .po files in bzr)
[08:39] <jin_> so if we wanna untrack .po files, we can use this way to unmark them in bzr
[08:40] <robru> jin_: i don't think that's how it works... the mp looks pretty clearly like you are removing all .po from trunk.
[08:40] <dpm> yeah
[08:40] <dpm> jin_, what's the trunk branch you are talking about?
[08:40] <jin_> dpm: lp:telegram-app
[08:40] <jin_> this one
[08:41] <dpm> jin_, the way I read the MP, you're effectively a) ignoring all *.po files in bzr, then b) removing them from revision control and c) hoping that LP will regardless auto-commit translations there
[08:41] <robru> jin_: yea I don't know why you want to "untrack" .po files, we want those tracked so that launchpad can update them.
[08:41] <dpm> I'm not quite sure c) works
[08:41] <robru> dpm: even if c) worked it'd just undo what this branch is doing.
[08:41] <dpm> agreed
[08:42] <dpm> jin_, all that was needed was to revert the po file changes on that other branch that you guys were trying to merge
[08:42] <jin_> dpm: yeah.... I get it now..
[08:43] <dpm> or even then, you could actually merge the .po changes if you want to keep things easy, and LP will overwrite the .po files on the next translations auto-commit. But I think it'd make more sense to just leave the .po files alone alltogether
[08:43] <jin_> dmp: okay, thanks, so the only thing need to be added at the moment I think will be the .bzrignore
[08:43] <jin_> dmp: yes, yes
[08:43] <jin_> dpm: okay, I will modify the MP ;)
[08:44] <dpm> I'm not sure I'd do that either, as LP is using bzr and is not ignoring the .po files
[08:44] <jin_> (sorry for typo)
[08:44] <dpm> no worries
[08:44] <dpm> I mean LP auto-commits to the translations branch, using bzr
[08:44] <jin_> dpm: yeah I see what you mean
[08:45] <dpm> I think all I'd do would be to revert all .po file changes on that branch: https://code.launchpad.net/~libqtelegram-team/telegram-app/converged/+merge/286861
[08:45] <jin_> dpm: good idea, and that makes sense to me,
[08:46] <jin_> dpm: I will add a patch to the merge you mentioned
[08:46] <dpm> jin_, no worries: and actually, unrelated, but while we're on that subject...
[08:46] <jin_> dpm: thanks ;)
[08:46] <dpm> -#: /home/karni/src/telegram/telegram-app/v2/telegram/app/qml/components/DelegateUtils.qml:41
[08:46] <dpm> 2122	+#: /home/jin/Works/Applications/Telegram/converged/telegram/app/qml/components/DelegateUtils.qml:41
[08:47] <dpm> these are the changes that were made to the .po files ^^
[08:47] <dpm> I'd recommend not to hardcode your home directory paths there
[08:47] <dpm> and make the paths in the .po files relatives
[08:47] <jin_> dpm: make sense
[08:48] <dpm> that'd help you: a) keep privacy of your personal filesystem layout :) and b) not have to modify all files when a new developer comes along
[08:49] <jin_> dpm: okay, will do!
[08:49] <jin_> ;)
[08:49] <dpm> jin_, have a look at http://bazaar.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/trunk/view/head:/po/CMakeLists.txt - that is how the core apps do it (clock, in this example)
[08:50] <jin_> dpm: hmmmm from #23
[08:51] <jin_> dpm: checking
[08:51] <dpm> jin_, I think it's rather in the first command, starting at L8
[08:52] <jin_> dpm: right.. good reference, Telegram will follow
[08:53] <dpm> I can't remember exactly which part takes care of it, perhaps L13 or L14. But I see telegram uses .pro files and qmake instead of CMakeLists.txt and cmake, so you will need to adapt to it. We used to have an example of doing this in qmake, but then we migrated to cmake.
[08:53] <dpm> but if it turns out not to be trivial, I can see if I can find that example
[08:54] <dpm> it should be in old revisions of the clock tree, or in any other core app's old history
[08:54] <alextu> hi~ there , I just created a ci-train request there, https://requests.ci-train.ubuntu.com/#/ticket/1108 , but can not see my ticket on trello : https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-ubuntu-qa-on-ubuntu-ci-eng
[08:55] <alextu> I used to change the status to "read for QA", but it seems can not be set now .
[08:55] <jin_> dpm: sure! I will search that and look a look deeper (make Telegram adaptive on this way), will ask you to be the reviewer after done,
[08:55] <alextu> Does someone know how can I let my ticket present in trello list ?
[08:56] <alextu> davmor2, ^
[08:56] <jin_> dpm: at the moment I think I will drop the merge proposal I just mentioned, is that okay to you?
[08:56] <dpm> sure, thanks jin_!
[08:56] <dpm> yes to both :)
[08:56] <jin_> dpm: thanks mate! we will do that!
[08:56] <dpm> cook
[08:56] <jin_> dpm: nice! super
[08:56] <dpm> *cool :)
[09:23] <michi> robru: ping
[09:27] <robru> michi: Heya
[09:28] <michi> Hey.  I hadn't seen that. Didn't you see my comment about the extra commits?
[09:29] <michi> Currently, it is still the most recent revision, so it’s easy to revert
[09:30] <michi> Sure.
[09:30] <Mirv> jibel: davmor2: ok let's skip it then. I can't even complain about GPS anymore since it's working great now.. landings seem ~normal at the moment.
[09:30] <michi> That was just because you based it on trunk.
[09:30] <michi> We do all the work on devel and merge periodially in bulk to trunk.
[09:30] <michi> Via the silo
[09:30] <robru> michi: yeah but that means there were trunk commits not in devel
[09:30] <michi> So, rejecting this has done nothing.
[09:30] <michi> I don’t believe there were any.
[09:31] <michi> There shouldn’t be.
[09:31] <michi> Not normally
[09:31] <michi> pstolowski: ^
[09:31] <davmor2> Mirv: alextu might need a hand with his silo for the device tarball https://requests.ci-train.ubuntu.com/#/ticket/1108 he can't set it manually to qa ready
[09:31] <robru> michi: i know rejecting it doesn't revert it, i just didn't notice it had been merged already, had a stale tab open i didn't refresh
[09:31] <michi> pstolowski: This is the MR: https://code.launchpad.net/~robru/unity-scopes-api/vivid-tweaks/+merge/288865
[09:31] <michi> robru: No problem.
[09:31] <michi> So, I tested this yesterday and was happy with it, so I approved.
[09:32] <michi> If you are happy with it too, it’s all good.
[09:33] <robru> michi: yeah I'm happy with the work i did, i was just worried the extra commits would cause a problem. If there's no problem for you then it's fine i guess
[09:33] <michi> No, no problem. Can you top-approve again please?
[09:33] <michi> Otherwise, it’ll look weird later.
[09:34] <robru> michi: yep, done. Reviewed the diff, looks good, I'm not sure what those extra commits were but i don't see them in the diff
[09:34] <michi> Trunk was behind devel.
[09:34] <robru> michi: no trunk was ahead of devel
[09:35] <michi> So, when you rebased against devel, you probably didn’t do a pull first?
[09:35] <Mirv> davmor2: alextu: ok the 1108 is now set to Ready (for QA)
[09:35] <michi> robru: Not sure whether trunk was behind. Let me check...
[09:36] <robru> michi: i started with trunk, did my commits, then just merged devel
[09:36] <davmor2> Mirv: thanks dude
[09:36] <michi> Sorry, “ahead”, I meant.
[09:36] <robru> michi: so extra trunk commits were in my branch
[09:36] <michi> That’s trunk: 359: CI Train Bot 2016-02-09 {1.0.3+16.04.20160209-0ubuntu1} Releasing 1.0.3+16.04.20160209-0ubuntu1
[09:37] <michi> There were changes to devel since, but not the other way around.
[09:37] <michi> Maybe your devel was out of date or something?
[09:37] <robru> michi: the changelog of the silo is generated by running "bzr missing" against the branch before merging it, so the fact that names other than mine were in the changelog could only happen if there were commits on the branch not by me, and not in devel
[09:37] <michi> Anyway, when I tested and pulled your MR, it all looked good.
[09:37] <alextu> Mirv, thanks a lot, but I still can not see it on trello, so should I track it until it present on trello ? https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-ubuntu-qa-on-ubuntu-ci-eng
[09:38] <michi> robru: I honestly have no idea what happened there.
[09:38] <robru> michi: OK well if it looked good to you i guess i won't worry too much, but the diff i made in the staging silo looked weird so I was worried
[09:38] <michi> But devel is where the action is for us, and devel is healthy.
[09:38] <michi> What I saw there were lots of changes we’d made to devel in the past few weeks.
[09:39] <robru> michi: OK great
[09:39] <michi> Like the logging changes, which was the bulk of the diff.
[09:39] <michi> No more boost::log, finally!
[09:39] <robru> Yay!
[09:43] <pstolowski> michi, robru is this critical for ota10?
[09:44] <michi> I don’t know. robru ?
[09:44] <Mirv> alextu: there's just a few minutes' delay there, it's now there already
[09:45] <pstolowski> i know it's not a feature etc. the question is if it's worth disrupting the existing big unity8/filters silo with it?
[09:45] <robru> pstolowski: michi nope nope, it doesn't affect anything at all, totally not noticeable change, just prepping for train changes that are still a month or more away
[09:45] <michi> pstolowski: No need to get it into the silo then.
[09:45] <robru> Yep
[09:47] <alextu> Mirv, cool! thanks for help
[09:48] <Mirv> no problem!
[09:49] <pstolowski> michi, robru ok, we will land it on the next occasion then
[09:52] <robru> pstolowski: yep, no rush, thanks
[11:25] <morphis> Mirv: you know what is with sil2100 today?
[11:25] <Mirv> morphis: he's away, back tomorrow
[11:26] <morphis> Mirv: ah ok, can you publish https://requests.ci-train.ubuntu.com/#/ticket/1081 instead?
[11:27] <morphis> Mirv: or should I better wait for sil2100 to be back?
[11:28] <Mirv> morphis: looks ok, approved by QA, but what's up with those unresolved emulator dependencies mentioned by britney?
[11:30] <Mirv> I see there's no actual related packaging change, but just interested
[11:30] <morphis> Mirv: sil2100 said that is due to some missing things for britney, afaik he just published it last time for this landing
[11:32] <Mirv> morphis: ok, that's good enough for me. maybe something multi-arch related, the emulator is a bit special.
[11:33] <morphis> Mirv: good
[11:36] <Mirv> morphis: seems to be at correct places now, let's see if xenial release pocket migration is of any problem because of that same thing
[11:36] <morphis> Mirv: yeah
[14:11] <boiko> robru: could you please rebuild dialer-app on xenial ppc64el on silo 78?
[14:20] <rvr> renatu: ping
[14:23] <renatu> rvr, hi
[14:28] <rvr> renatu: Hey
[14:29] <rvr> renatu: I'm testing silo 22. I found a problem creating a yearly event.
[14:29] <rvr> renatu: It won't let me go back.
[14:29] <renatu> rvr, what do you mean?
[14:30] <rvr> renatu: In the Repeat screen, selecting the "Yearly" frequency, I can't go back to the Create event screen.
[14:30] <rvr> renatu: file:///opt/click.ubuntu.com/com.ubuntu.calendar/0.5.775/EventRepetition.qml:120: TypeError: Cannot call method 'getMonth' of null
[14:31] <rvr> Hmm... I can in the store version.
[14:31] <renatu> yeah this is a know bug it is fixed on a new branch
[14:32] <rvr> renatu: Does it only happens with version 0.5.775?
[14:32] <renatu> no its happen before
[14:34] <rvr> renatu: Ah, just tried with the version in the store and couldn't reproduce it
[14:36] <rvr> https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1438910
[14:39] <renatu> rvr, this is the branch to fix that: https://code.launchpad.net/~renatofilho/ubuntu-calendar-app/fix-edit-ocurrence
[14:39] <renatu> will be the next MR on the list
[14:40] <renatu> rvr, if you want I can merge it now and send a new package
[14:41] <renatu> rvr, but in any cases recurrence is buggy on the calendar app, and we are preparing a new set of MR to fix that
[14:42] <rvr> renatu: I was worried it was a regression introduced by the package in the silo, but as it is not, the fix can wait to another silo.
[14:43] <renatu> rvr, thanks
[14:48] <Mirv> ubuntu-qa: can you confirm that oxide silo https://requests.ci-train.ubuntu.com/#/ticket/1085 wouldn't need QA signoff?
[14:49] <davmor2> oxide would need qa sign off
[14:49] <rvr> Mirv: ??
[14:49] <rvr> Mirv: Of course it needs QA :)
[14:50] <Mirv> rvr: yes, that's why I pointed you to it
[14:50] <rvr> Mirv: It says "N/A" :-/
[14:50] <Mirv> rvr: so I'm taking dbarth meant it's ready for QA instead of "N/A", and putting into your queue
[14:50] <rvr> Mirv: Ahh, thanks
[14:51] <Mirv> except that it resets back to N/A :(
[14:51] <Mirv> weird
[14:51] <rvr> Mirv: That blue color, usually is set when the silo is ok to publish :-/
[14:52] <Mirv> rvr: yes, and that is true if QA wouldn't be needed ("N/A"), which is incorrect
[14:52] <jibel> Mirv, it's one a the feature we're waiting for this ota
[14:52] <Mirv> rvr: for now, I'm adding a DO NOT PUBLISH comment there
[14:52] <Mirv> jibel: can you put it into the queue manually since train is not accepting my commands?
[14:52] <rvr> Mirv: Great, thanks
[14:53] <rvr> I'll do
[14:53] <Mirv> robru: is there a particular reason why https://requests.ci-train.ubuntu.com/#/ticket/1085 does not allow changing "N/A" to Required or Ready? it keeps on resetting back.
[14:53] <jibel> interesting bug in bileto
[14:53] <Mirv> rvr: ok, thanks!
[14:53] <jibel> Mirv, forced to 'ready for qa'
[14:54] <Mirv> jibel: oh, why the train respects you more than me!
[14:54] <rvr> lol
[14:54] <davmor2> Mirv: we're in QA we have bigger hammers
[14:54] <Mirv> :(
[14:54] <jibel> Mirv, you didn't whisper the sweet words it expected
[14:54] <Mirv> meanwhile I'm recreating the diff since the silo was also not targeted to overlay
[14:55] <davmor2> Mirv: the secrets are "Work or I'll rip you hard drive out"
[15:06] <boiko> trainguards: can someone please rebuild dialer-app on xenial ppc64el on silo 78?
[15:18] <mzanetti> trainguards, the silo bumps unity8 version to 8.13 here even though no branch does that. We did have a branch in there which did it but it was removed.
[15:19] <mzanetti> could it be that it doesn't ever decrease the version again unless we'd clear the unity8 package out of the silo and do a clean build?
[15:57] <cjwatson> boiko: done
[16:14] <Mirv> boiko: seems done now
[16:14] <Mirv> mzanetti: yes it's possible it works like that.
[16:15] <Mirv> mzanetti: but we could try deleting both the superseded and current package and then try again in 30mins or so
[16:16] <Mirv> mzanetti: since you apparently don't want 8.13 anyway, I'm trying that
[16:16] <mzanetti> Mirv, let me just ask back with the team... might be they rely on the 8.13 fact already. will let you know in a bit
[16:16] <Mirv> mzanetti: oh, ok
[16:21] <popey> davmor2: have you seen any notifications on latest rc-proposed? on my krillin I'm seeing grey on grey, unreadable notifications
[16:21] <popey> didn't get a screenshot in time
[16:21] <kenvandine> popey, i'm seeing the same thing on arale
[16:21] <davmor2> popey: there is a bug in unity8 for it
[16:21] <popey> thanks kenvandine
[16:21] <popey> ok
[16:21] <jibel> popey, it's a known bug
[16:21] <popey> \o/
[16:21]  * popey goes back to sleep
[16:22] <jibel> popey, bug 1554616
[16:22] <jibel> popey, if you find anything unity8 related not in the list please add it
[16:22] <popey> kk
[16:23] <popey> comment 17 covers my issue
[16:36] <boiko> cjwatson: Mirv: thanks
[17:30] <rvr> renatu: ping
[17:34] <renatu> rvr, hi
[17:35] <rvr> renatu: Something weird happened with a reminder (-5 minutes). It wasn't triggered. But then I re-edited the event, and cannot reproduce.
[17:35] <rvr> renatu: Anyway, there is this test case "Change the guests by adding and removing (swipe right)"
[17:36] <rvr> renatu: I cannot swipe right an event, because the calendar view moves.
[17:37] <renatu> let me check the test plan, you should not swipe right the event. I think the test plans want you to swipe right the guest
[17:37] <rvr> renatu: You may be right
[17:37] <rvr> renatu: Event modification "Change the guests by adding and removing (swipe right), save the event, re-open and make sure the changes were properly saved"
[17:38] <renatu> rvr, yes, open the event editor and swipe right a guest, save it and open again to check if the changes was commit
[17:38] <rvr> renatu:  Right.
[17:38] <rvr> Done
[17:39] <rvr> renatu: Final question. Will this calendar app version be published on the store?
[17:39] <renatu> rvr, no. it will be land on OTA 10
[17:39] <renatu> rvr, but still some fixes to land
[17:39] <rvr> renatu: Ah, cool
[17:40] <rvr> renatu: I'm approving the silo, then
[17:40] <renatu> rvr, thanks man[
[17:41] <renatu> rvr, sorry for the confusion with test plan It was wrote a log time ago. I started to work on calendar app some weeks ago
[17:41] <rvr> renatu: np :)
[17:44] <robru> mzanetti: yes, PPAs will never accept an upload with a lower version than what was in there before, so the train always picks the highest possible version when generating version numbers. If you want to go back down, you need to abandon & reassign to get a fresh ppa
[17:44] <mzanetti> I don't think it's that critical. we'd want to bump it anyways, and as this silo is already a FFE I don't feel like it's worth delaying it any further for skipping one version number tbh
[17:45] <mzanetti> but thanks for explaining, yes
[17:51] <robru> Mirv: bileto enforces na/required/ready states based on series & dest, so it wouldn't let you because it wasn't targeting overlay i think, the trick is that there's an exception for tickets with manual download URLs set, so jibel set "http://" there and then you can set any qa status
[17:51] <robru> Mirv: sooner or later I'll need to fix up the qa field to behave more predictably but I've just had other priorities, sorry
[17:52] <mzanetti> robru, fwiw, Mirv dropped just the unity8 package from the silo, I've rebuilt it now and it seems to be back to 8.12 (as opposed to the wrong 8.13 from before)
[17:52] <mzanetti> so seems a complete silo clean is not required
[17:53] <robru> mzanetti: oh interesting, thanks, i was under the impression that PPAs always remembered the versions even if you deleted the packages
[17:53] <mzanetti> robru, doesn't a "clear silo" just delete all the pacakges from a ppa too?
[17:54] <mzanetti> apart from the other train magic, but from a ppa point of view it seems to be just like deleting all the packages
[17:54] <robru> mzanetti: yes, but then when you re assign, you get a different one
[17:54] <robru> mzanetti: they're assigned in random order
[17:54] <mzanetti> robru, well, but if that wouldn't be enough, we would frequently get silos with wrogn versions because someone tested something in that silo before
[17:55] <robru> mzanetti: oh do you guys bump the version number a lot? I assumed that was rare
[17:55] <mzanetti> not *a lot* but well... whenever we change something in unity-api
[17:55] <robru> Fair enough
[17:55] <mzanetti> which does happen every 1.5 landings I'd say


[00:40] <belkinsa> hggdh: Can you reinvite me into the CC's channel?
[00:44] <pleia2> belkinsa: you can now do it yourself with /msg chanserv invite #channel-name
[04:15] <ahoneybun> knome: just found the ubuntu community wordpress theme
[04:15] <ahoneybun> awesome stuff!!!
[09:36] <knome> ahoneybun, thanks. if you plan on using it, don't hesitate to ping again.
[16:05] <hggdh> belkinsa: you should be able to invite yourself in
[16:06] <hggdh> belkinsa: /msg chanserv invite #ubuntu-communitycouncil
[16:06] <hggdh> belkinsa: I do not have op-powers to set you in the I list
[16:06] <hggdh> (which wyou should be in already)


[23:27] <penguin42> I am right to move Linux oops's reported against nfs-utils to Linux aren't I? There isn't a rule somewhere to special case them?


[10:30] <doko> infinity, mdz: is edgy already open?
[10:32] <infinity> doko: No.
[10:33] <infinity> doko: Some infrastructure still needs to be verified before it can open, and I'm also planning on hand-holding the new glibc and gcc before I put the buildds into free-for-all mode.
[10:34] <fabbione> infinity: i assume glibc 2.4 ?
[10:36] <infinity> fabbione: yes.
[10:36] <fabbione> infinity: do we have package ready for it?
[10:36] <fabbione> i wouldn't mind to give it a pre-spin on sparc
[10:36] <fabbione> i know gcc-4.1 will break some sparc stuf
[10:36] <infinity> Jeff's still polishing it.  He should be done his tomorrow morning.
[10:36] <fabbione> ok
[10:39] <infinity> I expect the whole world to break in edgy on every arch, so no big deal.
[10:42] <fabbione> infinity: eheh yea
[06:44] <mdz> doko: today is the day
[06:47] <doko> hmm, infinity told that he still needs buildd babysitting
[06:47] <doko> or should that be builddsitting
[06:54] <doko> infinity: we cannot sync gcc-4.1 and gcj-4.1; sparcv9 patch is missing ...
[09:31] <infinity> doko: Okay, then can you give me a gcc-4.1 and gcj-4.1 on chinstrap somewhere that I can do the chroot bootstrap with as soon as Jeff hands me a final glibc?
[09:32] <doko> infinity: yes, waiting on a final test build
[09:33] <infinity> doko: You rule; thanks.
[11:04] <doko> infinity: chinstrap:~doko/uploads -> gcc-4.1
[11:13] <jbailey> Ah, sorry 'bout that.
[11:14] <jbailey> I'm on my laptop so I don't auto-login to all my usual channels.
[11:21] <doko> so maybe it's safer to first build gcc-4.1 and gcj-4.1, then glibc?
[11:21] <doko> I do not want to block edgy for too long
[11:27] <infinity> We're not blocking anything yet.  Don't worry about it.
[11:28] <infinity> Anyhow, I've already got a plan laid out and it should go just fine.
[11:28] <jbailey> sparc did need the same fix, I've added it to my tree.
[11:28] <jbailey> infinity: My biggest weakness right now is that for all but ppc/ppc64 I'm only doing chroot tests for these.
[11:28] <jbailey> And I don't have a sparc.
[11:29] <jbailey> I need to keep my systems pure dapper right now for LSB
[11:29] <infinity> chroot tests are good enough for me.  <shrug>
[11:29] <infinity> We'll find out soon enough if you broke the world anyway.
[11:29] <doko> infinity: gcj-4.1 online as well
[11:29] <jbailey> you know my OCD ;)
[11:30] <infinity> jbailey: It's trivial to run a full GNOME environment from a chroot, if you really want to give it your acid test.
[11:30] <jbailey> How do you get access to X, just bindmount tmp?
[11:30] <infinity> Yeah, bindmount /tmp and don't kill your environment on chroot.
[11:31] <infinity> (so, "chroot /chroot su" instead of "su -", or "dchroot -d -c edgy" if using dchroot)
[11:32] <infinity> Alternately, for the full test, kill your X session, chroot into the chroot, then startx from there, so your whole test is ground-up running in the chroot.


[15:15] <ricotz> LocutusOfBorg, hi :) would it be possible to sync wine 6.0.2~repack-3 ?
[15:15] <LocutusOfBorg> ricotz, I will do it yes
[15:15] <LocutusOfBorg> after wine-development clears
[15:15] <ricotz> LocutusOfBorg, ack :)
[15:21] <LocutusOfBorg> I still don't get why wine development has no openldap fix, while wine has it
[15:21] <LocutusOfBorg> oh its a debian specific patch, nice
[18:46] <ahasenack> hi, I'm looking if there is a pattern for this. I have a postinst that might fail, but the service will keep running, but with a different config. I can let it fail, echo some helpful message on how to fix it, or don't fail, but still echo a message that is should be fixed
[18:46] <ahasenack> I'm wondering about release upgrades. I thought to use option (b) (not fail, but still echo messages) in the release upgrade case, and (a) if it's a normal upgrade
[18:47] <ahasenack> but I fear both cases might have the message ignored
[18:47] <ahasenack> just wondering out loud
[18:47] <ahasenack> if somebody has ever made a postinst behave differently if it's running under a bigger release upgrade or not
[18:53] <rbasak> ahasenack: what's the reason it'd fail? I've heard one argument that it's bad to silently succeed if we know it's broken.
[18:54] <ahasenack> rbasak: a bug. It's the nfs configuration script. If it fails, what happens is that local customizations done by the user are not reflected in the new config file, which will be using the defaults of a fresh install in that case
[18:54] <ahasenack> the service will be running, but not with the custom options that were being used before
[18:55] <ahasenack> emphasis on custom: the migration will not kick in if there were no changes to the default config
[18:55] <rbasak> It sounds bad to not fail the upgrade in that case
[18:55] <ahasenack> I can see that, yes
[18:55] <rbasak> I wonder if a preinst check might help - if it's predictable in advanvce.
[18:55] <rbasak> That might help limit the damage perhaps? This'd need testing.
[18:55] <ahasenack> but I also wonder about a release upgrade, where failing in the middle of it has worse consequences
[18:56] <rbasak> The UX around this kind of case has always been poor :-/
[18:56] <ahasenack> i.e., it's easier to fix this particular config post upgrade, then to recover from a upgrade that failed somewhere in the middle
[18:56] <ahasenack> but on a release upgrade the user also won't be seeing these messages (hey, heads up, your config wasn't migrated)
[18:56] <rbasak> MySQL packaging disables the daemon but also disables a debconf critical prompt in some cases like this
[18:57] <rbasak> *displays a debconf critical prompt
[18:58] <ahasenack> hm, should I go with the debconf critical prompt I wonder
[18:58] <ahasenack> "hey, I failed to convert your configuration, please see <foo>. Your service is running, but with the defaults"
[18:58] <rbasak> It might also be better not to start the daemon at all if you know you couldn't migrate the configuration
[18:58] <rbasak> Than to run it but wrong
[18:58] <rbasak> (which is why MySQL packaging also disables the daemon in this cae)
[18:58] <ahasenack> it's multiple daemons
[18:59] <rbasak> Sounds like fun
[18:59] <ahasenack> and we know mysql still apports dozens of postinst failures bugs
[18:59] <ahasenack> even with this care
[19:02] <rbasak> We didn't use it for many cases
[19:02] <rbasak> Looking at it now, it's only for the downgrade case (or the unsupported "crossgrade" from MariaDB). There we don't expect the daemon to be able to start at all.
[19:03] <rbasak> And attempting to start it may damage data
[19:05] <ahasenack> I don't expect data loss
[19:05] <ahasenack> at most an unreachable nfs server, if options like custom/fixed ports were used
[19:05] <ahasenack> but these are obviously the ones I'm testing a lot
[19:05] <ahasenack> still, stuff happens
[19:06] <ahasenack> I miss some sort of "notification central" for non-desktop
[19:27] <rbasak> "notification central"> I wonder if update-motd could be used for that kind of thing
[19:27] <rbasak> It'd need packages to be able to supply some kind of "I'm broken" status
[19:28] <ahasenack> yeah, with a limit of course, and "... run get-notifications for the remaining messages" or something like that
[19:28] <rbasak> That isn't quite as drastic as "dpkg will refuse to do anything now"
[19:28] <ahasenack> I mean, local mail used to be that
[19:28] <rbasak> Also things like "files exist in /etc with .dpkg-new or .dpkg-old" could trigger such notices
[19:29] <ahasenack> "You have 2 new mails"
[19:29] <ahasenack> just bring that to the XXI century
[19:29] <rbasak> I'd like it to have a feedback loop - so if the underlying reason goes away before the user notices, then so does the notice.
[19:29] <ahasenack> yes, I remember that idea of yours for the .dpkg-* files
[19:29] <ahasenack> I think it can be expanded
[19:30] <ahasenack> and without becoming annoying
[20:07] <melodie> hello
[20:08] <melodie> did someone notice that the default swapfile created during install can't work when the fs type chosen is BTRFS?
[20:09] <melodie> when having btrfs it needs to be created with specific command lines https://superuser.com/questions/539287/swapon-failed-invalid-argument-on-a-linux-system-with-btrfs-filesystem
[20:10] <melodie> should I report a bug?
[20:11] <melodie> (I had also followed here : https://btrfs.readthedocs.io/en/latest/Swapfile.html )
[20:17] <ahasenack> melodie: is this on jammy, or existing releases?
[20:22] <melodie> hi ahasenack sorry, forgot to mention : in focal
[20:23] <ahasenack> have you tried the version released last week? 20.04.4?
[20:23] <ahasenack> it might be fixed already
[20:23] <melodie> ahasenack, not yet, why have you seen a bug report related to this issue?
[20:24] <melodie> I can try a bit later, I have a rebuild ongoing (my remix) which I will test in Virtualbox once done.
[20:24] <ahasenack> no, but the topic is not new to me, so it's possible it was addressed already
[20:24] <melodie> ahasenack, I will test, thank you
[20:24] <ahasenack> thx for testing
[20:25] <ahasenack> http://releases.ubuntu.com/focal/
[20:25] <melodie> with pleasure,
[22:01] <mwhudson> hmm
[22:01] <mwhudson> sarnold: can you think of some way we can use your archive searching abilities to find packages that explicitly list libssl1.1 in Depends in debian/control?
[22:03]  * mwhudson sideyes libpython2.7-stdlib
[22:08] <cjwatson> mwhudson: isn't that just grep-dctrl?
[22:09] <sarnold> heh, is it? I don't think I've had much success with that
[22:09] <cjwatson> I use grep-dctrl all the time, it's great
[22:10] <cjwatson> assuming you have the relevant Packages files, but that's easy enough
[22:11] <mwhudson> cjwatson: no i need to do it on the source packages
[22:11] <mwhudson> cjwatson: i want to find packages that have libssl1.1 in depends from things other than dpkg-shlibdeps
[22:14] <mwhudson> because they need to stop doing that
[22:18] <sarnold> mwhudson: okay I kicked something I hope will do the trick :)
[22:18] <dbungert> codesearch with path:debian/control?
[22:47] <mwhudson> dbungert: yeah probably good enough
[22:54] <sarnold> mwhudson: https://termbin.com/38rx
[22:55] <mwhudson> oh that's not so bad
[22:58] <sarnold> way smaller than I expected, heh
[22:58] <sarnold> is there a lintian for these things?


[21:48] <bkerensa> hi devxdev
[21:53] <devxdev> whats up bkerensa
[21:53] <bkerensa> devxdev: nothing much just saying hello to a new face ;)
[21:53] <devxdev> :D
[21:54] <devxdev> i just started using irc a few days ago but i'm not a n00b :)
[22:50] <nathwill> *yawn*
[22:50] <nathwill> bkerensa: got the loco agenda updated last night...


[14:10] <cjwatson> So how did plymouth et al manage to wind up uninstallable in raring?
[14:10]  * cjwatson peers at logs
[14:15] <cjwatson> Hmm, maybe it's just dri2-utils
[14:43] <cjwatson> Ah, partial NBS, well that explains part of the problem
[14:54] <cjwatson> xnox: Hmm - doesn't plymouth need s/libdrm-nouveau1a/libdrm-nouveau2/g?


[00:20] <qwebirc97286> hi there, I am a newbie on mythbuntu, using 10.04rc upgraded to myth 0.23 fixes build 14158. I have installed libdecss, but when I put in a dvd it crashes out of myth back to ubuntu desktop, on checking the log it says qt4 error. can anyone help ???
[04:02] <hot_wheelz> correct me if i'm wrong but isn't there an auto back feature in mythtv 0.23?
[04:03] <hot_wheelz> backup sorry
[04:56] <tgm4883> hot_wheelz, I believe so, I don't know much about it though
[04:57] <tgm4883> it's just a db backup
[05:15] <Shadow__X> tgm4883: so the issue i was having with the errors is due to the os x fe apparently not supporting jpegs
[05:15] <tgm4883> Shadow__X, ah
[05:15] <Shadow__X> my ubuntu fe pulled them up eventually
[05:15] <tgm4883> Shadow__X, sorry I bugged out earlier, I was at work and dealing with a strange issue
[05:16] <Shadow__X> i also had a permission error as well
[05:16] <Shadow__X> no worries i know how that is
[05:16] <Shadow__X> i personally didnt think you bugged out but thank you
[10:03] <qwebirc51305> is 0/22khz continuous tone switching supported (4x4 multiswitches) in 0.23-fixes?
[10:04] <qwebirc51305> !help
[10:04] <Zinn> !help For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[10:31] <qwebirc51305> !help
[10:31] <Zinn> !help For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[13:07] <sidh> Greetings
[13:10] <sidh> I have to install mythbuntu on a old x86 machine (with older version available of nvidia gpu for tv output) as for now there is a lot of updates since 10.04 iso release included kernels updates, i wonder about the order of installing things
[13:10] <sidh> is it possible to not install nvidia drivers on first iso install, and install it , only when the dist-upgrade is finished ?
[13:16] <mrand> sidh: You can always add stuff later.
[13:17] <sidh> ok because nvdia reinstall is always an adventure with me
[13:17] <sidh> ;)
[16:42] <olx69> Following http://www.mythtv.org/wiki/ACPI_Wakeup I have to add %mythtv ALL = NOPASSWD: /sbin/shutdown, /bin/sh, /usr/bin/setwakeup.sh, /usr/bin/mythshutdown on the bottom, edited by visudo. Login/Logout/Reboot. Now I test it: sudo -u mythtv sh -c "/sbin/shutdown -k now"  shutdown: Need to be root
[16:42] <olx69> What's wrong?
[16:42] <Zinn> [www.mythtv.org] ACPI Wakeup - MythTV
[23:16] <miststlkr> I have mythbuntu 10.04 and another system with a base ubuntu 10.04 install.  I rather like having the Applications menu in the desktop context menu, but not sure how to add that.  Is there even a way to do it in GNOME?
[23:37] <tgm4883> miststlkr, that sounds like a question for #ubuntu
[23:37] <miststlkr> I thought so too, but no bites there so I thought perhaps someone in here might know how it was done in Mythbuntu and i could work from there.   thanks though.
[23:39] <tgm4883> well it's done in mythbuntu by using xfce
[23:39] <tgm4883> but you left
[23:39] <tgm4883> so I can't tell you that


[12:51] <qswz> guys, whether you use sublime text or not, I'd be glad if you upvote https://github.com/SublimeTextIssues/Core/issues/1361, they don't care enough about linux users
[23:07] <DJAnonimo> Hello, anyone here?
[23:08] <wxl> yes but
[23:08] <wxl> !ask
[23:08] <wxl> \:)
[23:08] <DJAnonimo> well I have a problem. I want to run 16 bit colordepth
[23:08] <DJAnonimo> but when I create a config file with 16 bit color depth the OS do not boot
[23:08] <wxl> phew that's a request i've never encountered before
[23:08] <DJAnonimo> it boot just in recovery mode.
[23:08] <wxl> what file?
[23:09] <DJAnonimo> etc/X11/xorg.conf
[23:09] <wxl> let's see a paste of it
[23:09] <DJAnonimo> https://ubuntuforums.org/showthread.php?t=1238639
[23:09] <DJAnonimo> from here
[23:10] <wxl> going into recovery seems strange
[23:10] <wxl> i could expect it failing to boot x, but not going into grub recovery
[23:10] <wxl> have you looked in the logs?
[23:10] <DJAnonimo> I go with press ESC
[23:10] <wxl> huh?
[23:11] <DJAnonimo> yes with a loader
[23:11] <DJAnonimo> with xwininfo -root | grep Depth
[23:11] <DJAnonimo> I get 16 bit result on recovery mode
[23:11] <wxl> let's clearly define "recovery mode"
[23:11] <DJAnonimo> I hope its not a fake
[23:11] <DJAnonimo> before lubuntu is booting I do ESC key
[23:12] <DJAnonimo> and then set kernel in Recovery mode
[23:12] <wxl> why do you do that?
[23:12] <DJAnonimo> because it do not boot in normal mode
[23:12] <wxl> what exactly happens?
[23:12] <DJAnonimo> when xorg.conf is configured on 16 bit mode
[23:13] <DJAnonimo> stops on black screen with: /dev/sda1: clean 2244728/7684096 files, bla bla bla blocks
[23:14] <wxl> ok, that's not that it fails to boot
[23:14] <wxl> but more likely that x fails to handle your configuration
[23:14] <DJAnonimo> yea
[23:14] <DJAnonimo> something like this :)
[23:14] <wxl> you can grep for EE (error) in /var/log/Xorg.0.log
[23:14] <DJAnonimo> the question is... why :D
[23:15] <wxl> in fact you can get to it from the blank screen
[23:15] <DJAnonimo> after a failure or now?
[23:15] <wxl> CTRL-ALT-F7
[23:15] <wxl> sorry
[23:15] <wxl> that's how to get back :)
[23:15] <wxl> CTRL-ALT-F1
[23:15] <wxl> ugh i'm tired
[23:15] <wxl> not F at all
[23:15] <wxl> no i was right
[23:15] <wxl> sorry it's like an automatic thing
[23:15] <wxl> physical memory works, but not mental memory :)
[23:15] <DJAnonimo> let me powerup my laptop and set to 16 bit
[23:16] <wxl> it's MOST LIKELY a syntax error
[23:22] <DJAnonimo> screenshot here: https://ibb.co/k3jRbQ
[23:25] <DJAnonimo> wxl still here?
[23:25] <wxl> that's the only example of an error?
[23:25] <DJAnonimo> I can upload you the whole log file...
[23:25] <DJAnonimo> thats inside Xorg.0.log
[23:25] <wxl> that would make the most sense
[23:27] <DJAnonimo> https://pastebin.com/QdewYXUQ
[23:28] <wxl> ok interesting. let me see the whole of the configuration file
[23:37] <DJAnonimo> when trying to run "X -configure"  https://ibb.co/dvW6bQ
[23:38] <wxl> still haven't seen the config file
[23:39] <DJAnonimo> I just tried creating it... with no luck as you can see in the screen shot
[23:40] <DJAnonimo> with just Screen section with color depth it fails...
[23:40] <DJAnonimo> so the questio is... how to create a proper config file
[23:40] <wxl> all you have to do is copy /etc/X11/Xorg.conf and paste it
[23:41] <DJAnonimo> I tried with the screen section line
[23:41] <DJAnonimo> Section "Screen"
[23:41] <DJAnonimo> 	Identifier	"Default Screen"
[23:41] <DJAnonimo> 	Monitor		"Configured Monitor"
[23:41] <DJAnonimo> 	Device		"Configured Video Device"
[23:41] <DJAnonimo>         DefaultDepth    16
[23:41] <DJAnonimo> EndSection
[23:42] <DJAnonimo> config file is https://pastebin.com/S81vph9S
[23:47] <DJAnonimo> wxl: any idea?


[23:01] <gilbert> a
[23:01] <gilbert> paultag: hehe, yeah
[23:02] <gilbert> paultag: actually, it had been a fairly civil discussion
[23:02] <gilbert> (i think, of course i could be biased)