 backports is its own form oc insanity
 form of insanity*
 i'm fairly familiar with backports but...
 ... backports shouljdn't be used to fix *bugs* ;) (re @philipz: anyone familiar with how the backport repo works, as we need to backport neofetch 7.1 into focal to fix the bug of it not showing the correct flavor logo. https://github.com/dylanaraps/neofetch/issues/1505)
 ... backports shouldn't be used to fix *bugs* ;) (edited) (re @philipz: anyone familiar with how the backport repo works, as we need to backport neofetch 7.1 into focal to fix the bug of it not showing the correct flavor logo. https://github.com/dylanaraps/neofetch/issues/1505)
 this is probably something you want to read:
 > The Backports Project is a means to provide new features to users. Because of the inherent stability risks in backporting packages, users do not get backported packages without some explicit action on their part. This generally makes backports an inappropriate avenue for fixing bugs. If a package in an Ubuntu release has a bug, it should be fixed either through the Security Upda
 this is probably something you want to read and focus on, from the Backports page's info: The Backports Project is a means to provide new features to users. Because of the inherent stability risks in backporting packages, users do not get backported packages without some explicit action on their part. This generally makes backports an inappropriate avenue for fixing bugs. If a pac
 thank for the insight. so it should be pushed into focal-updates then. got it. (re @teward001: this is probably something you want to read and focus on, from the Backports page's info: The Backports Project is a means to provide new features to users. Because of the inherent stability risks in backporting packages, users do not get backported packages without some explicit action on
 yes, though it needs to go through the SRU process first.  And the SRU team might NACK it, unless you have specific upstream commits that fix the problem you can nitpick into the specific older versions as specific patches. (re @philipz: thank for the insight. so it should be pushed into focal-updates then. got it.)
 backports is good to get newer software into older releases when SRU is not applicable (not bug fixes, primarily new features)
 but backports is not really where an upload just to address bugs should be put


[08:28] <acheronuk> mostly 'cleaning' going on on the non x86 builder. something need a poke?
[08:29] <wgrant> ah, my reset failed
[08:29]  * wgrant reruns
[08:30] <acheronuk> thanks
[08:30] <hloeung> wgrant: was that reset done after the recent rolling restarts?
[08:31] <wgrant> hloeung: My attempt to recover after those restarts ran into an LP API conflict
[08:31] <hloeung> ah
[12:12] <rbasak> https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer/+ref/master doesn't seem to be refreshing.
[12:12] <rbasak> A push a week or two never caused it to update, and my most recent push hasn't either.
[12:12] <rbasak> (the cgit view shows the newer commits)
[12:12] <rbasak> Was there some way to kick it?
[12:14] <cjwatson> rbasak: lp.load('/~usd-import-team/usd-importer/+git/usd-importer').rescan()
[12:14] <rbasak> Thanks!
[12:14] <cjwatson> happens if the scan job crashes
[12:14]  * rbasak makes a note this time
[12:14] <cjwatson> or is backlogged
[16:29] <rbasak> cjwatson: it's still not refreshed. Is it crashing every time? Seems it's unlikely to have been backlogged by weeks unless something is broken with queue processing?
[16:30] <cjwatson> the last one certainly crashed
[16:30] <cjwatson> OOPS-3a72bddd7e9eee0e491cd388463d2174
[16:31] <cjwatson> which is probably the ongoing meltdown of git.launchpad.net due to ceph rebalancing
[16:31] <cjwatson> best I have for you right now is to keep retrying, there's nothing I can immediately do
[16:31] <cjwatson> rescans are normally pretty quick if they actually work
[16:36] <rbasak> OK thanks
[16:37] <rbasak> +1 for lp-shell readline history!
[17:27] <rbasak> It updated that time \o/
[17:27] <cjwatson> phew
[20:05] <jimpop> teward: how long does it take for pkgs to be deleted from a PPA?
[20:05] <jimpop> :-)
[20:05] <jimpop> (small world)
[20:06] <teward> i'm not the one to highlight, but lol :P
[22:01] <jeremy31> Still some spam from October 6 on answers.launchpad.net/ubuntu
[23:31] <wgrant> jimpop: Why do you ask?


[03:43] <flocculant> popcon wasn't on last manifest I have from 11th
[04:13] <flocculant> bluesabre: and yea - wasn't sure you would see that in all the spam :D
[10:02] <bluesabre> false alarm, forgot that we've included gnome-sudoku for years
[10:02] <bluesabre> but yeah, popcon/langpacks are new
[10:09] <Unit193> Wonder if they're going to have a more visable opt-in for popcon.
[10:12] <bluesabre> We can push for it
[10:13] <bluesabre> I also think we should consider the minimal ubiquity install option. There's one person who can move -core forward and he's already stated his distaste and intentional delay
[10:18] <Unit193> ...Would I be told to stop publishing ISOs? :P
[10:26] <bluesabre> :)
[10:26] <bluesabre> I'll nudge him again and see if he will just merge the branches so we can move along
[12:34] <flocculant> bluesabre: well I hope ^^ will be on the meeting
[14:15] <brainwash> bluesabre, Unit193: can this be fixed in 18.04? bug 1758023
[14:15] <brainwash> see comment #19
[14:16] <brainwash> affects quite some people
[15:56] <bluesabre> brainwash: will take a look. Generally it doesn't affect anybody until they pull some package that brings libinput along for the ride. Need to confirm we're building with it now in 18.10, will do so this weekend.
[15:56] <bluesabre> It's one of those unfortunate things where libinput oversteps and takes over all control :\
[17:04] <brainwash> bluesabre: but isn't it installed by default?
[17:04] <brainwash> xserver-xorg-input-libinput 0.27.1-1
[17:04] <brainwash> that's on the 18.04.1 ISO
[21:58] <bluesabre> brainwash: aha, that didn't used to be the case (at least I thought)
[22:25] <bluesabre> brainwash: alrighty, sure enough, it's built with libinput support as of 4.13.1-1
[22:26] <bluesabre> Need to do some 18.04 / 4.12 testing to see if it's reasonable to consider for bionic
[22:26] <bluesabre> Though, that portion of the code hasn't been touched in ages
[22:26] <bluesabre> So, probably OK
[23:44] <ali1234> speaking of mouse acceleration. i've got this weird thing where after some time (usually several days) my mouse acceleration gets a lot slower. if i replug it it goes fast again. it's an ancient USB intellimouse explorer. anyone else seen anything like that?
[23:45] <ali1234> it's something that started happening recently too. it might just be dying hardware, idk...
[23:58] <bluesabre> ali1234: not seen that
[23:58] <bluesabre> computer usually running for weeks without a reboot or mouse disconnect


[21:28] <_Xenial_Xerus_> Is there any way to get  them to modify the kernel code for LUKS.
[21:28] <_Xenial_Xerus_> I can make some sort of lustration about why the keys need to be on a seperate partition.
[21:28] <_Xenial_Xerus_> Picture of a man pulling out the SDCARD.
[21:29] <_Xenial_Xerus_> Walking past police beating checkpoints.
[21:29] <_Xenial_Xerus_> Reaching the F.D.L. (food distribution location) and then returning to the computer without 8 necrosan neighbors data dumping the entire system during a home invasion.
[21:37] <_Xenial_Xerus_> JanC call up infinity
[21:44] <JanC> ?
[21:45] <JanC> I think you need to read documentation
[21:46] <_Xenial_Xerus_> Oh, you make a funny?
[21:52] <JanC> how to do what you ask for is explained in the cryptsetup manual (see e.g. the --header option)
[21:53] <_Xenial_Xerus_> JanC manually from a running kernel?
[21:53] <_Xenial_Xerus_> backup and restore header
[21:53] <_Xenial_Xerus_> This requires a second system.
[21:53] <_Xenial_Xerus_> Too much.
[22:03] <JanC> LUKS can have the key(s) on a separate device; you can suspend/resume a LUKS-encrypted device (suspend here means that the kernel erases the encryption key from memory); if you want you can automate the suspend/resume with udev or the like
[22:42] <_Xenial_Xerus_> JanC LUKS now allows for the header to be stored on /boot?
[22:42] <_Xenial_Xerus_> Can this be done from the ubuntu installer?
[22:42] <_Xenial_Xerus_> Last I looked into it the only way to remove the keys is to do a backup/restore manually from command line.
[22:42] <JanC> I think it always did, but maybe not from the installer
[22:43] <_Xenial_Xerus_> The LUKS code stores the keys in the header and the header at the start of the encrypted part.
[22:45] <JanC> AFAIK the kernel doesn't really care where the header/keys are; storing it there is just the default/usual way to do it with cryptsetup & most linux installers
[22:46] <JanC> (and you can always use bare dm-crypt also)
[22:58] <_Xenial_Xerus_> LUKS is designed so.
[22:59] <_Xenial_Xerus_> The keys are stored in the header, the header the beginning of the crypt part.
[23:01] <_Xenial_Xerus_> What do you mean bare dm-crypt, no LVM?
[23:02] <_Xenial_Xerus_> JanC?
[23:02] <JanC> meaning dm-crypt without LUKS
[23:03] <_Xenial_Xerus_> LUKS uses dm-crypt doesn't it?
[23:03] <_Xenial_Xerus_> It wraps the partition in an encrypted LVM.
[23:04] <_Xenial_Xerus_> Here we go turning support into an argument.
[23:05] <_Xenial_Xerus_> What is the command for pulling the current source?
[23:05] <_Xenial_Xerus_> sudo apt-get source linux?
[23:05] <_Xenial_Xerus_> or is it, sudo apt-get --download-source linux?
[23:07] <_Xenial_Xerus_> Or is it trapped with dependency injections?
[23:16] <_Xenial_Xerus_> JanC leaving the kernal as it is for now then, do you want to work on moving the /boot to an ISO with isolinux
[23:22] <JanC> see: https://skrilnetz.net/bullet-proof-data-encryption-with-luks-and-a-detached-header/
[23:40] <_Xenial_Xerus_> Did you writup my specs and predate it?
[23:41] <xnox> _Xenial_Xerus_, please use some other irc nickname, this one is tasteless
[23:42] <_Xenial_Xerus_> xnox: what is tasteful?
[23:45] <_Xenial_Xerus_> better?
[23:45] <ubuntu> better?
[23:46] <xnox> now, yes =)


[04:58] <Guest22544> hello does anybody knows when we will have gnome 3.8
[04:59] <Guest22544> on ubuntu?
[05:07] <Guest22544> yes
[05:34] <ikevin> hi
[05:34] <ikevin> anyone is here?
[05:46] <back_> ikevin, somebody is here but who :D
[07:00] <ikevin> im here
[07:00] <ikevin> hahah
[10:28] <tbvr> any one have any screenshots?
[10:28] <tbvr> test
[12:32] <ricotz> darkxst, hi
[12:33] <ricotz> darkxst, do not  simplycopy the saucy package of gtk+3.0 to raring
[12:38] <ricotz> darkxst, to be more precise, it would need glib 2.37.x and will break the appmenus
[16:36] <MrGrymReaper> You currently provide ubuntu gnome in 12.10 and 13.04 version. I was wondering why there isn't a 12.04 LTS flavour or why one couldn't be done for the next LTS release?
[16:37] <SonikkuAmerica> MrGrymReaper: (a) 12.10 is really an unofficial remix; 12.04 never really existed; (b) 14.04 will be the next LTS (as per the LTS release schedule).
[16:40] <MrGrymReaper> Is it possible for an LTS remix to be included so that people wishing to use Ubuntu but prefer gnome while having long term support.
[16:41] <jbicha> Ubuntu GNOME 14.04 probalby will not be supported for 5 years though
[16:41] <SonikkuAmerica> jbicha: ... are we going to follow the Xubuntu plan then (3 years)?
[16:41] <SonikkuAmerica> MrGrymReaper: Nope. However, you can install gnome-shell in Ubuntu (with Unity)
[16:41] <jbicha> that's not my decision but 3 years is at least closer to reasonable
[16:42] <jbicha> nobody here really runs 12.04 LTS and we haven't really bothered backporting fixes there for a while so even 3 years may be too long
[16:44] <SonikkuAmerica> jbicha: I'd prefer some sort of LTS... especially since if Canonical gets a lot of backlash for the Mir interface we can be as plausible as the other !flavors if they wind up dropping Ubuntu.
[16:44] <MrGrymReaper> The 12.04 release enables the use of Steam amongst other software. Steam has recently come to linux.It currently can only be installed properly under ubuntu 12.04 LTS.
[16:45] <jbicha> MrGrymReaper: any newer version of Ubuntu works with steam too
[16:45] <SonikkuAmerica> jbicha: Were the Steam PPA issues fixed then?
[16:47] <jbicha> uh, no PPA needed http://store.steampowered.com/about/
[16:49] <jbicha> yes, a 14.04 LTS would be nice but "LTS" is a promise of support so we'll have to look at our QA and developer resources to see what kind of committment we can make
[16:51] <jbicha> speaking of LTS, it sounds like RHEL 7 will be using GNOME 3.8
[16:52] <jbicha> if that's true that might be good reason to keep 3.8 for 14.04 too
[16:53] <SonikkuAmerica> The awkward moment when your flavor's DE pushes out its stable release the day after the RC freeze
[16:53] <jbicha> on the other hand, GNOME themselves don't really do LTS releases yet so 3.8 isn't necessarily any more stable than 3.10 would be
[16:54] <SonikkuAmerica> Isn't GNOME pushing to be its own OS?
[16:55] <jbicha> not exactly, "GNOME OS" wasn't a great naming choice
[16:56] <jbicha> they are trying to identify all the pieces of their platform (including low-level components) that are part of a given GNOME release
[16:57] <SonikkuAmerica> Maybe "Gnomos?" (GNU Network Object Model OS)
[16:57] <jbicha> there's more work being done on all levels to make the integration stronger so that users get a better experience
[16:58] <jbicha> and they want to have an easily downloadable image for developers so that they can build and test against GNOME
[16:58] <atrus> it's pretty clear that they're getting more and more attached to wayland and systemd...
[16:59] <atrus> and it seems like every distro that's moving is moving towards those, except ubuntu :/
[16:59] <jbicha> sure, wayland and systemd offer possibilities for a better user experience than sysvinit or X
[17:00] <atrus> and upstart.
[17:00] <atrus> is the plan from ubuntu-gnome to use wayland and systemd?
[17:00] <SonikkuAmerica> I think so...? I looked @ the mailing list
[17:00] <jbicha> Ubuntu 13.04 includes pieces of systemd and my uneducated estimate is that 13.10 includes half of systemd (logind, timedated, localed, & hostnamed)
[17:01] <SonikkuAmerica> atrus: We're the only flavor that doesn't depend on lightdm
[17:01] <jbicha> the Ubuntu Foundations Team will not support systemd as init to completely replace upstart but we already ship enough of sytsemd to get nearly everything GNOME offers
[17:03] <atrus> what's the situation with wayland?
[17:03] <SonikkuAmerica> AFAIK we just start GDM, and it runs Wayland...
[17:03] <jbicha> wayland is already in the Ubuntu archives but since 3.10 will support X or Wayland we'll probably keep with X until after 14.04
[17:03] <jbicha> that's a guess and not my decision either :)
[17:05] <atrus> interesting. thanks :)
[17:42] <driff> hi
[17:42] <driff> any1 there?
[21:55] <darkxst> jbicha, re alpha1 ok.
[21:56] <darkxst> I suppose we need to notify release team that we are opting in?
[22:59] <jbicha> darkxst: yup
[22:59] <jbicha> I'm happy the new GNOME Classic is working as of today in Saucy, and seb128 uploaded nautilus 3.8 too
[23:00] <darkxst> nice ;)
[23:00] <jbicha> what do you think of nautilus-classic?
[23:03] <jbicha> it's nautilus with desktop icons forced on, see https://bugzilla.gnome.org/695088
[23:04] <jbicha> I removed nautilus-classic from RequiredComponents for gnome-shell-extensions and gnome-panel and I'm not so sure I should disable the patch
[23:05] <darkxst> I hate desktop icons, however I know lots of people want them for whatever reason
[23:07] <jbicha> well like I said on the bug, it's broken that nautilus-classic doesn't allow opting-out of showing desktop icons
[23:08] <darkxst> yup, that needs to be fixed
[23:10] <darkxst> anyways I'm off for the weekend
[23:12] <jbicha> have fun
[23:28] <darkxst> will do, likely to be really cold but otherwise fun!
[23:32] <jbicha> come visit South Carolina, we're warm this time of year :)
[23:42] <darkxst> I suspect anywhere is warmer than here atm. it was 2 degrees the other night when I went out riding!


[01:49] <wgrant> https://oops.canonical.com/oops.py/?oopsid=OOPS-493eb7067f568cde87767956e4f8ce24 is impressive
[01:50] <wgrant> 1061 repetitions of a query to check if the current user is affected by a bug
[01:51] <StevenK> It wants to be REALLY sure
[01:51] <wgrant>         # Loop over dupes.
[01:51] <wgrant>         for dupe in self.duplicates:
[01:51] <wgrant>             if dupe._getAffectedUser(user) is not None:
[01:51] <wgrant>                 dupe.markUserAffected(user, affected)
[01:52] <StevenK> Oh
[01:52] <wgrant> That seems pretty pointless...
[01:53] <wgrant> I guess it might be helpful to unaffect dupes when unaffecting the master
[03:33] <StevenK> wgrant: I've fixed the test failures in destroy-old-bugactivity, I'll be landing it shortly.
[03:35] <wgrant> StevenK: Great
[03:35] <wgrant> Now go away :)
[03:36] <StevenK> Haha
[03:39] <nigelb> what? haha.
[03:39] <StevenK> nigelb: I'm on holidays this week.
[03:39] <StevenK> So wgrant is telling me to stop caring about work from last week. :-)
[03:39] <nigelb> StevenK: Aha. yes, go away.
[03:40] <StevenK> But it hasn't landed yet!
[03:40] <nigelb> Where's a freenode staff when you need one.
[03:40] <StevenK> Oh, don't even joke about that.
[03:40] <nigelb> Waitaminute
[03:40] <StevenK> They've k-lined me twice 'by accident'
[03:40] <nigelb> I'm sure your SO can arrange that ;)
[03:41] <StevenK> Hah
[04:29] <wallyworld_> wgrant: does it make sense that when auto confirming a bug, any duplicates of that bug should be confirmed also, without the need for affected user checks against each individual dup?
[04:34] <wgrant> wallyworld_: No. In fact it's a bug (probably already reported) that duplicates get autoconfirmed at all
[04:35] <wgrant> wallyworld_: Launchpad supports autoconfirmation only provisionally and begrudgingly; don't feel like you have to go too far out of your way to make it smooth
[04:35] <wallyworld_> wgrant: ok, so if i do a bulk update for affects user, i can ditch the need for any recursive call processing
[04:35] <wgrant> Right
[04:35] <wallyworld_> what about heat?
[04:35] <wallyworld_> can dupe heat be set to master heat?
[04:35] <wgrant> No
[04:35] <wallyworld_> i may need to to a stored proc which bulk updates heat
[04:36] <wallyworld_> instead of just one bug id at a time
[04:36] <wgrant> Nah
[04:36] <wgrant> See the garbo job
[04:36] <wallyworld_> oh, ok. didn't realise there was one
[04:36] <wgrant> You can do eg. some_result_set_of_bugs.set(heat=SQL('calculate_bug_heat(Bug.id)')
[04:36] <wgrant> And it'll construct a single UPDATE
[04:37] <wallyworld_> ok, nice
[04:37] <wallyworld_> thanks
[04:37] <wgrant> Calling the function a thousand times isn't a problem, as (particularly after I last took an axe to it) it's quite fast. The problem is making a bazillion roundtrip queries.
[04:37] <wallyworld_> yes
[04:37] <wgrant> A quick fix to this also wouldn't go near the heat issue at all
[04:38] <wgrant> Since it's very unlikely that the user has clicked the affectsme button on more than a couple of dupes
[04:38] <wgrant> So it won't be triggered more than a couple of times a request
[04:38] <wgrant> But batchifying more code is always good, so why not do the comprehensive fix, I guess :)
[04:38] <wallyworld_> well, i'm lookin at ditching the recursive call and bulk updating all dupes in the tope level affectsMe all
[04:38] <wgrant> Note that it's not quite like that
[04:39] <wgrant> It sets the affectsme status of any dupes that already have an affectsme status
[04:39] <wallyworld_> sure, i'm handling that
[04:39] <wgrant> Great
[04:39] <wgrant> Just confirming
[04:39] <wallyworld_> np :-)
[04:40] <wallyworld_> but it means ditching the confirm of dupes, which you say above is ok
[04:40] <wallyworld_> and i'll do a single update for heat
[04:40] <wgrant> So yeah, I'd just find all the dupes that have a BugAffectsPerson for the user, set them, set their users_affected_count to AutoReload (or amybe not, it might mean we don't care), and then bulk update the heat
[04:40] <wallyworld_> an invalidate and flush will do the same thing?
[04:40] <wallyworld_> as setting to AutoReload
[04:40] <wgrant> Yeah, but it's excessive
[04:41] <wgrant> So it's nice to avoid it
[04:41] <wallyworld_> it's used already
[04:41] <wgrant> Yes
[04:41] <wallyworld_> so i'll see if i can ditch it maybe
[04:41] <wgrant> It's already excessive!
[04:41] <wgrant> Right
[04:41] <wallyworld_> not sure
[04:41] <wgrant> To some extent we really don't care that the dupe counts are off by one
[04:41] <wgrant> (for the current transaction)
[04:42] <wallyworld_> ok, i may see what ec2 comes back with perhaps
[04:42] <wgrant> But if we do care, then just set the affected columns to AutoReload, as it's much cheaper than invalidating the entire object
[04:42] <wallyworld_> not sure if this will help the other bug 925937
[04:42] <_mup_> Bug #925937: Does this bug affect you: Timeout error popup <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/925937 >
[04:42] <wallyworld_> maybe
[04:43] <wallyworld_> since auto confirm for dupes is not going to be dome now
[04:47] <wgrant> wallyworld_: No, sadly
[04:47] <wgrant> wallyworld_: That's autoconfirming the main bug
[04:47] <wallyworld_> oh well
[04:54] <nigelb> Oh.  Until after vacations.
[06:02] <wgrant> Yep
[06:03] <StevenK> But I needs it for Steam!
[06:03] <StevenK> Anyway, I lose Internets on Wednesday
[06:04] <nigelb> You need to take a vacation on some island with poor internet connectivity. But, you already live in Australia.
[06:05] <StevenK> So yeah, mission accomplished?
[07:53] <adeuring> good morning
[08:26] <czajkowski> purple you guys were busy yesterday
[08:26] <czajkowski> *today
[08:26] <StevenK> We're always busy
[08:28] <czajkowski> my inbox says very busy :)
[12:11] <olli> gm Alice
[12:12] <olli> seems you are well informed, hadn't heard about Sam until I saw your mail
[12:16] <olli> wrong channel
[14:07] <abentley> rick_h_: On https://qastaging.launchpad.net/bzrtools/+edit I see a green flash when I change information type.  I believe that's supposed to mean that the change has been applied to our server.
[14:18] <rick_h_> abentley: looking
[14:19] <rick_h_> abentley: ah, gotcha. will file a bug/card
[14:21] <abentley> rick_h_: Cool.
[14:21] <rick_h_> do we have a tag we're using for privateproject work?
[14:22] <rick_h_> ah, see private-projects
[14:26] <rick_h_> abentley: I also looked into that bug from friday and filed that bug along side this one
[14:26] <rick_h_> where without JS you saw all of the radio buttons for all info types vs the 3 valid options
[14:27] <abentley> rick_h_: Thanks.  I experienced that bug with JS enabled, though.
[14:27] <rick_h_> abentley: hmm, well I figured there mus thave been a JS error in your local env since I didn't see it on qastaging but you mentioned you had it with js disabled
[14:28] <rick_h_> abentley: I guess if you can repeat it with JS enabled let me know and we can look if something in the JS to build the widget failed since you shouldn't see radio buttons
[14:29] <abentley> rick_h_: We should also fix JS errors that affect local dev environments.
[14:29] <rick_h_> abentley: agree, but I don't know what your JS error was which is why I'm saying if you hit it please let me know more details
[14:31] <abentley> rick_h_: Reproduced.
[14:31] <rick_h_> abentley: awesome
[14:32] <abentley> rick_h_: The console shows Error: extend failed, verify dependencies
[14:32] <rick_h_> ugh...ok so this is on a project/+edit you're getting this in your local dev env?
[14:33] <abentley> rick_h_: Yes, https://launchpad.dev/firefox/+edit
[14:33] <rick_h_> abentley: ok, loading up a clean trunk dev env to peek at
[14:33] <abentley> rick_h_: I am using firefox, btw.
[14:34] <rick_h_> abentley: ok, checking. Not seeing it in chrome
[14:34] <abentley> rick_h_: I'm seeing the radio buttons in chrome.
[14:35] <rick_h_> abentley: ok, trying to see if I can replicate. make clean/make run and such.
[14:36] <rick_h_> abentley: the error you hit is generally because there's a missing new SomeObject when creating an instance
[14:36] <rick_h_> or a missing dep in the list of requires for some module
[14:37] <abentley> rick_h_: This is on line 10 of https://launchpad.dev/+combo/?yui/yui/yui-min.js&lp/meta.js&yui/loader/loader-min.js
[14:38] <rick_h_> abentley: does your line 10 look anything like: https://pastebin.canonical.com/76544/
[14:39] <rick_h_> abentley: have you updated your feature flags locally? Are you running yui 3.5?
[14:39] <rick_h_> I wonder if it's broken for you since I used Y.View which is yui 3.5 and you might still be set in your dev env for 3.3
[14:39] <rick_h_> abentley: that would explain why it works in qastaging/production
[14:39] <abentley> rick_h_: No, it looks like https://pastebin.canonical.com/76545/
[14:40] <rick_h_> abentley: yea, I bet you're running the old YUI locally still via either lack of make clean/clean-buildout or via forced feature flag setting
[14:41] <abentley> rick_h_: One should never have to run make clean.  I can confirm I'm still running 3.3
[14:42] <rick_h_> abentley: ok, I guess that's a failing on my end then. I tend to run make clean whenever I bzr switch so didn't realize this
[14:43] <abentley> rick_h_: Yeah, I only run make clean as a last resort.
[14:43] <rick_h_> abentley: so the make commands around JS build check for the existing of the build/js/yui and build/js/lp and they existed
[14:43] <abentley> Not when I switch or anything.
[14:44] <rick_h_> and only rebuild around them missing so I guess we can look at a more robust or always rebuilding them
[14:47] <abentley> rick_h_: So I guess 3.3 is obsolete now, and we should remove support for it.
[14:48] <rick_h_> abentley: yes, it's on the JS clean up todo. SteveK talked about working on some of it, removing some of the jsbuild bits and such
[14:48] <abentley> rick_h_: Now that I've "make clean"ed, I'm seeing the JS widget, not the radio buttons.
[14:48] <rick_h_> granduating combo build up to full status and cleaning up the yui-deps.py
[14:48] <rick_h_> abentley: cool, good to hear
[15:07] <rick_h_> abentley: I'm working on trying to get InformationType to show up for new blueprints UI locally. I've enabled the feature flag, there's nothing in +configure-blueprints about adjusting the information types, but I don't get the field in the list as I do on qastaging/production.
[15:07] <rick_h_> abentley: is there another step I'm missing to enable the field?
[15:07] <abentley> rick_h_: OTP
[15:07] <rick_h_> abentley: rgr
[15:26] <sinzui> jcsackett, do you have time to hangout?
[15:30] <abentley> rick_h_: Have you enabled the blueprint-specific flag?
[15:31] <abentley> rick_h_: i.e. blueprints.information_type.enabled ?
[15:31] <rick_h_> abentley: yes
[15:31] <rick_h_> blueprints.information_type.enabled	default	1	on
[15:32] <abentley> rick_h_: Have you enabled private blueprints under +sharing?
[15:36] <rick_h_> abentley: ah I think I see. Since this new project is public and doesn't have a commercial subscription it can't immediately set a non-public blueprint?
[15:37] <abentley> rick_h_: Indirectly.  If your specification sharing policy is "Public", you can't set non-public, so you don't get the field.  Non-public policies should only be available if you have a commercial subscription.
[15:37] <rick_h_> abentley: got it
[15:37] <rick_h_> abentley: yea, had to get a commercial subscription to get the edit UI for the +sharing to change the policy
[15:38] <rick_h_> abentley: thanks
[15:38] <abentley> rick_h_: np
[15:40] <adeuring> abentley, deryck, rick_h_: sorry, I just saw another EC2 test failure that I missed earlier today; fixed now, but the new EC2 test is starting just now
[15:41] <deryck> adeuring, no worries.  thanks for the heads-up.
[15:41] <rick_h_> adeuring: cool thanks. Yea I'm just holding off until your stuff hits pqm and I'll merge/submit to ec2 EOD/tomorrow morning
[15:42] <adeuring> rick_h_: thanks. I'll ping you once my stuff lands.
[15:42] <rick_h_> adeuring: ty much
[16:01] <rick_h_> sinzui: ping
[16:02] <sinzui> hi rick_h_
[16:21] <jml> which squad is doing maintenance at the moment?
[16:22] <czajkowski> jml: purple
[16:22] <jml> czajkowski: ta
[16:23] <czajkowski> jml: why.. what have you broken :)
[16:23] <jml> czajkowski: time.
[16:24] <lifeless> \o/
[16:24] <czajkowski> lifeless: :D
[16:26] <sinzui> jml, you broke time?
[16:27] <jml> sinzui: time is out of joint.
[16:32] <rick_h_> sinzui: wanted to check on if you filed a bug for the JS inline stuff around https://bugs.launchpad.net/launchpad/+bug/1052551 The inline stuff was in the NullChoice side of the widget so wasn't sure if the bug was valid and wanted to check it out
[16:32] <_mup_> Bug #1052551: Specification sharing policy is not honored by the edit information_type widget <css> <information-type> <javascript> <private-projects> <specifications> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1052551 >
[16:34] <sinzui> rick_h_, why can't we change the info type of this blueprint. We own it and the project allows public :https://blueprints.qastaging.launchpad.net/launchpad-help-moin-theme/+spec/testing-proprietary-1
[16:34] <rick_h_> sinzui: yea, there's bug in the JS/css setup in the .pt
[16:35] <rick_h_> I've got that fixed, but was looking at the comment you made about the choiceedit.js doing manual style setup on 'inline'
[16:35] <rick_h_> sinzui: https://code.launchpad.net/~rharding/launchpad/info_portlet_1052551/+merge/129706 for the .pt and setup issues I'm fixing currently
[16:35] <sinzui> ah, I reported that as a separate issue.
[16:35] <rick_h_> sinzui: right, so tring to find that separate issue atm to look at it and my search-fu is failing me
[16:36] <sinzui> rick_h_,  this is definitely separate: https://bugs.launchpad.net/launchpad/+bug/1064555
[16:36] <_mup_> Bug #1064555: choicedit assumes icons are inline and tampers with the style.display <disclosure> <information-type> <javascript> <private-projects> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1064555 >
[16:36] <rick_h_> wondered if you had it handy and if you had realized the setStule stuff was in the NullChoice widget and if it still applies
[16:36] <sinzui> rick_h_, all feature bugs should be tagged private-projects, that will narrow the search
[16:36] <rick_h_> sinzui: yea, so the cause was manually adding display:inline to the .pt file
[16:36] <rick_h_> not the JS in choiceedit
[16:36] <rick_h_> ok cool, I'll reply to this one as well as I wrap things up here
[16:37] <rick_h_> sinzui: note line #47 of my diff in my MP I'm working on
[16:37] <rick_h_> sinzui: cool thanks for the link that helps
[16:38] <sinzui> rick_h_, I would exepct the choicesource bug to appear more frequently. It may affect your feature, but it definitely pre-exists a lot of feature work by about 3 years
[16:39] <rick_h_> sinzui: right, but in this case it wasn't a bug in choicesource, but in the JS manually run in specification-index.pt and boostrap html in blueprint-portlet-privacy.pt
[16:41] <sinzui> rick_h_, oh, so maybe the error I saw about manipulating style.display is actually from the template...which may mean we have dead code in choice source
[16:41] <rick_h_> sinzui: right, the code in choicesource you grepped pertains to a NullChoiceSource widget
[16:42] <rick_h_> so maybe there's still a bug there, but that's why we don't see it much as it's not used as often
[16:42] <sinzui> rick_h_, yes, I think you have fixed the real bug I experienced
[16:43] <rick_h_> sinzui: ok cool. Thanks for the link to the other bug. Want to make sure I catch all the parts here
[16:44] <sinzui> rick_h_, if you can edit, and after the edit the text "Edit" does not appear, you have fixed my use case. I will remove the tags from the other bug. I guess it is tech-debt
[16:45] <rick_h_> sinzui: yea, the only thing now is that edit always shows even when there's only one value "Public" so I'll probably fix this bug but then file a bug about hiding that all together when there's only the one choice
[16:45] <sinzui> ah
[16:46] <sinzui> rick_h_, toggleClass('hidden') was the intent then...and choice source does not do it.
[16:47] <rick_h_> sinzui: gotcha. Yea, so I'll file a new bug about that then with this as the specific use case
[16:49] <sinzui> rick_h_, so maybe the choice source should know to hide EDITICON when the length of choices are 1?
[16:50] <sinzui> How do proprietary only bugs and branch portlets solve this?
[16:51] <rick_h_> sinzui: yea, that's what I would expect.
[16:51] <rick_h_> sinzui: I'm going to check out how branches solve this. It's not jumping out at me and I want to get this fix in asap.
[16:58] <sinzui> rick_h_, This is not your problem...or at least this is not about blueprints.
[16:58] <sinzui> rick_h_, https://code.qastaging.launchpad.net/~launchpad/launchpad-help-moin-theme/moin_launchpad shows a choice of 1
[16:58] <rick_h_> sinzui: agreed which is why it'll be a new bug for now. I've got to wrap this up and move onto some more private project stuff
[16:59] <rick_h_> sinzui: ah, good to know then. Thanks
[16:59] <sinzui> okay
[17:07] <rick_h_> benji: https://code.launchpad.net/~rharding/launchpad/info_portlet_1052551/+merge/129706 for your eyeballs if you get a sec please
[17:08] <benji> rick_h_: sure
[19:00] <abentley> benji: could you please review https://code.launchpad.net/~abentley/launchpad/workitems-for-private-blueprints/+merge/129736 ?
[19:01] <benji> abentley: sure
[19:44] <abentley> benji: Thanks.
[19:44] <benji> my pleasure
[19:51] <abentley> rick_h_: Are you using my getProductPrivacyFilter for fixing bug #1063272 ?
[19:51] <_mup_> Bug #1063272: Cannot view +related-projects because of private-project <403> <private-projects> <Launchpad itself:In Progress by rharding> < https://launchpad.net/bugs/1063272 >
[19:54] <adeuring> rick_h_: my branch landed finally
[20:53] <beuno> wgrant, ping
[20:54] <beuno> wgrant, looking for a reviewer for a python-oops-tools branch: https://code.launchpad.net/~beuno/python-oops-tools/show-newest-oopses/+merge/129752
[20:59] <czajkowski> beuno: on call reviewer is benji
[21:00] <beuno> czajkowski, this may be a tad specific to throw in the general review queue
[21:19] <beuno> benji, thanks
[21:19] <beuno> benji, I'll reply in the merge proposal but the spaces after the comma are pep-8 complaints
[21:20] <benji> beuno: right, but the commas themseleves are what stood out to me
[21:21] <beuno> benji, ah, yes, there's a bunch of XXXs warning that it needs refactoring
[21:21] <beuno> didn't look into it
[21:22] <benji> beuno: I figured a code formatting tool or search/replace was used and the strange comma-after-a-single-item-list threw it off
[21:23] <beuno> right
[21:23] <beuno> no, all the crazy is hand-crafted!
[21:28]  * benji starts selling t-shirts with "all the crazy is hand-crafted!" on them.
[21:45] <wgrant> beuno: I'm happy to review that, but any Launchpad reviewer can also do it
[21:45] <wgrant> As benji suggests :)
[21:52] <beuno> wgrant, cool, thanks
[21:54] <wgrant> abentley: Do you have a branch in progress to stormify Person.specifications? I have a branch that needs it, so if not then I'll do it today.
[21:55] <abentley> wgrant: Yes, I do.
[21:55] <abentley> wgrant: ~abentley/launchpad/user-blueprints
[21:55] <wgrant> abentley: Thanks
[21:56] <wgrant> Although it's mysteriously empty
[21:56] <abentley> wgrant: I just pushed it now.
[21:56] <wgrant> Ah
[21:56] <wgrant> abentley: Is it likely to land in the next day or so?
[21:56] <abentley> wgrant: I'm just in the middle of adding unit tests for the existing behaviour.
[21:57] <wgrant> Right, it certainly needed it :/
[21:57] <abentley> wgrant: Yes, ideally it will land tomorrow.
[21:57] <wgrant> Great, thanks.
[21:58] <abentley> wgrant: What is your branch doing?
[21:58] <wgrant> abentley: Fixing the +specworkload timeouts, which needs that query to be reworded and run over multiple people
[22:00] <abentley> wgrant: Okay.  So where I'd naively put  "Specification.drafter = user.id", you
[22:00] <abentley> want to do "Specification.drafter.is_in(user_ids)" etc?
[22:00] <beuno> benji, addresed and pushed
[22:01] <wgrant> abentley: Right, I'll need to extract it out to separate function/method
[22:03] <abentley> wgrant: I should have *something* in the next couple of hours, but likely won't finish 'till tomorrow.
[22:04] <james_w> beuno, doesn't the db have the information on newest oopses?
[22:04] <beuno> james_w, I don't actually know  :)
[22:04] <wgrant> It does :)
[22:04] <beuno> wasn't sure if the oopses get processed and stored in PG as they come in
[22:04] <wgrant> I haven't actually looked at the branch yet
[22:05] <wgrant> You can find the latest with a simple Django ORM query
[22:05] <beuno> that would of been much simpler
[22:05] <james_w> benji, they do
[22:05] <james_w> beuno I mean
[22:05] <james_w> and much more efficient :-)
[22:05] <beuno> indeed
[22:05] <beuno> ok
[22:05] <beuno> so I need to change everything!
[22:06] <wgrant> Well, "everything" == "one 10 line method", but yes :)
[22:06] <james_w> well, not everything :-)
[22:06] <beuno> no, EVERYTHING
[22:06] <beuno> or not
[22:07] <beuno> test should still pass, so forced TDD!
[22:07] <beuno> but, at this stage I
[22:07] <beuno> I'll add what I was going to in my follow up branch
[22:07] <beuno> relative time since the oops and some data about it
[22:09] <wgrant> I want to add a similar thing to show the latest OOPSes for a pageid on a particular instance.
[22:09] <wgrant> But haven't got around to it yet
[22:28] <abentley> wgrant: Initial implementation is pushed.  Lots more to go.
[22:29] <wgrant> abentley: Lovely. Thanks
[23:19] <rick_h_> abentley: didn't get that far before EOD to tell yet
[23:21] <abentley> rick_h_: I expect that it will want to use it, so I was leaving it alone until the other branch lands.
[23:21] <rick_h_> abentley: abel's branch?
[23:21] <abentley> rick_h_: No, mine.
[23:21] <rick_h_> abentley: I just merge his stuff and going to get my stuff waiting on that to ec2 for the night
[23:21] <rick_h_> abentley: ah ok
[23:22] <rick_h_> abentley: thanks for the heads up. I'll take a peek then at your stuff you've got in the wings
[23:52] <wgrant> win 43
[23:53] <rick_h_> 44


[14:37] <mup> Issue operator#517 opened: AttributeError: 'property' object has no attribute 'Layer'  <Created by eminaktas> <https://github.com/canonical/operator/issues/517>
[15:01] <mup> Issue operator#518 opened: Support pebble push testing in harness <Created by balbirthomas> <https://github.com/canonical/operator/issues/518>
[16:15] <mup> Issue operator#519 opened: A Guarantee that workload is never null <Created by balbirthomas> <https://github.com/canonical/operator/issues/519>


[17:19] <akgraner> Hi all!  sorry I have been away this week and swamped at work...
[17:20] <akgraner> nhandler, no I needed to help him and I wasn't able too :-(
[18:02] <pleia2> akgraner: do you have time this weekend to teach several of us at once? at least that will allow us to see the status of the issue so we can pitch in throughout the process if we can't get ahold of you