Re: Why is Fx 57 in Updates Testing?
On Thu, 12 Oct 2017, Adam Williamson wrote: it sounds like downgrading from 56 to 52 (the most recent ESR), aside from the epoch bump it'd require on our side, is not straightforward (it seems there were profile changes between 56 and 52). Ouch. Is now a good time to think about how we could try to avoid getting into a similar situation again in the future? I see that Firefox ESR releases are supported for one year plus twelve weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/). For Fedora 27, would it be safer to include Firefox 57 and 58, but then stick with Firefox 59 ESR from March onwards? -- Peter Oliver ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
Another option could be to ship Fedora 27 with a Firefox 57 prerelease version. This will stop breakage of extensions 2 weeks after Fedora 27 ships (and shipped extensions can be moved to web extension version). On 13 Oct 2017 12:31 pm, "Peter Oliver" < lists.fedoraproject@mavit.org.uk> wrote: > On Thu, 12 Oct 2017, Adam Williamson wrote: > > it sounds like downgrading from 56 to 52 >> (the most recent ESR), aside from the epoch bump it'd require on our >> side, is not straightforward (it seems there were profile changes >> between 56 and 52). >> > > Ouch. > > Is now a good time to think about how we could try to avoid getting into a > similar situation again in the future? > > I see that Firefox ESR releases are supported for one year plus twelve > weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/). For > Fedora 27, would it be safer to include Firefox 57 and 58, but then stick > with Firefox 59 ESR from March onwards? > > -- > Peter Oliver > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On 10/13/2017 01:29 PM, Peter Oliver wrote: On Thu, 12 Oct 2017, Adam Williamson wrote: it sounds like downgrading from 56 to 52 (the most recent ESR), aside from the epoch bump it'd require on our side, is not straightforward (it seems there were profile changes between 56 and 52). Ouch. Is now a good time to think about how we could try to avoid getting into a similar situation again in the future? I see that Firefox ESR releases are supported for one year plus twelve weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/). For Fedora 27, would it be safer to include Firefox 57 and 58, but then stick with Firefox 59 ESR from March onwards? Fedora can certainly ship ESR line but nobody wants to package/maintain it. ma. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, Oct 13, 2017 at 02:21:42PM +0200, Martin Stransky wrote: > On 10/13/2017 01:29 PM, Peter Oliver wrote: > >On Thu, 12 Oct 2017, Adam Williamson wrote: > > > >>it sounds like downgrading from 56 to 52 > >>(the most recent ESR), aside from the epoch bump it'd require on our > >>side, is not straightforward (it seems there were profile changes > >>between 56 and 52). > > > >Ouch. > > > >Is now a good time to think about how we could try to avoid > >getting into a similar situation again in the future? > > > >I see that Firefox ESR releases are supported for one year plus > >twelve weeks > >(https://www.mozilla.org/en-US/firefox/organizations/faq/). For > >Fedora 27, would it be safer to include Firefox 57 and 58, but > >then stick with Firefox 59 ESR from March onwards? > Fedora can certainly ship ESR line but nobody wants to package/maintain it. ... and nobody even seems to want to use it :) I think that we cannot ignore or escape the fact that we can't hold back Firefox updates. Firefox 57 seems _very_ nice, but even if it wasn't, we just don't have the manpower to hold onto old Firefox versions for a long time. Lifetime of Fedora 27 is 13 or 14 months after the final release of FF57, and by the end of that period FF56 is going to be quite dated, and FF52 ESR even more so. All the energy devoted to this thread would imho be better spent on trying to encourage the authors of popular extensions to update to the new model, or trying to find alternatives that work with FF57+. Personally, I now have µBlock Origin, Gnome Shell Integration, and uMatrix as a replacement for noScript, and that covers my basic needs. The rest I can live without. I'd encourage everybody else to make similar reckoning, and identify the missing _essential_ extensions, and concentrate on them. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote: All the energy devoted to this thread would imho be better spent on trying to encourage the authors of popular extensions to update to the new model, My understanding is that the new API lacks capabilities needed to make some extensions possible. Mozilla may or may not reimplement some of these functionalities in the future, but, for the time being, there’s little that the authors of such extensions can do. -- Peter Oliver___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Broken dependencies: audacity
Pierre-Yves Chibon wrote: On Mon, Oct 09, 2017 at 08:44:27AM +0200, Pierre-Yves Chibon wrote: I think I found the issue. Last week we finally migrated the ACLs from pkgdb to pagure but it looks like the query I used to export the ACLs from pkgdb wasn't restricted to active Fedora branch, so it tooks the old branch as well which ended up for you with two entries: rpms,audacity,mschwendt,commit,Approved rpms,audacity,mschwendt,commit,Obsolete The first line added you and the second one was ignored (I wasn't going to migrate obsolete ACLs) so you can guess the outcome of that :) Took a little more time than I thought but I believe this is all fixed now. Feel free to let us know if you think otherwise. It might be unrelated, but I've received broken dependency notifications for nginx the past two days. I've never been a maintainer or contributor to nginx. I did fork the repo in pagure, just to look at patching a bug in the epel7 branch. Is it possible that the recent re-syncing of the ACL's picked up that fork unintentionally? -- Todd ~~ It takes 43 muscles to frown and 17 to smile, but it doesn't take any to just sit there with a dumb look on your face. -- Demotivators (www.despair.com) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, Oct 13, 2017 at 02:55:37PM +0100, Peter Oliver wrote: > On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote: > > >All the energy devoted to this thread would imho be better spent on > >trying to encourage the authors of popular extensions to update to the > >new model, > > My understanding is that the new API lacks capabilities needed to > make some extensions possible. Mozilla may or may not reimplement > some of these functionalities in the future, but, for the time > being, there’s little that the authors of such extensions can do. Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fx 57 Release Issues
Changing the subject to reflect the actual discussion. Apparently many people are unaware of Mozilla's plan for Fx and webextensions: Here are some links which might be helpful: https://blog.mozilla.org/addons/2015/08/21/the-future- of-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/ https://arewewebextensionsyet.com/ On Fri, Oct 13, 2017 at 6:55 AM, Peter Oliver wrote: > On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote: > > All the energy devoted to this thread would imho be better spent on >> trying to encourage the authors of popular extensions to update to the >> new model, >> > > My understanding is that the new API lacks capabilities needed to make > some extensions possible. Mozilla may or may not reimplement some of these > functionalities in the future, but, for the time being, there’s little that > the authors of such extensions can do. > > -- > Peter Oliver > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On 13/10/17 15:26, Zbigniew Jędrzejewski-Szmek wrote: Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly. So lets do a little review of the things I have installed in one of my firefox instances that aren't currently firefox 57 compatible... This is after I've dumped some rarely used things that I decided were unlikely to get an update. Cookie Monster Seemed to have been removed from AMO and no obvious replacement. Download Manager (S3) Author reports it can't be ported due to lack of required APIs and the same presumably applies to the various similar extensions none of which show any sign of being ported. There are bugs open with mozilla for providing a toolbar API for this but they're not saying much other than "on the roadmap" which could mean anything. Extension List Dumper 2 Last update in January, no sign of an update or of an obvious replacement but only used occasionally. NoScript Supposedly getting a five-to-midnight fix and other options are available if that doesn't happen. NoSquint Plus Last update yesterday but no mention of WE plans on AMO page but Zoom Page WE is possible replacement. pdfit Ancient and only in use because the (better) extension I used to use to save as PDF stopped working. Will likely replace with screenshots once that has "whole page" mode working. Saved Password Editor Needs new APIs which are supposedly in the works but won't be available for 57 at least. Tab Groups Author has stated (in a long rant) that he is not going to port to WE and that in any case the APIs will probably always be too limited for it to be possible. View Cookies Last updated nearly two years ago with no signs of life and no obvious replacement. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fx 57 Release Issues
There are also several alternatives for those who for whatever reason do not want to use the new Fx, and want to continue using the old extension system: https://www.waterfoxproject.org/ http://www.palemoon.org/ https://www.seamonkey-project.org/ On Fri, Oct 13, 2017 at 7:34 AM, Gerald B. Cox wrote: > Changing the subject to reflect the actual discussion. > > Apparently many people are unaware of Mozilla's plan for Fx and > webextensions: > > Here are some links which might be helpful: > > https://blog.mozilla.org/addons/2015/08/21/the-future-of- > developing-firefox-add-ons/ > > https://blog.mozilla.org/addons/2017/02/16/the-road-to- > firefox-57-compatibility-milestones/ > > https://arewewebextensionsyet.com/ > > > > > > On Fri, Oct 13, 2017 at 6:55 AM, Peter Oliver < > lists.fedoraproject@mavit.org.uk> wrote: > >> On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote: >> >> All the energy devoted to this thread would imho be better spent on >>> trying to encourage the authors of popular extensions to update to the >>> new model, >>> >> >> My understanding is that the new API lacks capabilities needed to make >> some extensions possible. Mozilla may or may not reimplement some of these >> functionalities in the future, but, for the time being, there’s little that >> the authors of such extensions can do. >> >> -- >> Peter Oliver >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> >> > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, Oct 13, 2017 at 01:14:50PM +, Zbigniew Jędrzejewski-Szmek wrote: > All the energy devoted to this thread would imho be better spent on > trying to encourage the authors of popular extensions to update to the > new model, or trying to find alternatives that work with FF57+. > Personally, I now have µBlock Origin, Gnome Shell Integration, and > uMatrix as a replacement for noScript, and that covers my basic needs. > The rest I can live without. I'd encourage everybody else to make similar > reckoning, and identify the missing _essential_ extensions, and > concentrate on them. +1 Although some extensions are hopeless, as pointed out earlier in the thread. I maintain a small extension to toggle proxy configurations and had to completely rewrite it to support webextensions and even though it still carries the same name/branding, it is a completely different extension regarding its features (still better than letting users down). I feel sorry for people who put a lot of effort maintaining their extensions who now have to either abandon them and their users or completely rewrite their extensions. -- Athos Ribeiro http://www.ime.usp.br/~athoscr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Broken dependencies: audacity
On Fri, Oct 13, 2017 at 10:15:37AM -0400, Todd Zullinger wrote: > Pierre-Yves Chibon wrote: > > On Mon, Oct 09, 2017 at 08:44:27AM +0200, Pierre-Yves Chibon wrote: > > > I think I found the issue. Last week we finally migrated the ACLs > > > from pkgdb to pagure but it looks like the query I used to export > > > the ACLs from pkgdb wasn't restricted to active Fedora branch, so it > > > tooks the old branch as well which ended up for you with two > > > entries: > > > rpms,audacity,mschwendt,commit,Approved > > > rpms,audacity,mschwendt,commit,Obsolete > > > > > > The first line added you and the second one was ignored (I wasn't > > > going to migrate obsolete ACLs) so you can guess the outcome of that > > > :) > > > > Took a little more time than I thought but I believe this is all fixed > > now. Feel free to let us know if you think otherwise. > > It might be unrelated, but I've received broken dependency notifications for > nginx the past two days. I've never been a maintainer or contributor to > nginx. I did fork the repo in pagure, just to look at patching a bug in the > epel7 branch. Is it possible that the recent re-syncing of the ACL's picked > up that fork unintentionally? As far as I can see there is nothing linking you to rpms/nginx on pagure itself. Could you see if it happens again and forward me the email if so? Thanks, Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, Oct 13, 2017 at 6:04 PM, Athos Ribeiro wrote: > I maintain a small extension to toggle proxy configurations […] Hi Athos, Does noturno support proxy authentication by any chance ;) ? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Broken dependencies: audacity
Pierre-Yves Chibon wrote: On Fri, Oct 13, 2017 at 10:15:37AM -0400, Todd Zullinger wrote: It might be unrelated, but I've received broken dependency notifications for nginx the past two days. I've never been a maintainer or contributor to nginx. I did fork the repo in pagure, just to look at patching a bug in the epel7 branch. Is it possible that the recent re-syncing of the ACL's picked up that fork unintentionally? As far as I can see there is nothing linking you to rpms/nginx on pagure itself. Could you see if it happens again and forward me the email if so? Sure. And thanks. :) -- Todd ~~ Honesty is the best policy, but insanity is a better defense. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
Please use the thread Fx 57 Release Issues. This discussion isn't about the use of the updates-testing repository for non-update software. On Fri, Oct 13, 2017 at 8:23 AM, Alexander Ploumistos < alex.ploumis...@gmail.com> wrote: > On Fri, Oct 13, 2017 at 6:04 PM, Athos Ribeiro > wrote: > > I maintain a small extension to toggle proxy configurations […] > > Hi Athos, > Does noturno support proxy authentication by any chance ;) ? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, Oct 13, 2017 at 6:31 PM, Gerald B. Cox wrote: > Please use the thread Fx 57 Release Issues. This discussion isn't about the > use of the updates-testing repository for non-update software. Sure, sorry for the digression. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, 2017-10-13 at 12:29 +0100, Peter Oliver wrote: > On Thu, 12 Oct 2017, Adam Williamson wrote: > > > it sounds like downgrading from 56 to 52 > > (the most recent ESR), aside from the epoch bump it'd require on our > > side, is not straightforward (it seems there were profile changes > > between 56 and 52). > > Ouch. > > Is now a good time to think about how we could try to avoid getting into a > similar situation again in the future? > > I see that Firefox ESR releases are supported for one year plus twelve weeks > (https://www.mozilla.org/en-US/firefox/organizations/faq/). For Fedora 27, > would it be safer to include Firefox 57 and 58, but then stick with Firefox > 59 ESR from March onwards? We've chosen not to ship ESR in the past, AIUI, because we think our target audiences generally prefer to get the main Firefox release stream, they don't want the ESR stream. We could change that decision, of course. I don't personally think a one-off ouch-y event like this would entirely justify such a change, but it'd be interesting to know if the Quantum stuff means a series of such ouch-y events might potentially be coming to the main release stream. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
Adam, can you please use the other thread. This discussion has gotten way off topic. The other thread I opened is Fx 57 Release Issues. Thanks! On Fri, Oct 13, 2017 at 8:40 AM, Adam Williamson wrote: > On Fri, 2017-10-13 at 12:29 +0100, Peter Oliver wrote: > > On Thu, 12 Oct 2017, Adam Williamson wrote: > > > > > it sounds like downgrading from 56 to 52 > > > (the most recent ESR), aside from the epoch bump it'd require on our > > > side, is not straightforward (it seems there were profile changes > > > between 56 and 52). > > > > Ouch. > > > > Is now a good time to think about how we could try to avoid getting into > a similar situation again in the future? > > > > I see that Firefox ESR releases are supported for one year plus twelve > weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/). For > Fedora 27, would it be safer to include Firefox 57 and 58, but then stick > with Firefox 59 ESR from March onwards? > > We've chosen not to ship ESR in the past, AIUI, because we think our > target audiences generally prefer to get the main Firefox release > stream, they don't want the ESR stream. We could change that decision, > of course. I don't personally think a one-off ouch-y event like this > would entirely justify such a change, but it'd be interesting to know > if the Quantum stuff means a series of such ouch-y events might > potentially be coming to the main release stream. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On 10/13/2017 10:40 AM, Adam Williamson wrote: We've chosen not to ship ESR in the past, AIUI, because we think our target audiences generally prefer to get the main Firefox release stream, they don't want the ESR stream. We could change that decision, of course. I don't personally think a one-off ouch-y event like this would entirely justify such a change, but it'd be interesting to know if the Quantum stuff means a series of such ouch-y events might potentially be coming to the main release stream. Shipping ESR will just lead to fragmentation of the user base. Some will create a copr with the latest version. Is everyone being over-dramatic (per usual)? Does this update break the entire browser? Could I make plenty more rhetorical questions? If we're going to suggest shipping ESR we might as well stop shipping the latest kernel, too. I can't believe I replied to this thread. :( ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, 2017-10-13 at 15:56 +0100, Tom Hughes wrote: > On 13/10/17 15:26, Zbigniew Jędrzejewski-Szmek wrote: > > > Sure, that's what everybody knows. But without going from generalities > > to details of a specific extension, we're just speculating idly. > > So lets do a little review of the things I have installed in one of my > firefox instances that aren't currently firefox 57 compatible... This is > after I've dumped some rarely used things that I decided were unlikely > to get an update. > > Cookie Monster > >Seemed to have been removed from AMO and no obvious replacement. I use(d) Self Destructing Cookies, but the page for that one says it's not being rewritten as a webextension and will be abandoned: https://addons.mozilla.org/EN-US/firefox/addon/self-destructing-cookies/ "This add-on is no longer maintained. It is incompatible with Firefox 55+ and this will never change. Also, it will not be rewritten as a WebExtension." https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/ seems to be a new webextension along the same lines, I don't know how good / safe it is or whether it does what you wanted from Cookie Monster. > NoSquint Plus > >Last update yesterday but no mention of WE plans on AMO page >but Zoom Page WE is possible replacement. I use this one too, it's useful for sites that don't play well with hidpi, though those are becoming less common now. I imagine it may be important for older / vision-impaired users, though. > Tab Groups > >Author has stated (in a long rant) that he is not going to port >to WE and that in any case the APIs will probably always be too >limited for it to be possible. As this was previously a Firefox feature and the excuse when removing it was "don't worry, it'll be available as an extension" this seems like a rather important one! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, 2017-10-13 at 08:44 -0700, Gerald B. Cox wrote: > Adam, can you please use the other thread. This discussion has gotten way > off topic. The other thread I opened is Fx 57 Release Issues. I think that ship sailed long ago, I'm afraid. I can't really 'move' a reply to the other thread, email doesn't work that way. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, 2017-10-13 at 10:47 -0500, Michael Cronenworth wrote: > > Is everyone being over-dramatic (per usual)? To take that personally for a minute, well, no, I don't believe I've been over-dramatic at all. I've never suggested anything besides 'maybe we should take a look at whether shipping Firefox 57 as fast as we usually ship updates is the best idea', and that's all the FESCo ticket I filed says. (My specific suggestion so far has been not to ship it for a couple of weeks after upstream releases it, to see just how common complaints turn out to be in widespread public use). It's not my fault that people seem to have taken this off in weird directions like "can we switch to ESR forever?!" or "can we maintain FF 56 until Fedora 27 EOL?!" -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On 13/10/17 16:48, Adam Williamson wrote: On Fri, 2017-10-13 at 15:56 +0100, Tom Hughes wrote: Cookie Monster Seemed to have been removed from AMO and no obvious replacement. I use(d) Self Destructing Cookies, but the page for that one says it's not being rewritten as a webextension and will be abandoned: https://addons.mozilla.org/EN-US/firefox/addon/self-destructing-cookies/ "This add-on is no longer maintained. It is incompatible with Firefox 55+ and this will never change. Also, it will not be rewritten as a WebExtension." https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/ seems to be a new webextension along the same lines, I don't know how good / safe it is or whether it does what you wanted from Cookie Monster. Yes it's not quite the same thing but it might actually be an even better solution so I had my eye on that as a possible replacement. NoSquint Plus Last update yesterday but no mention of WE plans on AMO page but Zoom Page WE is possible replacement. I use this one too, it's useful for sites that don't play well with hidpi, though those are becoming less common now. I imagine it may be important for older / vision-impaired users, though. I mostly just fine that some sites make weirdly small font choices ;-) I actually use it in text-zoom mode rather than the default full-zoom mode. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)
On Thu, Oct 12, 2017 at 11:46:42PM -0700, Adam Williamson wrote: > That's far less important. Especially the distinction between > enhancement and newpackage, I think, barely matters. If we had this metadata for stuff that lands in Rawhide, it'd be useful, but since we don't, it's basically just fluff. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, 2017-10-13 at 14:26 +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Oct 13, 2017 at 02:55:37PM +0100, Peter Oliver wrote: > > On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote: > > > > > All the energy devoted to this thread would imho be better spent on > > > trying to encourage the authors of popular extensions to update to the > > > new model, > > > > My understanding is that the new API lacks capabilities needed to > > make some extensions possible. Mozilla may or may not reimplement > > some of these functionalities in the future, but, for the time > > being, there’s little that the authors of such extensions can do. > > Sure, that's what everybody knows. But without going from generalities > to details of a specific extension, we're just speculating idly. Someone's given one example already, here's another: https://addons.mozilla.org/en-US/firefox/addon/calomel-ssl-validation/ "IMPORTANT: Development of the Calomel SSL Validation addon has been put on hold. Mozilla is disabling XUL and XPCOM in Firefox which means the addon is no longer able to query the current browser tab for the TLS certificate and cipher information." Sure, you can just manually inspect the details of any given site's certificate and TLS config, but Calomel's icon and grading system made it much easier to notice when some important site had a bad config. :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On vendredi 13 octobre 2017 17:48:51 CEST Adam Williamson wrote: > On Fri, 2017-10-13 at 15:56 +0100, Tom Hughes wrote: > > > On 13/10/17 15:26, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > Sure, that's what everybody knows. But without going from generalities > > > to details of a specific extension, we're just speculating idly. > > > > > > So lets do a little review of the things I have installed in one of my > > firefox instances that aren't currently firefox 57 compatible... This is > > after I've dumped some rarely used things that I decided were unlikely > > to get an update. > > > > Cookie Monster > > > > > >Seemed to have been removed from AMO and no obvious replacement. > > > I use(d) Self Destructing Cookies, but the page for that one says it's > not being rewritten as a webextension and will be abandoned: > > https://addons.mozilla.org/EN-US/firefox/addon/self-destructing-cookies/ > > "This add-on is no longer maintained. It is incompatible with Firefox > 55+ and this will never change. Also, it will not be rewritten as a > WebExtension." > You can replace SDC with Cookie AutoDelete by Kenny Do: https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/ It does not support the removal of Localstorage or IndexedDB yet, but the API allowing this are landing in Firefox 58: - https://bugzilla.mozilla.org/show_bug.cgi?id=1388428 - https://bugzilla.mozilla.org/show_bug.cgi?id=1333050 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, 2017-10-13 at 18:48 +0200, Robert-André Mauchin wrote: > On vendredi 13 octobre 2017 17:48:51 CEST Adam Williamson wrote: > > On Fri, 2017-10-13 at 15:56 +0100, Tom Hughes wrote: > > > > > On 13/10/17 15:26, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > > > > Sure, that's what everybody knows. But without going from generalities > > > > to details of a specific extension, we're just speculating idly. > > > > > > > > > So lets do a little review of the things I have installed in one of my > > > firefox instances that aren't currently firefox 57 compatible... This is > > > after I've dumped some rarely used things that I decided were unlikely > > > to get an update. > > > > > > Cookie Monster > > > > > > > > >Seemed to have been removed from AMO and no obvious replacement. > > > > > > I use(d) Self Destructing Cookies, but the page for that one says it's > > not being rewritten as a webextension and will be abandoned: > > > > https://addons.mozilla.org/EN-US/firefox/addon/self-destructing-cookies/ > > > > "This add-on is no longer maintained. It is incompatible with Firefox > > 55+ and this will never change. Also, it will not be rewritten as a > > WebExtension." > > > > You can replace SDC with Cookie AutoDelete by Kenny Do: > > https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/ Uhhh...you mean like the *very next paragraph of my email*, which you cut out, said? I mean, good grief, maybe finish reading it before hitting Reply next time? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Fri, 2017-10-13 at 09:43 -0700, Adam Williamson wrote: > On Fri, 2017-10-13 at 14:26 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Oct 13, 2017 at 02:55:37PM +0100, Peter Oliver wrote: > > > On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > All the energy devoted to this thread would imho be better > > > > spent on > > > > trying to encourage the authors of popular extensions to update > > > > to the > > > > new model, > > > > > > My understanding is that the new API lacks capabilities needed to > > > make some extensions possible. Mozilla may or may not > > > reimplement > > > some of these functionalities in the future, but, for the time > > > being, there’s little that the authors of such extensions can do. > > > > Sure, that's what everybody knows. But without going from > > generalities > > to details of a specific extension, we're just speculating idly. > > Someone's given one example already, here's another: > > https://addons.mozilla.org/en-US/firefox/addon/calomel-ssl-validation > / > > "IMPORTANT: Development of the Calomel SSL Validation addon has been > put on hold. Mozilla is disabling XUL and XPCOM in Firefox which > means > the addon is no longer able to query the current browser tab for the > TLS certificate and cipher information." > > Sure, you can just manually inspect the details of any given site's > certificate and TLS config, but Calomel's icon and grading system > made > it much easier to notice when some important site had a bad config. > :/ Adam not replying just to you but the general thread. What is the point of bringing up all these plugins breakage ? If Mozilla doesn't care, at most you are going to defer the inevitable by what? 2/3 weeks ? You can do the same by deferring your upgrade to Fedora 27 on your own ... or manually downloading the ESR from Mozilla and running that one. We are Fedora and we are First, even when it is painful IMHO. The only case when it is appropriate to discuss slowing down a project is if there are known security/privacy/whatever vulnerabilities that are going to be addressed very soon upstream anyway. If the *direction* of the project is under discussion then the only appropriate way is to let the project go and search for a replacement for the default. In light of this I think any suggestion of slowing down adoption of the new version in F27 is misplaced. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
On Oct 13, 2017 19:00, "Simo Sorce" wrote: We are Fedora and we are First, even when it is painful IMHO. I count for little in the Fedora community, but this is exactly my opinion in this discussion. A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why is Fx 57 in Updates Testing?
> Does this update break the entire browser? No, it's more akin to the switch from Gnome 2 to Gnome 3: lots of changes all over the place, old trusted features gone, replacements not totally there and in any case different requiring user adaptation. Which all means our release planning is too focused on Gnome and not enough thought is put into the roadmap of major non-Gnome desktop apps such as Firefox or Libreoffice. I'd argue that this kind of Firefox change is way more impacting for our users than the latest gnome settings redesign. Too late to switch to ESR now, the best outcome would be to make FF57 a major feature of F27 (since it will be), ship it (even as prerelease) from day 1 and pretend that was always what our release engineering intended to do. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)
On 10/12/2017 05:34 PM, Adam Williamson wrote: > In this case there's an even worse consequence; if you do attempt to > update to nss 3.33.0 without nspr 4.17.0 dnf will 'skip' *most* of the > nss packages (as it notices that they are missing dependencies), but it > *will* install nss-softokn-freebl . With this mix of packages (most of > nss at 3.32.0, but nss-softokn-freebl at 3.33.0), nss and anything that > depends on it just fails to work at all - e.g. curl and dnf...so that's > an extremely bad outcome. Then isn't this a packaging bug? They currently use ">=" requirements, but if a greater version doesn't work, shouldn't they be "="? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20171013.n.0 compose check report
Missing expected images: Server dvd i386 Workstation live i386 Server boot i386 Kde live i386 Failed openQA tests: 85/128 (x86_64), 1/2 (arm) Old failures (same test failed in Rawhide-20171012.n.0): ID: 157120 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/157120 ID: 157121 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/157121 ID: 157123 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/157123 ID: 157124 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/157124 ID: 157126 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/157126 ID: 157130 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/157130 ID: 157131 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/157131 ID: 157142 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/157142 ID: 157143 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/157143 ID: 157145 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/157145 ID: 157149 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/157149 ID: 157151 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/157151 ID: 157155 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/157155 ID: 157157 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/157157 ID: 157158 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/157158 ID: 157159 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/157159 ID: 157160 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/157160 ID: 157161 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/157161 ID: 157162 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/157162 ID: 157163 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/157163 ID: 157164 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/157164 ID: 157174 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/157174 ID: 157176 Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/157176 ID: 157177 Test: x86_64 Atomic-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/157177 ID: 157178 Test: x86_64 universal install_multi_empty URL: https://openqa.fedoraproject.org/tests/157178 ID: 157179 Test: x86_64 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/157179 ID: 157181 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/157181 ID: 157182 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/157182 ID: 157183 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/157183 ID: 157184 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/157184 ID: 157185 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/157185 ID: 157186 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/157186 ID: 157187 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/157187 ID: 157188 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/157188 ID: 157189 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/157189 ID: 157190 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/157190 ID: 157191 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/157191 ID: 157192 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/157192 ID: 157193 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/157193 ID: 157194 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/157194 ID: 157195 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/157195 ID: 157196 Test: x86_6
Fedora 27-20171013.n.0 compose check report
Missing expected images: Server dvd i386 Workstation live i386 Server boot i386 Kde live i386 Failed openQA tests: 24/128 (x86_64), 1/2 (arm) New failures (same test did not fail in 27-20171012.n.0): ID: 157273 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/157273 ID: 157276 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/157276 ID: 157290 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/157290 ID: 157291 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/157291 ID: 157292 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/157292 ID: 157293 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/157293 ID: 157294 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/157294 ID: 157305 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm URL: https://openqa.fedoraproject.org/tests/157305 ID: 157312 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/157312 ID: 157328 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/157328 ID: 157333 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/157333 ID: 157363 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/157363 ID: 157364 Test: x86_64 universal install_sata URL: https://openqa.fedoraproject.org/tests/157364 Old failures (same test failed in 27-20171012.n.0): ID: 157265 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/157265 ID: 157275 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/157275 ID: 157281 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/157281 ID: 157285 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/157285 ID: 157324 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/157324 ID: 157326 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/157326 ID: 157329 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/157329 ID: 157339 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/157339 ID: 157340 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/157340 ID: 157346 Test: x86_64 universal install_rescue_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/157346 ID: 157361 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/157361 ID: 157378 Test: x86_64 universal install_rescue_encrypted URL: https://openqa.fedoraproject.org/tests/157378 Soft failed openQA tests: 5/128 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in 27-20171012.n.0): ID: 157277 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/157277 Old soft failures (same test soft failed in 27-20171012.n.0): ID: 157323 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/157323 ID: 157325 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/157325 ID: 157330 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/157330 ID: 157332 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/157332 Passed openQA tests: 89/128 (x86_64), 1/2 (arm) New passes (same test did not pass in 27-20171012.n.0): ID: 157250 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/157250 ID: 157251 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/157251 ID: 157272 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/157272 ID: 157304 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/157304 Skipped openQA tests: 9 of 130 Installed system changes in test x86_64 Server-boot-iso install_default@uefi: Mount / contents changed to 86.95411780% of previous size 1 packages(s) added since previous compose: libzstd 1 services(s) removed since previous compose: getty@tty6.service Previous test data: https://openqa.fedoraproject.org/tests/156759#downloads Current test data: https://openqa.fedoraproject.org/tests/1
Re: Why is Fx 57 in Updates Testing?
On Fri, 2017-10-13 at 12:58 -0400, Simo Sorce wrote: > On Fri, 2017-10-13 at 09:43 -0700, Adam Williamson wrote: > > On Fri, 2017-10-13 at 14:26 +, Zbigniew Jędrzejewski-Szmek wrote: > > > On Fri, Oct 13, 2017 at 02:55:37PM +0100, Peter Oliver wrote: > > > > On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > > > All the energy devoted to this thread would imho be better > > > > > spent on > > > > > trying to encourage the authors of popular extensions to update > > > > > to the > > > > > new model, > > > > > > > > My understanding is that the new API lacks capabilities needed to > > > > make some extensions possible. Mozilla may or may not > > > > reimplement > > > > some of these functionalities in the future, but, for the time > > > > being, there’s little that the authors of such extensions can do. > > > > > > Sure, that's what everybody knows. But without going from > > > generalities > > > to details of a specific extension, we're just speculating idly. > > > > Someone's given one example already, here's another: > > > > https://addons.mozilla.org/en-US/firefox/addon/calomel-ssl-validation > > / > > > > "IMPORTANT: Development of the Calomel SSL Validation addon has been > > put on hold. Mozilla is disabling XUL and XPCOM in Firefox which > > means > > the addon is no longer able to query the current browser tab for the > > TLS certificate and cipher information." > > > > Sure, you can just manually inspect the details of any given site's > > certificate and TLS config, but Calomel's icon and grading system > > made > > it much easier to notice when some important site had a bad config. > > :/ > > Adam not replying just to you but the general thread. > What is the point of bringing up all these plugins breakage ? Zbigniew specifically asked for examples. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)
On Fri, 2017-10-13 at 10:38 -0700, Josh Stone wrote: > On 10/12/2017 05:34 PM, Adam Williamson wrote: > > In this case there's an even worse consequence; if you do attempt to > > update to nss 3.33.0 without nspr 4.17.0 dnf will 'skip' *most* of the > > nss packages (as it notices that they are missing dependencies), but it > > *will* install nss-softokn-freebl . With this mix of packages (most of > > nss at 3.32.0, but nss-softokn-freebl at 3.33.0), nss and anything that > > depends on it just fails to work at all - e.g. curl and dnf...so that's > > an extremely bad outcome. > > Then isn't this a packaging bug? They currently use ">=" requirements, > but if a greater version doesn't work, shouldn't they be "="? Well, there's *additionally* probably a packaging bug, yeah: nss- softokn-freebl should be more strictly tied to the other packages. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2017-10-13)
On Thu, Oct 12, 2017 at 3:43 PM, Adam Miller wrote: > Following is the list of topics that will be discussed in the > FESCo meeting Friday at 16:00UTC in #fedora-meeting on > irc.freenode.net. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/UTCHowto > > or run: > date -d '2017-10-13 16:00 UTC' > > > Links to all issues below can be found at: > https://pagure.io/fesco/report/meeting_agenda > > = Followups = > > These are considered followups because we didn't have a meeting last week and > they were on the agenda then > > #topic #1779 Consider fedora-* initscript units > .fesco 1779 > https://pagure.io/fesco/issue/1779 > > #topic #1780 F28 System Wide Change: Annobin > .fesco 1780 > https://pagure.io/fesco/issue/1780 > > = New business = > > #topic #1767 F28 Self Contained Changes - Facter 3 > .fesco 1767 > https://pagure.io/fesco/issue/1767#comment-471878 > > #topic #1775 f27 modular server release planning > .fesco 1775 > https://pagure.io/fesco/issue/1775 > > #topic #1780 F28 System Wide Change: Annobin > .fesco 1780 > https://pagure.io/fesco/issue/1780 > > #topic #1781 qt5-qtwebengine maintainership, kde-sig access rights > .fesco 1781 > https://pagure.io/fesco/issue/1781 > > #topic #1782 use of updates-testing for testing of non-update software > .fesco 1782 > https://pagure.io/fesco/issue/1782 > > #topic #1783 Firefox 57 and the Updates Policy > .fesco 1783 > https://pagure.io/fesco/issue/1783 > > = Open Floor = > > For more complete details, please visit each individual > issue. The report of the agenda items can be found at > https://pagure.io/fesco/report/meeting_agenda > > If you would like to add something to this agenda, you can > reply to this e-mail, file a new issue at > https://pagure.io/fesco, e-mail me directly, or bring it > up at the end of the meeting, during the open floor topic. Note > that added topics may be deferred until the following meeting. === #fedora-meeting: FESCO (2017-10-13) === Meeting started by maxamillion at 16:01:43 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2017-10-13/fesco.2017-10-13-16.01.log.html . Meeting summary --- * init process (maxamillion, 16:01:46) * Follow Ups (maxamillion, 16:04:23) * #1779 Consider fedora-* initscript units (maxamillion, 16:04:28) * LINK: https://pagure.io/fesco/issue/1779 (maxamillion, 16:04:28) * LINK: https://pagure.io/fork/zbyszek/fedora-release/c/c0dbaabb816ac181e79f07244dc461f4ef65d86d (nirik, 16:06:21) * AGREED: Proposal: Based on latest BZ update, ask if FESCo is still needed in the process and defer to next week if needed (+1:8, -1:0, +0:0) (maxamillion, 16:21:41) * #1780 F28 System Wide Change: Annobin (maxamillion, 16:21:48) * LINK: https://pagure.io/fesco/issue/1780 (maxamillion, 16:21:49) * LINK: https://pagure.io/releng/issue/7069 doesn'thave comments from releng yet either (bowlofeggs, 16:26:52) * AGREED: APPROVED: F28 System Wide Change: Annobin (+1:8, -1:0, +0:0) (maxamillion, 16:31:11) * New Business (maxamillion, 16:31:40) * #1767 F28 Self Contained Changes - Facter 3 (maxamillion, 16:31:42) * LINK: https://pagure.io/fesco/issue/1767#comment-471878 (maxamillion, 16:31:42) * LINK: https://docs.puppet.com/facter/3.0/release_notes.html " (jsmith, 16:33:31) * AGREED: Self Contained Changes - Facter 3 (+1:7, -1:0, +0:1) (maxamillion, 16:37:06) * #1775 f27 modular server release planning (maxamillion, 16:37:18) * LINK: https://pagure.io/fesco/issue/1775 (maxamillion, 16:37:18) * AGREED: : Add a presumed one-week slip to be the Rain Date; slip Final if that isn't achieved. (+1:8, -1:0, +0:0) (maxamillion, 16:43:24) * #1781 qt5-qtwebengine maintainership, kde-sig access rights (maxamillion, 16:43:36) * LINK: https://pagure.io/fesco/issue/1781 (maxamillion, 16:43:36) * AGREED: Proposal: We add KDE SIG as a comaintainer. In general, it will require 2 KDE SIG members to approve a Pull Request. In the event that Kevin still refuses, an additional 2 may overrule him. (+1:8, -1:0, +0:0) (maxamillion, 17:33:26) * #1782 use of updates-testing for testing of non-update software (maxamillion, 17:34:18) * LINK: https://pagure.io/fesco/issue/1782 (maxamillion, 17:34:19) * jforbes will create a Policy change proposal to be voted on next week (maxamillion, 17:41:53) * #1783 Firefox 57 and the Updates Policy (maxamillion, 17:42:42) * LINK: https://pagure.io/fesco/issue/1783 (maxamillion, 17:42:43) * AGREED: firefox 57beta is removed from f25/f26 updates-testing but stays in f27/rawhide. When final it out, maintainer is encouraged to allow extra time in f25/f26 for testing (+1:7, -1:0, +0:0) (maxamillion, 17:51:17) * Next Week's Chair (maxamillion, 17:51:58) * jforbes to chair next week's meeting (maxamillion, 17:53:04) * Open F
Re: Why is Fx 57 in Updates Testing?
On Fri, Oct 13, 2017 at 12:05 PM, Adam Williamson < adamw...@fedoraproject.org> wrote: > On Fri, 2017-10-13 at 12:58 -0400, Simo Sorce wrote: > > On Fri, 2017-10-13 at 09:43 -0700, Adam Williamson wrote: > > > On Fri, 2017-10-13 at 14:26 +, Zbigniew Jędrzejewski-Szmek wrote: > > > > On Fri, Oct 13, 2017 at 02:55:37PM +0100, Peter Oliver wrote: > > > > > On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > > > > > All the energy devoted to this thread would imho be better > > > > > > spent on > > > > > > trying to encourage the authors of popular extensions to update > > > > > > to the > > > > > > new model, > > > > > > > > > Adam not replying just to you but the general thread. > > What is the point of bringing up all these plugins breakage ? > > Zbigniew specifically asked for examples. > I posted this in the other thread, but will repost here: https://blog.mozilla.org/addons/2015/08/21/the-future-of- developing-firefox-add-ons/ https://blog.mozilla.org/addons/2017/02/16/the-road-to- firefox-57-compatibility-milestones/ https://arewewebextensionsyet.com/ The above are good links to familiarize yourself with what is going on with Fx. Yes, some extensions are not being ported... but many are. The nice thing now is that many chrome excellent chrome extensions will now be available to Fx users because they will be easier to modify, for example the excellent Checker Plus extensions for GMail, Google Calendar and Drive. Those are available NOW and have been for some time. Conversely developers are now interested in making some Fx extensions available for Chrome, for example DownloadThemAll People who are frustrated LastPass isn't yet a webextension (don't worry, LogMeIn willl meet the deadline) can also checkout Bitwarden... it's available now, and as a plus is GPLv3 - I've been using it for about a month and decided to switch from LastPass, because IMO it's better. People who are interested in SpeedDial, try out the excellent: New Tab Tools Those who want adblockers... there is uBlock Origin Those are just a few examples. This isn't Fx Apocalypse - it's an opportunity to discover a whole new world of extensions and enjoy a revived, multi-threaded much improved Fx. Yes, change is hard and people resist it. That is human nature - but as the saying goes... "The train is leaving the station... get onboard, or get left behind.'" Not trying to be confrontational or upset anybody, but that is the reality. Mozilla isn't going to go backward and change their strategy... ain't gonna happen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Modular bikeshed compose report: 20171013.n.0 changes
OLD: Fedora-Modular-Bikeshed-20171012.n.0 NEW: Fedora-Modular-Bikeshed-20171013.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 531.63 KiB Size of dropped packages:0.00 B Size of upgraded packages: 0.00 B Size of downgraded packages: 0.00 B Size change of upgraded packages: 0.00 B Size change of downgraded packages: 0.00 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: meson-0.43.0-1.module_a8503148 Summary: High productivity build system RPMs:meson Size:544392 bytes = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Modular 27 compose report: 20171013.n.0 changes
OLD: Fedora-Modular-27-20171012.n.0 NEW: Fedora-Modular-27-20171013.n.0 = SUMMARY = Added images:12 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 291 Downgraded packages: 21 Size of added packages: 0.00 B Size of dropped packages:0.00 B Size of upgraded packages: 3.56 GiB Size of downgraded packages: 1.31 GiB Size change of upgraded packages: 981.28 KiB Size change of downgraded packages: 61.54 KiB = ADDED IMAGES = Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Modular-Server-27_Modular-20171013.n.0.aarch64.raw.xz Image: Container_Minimal docker x86_64 Path: Server/x86_64/images/Fedora-Modular-Container-Minimal-27_Modular-20171013.n.0.x86_64.tar.xz Image: Container_Base docker ppc64le Path: Server/ppc64le/images/Fedora-Modular-Container-Base-27_Modular-20171013.n.0.ppc64le.tar.xz Image: Container_Minimal docker aarch64 Path: Server/aarch64/images/Fedora-Modular-Container-Minimal-27_Modular-20171013.n.0.aarch64.tar.xz Image: Server raw-xz ppc64le Path: Server/ppc64le/images/Fedora-Modular-Server-27_Modular-20171013.n.0.ppc64le.raw.xz Image: Container_Base docker aarch64 Path: Server/aarch64/images/Fedora-Modular-Container-Base-27_Modular-20171013.n.0.aarch64.tar.xz Image: Container_Minimal docker ppc64le Path: Server/ppc64le/images/Fedora-Modular-Container-Minimal-27_Modular-20171013.n.0.ppc64le.tar.xz Image: Container_Minimal docker armhfp Path: Server/armhfp/images/Fedora-Modular-Container-Minimal-27_Modular-20171013.n.0.armhfp.tar.xz Image: Server qcow2 ppc64le Path: Server/ppc64le/images/Fedora-Modular-Server-27_Modular-20171013.n.0.ppc64le.qcow2 Image: Server qcow2 aarch64 Path: Server/aarch64/images/Fedora-Modular-Server-27_Modular-20171013.n.0.aarch64.qcow2 Image: Container_Base docker x86_64 Path: Server/x86_64/images/Fedora-Modular-Container-Base-27_Modular-20171013.n.0.x86_64.tar.xz Image: Container_Base docker armhfp Path: Server/armhfp/images/Fedora-Modular-Container-Base-27_Modular-20171013.n.0.armhfp.tar.xz = DROPPED IMAGES = Image: Docker_Base docker x86_64 Path: Server/x86_64/images/Fedora-Modular-Docker-Base-27_Modular-20171012.n.0.x86_64.tar.xz = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: PyYAML-3.12-8.module_80d712e7 Old package: PyYAML-3.12-8.module_1d780a7b Summary: YAML parser and emitter for Python RPMs: python2-pyyaml python3-PyYAML Size: 2473624 bytes Size change: 64 bytes Package: acl-2.2.52-18.module_80d712e7 Old package: acl-2.2.52-18.module_6faa4f4e Summary: Access control list utilities RPMs: acl libacl libacl-devel Size: 1358204 bytes Size change: 3862 bytes Package: alsa-lib-1.1.4.1-3.module_80d712e7 Old package: alsa-lib-1.1.4.1-3.module_04d473e8 Summary: The Advanced Linux Sound Architecture (ALSA) library RPMs: alsa-lib alsa-lib-devel alsa-ucm Size: 10279996 bytes Size change: 1920 bytes Package: attr-2.4.47-21.module_80d712e7 Old package: attr-2.4.47-21.module_6faa4f4e Summary: Utilities for managing filesystem extended attributes RPMs: attr libattr libattr-devel Size: 888396 bytes Size change: 3310 bytes Package: audit-2.7.7-5.module_80d712e7 Old package: audit-2.7.7-5.module_6faa4f4e Summary: User space tools for 2.6 kernel auditing RPMs: audispd-plugins audispd-plugins-zos audit audit-libs audit-libs-devel audit-libs-python audit-libs-python3 audit-libs-static Size: 5620568 bytes Size change: 10364 bytes Package: augeas-1.8.1-1.module_80d712e7 Old package: augeas-1.8.1-1.module_04d473e8 Summary: A library for changing configuration files RPMs: augeas augeas-devel augeas-libs Size: 3155296 bytes Size change: 1840 bytes Package: b43-openfwwf-5.2-16.module_e79124d2 Old package: b43-openfwwf-5.2-16.module_b1e638e8 Summary: Open firmware for some Broadcom 43xx series WLAN chips RPMs: b43-openfwwf Size: 23280 bytes Size change: 8 bytes Package: babeltrace-1.5.3-1.module_80d712e7 Old package: babeltrace-1.5.3-1.module_6faa4f4e Summary: Trace Viewer and Converter, mainly for the Common Trace Format RPMs: babeltrace libbabeltrace libbabeltrace-devel python3-babeltrace Size: 2498704 bytes Size change: 3360 bytes Package: basesystem-11-4.module_80d712e7 Old package: basesystem-11-4.module_6faa4f4e Summary: The skeleton package which defines a simple Fedora system RPMs: basesystem Size: 9408 bytes Size change: 194 bytes Package: bash-4.4.12-10.module_80d712e7 Old package: bash-4.4.12-10.module_04d473e8 Summary: The GNU Bourne Again shell RPMs: bash bash-doc Size: 20441672 bytes Size change: 1516 bytes Package: bc-1.07.1-3.module_80d712e7 Old package: bc-1.07.1-3.module_04d473e8 Summary: GNU's bc (a nu
GCL and SELinux: help requested
On Sat, Oct 7, 2017 at 9:34 AM, Jerry James wrote: > I don't believe that anybody looks at those pull requests on a regular > basis. Should somebody be doing so? There are 8 pull requests, > dating back to about the time of the above conversation. Five of > those don't contain a single comment. > > I opened one for gcl on July 29, and added a comment a month later > asking if somebody was going to look at it. No response. This is a > bit annoying, considering that I opened a bugzilla request asking for > the same thing 4 years ago, and no action has ever been taken on it. > I thought maybe a PR would finally get something to happen. Nearly a week has gone by, and no answer. I'm really stumped about what to do. Let me summarize the whole long saga and solicit help. GCL is a Common Lisp implementation. It is known for its speed compared to other CL implementations. It has a long lineage, summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp. I took over maintenance of the package in late 2008 when the previous maintainer did not have time to continue. At that point, the package did not build in Rawhide and was slated to be dropped from Fedora soon. I got it working with help from upstream and Daniel Walsh, who provided advice on putting together an SELinux policy to account for the fact that GCL produces executable code on the fly by calling mprotect on selected pages. Fast forward to 2013. By that time, the GCL policy also had to mention maxima executables, since executables built with GCL also use the GCL memory allocator. I figured that meant it was time to merge the GCL policy into the system policy, and consequently opened a bugzilla ticket. In spite of me trying to reboot the conversation a couple of times, those involved who held the SELinux reins for Fedora, Just. Could. Not. Stay. On. Topic. We talked about the execheap permission in general, and its place in the universe. Some of them sneeringly, condescendingly wondered why upstream and I were both so incompetent that we didn't just rewrite the allocator to use mmap. (Hint: it isn't easy, and upstream isn't interested in the exercise.) After multiple failures on my part to get something to happen, I gave up in despair. Fast forward to 2017. Attempts to build maxima with gcl on aarch64 started hanging at package install time. See https://bugzilla.redhat.com/show_bug.cgi?id=1435395. This was blamed on gcl, incorrectly I believe. As I pointed out in the bug, nothing built from gcl sources runs at package install time, so the hang must be happening inside one of fixfiles, semodule, or restorecon, which ARE run from the gcl install scripts because GCL has to install its own SELinux policy, due to that policy not being merged into the system policy. So, policycoreutils maintainers! Something Is Afoot on aarch64! But that's not the end of the fun. GCL failed the mass rebuild this summer. It built successfully on every architecture but s390x. On s390x, the build failed due to a failed call to mprotect(), almost certainly a sign that SELinux was in enforcing mode on the builder. Was that a known issue with s390x builders? And, if so, has it been rectified since? If so, I'll try building again. I still want the system policy to account for GCL, in some way or another. But, as you can see from the quoted text above, submitting a pull request to the relevant git repository has resulted in months of . And pointing that out on this list last weekend has resulted in still more of the crickets. So ... what is a packager supposed to do Why is it so hard to get any attention for submissions to the system SELinux policy? There should be a barrier to entry; I understand that. But I can't even get the gatekeeper to have a conversation with me. Hellp!!! Frustratedly yours, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On Fri, Oct 13, 2017 at 03:07:05PM -0600, Jerry James wrote: > But that's not the end of the fun. GCL failed the mass rebuild this > summer. It built successfully on every architecture but s390x. On > s390x, the build failed due to a failed call to mprotect(), almost > certainly a sign that SELinux was in enforcing mode on the builder. > Was that a known issue with s390x builders? And, if so, has it been > rectified since? If so, I'll try building again. AIUI the builders run with SELinux disabled. Has this changed? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/13/2017 11:07 PM, Jerry James wrote: But that's not the end of the fun. GCL failed the mass rebuild this summer. It built successfully on every architecture but s390x. On s390x, the build failed due to a failed call to mprotect(), almost certainly a sign that SELinux was in enforcing mode on the builder. Was that a known issue with s390x builders? And, if so, has it been rectified since? If so, I'll try building again. s390x before z14 is a read-implies-exec architecture, so the mprotect calls are probably unnecessary there. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/13/2017 02:07 PM, Jerry James wrote: > On Sat, Oct 7, 2017 at 9:34 AM, Jerry James wrote: ...snip... > But that's not the end of the fun. GCL failed the mass rebuild this > summer. It built successfully on every architecture but s390x. On > s390x, the build failed due to a failed call to mprotect(), almost > certainly a sign that SELinux was in enforcing mode on the builder. > Was that a known issue with s390x builders? And, if so, has it been > rectified since? If so, I'll try building again. The default config for all our builders is selinux permissive. Mostly because we have never had enough cycles to track down any problems with making them enforcing. However, I just checked and the s390x builders _were_ in enforcing mode. ;( They are not installed like all the rest of our builders (via kickstarts), but via a install image the mainframe admins made for us. Sorry this wasn't noticed until now. ;( I've set them all in permissive and tweaked our ansible playbooks to make sure all of them stay that way. > I still want the system policy to account for GCL, in some way or > another. But, as you can see from the quoted text above, submitting a > pull request to the relevant git repository has resulted in months of > . And pointing that out on this list last weekend > has resulted in still more of the crickets. > > So ... what is a packager supposed to do Why is it so hard to get > any attention for submissions to the system SELinux policy? There > should be a barrier to entry; I understand that. But I can't even get > the gatekeeper to have a conversation with me. Hellp!!! > > Frustratedly yours, I don't know. Others have expressed frustration with selinux policy maintainers of late as well. It's really hard to say what the trouble is... are there to few of them? Overtasked with other work? Workflow too difficult? Perhaps we can get FESCO or someone to work with them and try and come up with a more open and working workflow. I'm not sure what the answer is here. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review swap
Easy python module, python-Mastodon: https://bugzilla.redhat.com/show_bug.cgi?id=1502072 I'll take one of yours in return if you like. Thanks all! -Gwyn -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On Fri, 2017-10-13 at 14:53 -0700, Kevin Fenzi wrote: > It's really hard to say what the trouble > is... are there to few of them? Overtasked with other work? Workflow too > difficult? AFAIK it's basically just lvrabec at the moment, and I think the 'map' permission issues that showed up this cycle may have been keeping him pretty busy. Not sure if there are other factors involved. It seems like there's sort of been an idea floating around for a while that we should be trying to move SELinux policies out of the centralized selinux-policy package - e.g. the Apache-relevant policies should move into the httpd package, and so on - but I don't know any details about how serious / achievable that idea is. It *is* possible for packages to ship their own SELinux policies now, though, and some (not many) do. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/13/2017 03:00 PM, Adam Williamson wrote: > On Fri, 2017-10-13 at 14:53 -0700, Kevin Fenzi wrote: >> It's really hard to say what the trouble >> is... are there to few of them? Overtasked with other work? Workflow too >> difficult? > > AFAIK it's basically just lvrabec at the moment, and I think the 'map' > permission issues that showed up this cycle may have been keeping him > pretty busy. Not sure if there are other factors involved. The workflow is pretty unclear too...at least to me. Like there are never any new releases anymore and just large patches against that release... rawhide has 3.13.1-295 ! and -rw-rw-r--. 1 kevin kevin 1685866 Oct 13 15:54 policy-rawhide-base.patch -rw-rw-r--. 1 kevin kevin 3664459 Oct 13 15:54 policy-rawhide-contrib.patch If you want to do a PR what do you do here? > It seems like there's sort of been an idea floating around for a while > that we should be trying to move SELinux policies out of the > centralized selinux-policy package - e.g. the Apache-relevant policies > should move into the httpd package, and so on - but I don't know any > details about how serious / achievable that idea is. It *is* possible > for packages to ship their own SELinux policies now, though, and some > (not many) do. Yeah, this idea is already true with epel now. It used to be RHEL selinux folks would add in policy for epel packages, but they now will not and require them to be in the package itself. At least they have said so in bugs, without much in the way of any formal announcement. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On Fri, 2017-10-13 at 15:58 -0700, Kevin Fenzi wrote: > On 10/13/2017 03:00 PM, Adam Williamson wrote: > > On Fri, 2017-10-13 at 14:53 -0700, Kevin Fenzi wrote: > > > It's really hard to say what the trouble > > > is... are there to few of them? Overtasked with other work? Workflow too > > > difficult? > > > > AFAIK it's basically just lvrabec at the moment, and I think the 'map' > > permission issues that showed up this cycle may have been keeping him > > pretty busy. Not sure if there are other factors involved. > > The workflow is pretty unclear too...at least to me. > > Like there are never any new releases anymore and just large patches > against that release... > > rawhide has 3.13.1-295 ! > and > -rw-rw-r--. 1 kevin kevin 1685866 Oct 13 15:54 policy-rawhide-base.patch > -rw-rw-r--. 1 kevin kevin 3664459 Oct 13 15:54 policy-rawhide-contrib.patch > > If you want to do a PR what do you do here? Yeah, I noticed that too and found it a bit weird, but wasn't sure whether to stick any oars in. Perhaps we could ask Lukas, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 14 Oct 2017 12:08 am, "Adam Williamson" wrote: On Fri, 2017-10-13 at 15:58 -0700, Kevin Fenzi wrote: > On 10/13/2017 03:00 PM, Adam Williamson wrote: > > On Fri, 2017-10-13 at 14:53 -0700, Kevin Fenzi wrote: > > > It's really hard to say what the trouble > > > is... are there to few of them? Overtasked with other work? Workflow too > > > difficult? > > > > AFAIK it's basically just lvrabec at the moment, and I think the 'map' > > permission issues that showed up this cycle may have been keeping him > > pretty busy. Not sure if there are other factors involved. > > The workflow is pretty unclear too...at least to me. > > Like there are never any new releases anymore and just large patches > against that release... > > rawhide has 3.13.1-295 ! > and > -rw-rw-r--. 1 kevin kevin 1685866 Oct 13 15:54 policy-rawhide-base.patch > -rw-rw-r--. 1 kevin kevin 3664459 Oct 13 15:54 policy-rawhide-contrib.patch > > If you want to do a PR what do you do here? Yeah, I noticed that too and found it a bit weird, but wasn't sure whether to stick any oars in. Perhaps we could ask Lukas, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org The few selinux policy changes I've needed in the past have been a pull request to the fedora policy on github and a bug filed in bugzilla linking to the PR ... Nothing more complex than that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] 2017-10-16 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2017-10-16 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's time for another meeting! Let's call this the Everyone Tell Adam What's Going On meeting, as I'm trying to catch up on return from vacation :) If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 27 status * Main release status * Server / Modularity status, process state 3. Test Day status 4. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Proposal to CANCEL: 2017-10-16 blocker review meeting
Hi folks! I'm proposing we cancel the blocker review meeting for Monday, as there are no proposed Final (or Server Beta) blockers. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)
Adam Williamson writes: > There are currently separate updates for nss 3.33.0 and nspr 4.17.0 in > both Fedora 26 and 27. However, nss 3.33.0 requires nspr 4.17.0. > > As a reminder, this is a violation of the Updates Policy: > > https://fedoraproject.org/wiki/Updates_Policy#Updating_inter-dependent_packages > > "When one updated package requires another (or more than one other), > the packages should be submitted together as a single update." > > The problem with doing things this way is that, if the nss update > happened to be pushed stable before the nspr update (which could easily > happen due to human error, network issues etc. even if the maintainer > *intends* to push them together!), the dependencies in the stable > repository will be broken; nss will not be installable. Thank you for the reminder; there was indeed a fuss in updating nspr/nss this time. I have submitted the nss updates for F27/F26 stable, after nspr 4.17 got pushed to stable. > On Fri, 2017-10-13 at 10:38 -0700, Josh Stone wrote: >> On 10/12/2017 05:34 PM, Adam Williamson wrote: >> > In this case there's an even worse consequence; if you do attempt to >> > update to nss 3.33.0 without nspr 4.17.0 dnf will 'skip' *most* of the >> > nss packages (as it notices that they are missing dependencies), but it >> > *will* install nss-softokn-freebl . With this mix of packages (most of >> > nss at 3.32.0, but nss-softokn-freebl at 3.33.0), nss and anything that >> > depends on it just fails to work at all - e.g. curl and dnf...so that's >> > an extremely bad outcome. >> >> Then isn't this a packaging bug? They currently use ">=" requirements, >> but if a greater version doesn't work, shouldn't they be "="? > > Well, there's *additionally* probably a packaging bug, yeah: nss- > softokn-freebl should be more strictly tied to the other packages. I still don't figure out why this causes a problem. nss-softokn-freebl is parallel installable with older nss* packages and that could run into a problem if nss-softokn-freebl used a new symbol from a newer nspr. However, as far as I know nspr 4.17 doesn't add any new symbol so it's shouldn't be a problem at least in this case. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)
On Sat, 2017-10-14 at 07:41 +0200, Daiki Ueno wrote: > Adam Williamson writes: > > > There are currently separate updates for nss 3.33.0 and nspr 4.17.0 in > > both Fedora 26 and 27. However, nss 3.33.0 requires nspr 4.17.0. > > > > As a reminder, this is a violation of the Updates Policy: > > > > https://fedoraproject.org/wiki/Updates_Policy#Updating_inter-dependent_packages > > > > "When one updated package requires another (or more than one other), > > the packages should be submitted together as a single update." > > > > The problem with doing things this way is that, if the nss update > > happened to be pushed stable before the nspr update (which could easily > > happen due to human error, network issues etc. even if the maintainer > > *intends* to push them together!), the dependencies in the stable > > repository will be broken; nss will not be installable. > > Thank you for the reminder; there was indeed a fuss in updating nspr/nss > this time. I have submitted the nss updates for F27/F26 stable, after > nspr 4.17 got pushed to stable. Thanks a lot. > > On Fri, 2017-10-13 at 10:38 -0700, Josh Stone wrote: > > > On 10/12/2017 05:34 PM, Adam Williamson wrote: > > > > In this case there's an even worse consequence; if you do attempt to > > > > update to nss 3.33.0 without nspr 4.17.0 dnf will 'skip' *most* of the > > > > nss packages (as it notices that they are missing dependencies), but it > > > > *will* install nss-softokn-freebl . With this mix of packages (most of > > > > nss at 3.32.0, but nss-softokn-freebl at 3.33.0), nss and anything that > > > > depends on it just fails to work at all - e.g. curl and dnf...so that's > > > > an extremely bad outcome. > > > > > > Then isn't this a packaging bug? They currently use ">=" requirements, > > > but if a greater version doesn't work, shouldn't they be "="? > > > > Well, there's *additionally* probably a packaging bug, yeah: nss- > > softokn-freebl should be more strictly tied to the other packages. > > I still don't figure out why this causes a problem. nss-softokn-freebl > is parallel installable with older nss* packages and that could run into > a problem if nss-softokn-freebl used a new symbol from a newer nspr. > However, as far as I know nspr 4.17 doesn't add any new symbol so it's > shouldn't be a problem at least in this case. I definitely observed the half-upgraded case causing problems, but didn't really prove that it was the nss-softokn-freebl causing the problem, I guess. I suppose it could equally well just have been a mismatch between NSS 3.32.0 and NSPR 4.17.0? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
