[05:51] <hikiko> Hi
[06:54] <RAOF> Oh, duplicity.   We did Ikea as well.  So the full house of shopping.
[09:02] <seb128> lol
[09:02] <seb128> had a nice lunch in the middle?
[09:03] <xnox> seb128, the hints were crap, and the last task was to find 15 tiny 2cm x 2cm tokens glued to inside of window seals, under the menus and generally impossible to find and boring.
[09:03] <willcooke> Yes!  We went to Waggamama
[09:03] <Laney> guten morgen
[09:03] <xnox> seb128, it started off as fun, and then quickly degraded into boredom.
[09:03] <davmor2> Morning all
[09:06] <seb128> willcooke, nice :-)
[09:06] <seb128> xnox, I see, at least it's not freezing in Sevilla ;-)
[09:06] <seb128> hey Laney
[09:06] <seb128> hey davmor2
[09:06] <seb128> how are you today?
[09:08] <davmor2> seb128: Good thanks, you?
[09:09] <seb128> davmor2, I'm good thanks!
[09:10] <Laney> hey seb128
[09:10] <Laney> good
[09:10] <Laney> napped and then went to the pub quiz ;-)
[09:10] <Laney> we got 26/30
[09:10] <Laney> winners got 28.5 :|
[09:11] <seb128> quite some comptetition!
[09:11] <davmor2> Laney: knowledge whores that's what they were ;)
[09:12] <Laney> tattooed wikipedia under their eyelids
[09:12] <Laney> davmor2: one question was basically "what's the name of that advertising company that plays that catchy tune before films at the cinema?"
[09:12] <Laney> I kept going "BRADFORD AND BINGLEY... no wait that's a bank :("
[09:13] <Laney> eventually someone remembered it
[09:13] <seb128> what was it?
[09:13] <seb128> or is it
[09:13] <davmor2> Laney: Hanna and Barbara spelt wrong but you know who I mean
[09:13] <Laney> https://www.youtube.com/watch?v=3WQrLuaMBMw
[09:13] <Laney> this thing
[09:14] <davmor2> Laney: pearl and dean that's it I knew the music, the others were the cartoon people behind the flintstones
[09:14] <davmor2> I was close :)
[09:16] <Laney> davmor2: good effort, you can stay
[09:22] <davmor2> Laney: man now I've had to watch this https://www.youtube.com/watch?v=j-KDZDNnR9A
[09:25] <Laney> ah, the creepy milk tray stalker
[09:28] <davmor2> Laney: the second best Coke advert ever too and cinzano with Joan and Leonard
[10:26] <xnox> tedg, unity-scope-click doesn't really depend on click
[10:26] <xnox> as i don't have any clicks installed, and it shows things from debs
[10:26] <xnox> however does it use ubuntu-app-launch to launch legacy apps?
[10:42] <flexiondotorg> Morning desktopers
[10:42] <flexiondotorg> Sorry for the late start.
[10:43] <flexiondotorg> Annual watch the children wear tea towels on their heads day here :-)
[10:43] <willcooke> :D
[10:48] <seb128> hey flexiondotorg
[10:57] <xnox> seb128, Laney, pitti - is /usr/lib/gnome-session/run-systemd-session only run in systemd-only sessions? and sessions that have upstart, never execute that thing?
[10:58] <pitti> xnox: correct
[10:58] <xnox> yeah
[10:58] <pitti> xnox: more precisely, whatever the Exec= from the session .desktop says
[10:59] <pitti> (except that upstart completely overrides this)
[10:59] <xnox> pitti, so i had stale UPSTART_SESSION imported into user systemd session, thus i think run-systemd-session should be cleaning that up.
[10:59] <xnox> environment that is
[10:59] <pitti> ah, good point
[11:13] <FJKong> hi desktop, I met a bug, after resume from suspend, when right click, it will be black area by pop up menu.
[11:13] <FJKong> oh not just right click all window and menu will be like this
[11:16] <FJKong> https://postimg.org/image/izo0e7r7t/
[11:20] <seb128> hey FJKong
[11:21] <FJKong> seb128: hey
[11:31] <seb128> FJKong, weird, no idea what that could be, does it do every time? only in gtk applications?
[11:32] <seb128> FJKong, what ubuntu serie is that?
[11:39] <FJKong> seb128: I am using yakkety, upgrade from previous version, not every time , It will shown after some times of suspend
[11:39] <FJKong> not only in gtk app
[11:40] <FJKong> it seems all window like this
[11:40] <FJKong> I guess this is related with display mamager things
[11:40] <seb128> could be a video driver issue
[12:10] <FJKong> maybe, I use nvidia video card
[12:23] <seb128> FJKong, nvidia binary drivers or nouveau?
[12:33] <FJKong> seb128: I use nvidia binary drivers
[12:34] <seb128> FJKong, try maybe with nouveau if you get the same issue
[16:35] <muhaha> muhahaha
[16:36] <willcooke> k
[16:37] <seb128> right
[17:23] <seb128> k, time for some exercice
[17:23] <seb128> have a nice evening desktopers
[17:23] <willcooke> l8r seb128
[17:23] <seb128> see you tomorrow
[17:23] <seb128> bye willcooke
[17:24] <flexiondotorg> Night seb128
[18:12] <willcooke> night all


 Good I guess. You?
[07:10] <didrocks> salut seb128
[07:11] <seb128> lut didrocks, en forme ?
[07:11] <seb128> I'm good! had a good night and the kid is better/at the childcare
[07:12] <seb128> just having to deal with the company coming to do the new floor now
[07:12] <didrocks> seb128: ça va :)
[07:12] <didrocks> great
[07:13] <duflu> Just levitate
[07:13] <duflu> It will be fine
[07:19] <seb128> :)
[07:34] <marcustomlinson> morning all
[07:36] <oSoMoN> good morning marcustomlinson
[07:37] <didrocks> hey marcustomlinson
[07:37] <seb128> hey marcustomlinson, how are you today?
[07:38] <marcustomlinson> seb128: yeah alright, yourself?
[07:38] <duflu> Morning marcustomlinson
[07:39] <seb128> marcustomlinson, I'm good!
[07:42] <seb128> jamesh, hey, your weekly summary discourse post? ;)
[08:13] <seb128> marcustomlinson, kenvandine, unsure if you noticed but eog-master snap is failing upload because of external help symlinks
[08:14] <seb128> and quadrapassel-master is failing on
[08:14] <seb128> error: Package `gsound' not found in specified Vala API directories or GObject-Introspection GIR directories
[08:14] <seb128> so probably a new build-depends needed
[08:25] <marcustomlinson> seb128: I think ken has been experimenting with these snaps, it's possible this is WIP stuff
[08:28] <seb128> marcustomlinson, k, thx, the error emails end up in the desktop list moderation queue and I'm unsure if others get them as well so I mentioned it in case it's useful
[09:07] <jamesh> seb128: sorry for the delay.  Posted the status update now (no branch landings, mostly due to the people who could approve them being at the sprint)
[09:17] <seb128> jamesh, thx
[09:38] <tseliot> hey seb128, do you mind if I merge libvdpau from debian? (I noticed you worked on the last merge)
[10:22] <k_alam> seb128: Hi, good morning
[10:24] <k_alam> u there ?
[11:36] <seb128> tseliot, hey, please do, I just ddi it because it's an easy one and our version was outdated compared to Debian, I'm not maintaining it :)
[11:36] <tseliot> seb128: all right then, I'll take care of that :)
[11:37] <seb128> tseliot, great, thx!
[11:38] <seb128> rbalint, hey, I saw your systemd/gdm message from yesterday, I think the best person to have a look is Laney but he's out this week ... also even if gdm is doing something weird did we define it as really buggy? or is that just the systemd tests that don't handle that special case and are at fault?
[13:04] <kenvandine> seb128: i had noticed eog but not quadrapassel
[13:04] <kenvandine> seb128: i'll take care of it
[13:04] <seb128> kenvandine, hey, thx :)
[13:05] <seb128> kenvandine, also eog fails upload due to help symlinks
[13:05] <kenvandine> yeah, i'll fix that
[13:05] <kenvandine> that's a meson issue
[13:06] <seb128> thx
[13:29] <willcooke> #startmeeting Desktop Team Meeting 2019-08-06
[13:29] <meetingology> Meeting started Tue Aug  6 13:29:55 2019 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[13:29] <meetingology> Available commands: action commands idea info link nick
[13:29] <willcooke> Hi!
[13:30] <willcooke> Roll call: didrocks, duflu (out), jamesh (out), jibel (hols), kenvandine, laney (hols), marcustomlinson, oSoMoN, seb128, tkamppeter, trevinho, robert_ancell (out)
[13:30] <marcustomlinson> hi
[13:30] <didrocks> hey
[13:30] <kenvandine> o/
[13:30] <oSoMoN> o/
[13:30] <seb128> hey
[13:31] <willcooke> Lets crack on
[13:31] <willcooke> Starting with....
[13:31] <willcooke> #topic rls-bb bugs
[13:31] <willcooke> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[13:32] <willcooke> one which k_alam is on the case
[13:32] <willcooke> And one which looks like the OEM team are assigned for
[13:32] <seb128> the first one needs to be untagged since it's assigned, I'm doing that
[13:32] <willcooke> same for the second one
[13:33] <seb128> doing the same
[13:33] <willcooke> seb128, I did it
[13:33] <seb128> cool
[13:33] <willcooke> #topic rls-dd bugs
[13:33] <willcooke> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html
[13:33] <willcooke> empty!
[13:33] <willcooke> #topic rls-ee bugs
[13:34] <willcooke> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-incoming-bug-tasks.html
[13:34] <willcooke> also empty
[13:34] <willcooke> dayyumm, good work team!
[13:34] <willcooke> #topic unassigned but targetted bugs
[13:34] <willcooke> seb128, shall we look at unassigned now?
[13:34] <willcooke> or do it off line
[13:35] <seb128> I'm not sure we need the team to 'fix' those
[13:35] <willcooke> agreed, let's move on
[13:35] <seb128> might be better to fix before the meeting so they end up out of the list or on the incoming report?
[13:35] <seb128> good :)
[13:35] <willcooke> yeah we should do that
[13:35] <willcooke> like we say every week :)
[13:35] <seb128> lol
[13:35] <willcooke> Mondays are not a good day to do it
[13:35] <seb128> I can review that list on mondays
[13:35] <willcooke> we can look in the mgr meeting tomorrow if we have time
[13:35] <willcooke> oki
[13:36] <willcooke> if we have time tomorrow we can look too
[13:36] <seb128> then I can ask about the ones I'm unsure in the meeting
[13:36] <seb128> k
[13:36] <willcooke> crap, it's raining, and the doors are open
[13:36] <willcooke> #topic AOB
[13:36] <willcooke> brb
[13:37] <seb128> willcooke, you forgot https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[13:37] <willcooke> seb128, that's what I meant by laney not being here
[13:37] <willcooke> lets look
[13:37] <willcooke> #topic proposed migrations
[13:37] <willcooke> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[13:37] <seb128> Laney created some cards on the board
[13:38] <seb128> so if you want to volunteer to look at some of the issues please do and add yourself to the card
[13:38] <willcooke> oh great
[13:38] <seb128> if no I think we review that in the managers meeting and do assignements there
[13:38] <seb128> if not*
[13:38] <seb128> wdyt?
[13:38] <willcooke> +1 lets do that,
[13:38] <seb128> also
[13:38] <seb128> tkamppeter, kenvandine, http://autopkgtest.ubuntu.com/packages/n/network-manager/eoan/amd64 n-m is still not fixed
[13:38] <kenvandine> tkamppeter: i thought you said the autopackage tests were fixed
[13:39] <tkamppeter> I saw them all passed in https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html yesterday.
[13:39] <seb128> kenvandine, tkamppeter, ah, sorry the recent tries are the previous version, the update is blocked on firewalld/n-m not liking each others
[13:39] <seb128> so we need to investigate that one as well
[13:39] <kenvandine> ok
[13:40] <kenvandine> tkamppeter: please look at that
[13:40] <seb128> tkamppeter, kenvandine, thx :)
[13:40] <willcooke> thx
[13:40] <seb128> willcooke, I think that's it for that section
[13:40] <willcooke> so please take a look at the cards and assign yourself to ones which you can fix, and we can assign as needed
[13:40] <willcooke> #topic AOB
[13:40] <willcooke> Anyone got anything to share?
[13:40] <seb128> I've a reminder that feature freeze is coming
[13:41] <seb128> we should probably do a review of where we stand for that in the next week?
[13:41] <willcooke> Did I read it was delayed by a week?
[13:41] <seb128> that was 18.04.3
[13:41] <willcooke> oh right, thanks
[13:41] <seb128> feature freeze is still on aug 22th
[13:42] <seb128> so some time but we should still review what is at risk
[13:42] <seb128> maybe something else for the manager's meeting tomorrow
[13:42] <seb128> but if anyone feels like they have a feature at risk please raise that up
[13:42] <seb128> willcooke, that was it from me
[13:42] <willcooke> thanks seb128
[13:42] <willcooke> anyone else?
[13:43] <willcooke> 5
[13:43] <willcooke> 4
[13:44] <willcooke> 3
[13:44] <willcooke> 2
[13:44] <willcooke> 1
[13:44] <kenvandine> :-)
[13:44] <oSoMoN> ignition
[13:44] <willcooke> #endmeeting
[13:44] <meetingology> Meeting ended Tue Aug  6 13:44:32 2019 UTC.
[13:44] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2019/ubuntu-desktop.2019-08-06-13.29.moin.txt
[13:44] <willcooke> thanks all
[13:44] <didrocks> thx
[13:44] <oSoMoN> thanks
[13:44] <seb128> thanks!
[13:45] <marcustomlinson> thanks
[13:51] <tkamppeter> kenvandine, seb128, I have looked into this test failure now and the debdiff of nm ubuntu5 -> ubuntu6 contains only my changes in the autopkgtest script, the code of NM is completely untouched.
[13:54] <tkamppeter> kenvandine, seb128, so either the failure is intermittent and one simply needs to restart this one test (I cannot as it requires upload rights of NM or firewalld) or in the meantime between the old NM ubuntu5 and the current ubuntu6 there was an update of firewalld 0.7.x (used only for arm64).
[13:55] <seb128> tkamppeter, you investigate and tell us what you figure out?
[13:56] <tkamppeter> seb128, this is what I found out, it would be nice if one of you (core-dev) could restart this test.
[13:56] <kenvandine> tkamppeter: yeah, check to see if there have been other uploads that affect this
[13:56] <kenvandine> sure, just ask anytime
[13:57] <tkamppeter> kenvandine, could you restart the test right now?
[13:57] <kenvandine> sure
[13:57] <kenvandine> looking at the firewalld history
[13:57] <kenvandine> this was failing for over a week
[13:58] <kenvandine> with a different version
[13:58] <kenvandine> so seems someone has been uploading new versions, perhaps trying to fix this
[13:58] <tkamppeter> All the others of NM passed and NM cannot be the culprit for this one as NM's code did not change.
[13:59] <kenvandine> tkamppeter: indeed, but we can't just assume someone else is going to fix it or even notice it's broken.  We need to figure it out and ping whoever is best to look at it.
[13:59] <tkamppeter> kenvandine what is also special with firewalld is that for arm64 a newer version is used.
[14:00] <tkamppeter> kenvandine, who is the maintainer of firewalld?
[14:00] <kenvandine> check he changelog
[14:00] <kenvandine> s/he/the
[14:01] <tkamppeter> OK, seems that it is best to report a bug on firewalld.
[14:01] <kenvandine> i've kicked the test, but not optimistic
[14:02] <kenvandine> but... looking at the running tests right now
[14:02] <kenvandine> i can tell he's trying to get the test to pass in his own ppa
[14:02] <kenvandine> Ppas:	['costamagnagianfranco/locutusofborg-ppa']
[14:02] <kenvandine> Triggers:	['firewalld/0.7.1-1ubuntu3']
[14:05] <kenvandine> tkamppeter: with a couple of minutes of digging i found he had a PPA build with a changelog entry of "verbose testsuite" and another PPA build with a changelog referencing a workaround of a kernel bug.  So sounds like he might be close to a fix
[14:09] <seb128> LocutusOfBorg is on #ubuntu-devel if you want to ping him
[14:09] <seb128> (brb, changing location)
[14:09] <tkamppeter> OK, thanks.
[14:19] <tkamppeter> kenvandine, I asked LocutusOfBorg, it is bug 1839154
[15:04] <k_alam> seb128: Hi, good afternoon
[15:06] <k_alam> Can you sync notify-osd launchpad source with trunk ?
[15:29] <seb128> k_alam, hey, sorry I was in a call ... how sync?
[16:04] <k_alam> seb128:  Sorry , got disconnected...
[16:05] <seb128> k_alam, no worry, I didn't understood what you were asking for
[16:05] <k_alam> seb128: Launchpad source is one commit ahead of lp:notify-osd
[16:06] <k_alam> it was merged without going through trunk
[16:08] <k_alam> https://launchpad.net/ubuntu/+source/notify-osd/0.9.35+16.04.20160415-0ubuntu3
[16:09] <seb128> k_alam, k, fixed
[16:10] <k_alam> Thanks.Another issue, can you make a 18.04 branch for unity-settings-daemon ?
[16:10] <k_alam> I have sru merge pending..
[16:17] <sil2100> seb128: hey! Is Laney out this week?
[16:45] <seb128> sil2100, yes, see UES holidays calendar
[16:46] <seb128> k_alam, I'm going to have a look to that but we can also upload with a debdiff
[16:46] <sil2100> seb128: ok, thanks o/
[16:47] <seb128> yw!
[16:48] <k_alam> seb128: Alright, I will try to provide a debdiff as well. Thanks
[16:49] <seb128> yw!
[17:19] <willcooke> night all
[17:25] <rbalint> seb128, imo it is not the test, and i reported the bug against gdm3 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934067
[17:26] <seb128> rbalint, thx, let's see what the maintainer says
[19:55] <bittin> Anyone has logs of tonights Ubuntu Desktop meeting?
[19:56] <tomreyn> bittin: same location as always: http://ubottu.com/meetingology/logs/ubuntu-desktop/2019/ubuntu-desktop.2019-08-06-13.29.moin.txt
[19:56] <bittin> tomreyn, thanks :)


[18:18] <john-davidge> Hello everyone o/
[18:19] <john-davidge> I have a question. Is it possible to change the 'magic' IP (<IP_ADDRESS>) cloud init uses to access EC2-style meta data with a config option?
[18:20] <JayF> I don't believe so; but IMBW
[18:23] <john-davidge> Interesting. Specifically I'm interested in using an IPv6 address instead of the default. Perhaps this will require a change to cloud inti
[18:23] <john-davidge> *init
[18:25] <harmw_> ipv6 metadata?
[18:25] <harmw> how whre you planning that?
[18:26] <JayF> Oooh. Fancy.
[18:27] <JayF> I like IPv6, would be interesting to hear how you get it working :)
[18:27] <harmw> ^ +1 :)
[18:27] <john-davidge> so I'm testing for cloud environments running on IPv6-only networks, and I'm trying to figure out what changes (if any) are needed to get cloud-init working
[18:28] <john-davidge> I'll do some more poking around and see what needs doing. Will keep you updated :)
[18:29] <JayF> Well you can always use configdrive with cloud-init
[18:29] <JayF> and just get rid of the metadata service
[18:29] <JayF> if you wanted to just not have to worry about that piece of it today
[18:33] <john-davidge> JayF: True, but I'm trying to cover all the bases for now.
[18:33] <harmw> I'm running IP6 cloud atm
[18:33] <harmw> with only metadata on V4
[18:36] <harlowja_> john-davidge so u can change it; the problem is that it needs to get the config from somewhere to change that value in the first place ;)
[18:36] <harlowja_> unless u have control over your images
[18:37] <john-davidge> harlowja_: Does that have to be changed on an image-by-image basis, or can it be passed at startup via user-data or similar?
[18:37] <JayF> well, unless you use configdrive
[18:37] <JayF> the metadata service is how user_data gets to the node :)
[18:38] <JayF> so you have a bit of a bootstrapping problem
[18:38] <harlowja_> yup :)
[18:38] <JayF> you have to make the default (last IP in v4 link local) work or patch your images to have a different cloud-init config
[18:39] <harlowja_> john-davidge the issue is 'passed at startup via user-data' (how does this data get to the image if not by the metadata service)?
[18:39] <john-davidge> Hmm, very true
[18:40] <john-davidge> What is the liklihood that cloud-init could adopt an IPv6 default as well as the current IPv4 default?
[18:41] <john-davidge> And does anyone know who I'd need to talk to about that?
[18:41] <harlowja_> u talking to the right people i think ;)
[18:41] <harlowja_> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/DataSourceEc2.py is where the ec2 stuff happens
[18:41] <harlowja_> and where said change would occur
[18:42] <harlowja_> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/DataSourceEc2.py#L42 could likely just have a ipv6 url, and it might 'just work'
[18:44] <harlowja_> although idk what ipv6 default that should use :-P
[18:45] <john-davidge> harlowja_: Thanks! Will poke around with it in the morning
[18:45] <harlowja_> k
[18:45] <john-davidge> harlowja_: Yes that's another debate!
[18:46] <john-davidge> I was thinking the easist might be the v4-in-v6 of the current default
[18:48] <john-davidge> Perhaps ::ffff:a9fe:a9fe
[18:51] <harlowja_> maybe
[18:51] <harlowja_> so then it'd be interseting to try that
[18:51] <harlowja_> if u are stuck on ec2, that might be hard
[18:51] <harlowja_> since u need somewhere that provides an ipv6 metadata service
[18:52] <john-davidge> harlowja_: I'm on OpenStack, so I can do what I want! :D
[18:52] <harlowja_> kk
[18:52] <john-davidge> harlowja_: Will give it a go and report my findings tomorrow. 7pm here in the UK so I'm clocking off for the day
[18:52] <harlowja_> kk
[18:52] <harlowja_> cool
[18:52] <john-davidge> Thanks for your help!
[18:53] <harlowja_> may the force be with u :-P
[18:53] <harlowja_> ha
[18:53] <john-davidge> Always!
[21:34] <tennis> hi... Where are the various files with "#cloud-config" supposed to live?
[22:04] <harlowja_> define live?
[22:04] <harlowja_> u can place them wherever u want
[22:33] <smoser> o/ just wanted to say hello.
[22:33] <smoser> tennis_, they live in /etc/cloud/cloud.cfg.d/whatever.cfg
[22:34] <smoser> or you can put them in as user-data.
[23:16] <tennis_> smoser: How does that relate to /etc/cloud/config.cfg?  That is, does /etc/cloud/cloud.cfg get ignored?


 Can you highlight me on unity 8 for 16.04 desktop. Does it brake gnome or unity 7 if installed on the same machine ?
 it shouldn't break them. currently the packages in the ubports repo are not installable though
 @Cédric, Remember to check on the frequency bands for your location!
 ok thanks, i'll give a look
[06:27] <ubptgbot> ybristes was added by: ybristes
 @Gorsh2, thank you for the hint
[07:35] <ubptgbot> koozyathebear was added by: koozyathebear
 sup guys
 poor russian guy need you assistance
 which smartphone choose to use with ubuntu touch in 2018?
 and where i can get it?
[07:37] <lotuspsychje> koozyathebear: check ubports.com
 already checked and can't find where i can buy devices from this list https://ubuntu-touch.io/devices
 hope there is another list of non-official supporting devices or smth
 The Fairphone 2 is the only of the devices, that is still on sale afaik: https://shop.fairphone.com/en/buy-fairphone2-2/
 If you are patient, you could wait for the Librem 5: https://puri.sm/posts/ubports-ubuntu-touch-on-librem5-collaboration/
 But both of them are quite expensive.
 You might still find an One Plus One for a reasonable price, I guess...
 @jonny, don't want to buy used device. checked china shops for meizu and oneplus one phones and got no results
 checked price for fairphone 2 and it's too expensive for poor soviet russian guy
 But you are a minister or not?
 that's just a joke bro
 russian junkie and nothing more
 😿
 @NotKit, Is this a libhybris alternative?
 Welcome @ybristes & @koozyathebear !!! Check out https://ubports.com/page/telegram-welcome to get you started, we have language groups available.
 @dohniks, not really, but it's possible way
 This is the best Ubuntu phone which is easily purchasable, for a good price, and with best specs. Ys it says "90% used" but that is a trick to prevent import tax from screwing you over with any luck. For all intents and purposes it is 100% new. You will have to flash Ubuntu onto it but the whole community is keen to help with
[09:24] <ubptgbot> that. Highest of recommendations.
 https://www.ebay.co.uk/itm/90-new-Meizu-PRO-5-64GB-4gbRAM-LTE-Unlocked-DualSIM-21Mcam-NFC-FastCharge/272196027342?hash=item3f6025c3ce:g:HCkAAOSwZtJW9UVP
 *Yes
 https://github.com/cmsj/nintendo-switch-ubuntu-builder
 (Photo, 1280x959) https://irc.ubports.com/Qu7n0sh7.png Arm 64 Ubuntu on nindento switch
 it's offtopic here don't you think @KrisJacewicz
 please join @ubportsOT
 [Edit] please join @ubports_OT
 [Edit] #Offtopic … https://github.com/cmsj/nintendo-switch-ubuntu-builder
 @vanyasem, yup, offtopic
 Probably not offtopic if unity8 is installed
 I always thought the switch was an interesting target for convergence
[10:37] <ubptgbot> InfamousJiraiya was added by: InfamousJiraiya
 @KrisJacewicz, Coooool
[10:42] <ubptgbot> Jose was added by: Jose
 oneplus 2?
 @InfamousJiraiya, Whats your question?
 @Flohack, (Can I install Ubuntu touch on my) oneplus 2?
 yes
 @InfamousJiraiya, Supported Devices: https://ubports.com/page/get-ubuntu-touch
 not available ;(
 anything else sir?
 How much for it to be able to flash
 time?
 how much time
 no ETAs sir, sorry
 Mercy Madame
[11:10] <ubptgbot> * mariogrip loves @vanyasem new picture :D
 @mariogrip, :3 thank you
[11:13] <ubptgbot> * xandrosdarkstorm
 Hey guys, one question: Sometimes I cannot switch  mobile Data on or off (button turned grey) and all the apps take a very long time to start … Reboot helps sometimes, but not always... :-( … Ist that a common bug and can I find some Info about that anywhere?
 Device is Nexus 5 @ 15.04
 @KrisJacewicz, 👍
 @InfamousJiraiya, @vanyasem this 😆
 oh i haven't noticed that lol
 Welcome @InfamousJiraiya & Jose !!! Check this put for more about UBports https://ubports.com/page/telegram-welcome
 @InfamousJiraiya, Probably OnePlusThree and 3T will be next, skipping the 2
 @Fabian, I've not seen this specific issue, but reboot is less reliable than a real switch off & switch on. (And sometimes switch off doesn't work first time.) … HTH
 OK thanks, I noticed that, too... … I actually just reset the phone, but I am still not allowed to turn mobile Data on...
 Maybe trying it through the terminal will be more reliable or at least give more information about the problem?
 @Stereofont, Did someone say oneplus 3?!
 @InfamousJiraiya possible, but needs work
 Someone like @dohbee should have the command to turn mobile data on/off from CLI at his fingertips IIRC.
 @TartanSpartan, Try turn on/off mobile data through the terminal? … Problem is: Mobile Data button is grey, which means right now I cannot turn it off.
 But the terminal should bypass any UI glitches.
 I guess... So hopefully someone knows the command X-)
 Probably worth doing a search of this SG for "data" "cellular" and related terms.
 Until the Rodneymeister wakes up and is ready to advise, that is.
 @Fabian, Try: … dbus-send --session --print-reply           \ …     --dest=com.ubuntu.connectivity1         \ …     /com/ubuntu/connectivity1/Private       \ …     org.freedesktop.DBus.Properties.Set     \ …     string:com.ubuntu.connectivity1.Private \ …     string:MobileDataEnabled                \ …     variant:boolean
[13:11] <ubptgbot> :false … sh get-mobile-data-enabled.sh
 @Fabian, [Edit] Try: … dbus-send --session --print-reply \ …     --dest=com.ubuntu.connectivity1 \ …     /com/ubuntu/connectivity1/Private \ …     org.freedesktop.DBus.Properties.Set \ …     string:com.ubuntu.connectivity1.Private \ …     string:MobileDataEnabled \ …     variant:boolean:false … sh get-mobile-data-enabled.
[13:11] <ubptgbot> sh
 @Fabian, [Edit] Try: … dbus-send --session --print-reply \ …     --dest=com.ubuntu.connectivity1 \ …     /com/ubuntu/connectivity1/Private \ …     org.freedesktop.DBus.Properties.Set \ …     string:com.ubuntu.connectivity1.Private \ …     string:MobileDataEnabled \ …     variant:boolean:false
 In a terminal
 To turn on, the same but with the last line variant:boolean:true
 https://wiki.ubuntu.com/Process/Merges/TestPlan/indicator-network
 The Meister of Rod respondeth
 Boom.
 Are we getting our fortnightly show this evening? Or is it on hold because of Jan's confrence?
[14:08] <ubptgbot> askmyhat was added by: askmyhat
 @askmyhat, Асхат, welcome
 @TartanSpartan, yes, next weekend
 @TronFortyTwo, Nice, that works, thank you very much! … Switch stays grey though...
 @dohbee, Was that related to my question? Because if, I do not get it... X-(
 @Fabian, 👍
 @Fabian, Yup, switch stays grey. Is your mobile connection works then or it's just switch has changed its position ?
 Connection works!
[14:48] <ubptgbot> MrAjAnderson was added by: MrAjAnderson
 Welcome MrAjAnderson!!! Check out https://ubports.com/page/telegram-welcome to get you up to speed
[16:23] <ubptgbot> VotecTox was added by: VotecTox
 Welcome @VotecTox!!! Check out this to get you started! If you have any questions, feel free to ask here or in our Welcome and Install room! … ubports.com/telegram-welcome
 @PhoenixLandPirate, I said 'next'. I didn't say 'soon' 😆
 @tydell, Turned out it just worked one time... Now I can just change the switch. Cellular Data still active...
 For me it doesnt work :( with cli command I can change switch position, but it is grey all the time and mobile connection also doesnt work
 Are you using a Nexus 5 too?
 It works for me now -> I reset the phone and did not log into wifi in the setup process... Question is now for how long it will work.
[17:52] <ubptgbot> ChiluveruSra1 was added by: ChiluveruSra1
 Hello everyone
 Can u develop Ubuntu touch os for leEco phones
 Fwd from BrisPete: We'd love to support as many devices as possible. Unfortunately porting a new device takes a long time and there are only a few of us doing the work. More developers working on porting devices would mean more devices ported. This will particularly be true when the Halium Project is successful.
 @ChiluveruSra1, Someone with a phone would need to try it. https://docs.ubports.com/en/latest/porting/introduction.html
 But it is a difficult process.
 Yeah
 will it support 1+3
 @jonny, Can u help me out in doing this
 @ChiluveruSra1, I am not very experienced in Porting. But there is a Telegram group for Halium, where you can get help: https://t.me/halium
 Ooh … Thnk yu
 @ChiluveruSra1, Here you can find the Status: http://docs.halium.org/en/latest/supplementary/devices/oneplus3.html
 It will become a ported device I guess.
 @jonny, Bug me and @sk8higher
 We are the ones behind that port
 :P
[18:25] <ubptgbot> SuVuK was added by: SuVuK
 Oh cool. 👍🏿
 @ChiluveruSra1, Someone started on a le eco phone I think
 Fwd from mayltonfnds: https://forums.ubports.com/topic/1169/porting-halium-to-leeco-le-max2-aka-x2-x820
 Btw, awesome talk from @neothethird at ubucon europe 2018 xixon
 Other LeEco devices would be entirely different than that one
 @arudy, Recorded?
 @Stereofont, Also interested
 Welcome @SuVuK!!! Check out https://ubports.com/page/telegram-welcome to get you started, we have language groups available.
 @arudy, is there any recording of it?
 @ubports_news if there is, it will probably be pasted there. A good reason for anyone who hasn't joined that channel to do so now
 👍
 Guys seems like Switch is gonna get mainlined faster than any of our snapdragons
 (Photo, 1280x960) https://irc.ubports.com/6TLXAO0c.png
 @Fabian, Yes, I have N5 too. After phone reset it works for me sometimes and sometimes not. It usually works for me till my battery got empty or first reboot :(
 @Stereofont, They say Nerdzoom will publish?
[20:08] <ubptgbot> Werner Oberegger was added by: Werner Oberegger
[20:12] <ubptgbot> <Werner Oberegger> Hi. I have Trouble installing Ubuntu Touch via the ubports-installer on my bq aquaris m10hd. The prompt says: FAILED (remote: download for partition 'recovery' is not allowed. Help would be greatly appreciated.
 Welcome Werner! Find the most important info here: https://ubports.com/page/telegram-welcome Specifically, please join our Newcomers Room (Welcome & Install) for support for such questions. Enjoy your stay!
[20:22] <ubptgbot> Benedikt was added by: Benedikt
 Hi Benedikt! You too, please read https://ubports.com/page/telegram-welcome and feel free to ask any question!
 Hello :)
 @peternerlich, Danke kenne schon alles ^^ Aber Danke :)
 Dann möchtest du vielleicht auch @UBports_Deutsch beitreten
 Bin ich schon :)
 ha 😁
[20:30] <ubptgbot> <Werner Oberegger> Thank you for the warm welcome 😀
 @arudy, thanks :)
[21:26] <ubptgbot> <Andre Büsgen> I just installed telegram on my device and got a question: Do encrypted chats work already?
 No, sadly
 The whole base of Telegram is being rebuilt, so we should move forward dramatically with that. At the moment we adapt old Cutegram
 Maybe 2018 but not soon ™
[21:29] <ubptgbot> <Andre Büsgen> Thanks this was very helpful. I thought I did something wrong ;)
 @Andre Büsgen, You are taliking about secret chats, I assume
[21:30] <ubptgbot> <Andre Büsgen> Yes, indeed.
 Maybe somebody has more detail but that is the outline of the situation
 Telegram CLI would propably work and it supports encrypted chats. But chatting in the terminal is not so much fun. 😁
 Would some admin fix the group info? The "Supported devices" link isn't to supported devices 😉
 You mean the website?
 @Stereofont, No the TG group info here lol
 Hamburger menu top right corner
 Done
[22:13] <ubptgbot> Ash Walker was added by: Ash Walker
 @Ash Walker, Hello Ash. Check the link for information about UBports … https://ubports.com/page/telegram-welcome
[22:14] <ubptgbot> <Ash Walker> 👌
 @Stereofont, Well I've been linking to the wrong website when directing people to the supported devices. Nice to know 🙂
 Lol
 Lol I've been sending people to ubuntu-touch.io/devices
 They also get a Patreon option
 I saw that lol
 @amolith, That is the newer site. I think it has the same info
 It has a lot more devices
 the ubports.com/devices does I mean
 [Edit] the devices.ubports.com does I mean
 But it says wrongly that legacy will not get 16.04
 We need the best of both maybe
 Also it should mention Liberapay
 Anyway, for now there is a list in the link 😊
 @Stereofont, Lol yes 🙂
[22:23] <ubptgbot> Vincenzo was added by: Vincenzo
 @Vincenzo, Hi Vincenzo. Have a look at the link for an intro to UBports … https://ubports.com/page/telegram-welcome
 (Sticker, 512x256) https://irc.ubports.com/7W16WVFK.webp
 No spam please
 @hwpplayer1 I was one tap from banning you like any other spammer on Telegram. Do be more careful.


[03:59] <guiverc> Bashing-om, just FYI, but I've 'suggested' a change on gdoc.. you can look when you copy to wiki maybe & ignore/accept  (minor or petty change)
[04:00] <Bashing-om> guiverc: Looking - I got time now :)
[04:00] <guiverc> Linux Review (Kubuntu)
[04:14] <guiverc> I'm happy Bashing-om
[04:16] <Bashing-om> guiverc: Hey we done good - // "Ubuntu Summit 2023 " move up to the Planet and summarize ?
[04:18] <guiverc> it'll draw more attention to it.. I'm maybe 60% yep..  I'm writing a reply to something so could write summary in ~3-5 mins maybe
[04:20] <Bashing-om> guiverc: No hurry - I would feel the better placed in Planet - now that the blog has made that appearance on the Planet.
[04:23] <guiverc> you can move & ready it; I can write a summary in a min or so
[04:32] <Bashing-om> doing ^
[21:58] <Bashing-om> UWN: Issue789 up for review and final edits: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue789 :D


[20:34] <Palintheus> ;
[20:35] <davies> ;)*
[20:36] <Palintheus> bah...irssi was slow on the window change


[04:09] <Kon-> Hi, after updating the kernel on Bionic, dpkg shows I have both 4.15.0-32.35 and 4.15-32.34 installed
[04:09] <Kon-> https://images2.imgbox.com/1c/20/xLsu5m6M_o.png
[04:10] <Kon-> Package history tells me many 30.32 files were upgraded to 32.34, but then 32.35 files were installed for the first time
[04:17] <Kon-> Here's the package history showing some files were upgraded to 32.34 while 32.35 was also installed https://images2.imgbox.com/4f/5c/lA8G6cNc_o.png
[07:46] <apw> Kon-, no that is showing you you have linux-image-* at 4.15.0-32.35 and linux-image-generic at <IP_ADDRESS>.34 ... the first is always new, the second is upgraded; but they are distinct
[07:47] <apw> the second is the meta package and comes from a different source; it is this that drives installation of the other
[07:47] <apw> this is the mechanism by which it is possible to have >1 kernel installed
[20:50] <juliank> I'm seeing files disappearing on my btrfs system on 4.17 (a few each day). I guess I'll revert to 4.15 and see if that is affected too. Is there any data I should collect?
[20:51] <juliank> My $HOME is pretty well backed up so I'm not worrying a lot
[20:51] <tsimonq2> Git bisect? XD
[20:52] <juliank> that's with the -6 kernel
[20:53] <juliank> tsimonq2: It needs a day per step...
[20:53] <juliank> roughly
[20:53] <juliank> I see at least one new file disappearing each day
[20:53] <tsimonq2> Ah, I was half joking, but hey :)
[20:53] <juliank> today it ate my keepass keyfile
[20:54] <juliank> now I gotta copy it over again from my other machine :/
[20:54] <juliank> or the backup, I think it has a copy as well
[20:54] <juliank> And the backup server runs ZFS in raid-z2 I think, so that data is fairly safe
[20:59] <tsimonq2> Perhaps try and find a pattern...


[00:16] <mdeslaur> nacc: ugh :(
[00:22] <nacc> mdeslaur: yeah, i went through this before too -- i'll keep hacking at it
[00:23] <nacc> fun, swig upstream got php7 support
[00:24] <nacc> mdeslaur: one issue (present in debian too), seems to be an off by one somewhere (0-255 is expected, but 1-256 is being used, maybe?)
[01:00] <nacc> mdeslaur: i wonder if it's a comlete thinko on my part and these two need nochange rebuilds! let me test
[01:24] <nacc> mdeslaur: yep that was it (still the one failure i need to figure out)
[01:42] <nacc> mdeslaur: and that fixes the ruby-rmagick regression too
[04:44] <chiluk> sarnold you are absolutely correct.   I'll re-work it tomorrow, as it's on my laptop, and that's downstairs.
[04:45] <sarnold> chiluk: eod, very good idea :) just about time for me to go find tacos...
[04:46] <chiluk> sarnold where are you at that you have tacos?
[04:46] <sarnold> chiluk: portland
[04:46] <chiluk> hmm not what I was expecting.
[04:46] <sarnold> :)
[04:46] <chiluk> well have a good night... I'll harass people tomorrow about yakkety.
[04:47] <sarnold> there's a hole-in-the-wall style of fast-food-iksh taco place less than a mile from home. it's dangerous. :)
[04:47] <sarnold> thanks, you too
[06:56] <pitti> Good morning
[08:13] <seb128> wgrant, hey, do you think we could start langpack exports for zesty?
[08:13] <seb128> tuesday might be a good day for those
[08:13] <seb128> looking at looking at https://dev.launchpad.net/Translations/LanguagePackSchedule
[09:04] <pitti> zyga: good morning! I just filed bug 1646036; I'm happy to just upload it to Ubuntu, but that would introduce a delta; i. e. it would be better (also for Debian) if you would fix that straight in Debian and we'll let it sync?
[09:09] <pitti> Laney: hm, I really wonder why the amqp queues are so heavily lopsided towards i386 -- perhaps it helps if we shuffle "arches" in the worker?
[09:10] <pitti> my best guess is that each time a worker restarts (and these days they do that very often, apparently some cloud instability again) they grab the next 70 i386 requests, and this adds up
[09:10] <pitti> so if we randomize the arches array first, it should equalize a bit
[09:12] <Laney> pitti: I read the code last time and couldn't really tell why it prefers one queue over another
[09:12] <Laney> maybe the server always delivers the queue you connect to first?
[09:12] <pitti> Laney: my best guess is that "architectures = i386 amd64" in the config and we connect to the queues in that order
[09:13] <pitti> and that order somehow matters in the round-robin
[09:16] <pitti> Laney: I committed https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=38331c768 and deployed it
[09:16] <pitti> Laney: in the best case it works, and in the worst case it's a no-op
[09:18] <Laney> pitti: I was RTFMing
[09:18] <Laney> sounds like it might be prefetching (that's what you were saying?) and so it could help to lower the count
[09:19] <pitti> Laney: I read the amqp docs a while ago, and I couldn't spot anything relevant; infinity already pointed this out at the previous glibc update, and I didn't find a "proper" solution back then
[09:19] <pitti> Laney: prefetch count is 1
[09:19] <Laney> meh
[09:19] <Laney>     queue.basic_qos(0, 1, True)
[09:19] <Laney> I see
[09:20] <pitti> but the only assymmetry that I can see is the ordered architecture list
[09:21] <Laney> that probably works around it
[09:21] <pitti> Laney: so the elaborate answer would be "By randomizing the input values, assymmetric distribution in the AMQP implementation is rendered irrelevant"
[09:21] <pitti> (real answer: "NFC, let's hack around it")
[09:22] <Saviq> seb128, hey, need a bit of help with the migration of our last silo - can you please recycle the two reds (we're looking into why we didn't get those failures before) http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#ubuntu-settings-components
[09:23] <Saviq> seb128, and I need guidance on what to do with unity8 just below, we have a new dependency (qml-module-qtqml-statemachine) that's in universe (it comes from qtdeclarative-opensource-src), do I need a MIR?
[09:23] <seb128> Saviq, clicked them, let's see how it's working out
[09:24] <Saviq> thanks
[09:24] <seb128> Saviq, you don't need a MIR if the source is already in main, just land it and it's going to be listed on component mismatch and then an archive admin needs to promote the new binary
[09:25] <seb128> but we usually wait for the depends to land
[09:25] <seb128> because otherwise component mismatch lists it for demotion because then it's in main without reason
[09:25] <Saviq> seb128, right, it's here then http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#unity8
[09:25] <Saviq> already waiting for the promotion
[09:26] <seb128> k, so your side is done
[09:26] <Saviq> but I suppose it's waiting for the others from that silo, too
[09:26] <Saviq> seb128, ack, thanks!
[09:26] <seb128> yw!
[09:26] <seb128> well, tests retried, let's see
[09:55] <zyga> pitti: looking
[09:55] <zyga> pitti: good morning :)
[09:56] <zyga> pitti: this is just more stale stuff in checkbox, I'll have someone remove it
[09:56] <pitti> zyga: thanks
[09:56] <pitti> ideally we'd be able to completely remove the package, but powernap is the only hard dependency left
[09:56] <pitti> kirkland: ^ who maintains that these days?
[09:57] <zyga> spineau, kissiel: ^^ hey, can one of you guys look at https://bugs.launchpad.net/ubuntu/+source/plainbox-provider-checkbox/+bug/1646036 please
[09:57] <kissiel> zyga: ack
[09:58] <zyga> kissiel: please fix it upstream and in debian, I can assist with debian side if required
[09:58] <pitti> Laney: I'm considering to remove the remaining amd64 glibc test requests; it's been tested on the other architectures, and realistically we won't get it all to green anyway; WDYT?
[10:01] <pitti> and the regressions look rather consistent on the other arches anyway, so we have enough data to go through already
[10:06] <pitti> sakrecoer: hey Set, how are you? I sent https://code.launchpad.net/~pitti/ubuntu-seeds/ubuntustudio.zesty.drop-pm-utils/+merge/312134 (trivial), would you have a minute to merge/pull it?
[10:07] <Laney> pitti: ok - will they stay as in progress forever?
[10:07] <pitti> Laney: yes; but I expect we'll need a force-skiptest after reviewing the regessions anyway; there are definitively some unrelated ones (I didn't review all of them yet)
[10:08] <pitti> the apt one looks suspicious, it started failing with new glibc
[10:08] <pitti> Laney: I already ran a mass-retry on armhf and s390x yesterday to weed out the flaky ones, FYI
[10:10] <pitti> the history on http://autopkgtest.ubuntu.com/packages/a/apt/zesty/armhf looks pretty unambiguous, but I'm confused how
[10:10] <pitti> -   - Filesize:3 [weak]
[10:10] <pitti> +   - Checksum-FileSize:3 [weak]
[10:10] <pitti> can be glibc related
[10:10] <xnox> pitti, tah.
[10:11] <pitti> xnox: good morning; WDYM? :-)
[10:12] <xnox> pitti, I have highlights on s390x =) and you said you mass-retried it.
[10:12] <pitti> oh
[10:12] <xnox> pitti, also i suspect that autopkgtest-build-vm does not work on s390x properly =/ as i'm failing to build a vm for qemu adt test runs. However, it might be me and my network proxy at fault.
[10:12] <xnox> will dig deeper into that.
[10:13] <pitti> xnox: ack, thanks; I don't have any machine to try this on
[10:15] <cpaelzer> xnox: with pitti I got some of the blockers out of the way about 3 weeks ago, but not all
[10:15] <cpaelzer> xnox: I still fixed up the tty spawning manually
[10:15] <pitti> ah, the serial console stuff
[10:15] <xnox> cpaelzer, yes that's what i have blocking me i believe.
[10:15] <cpaelzer> pitti: I think we documented in the bug what would have to be done
[10:15] <cpaelzer> but so far only did manually
[10:15] <xnox> cpaelzer, and i had to fix before, in e.g. curtin test-suite
[10:16] <cpaelzer> let me search the bug for you
[10:16] <xnox> (use -no-defaults, specify everything "by-hand")
[10:16] <xnox> i'm sure things can be copy&pasted from curtin test-suite fixes i did a while back.
[10:16] <pitti> could this be fixed in qemu itself, that defaults and a thing like "-serial unix:..." would actually work?
[10:16] <cpaelzer> xnox: bug 1630909
[10:17] <pitti> seems odd having to work around this in every qemu consumer
[10:17] <xnox> pitti, i think it should, i have not raised it with upstream. The problem is that with x86 - qemu supports multiple consoles and that flag creates a new console.
[10:18] <xnox> with s390x qemu there is no multi-console support, and the one is already defined as defaults, and flags like -serial do not supplement/override the default behaviour.
[10:18] <xnox> i guess i should raise this with upstream.
[10:18] <xnox> (again)
[10:18] <cpaelzer> we added extra virtio-serial back then
[10:18] <cpaelzer> I think you een suggested that xnox
[10:18] <cpaelzer> the bug holds all notes I had with my WIP on this
[10:19] <cpaelzer> if you want to leverage anything - but it seems your own old notes covered just as much
[10:19] <xnox> tah! will look more into it.
[10:19] <xnox> ubottu net split =)
[10:22] <pitti> Laney, infinity: FTR, remaining glibc amd64 test requests killed
[10:27] <Laney> pitti: I expected that to kill a bigger percentage of the queue :)
[10:27] <pitti> Laney: well, 2600 → 800 isn't to be sneezed at :)
[10:30] <pitti> Laney, infinity: I went through, and these cannot be trivially excluded to be unrelated: apt gnome-color-manager gspell mercurial why
[10:30]  * pitti creates a bug
[10:33] <pitti> infinity1: bug 1646064
[10:50] <Laney> pitti: gtk+3.0 segfaults too
[10:50] <Laney> hmm
[10:50] <Laney> HMM
[10:50] <Laney> it did that with mesa also
[10:52] <pitti> Laney: right, but happy to add it to the list, to be safe
[10:52] <pitti> should at least compare a local run against -release and -proposed
[10:52] <pitti> bug updated
[10:53] <Laney> it passed when triggered by itself anyway
[10:53] <Laney> worrying
[13:19] <ChrisTownsend> seb128: Hey!  If I have a binary package that I want in main, do all Recommends of that package have to be in main as well or is it just Depends?
[13:20] <xnox> ChrisTownsend, main is depends, pre-depends, recommends, built-using
[13:21] <ChrisTownsend> xnox: Ok, thanks!
[14:54] <chiluk> sarnold: fixed https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1634304  ... looks like I accidently built the sources against oringal sources that I had accidently rebuilt with newer versions... That was the reason for it being malformed.
[14:54] <mdeslaur> nacc: looks like you need to rebuild php-imagick with the new imagemagick. Some of the tests rely on functions that are missing because it was built with the old version.
[14:54] <chiluk> sarnold: rather built the debdiff against bad originals.
[14:58] <kirkland> pitti: I suppose that's roaksoax and myself
[14:58] <kirkland> pitti: though neither of us have touched it in forever.
[14:58] <kirkland> pitti: what needs to be done?
[14:59] <pitti> kirkland: wean it off pm-utils (see bug 1646036)
[14:59] <pitti> kirkland: we haven't used pm-utils since 15.04, it's just dead weight and its quirks can even be detrimental these days
[14:59] <pitti> kirkland: suspend quirks, I mean
[15:00] <pitti> kirkland: so for the most part it should be an exercise in sed'ing s/pm-suspend/systemctl suspend/g and the like, but I haven't checked what else it does with pm-utils
[15:02] <pitti> kirkland: or directly use /sys/power/state, if you don't care about userspace inhibitors (which aren't really a server thing anyway)
[15:07] <kirkland> pitti: oh, okay -- that sounds very doable
[15:08] <kirkland> pitti: can you stash just such a bug away against pad.lv/u/powernap ?
[15:08] <kirkland> pitti: and I'll get to it?
[15:08] <pitti> kirkland: that bug already has a powernap task
[15:11] <kirkland> pitti: cool -- #?
[15:11] <pitti> kirkland: bug 1646036
[15:11] <kirkland> pitti: thanks.
[15:28] <rbasak> pitti: could you please take a look at bug 1642966?  Thanks! Let me inform the team first, not that i don't trust you, but you know where my skills at (an inch above the bottom) :D
[16:01] <pitti> barry: thanks for your interest wrt. RFH autopkgtest! I added it to our sprint agenda next week
[16:02] <barry> pitti: +1
[16:02] <barry> pitti: been thinking about doing that anyway.  wish it were under happier (for us ;) circumstances
[16:03] <pitti> barry: so, a *python* tool for you for a change! :)
[16:04]  * barry can't wait to get his grubby little hands on it :)
[16:05] <niedbalski> pitti, rbasak any of you could accept https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1432935 for Trusty series?
[16:05] <rbasak> niedbalski: my queue is overflowing at the moment :-(
[16:07] <niedbalski> rbasak, it's just the series nomination, no patch yet :)
[16:07] <rbasak> Oh. I can do that :)
[16:07] <rbasak> Done.
[16:08] <niedbalski> rbasak, thanks!
[16:37] <nacc> so clearly I'm missing something (or it was too late last night when I thought of it). If I have two packages that need to be rebuilt using deps (all binary-pkgs from one specific src-pkg's in -proposed), do I need an AA to help do that?
[16:38] <nacc> submitting a no-change rebuild re-used what is in the release pocket
[16:39] <nacc> in this case, i'm referring to imagemagick + php-imagick + ruby-rmagick -- although i'm still debugging a testcase failure, the latter two need to be rebuilt agains the imagemagick in z-p
[17:03] <dmj_s76> sforshee: How do you feel about having the linux-firmware package update the initramfs on install/update?  There was a fair bit of "sticky" behavior that made this hard to debug and seen non-deterministic because it doesn't?
[17:03] <dmj_s76> I'm testing your package now.
[17:06] <sforshee> dmj_s76: that might be okay, linux-firmware generally isn't updated that frequently anyway
[17:07] <infinity1> nacc: You probably need patience, not an AA.
[17:08] <infinity1> nacc: All builds in proposed happen against proposed (if they didn't we'd never get transitions of any sort done), but you can't build against a binary until it exists in the archive, published.
[17:08] <infinity1> nacc: ie, make sure rmadison says it's there.
[17:13] <smoser> nacc, what is yakkety-devel ?
[17:13] <smoser> https://git.launchpad.net/~usd-import-team/ubuntu/+source/ifupdown/refs/heads?h=ubuntu/yakkety-proposed
[17:25] <rbasak> smoser: it's the equivalent of "pull-lp-source yakkety". IIRC, that's the highest of release,security,updates. So I can base a branch from where without having to look it up.
[17:26] <rbasak> s/where/there/
[17:26] <smoser> rbasak, thats nice. kind of what i expecred, but i didnt think about security
[17:26] <smoser> so didnt' realize difference from -proposed
[17:27] <rbasak> smoser: also, if there has never been a stable update, then the package won't exist in the other pockets. So you'd have to look up or get an error.
[17:33] <smoser> rbasak, usd build-source -v
[17:33] <smoser> ...
[17:33] <smoser> 11/30/2016 12:32:57 - DEBUG:Checking if upstream version of publish <IP_ADDRESS>ubuntu8 matches 0.8.10ubuntu1.2
[17:33] <smoser> 11/30/2016 12:32:57 - DEBUG:Checking if upstream version of publish <IP_ADDRESS>ubuntu7 matches 0.8.10ubuntu1.2
[17:33] <smoser> ...
[17:33] <smoser> what is that ?
[17:33] <rbasak> Not sure. nacc? ^
[17:33] <bdmurray> tseliot: Could you have a look at bug 1639663?
[17:41] <nacc> infinity: yeah, that's why i was confused; oh i wonder if it's because of this message about imagemagick: old binaries left on amd64: imagemagick-dbg, libmagick++-6.q16-5v5 (from 8:<IP_ADDRESS>-7ubuntu10) ?
[17:42] <nacc> smoser: the algorithm for caching is:
[17:43] <infinity> nacc: Generally not.  Which package failed to pick up the new imagemagick?
[17:43] <nacc> smoser: for dist in ubuntu, debian: for published versions in dist, see if upstream of publish matches upstream of version to build
[17:43] <nacc> infinity: ruby-rmagick 2.15.4+dfsg-2build1
[17:44] <nacc> infinity: oh wait!
[17:44] <nacc> infinity: hrm, the build used the right deps, but the autopkgtest is using the release version?
[17:45] <infinity> nacc: Yes, that's generally correct.
[17:45] <infinity> nacc: If there was an undeclared ABI break, that would indeed, break.
[17:45] <nacc> infinity: ok, it's a hard-dependency, though (and using the wrong imagemagick will lead to segfaults)
[17:45] <nacc> infinity: yeah, i think that's what's going on -- i'll see if i can suss it out in debian
[17:46] <nacc> infinity: in theory, then, though, could I force the dep in the tests to be the same that is built against?
[17:47] <infinity> nacc: We can force that on the infra side.  However, that doesn't solve the bug. :P
[17:47] <infinity> nacc: Forcing it in the packaging means making your dependencies more strict.
[17:48] <infinity> nacc: If it's a question of ABI breaking, the SONAME should be bumping.  If it's some more nefarious "versions must always match because $obscure_reason", dependencies need to reflect that.
[17:49] <infinity> nacc: Fudging any of this on the test side is the wrong way of thinking about it.  The tests are rightly testing that your declared deps work.  And they don't.
[17:50] <nacc> infinity: so, my understanding of both php-imagick and ruby-rmagick, is they link to a specific version of imagemagick's -dev libraries. That defines some ABI dependency, clearly. It only make sense (and is only possible) to test the resulting binary package using the same imagemagick to satisfy the dependencies.
[17:50] <nacc> infinity: I understand what you are saying, but this is probably why the autopkgtests have rarely passed on Debian :)
[17:51] <nacc> infinity: every imagemagick upload needs to rebuild these two packages, and only test against that version, if that makes sense
[17:51] <nacc> infinity: which i think implies the test dependency is wrong (too broad)
[17:51] <infinity> nacc: If every imagemagick upload breaks ABI, but the rdeps don't have a dependency that reflects that, imagemagick's shlibs are wrong.
[17:51] <infinity> nacc: The *test* dependency is correct.
[17:52] <infinity> nacc: If you can install the packages in this broken state, the packages are broken, not the test.
[17:52] <infinity> (Indeed, the test is doing its job of exposing broken packages)
[17:53] <nacc> infinity: yes, I see what you mean now
[17:56] <mdeslaur> it's not an ABI issue
[17:56] <mdeslaur> php-imagick is parsing the imagemagick version string both during compilation and during the tests and there's a mismatch
[17:57] <smoser> nacc, so i
[17:57] <smoser> so i'm confused. i did: usd build-source
[17:57] <nacc> mdeslaur: right, but i think ruby-rmagick's failure is different
[17:57] <nacc> mdeslaur: in that it's a segmentation fault in imagemagick, afaict
[17:57] <smoser> and it is doing all this network traffic ?
[17:57] <mdeslaur> oh, perhaps, I didn't look at that one
[17:58] <smoser> maybe this is because its a native package
[17:58] <nacc> smoser: `usd build-source` is a wrapper around dpkg-buildpackage. But it needs an orig tarball, etc. to build. In the case of a native package, that algorithm may be wrong
[17:59] <nacc> smoser: which src pkg?
[17:59] <nacc> mdeslaur: so maybe there are two cases here :) one is an ABI dependency (I think) and one is a symbol dependency (of sorts -- the symbol being the version of imagemagick as defined by MagickLibVersion or whatever)
[18:00] <smoser> ifupdown
[18:00] <nacc> smoser: the algorithm also does break if it's a fully new upstream publish, as it wont' find a common ancestor (but that is also expected)
[18:01] <smoser> right, but it broke in that i got tired of sitting there after 60+ seconds
[18:01] <nacc> smoser: well, that's a usability issue :)
[18:01] <smoser> maybe recognize native package (no '-' in version) and special case that ?
[18:02] <nacc> smoser: i'm not sure it should matter, actually
[18:02] <nacc> smoser: ah you're right
[18:03] <nacc> smoser: is that check sufficient?
[18:06] <smoser> i'm not certain
[18:07] <nacc> smoser: http://paste.ubuntu.com/23559120/ or so
[18:08] <nacc> smoser: does that speed up your case, at least? i'll do some resarch into native package detection
[18:17] <smoser> nacc, yes. your logging.info is missing a stirng fwiw
[18:17] <nacc> smoser: ack :)
[18:18] <nacc> smoser: sorry, this is a thinko on my part, i even documented it but forgot to put it in
[18:19] <nacc> smoser: i think that will trigger false positives for '-' in upstrema versions
[18:20] <smoser> ?
[18:20] <smoser> i dont think so
[18:20] <smoser> if there is *no* '-' in the full version, then it is a native package.
[18:21] <smoser> if there is a dash, then there is no upstream version to have a '-' in its version
[18:21] <smoser> as it is a native package.
[18:21] <smoser> er..we... let me re-say that.
[18:21] <smoser> if there is a dash, then it is not native version
[18:21] <nacc> smoser: err, right
[18:22] <nacc> smoser: yeah, ok, i think this is sufficient for now, at least
[18:22] <infinity> nacc: smoser, Debian policy, and dpkg all agree.  Our archive disagrees occasionally (lol, linux), but those cases should be rare, and the uploaders know they're breaking the rules. :P
[18:23] <nacc> infinity: thanks!
[18:23] <smoser> nacc,
[18:23] <smoser> https://www.debian.org/doc/debian-policy/ch-binary.html
[18:23] <smoser> If punctuation is desired between the date components, remember that hyphen (-) cannot be used in native package versions.
[18:23] <nacc> yep
[18:23] <nacc> thanks!
[18:24] <smoser> so i guess that is not the same as what we're saying here...
[18:24] <smoser> hyphens cannot exist in native packages != if it does not have a -, then it is a native package.
[18:24] <nacc> smoser: right, it's one subset
[18:25] <infinity> smoser: It's indeed an exclusive rule.
[18:25] <nacc> smoser: so a hyphen being present means it's not native, but there is still no positive detection of native packages (beyond maybe looking debian/source/format?0
[18:25] <infinity> non-native *must* have a '-'
[18:25] <infinity> native *must not* have a '-'
[18:26] <infinity> Our archive has rule-breakers (as I said), but they're few.
[18:26] <infinity> And totally unimportant packages, like kernels.
[18:26] <smoser> oh. ok.
[18:26] <nacc> infinity: ah you're right!
[18:27] <smoser> nacc, so why did that go looking on the internet (via launchpad) for a orig tarball or dsc rather than checking my nicely local lpusip/importer/debian/dsc branch
[18:27] <nacc> smoser: because we said all along the tooling would not rely on that
[18:27] <nacc> smoser: it didn't necessarily exist
[18:28] <smoser> well, it idd.
[18:28] <nacc> smoser: you're welcome to make coding changes too :)
[18:28] <smoser> inded
[18:28] <nacc> smoser: or file a feature request
[18:28] <smoser> ya.
[18:28] <nacc> smoser: but our original goal with that tool was *just* to wrap `pull-lp-source` appropriately
[18:28] <nacc> smoser: we added the dsc and pristine-tar branches later
[18:28] <smoser> right
[18:29] <nacc> smoser: so we could use those, now that we've decided to keep them, it seems like
[18:29] <nacc> and fallback to pull-lp-source/pull-debian-source when that fails to get us the rigth tarball
[18:30] <nacc> smoser: also not all packages have been re-imported with the DSC branch for older imports -- so it was going to complicate the code to try to use file that may or may not exist in the repo first, etc. -- not to say we can't or won't, just not a first step
[18:31] <nacc> smoser: lastly, i was worried about having two ways of doing things / relying on our repository to be correct for orig tarballs. I'm much more comfortable trusting Launchpad itself :)
[18:33] <nacc> smoser: pushed then native pkg fix up
[18:34] <smoser> nacc, and i'
[18:34] <smoser> and i'm sure that launchpad appreciates you pounding its api  :)
[18:34] <smoser> for data that you had locally, all nicely and cleanly collected once.
[18:35] <nacc> smoser: you seem to care more about launchpad than correctness :)
[18:35] <nacc> smoser: i get your point, though, i think the new functionality is more stable now
[18:54] <smoser> hey... question
[18:54] <smoser> we have an 'all' arch package (curtin) and we'd like to add a dependency on a package only on one arch
[18:54] <smoser> info at https://code.launchpad.net/~ltrager/curtin/lp1640519/+merge/310604
[18:55] <smoser> i'd like to have a depends on flash-kernel on arm64 and armhf, but not on others.
[18:55] <smoser> but i guess since we're only building one deb, thats not possible.
[18:55] <smoser> is there a solution for that ?
[18:55] <smoser> ltrager, ^ fyi
[18:58] <sarnold> smoser: does this look useful? https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps search for "restricted"
[18:59] <nacc> smoser: right, could you specify flash-kernel [arm64 armhf] ?
[19:00] <smoser> nacc, well, you cant. because it is only building one deb
[19:01] <smoser> ie, i'm pretty sure that is build-time not runtime
[19:01] <nacc> ah yes
[19:01] <nacc> "This means that architecture restrictions must not be used in binary relationship fields for architecture-independent packages (Architecture: all)."
[19:01] <smoser> yeah
[19:01] <smoser> thats what ltrager was seeing
[19:02] <nacc> i guess you're making it explicitly not architecture-independent at this point, though
[19:07] <nacc> infinity: mdeslaur: for ruby-rmagick, I think I see the issue, but still figuring out how to resolve it (i don't know much about ruby packaging). During the build, it prints: 'Ruby 2.3.3 (x86_64-linux-gnu) and ImageMagick 6.9.6' (which implies a dependency). And the test builds that way. But when the control file is generated later, "Depends: ruby (>= 1:2.3~0), libc6 (>= 2.14), libmagickcore-6.q16-2
[19:07] <nacc> (>= 8:<IP_ADDRESS>), libruby2.3 (>= 2.3.0~preview2)"
[19:10] <sarnold> aww :(
[19:13] <mdeslaur> nacc: it's autogenerating that from the symbols file in the imagemagick package. Let me see what the failure is, one sec
[19:18] <mdeslaur> nacc: nothing looks specific to the imagemagick version in ruby-rmagick. Do the ruby-rmagick tests work locally for you?
[19:21] <nacc> mdeslaur: right, so looking at: https://launchpadlibrarian.net/295471663/buildlog_ubuntu-zesty-amd64.ruby-rmagick_2.15.4+dfsg-2build1_BUILDING.txt.gz. The package builds against (using) the version of imagemagick in z-p. But the resulting binary packages have a dep against the imagemagick (well, at least that upstream version). You can see during the build, the tests pass (against the z-p imagemagick),
[19:21] <nacc> but the autopkgtests end up using the one from release, due to the dep specification?
[19:22] <nacc> mdeslaur: iiuc, that dep is coming from dh_shlibdeps?
[19:23] <dmj_s76> sforshee: The test package works.  One question, do you know why rebooting after updating the initramfs doesn't work, but a complete shutdown and cold boot does?
[19:23] <mdeslaur> nacc: ah, yes, you're right, the tests are passing with the new one
[19:23] <mdeslaur> nacc: yeah, that's what's adding the dep
[19:26] <sforshee> dmj_s76: I'd guess that there's some state of the hardware that isn't getting reset on a reboot but does on a cold boot
[19:29] <infinity> nacc: More specifically, the dep comes from the symbols file.
[19:29] <infinity> nacc: In that, if all the symbols encountred are delcared at <IP_ADDRESS>, that's the dep you get.
[19:30] <infinity> nacc: If some of those *changed*, that's a hard ABI break (needs a new SOVER), if new ones were added with the wrong version tag, that's just a bug in the symbols file.
[19:30] <nacc> infinity: i see!
[19:30] <nacc> infinity: Using symbols file /var/lib/dpkg/info/libmagickcore-6.q16-2:amd64.symbols for libMagickCore-6.Q16.so.2
[19:30] <nacc> and that contains <IP_ADDRESS>, <IP_ADDRESS>, etc., but not the latest version
[19:31] <infinity> Well, it shouldn't contain the latest version unless the latest version introduced new symbols.
[19:31] <nacc> oh it does have some, you're right
[19:31] <nacc> so the symbols are properly version
[19:31] <infinity> So, that's the thing.  Is your crash an attempt to call a symbol that doesn't exist in the old version?
[19:32] <infinity> If so, the symbols file is wrong.
[19:32] <infinity> If your crash is an attempt to call a symbol that exists in both, but CHANGED, then the SONAME is wrong.
[19:33] <nacc> i don't think it can be the former, as the ruby-rmagick source isn't changing (so it is calling a symbol that exists before and now, afaict?)
[19:33] <infinity> Not necessarily true.
[19:33] <nacc> infinity: can you explain, I don't follow the 'doesn't exist in the old version' if it worked with the old version?
[19:35] <infinity> nacc: When you build and link against the new version, you may pick up references to symbols that didn't exist in the old version.  Your source doesn't have to change for that to happen.
[19:35] <infinity> nacc: Looking at the two binaries in question would help here.
[19:35]  * infinity grabs them quickly.
[19:36] <nacc> infinity: ah, of course
[19:36] <nacc> infinity: for my own edification, what are you looking for? symbol changes between the two binaries? what do you use to determine that?
[19:43] <sarnold> the security team uses http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/view/head:/package-tools/debcompare as part of our update process
[19:44] <nacc> sarnold: thanks for the pointer!
[19:45] <mdeslaur> size of the GradientInfo struct changed, which then offset DrawInfo->text
[19:45] <infinity> nacc: FWIW, I see no meaningful differences in RMagick2.so
[19:46] <infinity> mdeslaur: Ew, in libmagickcore?
[19:46] <mdeslaur> looks like it
[19:46] <infinity> That sounds like an ABI break.
[19:46] <mdeslaur> magick/draw.h
[19:46] <mdeslaur> which possibly explains GetTypeMetrics: Assertion `draw_info->text != (char *) NULL' failed.
[19:48] <nacc> mdeslaur: did you get that from debcompare?
[19:49] <nacc> sorry for pestering about it, but want to be able to figure this out on my own in the future, if possible :)
[19:49] <mdeslaur> nacc: no, just looking at the diff between the old imagemagick and the new one
[19:53] <smoser> cyphermox, can you give me an example kernel cmdline that you'd expect to use with your isc-dhcp/initramfs-tools changes ?
[19:54] <nacc> mdeslaur: so how should/would this normally be detected/resolved? Should that symbol have been tracked? Or does it get added to an appropriate symbols file? or is the correct fix to bump the SONAME?
[19:55] <cyphermox> smoser: if you were to bring things up in an ipv6 only network; "ip=off ip6=dhcp", for example
[19:57] <mdeslaur> nacc: upstream developer is either supposed to be careful it doesn't happen, or bump the so number
[19:57] <mdeslaur> nacc: https://abi-laboratory.pro/tracker/compat_report/imagemagick/6.9.1-10/6.9.2-10/67f2f/abi_compat_report.html
[19:57] <mdeslaur> looks like it broke in 6.9.2
[19:57] <mdeslaur> looking at all the brokenness here https://abi-laboratory.pro/tracker/timeline/imagemagick/
[19:57] <mdeslaur> doesn't inspire much confidence
[19:59] <nacc> mdeslaur: and the last time the debian ABI was bumped was <IP_ADDRESS>-1 (iiuc)
[20:00] <nacc> https://anonscm.debian.org/git/collab-maint/imagemagick.git/commit/?h=debian/<IP_ADDRESS>-1&id=392cce49e2bfa28daff8d8de18dd62468f39fda4
[20:01] <mdeslaur> nacc: ok, that's odd...that should have worked
[20:02] <nacc> mdeslaur: well, shouldn't it have been bumped again when 6.9.2 was picked up (note the above is 6.9.1-2 upstream, iiuc)
[20:02] <mdeslaur> nacc: yes, it should
[20:02] <mdeslaur> nacc: but we went from 6.8.something to 6.9.something
[20:02] <mdeslaur> so we should have gotten that bump
[20:04] <nacc> mdeslaur: sorry, i'm confused -- i meant, shouldn't debian have had to do more ABI bumps if upstream is changing the ABI? I see no commits in debian's VCS after <IP_ADDRESS>-1 that change the symbols file(s)?
[20:04] <mdeslaur> nacc: yes, debian should have bumped it again
[20:04] <mdeslaur> nacc: _but_ debian did bump it in 6.9.1
[20:04] <mdeslaur> we went from 6.8.x to 6.9.x so we should have at least gotten _that_ bump
[20:06] <nacc> mdeslaur: yes, i think we did -- but if the issue you found occurred in 6.9.2, wouldn't we still hit it (the gradientinfo change)?
[20:06] <mdeslaur> we would hit it if we had 6.9.1 and went to 6.9.2, yes
[20:06] <mdeslaur> since we never had 6.9.1, meh
[20:06] <nacc> ah i see what you're saying, i think
[20:07] <mdeslaur> we're lacking one of the bumps, but we have the previous one, which is newer than our previous package
[20:09] <mdeslaur> ok, so debian bumped the libmagick++-6.q16-6.symbols file, but they didn't bump the libmagickcore-6.q16-2.symbols file
[20:09] <mdeslaur> ah, because upstream didn't bump that library
[20:10] <mdeslaur> man, this package is complicated
[20:10] <sarnold> how many packages needed to be fixed up to switch to graphicsmagick?
[20:11] <nacc> sarnold: is that a (saner?) fork?
[20:11] <sarnold> nacc: the main guy sure feels more sane; many of the issues in imagemagick he's already fixed by rewriting the ugly bits. but not all obviously or everyone would have moved over by now..
[20:12] <sarnold> nacc: he at least understands email and participates in oss-security mail list :)
[20:12] <nacc> mdeslaur: given the report you found, shouldn't upstream have bumped the core lib too? I guess they didn't want to?
[20:12] <nacc> sarnold: interesting -- src:imagemagick has a lot of rdeps
[20:12] <mdeslaur> nacc: they should have, yes
[20:13] <nacc> mdeslaur: ok, so i'm guessing the right fix here is to contact debian and see if they agree and if they want to bump due to ABI breakage?
[20:14] <mdeslaur> nacc: I'm not sure what the right approach is, but the struct change does affect all libraries
[20:14] <mdeslaur> nacc: sounds like something to discuss with the maintainer
[20:15] <nacc> mdeslaur: ack, i'll start there
[20:15] <nacc> mdeslaur: infinity: sarnold: thank you for your patience and help!
[20:16] <sarnold> check these beautiful commit messages, not a single "..." in sight! https://sourceforge.net/p/graphicsmagick/code/ci/default/tree/
[20:26] <dobey> oi hg
[20:27] <sarnold> heh, my first thought was "ugh sourceforge" but each their own, I guess
[20:27] <sarnold> but seriously look at all these "..." checkins https://github.com/ImageMagick/ImageMagick/commits/master
[20:27] <sarnold> even sourceforage _and_ hg are easier to deal with than "..."
[20:29] <dobey> lol
[20:29] <dobey> surprised they even bother with vccs
[20:29] <dobey> err, vcs
[20:35] <sarnold> it sure feels like they've got their IDE or whatever configured to check in automatically after a few minutes of idle time or something
[20:35] <sarnold> an astonishing number of commits have a chunk or two that reverts previous commits
[20:35] <sarnold> which feels a lot like multi-level undo backing things out
[22:28] <kw1234> hi, after latest update, which included the kernel, ssd is not recognized as bootable anymore. any help on how to resolve/diagnose appreciated
[22:32] <kw1234> 16.10... do not remember kernel package versions...
[22:32] <nacc> kw1234: I think you want #ubuntu
[22:34] <kw1234> nacc: desperate times. trying everywhere. sorry for inconvenience.
[22:54] <tseliot> bdmurray: I'll have a look at it tomorrow, thanks
[23:44] <nacc> smoser: there's another corner case to 'workaround', the build after a merge will search through all of ubuntu first ... when we want the most recent in debian. I will see if it's detectable easily
[23:54] <nacc> mdeslaur: ah so debian bumped the so again in 6.9.5-8, but *only* for libmagick++
[23:54] <nacc> mdeslaur: https://anonscm.debian.org/git/collab-maint/imagemagick.git/commit/?h=debian/<IP_ADDRESS>%2bdfsg-2&id=efdea96ace66eceb20514391f65ba46a3941899b
[23:57] <mdeslaur> nacc: that was for the incompatible gcc upload, not because of imagemagick changes
[23:58] <mdeslaur> yeah, libmagickcore needs to be bumped too based on the abi checking website url I gave you earlier, and the problem we're having now
[23:58] <mdeslaur> I wonder how many packages in debian testing are broken right now because of the ABI change that nobody noticed
[23:59] <nacc> mdeslaur: yes, i understand; just debian says they bumped then, so they're fine :)


[21:27] <ada_> Hiya,
[21:28] <ada_> oops new to irc thought shift+enter worked but no... anywho, I'm getting some graphical glitches on ubuntustudio 20.10 on intel hd graphics, using mesa drivers, is this a known issue? systeminfo here: https://paste.ubuntu.com/p/nTgwW2DJXH/


[13:38] <kaushal> hi
[13:38] <kaushal> I did added JAVA_OPTIONS="-Xms512m -Xmx4500m -XX:+HeapDumpOnCtrlBreak -XX:+HeapDumpOnOutOfMemoryError"
[13:38] <kaushal> and did export $JAVA_OPTIONS
[13:38] <kaushal> but on ps aux | grep tomcat it does not show the JAVA options
[13:38] <kaushal> Any clue please ?
[13:44] <nthykier> kaushal: did you set these options in /etc/default/tomcat ? Alternatively are you running a "per user" instance of tomcat?
[13:44] <kaushal> nthykier: i did added on the init script of tomcat
[13:44] <kaushal> the init script is a customized script
[13:45] <nthykier> Well, by default we use JAVA_OPTS and not JAVA_OPTIONS in our script - also by default /etc/default/tomcat6 will set the value of JAVA_OPTS
[13:45] <kaushal> ok
[13:46] <nthykier> At least this is the case in 6.0.26-2
[13:47] <kaushal> Unrecognized VM option '+HeapDumpOnCtrlBreak'
[13:47] <kaushal> JAVA_OPTS="-Xms512m -Xmx4500m -XX:+HeapDumpOnCtrlBreak -XX:+HeapDumpOnOutOfMemoryError"
[13:47] <kaushal> I am running tomcat 5.5.27
[13:48] <nthykier> guess your VM doesn't support that option, what VM are you using?
[13:49] <kaushal> nthykier: is it java -version ?
[13:49] <kaushal> I mean VM ?
[13:49] <kaushal> java version "1.5.0_15"
[13:55] <nthykier> kaushal: No, the actual implementation (e.g. Openjdk-6, GCJ or Sun-java)
[13:56] <kaushal> nthykier: ok
[13:56] <kaushal> shall i pastebin the configs ?
[13:57] <kaushal> I am using sun java
[13:57] <nthykier> kaushal: Okay, then sun-java does not support the option (or you wrote it wrong) in that version
[13:58] <nthykier> -X (and -XX) are nonstandard options
[13:58] <kaushal> nthykier: ok please suggest me the correct options
[14:00] <nthykier> kaushal: I do not know them, I usually do not need to pass this kind of option to my JVM.
[14:01] <nthykier> perhaps your source for those options may know more about which JVM (or/and version) support those options
[18:37] <SpamapS> Hello everyone. I'm trying to package Antlr3 .. and its very confusing where to find certain pieces of software and how to assemble them... for instance, antlr3-maven-plugin .. the only place I find the "release" files is http://grepcode.com/snapshot/repo1.maven.org/maven2/org.antlr/antlr3-maven-plugin/3.1.2-1
[18:39] <SpamapS> There's a jar with the class files and pom.xml ..
[18:39] <SpamapS> and another with the src
[18:39] <SpamapS> so do we always have to download both, and then assemble them into a .orig?
[18:42] <nthykier> SpamapS: I thought antlr3 was packed already ?
[18:43] <SpamapS> nthykier: 3.0 is, but 3.1 changed to a pure maven build
[18:43] <SpamapS> they seem to have the same affliction as the php world.. changing huge swaths of code in minor releases. :-/
[18:44] <nthykier> ah 3.1
[18:44] <SpamapS> I'm working on packaging Cassandra
[18:45] <SpamapS> which ships antlr3-3.1.2.jar in their source distribution. :-/
[18:46] <nthykier> SpamapS: Okay, I am afraid I am not sure how the antlr3 orig.tar is/should be generated. The Debian side seems to be lacking some love as well
[18:47] <SpamapS> seems like there should be a uniform way to say "grab this maven based source and make it into a debian source"
[18:48] <SpamapS> sort of like dh-make-perl
[18:51] <nthykier> file a bug against the maven helper in Debian perhaps :P
[18:54] <nthykier> SpamapS: perhaps I could have you send an email to<EMAIL_ADDRESS>- perhaps there are some people there who knows more about antlr3 and how to package it
[18:55] <nthykier> I recall someone bringing it up a few months back
[18:56] <SpamapS> probably ttx :)
[19:49] <SpamapS> ugh.. boostrap.. fun.. antlr3 depends on antl3-maven-plugin depends on antlr3......
[19:49] <SpamapS> :-P
[19:56] <nthykier> SpamapS: guess you have to break that circle :P
[19:57] <SpamapS> According to Thierry's java lib packaging guide (https://wiki.ubuntu.com/JavaTeam/LibraryPackaging) its ok to start out with a binary upload to multiverse if this is the case