Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Chuck Anderson]

On Tue, Feb 06, 2024 at 09:56:30AM +1000, Peter Hutterer wrote:
> On Mon, Feb 05, 2024 at 10:33:52AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Feb 05, 2024 at 10:34:13AM +1000, Peter Hutterer wrote:
> > > > And even before that, things were already only limping along. That was
> > > > happening for over a decade and in that timeframe *nobody* has wanted
> > > > to step up and work on it. Wayland is the future because otherwise we
> > > > have no graphics future, as things currently stand.
> > > 
> > > It also doesn't help that the "it's the same people working on X and
> > > Wayland" argument means that, absent significant breakthroughs in
> > > space-time research, we can work on one or the other, not both.
> > > Something's got to give.
> > 
> > We could also switch to a 4-day week, with 20h shifts ;)
> 
> "if 24h in a day isn't enough, work at night"
> 
> Uncredited because I'm not sure the person I got this from (in jest)
> really wants the credit ;)

Just schedule the work for Q5 (the fifth quarter).
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Chuck Anderson]

On Tue, Jan 16, 2024 at 08:02:28PM +0100, Pavel Raiskup wrote:
> I just want to bump this thread; @kevin updated Fedora Koji today
> - the Fedora 40+ (current Rawhide) builds are already handled with DNF5.
> 
> Happy (faster) building!  And should you face any issue, please report.
> Pavel

In case it helps someone else, as documented here:

https://fedoraproject.org/wiki/Changes/BuildWithDNF5

You need to do:

mock -r fedora-40-x86_64 --scrub=all

to allow "fedpkg mockbuild" to work again, otherwise one gets this error:

DEBUG util.py:461:  execv(/usr/bin/dnf5) failed: No such file or directory
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Change of cronie and crontabs CIS compliance

[Chuck Anderson]

On Wed, Dec 06, 2023 at 12:18:48PM +, Daniel P. Berrangé wrote:
> The main effect of the permissions change on these files is that non-root
> users can't see any env variables set against the commands scheduled to run.
> The actual command lines are still all visible in the proces listing when
> the command runs.

I think this part alone is worthwhile in a general distro like Fedora,
irrespective of any CIS requirements.  Env vars can contain secret
data and they are no longer readble by all users in process lists, so
changing permissions on cron files fixes a real potential information
leak.

Also, it is hard to keep file and directory permissions changed from
how they are packaged.  The files will become exposed during package
updates until some other script comes by and fixes them again.  So it
is worthwhile to fix this in the packaging.

I agree that the correct middle ground is to fix the permissions, but
leave the other parts about cron.allow/cron.deny alone.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Unretiring keepass

[Chuck Anderson]

On Thu, Nov 23, 2023 at 05:47:30PM +0100, Julian Sikorski wrote:
> 23.11.23 um 14:48 schrieb Sandro:
> > [1] https://keepassxc.org/
> > [2] https://src.fedoraproject.org/rpms/keepassxc
> > [3] https://www.keepassdx.com/
> 
> Thanks for the info! I do not remember what the problem was exactly, but 
> last time I tried I ran into issues when trying to use keepassxc 
> cross-platform on Linux, Windows and Android (Keepass2Android) while 
> using Kee for browser integration. Something was missing, so I just kept 
> updating the keepass rpm locally and making sure not to trigger the bug.
> With the issue fixed, it makes sense to put keepass back into Fedora.

FYI these are also available in Fedora:

keepassxc-cli - non-interactive CLI command interface to Keepass
databases (part of the keepassxc package mentioned above)

kpcli - interactive shell-style interface to Keepass databases (now
supports v3 and v4 databases)
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Chuck Anderson]

On Fri, Sep 15, 2023 at 02:35:36PM +0100, Daniel P. Berrangé wrote:
> IIUC strictly speaking content must be validated for license compliance
> before it is present on any Fedora infrastructure. IOW, doing scratch
> builds in either Koji or Copr is also predicated on having permissible
> content under an approved license, just as lookaside cache uploads are.

Doesn't the-new-hotness already do scratch builds in Koji in an automated
fashion with no license checking?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5-5.0.1 has a stable API

[Chuck Anderson]

On Wed, Jul 26, 2023 at 09:05:08AM +0200, Miroslav Suchý wrote:
> Dne 24. 07. 23 v 22:43 Chuck Anderson napsal(a):
> > I propose "qzw".  It's so easy to type on a qwerty keyboard layout.
> 
> English qwerty layout. Because on Czech layout "z" and "y" are swappe. :)

Oh yeah, we need to find a better name that takes equal effort for trained 
touch-typists on all keyboard layouts.  Gotta work that left pinky finger.  
(Can you tell I'm still bitter because of the yum --> dnf rename?)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5-5.0.1 has a stable API

[Chuck Anderson]

On Mon, Jul 24, 2023 at 02:08:25PM -0400, Stephen Smoogen wrote:
> Personally I would have preferred to call this a new tool versus trying to
> use dnf name still. It makes it clearer that the break is going to happen.

I propose "qzw".  It's so easy to type on a qwerty keyboard layout.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg: Failed to get repository name from Git url or pushurl -> %build

[Chuck Anderson]

On Tue, Mar 07, 2023 at 11:14:34PM +, Kenneth Goldman wrote:
> Let's see if I have this right ...
> 
> %build
> %configure
> %make_build
> 
> are not three separate steps.  %build is the overall step, and the next two 
> lines
> are the build steps.  The blank line terminates the %build.  Correct?

An unfortunate happenstance of RPM is that spec file script sections and
macros both start with the % character.  The main script sections are:

%prep %build %install %check %pre %post %preun %postun
(there are some others)

Some other sections that aren't scripts are:

%files %changelog %package

Other words that start with % are macros. That's what these are:

%setup
%autosetup
%configure
%make_build
%make_install

> Where are the macros defined?  I.e., %configure probably expands
> to ./configure and %make_build to make. 

/usr/lib/rpm/macros
/usr/lib/rpm/macros.d/*

> If I want to add some arguments to configure, 

%configure --argument1 --argument2 etc.

> and add an autoreconf step before configure, how would I do that?

I don't think there are any autoconf/autoreconf macros.  You just run
it directly, e.g:

%build
autoreconf -iv
%configure
%make_build

Sometimes the upstream source includes a script to do all the right
things with autoconf/autoreconf:

%build
./autogen.sh
%configure
%make_build
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Strange RPM build warning

[Chuck Anderson]

February is abbreviated as "Fed" in the first changelog entry:

* Tue Fed 28 2023 Steve Dickson  1.2.6-4.rc2
- Updated to latest upstream RC release: rpcbind-1_2_7-rc2

On Tue, Feb 28, 2023 at 12:33:39PM -0500, Steve Dickson wrote:
> 
> 
> On 2/28/23 12:12 PM, Miro Hrončok wrote:
> > On 28. 02. 23 17:43, Steve Dickson wrote:
> >> Hello,
> >>
> >> I'm getting this warning
> >>
> >> RPM build warnings:
> >>  source_date_epoch_from_changelog set but %changelog is missing
> >>
> >> But the %changelog is not missing...
> >>
> >> Any ideas?
> > 
> > Could you please share the spec file?
> > 
> > I've seen this when the %changelog was considered "invalid" by RPM. That 
> > way, it is ignored. E.g. when it is not sorted by date or if the dates 
> > are bogus.
> Sure... see the attachment... I don't see any bogus dates... but
> maybe I'm just not seeing something... Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

review swap: ancient - Modern decompressor for old data compression formats

[Chuck Anderson]

ocp (Open Cubic Player for MOD/S3M/XM/IT/MIDI music files) has grown a
new dependency on libancient.  I submitted a new package review
request:

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

Review Request: ancient - Modern decompressor for old data compression formats

This is a collection of decompression routines for old formats popular
in the Amiga, Atari computers and some other systems from 80's and
90's as well as some that are currently used which were used in a some
specific way in these old systems.

Would someone be willing to swap reviews with me?

Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Chuck Anderson]

Another system success:

Installing weak dependencies:
 ipp-usb   x86_64 
0.9.23-2.fc38   fedora  
   2.1 M
 oneVPL-intel-gpu  x86_64 
22.5.3-1.fc38   fedora  
   2.1 M
 passt x86_64 
0^20230216.g4663ccc-1.fc38  fedora  
   174 k
Removing:
 kernelx86_64 
6.1.7-200.fc37  @updates-testing
 0  
 kernel-core   x86_64 
6.1.7-200.fc37  @updates-testing
91 M
 kernel-modulesx86_64 
6.1.7-200.fc37  @updates-testing
57 M
 kernel-modules-extra  x86_64 
6.1.7-200.fc37  @updates-testing
   3.2 M
Downgrading:
 Lmod  x86_64 
8.7.18-1.fc38   fedora  
   258 k
 enchant2  x86_64 
2.3.3-6.fc38fedora  
65 k
 freerdp-libs  x86_64 
2:2.9.0-3.fc38  fedora  
   1.0 M
 fwupd x86_64 
1.8.10-1.fc38   fedora  
   1.8 M
 fwupd-plugin-flashrom x86_64 
1.8.10-1.fc38   fedora  
26 k
 fwupd-plugin-modem-managerx86_64 
1.8.10-1.fc38   fedora  
60 k
 fwupd-plugin-uefi-capsule-datax86_64 
1.8.10-1.fc38   fedora  
   1.8 M
 hdparmx86_64 
9.63-2.fc38 fedora  
96 k
 libwinpr  x86_64 
2:2.9.0-3.fc38  fedora  
   355 k
 mock-core-configs noarch 
38.1-1.fc38 fedora  
   141 k

Transaction Summary
===
Install  37 Packages
Upgrade2669 Packages
Remove4 Packages
Downgrade10 Packages

Total download size: 3.5 G
Operation aborted.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Chuck Anderson]

Success:

Installing weak dependencies:
 ipp-usb   x86_64 
0.9.23-2.fc38   fedora  
   2.1 M
 oneVPL-intel-gpu  x86_64 
22.5.3-1.fc38   fedora  
   2.1 M
 passt x86_64 
0^20230216.g4663ccc-1.fc38  fedora  
   174 k
Removing:
 kernelx86_64 
6.0.15-300.fc37 @updates
 0
 kernel-core   x86_64 
6.0.15-300.fc37 @updates
92 M
 kernel-modulesx86_64 
6.0.15-300.fc37 @updates
56 M
 kernel-modules-extra  x86_64 
6.0.15-300.fc37 @updates
   3.2 M
Downgrading:
 fwupd x86_64 
1.8.10-1.fc38   fedora  
   1.8 M
 fwupd-plugin-flashrom x86_64 
1.8.10-1.fc38   fedora  
26 k
 fwupd-plugin-modem-managerx86_64 
1.8.10-1.fc38   fedora  
60 k
 fwupd-plugin-uefi-capsule-datax86_64 
1.8.10-1.fc38   fedora  
   1.8 M
 mock-core-configs noarch 
38.1-1.fc38 fedora  
   141 k

Transaction Summary
===
Install  36 Packages
Upgrade2636 Packages
Remove4 Packages
Downgrade 6 Packages

Total download size: 2.9 G
Operation aborted.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Take 1 minute to help with Infra & Releng Team with a decision

[Chuck Anderson]

On Wed, Feb 08, 2023 at 06:43:02PM +0100, Eike Rathke wrote:
> Hi Michal,
> 
> On Tuesday, 2023-02-07 16:24:16 +0100, Michal Konecny wrote:
> 
> > [0] - https://forms.gle/J2HWDkw1UNuj8HYD8
> 
> Don't be surprised if you don't get the number of answers you hoped for,
> on
> 
> a) a Google form
> b) that requires a Google account
> c) to be logged in

b) and c) are not true.  A private-browsing FF window worked fine for me.



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: systemd-resolved package overwrite /etc/resolv.conf again

[Chuck Anderson]

On Sun, Jan 22, 2023 at 07:54:52AM +0100, Francois wrote:
> On Sun, 22 Jan 2023 at 05:44, Casper  wrote:
> >
> > This bug is rare and I'm not able to reproduce it, actually.
> >
> 
> it's not what you asked for, but you mention fping and the last commit
> on fping addresses an issue with name resolution
> https://github.com/schweikert/fping/commit/8dc0b7f39a09f0745ba308292c3ac1c6013394c3
> 
> it would be interesting to try running a version containing this fix,
> see if you still have issues.

That we me, not the OP.  Thanks for the pointer--I tried it but it
still hangs.  I'll open a bug against fping first and move it to
systemd-resolved if necessary.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: systemd-resolved package overwrite /etc/resolv.conf again

[Chuck Anderson]

On Sat, Jan 21, 2023 at 09:48:35PM +0100, Peter Boy wrote:
> However, all of this is not advisable. Rather, my question is, what exactly 
> doesn’t work well. We are aware of issues with libvirt  virbr0 virtual 
> network interfaces and various parts of systemd. One of them is 
> systemd-resolved and specifically split DNS resolving.

For example the following fails with systemd-resolved and works with a normal 
resolv.conf:

fping -n -g 192.168.1.0/24
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Chuck Anderson]

On Thu, Jan 12, 2023 at 07:57:28PM +0100, Miro Hrončok wrote:
> On 12. 01. 23 18:53, Susi Lehtola wrote:
> > On 1/12/23 19:48, Miro Hrončok wrote:
> >> On 12. 01. 23 18:42, Susi Lehtola wrote:
> >>> On 12/5/22 13:36, Miro Hrončok wrote:
>  The following packages are orphaned and will be retired when they
>  are orphaned for six weeks, unless someone adopts them. If you know for 
>  sure
>  that the package should be retired, please do so now with a proper 
>  reason:
>  https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
>  Note: If you received this mail directly you (co)maintain one of the 
>  affected
>  packages or a package that depends on one. Please adopt the affected 
>  package or
>  retire your depending package to avoid broken dependencies, otherwise 
>  your
>  package will fail to install and/or build when the affected package gets 
>  retired.
> >>>
> >>> Hello,
> >>>
> >>> although I was mentioned in the email
> >>>
>  Affected (co)maintainers (either directly or via packages' dependencies):
>  jussilehtola: CheMPS2
> >>>
> >>> I was was not contacted about this and the package has been falsely 
> >>> retired.
> >>> Please check your scripts to reach out to other maintainers who may have 
> >>> been
> >>> bitten by the retirements.
> >>
> >> I have just checked and you were Bcc'ed like all the other affected 
> >> maintainers.
> > 
> > Well, bccing means that the mail wasn't addressed to me and therefore I 
> > just got
> > the single mail that got delivered as part of the normal list distribution,
> > which means I also didn't get notified about the retirement...
> 
> Better suggestions welcome.

For receiving/filtering emails, you can filter on the List-Id: header
rather than the To: or Cc: headers.  In that way you can differentiate
between normal list distribution and Bcc:.  If there is no List-Id:
header, the mail can be directed to your Inbox rather than the mailing
list folder (if that is how you filter your messages) or otherwise
flag it as important, etc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Chuck Anderson]

On Wed, Jan 04, 2023 at 03:04:02PM +0100, Vít Ondruch wrote:
> 
> Dne 03. 01. 23 v 19:03 Todd Zullinger napsal(a):
> > Zbigniew Jędrzejewski-Szmek wrote:
> >> Yes, this is what I was talking about too. Because rpmbuild does not set
> >> %_sourcedir, it may fail to load some files. Even worse, it may load 
> >> *wrong*
> >> versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
> >> Personally, I have dozens of stray files there from old rpm builds there…
> > I've used the following in ~/.rpmmacros for many years to
> > have rpmbuild keep package files together, as rpkg/fedpkg
> > do:
> >
> >  %_sourcedir %{_topdir}/%{?name:%name}
> >  %_specdir   %{_sourcedir}
> >  %_builddir  %{_sourcedir}
> >  %_srcrpmdir %{_sourcedir}
> >  %_rpmdir%{_sourcedir}
> 
> 
> Change to the dist-git layout is tracked upstream [1], so maybe the 
> default will change one day. But shouldn't we suggest this configuration 
> somewhere in Fedora documentation? Maybe we could speed up the 
> transition ...

There is rpmdev-setuptree in the rpmdevtools package, which itself is
required by fedora-packager.  It creates the following:

$ cat .rpmmacros

%_topdir %(echo $HOME)/rpmbuild

%__arch_install_post \
[ "%{buildarch}" = "noarch" ] || QA_CHECK_RPATHS=1 ; \
case "${QA_CHECK_RPATHS:-}" in [1yY]*) /usr/lib/rpm/check-rpaths ;; esac \
/usr/lib/rpm/check-buildroot

$ find rpmbuild
rpmbuild/
rpmbuild/RPMS
rpmbuild/SOURCES
rpmbuild/SPECS
rpmbuild/SRPMS
rpmbuild/BUILD

Perhaps this can be modified to create a layout that matches dist-git?


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Chuck Anderson]

On Wed, Dec 21, 2022 at 01:32:10PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote:
> [...]
> > Let me put together a few points to sum this up:
> > 
> > 1) DNF name is well established, keep the DNF name (and forget about YUM).
> > 
> > 2) Keep the compatibility on reasonable level. 100% compatibility is myth
> > (even between the tiniest updates).
> > 
> > 3) Changes are inevitable, especially between major versions. That is why we
> > version, right? While nobody likes them (especially breaking changes), they
> > are accepted. Please don't be afraid to do them for good!
> > 
> > 4) Keep the package name, so if somebody don't want to update, they can do
> > `dnf update --exclude dnf` instead of looking for new package name to do
> > `dnf update --exclude dnf5`
> > 
> > 5) I certainly wont combine DNF 4 and DNF 5 on one system. I don't think any
> > user want to combine these, unless they are desperate. Don't bet everything
> > on this.
> > 
> > 6) Keep only one instance of documentation, if needed, document the old
> > behavior
> > 
> > 7) Tooling and framework changes on background are unimportant to end users.
> 
> This is a very good summary of my opinion as well. Thanks, Vit!

Is the command line tool for DNF version 5 called /usr/bin/dnf?  Or
will users have to learn to use "dnf5 install ..." etc?  If the
latter, I think it is a bad idea.  Each time a new version of "ls"
comes out, they don't append a new digit to the command.  Users
shouldn't have to learn a new command name just to upgrade to a new
major version of a command.  If the syntax and functionality is
substantially the same, then the command name should remain the same.

If the UX (user experience) is sustantially changed such that a user
would have to learn a completely new syntax in order to use it, then
perhaps it would be better to rename the whole product/command to
something other than DNF.  For example, when we moved from
initscripts/service/chkconfig to systemd, the syntax changed enough
that it made sense to have a new command "systemctl" to replace the
previous commands "chkconfig" and "service".

As for the RPM package name, that is less important because it doesn't
really affect the UX much.  Guidance here should be taken from the
packaging guidelines.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple

Examples:

The python-sqlalchemy package occasionally has multiple versions
in Fedora for backwards compatibility. The most current version of
python-sqlalchemy is named python-sqlalchemy and an older
supported version is python-sqlalchemy0.5. No delimiter is used in
this situation.

This seems to suggest that the package name should be "dnf" for the
latest version and "dnf4" for the previous version.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Chuck Anderson]

On Mon, Dec 05, 2022 at 01:28:28PM +0100, Emmanuel Seyman wrote:
> * Miro Hrončok [05/12/2022 12:36] :
> >
> > perl-App-PFT  orphan   1 weeks 
> > ago
> > perl-File-KeePass cra, echevemaster, orphan,   0 weeks 
> > ago
> >   xavierb
> > perl-HTTP-Server-Simple-Authenorphan   1 weeks 
> > ago
> > perl-Library-CallNumber-LCorphan   1 weeks 
> > ago
> > perl-PFT  orphan   1 weeks 
> > ago
> > perl-Pod-PseudoPodorphan   1 weeks 
> > ago
> > perl-Pod-PseudoPod-LaTeX  orphan   1 weeks 
> > ago
> > perl-Proc-PID-Fileorphan   1 weeks 
> > ago
> > perl-WWW-xkcd orphan   0 weeks 
> > ago
> 
> I have taken the above packages.

Emmanuel,

Would you lke to take perl-Term-ShellUI as well?  It is a dependency
of kpcli which requires perl-File-KeePass.  Otherwise I'm happy to
take it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Chuck Anderson]

On Wed, Oct 12, 2022 at 10:47:07AM -0400, Stephen Smoogen wrote:
> On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming  wrote:
> 
> > On 10/12/22 08:59, Stephen Smoogen wrote:
> > > Maybe call it the Fedora Update Manager 'FUM' ?
> >
> > Unless we're going to call it RUM when it makes its way into RHEL, that
> > name may not be the best choice :-)
> >
> >
> Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am
> sure they can go with FUM or RUM (RPM Update Manager).. I would avoid
> Backup Upgrade Manager though.

How about PUM, Package Update Manager?  Pa rum pum pum pum...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 Change Proposal: libsoup 3: Part One (System-Wide Change)

[Chuck Anderson]

On Wed, Jun 29, 2022 at 11:49:51PM +0530, Vipul Siddharth wrote:
> Fedora 37 as a compatibility library. Because libsoup is a sensitive
> network-facing HTTP library written in an unsafe language and where
> CVEs may have disastrous impact, it is not safe to leave libsoup 2
> hanging around indefinitely, but we are not yet ready to remove it
> altogether. We will propose removing libsoup 2 (and all applications
> and libraries that still depend on it) for Fedora 39 in a separate
> change proposal.

Why are we using a "network-facing HTTP library written in an unsafe
language"?  Shouldn't we take this opportunity to move to a safer HTTP
library?  Or is libsoup 3 safe(r) than libsoup 2?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: nfs4-acl-tools

[Chuck Anderson]

On Thu, Jun 23, 2022 at 09:53:40AM -0400, Steve Dickson wrote:
> I just took over the maintership of nfs4-acl-tools
> and it appears the command has not been part
> of Fedora since f32.
> 
> Granted there has not been any upstream activity
> until now, but is there a way to get back into,
> at least, rawhide?

What do you mean "not part of fedora"?  I see builds from f35 which
should be inherited into f36 and rawhide.

https://mirrors.rit.edu/fedora/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/n/nfs4-acl-tools-0.3.5-6.fc35.x86_64.rpm

Could you not just submit a new build for rawhide?  I see someone tried but the 
build failed:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1889804
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Non-responsive maintainer check for snirkel

[Chuck Anderson]

As per: 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

Does anyone know how to reach Linux Walleij (snirkel)?  This bug and
pull request opened two years ago is still not addressed:

https://bugzilla.redhat.com/show_bug.cgi?id=1800905
https://src.fedoraproject.org/rpms/libbinio/pull-request/1

(libbinio: update to fix off-by-one error in binisstream, libbinio fails to use 
memoryobjects)

Other stale bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1989761 (libmtp: FC34 stopped 
showing files and folders on my Android tablet)
https://bugzilla.redhat.com/show_bug.cgi?id=1971318 (libmtp: Galaxy Samsung 
Android can not be mounted)

Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: List of long term FTBFS packages to be retired tomorrow

[Chuck Anderson]

On Tue, Mar 01, 2022 at 07:45:26PM +0100, Miro Hrončok wrote:
> And just for the record, this is the current list of packages that FTBFS at 
> least since Fedora 35:
> 
> perl-Crypt-PWSafe3
>
> If they continue to fail, they will be included in my report in ~5 months.

Upstream has fixed the issue and I have built and pushed updates for this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers

[Chuck Anderson]

On Wed, Jul 07, 2021 at 11:18:04AM +0200, Miro Hrončok wrote:
> cra: guile22

I'm not listed as a (co)maintainer, so I'm not sure how I ended up on
this list.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: "Fedora Linux" in /etc/os-release

[Chuck Anderson]

On Wed, Mar 10, 2021 at 01:26:55PM +0100, Björn Persson wrote:
> If we're going to name the distribution after some of its components,
> why stop at one or two?
...

> It's better to give the whole distribution its own name, and not name
> it after any of its components. Fedora is a software distribution. It
> contains Linux, many GNU components, RPM, MariaDB, Libreoffice and lots
> of other things, but its name is "Fedora". Or call it "Fedora Software
> Distribution" or anything else that doesn't single out any of the
> components. That approach seems to minimize the political fighting.

FreeBSD is just FreeBSD and BSD stands for Berkeley Software Distribution.

Maybe we should use Fedora Software Distribution.  But I rather like
just plain "Fedora".


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: "Fedora Linux" in /etc/os-release

[Chuck Anderson]

On Wed, Mar 10, 2021 at 07:21:44PM -, Reon Beon via devel wrote:
> uname -a
> 
> Linux fedora 5.12.0-0.rc2.165.fc35.x86_64 #1 SMP Sat Mar 6 16:32:15 UTC 2021 
> x86_64 x86_64 x86_64 GNU/Linux
> 
> Shouldn't fedora be capitalized?

No.  The 2nd word of the output of "uname -a" is the nodename
(hostname), so it just outputs the value of the system's hostname
there.  See also "uname -n".  Hostnames are traditionally all
lowercase, but if you want to change it feel free:

hostnamectl set-hostname Fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: git push on master branch rejected.

[Chuck Anderson]

On Mon, Feb 22, 2021 at 09:39:55AM -0500, Steve Dickson wrote:
> > Well it appears this is still the problem
> > 
> > origin/rawhide/user/steved/pnfs-rawhide
> > origin/rawhide_old/user/steved/pnfs-rawhide
> Never mind... I just had to recreate the git tree... thanks again!

https://xkcd.com/1597/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What is the most time consuming task for you as packager?

[Chuck Anderson]

On Tue, Dec 15, 2020 at 11:29:27PM +0100, Miroslav Suchý wrote:
> I am looking for challenges for upcoming year - what I and my team should 
> enhance. I have some ideas, but I want to hear
> yours.
> 
> What you - as Fedora packager - find most time consuming on packaging?
> Where you will welcome more simplicity or automation?

Looking up the latest guidelines and recommendations for packaging.
It seems to be spread between the Wiki and "docs" site and it isn't
always clear which one is correct.  Google searches may still find old
or "draft" guidelines.  Not all are ported over to docs.fp.org, so you
have to use the Wiki site for some content.  Wiki documents link to
themselves, even when in some cases the Wiki version is out of date,
replaced by docs.fp.org version.  There isn't always a warning or
reminder that links to the correct version on docs.fp.org.  Or there
is a redirect to the new site, but it doesn't link to the right
content.

https://fedoraproject.org/wiki/Packaging:Guidelines

"The packaging guidelines have been moved out of the wiki. The current
version of this document is located at
https://docs.fedoraproject.org/en-US/packaging-guidelines/ . Please
update your bookmarks."

But say I search Google for "fedora perl packaging guidelines" I find this:

https://fedoraproject.org/wiki/Packaging:Perl

Then there is a link on there to:

https://fedoraproject.org/wiki/Category:Packaging_guidelines

Or search Google for "fedora packaging systemctl" finds this:

https://fedoraproject.org/wiki/Packaging:Systemd

which has:

 Unit files in spec file scriptlets

Information on proper handling of unit files in spec file scriptlets can be 
found here: Packaging:Scriptlets#Systemd

but that links to:

https://fedoraproject.org/wiki/Packaging:Scriptlets#Systemd

which redirects to:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#Systemd

which doesn't have a #Systemd anchor.  So you are dumped at the top of
that page rather than at the section about Systemd which has an anchor
of #_systemd instead.

It would be nice if this could all be cleaned up, because right now it
makes navigating the documentation a nightmare.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unable to disable SysRq

[Chuck Anderson]

On Tue, Nov 17, 2020 at 01:10:02PM +0100, Kevin Kofler via devel wrote:
> Robert Marcano via devel wrote:
> > Two times in a week I have killed all processes trying to use Alt+i. Ts
> > is to easy to press the Alt and the PrtScr at the same, starting that
> > way the SysRq i command.
> > 
> > So before staring to write a kernel patch to add an option where the
> > SysRq is only triggered by the Left Alt key. I decided to initially
> > disable sysrq entirely.
> [followed by technical details of why that failed]
> 
> This is funny because SysRq is supposed to be disabled by default in Fedora 
> to begin with, for security reasons.

According to https://fedoraproject.org/wiki/QA/Sysrq

16 - enable sync command

64 - enable signalling of processes (term, kill, oom-kill)

80 = 16+64 and enables both of the above.

Sync seems safe to always leave enabled.  Killing processes probably not.

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

Re: patch applied without package maintainers' approve

[Chuck Anderson]

On Mon, Nov 09, 2020 at 09:02:12PM +0800, Honggang LI wrote:
> The patch maybe useful or fix something. But the divergence between
> upstream and Fedora rawhide is what I don't want to see, because
> such divergence is source of regression issues.

https://src.fedoraproject.org/rpms/rdma-core/c/59a8e2e0d0ddba785fc79c4731e0b8685893458b?branch=master

It only changes how the software is packaged in Fedora, by making a
separate libibverbs RPM package that can be installed separately from
rdma-core.  There is nothing to upstream since this is purely an RPM
build change.

> What I should to do with that commit? Just blindly revert it?

It seems useful to keep the change for minimizing unnecessary
dependencies by consumers of the libibverbs library (such as the
libpcap package mentioned in the commit).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging rules for build from source vs BPF byte code ?

[Chuck Anderson]

On Thu, Nov 05, 2020 at 12:03:43PM +, Daniel P. Berrangé wrote:
> Given that dpdk is not providing any build process for going from
> tap_bpf_program.c to tap_bpf_insns.h, it looks to me like the upstream
> project effectively considers  "tap_bpf_insns.h" to be their preferred
> source form, and  tap_bpf_program.c as just a reference for its
> original creation.
> 
> IOW, to me it looks like this embedded BPF program shouldn't be
> considered a binary from Fedora POV and can be used as is.

One example of a package doing something incorreclty doesn't mean it
is okay to continue that practice.  I'd argue thet dpdk needs to be
fixed to provide the original source code and build scripts for the
BPF program.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

[Chuck Anderson]

On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote:
> With enterprise server deployments, DNS will be managed by the network
> via resolve.conf to enterprise DNS servers. These servers tend to have
> "bind views" for different category of deployments. These deployments
> will have no VPN, no mDNS requirements etc. They also do not need (and
> most likely do not want) DNS caching.

I think all enterprise servers can benefit from having a local DNS
server, whether that server caches or not, because that is the best
way to fix/work around the broken C APIs for name resolution that
doesn't handle DNS server failover very well.

That doesn't mean I'm against splitting out systemd-resolved into a
separate package, though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Chuck Anderson]

On Mon, Sep 28, 2020 at 03:51:51PM -0500, Michael Catanzaro wrote:
> That's still the case. All this discussion about split DNS is only 
> relevant to the case where the user checks the box "use this connection 
> only for resources on its network" (or imports a VPN profile that 
> selects that automatically). By default, it's not checked, nothing is 
> split, all DNS and routing goes to the VPN.

I think the VPN plugin and VPN server has some input, no?  All the VPN
servers I've used send routes to the VPN client to determine which
traffic the client should send via the VPN.  How does that interact
with "use this connection only for resources on its network"?  Does
the user preference take precendence over the VPN server-provided
routes?  What if the VPN server doesn't send any route other than
0.0.0.0/0?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Chuck Anderson]

On Mon, Sep 28, 2020 at 05:26:50PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 28, 2020 at 01:14:14PM -0400, Robbie Harwood wrote:
> > Zbigniew Jędrzejewski-Szmek  writes:
> > 
> > > Pfff, now I'm confused. Here is a case where systemd-resolved
> > > implements the standard, and some people were unhappy because they
> > > were relying on sloppy implementations which don't follow the RFC.
> > 
> > Yes, welcome to software development!
> > 
> > Sometimes people care about the standard and sometimes the standard
> > isn't helpful.  You can bemoan it, or belittle the users as you are
> > doing here, but *that's how it is*.
> 
> I agree, but I was replying to a mail which said that systemd-resolved does
> not follow the standard. In *this* particular case, that complaint is off
> target.

How is systemd-resolved compliant with this requirement of RFC 3397 section 4:

 [2]   Resolve a name that contains any dots by first trying it as an
   FQDN and if that fails, with the local domain name (or
   searchlist if specified) appended.

when it does not resolve "dk." via DNS?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Chuck Anderson]

On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > * Andrew Lutomirski:
> > 
> > > Paul may well have been mixing different things here, but I don't
> > > think you answered the one that seems like the most severe problem:
> > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > supplied by the upstream server.  One might reasonably debate whether
> > > Fedora's default DNS resolver configuration should validate DNSSEC,
> > > but I think it should honor the DO bit in client requests and return
> > > DNSSEC data.
> > 
> > FWIW, this is .
> 
> In an ideal world, we would just implement this missing functionality.
> It's definitely on the TODO list, and there has been some preparatory
> work done, but so far nobody found the time. If this is judged necessary,
> we'll raise the priority of that work. Nevertheless, I don't think it is
> such high priority — the number of people using DNSSEC is not too large,
> and they are generally power-users who understand how to specify a different
> server. So while definitely annoying, I didn't consider this a deal-breaker.

DNSSEC is not meant for power-users, and it doesn't require specifying
"a different server".

I thought Fedora was supposed to be First?  How can it be if Fedora
chooses to use/configure software by default that is missing critical
DNSSEC functionality and breaks DNS standards?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: paranoid md raid1 -> Btrfs migration tools?

[Chuck Anderson]

On Mon, Sep 28, 2020 at 03:07:39PM +0200, Daniel Pocock wrote:
> 5. you can now use
> 
>  rsync --dry-run /mnt/sda1_non_raid /mnt/btrfs_new
> 
> to see if every file on the sda1 side of the mirror matches what was
> copied to Btrfs

Add --checksum to the rsync invocation.  Otherwise, rsync relies on
modified timestamp and file size only to determine whether to sync
files.  --checksum will actually run a checksum on the source and
destination files to determine if they are different.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Chuck Anderson]

On Wed, Jul 01, 2020 at 04:25:31PM +0200, Nicolas Mailhot via devel wrote:
> Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek
> a écrit :
> > 
> > Actually that part has been answered pretty comprehensively. The
> > split between / and /home is hurting users 
> 
> Actually this split is a godsend because you can convince anaconda to
> leave your home alone when reinstalling, while someone always seems too
> invent a new Fedora change that justifies the reformatting of /.
> 
> Good luck dealing with user data the next time workstation (or any
> other group) feels the / filesystem should change, once you've put user
> data on the same mount point

The whole point of the btrfs change is to keep / and /home on separate 
subvolumes to avoid the anaconda requirement to reformat / from affecting /home 
while also avoiding the problem of running out of space on one while still 
having tons of free space on the other.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Chuck Anderson]

On Sat, Jun 27, 2020 at 08:06:26PM -0600, Chris Murphy wrote:
> Just a PSA: btrfs raid1 does not have a concept of automatic degraded
> mount in the face of a device failure. By default systemd will not
> even attempt to mount it if devices are missing. And it's not advised
> to use 'degraded' mount option in fstab. If you do need to mount
> degraded and later the missing device is found (?) you need to scrub
> to catch up the formerly missing device to the current state.

An alternative to raid1 might be lsyncd (Live Syncing Daemon).  I use
it to sync my single SSD to a HDD in near-real-time, because doing
raid1 with devices that have different performance characteristics
does not work well (the slower device slows down all writes, even when
using write-behind modes of mdraid).

Or maybe even btrfs send/receive between two separate btrfs
filesystems on the two disks?  I have no experience with that (or
btrfs at all really).

I'm cautiously optimistic and would like to see btrfs adopted as the
default due to the huge benefit to having data integrity features (I
run FreeNAS at home for that reason), but I'm honestly a bit scared
off by some of the recent comments in this thread.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

review requests/intent to unretire kpcli requirements perl-Crypt-ECB and perl-Crypt-PWSafe3

[Chuck Anderson]

I'm in the process of unretiring perl-crypt-ECB and perl-Crypt-PWSafe3 that are 
requirements of kpcli.

I could use some help with reviews:

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1835258
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1835263

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

Re: Random *** stack smashing detected *** message

[Chuck Anderson]

On Wed, Sep 05, 2018 at 06:04:27PM +0100, Richard W.M. Jones wrote:
> On Wed, Sep 05, 2018 at 06:40:47PM +0200, Mark Wielaard wrote:
> > We don't know the exact release version, but given the build-id
> > [0aea4b30d53d7cc6386f1773a8dc8972793def1a] we should be able to
> > match it against an older glibc package.
> 
> Here are all the versions of glibc installed on that machine as far
> back as the DNF logs go (which is only a couple of months
> unfortunately):
> 
> 2.26.9000-41.fc28
> 2.26.9000-48.fc28
> 2.27.9000-28.fc29
> 2.27.9000-35.fc29
> 2.28-6.fc29
> 2.28.9000-4.fc30
> 2.28-9.fc29
> 
> Of those only 2.27.9000-35.fc29 contains the build ID.
> 
> That's the glibc-debuginfo that I already have installed (I realize
> now why my previous email was wrong - the file is called
> /usr/lib/debug/.build-id/0a/ea4b30d53d7cc6386f1773a8dc8972793def1a).
> 
> However it still can't find a symbol matching the address, so I guess
> we're out of luck.

Do you have both these:

glibc-debuginfo.x86_64
glibc-debuginfo-common.x86_64
___
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: [CoreOS] Re: Starting a Container SIG

[Chuck Anderson]

Doesn't HyperKitty provide the forum experience integrated with the traditional 
mailing list?

On Tue, Jul 31, 2018 at 12:37:50PM +0100, Sanja Bonic wrote:
> For search and threaded visibility, it would be useful to have these
> discussions happen on the forums (created a category, let's see if we use
> it: https://discussion.fedoraproject.org/c/containers) and then be put into
> the issue tracker on Pagure where applicable.
> 
> Since both Pagure and Discourse work with FAS, noone needs to create any
> extra accounts. I'm up for it, let's see what we end up using. If we do
> want some engagement within Fedora from outside the world of people who
> know how to handle mailing lists, this is a good way to start. I have to
> just remind everyone here that there are plenty of smart people willing to
> get started with open source who have no experience with mailing lists and
> IRC, where a forum with usability and structure really provides some
> initial help that shouldn't be underestimated.
> 
> On Tue, Jul 31, 2018 at 10:59 AM, Matthew Miller 
> wrote:
> 
> > On Wed, Jul 25, 2018 at 07:09:39PM +0200, Clement Verna wrote:
> > > Container story great in Fedora. If there is a good response, I will
> > > create a Container SIG wiki page, and I guess we can ask for
> > > container-devel mailing list for SIG discussions.
> >
> > What about trying https://discussion.fedoraproject.org/ for discussions
> > instead of a new mailing list?
___
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/message/HAFFCI74D2LMC2HI5YBNHLKKJII5FVA5/

Re: Hiding the grub menu by default on single OS installs

[Chuck Anderson]

On Thu, May 31, 2018 at 12:09:45PM -0500, Chris Adams wrote:
> Once upon a time, Hans de Goede  said:
> > On 31-05-18 15:08, Chris Adams wrote:
> > >Once upon a time, Hans de Goede  said:
> > >>And for F30, single OS install we get:
> > >>
> > >>1) grub menu not shown, 0 second timeout, no way to get to the menu
> > >>2) grub menu shown with 5 sec timeout after a failed boot
> > >
> > >If I know I want the menu (say I need to boot single-user to fix
> > >something), how would I do that in this setup?
> > 
> > Hopefully what ever you want to fix will count as a "failed boot"
> > if it requires single user mode.
> 
> Hmm... not really.  For example (just off the top of my head): lost root
> password.  Without it, you won't be able to set any "next boot is
> special" option, so resetting root's password would now require rescue
> media.
> 
> I'd say I'm against this part of your proposal.  I understand the
> reasoning, but it just seems like too much restriction to shave off a
> small amount of time.  You mentioned it "could take several seconds" for
> EFI to initialize USB, but what is the normal time, for a typical
> desktop or notebook with just a keyboard and mouse attached?

I agree.  Another use case is that failed graphics initialization may
not count as "failed boot". 
___
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/message/CWA5Z3IYQQURAIFFNNCLE5TXXSGXRC5E/

Re: DNSSEC, DoH, dnscrypt-proxy 1 vs 2

[Chuck Anderson]

On Mon, Apr 09, 2018 at 10:54:10AM +0200, Matthias Runge wrote:
> On Mon, Apr 09, 2018 at 10:01:21AM +0200, Martin Sehnoutka wrote:
> > > Restarted Firefox and then also the whole laptop. Doesn't work. But
> > > then I'm in Fedora 28 so it may be a bug. Anyway, getting this to work
> > > for me isn't really the point of the thread. I'm wondering about
> > > something that works out of the box for everyone, what that looks
> > > like, and it seems like dnscrypt-proxy 2 can support either DNSSEC or
> > > DNS-over-HTTP.
> > 
> > I've been playing with dnssec-trigger for a while and I would not enable
> > it by default. If you have a single connection with ISP provided
> > resolvers or public DNS, it is fine, but it gets harder to configure
> > when you have multiple connections like Wi-Fi and corporate or
> > university VPNs where each provides some forward zones and needs reverse
> > zones for correct behavior.
> 
> Same here, I' cusious if anyone has been able to get it working
> properly? In best case, has someone written about it?

It works fine for me on multiple desktops 99% of the time.  The bug with the 
latest update was the first time in a long time that I've had issues.

With laptops, you are more likely to run into issues, but even there I keep it 
enabled most of the time, knowing that I can disable it if I run into an issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNSSEC, DoH, dnscrypt-proxy 1 vs 2

[Chuck Anderson]

On Sun, Apr 08, 2018 at 04:41:34PM -0600, Chris Murphy wrote:
> On Sun, Apr 8, 2018 at 3:52 PM,   wrote:
> >
> > There was also
> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver which was
> > proposed for F22, but deferred twice and eventually dropped.
> 
> I followed the multistep instructions there, and this also breaks everything.
> 
> Apr 08 16:38:21 f28h.local unbound[5065]: [5065:0] error: .: failed
> lookup, cannot transfer from master k.root-servers.net

That looks like this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1560223
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Notifications app is incomprehensible

[Chuck Anderson]

Is there a training video to explain how to use Fedora Notifications?
It is utterly incomprehensible and uses "cute" phrases like "Party
Perished" and "tabula rasa" that fail to help the user understand how
to use it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Chuck Anderson]

On Thu, Mar 15, 2018 at 04:19:46PM +, Daniel P. Berrangé wrote:
> On Thu, Mar 15, 2018 at 04:14:34PM +0100, Patrick Uiterwijk wrote:
> > For user consumption, they are Name:Stream:Version:Context, so you may
> > need to manually convert between one representation and the other if
> > you need to look up in koji or other systems versus display to users.
> 
> What stops us using Name:Stream:Version:Context everywhere,
> or  Name:Stream:Context-Version or Name:Stream-Version-Context
> if we need it closer to RPM NVR style ?

: doesn't work very well in filenames due to it being a pathname separator in 
some filesystems among other things.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: On Ye Olde Foreste of Anciente LLVM Versiones

[Chuck Anderson]

On Thu, Mar 08, 2018 at 04:06:33PM -0800, Adam Williamson wrote:
> On Thu, 2018-03-08 at 17:23 -0600, Yaakov Selkowitz wrote:
> > 
> > > llvm3.9
> > 
> > Still required by julia[1].
> 
> "The Julia Language: A fresh approach to technical computing."
> 
> But not *too* fresh, apparently. ;)

Technical Computing, as in Fortran 90?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Chuck Anderson]

On Sun, Feb 18, 2018 at 06:09:40PM +0100, Igor Gnatenko wrote:
> https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt

These are fixed: flac123 fping fxload ocp perl-HTML-Strip sedutil

I retired msed because sedutil replaced it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: can't push to perl-HTML-Strip master

[Chuck Anderson]

On Sun, Feb 18, 2018 at 05:14:11PM -0800, Kevin Fenzi wrote:
> On 02/18/2018 04:29 PM, Chuck Anderson wrote:
> > Can someone please help me with this?  I'm listed as an admin on 
> > src.fedoraproject.org for perl-HTML-Strip, but I still cannot commit to 
> > master:
> > 
> >> fedpkg push
> > Enter passphrase for key '/home/cra/.ssh/fedora_rsa': 
> > X11 forwarding request failed on channel 0
> > Counting objects: 6, done.
> > Delta compression using up to 8 threads.
> > Compressing objects: 100% (6/6), done.
> > Writing objects: 100% (6/6), 846 bytes | 846.00 KiB/s, done.
> > Total 6 (delta 2), reused 0 (delta 0)
> > ^[[B^[[B^[[Bremote: FATAL: W refs/heads/master rpms/perl-HTML-Strip cra 
> > DENIED by fallthru
> > remote: error: hook declined to update refs/heads/master
> > To ssh://pkgs.fedoraproject.org/rpms/perl-HTML-Strip
> >  ! [remote rejected] master -> master (hook declined)
> > error: failed to push some refs to 
> > 'ssh://c...@pkgs.fedoraproject.org/rpms/perl-HTML-Strip'
> > Could not execute push: Command '['git', 'push']' returned non-zero exit 
> > status 1
> 
> Try now? I've regenerated the acls for that package and they look
> correct now.

Works now.  Thanks.

> Note: for things like you a releng or infrastructure ticket is the usual
> way to get them looked at.

Okay, will do.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

can't push to perl-HTML-Strip master

[Chuck Anderson]

Can someone please help me with this?  I'm listed as an admin on 
src.fedoraproject.org for perl-HTML-Strip, but I still cannot commit to master:

>fedpkg push
Enter passphrase for key '/home/cra/.ssh/fedora_rsa': 
X11 forwarding request failed on channel 0
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 846 bytes | 846.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
^[[B^[[B^[[Bremote: FATAL: W refs/heads/master rpms/perl-HTML-Strip cra DENIED 
by fallthru
remote: error: hook declined to update refs/heads/master
To ssh://pkgs.fedoraproject.org/rpms/perl-HTML-Strip
 ! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 
'ssh://c...@pkgs.fedoraproject.org/rpms/perl-HTML-Strip'
Could not execute push: Command '['git', 'push']' returned non-zero exit status 
1

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

Re: Removal of BuildRoot

[Chuck Anderson]

On Tue, Feb 13, 2018 at 11:05:28PM +0100, Igor Gnatenko wrote:
> Just a small heads up, BuildRoot tag is not needed since RHEL6 (which is 
> oldest
> supported one nowadays, it's been year or so after EL5 retirement). And we
> don't support EL5 anymore, so...
> 
> I wanted to send this heads up before I actually did that, but I hit "enter"
> button too early.
> 
> Anyway, this is straitghtforward change, so no one should notice anything
> (apart from one commit with, hopefully, useful description in their
> repositories) 
> -- 
> -Igor Gnatenko

FWIW, I support your efforts with this, so thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Rename "nobody" user

[Chuck Anderson]

On Thu, Jan 11, 2018 at 11:24:56PM +0100, Lennart Poettering wrote:
> I hope you are aware that user id 65534 is used by user namespacing
> (i.e. CLONE_NEWUSER) too, and in that context is probably much more
> prominently visible to users than in the NFS context. The fact that
> the user/group is called "nfsnobody" is quite misleading if most users
> see it only in the user namespacing context which has zero
> relationship to NFS.

Is there any security implication of re-using 65534 for user
namespacing, since NFS was using it before?  Why not assign a new uid
for user namespacing?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

linux-firmware, microcode_ctl, libvirt, qemu updates?

[Chuck Anderson]

Red Hat has released linux-firmware, microcode_ctl, libvirt, and qemu
updates in addition to the kernel updates to mitigate against Meltdown
and Spectre.  Is anyone working on those updates for Fedora?  Is there
anything I can do to help with those?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: no updates since Monday

[Chuck Anderson]

On Fri, Dec 08, 2017 at 09:25:05AM -0500, Chuck Anderson wrote:
> Does anyone know why there have been no updates or changes to any of
> the Fedora repos (including rawhide) since Monday?

Darn, I just found the announcement about the data center move.  Never mind...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

no updates since Monday

[Chuck Anderson]

Does anyone know why there have been no updates or changes to any of
the Fedora repos (including rawhide) since Monday?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upgrade failed

[Chuck Anderson]

On Sat, Sep 30, 2017 at 09:08:45AM -0700, Howard Howell wrote:
> On Sat, 2017-09-30 at 02:51 +0200, Reindl Harald wrote:
> > 
> > Am 30.09.2017 um 01:53 schrieb Howard Howell:
> > > installing package ncurses-libs-6.0-8.20170212.fc26.i686 needs
> > > 22458368
> > > on the / filesystem
> > > installing package json-c-0.12.1-2.fc26.i686 needs 21594112 on the
> > > /
> > > filesystem
> > 
> > well, don't mess up your system until your disk is full and that is 
> > hardly a "development topic"
> I didn't mess up my system, I don't put stuff in /.  If a set of
> software is putting stuff in /, that needs to be paid attention, and
> corrected in the chain.

PackageKit fills up /var/cache/PackageKit with downloaded packages.
If you always use dnf and not the graphical updater, it will never get
deleted and the system will crash when / runs out of space.  The
upgrade itself also uses space to download everything.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: f26 branch?

[Chuck Anderson]

On Tue, Aug 29, 2017 at 12:03:16PM -0500, Michael Cronenworth wrote:
> On 08/29/2017 11:48 AM, Chuck Anderson wrote:
> >zoneminder]>fedpkg switch-branch f26
> >Could not execute switch_branch: Unknown remote branch origin/f26
> 
> You've declared this package retired. There won't be one.

Okay, that is good to know.  But strange that I have an f27 branch.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: f26 branch?

[Chuck Anderson]

On Tue, Aug 29, 2017 at 11:43:13AM -0500, Michael Cronenworth wrote:
> On 08/29/2017 11:00 AM, Chuck Anderson wrote:
> >My packages git checkouts have f25, f27, and master branches.  Are
> >they supposed to have an f26 brach too?  This page suggests they are:
> >
> >https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb
> 
> How are you checking? git branch? Those are local-only branches.
> Issue `git branch -a` to view all branches.
> 
> git checkout f26
> 
> Then you will get the upstream, remote git branch f26.

zoneminder]>fedpkg switch-branch f26
Could not execute switch_branch: Unknown remote branch origin/f26

zoneminder]>git branch 
  f25
  f27
* master

zoneminder]>git branch -a
  f25
  f27
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/f10
  remotes/origin/f11
  remotes/origin/f12
  remotes/origin/f13
  remotes/origin/f14
  remotes/origin/f15
  remotes/origin/f16
  remotes/origin/f17
  remotes/origin/f18
  remotes/origin/f19
  remotes/origin/f20
  remotes/origin/f21
  remotes/origin/f22
  remotes/origin/f23
  remotes/origin/f24
  remotes/origin/f25
  remotes/origin/f27
  remotes/origin/f7
  remotes/origin/f8
  remotes/origin/f9
  remotes/origin/fc6
  remotes/origin/master

zoneminder]>git checkout f26   error: pathspec 'f26' did not match any file(s) 
known to git.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

f26 branch?

[Chuck Anderson]

My packages git checkouts have f25, f27, and master branches.  Are
they supposed to have an f26 brach too?  This page suggests they are:

https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Chuck Anderson]

On Wed, Jul 12, 2017 at 10:27:06AM +0200, Guido Aulisi wrote:
> I'm still using some old 32 bit physical servers with Fedora, and they
> still work well!
> So I would like to have a 32 bit kernel for some other releases, maybe
> f28 if possible.

Maybe you could keep the F26 kernel and try running it with F27 and F28.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Deprecated net-tools? Mass bug filing?

[Chuck Anderson]

On Wed, May 17, 2017 at 09:16:27PM +0100, Athmane Madjoudj wrote:
> On Wed, May 17, 2017 at 6:47 PM, Chuck Anderson <c...@wpi.edu> wrote:
> > I don't mind removing dependencies on net-tools, as long as there
> > still exists these commands in the default install:
> >
> > netstat
> > arp
> > ifconfig
> > route
> 
> AFAIK, busybox (as configured in Fedora) has some of those commands,
> eg: busybox ifconfig
> 
> It can call the right command when symlinked.

Thanks.  That could be a viable option if net-tools is somehow
undesireable compared to busybox, but it depends on what we are trying
to accomplish.

- Package sizes are below 1MB in both cases.

- Busybox has no requires, but net-tools only requires glibc

- Maybe Busybox's tools are better maintained than old net-tools?

# dnf repoquery --requires busybox
Last metadata expiration check: 2:05:44 ago on Wed May 17 14:32:39 2017.

# dnf repoquery --requires net-tools
Last metadata expiration check: 2:05:46 ago on Wed May 17 14:32:39 2017.
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libselinux.so.1()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Deprecated net-tools? Mass bug filing?

[Chuck Anderson]

On Wed, May 17, 2017 at 07:04:46PM +0100, Sérgio Basto wrote:
> On Wed, 2017-05-17 at 13:47 -0400, Chuck Anderson wrote:
> > Here is a list of binary commands in net-tools:
> > 
> > /usr/bin/netstat
> > /usr/sbin/arp
> > /usr/sbin/ether-wake
> > /usr/sbin/ifconfig
> > /usr/sbin/ipmaddr
> > /usr/sbin/iptunnel
> > /usr/sbin/mii-diag
> > /usr/sbin/mii-tool
> > /usr/sbin/nameif
> > /usr/sbin/plipconfig
> > /usr/sbin/route
> > /usr/sbin/slattach
> > 
> > I don't mind removing dependencies on net-tools, as long as there
> > still exists these commands in the default install:
> > 
> > netstat
> > arp
> > ifconfig
> > route
> > 
> > I consider those to be a basic part of the user interface of any
> > Linux/UNIX system--there is too much historical precedent and
> > documentation to remove them IMO.  It would be like trying to remove
> > "ls" just because there is a newer/better way to list files.
> 
> I generally agree , but what are the replacement ?  that is "the"
> important information .

The important detail is that a user should be able to type the same
commands that have worked on almost every Linux/UNIX system for 20+
years to get information about the system.  I think this is most
important for showing the current network status.  It is less imporant
for configuring the network, but some basic changes should still be
possible with the compatible commands.  Here is a list off the top of
my head that we should keep working in a default install:

netstat -r, netstat -i, netstat -a, netstat -l
arp, arp -a, arp -d, arp -s
ifconfig, ifconfig -a, ifconfig up/down
route -a, route add/del (at least for default gateway)

Heck, many of those even work on Windows.  It would be a shame to lose
this basic level of compatibility across so many types of systems that
has been there for so long.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Deprecated net-tools? Mass bug filing?

[Chuck Anderson]

On Wed, May 17, 2017 at 06:33:53PM +0100, James Hogarth wrote:
> On 17 May 2017 4:35 pm, "Peter Robinson"  wrote:
> 
> On Wed, May 17, 2017 at 3:48 PM, Matthew Miller
>  wrote:
> > On Wed, May 17, 2017 at 09:15:51AM +0100, James Hogarth wrote:
> >> On 17 May 2017 at 08:46, Daniel P. Berrange  wrote:
> >> > Converting apps from nettools to iproute is often non-trivial piece
> >> > of work. As such isn't really something Fedora package maintainers
> >> > should look to undertake as the risk of introducing regressions is
> >> > non-negligible.  Bug reports really need to go the corresponding
> >> > upstream communities to get anything done.
> >> >
> >>
> >> That's a sensible position and one I can respect. I do wonder how much
> >> is upstream and how much is a result of packaging though, that itself
> >> might be an interesting investigation.
> >
> > I think this might be something that rises to the level of a
> > Change ("Officially Deprecate net-tools in Fedora"), and while working
> > with upstreams is going to be necessary, I think having a Fedora
> > tracker could be useful, if you're interested in putting in that
> > effort.
> 
> Yes, there was already an effort to do this 6 years ago [1] which got
> some of the way there. I don't think the package itself will go away
> any time soon but it would be good to not need it in the core
> distribution. For a while we actually managed to do that but it's
> crept back in over time. I think a focus on getting things like
> cloud-init, vpnc-script, pki-server and similar packages that ship in
> core deliverables would be a good start.
> 
> >> At the very least it may be worth checking for upstream bugs, filing
> >> them where they don't exist, and then filing a bugzilla (even with a
> >> tracking bug perhaps? Is this something for FPC to discuss maybe?)
> >> ticket linked to the upstream.
> >
> > Probably FESCo rather than FPC, unless we're going to ban depending on
> > net-tools or something like that.
> 
> Yes, it would definitely be FESCo over FPC IMO
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=687920
> 
> 
> 
> 
> Well I'm ready to put my virtual money where my virtual mouth is :)
> 
> In the next couple of weeks I'll get the ticket and tracking bug in place
> with bugs on the relevant packages linked to it.
> 
> If FESCo think it needs a Change as well I'll get that in place.
> 
> We may not get all the way... But I think it'd be good to make a start and
> see just how far we can get.
> 
> It was pointed out to me off list that bridge-utils is in a similar
> situation... But I think it's best to focus on just net-tools first and
> then we can take the next step separately when ready.

Here is a list of binary commands in net-tools:

/usr/bin/netstat
/usr/sbin/arp
/usr/sbin/ether-wake
/usr/sbin/ifconfig
/usr/sbin/ipmaddr
/usr/sbin/iptunnel
/usr/sbin/mii-diag
/usr/sbin/mii-tool
/usr/sbin/nameif
/usr/sbin/plipconfig
/usr/sbin/route
/usr/sbin/slattach

I don't mind removing dependencies on net-tools, as long as there
still exists these commands in the default install:

netstat
arp
ifconfig
route

I consider those to be a basic part of the user interface of any
Linux/UNIX system--there is too much historical precedent and
documentation to remove them IMO.  It would be like trying to remove
"ls" just because there is a newer/better way to list files.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: MATE Desktop in EPEL repository

[Chuck Anderson]

You can open bugs against the specific packages in bugzilla.redhat.com
requesting they be updated, but note that having the newest/latest
packages in EPEL is secondary to maintaining stability.  See:

https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy
https://fedoraproject.org/wiki/EPEL_Updates_Policy
https://fedoraproject.org/wiki/Updates_Policy

For requesting new EPEL packages:

https://fedoraproject.org/wiki/Package_maintainers_wishlist
https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL

On Wed, May 17, 2017 at 10:32:22AM +0200, Arnold Fabian1 wrote:
> 
> 
> Dear Team
> 
> I would have a question regarding EPEL repository for RHEL 7.x
> I can see, that the MATE Desktop 1.18 released in 2017-03-13
> but in the EPEL repository, it is not available yet, only the 1.16:
> https://dl.fedoraproject.org/pub/epel/7/x86_64/m/
> 
> 
> Also I would have another question:
> F3 was available in the Rhel6-EPEL repository
> https://dl.fedoraproject.org/pub/epel/6/x86_64/
> But the newest version is not available for us in the Rhel7-EPEL repository
> https://dl.fedoraproject.org/pub/epel/7/x86_64/f/
> 
> About F3, the newest version is 6.0
> http://oss.digirati.com.br/f3/
> 
> 
> Also is there any way to request any other packages via this email address?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: EPEL Steering Committee Meeting Canceled for 2017-04-05

[Chuck Anderson]

On Wed, Apr 05, 2017 at 12:03:14PM -0400, Stephen John Smoogen wrote:
> 2. EPEL-5 has been archived over to /pub/archive/epel/5/
> 3. EPEL-4 has been archived over to /pub/archive/epel/4/

No hardlinks from the regular epel tree to the archive tree?  I guess
it is too late now, but it would have been nice to avoid mirrors
having to re-download everything.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Fedora mass rebuild 2017

[Chuck Anderson]

On Tue, Feb 07, 2017 at 10:32:09PM +0100, Marek Polacek wrote:
> ocp-0.1.22-0.10.git849cc42.fc26.src.rpm
>   These are not ready for a new gcc version (gcc -dumpversion says '7'
>   and not e.g. '6.3.1') and the packages fail to cope with that.

Fixed, thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ZoneMinder retired from Fedora, moving to RPM Fusion.

[Chuck Anderson]

I have now retired zoneminder in master and fixed the depencency bug
for F25.  The zmrepo maintainer has joined Fedora and RPM Fusion and
will be maintaining the package in RPM Fusion.

Review requests and relevent bugs here:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4393
https://bugzilla.redhat.com/show_bug.cgi?id=1409869
https://bugzilla.redhat.com/show_bug.cgi?id=1409866
https://bugzilla.redhat.com/show_bug.cgi?id=1409803
https://bugzilla.redhat.com/show_bug.cgi?id=1409658
https://bugzilla.redhat.com/show_bug.cgi?id=1408872

On Sat, Dec 17, 2016 at 11:27:10PM -0500, Chuck Anderson wrote:
> I have orphaned zoneminder on all branches.
> 
> It has a number of bugs and crash reports in ABRT.  It now has broken
> deps:
> 
> zoneminder has broken dependencies in the rawhide tree:
> On x86_64:
>   zoneminder-1.28.1-6.fc25.x86_64 requires php-mysql
> On armhfp:
>   zoneminder-1.28.1-6.fc25.armv7hl requires php-mysql
> On ppc64le:
>   zoneminder-1.28.1-6.fc25.ppc64le requires php-mysql
> On aarch64:
>   zoneminder-1.28.1-6.fc25.aarch64 requires php-mysql
> On ppc64:
>   zoneminder-1.28.1-6.fc25.ppc64 requires php-mysql
> On i386:
>   zoneminder-1.28.1-6.fc25.i686 requires php-mysql
> Please resolve this as soon as possible.
> 
> I recommend anyone who was using it to instead use the zmrepo version.
> That version can/does use ffmpeg, so it supports more newer cameras.
> 
> If someone really wants this to stay in Fedora and/or EPEL, feel free
> to take it but I recommend starting over with the zmrepo src.rpm.  I
> was able to complete a zmrepo build with the ffmpeg, X10, and vlc
> requirements removed, but there are several missing requirements for
> CPAN modules that would need to be added.  I can provide my
> uncompleted work on this to anyone who is interested.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Orphaning Zoneminder

[Chuck Anderson]

I have orphaned zoneminder on all branches.

It has a number of bugs and crash reports in ABRT.  It now has broken
deps:

zoneminder has broken dependencies in the rawhide tree:
On x86_64:
zoneminder-1.28.1-6.fc25.x86_64 requires php-mysql
On armhfp:
zoneminder-1.28.1-6.fc25.armv7hl requires php-mysql
On ppc64le:
zoneminder-1.28.1-6.fc25.ppc64le requires php-mysql
On aarch64:
zoneminder-1.28.1-6.fc25.aarch64 requires php-mysql
On ppc64:
zoneminder-1.28.1-6.fc25.ppc64 requires php-mysql
On i386:
zoneminder-1.28.1-6.fc25.i686 requires php-mysql
Please resolve this as soon as possible.

I recommend anyone who was using it to instead use the zmrepo version.
That version can/does use ffmpeg, so it supports more newer cameras.

If someone really wants this to stay in Fedora and/or EPEL, feel free
to take it but I recommend starting over with the zmrepo src.rpm.  I
was able to complete a zmrepo build with the ffmpeg, X10, and vlc
requirements removed, but there are several missing requirements for
CPAN modules that would need to be added.  I can provide my
uncompleted work on this to anyone who is interested.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

installing RPMs on NFS filesystems

[Chuck Anderson]

Is it supposed to be supported to install RPMs onto NFS filesystems?
Apparently NFSv3 doesn't support capabilities, so I'm not sure what to
do with this bug which happens because cap_net_raw is used for the
fping binaries:

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

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

Re: DNF and PackageKit background data usage

[Chuck Anderson]

On Sun, Oct 30, 2016 at 10:02:43AM -0500, Michael Catanzaro wrote:
> On Sun, 2016-10-30 at 09:15 +0100, Theodore Papadopoulo wrote:
> > I
> > just found that the packagekit cache on my machine is about 7Gb !!!
> 
> This has got to be a bug, please report it.

My packagekit cache regularly fills up / on my systems.  I almost
never use packagekit to perform updates or installs, so maybe that's
why.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: where is /1 coming from?

[Chuck Anderson]

Am I the only one who can't see the email body below?

On Wed, Oct 12, 2016 at 10:44:00AM -0400, pete0verse wrote:
> 
> MIME-Version: 1.0
> Content-Type: multipart/alternative; 
> boundary="--_com.samsung.android.email_1427992738156800"
> 
> _com.samsung.android.email_1427992738156800
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: base64
> 
> SSBoYWQgdGhpcyBpc3N1ZSBvZiAxIGluIC8gaW4gRjI0IEkgaGFkIHVwZ3JhZGVkIGZyb20gMjIu
> wqAKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgUzcsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0
> cGhvbmUKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IEpvYWNoaW0gQmFj
> a2VzIDxqb2FjaGltLmJhY2tlc0ByaHJrLnVuaS1rbC5kZT4gRGF0ZTogMTAvMTIvMTYgIDEwOjM2
> IEFNICAoR01ULTA1OjAwKSBUbzogRGV2ZWxvcG1lbnQgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byBG
> ZWRvcmEgPGRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnPiBTdWJqZWN0OiBSZTogd2hlcmUg
> aXMgLzEgY29taW5nIGZyb20/IApPbiAxMC8xMi8xNiAxNTowMywgTWF0dGhldyBNaWxsZXIgd3Jv
> dGU6Cj4gU29tZW9uZSBvbiBSZWRkaXQgbm90ZWQgdGhhdCB0aGVyZSdzIGEgemVyby1sZW5ndGgg
> ZmlsZSBuYW1lZCBgMWAgaW4gLwo+IG9uIHRoZWlyIEYyNSBzeXN0ZW0uIEkganVzdCBsb29rZWQg
> b24gbWluZSwgYW5kIEkgaGF2ZSBvbmUgdG9vLiBJdCdzCj4gbm90IG93bmVkIGJ5IGFueSBSUE0u
> IEFuZCBJIGNoZWNrZWQgb24gYW4gRjI0IGJveCwgYW5kIGl0J3MgZ290IHRoYXQKPiB0b28uIEFu
> eW9uZSBrbm93IHdoZXJlIHRoaXMgaXMgY29taW5nIGZyb20/Cj4KQWRkaXRpb25hbGx5IEkgc2Vl
> IGEgZmlsZSBjYWxsZWQgL251bGwgd2l0aCB6ZXJvIGxlbmd0aCEKCktpbmQgcmVnYXJkcwoKSm9h
> Y2hpbSBCYWNrZXMKCi0tIAoKRmVkb3JhIHJlbGVhc2UgMjUgKFR3ZW50eSBGaXZlKQpLZXJuZWwt
> NC44LjEtMS5mYzI1Lng4Nl82NAoKCkpvYWNoaW0gQmFja2VzIDxqb2FjaGltLmJhY2tlc0ByaHJr
> LnVuaS1rbC5kZT4KaHR0cDovL3d3dy11c2VyLnJocmsudW5pLWtsLmRlL35iYWNrZXMvCl9fX19f
> X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRldmVsIG1haWxpbmcg
> bGlzdCAtLSBkZXZlbEBsaXN0cy5mZWRvcmFwcm9qZWN0Lm9yZwpUbyB1bnN1YnNjcmliZSBzZW5k
> IGFuIGVtYWlsIHRvIGRldmVsLWxlYXZlQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnCg==
> 
> _com.samsung.android.email_1427992738156800
> Content-Type: text/html; charset=utf-8
> Content-Transfer-Encoding: base64
> 
> PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
> L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkkgaGFkIHRoaXMgaXNzdWUg
> b2YgMSBpbiAvIGluIEYyNCBJIGhhZCB1cGdyYWRlZCBmcm9tIDIyLiZuYnNwOzwvZGl2PjxkaXY+
> PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2Vy
> X3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9
> ImF1dG8iPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTNywgYW4gQVQmYW1wO1QgNEcgTFRF
> IHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNp
> emU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0t
> LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IEpvYWNoaW0gQmFj
> a2VzICZsdDtqb2FjaGltLmJhY2tlc0ByaHJrLnVuaS1rbC5kZSZndDsgPC9kaXY+PGRpdj5EYXRl
> OiAxMC8xMi8xNiAgMTA6MzYgQU0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IERldmVsb3Bt
> ZW50IGRpc2N1c3Npb25zIHJlbGF0ZWQgdG8gRmVkb3JhICZsdDtkZXZlbEBsaXN0cy5mZWRvcmFw
> cm9qZWN0Lm9yZyZndDsgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogd2hlcmUgaXMgLzEgY29taW5n
> IGZyb20/IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2Pk9uIDEwLzEyLzE2IDE1OjAzLCBNYXR0
> aGV3IE1pbGxlciB3cm90ZTo8YnI+Jmd0OyBTb21lb25lIG9uIFJlZGRpdCBub3RlZCB0aGF0IHRo
> ZXJlJ3MgYSB6ZXJvLWxlbmd0aCBmaWxlIG5hbWVkIGAxYCBpbiAvPGJyPiZndDsgb24gdGhlaXIg
> RjI1IHN5c3RlbS4gSSBqdXN0IGxvb2tlZCBvbiBtaW5lLCBhbmQgSSBoYXZlIG9uZSB0b28uIEl0
> J3M8YnI+Jmd0OyBub3Qgb3duZWQgYnkgYW55IFJQTS4gQW5kIEkgY2hlY2tlZCBvbiBhbiBGMjQg
> Ym94LCBhbmQgaXQncyBnb3QgdGhhdDxicj4mZ3Q7IHRvby4gQW55b25lIGtub3cgd2hlcmUgdGhp
> cyBpcyBjb21pbmcgZnJvbT88YnI+Jmd0Ozxicj5BZGRpdGlvbmFsbHkgSSBzZWUgYSBmaWxlIGNh
> bGxlZCAvbnVsbCB3aXRoIHplcm8gbGVuZ3RoITxicj48YnI+S2luZCByZWdhcmRzPGJyPjxicj5K
> b2FjaGltIEJhY2tlczxicj48YnI+LS0gPGJyPjxicj5GZWRvcmEgcmVsZWFzZSAyNSAoVHdlbnR5
> IEZpdmUpPGJyPktlcm5lbC00LjguMS0xLmZjMjUueDg2XzY0PGJyPjxicj48YnI+Sm9hY2hpbSBC
> YWNrZXMgJmx0O2pvYWNoaW0uYmFja2VzQHJocmsudW5pLWtsLmRlJmd0Ozxicj5odHRwOi8vd3d3
> LXVzZXIucmhyay51bmkta2wuZGUvfmJhY2tlcy88YnI+X19fX19fX19fX19fX19fX19fX19fX19f
> X19fX19fX19fX19fX19fX19fX19fX188YnI+ZGV2ZWwgbWFpbGluZyBsaXN0IC0tIGRldmVsQGxp
> c3RzLmZlZG9yYXByb2plY3Qub3JnPGJyPlRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwgdG8g
> ZGV2ZWwtbGVhdmVAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmc8YnI+PC9ib2R5PjwvaHRtbD4=
> 
> _com.samsung.android.email_1427992738156800--
> ___
> 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: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Chuck Anderson]

On Wed, May 18, 2016 at 12:38:37PM -0700, Adam Williamson wrote:
> On Wed, 2016-05-18 at 15:02 -0400, Chuck Anderson wrote:
> > On Wed, May 18, 2016 at 11:10:57AM -0700, Adam Williamson wrote:
> > > On Fri, 2016-05-13 at 15:19 +0200, Petr Spacek wrote:
> > > > 
> > > > +1
> > > > 
> > > > The Change Page did not even try to weight pros and cons. IMHO cons (as
> > > > described above) are worse that living with original name, which is
> > > > well-known, well-documented, and relied on.
> > > 
> > > Another +1 here. I think the name should stay. Changing it brings no
> > > significant benefits but will certainly break stuff, and render huge
> > > amounts of existing information obsolete.
> > 
> > I happen to agree, but that argument was lost on the yum -> dnf
> > rename.
> 
> No it wasn't. There are many precedents for keeping some things after a
> rename where changing them would be too destructive, and we even have a
> perfectly good rationale that's already been cited in this thread: the
> repository metadata format is still the same one originally defined by
> yum and could still be referred to as the 'yum repository format'.

I believe we are in agreement about the present change under
discussion (don't change things needlessly).  My point was that we (as
a project) couldn't agree to keep the CLI command named "yum" for the
same reasons.  Maybe over time that will become true if/when "yum"
stops warning people to change to "dnf".
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Chuck Anderson]

On Wed, May 18, 2016 at 11:10:57AM -0700, Adam Williamson wrote:
> On Fri, 2016-05-13 at 15:19 +0200, Petr Spacek wrote:
> > 
> > +1
> > 
> > The Change Page did not even try to weight pros and cons. IMHO cons (as
> > described above) are worse that living with original name, which is
> > well-known, well-documented, and relied on.
> 
> Another +1 here. I think the name should stay. Changing it brings no
> significant benefits but will certainly break stuff, and render huge
> amounts of existing information obsolete.

I happen to agree, but that argument was lost on the yum -> dnf
rename.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Xulrunner - intent to remove from Fedora 24

[Chuck Anderson]

On Wed, Jan 27, 2016 at 06:41:55PM +, Richard Hughes wrote:
> On 27 January 2016 at 18:35, Stephen John Smoogen  wrote:
> > What can use the plugins if the major user no longer does? Don't the other
> > tools rely on xulrunner to use the plugons
> 
> I'm kinda thinking of removing the PackageKit plugin from Fedora just
> because of this; if it exists and doesn't work, what's the point?

So why is all this functionality being removed?  What is supposed to
replace NPAPI, and can our plugins be modified to work with whatever
that new thing is?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Chuck Anderson]

On Thu, Jan 14, 2016 at 05:07:57PM -0500, Zach Villers wrote:
> A - determine with we were going to start building a kernel with nodebug
> turned off

Why?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: keepassx 2.0?

[Chuck Anderson]

On Tue, Jan 12, 2016 at 10:41:24AM +, Jonathan Wakely wrote:
> I'm concerned by this update too.
> 
> The latest post in Bugzilla says:
> 
> (In reply to Francesco Frassinelli (frafra) from comment #35)
> >(In reply to Ed Marshall from comment #33)
> >> (and, obviously, send email to the mailing list, so users are
> >> actually
> >> notified this time rather than getting a surprise breaking upgrade
> >> out of
> >> the blue)
> >
> >I can't downgrade keepassx because many people upgraded their
> >database
> >(comment #34).
> 
> Those people are presumably happy with version 2 (or are stuck with it
> now). But there are other people refusing to upgrade because of this.
> 
> A possible solution is to include both keepassx-0.4.4 and
> keepassx2-2.0.0 in F22 and F23, so people can choose which version to
> use based on their preference (and whether they've already upgraded
> their databases).
> 
> >I could provide a keepassx2 subpackage which replaces keepassx =
> >2.0.0, but
> >I'm not sure about how to handle Obsoletes/Provides in this case.
> 
> Couldn't both be installed at the same time (if the binaries are
> renamed)? You just can't use the same .kdb file with both versions.

Given that people have already had their databases upgraded to .kdbx
(but the v1 .kdb file is still there), instead of downgrading keepassx
which is now at v2, you could inroduce a new keepassx1 package.  It
might be cleaner that way now that the v2 package has already gone
out.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: wayland in rawhide

[Chuck Anderson]

On Thu, Nov 12, 2015 at 10:59:02AM +, Tom Hughes wrote:
> On 12/11/15 10:51, Jared K. Smith wrote:
> 
> >On Thu, Nov 12, 2015 at 2:10 AM, Tom Hughes  >> wrote:
> >
> >You forgot primary selection/middle click paste, which was what made
> >me go back to X when I tried it in F23.
> >
> >I've been testing Wayland myself since around the F22 time period, but
> >"middle click paste" and the occasional odd bug keep annoying me enough
> >to go back to X.  Can you elaborate on the plans for supporting middle
> >click to paste, or is it considered a relic of a bygone era and I should
> >try to unlearn?  I'm generally in favor of pushing the envelope a bit
> >when it comes to new features, but I have to admit that defaulting to
> >Wayland at this point seems a bit premature to me, even for rawhide.
> 
> All I know is what I found by googling:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1214655
> 
> https://ask.fedoraproject.org/en/question/75924/fedora-23-wayland-gnome-terminal-mouse-middle-click-paste/

My brain hurts after reading that.  Since Wayland decided there should
be Only One clipboard buffer (which is probably a good idea), would it
be too hard to just make Menu Copy/Paste do the same thing as Keyboard
Copy/Paste (Ctrl-C/Ctrl-V) do the same thing as Select/Middle-Click
Copy/Paste, all with the same single clipboard buffer, on/between both
Xwayland apps and native Wayland apps?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Chuck Anderson]

On Wed, Sep 30, 2015 at 08:35:41AM -0400, Stephen Gallagher wrote:
> * All packages not in the critical path whose upstreams have no
> mechanism to build against system libraries '''must''' be contacted
> publicly about a path to supporting system libraries. If upstream
> refuses, this must be recorded in a link included in the spec file.
> * All packages not in non-critical path whose upstreams have no
> mechanism to build against system libraries '''may''' opt to carry
> bundled libraries, but if they do, they '''must''' include {{{Provides:
> bundled() = }}} in their RPM spec file.

In this last bullet oint, did you mean "all packages not in the
critical path", or did you really mean what it literally says above
"all packages not in the NON-critical path".  If the latter, I suggest
a wording change: "all packages in the critical path".
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Do you know how many 64-bit architectures Fedora has?

[Chuck Anderson]

On Mon, Aug 24, 2015 at 06:02:35PM +0200, Marcin Juszkiewicz wrote:
 W dniu 24.08.2015 o 16:09, Jonathan Underwood pisze:
 It would be worthwhile adding this to:
 
 https://fedoraproject.org/wiki/Packaging_tricks
 
 Added

Is there an analagous macro for all little endian arches?  This
would be useful for the msed package.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

(co-)maintainer(s) needed for zoneminder

[Chuck Anderson]

A few months ago zoneminder was orphaned and I took it because I have
an instance of it I have to keep running.  I got rawhide/F23 to build,
but haven't really had the time to test it or do the bigger work
necessary to bring it into line with how upstream operates.  I also
have not updated older branches.

Is there anyone out there who is interested in helping to maintain
zoneminder?  Even someone who can just test what I've done would be
helpful at this point.  If not, I'll eventually get to working on it
more, but it may not be for several more weeks...

Thanks.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Review swap: parcimonie.sh

[Chuck Anderson]

I'll take this review in exchange for this one:

Review Request: msed - Tools to manage the activation and use of self 
encrypting drives

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

Thanks,
Chuck

On Sun, Jul 26, 2015 at 06:05:59PM +0200, Till Hofmann wrote:
 Hi all,
 
 I'm looking for a review for parcimonie.sh [1].
 
 parcimonie.sh refreshes individual keys in your GnuPG keyring at
 randomized intervals. Each key is refreshed over a unique, single-use
 Tor circuit.
 
 The package is rather simple, as it only consists of a single bash
 script and a parameterized systemd service.
 
 I'll review a package in return.
 
 Thanks,
 Till
 
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1242086
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: building an embedded Linux distro into a RPM package

[Chuck Anderson]

Using the Opal SED built-in encryption is really orthogonal to
dm-crypt.  You could use both at the same time if you were really
paranoid though.

You need a partitioned bootable disk image with MBR bootcode and a
bootloader to load into the SED with msed --loadPBAimage.  That
image must be smaller than about 7MB, or certain SED's (mainly
Crucial) won't load the image successfully.  If dracut can make such
an image, I supposed it could be used.  However, I think the default
Fedora kernel image alone (not including kernel modules) is already
too big by itself for this to be possible.

On Sun, Jul 26, 2015 at 11:20:04AM -0400, Subhendu Ghosh wrote:
 Adding Harald to thread.
 
 Seems to be nominally related boot path with deo and dm-crypt.
 
 Adding to Dracut might be preferable to creating a separate PBA
 
 Subhendu
 
 On Jul 23, 2015 10:20 AM, Chuck Anderson c...@wpi.edu wrote:
 
  I originally sent this to the packaging list, but there was no
  response there so I'm posting to devel now.
 
  I've also opened a review request for the non-controversial packaging
  of the msed utilities.  Would anyone care to do a review swap?
 
  Review Request: msed - Tools to manage the activation and use of self
 encrypting drives
 
  https://bugzilla.redhat.com/show_bug.cgi?id=1245640
 
  Thanks.
 
  Date: Tue, 21 Jul 2015 18:48:27 -0400
  From: Chuck Anderson c...@wpi.edu
  To: packag...@lists.fedoraproject.org
  Subject: [Fedora-packaging] building an embedded Linux distro into a RPM
 package
  Precedence: list
  Reply-To: Discussion of RPM packaging standards and practices for Fedora 
 packag...@lists.fedoraproject.org
 
  I would like to submit a new package that provides a Pre-Boot
  Authorization (PBA) image.  The PBA is a bootloader of sorts that
  prompts the user for the passphrase to unlock a Self-Encrypting Drive
  (SED) using the TCG OPAL command set, and then either chainloads to
  the real OS or reboots to allow the BIOS to boot the real OS.  The
  image gets installed to the OPAL SED as a sort of shadow MBR/shadow
  disk image using a special command msed (Manage Self-Encrypting
  Drive) that I also plan to submit a package for.
 
  In my case, I've developed a tiny embedded Linux-based PBA image [1]
  using Buildroot [2] and the MSED software [3].  The final image is a
  MBR-partitioned disk image with VFAT filesystem containing the
  specially built Linux kernel (vmlinuz), initramfs (rootfs.gz), and the
  installed syslinux bootloader.
 
  Before you ask, I can't use even a stripped-down Fedora image for this
  purpose, because it must be TINY and it only exists to run a single
  command (linuxpba), then reboot.  My image is 4MB and could be made
  even smaller.  See the reasoning in [1] for why it must be so small.
 
  [1] https://github.com/cranderson/buildroot-linuxpba
  [2] http://buildroot.uclibc.org/
  [3] http://www.r0m30.com/msed
 
  Now I know there are several challenges to using the Buildroot
  approach to building software for Fedora.  Buildroot downloads
  software from the Internet, unpacks, patches, configures, and builds
  it.  The build environment is built first, so gcc, uClibc, busybox,
  etc. and then the packages you want to include are built in that
  environment.
 
  What is the best approach I should use that is acceptable to Fedora?
 
  Would it be acceptable to bundle source packages, Buildroot itself,
  and my Buildroot configuration into one SRPM so everything is
  self-contained and can be built without requiring network
  connectivity?  This means I would have to bundle the source code for
  gcc, the linux kernel, uClibc, busybox, etc.
 
  Or is there some way to pull in SRPM packages that already exist in
  Fedora, and use those as part of my build process so that I don't have
  to bundle all the source code?  Additionally, I could made separate
  SRPM packages for Buildroot itself, any components needed (uClibc is
  already in the distro), the Buildroot build scripts for
  buildroot-linuxpba, and the actual package I need (msed).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: building an embedded Linux distro into a RPM package

[Chuck Anderson]

On Sat, Jul 25, 2015 at 08:51:09AM -0500, Bruno Wolff III wrote:
 On Fri, Jul 24, 2015 at 23:05:07 -0400,
  Chuck Anderson c...@wpi.edu wrote:
 
 Is there an existing Fedora cross toolchain for targeting a tiny
 i586/i686 Linux userspace with uClibc?  Maybe I could use that to
 build linuxpba and the PBA image itself.  I'd still need a custom
 kernel, because the standard kernel bzImage is already bigger than my
 entire PBA image, and that isn't counting the loadable modules.
 
 openwrt builds on Fedora with very little work. The first part of
 that is building the cross tool chain it uses to build images.

Okay, but is that toolchain in Fedora already?  It seems there is no
i586/i686 uClibc toolchain already packaged in Fedora.

What the question seems to come down to is, does Fedora insist that
every unique toolchain/build environment used by any particular
package MUST be available as separate Fedora package(s), or is it okay
to bundle the particular special toolchain with the package that is
being built?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: building an embedded Linux distro into a RPM package

[Chuck Anderson]

On Fri, Jul 24, 2015 at 12:54:23PM -0600, Kevin Fenzi wrote:
 On Thu, 23 Jul 2015 10:19:26 -0400
 Chuck Anderson c...@wpi.edu wrote:
 
 ...snip...
 
  I would like to submit a new package that provides a Pre-Boot
  Authorization (PBA) image.  The PBA is a bootloader of sorts that
  prompts the user for the passphrase to unlock a Self-Encrypting Drive
  (SED) using the TCG OPAL command set, and then either chainloads to
  the real OS or reboots to allow the BIOS to boot the real OS.  The
  image gets installed to the OPAL SED as a sort of shadow MBR/shadow
  disk image using a special command msed (Manage Self-Encrypting
  Drive) that I also plan to submit a package for.
 
 So, the idea would be someone would 'dnf install' this package, run
 msed and then reboot to have it take effect?

Basically, yes.  There would be a few msed runs, once to set the
passphrase, once to load the PBA image to the drive, and once to
enable the shadow MBR.  I envision making this easier eventually,
perhaps with a GUI for presenting a list of drives that support OPAL
and providing the ability to encrypt them and load a PBA image for
unlocking at boot.  The nice thing about SEDs is that you can
encrypt them without reinstalling--you are basically just setting
the passphrase for the master key that is always being used inside the
drive for the always-on encryption.

  In my case, I've developed a tiny embedded Linux-based PBA image [1]
  using Buildroot [2] and the MSED software [3].  The final image is a
  MBR-partitioned disk image with VFAT filesystem containing the
  specially built Linux kernel (vmlinuz), initramfs (rootfs.gz), and the
  installed syslinux bootloader.
  
  Before you ask, I can't use even a stripped-down Fedora image for this
  purpose, because it must be TINY and it only exists to run a single
  command (linuxpba), then reboot.  My image is 4MB and could be made
  even smaller.  See the reasoning in [1] for why it must be so small.
  
  [1] https://github.com/cranderson/buildroot-linuxpba
  [2] http://buildroot.uclibc.org/
  [3] http://www.r0m30.com/msed
  
  Now I know there are several challenges to using the Buildroot
  approach to building software for Fedora.  Buildroot downloads
  software from the Internet, unpacks, patches, configures, and builds
  it.  The build environment is built first, so gcc, uClibc, busybox,
  etc. and then the packages you want to include are built in that
  environment.
  
  What is the best approach I should use that is acceptable to Fedora?
 
 I'm not sure. :) 
 
  Would it be acceptable to bundle source packages, Buildroot itself,
  and my Buildroot configuration into one SRPM so everything is
  self-contained and can be built without requiring network
  connectivity?  This means I would have to bundle the source code for
  gcc, the linux kernel, uClibc, busybox, etc.
  
  Or is there some way to pull in SRPM packages that already exist in
  Fedora, and use those as part of my build process so that I don't have
  to bundle all the source code?  Additionally, I could made separate
  SRPM packages for Buildroot itself, any components needed (uClibc is
  already in the distro), the Buildroot build scripts for
  buildroot-linuxpba, and the actual package I need (msed).
 
 This sounds to me like something thats better suited to be composed and
 shipped as some kind of image instead of being a package. 

Perhaps, but however it is delivered, it needs to be built somewhere
by someone...and I don't think RelEng would be happy to have a build
procedure that involved downloading sources from the Internet
either...

 I can see the appeal of a package however since it's so small. 
 
 The build system will not let you download stuff from the net.
 If we did builds would not be reproducable. 

Agreed.

 You cannot use the existing gcc/busybox/etc to build the image?

The msed linuxpba Linux userspace program is the one that prompts
the user for the passphrase, does the unlocking, and reboots the
system afterwards.  It is written in C++ and links against ncurses.  I
haven't found a way to statically link the whole thing since it is
written in C++, so it needs enough of a Linux userspace to be able to
dynamically load libraries, access device nodes, etc.

Everything else exists solely to boot up and run linuxpba in as tiny
a way as possible.

To keep things tiny, the kernel is built with most options turned off,
and anything required is built-in (no modules)--including all SATA
drivers.

uClibc is used with a tweaked config file, again to keep things small.

busybox is used as an init program and to launch linuxpba--most of
the busybox options are turned off in the config.  It might be
possible to completely eliminate busybox as well, but I haven't
figured that part out yet.

The whole thing is built with a cross-compile toolchain.  First the
toolchain itself is built--the host gcc is used to build the cross gcc
which then is used to build itself, uClibc, etc.

The problem with trying

building an embedded Linux distro into a RPM package

[Chuck Anderson]

I originally sent this to the packaging list, but there was no
response there so I'm posting to devel now.

I've also opened a review request for the non-controversial packaging
of the msed utilities.  Would anyone care to do a review swap?

Review Request: msed - Tools to manage the activation and use of self 
encrypting drives

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

Thanks.

Date: Tue, 21 Jul 2015 18:48:27 -0400
From: Chuck Anderson c...@wpi.edu
To: packag...@lists.fedoraproject.org
Subject: [Fedora-packaging] building an embedded Linux distro into a RPM package
Precedence: list
Reply-To: Discussion of RPM packaging standards and practices for Fedora 
packag...@lists.fedoraproject.org

I would like to submit a new package that provides a Pre-Boot
Authorization (PBA) image.  The PBA is a bootloader of sorts that
prompts the user for the passphrase to unlock a Self-Encrypting Drive
(SED) using the TCG OPAL command set, and then either chainloads to
the real OS or reboots to allow the BIOS to boot the real OS.  The
image gets installed to the OPAL SED as a sort of shadow MBR/shadow
disk image using a special command msed (Manage Self-Encrypting
Drive) that I also plan to submit a package for.

In my case, I've developed a tiny embedded Linux-based PBA image [1]
using Buildroot [2] and the MSED software [3].  The final image is a
MBR-partitioned disk image with VFAT filesystem containing the
specially built Linux kernel (vmlinuz), initramfs (rootfs.gz), and the
installed syslinux bootloader.

Before you ask, I can't use even a stripped-down Fedora image for this
purpose, because it must be TINY and it only exists to run a single
command (linuxpba), then reboot.  My image is 4MB and could be made
even smaller.  See the reasoning in [1] for why it must be so small.

[1] https://github.com/cranderson/buildroot-linuxpba
[2] http://buildroot.uclibc.org/
[3] http://www.r0m30.com/msed

Now I know there are several challenges to using the Buildroot
approach to building software for Fedora.  Buildroot downloads
software from the Internet, unpacks, patches, configures, and builds
it.  The build environment is built first, so gcc, uClibc, busybox,
etc. and then the packages you want to include are built in that
environment.

What is the best approach I should use that is acceptable to Fedora?

Would it be acceptable to bundle source packages, Buildroot itself,
and my Buildroot configuration into one SRPM so everything is
self-contained and can be built without requiring network
connectivity?  This means I would have to bundle the source code for
gcc, the linux kernel, uClibc, busybox, etc.

Or is there some way to pull in SRPM packages that already exist in
Fedora, and use those as part of my build process so that I don't have
to bundle all the source code?  Additionally, I could made separate
SRPM packages for Buildroot itself, any components needed (uClibc is
already in the distro), the Buildroot build scripts for
buildroot-linuxpba, and the actual package I need (msed).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary of Thursday's call between GNOME and NM devels and Default DNS resolver change owners

[Chuck Anderson]

Looks great!  I've been using this daily on Fedora 21 and I have to
say it mostly works well EXCEPT for the captive portal detection stuff
which is just horrendously bad, so I'm happy to see a new design that
may work a lot better.

Will the below be substantially implemented and testable
by the July 28 Change CheckPoint: Completion deadline (testable)?
That is only 10 days away...

It would be great if the Change page could be updated with these plans
and the current status, how to test, etc.

Thanks!

On Fri, Jul 17, 2015 at 05:40:56PM +0200, Tomas Hozza wrote:
 Hello all.
 
 I would like to share the outcome of the discussion between GNOME and NM 
 developers
 and the Default DNS resolver [1] Change for F23.
 
 The full summary can be found here [2] and recording here [3] is anyone is 
 interested.
 
 
 Integration points:
 - Captive portal detection
 - Captive portal handling
 - User interaction
 
 
 Points we agreed on:
 * Captive portal detecion
   * NM side
 * NM will be the only daemon doing Captive portal detection
 * NM moves connectivity check before NM_DEVICE_STATE_ACTIVATED, emits 
 signal before network is up
 * If portal has been detected, NM blocks NM_DEVICE_STATE_ACTIVATED for a 
 specific device until there is no more portal
 * NM regularly does the Captive portal detection (connectivity check) to 
 determine if the login using GNOME was already done
 * Once the login was done and Internet connectivity is detected, NM 
 triggers some event in nm-dispatcher (or something like that)
   * GNOME side
 * GNOME Shell does not do detection itself, but relies on the NM (as 
 already done)
 * GNOME is watching the change of connectivity state property in NM
   * dnssec-trigger side
 * Does not do any detection
 * does not do any user interaction
 * Only relies on events triggered by NM and acts based on the 
 connectivity status
 
 * Captive portal handling (login)
   * GNOME side
 * If Captive portal is detected, then browser window is launched
 * The browser window ls launched with LD_PRELOAD 
 (https://github.com/hadess/resolvconf-override) as resolv.conf override
 * GNOME should fetch the connection-provided DNS servers using NM API 
 (existing) and use those for LD_PRELOAD solution
   * dnssec-trigger side
 * does not do any user interaction
 * Only relies on events triggered by NM and acts based on the 
 connectivity status
 
 * User interface / user interaction
   * Fedora Workstation product
 * GNOME shell
   * informs the user about the Captive portal
   * launches the window 
 * dnssec-trigger
   * the applet will be split into separate package and not installed by 
 default (already done)
   * if all falbacks fail, it switches automatically to Insecure mode 
 (no DNSSEC validation) without user interaction
 * automatic switch to insecure mode will be possible to turn off 
 using configuration file for expert users
 * a notification can be emited about switching to insecure mode (so 
 far by default OFF)
   * Other desktops / Spins
 * dnssec-trigger applet
   * should handle the UI that is usually handled by GNOME Shell (if there 
 is not any specific Spin implementation to do that, i.e. if GNOME is not in 
 use)
   * Captive portal detection will be still done in NM
 
 * under discussion:
   * notification can be turned OFF by default, but configurable in config 
 file for expert users - unfortunatelly this will not create pressure on 
 admins to fix the networks
   * alternative: display a message which will say that local network is 
 broken and that admin should be woken up:
 * 'Your network is seriously broken. Go and kick your network admin NOW!
 * This broken network will stop working from Fedora 24 on because it does 
 not support DNSSEC. (Tell this to your admin!)'
 
 
 [1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
 [2] https://www.piratepad.ca/p/default-dns-resolver-f23
 [3] https://bluejeans.com/s/8pTY/
 
 
 Regards,
 -- 
 Tomas Hozza
 Software Engineer - EMEA ENG Developer Experience
 
 PGP: 1D9F3C2D
 Red Hat Inc. http://cz.redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary of Thursday's call between GNOME and NM devels and Default DNS resolver change owners

[Chuck Anderson]

On Fri, Jul 17, 2015 at 01:18:51PM -0500, Dan Williams wrote:
 On Fri, 2015-07-17 at 13:22 -0400, Chuck Anderson wrote:
  Looks great!  I've been using this daily on Fedora 21 and I have to
  say it mostly works well EXCEPT for the captive portal detection stuff
  which is just horrendously bad, so I'm happy to see a new design that
  may work a lot better.
 
 What doesn't work in your experience with the captive portal stuff?
 Just wondering so we can improve it.  This plan doesn't necessarily make
 anything about *detecting* a portal better, just the flow after one has
 been detected.

Usually, the dnssec-triggerd captive portal detection pops up a
dialog, and when I click log in nothing happens.  When I click
skip (sorry I might be forgetting the exact button names) then a
captive portal browser pops up (I think this is the normal Gnome or NM
one, again not sure).  Usually things work fine after logging in
there.

Yesterday I happened to be testing a captive portal implementation (a
new guest wireless system we are deploying) using my Fedora 21 laptop,
and whatever I did, I couldn't get dnssec-triggerd to cooperate.  I
had to shut it off completely, because I kept hitting SELinux issues.
Even after I did setenforce 0 I kept getting an authentication
dialog popup for ABRT and/or selinux-troubleshooter to be able to
read other people's reports or something to that effect.  I couldn't
get the darn thing to shut up, so I had to disable it.  I know there
is/was an outstanding SELinux issue with dnssec-triggerd sending a
signal to NM, so that might be fixed by now.

Now without dnssec-triggerd in the picture, the Gnome/NM captive
portal detection worked beautifully.

Even without the recent SELinux issues, dnssec-triggerd's captive
portal implementation has been iffy.  Sometimes it works, and
sometimes it doesn't.  I think there may be an issue with it trying to
launch the captive portal login browser, or timing issues between
Gnome/NM and dnssec-triggerd.

So I think the bulk of my troubles are the fighting between
dnssec-trigger's captive portal code and the Gnome/NM code.  But that
is exactly what you all agreed to address, so I'm happy that this will
be fixed.  I just hope it can all be implemented in time for the
Change Completion Deadline (10 days away).

Keep in mind all of my experience so far is on Fedora 21, so even F22
may have improved things already.

 
 Dan
 
  Will the below be substantially implemented and testable
  by the July 28 Change CheckPoint: Completion deadline (testable)?
  That is only 10 days away...
  
  It would be great if the Change page could be updated with these plans
  and the current status, how to test, etc.
  
  Thanks!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Chuck Anderson]

On Mon, Jun 01, 2015 at 09:31:14PM +0200, Reindl Harald wrote:
 
 Am 01.06.2015 um 20:30 schrieb Andrew Lutomirski:
 I would think that avoiding a single point of failure (your LAN
 nameserver) would be a *good* thing
 
 and your holy one and only resolver on localhost is not a single
 point of failure? in fact it would take much longer to recognize a
 failing and exclusive local resolver on 2 out of 1000 servers why it
 gets visible from the first second if your central nameservers have
 problems
 
 and BTW glibc has no problem with the first nameserver in
 /etc/resolv.conf failing as long as the slave responds, it may take
 a little time but that don't matter as long as we are not talking
 about a incoming mail exchanger

I'm sorry, but saying that it may take a little time is a
non-starter.  For anyone who says this, I challenge you to set your
system's resolv.conf so that the first listed nameserver is a
completely offline IP address, and the second/third listed ones are
your normal nameservers.  Note that the first one must be completely
offline, not an IP that is up but just doesn't have a listening
nameserver, but an IP that is non-existent on your local network.
E.g. if your local network is 192.168.1.0/24, set it to
192.168.1.unassigned-to-any-host.  Make sure you can't ping the
unassigned IP.

There are many services that will choke in this sort of configuration.
Not just mail servers, but RADIUS servers, LDAP servers, Samba
servers, web servers depending on the configuration, SSH servers and
clients, etc.  Sure, if you test everything in this exact failure
scenario, you may be able to work around this problem (e.g. turn off
reverse DNS lookups in Apache and sshd, etc.) but if you run a LAN or
data center with many different groups maintaining different systems,
you can't guarantee that everyone has done this sort of rigorous
testing and configurations to avoid problems, if it is even possible
for some services which it may not be.

Of course a localhost resolver is also a single point of failure.  But
the important property is that it is very much FATE SHARED with the
rest of the system.  So when you reboot the system to apply a security
update, it doesn't matter that the localhost resolver is offline,
because the services on that box are offline too.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ping6 and other tool6 awkwardness

[Chuck Anderson]

On Wed, May 13, 2015 at 01:10:05PM -0700, J.C. Cleaver wrote:
 On Tue, May 12, 2015 1:41 am, Richard W.M. Jones wrote:
  On Tue, May 12, 2015 at 10:34:28AM +0200, Nikos Mavrogiannopoulos wrote:
  On Tue, 2015-05-12 at 09:04 +0100, Richard W.M. Jones wrote:
While working for an updated ipcalc to support ipv6 transparently, I
figured we have more tools which are not IPv6-ready and awkwardly
provide an additional tool with a -6 suffix, supposedly for separate
IPv6 support. That looks like a relic of the past, we still drag.
  IPv6
support should be transparent in programs (fortunately we don't have
ssh6). Any objection to fill bugs to merge the following tools with
their ipv4 equivalent?
   
ping6, geoiplookup6, tracepath6, traceroute6
  
   While I agree with your assessment of the separate tools, I think
   you're better off filing bugs with the upstream projects.
 
  I'm interested in what fedora ships rather than the upstream project per
  se.
 
  Fedora ships whatever upstream ships.  Big changes like integrating
  separate programs together should be made upstream.
 
  https://fedoraproject.org/wiki/Staying_close_to_upstream_projects
 
  The fedora maintainer may chose to switch to another upstream
  project if that is required.
 
  Are there other such projects that have all the features of current
  ping/traceroute/etc but integrate the tools together?
 
  Rich.
 
 
 
 Probably worth it to add fping/fping6 to the list as well:
 https://github.com/schweikert/fping

As Fedora fping maintainer, I can't do anything with this.  It needs
to be filed upstream.

I see a few reasons why network testing tools like ping, traceroute,
fping, etc. may still be using separate binaries for IPv6.

One is that when you are testing network functionality, you often want
to test IPv4 or IPv6 specifically.  These tools aren't really end-user
applications like ssh, where you don't care what protocol it uses to
connect because the protocol is just a means to an end.  With the
network testing tools, you often DO care.

Two is that the network testing tools often need to do
protocol-specific low-level things, like open raw sockets or build
packets manually rather than relying on the OS TCP/IP stack to do it.

Three is that these tools were often ported from IPv4 and don't
support integrated functionality (due to #2).  They can be compiled
for either IPv4 or IPv6, but not both at the same time.  For example,
the fping RPM used to build the software twice--once for IPv4 and once
for IPv6--and then package up the results together.  This changed with
newer fping versions, however.

I don't think pushing Fedora maintainers on this by filing bugs
downstream is going to change things.  It is the upstream software
that needs enhancement, so the bugs should be filed upstream.  Also,
suggesting alternate upstream projects that have the integrated
IPv4/IPv6 functionality is fine, but they may not be drop-in
replacements for the existing tools.  In that case the existing tools
should stay and the new ones can be added to the distro separately if
desired.  You can't exactly stop shipping a ping command and replace
it with gnip just because the latter supports IPv4+IPv6 with a
single command.  Add it sure, but not replace.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[EPEL-devel] el7 liblockfile

[Chuck Anderson]

liblockfile is installed with CentOS 7 and it gets updated by EPEL 7.
Is that supposed to happen?

# yum info liblockfile
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.mirror.constant.com
 * epel: mirrors.mit.edu
 * extras: centos.mirror.constant.com
 * updates: centos.mirror.constant.com
Installed Packages
Name: liblockfile
Arch: x86_64
Version : 1.08
Release : 18.el7
Size: 38 k
Repo: installed
From repo   : epel
Summary : This implements a number of functions found in -lmail on SysV
: systems
URL : http://packages.qa.debian.org/libl/liblockfile.html
License : GPLv2+ and LGPLv2+
Description : This library implements a number of functions found in -lmail on
: SysV systems. These functions are designed to lock the standard
: mailboxes in /var/mail (or wherever the system puts them).
: 
: In additions, this library adds a number of functions to create,
: manage and remove generic lockfiles.

Available Packages
Name: liblockfile
Arch: i686
Version : 1.08
Release : 17.el7
Size: 21 k
Repo: base/7/x86_64
Summary : This implements a number of functions found in -lmail on SysV
: systems
URL : http://packages.qa.debian.org/libl/liblockfile.html
License : GPLv2+ and LGPLv2+
Description : This library implements a number of functions found in -lmail on
: SysV systems. These functions are designed to lock the standard
: mailboxes in /var/mail (or wherever the system puts them).
: 
: In additions, this library adds a number of functions to create,
: manage and remove generic lockfiles.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: F22 System Wide Change: Default Local DNS Resolver

[Chuck Anderson]

On Mon, Jan 12, 2015 at 04:54:46PM +0100, Jaroslav Reznik wrote:
 = Proposed System Wide Change: Default Local DNS Resolver =
 https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

I've been using unbound + dnssec-trigger on my laptop at home and
desktop at work since this was announced for F21.  It works fine most
of the time, but there are occasionally issues with name resolution
that are fixed by restarting unbound.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[Chuck Anderson]

On Thu, Jan 08, 2015 at 08:43:48AM -0500, Stephen Gallagher wrote:
 Can we clarify something here? Is this a request to change the defaults
 globally for all Products/nonproduct installs?
 
 I would argue that it could be sensible to do this for Workstation and
 non-product installs, but not for Server and Cloud.
 
 In the Server case, nearly every deployment is headless. Disabling root
 login to ssh by default would mean that many people would have no way to
 get into the system at all. (Yes, we could force the creation of a
 non-root user at install time, but this user would by necessity be an
 administrator capable of becoming root via sudo, so the distinction
 is... fuzzy). The only other approach I could see for the headless
 servers would be mandating the enrollment in an identity domain at
 installation time (such as to FreeIPA or Active Directory).

Having a non-root account with sudo is already more secure because the
attacker would have to guess the username in addition to the password.

 Neither of those approaches is anything like ideal, so I would argue
 that Server should continue to operate with the SSH root login being
 available by default, but perhaps add documentation to the install guide
 recommending to disable it if other accounts are available; perhaps even
 by adding a simple kickstart directive (but no UI element) to accomplish
 this.

I disagree.  I think requiring a non-root account w/Admin to be
created is the best way to go.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Chuck Anderson]

On Tue, Dec 09, 2014 at 11:16:54AM -0700, Pete Travis wrote:
 But seriously, there's an implication in this thread that there will be
 work happening to give stuff a path to ask for an open port.  Where can we
 follow along with that effort? Starting with, say, how I might change
 `nikola runserver` or `django-admin runserver` to ask for the port, and
 ending with the resulting UI that asks me for approval?

The functionality for a program to ask for an open port already
exists.  It is called bind(2).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Chuck Anderson]

On Tue, Dec 09, 2014 at 11:52:01AM -0700, Pete Travis wrote:
 On Dec 9, 2014 11:33 AM, Chuck Anderson c...@wpi.edu wrote:
 I should have said ask firewalld for a port to be opened - sorry, I
 thought that would come from the context.
 
 Are you saying bind() should be talking to firewalld, via some approval
 agent?  how do we make that happen?

My point was that a firewall is superfluous if a program can just ask
firewalld to poke a hole in the firewall for it automatically, because
a program can already ask the system to open a listening port for it
using bind(2) (and listen(2) and accept(2)) when no firewall is
present.

It means that in a world where automatic-hole-punching exists, the
only use of a firewall on the host is maybe to limit the SCOPE of such
communication, not whether such communication is allowed at all or
not.  This is where firewall zones come in.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Chuck Anderson]

On Tue, Dec 09, 2014 at 12:09:23PM -0700, Pete Travis wrote:
 On Dec 9, 2014 12:06 PM, Chuck Anderson c...@wpi.edu wrote:
 
  On Tue, Dec 09, 2014 at 11:52:01AM -0700, Pete Travis wrote:
   On Dec 9, 2014 11:33 AM, Chuck Anderson c...@wpi.edu wrote:
   I should have said ask firewalld for a port to be opened - sorry, I
   thought that would come from the context.
  
   Are you saying bind() should be talking to firewalld, via some approval
   agent?  how do we make that happen?
 
  My point was that a firewall is superfluous if a program can just ask
  firewalld to poke a hole in the firewall for it automatically, because
  a program can already ask the system to open a listening port for it
  using bind(2) (and listen(2) and accept(2)) when no firewall is
  present.
 
  It means that in a world where automatic-hole-punching exists, the
  only use of a firewall on the host is maybe to limit the SCOPE of such
  communication, not whether such communication is allowed at all or
  not.  This is where firewall zones come in.
 
 Okay, one more thing on the ideal requirements list:  firewalld must not
 blindly approve all requests, there must be some approval mechanism.  What
 would that look like?

You either have a pre-approved policy of what is allowed and what is
not similar to how SELinux policy, PolicyKit rules, and the existing
firewall rule mechanisms work, you ask the user on each request,
similar to how some Windows firewalls work, or you ask the user when
they connect to a network which zone to associate that network with,
and use a pre-approved policy for each zone.  Zones can be Home,
Public, Work, etc.  Windows does this as well.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Chuck Anderson]

On Tue, Dec 09, 2014 at 01:25:47PM -0700, Pete Travis wrote:
 On Dec 9, 2014 12:55 PM, Reindl Harald h.rei...@thelounge.net wrote:
 
 
  Am 09.12.2014 um 20:51 schrieb Pete Travis:
 
  Hmm... a whitelist of things that are allowed to ask for firewall
  accommodation doesn't help me develop new applications at all.  And
  you're jumping to a really high level UI thing and just sort of hand
  waving over the mechanism needed to make it all work.  Assigning
  different networks to zones is a different problem compared to a program
  asking for a port.
 
 
  don't get me wrong but if it is too much asked for you to open a firewall
 port i don't want to have your network-aware new application on my machines
 or any machine working in networks i am responsible for
 
  a prerequisite for develop network applications is understanding of
 network basics and if your application don't use networking you are not
 affected
 
 
  --
 
 
 Lets say I do have an understanding of network basics, just for the sake of
 argument.  I share my application with you.  The application is intended to
 listen on the network, you know this and want the application for that
 purpose.  You run the application, it tries to listen to a network port.
 Magick, prayers, and the ghost of Charles Babbage - or maybe some
 hypothetical dbus service- does *something* to find out if you really
 wanted that.  You did.  Neither one of us is is made incompetent by the
 convenience.
 
 Here's the thing: firewalld will let this happen.  at here is a dbus
 interface.  Thomas has proven more than willing to accommodate RFEs. Nobody
 is asking for changes that would solve the problem of frustrated users or
 developers encountering firewall restrictions.  The GNOME folks don't want
 the UX compromise of rote-clicked dialogs.  Nobody else is suggesting an
 alternative implementation that actually *improves* the Fedora experience.
 Ideas get more traction than complaints.

Gnome doesn't want a dialog.  What other choice is there then besides
1) remove firewall?  Because any other choice basically a convoluted
equivalent to #1.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mozilla enabled ads in Firefox and they're active in Fedora

[Chuck Anderson]

On Sat, Nov 15, 2014 at 02:25:48PM +0100, Lars Seipel wrote:
 So Mozilla has recently gone live with its advertisement tiles on the
 New Tab page. Only newly created profiles get to see this stuff.

I started seeing the advertisement tiles on my existing profile.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] epel-release: consider adding %epel macro ?

[Chuck Anderson]

On Mon, Oct 20, 2014 at 08:56:35PM -0500, Rex Dieter wrote:
 Jeff Sheltren wrote:
 
  On Mon, Oct 20, 2014 at 3:11 PM, Rex Dieter
  rdie...@math.unl.edu wrote:
 
 
  ping, any comment or objection?
 
  I'll work on a patch for epel-release to implement a %{epel} macro, in
  case anyone was waiting for implementation details.
 
 
  Seems like it can't hurt much to have such a macro defined by the
  epel-release package.  Could you give an example of the kind of logic
  you'd use this for?
 
 Sure.  My primary motivation is that I'd like be able keep fedora/rhel kde 
 packaging merged in fedora's git repos.  *Normally*, rhel kde packaging 
 disables some features ( based on %rhel macro), but I'd like to be able 
 (re)enable those via some extras macro, like %epel.  This is one approach 
 redhat's kde maintainers agreed would be acceptable.

How would enabling features at build-time contional on the presence of
epel-release and this macro help?  Will you be building in two
environments and creating two repositories--one for RHEL binaries and
one for RHEL+EPEL binaries?
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: The xtrace package needs to be removed from Fedora

[Chuck Anderson]

On Thu, Aug 21, 2014 at 02:13:43PM +0100, David Howells wrote:
 David Howells dhowe...@redhat.com wrote:
 
   I can see a fedpkg retire option for removing it from Rawhide
  
  Which doesn't work, possibly due to a script error:
  
  ERROR:rpkg:Could not retire package: 'Namespace' object has no 
  attribute 'msg'
 
 Fixed in fedpkg-1.18-1 (bz 1107646).

http://fedoraproject.org/wiki/Package_Renaming_Process

http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct