Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)

[Daiki Ueno]

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

[Test-Announce] Proposal to CANCEL: 2017-10-16 blocker review meeting

[Adam Williamson]

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

[Test-Announce] 2017-10-16 @ 15:00 UTC - Fedora QA Meeting

[Adam Williamson]

# 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

[389-devel] Build failed in Jenkins: NIGHTLY #108

[mareynol]

See 


--
[...truncated 54372 lines...]

# Create and extract a service keytab
args = {SER_HOST: self.host,
SER_PORT: self.port,
SER_SECURE_PORT: self.sslport,
SER_ROOT_DN: self.binddn,
SER_ROOT_PW: self.bindpw,
SER_CREATION_SUFFIX: self.creation_suffix,
SER_USER_ID: self.userid,
SER_SERVERID_PROP: self.serverid,
SER_GROUP_ID: self.groupid,
SER_DEPLOYED_DIR: self.prefix,
SER_BACKUP_INST_DIR: self.backupdir,
SER_STRICT_HOSTNAME_CHECKING: self.strict_hostname}

if self.inst_scripts is not None:
args[SER_INST_SCRIPTS_ENABLED] = self.inst_scripts

content = formatInfData(args)
result = DirSrvTools.runInfProg(prog, content, self.verbose,
prefix=self.prefix)
if result != 0:
>   raise Exception('\''Failed to run setup-ds.pl'\'')
E   Exception: Failed to run setup-ds.pl

../../../lib389/lib389/__init__.py:841: Exception
 Captured stdout setup -
Instance slapd-standalone1 removed.
OK group dirsrv exists
OK user dirsrv exists
=== FAILURES ===
_ test_slapd_InstScriptsEnabled[true] __

config_attr = '\''true'\''

@pytest.mark.parametrize("config_attr", ('\''true'\'', '\''false'\''))
def test_slapd_InstScriptsEnabled(config_attr):
"""Tests InstScriptsEnabled attribute with "True" and "False" options

:id: 02faac7f-c44d-4a3e-bf2d-1021e51da1ed

:setup: Standalone instance with slapd.InstScriptsEnabled option as 
"True" and "False"

:steps:
 1. Execute setup-ds.pl with slapd.InstScriptsEnabled option as 
"True".
 2. Check if /usr/lib64/dirsrv/slapd-instance instance script 
directory is created or not.
 3. Execute setup-ds.pl with slapd.InstScriptsEnabled option as 
"False".
 4. Check if /usr/lib64/dirsrv/slapd-instance instance script 
directory is created or not.

:expectedresults:
 1. Instance should be created.
 2. /usr/lib64/dirsrv/slapd-instance instance script directory 
should be created.
 3. Instance should be created.
 4. /usr/lib64/dirsrv/slapd-instance instance script directory 
should not be created.
"""

log.info('\''set SER_INST_SCRIPTS_ENABLED to {}'\''.format(config_attr))
>   standalone = create_instance(config_attr)

suites/setup_ds/setup_ds_test.py:62: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
suites/setup_ds/setup_ds_test.py:35: in create_instance
standalone.create()
../../../lib389/lib389/__init__.py:936: in create
self._createDirsrv()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 

def _createDirsrv(self):
"""Create a new instance of directory server

@param self - containing the set properties

SER_HOST(host)
SER_PORT(port)
SER_SECURE_PORT (sslport)
SER_ROOT_DN (binddn)
SER_ROOT_PW (bindpw)
SER_CREATION_SUFFIX (creation_suffix)
SER_USER_ID (userid)
SER_SERVERID_PROP   (serverid)
SER_GROUP_ID(groupid)
SER_DEPLOYED_DIR(prefix)
SER_BACKUP_INST_DIR (backupdir)
SER_REALM   (krb5_realm)

@return None

@raise None

}
"""

DirSrvTools.lib389User(user=DEFAULT_USER)
prog = os.path.join(self.ds_paths.sbin_dir, CMD_PATH_SETUP_DS)

if not os.path.isfile(prog):
log.error("Can'\''t find file: %r, removing extension" % prog)
prog = prog[:-3]

# Create and extract a service keytab
args = {SER_HOST: self.host,
SER_PORT: self.port,
SER_SECURE_PORT: self.sslport,
SER_ROOT_DN: self.binddn,
SER_ROOT_PW: self.bindpw,
SER_CREATION_SUFFIX: self.creation_suffix,
SER_USER_ID: self.userid,
SER_SERVERID_PROP: self.serverid,
SER_GROUP_ID: self.groupid,
SER_DEPLOYED_DIR: self.prefix,
SER_BACKUP_INST_DIR: self.backupdir,
SER_STRICT_HOSTNAME_CHECKING: self.strict_hostname}

if self.inst_scripts is not None:
args[SER_INST_SCRIPTS_ENABLED] = self.inst_scripts

  

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 950  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 712  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 294  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 192  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 189  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7ecb12e378   
python-XStatic-jquery-ui-1.12.0.1-1.el7
  24  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-52b8147c68   
openvpn-auth-ldap-2.0.3-15.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4826761f5d   
openvpn-2.4.4-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-abe6f98ebf   
tor-0.2.9.12-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0f92580f68   
yadifa-2.2.6-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-17b77b3268   
botan-1.10.17-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3c06a7eecf   
nagios-4.3.4-3.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-9e6a789af9   
check-mk-1.2.8p26-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-853d71e01b   
tnef-1.4.15-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

borgbackup-1.1.0-1.el7
getmail-5.4-1.el7
golang-github-hashicorp-go-plugin-0-0.1.20171028git3e6d191.el7
gridsite-2.3.4-1.el7
phoronix-test-suite-7.4.0-1.el7
python-openqa_client-1.3.1-1.el7
python-wikitcms-2.1.12-1.el7

Details about builds:



 borgbackup-1.1.0-1.el7 (FEDORA-EPEL-2017-f2d9488b45)
 A deduplicating backup program with compression and authenticated encryption

Update Information:

upstream version 1.1.0 (BZ#1499512)

References:

  [ 1 ] Bug #1499512 - borgbackup 1.1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1499512
  [ 2 ] Bug #1493434 - Missing fuse dependency for borgbackup package
https://bugzilla.redhat.com/show_bug.cgi?id=1493434




 getmail-5.4-1.el7 (FEDORA-EPEL-2017-02d50ac26f)
 POP3, IMAP4 and SDPS mail retriever with Maildir delivery

Update Information:

update to 5.4




 golang-github-hashicorp-go-plugin-0-0.1.20171028git3e6d191.el7 
(FEDORA-EPEL-2017-953e73772b)
 Golang plugin system over RPC

Update Information:

First package for Fedora

References:

  [ 1 ] Bug #1501007 - Review Request: golang-github-hashicorp-go-plugin - 
Golang plugin system over RPC
https://bugzilla.redhat.com/show_bug.cgi?id=1501007




 gridsite-2.3.4-1.el7 (FEDORA-EPEL-2017-715a4a628b)
 Grid Security for the Web, Web platforms for Grids

Update Information:

Fixed missing environment variables and out-of-bound array access




 phoronix-test-suite-7.4.0-1.el7 (FEDORA-EPEL-2017-c285a77c39)
 An Automated, Open-Source Testing Framework

Update Information:

update to 7.4.0




 python-openqa_client-1.3.1-1.el7 (FEDORA-EPEL-2017-2841bdf674)
 Python client library for openQA API

Update Information:

This update provides the latest release of the library, which updates the job
state definitions in the `const` module to match the latest upstream openQA
code. Note the openQA currently packaged for Fedora does not yet include 

Re: GCL and SELinux: help requested

[James Hogarth]

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

Re: GCL and SELinux: help requested

[Adam Williamson]

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

[Kevin Fenzi]

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

[Adam Williamson]

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

Review swap

[Gwyn Ciesla]

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

[Kevin Fenzi]

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

Re: GCL and SELinux: help requested

[Florian Weimer]

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

[Richard W.M. Jones]

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

[Bug 1492094] CVE-2017-12837 CVE-2017-12883 perl: various flaws [ fedora-all]

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1492094



--- Comment #13 from Fedora Update System  ---
perl-5.24.3-389.fc25 has been pushed to the Fedora 25 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1492093] CVE-2017-12883 perl: Buffer over-read in regular expression parser

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1492093



--- Comment #7 from Fedora Update System  ---
perl-5.24.3-389.fc25 has been pushed to the Fedora 25 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1492091] CVE-2017-12837 perl: Heap buffer overflow in regular expression compiler

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1492091



--- Comment #7 from Fedora Update System  ---
perl-5.24.3-389.fc25 has been pushed to the Fedora 25 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

GCL and SELinux: help requested

[Jerry James]

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

Fedora Modular 27 compose report: 20171013.n.0 changes

[Fedora Branched Report]

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 numeric

Fedora Modular bikeshed compose report: 20171013.n.0 changes

[Fedora Rawhide Report]

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

Re: Why is Fx 57 in Updates Testing?

[Gerald B. Cox]

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

Summary/Minutes from today's FESCo Meeting (2017-10-13)

[Adam Miller]

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  

Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)

[Adam Williamson]

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

Re: Why is Fx 57 in Updates Testing?

[Adam Williamson]

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

Fedora 27-20171013.n.0 compose check report

[Fedora compose checker]

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: 

Fedora Rawhide-20171013.n.0 compose check report

[Fedora compose checker]

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: 

Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)

[Josh Stone]

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

Re: Why is Fx 57 in Updates Testing?

[nicolas . mailhot]

> 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: Why is Fx 57 in Updates Testing?

[Alessio Ciregia]

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?

[Simo Sorce]

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?

[Adam Williamson]

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?

[Robert-André Mauchin]

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: what openQA packages versions on openqa.stg.fedoraproject.org

[Adam Williamson]

On Fri, 2017-10-13 at 18:09 +0200, Normand wrote:
> Hello Adam,
> 
> What are the currently running openQA rpm versions on 
> openqa.stg.fedoraproject.org ?
> 
> I saw in (1) that this version is sorting the successive runs with most 
> recents on top, which is an option I like.
> 
> But we do not have such behaviour on our openQA server running f26 
> fedora with following openQA versions:
> ===
> $rpm -qa |grep -i openqa |sort
> openqa-4.4-49.20170409gitfead7af.fc26.noarch
> openqa-client-4.4-49.20170409gitfead7af.fc26.noarch
> openqa-common-4.4-49.20170409gitfead7af.fc26.noarch
> openqa-httpd-4.4-49.20170409gitfead7af.fc26.noarch
> openqa-plugin-fedmsg-4.4-49.20170409gitfead7af.fc26.noarch
> openqa-worker-4.4-49.20170409gitfead7af.fc26.noarch
> ===
> 
> (1) https://openqa.stg.fedoraproject.org/group_overview/3

This is actually configurable. Go to the Job Groups page from the admin
menu, click on a group, click Edit Job Group Properties, and select
"Sort by time job most recently created".

I actually implemented this :P
https://github.com/os-autoinst/openQA/pull/1243

The version running on both prod and stg at present is 4.4-64, btw. But
this feature should be in -49 I think, it was merged on March 7. The
new scheduler was implemented since -49 which has been causing various
problems, but it's *mostly* working okay now I think...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Adam Williamson]

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

what openQA packages versions on openqa.stg.fedoraproject.org

[Normand]

Hello Adam,

What are the currently running openQA rpm versions on 
openqa.stg.fedoraproject.org ?


I saw in (1) that this version is sorting the successive runs with most 
recents on top, which is an option I like.


But we do not have such behaviour on our openQA server running f26 
fedora with following openQA versions:

===
$rpm -qa |grep -i openqa |sort
openqa-4.4-49.20170409gitfead7af.fc26.noarch
openqa-client-4.4-49.20170409gitfead7af.fc26.noarch
openqa-common-4.4-49.20170409gitfead7af.fc26.noarch
openqa-httpd-4.4-49.20170409gitfead7af.fc26.noarch
openqa-plugin-fedmsg-4.4-49.20170409gitfead7af.fc26.noarch
openqa-worker-4.4-49.20170409gitfead7af.fc26.noarch
===

(1) https://openqa.stg.fedoraproject.org/group_overview/3

--
Michel Normand
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)

[Matthew Miller]

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?

[Tom Hughes]

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: Why is Fx 57 in Updates Testing?

[Adam Williamson]

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?

[Adam Williamson]

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?

[Adam Williamson]

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?

[Michael Cronenworth]

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?

[Gerald B. Cox]

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?

[Adam Williamson]

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?

[Alexander Ploumistos]

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?

[Gerald B. Cox]

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: Broken dependencies: audacity

[Todd Zullinger]

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?

[Alexander Ploumistos]

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]

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?

[Athos Ribeiro]

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: Fx 57 Release Issues

[Gerald B. Cox]

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?

[Tom Hughes]

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

Fx 57 Release Issues

[Gerald B. Cox]

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

[389-devel] Build failed in Jenkins: COMMIT_SANITY_TEST #70

[mareynol]

See 


Changes:

[spichugi] Issue 49381 - Refactor filter test suite docstrings

--
[...truncated 1537 lines...]
D   man/man8/saveconfig.8
D   man/man8/schema-reload.pl.8
D   man/man8/setup-ds.pl.8
D   man/man8/start-dirsrv.8
D   man/man8/status-dirsrv.8
D   man/man8/stop-dirsrv.8
D   man/man8/suffix2instance.8
D   man/man8/syntax-validate.pl.8
D   man/man8/upgradedb.8
D   man/man8/upgradednformat.8
D   man/man8/usn-tombstone-cleanup.pl.8
D   man/man8/verify-db.pl.8
D   man/man8/vlvindex.8
D   rfcs/Makefile
D   rfcs/examples/template-bare-06.txt
D   rfcs/src/draft-wibrown-ldapssotoken-00.xml
D   rpm.mk
D   rpm/389-ds-base-devel.README
D   rpm/389-ds-base-git.sh
D   rpm/add_patches.sh
D   rpm/rpmverrel.sh
D   setup.py.in
D   src/contrib/README.md
D   src/contrib/back-ldif/add.c
D   src/contrib/back-ldif/back-ldif.h
D   src/contrib/back-ldif/bind.c
D   src/contrib/back-ldif/close.c
D   src/contrib/back-ldif/compare.c
D   src/contrib/back-ldif/config.c
D   src/contrib/back-ldif/delete.c
D   src/contrib/back-ldif/init.c
D   src/contrib/back-ldif/modify.c
D   src/contrib/back-ldif/modrdn.c
D   src/contrib/back-ldif/monitor.c
D   src/contrib/back-ldif/search.c
D   src/contrib/back-ldif/start.c
D   src/contrib/back-ldif/unbind.c
D   src/libsds/README.md
D   src/libsds/external/csiphash/csiphash.c
D   src/libsds/external/liblfds711/build/gcc_gnumake_kbuild/Kbuild
D   src/libsds/external/liblfds711/build/msvc_gnumake/liblfds711.def
D   src/libsds/external/liblfds711/build/msvc_gnumake/makefile
D   src/libsds/external/liblfds711/build/wdk_7.1/dirs
D   
src/libsds/external/liblfds711/build/wdk_7.1/driver_entry_renamed_to_avoid_compiler_warning.c
D   src/libsds/external/liblfds711/build/wdk_7.1/liblfds711.def
D   
src/libsds/external/liblfds711/build/wdk_7.1/readme_before_win_kernel_build.txt
D   
src/libsds/external/liblfds711/build/wdk_7.1/runme_before_win_kernel_dynamic_lib_build.bat
D   
src/libsds/external/liblfds711/build/wdk_7.1/runme_before_win_kernel_static_lib_build.bat
D   src/libsds/external/liblfds711/build/wdk_7.1/sources.dynamic
D   src/libsds/external/liblfds711/build/wdk_7.1/sources.static
D   src/libsds/external/liblfds711/inc/liblfds711.h
D   
src/libsds/external/liblfds711/inc/liblfds711/lfds711_btree_addonly_unbalanced.h
D   src/libsds/external/liblfds711/inc/liblfds711/lfds711_freelist.h
D   src/libsds/external/liblfds711/inc/liblfds711/lfds711_hash_addonly.h
D   
src/libsds/external/liblfds711/inc/liblfds711/lfds711_list_addonly_singlylinked_ordered.h
D   
src/libsds/external/liblfds711/inc/liblfds711/lfds711_list_addonly_singlylinked_unordered.h
D   src/libsds/external/liblfds711/inc/liblfds711/lfds711_misc.h
D   
src/libsds/external/liblfds711/inc/liblfds711/lfds711_porting_abstraction_layer_compiler.h
D   
src/libsds/external/liblfds711/inc/liblfds711/lfds711_porting_abstraction_layer_operating_system.h
D   
src/libsds/external/liblfds711/inc/liblfds711/lfds711_porting_abstraction_layer_processor.h
D   src/libsds/external/liblfds711/inc/liblfds711/lfds711_prng.h
D   
src/libsds/external/liblfds711/inc/liblfds711/lfds711_queue_bounded_manyproducer_manyconsumer.h
D   
src/libsds/external/liblfds711/inc/liblfds711/lfds711_queue_bounded_singleproducer_singleconsumer.h
D   
src/libsds/external/liblfds711/inc/liblfds711/lfds711_queue_unbounded_manyproducer_manyconsumer.h
D   src/libsds/external/liblfds711/inc/liblfds711/lfds711_ringbuffer.h
D   src/libsds/external/liblfds711/inc/liblfds711/lfds711_stack.h
D   
src/libsds/external/liblfds711/src/lfds711_btree_addonly_unbalanced/lfds711_btree_addonly_unbalanced_cleanup.c
D   
src/libsds/external/liblfds711/src/lfds711_btree_addonly_unbalanced/lfds711_btree_addonly_unbalanced_get.c
D   
src/libsds/external/liblfds711/src/lfds711_btree_addonly_unbalanced/lfds711_btree_addonly_unbalanced_init.c
D   
src/libsds/external/liblfds711/src/lfds711_btree_addonly_unbalanced/lfds711_btree_addonly_unbalanced_insert.c
D   
src/libsds/external/liblfds711/src/lfds711_btree_addonly_unbalanced/lfds711_btree_addonly_unbalanced_internal.h
D   
src/libsds/external/liblfds711/src/lfds711_btree_addonly_unbalanced/lfds711_btree_addonly_unbalanced_query.c
D   
src/libsds/external/liblfds711/src/lfds711_freelist/lfds711_freelist_cleanup.c
D   
src/libsds/external/liblfds711/src/lfds711_freelist/lfds711_freelist_init.c
D   
src/libsds/external/liblfds711/src/lfds711_freelist/lfds711_freelist_internal.h
D   
src/libsds/external/liblfds711/src/lfds711_freelist/lfds711_freelist_pop.c
D   

Re: Why is Fx 57 in Updates Testing?

[Zbigniew Jędrzejewski-Szmek]

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

Re: Broken dependencies: audacity

[Todd Zullinger]

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?

[Peter Oliver]

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

[Bug 1501400] perl-Parse-Gitignore-0.04 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1501400

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Parse-Gitignore-0.04-1
   ||.fc28
 Resolution|--- |RAWHIDE
   Assignee|de...@fateyev.com   |jples...@redhat.com
Last Closed||2017-10-13 09:22:56



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Zbigniew Jędrzejewski-Szmek]

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?

[Martin Stransky]

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

[389-devel] Build failed in Jenkins: COMMIT_SANITY_TEST #69

[mareynol]

TY_TEST/ws/source/389-ds-base/rpmbuild/BUILDROOT/389-ds-base-1.4.0.1-20171013gitdf4492b.fc25.x86_64/usr/share/doc/python3-389-ds-base-tests>
+ export DOCDIR
+ /usr/bin/mkdir -p 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/BUILDROOT/389-ds-base-1.4.0.1-20171013gitdf4492b.fc25.x86_64/usr/share/doc/python3-389-ds-base-tests>
+ cp -pr LICENSE 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/BUILDROOT/389-ds-base-1.4.0.1-20171013gitdf4492b.fc25.x86_64/usr/share/doc/python3-389-ds-base-tests>
+ cp -pr LICENSE.GPLv3+ 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/BUILDROOT/389-ds-base-1.4.0.1-20171013gitdf4492b.fc25.x86_64/usr/share/doc/python3-389-ds-base-tests>
+ exit 0
Provides: python3-389-ds-base-tests = 1.4.0.1-20171013gitdf4492b.fc25 
python3.5dist(dirsrvtests) = 1.4.0.1 python3dist(dirsrvtests) = 1.4.0.1
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 
4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: python(abi) = 3.5
Processing files: 389-ds-base-debuginfo-1.4.0.1-20171013gitdf4492b.fc25.x86_64
Provides: 389-ds-base-debuginfo = 1.4.0.1-20171013gitdf4492b.fc25 
389-ds-base-debuginfo(x86-64) = 1.4.0.1-20171013gitdf4492b.fc25
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 
4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/BUILDROOT/389-ds-base-1.4.0.1-20171013gitdf4492b.fc25.x86_64>
Wrote: 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/SRPMS/389-ds-base-1.4.0.1-20171013gitdf4492b.fc25.src.rpm>
Wrote: 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/RPMS/x86_64/389-ds-base-1.4.0.1-20171013gitdf4492b.fc25.x86_64.rpm>
Wrote: 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/RPMS/x86_64/389-ds-base-libs-1.4.0.1-20171013gitdf4492b.fc25.x86_64.rpm>
Wrote: 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/RPMS/x86_64/389-ds-base-devel-1.4.0.1-20171013gitdf4492b.fc25.x86_64.rpm>
Wrote: 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/RPMS/x86_64/389-ds-base-snmp-1.4.0.1-20171013gitdf4492b.fc25.x86_64.rpm>
Wrote: 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/RPMS/noarch/python3-lib389-1.4.0.1-20171013gitdf4492b.fc25.noarch.rpm>
Wrote: 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/RPMS/noarch/python3-389-ds-base-tests-1.4.0.1-20171013gitdf4492b.fc25.noarch.rpm>
Wrote: 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/RPMS/x86_64/389-ds-base-debuginfo-1.4.0.1-20171013gitdf4492b.fc25.x86_64.rpm>
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.YzXiNP
+ umask 022
+ cd 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/BUILD>
+ cd 389-ds-base-1.4.0.1.20171013gitdf4492b
+ rm -rf 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/BUILDROOT/389-ds-base-1.4.0.1-20171013gitdf4492b.fc25.x86_64>
+ exit 0
cp 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/RPMS/*/389-ds-base-1.4.0.1-20171013gitdf4492b*.rpm>
 dist/rpms/
cp 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/RPMS/*/389-ds-base-*-1.4.0.1*.rpm>
 dist/rpms/
cp 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild/SRPMS/389-ds-base-1.4.0.1-20171013gitdf4492b*.src.rpm>
 dist/srpms/
rm -rf 
<http://vm-166.abc.idm.lab.eng.brq.redhat.com:8080/job/COMMIT_SANITY_TEST/ws/source/389-ds-base/rpmbuild>
+ cd dist/rpms/
+ sudo rpm -iUvh 389-ds-base-1.4.0.1-20171013gitdf4492b.fc25.x86_64.rpm 
389-ds-base-libs-1.4.0.1-20171013gitdf4492b.fc25.x86_64.rpm 
389-ds-base-debuginfo-1.4.0.1-20171013gitdf4492b.fc25.x86_64.rpm 
389-ds-base-devel-1.4.0.1-20171013gitdf4492b.fc25.x86_64.rpm 
389-ds-base-snmp-1.4.0.1-20171013gitdf4492b.fc25.x86_64.rpm
Preparing...  ####
Updating / installing...
389-ds-base-libs-1.4.0.1-20171013gitdf
389-ds-base-1.4.0.1-20171013gitdf4492b
389-ds-base-snmp-1.4.0.1-20171013gitd

Re: Why is Fx 57 in Updates Testing?

[Naheem Zaffar]

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?

[Peter Oliver]

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

[389-devel] Re: csiphash on Sparc

[William Brown]

On Wed, 2017-10-11 at 13:36 +0200, Lukas Slebodnik wrote:
> On (11/10/17 12:42), Carsten Grzemba wrote:
> >
> 
> >
> 
> >On 11.10.17 10:54, William Brown   wrote: 
> 
> >> 
> 
> >> On Tue, 2017-10-10 at 16:28 +0200, Carsten Grzemba wrote:
> 
> >> > 
> 
> >> > On 10.10.17 16:10, William Brown  wrote: 
> 
> >> > > 
> 
> >> > > On Fri, 2017-10-06 at 10:21 +0200, Carsten Grzemba wrote:
> 
> >> > > > Currently the code src/libsds/external/csiphash/csiphash.c do not 
> >> > > > work on Sparc. 
> 
> >> > > > The casting void* or char* to unit64_t* throws Bus-Error.
> 
> >> > > > 
> 
> >> > > > The solution would be to copy the content of the void and char 
> >> > > > pointer so that the variabeles are suitably aligned.
> 
> >> > > > To prevent have to use malloc: do we know the max of src_sz?
> 
> >> > > > 
> 
> >> > > 
> 
> >> > > 
> 
> >> > > What line is this? I assume you are refering to:
> 
> >> > > 
> 
> >> > > https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82
> 
> >> > > 
> 
> >> > yes!
> 
> >> > 
> 
> >> > > 
> 
> >> > > (https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82)
> 
> >> > > 
> 
> >> > > No, we can't know the max of src_sz, in theory it could be uint64_t 
> >> > > max.
> 
> >> > > So this may not be an option.
> 
> >> > > 
> 
> >> > So is malloc for uint64 alignment of the src variable the only option?
> 
> >> > 
> 
> >> > > 
> 
> >> > > 
> 
> >> > > 
> 
> >> > > Are you trying this on a 32bit platform perhaps? What's the arch of the
> 
> >> > > machine with the issue?
> 
> >> > > 
> 
> >> > 64bit, Fujitsu M4000
> 
> >> > $ isainfo -v
> 
> >> > 64-bit sparcv9 applications
> 
> >> > fmaf vis2 vis popc 
> 
> >> 
> 
> >> I feel like there is something I'm missing here in the problem. What is
> 
> >> sizeof(void *) on this platform? I'm assuming 4 or 16 rather than 8
> 
> >> bytes? Is this correct? 
> 
> >> 
> 
> >no it is 8.
> 
> >
> 
> >The following programm works on x86 but dumps on Sparc:
> 
> >
> 
> >
> 
> >
> 
> >#include 
> 
> >#include 
> 
> >
> 
> >int func(const void *str, size_t sz, const char key[16]){
> 
> > uint64_t *ip = (uint64_t*) str;
> 
> > printf ("str: %lx:%lx\n", ip, *ip);
> 
> >}
> 
> >
> 
> >int main()
> 
> >{
> 
> > char str[25] = "ABCDEFGH12345678";
> 
> > char key[16];
> 
> >
> 
> But following code should work. Please correct me if I am wrong. I didn't 
> test.
>   char *str = strdup("ABCDEFGH12345678");
>   char *key = malloc(16);
> 
> yes, function sds_siphash13 is not ideal because it rely on properly alligned
> input data.
> 

We are free to change the signature of the function, it's just that I
used this from another open source component (thus why it's slightly
different style wise)

What would you suggest here Lukas? 


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)

[Adam Williamson]

On Fri, 2017-10-13 at 08:16 +0200, Igor Gnatenko wrote:
> On Thu, 2017-10-12 at 17:34 -0700, Adam Williamson wrote:
> > 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-dependen
> > t_packages
> > 
> > "When one updated package requires another (or more than one other),
> > the packages should be submitted together as a single update."
> 
> The problem I face myself is when update requires new packages. And in
> that case what kind of "type" should I choose? enhancement or
> newpackage?

That's far less important. Especially the distinction between
enhancement and newpackage, I think, barely matters.
-- 
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

[Bug 1501402] perl-Perl-Critic-Pulp-95 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1501402



--- Comment #4 from Fedora Update System  ---
perl-Perl-Critic-Pulp-95-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-5e7aff6b97

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1501270] perl-Digest-SHA-5.98 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1501270



--- Comment #6 from Fedora Update System  ---
perl-Digest-SHA-5.98-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-8845168e95

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1501310] perl-Eval-WithLexicals-1.003006 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1501310

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Eval-WithLexicals-1.003006-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-ef1707a038

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1501363] perl-local-lib-2.000024 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1501363

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-local-lib-2.24-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-f9663fe50f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1501321] perl-Gearman-2.004.009 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1501321

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Gearman-2.004.009-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-d6621a14b6

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1500804] perl-Net-IPv6Addr-0.91 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1500804

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Net-IPv6Addr-0.91-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-24e6d084f5

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1500805] perl-MP3-Info-1.26 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1500805

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-MP3-Info-1.26-1.fc27 has been pushed to the Fedora 27 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-b21af0f328

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1500438] perl-Code-TidyAll-0.69 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1500438

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Code-TidyAll-0.69-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-7550e1e1c0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2017-10-12 at 17:34 -0700, Adam Williamson wrote:
> 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-dependen
> t_packages
> 
> "When one updated package requires another (or more than one other),
> the packages should be submitted together as a single update."
The problem I face myself is when update requires new packages. And in
that case what kind of "type" should I choose? enhancement or
newpackage?
> 
> 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.
> 
> 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.
> 
> If both packages are in a single update, we cannot run into this
> problem; either both packages get pushed stable or neither does. That
> is why updates to interdependent packages should *always* be grouped
> together. Please remember this, package maintainers. Thanks!
> 
> (note: this issue was caught by openQA, which tests individual
> updates
> from updates-testing, rather than enabling the repository wholesale,
> so
> it catches things like this.)
> -- 
> 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

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlngWlkACgkQaVcUvRu8
X0yx+RAAqecZPJyN1NrGnFwvT8WmRxTed4oP0dsfzz7mdvuuQKDcJClx7y4BxfP7
rQYy4xQwa7rbLRPMd86mnS69VQ+fm1cQp0VzunAqnCAI4+4Ra1BrTmDo+lp8rq9x
W0qxQuK+rbUxPv8P45w8HxZQNLT/xUtgEnPTG5eZBHzBmB05iIxS9Um8gvcoSkgQ
x7hm5f6qGIGsQO7QoG8YguLl9Me/6CWnza3ucBkUSVAQlgkJn3J3lKHP5cMSsfEz
Y1toLL5zsCHrngiJNq38DBzTTarpryzsWYpen2Z95FOnQ3/8LqxaEukSe2PTp5Ka
IYuAUnayRlR2l3JXFmSYNm7s+nKKRt+Uls37YvrZQEfoxDFoGZOl36WT8vEHwBQd
BByeG1n61V0Xu5DlgdVPIFRvFcw/tP8D8BY46nfvCLMBeYozDew9WOWr8ZGFhk/L
yfVufslG7w/d37e10ORWezyxVJDc6GtoXzkwcPJVIYCk8+ShfRZxsbtWnFbOPNy7
mmqqRpPEJLoNPN6YWhmFjdgXZPVNd2viIGf4ww5XRlO0LX6h7bRCHpj2h22fEM7o
fKAR6lu5uVJUcgRxOfGKHH67qcZby9mgpEtrbqaOTc+4pMHIcvrIZ4MdUQxsU8Hu
lR/4KoFGwb+QQF1CE62Jzl4759nGaoWMKXLepHK8VwRZZAufOOE=
=SZdk
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org