[Test-Announce] 2019-01-07 @ 16:00 UTC - Fedora QA Meeting

2019-01-04 Thread Adam Williamson 
# Fedora Quality Assurance Meeting
# Date: 2019-01-07
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

Again I don't have anything critical for the agenda, but we didn't
meet since before the holidays, so let's do a quick check-in.

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 30 status
3. Test Day / community event 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F30 System-Wide Change proposal: Switch cryptsetup default metadata format to LUKS2

2019-01-04 Thread Ben Cotton 
https://fedoraproject.org/wiki/Changes/SwitchCryptsetupDefaultToLUKS2

== Summary ==
The change switches Fedora system default metadata format for full
disk encryption from LUKS1 to LUKS2. It mostly involves cryptsetup
package and Anaconda installer so that both creates new LUKS2
containers by default.

== Owner ==
* Name: [[User:Okozina| Ondřej Kozina]] and [[User:Vponcova | Vendula Poncova]]
* Email: okozina AT redhat DOT com, vponcova AT redhat DOT com

== Detailed Description ==

The LUKS2 is evolution of current LUKS standard for software full disk
encryption. It's enabler for new features: introduces new Argon2 kdf
(alongside current PBKDF2) for keyslots, better support for
auto-activation, support for wrapped key ciphers (paes cipher),
experimental authenticated encryption. Plus coming new features
(online-reencryption).

The LUKS2 format is available and supported since cryptsetup release
2.0.0 (included in Fedora 28).

== Scope ==
* Proposal owners:

Ensure LUKS2 is declared default in upstream (owner is involved in
upstream development). Currently upstream aims for LUKS2 being default
in cryptsetup-2.1 (next release). We can switch it even before
cryptsetup 2.1 release by overriding the default via configuration
switch, but owner would prefer upstream default way.

* Other developers:
Installer (Anaconda & co) should adapt to the change (and create new
LUKS2 containers by default if user selects "encrypted storage" during
installation).

* Release engineering: [https://pagure.io/releng/issue/8028 #8028]
** List of deliverables: N/A
* Policies and guidelines:
* Trademark approval: N/A


== Upgrade/compatibility impact ==

There should be none with regard to currently supported Fedora
distributions. Both Fedora 28 and 29 provides cryptsetup-2.0.6 (at
least via updates streams) that is fully compatible with LUKS2 format.
LUKS1 stays to be fully supported even with LUKS2 being new default.

== How To Test ==

Basically there will be two areas to test:

* cryptsetup luksFormat command creates LUKS2 devices by default
*  Anaconda installs on LUKS2 devices by default when users selects
"encrypted storage" option.

In general this test plan should not cover bugs related to LUKS2
format itself. Those bugs should be covered by development testsuite
shipped with cryptsetup package.


== User Experience ==
The everyday experience should not be affected by the change in any
way. The basic LUKS2 operations (open, close, add new keyslots, remove
keyslot) is handled via same CLI.

More experienced users gain access to new features with default
installation as stated in detailed description.

== Dependencies ==
Currently only Anaconda installer. It would be inconvenient to install
Fedora (encrypted storage) using different LUKS format by default if
cryptsetup used LUKS2. The contact person is listed among Owners of
this change.

== Contingency Plan ==
* Contingency mechanism: Stay with LUKS1 format as default
* Contingency deadline: Beta freeze
* Blocks release? No
* Blocks product? N/A

= Documentation ==
[https://gitlab.com/cryptsetup/LUKS2-docs/blob/master/luks2_doc_wip.pdf
LUKS2 specification document]



-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Installation image layout

2019-01-04 Thread Georg Sauthoff 
On Sun, Oct 14, 2018 at 04:35:53PM -0600, Chris Murphy wrote:
[..]
> Ha! I just realized after all this time that the Btrfs wiki does not
> make clear how to make a sprout, even though it mentions the more
> esoteric recursive seed.[1] Of course you can mkfs.btrfs, mount it,
> and send/receive. But send requires read only snapshots. Making a
> sprout is easier, you just remove the seed device. This is supported
> since 2009.
> 
> # losetup -r /dev/loop0 root.img
> # mount /dev/loop0 /mnt/
> # btrfs device add /dev/sda3 /mnt
> # mount -o remount,rw /mnt
> # btrfs device remove /dev/loop0 /mnt
> 
> And now it replicates extents from seed to sprout.  The copy is faster
> than pvmove, rsync, dd, or rpm-ostree deploy.

This sounds great!

I just tried it (on Fedora 29), but those steps don't work for me:

# cryptsetup --readonly luksOpen /dev/nbd0p4 tmp
# mount -o noatime /dev/mapper/tmp /mnt/tmp
# mount: /mnt/tmp: WARNING: device write-protected, mounted read-only.
# btrfs device add /dev/nbd1 /mnt/tmp   
Performing full device TRIM /dev/nbd1 (4.00GiB) ...
ERROR: error adding device '/dev/nbd1': Read-only file system

Am I missing something?

Best regards
Georg
-- 
'NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE
INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION!'
(http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000239.html)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Monday's FESCo Meeting (2019-01-07)

2019-01-04 Thread Randy Barlow 
Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2019-01-07 15:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda


= Discussed and Voted in the Ticket =

F30 System-Wide Change: Ruby 2.6
https://pagure.io/fesco/issue/2022
Accepted (+7, 0, -0)

F30 System-Wide Change: Boost 1.69 upgrade
https://pagure.io/fesco/issue/2024
Accepted (+7, 0, -0)

F30 Change: Erlang 21
https://pagure.io/fesco/issue/2025
Accepted (+5, 1, -0)

F30 System-Wide Change: Enabling Python Generators by default
https://pagure.io/fesco/issue/2026
Accepted (+7, 0, -0)

F30 Change: Python-progressbar2 as default
https://pagure.io/fesco/issue/2030
Accepted (+5, 0, -0)


= New business =

#topic #2021 F30 Change: Migrate Python-based Nautilus extensions to
Python 3
.fesco 2021
https://pagure.io/fesco/issue/2021

#topic #2027 RFC: Module lifecycles
.fesco 2027
https://pagure.io/fesco/issue/2027

#topic #2028 RFC: Stream branch ownership for packages & modules
.fesco 2028
https://pagure.io/fesco/issue/2028

#topic #2033 F30 Change: Deprecate Sonatype OSS Parent
.fesco 2033
https://pagure.io/fesco/issue/2033

#topic #2035 F30 Change: Deprecate Apache Jakarta ORO and Regexp
.fesco 2035
https://pagure.io/fesco/issue/2035

#topic #2036 F30 Change: Deprecate Apache Jakarta Commons HttpClient
.fesco 2036
https://pagure.io/fesco/issue/2036

#topic #2038 Rebase of systemd in F29
.fesco 2038
https://pagure.io/fesco/issue/2038

#topic #2045 Unresponsive maintainer: Pradeep Kilambi
.fesco 2045
https://pagure.io/fesco/issue/2045


= 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.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ONGOING PROBLEM: Buildsystem degradation

2019-01-04 Thread Kevin Fenzi 
On 12/24/18 4:24 AM, Till Hofmann wrote:

> OK, I was actually wondering exactly that, I remembered that COPR is
> maintained/run by someone else. But on the Fedora Infrastructure Status
> page [1], there is also a COPR status, and the link for outages directly
> leads to the fedora-infrastructure tracker, that's why I thought that's
> the right place. I guess it may already help if the status page linked
> to the right trackers for each component?

Yes, or (as we have planned but not yet done, reorganize status to note
different sections of things based on their SLE).

> Is status.fp.o still actually used? There is at least one commit from
> April 2017 that still hasn't been deployed.

It is. Where are you seeing that?

The repo is:

https://github.com/fedora-infra/statusfpo/commits/master

last commit dec 18th, 2018.

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What does delaying F31 mean for packagers/users?

2019-01-04 Thread Florian Weimer 
* Owen Taylor:

> One of the key parts of making a decision to delay/skip F31 is
> figuring out, ahead of the decision, what the expected experience is
> for users and packagers. Does F30 have normal stability, or do we try
> to keep users happy by moving things forward with ad-hoc updates and
> cross-our-fingers and hope nothing breaks?

Has a definite decision been made here?  Where can we track the process
for that, so that we can adjust our plans as necessary?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

2019-01-04 Thread Jakub Jelen 
On Wed, 2018-12-12 at 17:20 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
> 
> == Summary ==
> Remove scriptlets which are not needed anymore (ldconfig,
> gtk-update-icon-cache, etc.).
> 
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Gnatenko]]
> * Email: ignatenkobr...@fedoraproject.org
> 
> == Scope ==
> * Proposal owners: Find appropriate packages and remove obsolete
> scriptlets.
> * Other developers: Package Maintainers are advised to remove
> scriptlets themselves or wait until Proposal Owners will do that.
> * Release engineering: [https://pagure.io/releng/issue/7977 #7977]
> (to
> avoid multiple rebuilds, completing this change before mass rebuild
> is
> advised)

Please, make sure you update and release fedora-review to not require
these scriptlets and warn when they are not needed.

The official review tool still errors if some of the scriptlets that
were removed in the previous batches are needed.

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Problem with portaudio linking

2019-01-04 Thread Michael Schwendt 
On Fri, 4 Jan 2019 10:41:46 +0100, Michal Ruprich wrote:

> Hi,
> 
> has anyone encountered a problem on F28 when building a package that
> uses portaudio? I was building newer version of wireshark a month ago
> and -lportaudio worked fine. Now the build with the same version fails
> with message 'checking for Pa_Initialize in -lportaudio... no' and
> 'configure: error: Linking with libportaudio failed'. The build still
> works on F29 and in Rawhide, only F28 hits this issue. Anyone else has
> seen this happening?

Have you tried a build with

  %configure || cat config.log

to check why the library linking test has failed?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: clang and Fedora's default C/CXX flags

2019-01-04 Thread Florian Weimer 
* Serge Guelton:

> https://clang.llvm.org/docs/SafeStack.html looks like a decent choice.

“Linking a DSO with SafeStack is not currently supported.”
I also don't see any discussion of debugging support.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

2019-01-04 Thread Panu Matilainen 

On 1/4/19 12:15 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Jan 04, 2019 at 10:56:05AM +0200, Panu Matilainen wrote:

On 1/3/19 5:02 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Jan 03, 2019 at 12:00:13PM +0200, Panu Matilainen wrote:

On 1/3/19 11:47 AM, Dridi Boukelmoune wrote:



On Thu, Jan 3, 2019, 09:59 Panu Matilainen mailto:pmati...@redhat.com> wrote:

  On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
   >> "FV" == Fabio Valentini mailto:decatho...@gmail.com>> writes:
   >
   > FV> - unless those other, main icon theme packages have also added
   > FV> %transfiletrigger* scriptlets, like I've done for elementary and
   > FV> Paper.
   >
   > Perhaps it should be mandatory for icon themes to add the
  necessary file
   > triggers so that no package will ever need to have a scriptlet which
   > calls gtk-update-icon-cache.
   >
   > In general I think that the distro as a whole should pivot towards
   > official, guideline-codified scriptlet avoidance, such that adding
   > appropriate file triggers should be mandatory where it avoids the
  need
   > for packages down the dependency chain to have scriptlets.  I'm sure
   > there are a number of places where this could be done.  Having
  this as a
   > distro-wide goal would make it easier to get changes like the glibc
   > ldconfig file triggers implemented (which took years to get the
  current
   > incomplete implementation pushed).

  +1

  Ultimately the goal should be making the "traditional" scriptlets
  extinct to the point that using them requires an exception.

  I've no illusions here, it's going to be a long long road and require
  further enhancements to rpm (for example dealing with users and groups)
  but that's what the long-term overall goal should be.


I was wondering about the case of users and groups in scriptlets.
Something I would like to investigate next time I dedicate free time to
Fedora is conditional and one-shot services with systemd.

Maybe some of that complexity could move from the package manager to the
service manager. For the use case I have in mind it's definitely the
service that wants the user and group, because none of the installed
files need them. It's only a runtime requirement for the service.


For the case where the packaged files don't need custom user/groups, you can
(and probably should) use systemd facilities already: see sysusers.d(5)

That doesn't help with packaged files though, unless split into a separate
pre-requisite package which is a bit heavy solution for that.


This is a solved problem already.


No it's not.


 From systemd.macros:

# This should be used by package installation scripts which require users or
# groups to be present before the files installed by the package are present on
# disk (for example because some files are owned by those users or groups).
#
# Example:
#   Source1: %{name}-sysusers.conf
#   ...
#   %install
#   install -D %SOURCE1 %{buildroot}%{_sysusersdir}/%{name}.conf
#   %pre
#   %sysusers_create_package %{name} %SOURCE1
#   %files
#   %{_sysusersdir}/%{name}.conf

Also please note that Harald Hoyer and Kay Sievers (in cc) are working on
actually making use of this in Fedora.


Having standard macros for user/group creation is certainly an improvement
over the current situation, but this still requires scriptlets for a task
that should be a declarative item in the spec.


It's "solved" in the sense that a fully working solution exists. It
doesn't require a seperate package. 


Oh okay you were referring to *that* particularly. In that case, yeah.


The biggest advantage is that the data is declarative in the sysusers
file, the information does not have to be duplicated, and the
scriptlet produces the exact same effect as running sysusers after
installation.

Having this implemented directly in rpm would be an improvement, but
wouldn't change a lot for the packager, because we'd still want the
sysusers file to be installed. I'm not even sure if reimplementing
user creation in rpm would be good. A better solution could be something
like %transfiletriggerpre, where a trigger could be installed for some
file patterns and would run before the rest of the package is installed.
I.e. something like those scriptlets do now, but without having to
define the scriptlet in each package.


Yup, only you need the files unpacked in order to do such a thing, and 
at that point it's too late, at least with the way rpm currently works.


Yup. I don't fancy reimplementing user/group management in rpm directly, 
I'm thinking more about integrating with existing solutions one way or 
the other. Sysusers is a good candidate since, as you point out, it has 
a declarative syntax already. The biggest problems with any approach 
tend to be with bootstrapping, when installing into an empty chroot 
it'll be a good while until any user management tools are present there

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

2019-01-04 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Jan 04, 2019 at 10:56:05AM +0200, Panu Matilainen wrote:
> On 1/3/19 5:02 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Jan 03, 2019 at 12:00:13PM +0200, Panu Matilainen wrote:
> > > On 1/3/19 11:47 AM, Dridi Boukelmoune wrote:
> > > > 
> > > > 
> > > > On Thu, Jan 3, 2019, 09:59 Panu Matilainen  > > >  wrote:
> > > > 
> > > >  On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
> > > >   >> "FV" == Fabio Valentini  > > >  > writes:
> > > >   >
> > > >   > FV> - unless those other, main icon theme packages have also 
> > > > added
> > > >   > FV> %transfiletrigger* scriptlets, like I've done for 
> > > > elementary and
> > > >   > FV> Paper.
> > > >   >
> > > >   > Perhaps it should be mandatory for icon themes to add the
> > > >  necessary file
> > > >   > triggers so that no package will ever need to have a scriptlet 
> > > > which
> > > >   > calls gtk-update-icon-cache.
> > > >   >
> > > >   > In general I think that the distro as a whole should pivot 
> > > > towards
> > > >   > official, guideline-codified scriptlet avoidance, such that 
> > > > adding
> > > >   > appropriate file triggers should be mandatory where it avoids 
> > > > the
> > > >  need
> > > >   > for packages down the dependency chain to have scriptlets.  I'm 
> > > > sure
> > > >   > there are a number of places where this could be done.  Having
> > > >  this as a
> > > >   > distro-wide goal would make it easier to get changes like the 
> > > > glibc
> > > >   > ldconfig file triggers implemented (which took years to get the
> > > >  current
> > > >   > incomplete implementation pushed).
> > > > 
> > > >  +1
> > > > 
> > > >  Ultimately the goal should be making the "traditional" scriptlets
> > > >  extinct to the point that using them requires an exception.
> > > > 
> > > >  I've no illusions here, it's going to be a long long road and 
> > > > require
> > > >  further enhancements to rpm (for example dealing with users and 
> > > > groups)
> > > >  but that's what the long-term overall goal should be.
> > > > 
> > > > 
> > > > I was wondering about the case of users and groups in scriptlets.
> > > > Something I would like to investigate next time I dedicate free time to
> > > > Fedora is conditional and one-shot services with systemd.
> > > > 
> > > > Maybe some of that complexity could move from the package manager to the
> > > > service manager. For the use case I have in mind it's definitely the
> > > > service that wants the user and group, because none of the installed
> > > > files need them. It's only a runtime requirement for the service.
> > > 
> > > For the case where the packaged files don't need custom user/groups, you 
> > > can
> > > (and probably should) use systemd facilities already: see sysusers.d(5)
> > > 
> > > That doesn't help with packaged files though, unless split into a separate
> > > pre-requisite package which is a bit heavy solution for that.
> > 
> > This is a solved problem already.
> 
> No it's not.
> 
> > From systemd.macros:
> > 
> > # This should be used by package installation scripts which require users or
> > # groups to be present before the files installed by the package are 
> > present on
> > # disk (for example because some files are owned by those users or groups).
> > #
> > # Example:
> > #   Source1: %{name}-sysusers.conf
> > #   ...
> > #   %install
> > #   install -D %SOURCE1 %{buildroot}%{_sysusersdir}/%{name}.conf
> > #   %pre
> > #   %sysusers_create_package %{name} %SOURCE1
> > #   %files
> > #   %{_sysusersdir}/%{name}.conf
> > 
> > Also please note that Harald Hoyer and Kay Sievers (in cc) are working on
> > actually making use of this in Fedora.
> 
> Having standard macros for user/group creation is certainly an improvement
> over the current situation, but this still requires scriptlets for a task
> that should be a declarative item in the spec.

It's "solved" in the sense that a fully working solution exists. It
doesn't require a seperate package. The biggest advantage is that the
data is declarative in the sysusers file, the information does not
have to be duplicated, and the scriptlet produces the exact same effect
as running sysusers after installation.

Having this implemented directly in rpm would be an improvement, but
wouldn't change a lot for the packager, because we'd still want the
sysusers file to be installed. I'm not even sure if reimplementing
user creation in rpm would be good. A better solution could be something
like %transfiletriggerpre, where a trigger could be installed for some
file patterns and would run before the rest of the package is installed.
I.e. something like those scriptlets do now, but without having to
define the scriptlet in each package.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsub

Re: clang and Fedora's default C/CXX flags

2019-01-04 Thread Serge Guelton 
On Thu, Jan 03, 2019 at 12:31:50PM -0800, Tom Stellard wrote:
> On 01/03/2019 12:28 PM, Carlos O'Donell wrote:
> > On 1/3/19 2:49 PM, Michael Cronenworth wrote:
> >> Part of Fedora's default C/CXX flags include -fstack-clash-protection
> >> but clang does not support this flag and has until a few weeks ago[1]
> >> silently ignored the flag.
> >>
> >> What are clang apps who use Fedora's default flags supposed to do?
> >> Are there clang default flag macros?
> >>
> >> Thanks, Michael
> >>
> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1658311
> > 
> > You should reach out to Tom or Serge for comments :-)
> > 
> 
> The recommended solution for now is to filter out flags that clang does
> not support.
> 
> See for example: 
> https://src.fedoraproject.org/rpms/libcxx/blob/master/f/libcxx.spec#_60
> 
If the goal is to harden the binary without much performance overhead,
clang also proposes some unique flags, maybe it is worth considering
them?

https://clang.llvm.org/docs/SafeStack.html looks like a decent choice.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Call for participation: FOSDEM 2019

2019-01-04 Thread Zacharias Mitzelos 
Hello everyone,

FOSDEM[0], the biggest free and non-commercial event organized by and for the 
community in Europe, is less than a month away. The conference will be held in 
Brussels, Belgium, on February 2 & 3. As every year, EMEA Ambassadors organize 
the booth at FOSDEM, where many developers, contributors and students visit it 
to discuss with us or get some swag.

This is an open call especially for Fedora developers and technical 
contributors, to participate in our booth at FOSDEM. One of your main tasks 
would be to assist people and represent Fedora from a technical point of view. 
Our theme is about extending the Fedora Project by developing new solutions, 
packaging, helping users get installed, and troubleshoot any errors that they 
may have. We are looking for experienced packagers and developers who have 
extensive knowledge on packaging, rpm, Gnome, or in general have extensive 
knowledge of the ins and outs of Fedora, willing to help users and answer 
technical questions. We want to focus on helping users be successful with 
Fedora, and not try to be a general helpdesk for all technologies as most of 
them have their own communities present. We are also welcoming new contributors 
who didn’t get the chance to come in the previous years. While we prefer 
contributors from EMEA to allow us to use our budget to bring the most 
contributors, we make our decision based on fit for our goals at the conference 
first and money second.
 
There is also some budget in place and we can provide travel and lodging 
funding to some developers and technical contributors in order to attend and 
assist at the booth. Sponsored contributors are expected to work for 8 hours at 
the booth during the two days of the conference. We will try to accommodate 
your needs, but we need to keep the booth fully staffed so we will be building 
the schedule for you. If you would like to request funding, open a funding 
request at the EMEA funding request tracker[1], explaining why you are asking 
for funding, why you should get it and how you are going to contribute to the 
booth. We will start reviewing requests on January 8, so submit early to get 
selected.

Have a nice weekend,
Zach

[0] https://fosdem.org
[1] https://pagure.io/ambassadors-emea/funding_requests/new_issue

--
Zacharias Mitzelos

mitzie on freenode
http://zacharias.mitzelos.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Problem with portaudio linking

2019-01-04 Thread Michal Ruprich 
Hi,

has anyone encountered a problem on F28 when building a package that
uses portaudio? I was building newer version of wireshark a month ago
and -lportaudio worked fine. Now the build with the same version fails
with message 'checking for Pa_Initialize in -lportaudio... no' and
'configure: error: Linking with libportaudio failed'. The build still
works on F29 and in Rawhide, only F28 hits this issue. Anyone else has
seen this happening?

Thanks.

-- 
Michal Ruprich
Associate Software Engineer

Email: mrupr...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

2019-01-04 Thread Panu Matilainen 

On 1/3/19 5:02 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Jan 03, 2019 at 12:00:13PM +0200, Panu Matilainen wrote:

On 1/3/19 11:47 AM, Dridi Boukelmoune wrote:



On Thu, Jan 3, 2019, 09:59 Panu Matilainen mailto:pmati...@redhat.com> wrote:

 On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
  >> "FV" == Fabio Valentini mailto:decatho...@gmail.com>> writes:
  >
  > FV> - unless those other, main icon theme packages have also added
  > FV> %transfiletrigger* scriptlets, like I've done for elementary and
  > FV> Paper.
  >
  > Perhaps it should be mandatory for icon themes to add the
 necessary file
  > triggers so that no package will ever need to have a scriptlet which
  > calls gtk-update-icon-cache.
  >
  > In general I think that the distro as a whole should pivot towards
  > official, guideline-codified scriptlet avoidance, such that adding
  > appropriate file triggers should be mandatory where it avoids the
 need
  > for packages down the dependency chain to have scriptlets.  I'm sure
  > there are a number of places where this could be done.  Having
 this as a
  > distro-wide goal would make it easier to get changes like the glibc
  > ldconfig file triggers implemented (which took years to get the
 current
  > incomplete implementation pushed).

 +1

 Ultimately the goal should be making the "traditional" scriptlets
 extinct to the point that using them requires an exception.

 I've no illusions here, it's going to be a long long road and require
 further enhancements to rpm (for example dealing with users and groups)
 but that's what the long-term overall goal should be.


I was wondering about the case of users and groups in scriptlets.
Something I would like to investigate next time I dedicate free time to
Fedora is conditional and one-shot services with systemd.

Maybe some of that complexity could move from the package manager to the
service manager. For the use case I have in mind it's definitely the
service that wants the user and group, because none of the installed
files need them. It's only a runtime requirement for the service.


For the case where the packaged files don't need custom user/groups, you can
(and probably should) use systemd facilities already: see sysusers.d(5)

That doesn't help with packaged files though, unless split into a separate
pre-requisite package which is a bit heavy solution for that.


This is a solved problem already. 


No it's not.


From systemd.macros:

# This should be used by package installation scripts which require users or
# groups to be present before the files installed by the package are present on
# disk (for example because some files are owned by those users or groups).
#
# Example:
#   Source1: %{name}-sysusers.conf
#   ...
#   %install
#   install -D %SOURCE1 %{buildroot}%{_sysusersdir}/%{name}.conf
#   %pre
#   %sysusers_create_package %{name} %SOURCE1
#   %files
#   %{_sysusersdir}/%{name}.conf

Also please note that Harald Hoyer and Kay Sievers (in cc) are working on
actually making use of this in Fedora.


Having standard macros for user/group creation is certainly an 
improvement over the current situation, but this still requires 
scriptlets for a task that should be a declarative item in the spec.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

2019-01-04 Thread Pavel Březina 

On 12/6/18 12:20 PM, Pavel Březina wrote:

Hello,

systemd and nss-mdns packages modifies nsswitch.conf in their %post 
scriptlets which creates conflicts with authselect on systems that are 
configured by authselect. This needs to be solved somehow.


Originally, I wanted to create an authselect command that can be used by 
packages on systems that are configured by authselect and on systems 
that are configured with different ways [1]. But it turned out that 
there are only two packages that touches nsswitch.conf so I do not think 
this is necessary.


I prepared initial design document with multiple solutions that came to 
my mind [2] and I would like to discuss this with the community to see 
what is the correct and desired way to solve this.


Thank you,
Pavel.

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4YMQOZCV32272UIGZM45NVJLVZY2UOZH/ 



[2] 
https://fedoraproject.org/wiki/User:Pbrezina/Authselect_and_packages_that_modifies_nsswitch 


Reading the whole discussion here, I think it would be best for the 
moment to make systemd and nss-mdns scriptlets compatible also with 
authselect configuration and let systemd maintainers to get their 
modules in glibc if/when possible. Once it is in glibc default 
nsswitch.conf it will get picked up by authselect.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org