Announcement: python-asyncssh license change EPL1 to EPL2/GPLv2+
Hello, fyi, with the update to the latest upstream version 1.14, the python-asyncssh package (binary subpackage: python3-asyncssh) also updated its license from 'EPL-1.0' to 'EPL-2.0 or GPLv2+' (a.k.a. as EPL-2.0 with GPLv2+ secondary license clause). See also: - Package Description: Python 3 library for asynchronous client and server-side SSH communication. It uses the Python asyncio module and implements many SSH protocol features such as the various channels, SFTP, SCP, forwarding, session multiplexing over a connection and more. - Package sources: https://src.fedoraproject.org/rpms/python-asyncssh - Upstream documented license change: https://github.com/ronf/asyncssh/issues/162 - Fedora guideline regarding announcing package license changes: https://fedoraproject.org/wiki/Licensing:Main#License_Changes Best regards Georg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Installation image layout
On Fri, Jan 04, 2019 at 09:27:33PM +0100, Georg Sauthoff wrote: > On Sun, Oct 14, 2018 at 04:35:53PM -0600, Chris Murphy wrote: > [..] > > And now it replicates extents from seed to sprout. The copy is faster > > than pvmove, rsync, dd, or rpm-ostree deploy. > > This sounds great! > > I just tried it (on Fedora 29), but those steps don't work for me: > > # cryptsetup --readonly luksOpen /dev/nbd0p4 tmp > # mount -o noatime /dev/mapper/tmp /mnt/tmp > # mount: /mnt/tmp: WARNING: device write-protected, mounted read-only. > # btrfs device add /dev/nbd1 /mnt/tmp > Performing full device TRIM /dev/nbd1 (4.00GiB) ... > ERROR: error adding device '/dev/nbd1': Read-only file system > > Am I missing something? Ok, a necessary condition for creating a sprout is setting the seed parameter on the source filesystem (via btrfstune). [1] (with the seed parameter a mount of that FS is automatically read-only) Thus, this works for me: # cryptsetup luksOpen /dev/nbd0p4 tmp # btrfstune -S 1/dev/mapper/tmp # mount -o noatime /dev/mapper/tmp /mnt/tmp # mount: /mnt/tmp: WARNING: device write-protected, mounted read-only. # btrfs device add /dev/nbd1 /mnt/tmp Performing full device TRIM /dev/nbd1 (2.80GiB) ... # mount -o remount,rw /mnt/tmp # time btrfs device remove /dev/mapper/tmp /mnt/tmp # umount /mnt/tmp Best regards Georg Sauthoff [1]: btrfstune is also mentioned in the previously referenced https://btrfs.wiki.kernel.org/index.php/Seed-device article ___ 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
bugzilla-requests recipient rejected (was: Re: Spam/scam links in bugzilla)
On Thu, Nov 01, 2018 at 05:10:37PM +, Alasdair G Kergon wrote: > If anyone spots any more, please open a ticket by emailing bugzilla-requests > @redhat.com and one of us will clean it up. I just tried that but my email was rejected: : host mx1.redhat.com[209.132.183.28] said: 554 5.7.1 : Recipient address rejected: Access denied (in reply to RCPT TO command) My original report: > Subject: Bugzilla Comment Spam in Bug 1489554 > > https://bugzilla.redhat.com/show_bug.cgi?id=1489554#c178 is a spam > comment. > > Can you remove it? Best regards Georg -- '*Warning:* Never, *never*, *NEVER* use Python string concatenation (+) or string parameters interpolation (%) to pass variables to a SQL query string. Not even at gunpoint.' (Psycopq 2.7.4.dev0, Basic module usage, 2017) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Installation image layout
On Sun, Oct 14, 2018 at 04:35:53PM -0600, Chris Murphy wrote: [..] > Ha! I just realized after all this time that the Btrfs wiki does not > make clear how to make a sprout, even though it mentions the more > esoteric recursive seed.[1] Of course you can mkfs.btrfs, mount it, > and send/receive. But send requires read only snapshots. Making a > sprout is easier, you just remove the seed device. This is supported > since 2009. > > # losetup -r /dev/loop0 root.img > # mount /dev/loop0 /mnt/ > # btrfs device add /dev/sda3 /mnt > # mount -o remount,rw /mnt > # btrfs device remove /dev/loop0 /mnt > > And now it replicates extents from seed to sprout. The copy is faster > than pvmove, rsync, dd, or rpm-ostree deploy. This sounds great! I just tried it (on Fedora 29), but those steps don't work for me: # cryptsetup --readonly luksOpen /dev/nbd0p4 tmp # mount -o noatime /dev/mapper/tmp /mnt/tmp # mount: /mnt/tmp: WARNING: device write-protected, mounted read-only. # btrfs device add /dev/nbd1 /mnt/tmp Performing full device TRIM /dev/nbd1 (4.00GiB) ... ERROR: error adding device '/dev/nbd1': Read-only file system Am I missing something? Best regards Georg -- 'NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION!' (http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000239.html) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
zlib compress bit-identical output on different archs - goal or non-goal?
Hello, during packaging of a new python-img2pdf version I noticed that 2 unit-test cases fail on aarch64. This is caused by zlib.compress() yielding different output on aarch64 and x86-64. Which triggers the failure because the unit-test case just compares the result after compression (it's a small PDF that contains a compressed image - and that PDF is compared against a reference PDF). I checked the aarch64 compress output and it's valid zlib data, i.e. I can decompress it on both aarch64 and x86-64 and get the same decompression result (i.e. the input image data). As far as I understand RFC 1951, it allows for different implementations to yield differing compress output bit-streams - as long as other requirements are met and uncompress(compress(x)) == x (in any combination of implementations). Funnily, the img2pdf author uses Debian, and Debian aarch64 zlib.compress() *does* yield bit-identical output (to x86-64). Perhaps the deviating Fedora aarch64 behaviour is due to different compile options/patches (e.g. some Neon optimization or something like that). The img2pdf author isn't really convinced that zlib may produce different output on different architectures: https://gitlab.mister-muffin.de/josch/img2pdf/issues/51 Any thoughts? Best regards Georg -- 'I have long really held the opinion that the amount of noise which any one can bear undisturbed stands in inverse proportion to his mental capacity, and therefore may be regarded as a pretty fair measure of it.' (Arthur Schopenhauer, The World As Will And Idea. Vol. 2, p.199, 1883) ___ 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
dracut-sshd in fedora - ssh access to early cryptsetup/dracut shell
Hello, so I wrote dracut-sshd - a dracut module that adds sshd to the initramfs such that one is able to remotely access early userspace for e.g. unlocking an encrypted root filesystem or dealing with the dracut emergency shell: https://github.com/gsauthof/dracut-sshd I would like to add it to Fedora because it adds important functionality that is currently missing. There are basically two routes: 1) Integrate it into upstream dracut (and package it as new package in Fedora) 2) Package it independently and submit a review request to the Fedora bugzilla (I could maintain that package) In May, 2018 I posted to the dracut mailing list (https://www.spinics.net/lists/linux-initramfs/msg04617.html), but I didn't receive any reply on that list. Thus, I lean towards following route 2) now. Any comments/suggestions? See also: - dracut-sshd copr repository for f28/f29/c7 https://copr.fedorainfracloud.org/coprs/gsauthof/dracut-sshd/ - Travis-CI continuous integration (tests run on f29/c7) https://travis-ci.org/gsauthof/dracut-sshd - >9 year old open Fedora Bug about this feature Dracut + encrypted root + networking https://bugzilla.redhat.com/show_bug.cgi?id=524727 My comment there: https://bugzilla.redhat.com/show_bug.cgi?id=524727#c28 Best regards Georg -- https://gms.tf/ 'You're not paranoid if they are after you.' (in Steven T. Wax, 2008) ___ 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: dracut-sshd in fedora - ssh access to early cryptsetup/dracut shell
On Sun, Jan 27, 2019 at 06:41:10PM +0100, Steve Grubb wrote: > The biggest problem in dealing with crypto early in boot is that the > system is starved for entropy. I'm wondering if this runs before or > after systemd loads the saved entropy seed into the kernel? On bare-metal, I didn't notice real problems regarding low entropy during the early sshd startup. I just noticed sometimes that sshd took a bit longer than usual to startup (due to low entropy). Perhaps this isn't the only reason, but I suspect that the usual network 'noise' and a ping I have running when I reboot a remote machine is sufficient for the remote machine to build up enough entropy in reasonable time. With the CI suite rapidly starting VMs, possibly inside a VM, I noticed serious entropy starving which resulted in slow sshd startup or even timeouts (with the early and late sshd), sometimes. Which resulted in pseudo-randomly failing tests, of course. Thus, my solution to this is to add `-device virtio-rng-pci` to the QEMU call. And when running the tests locally I also start haveged (on the host). This is not necessary in the Travis-CI environment. Best regards Georg -- 'Correction of ASN.1 syntax definition errors introduced by automatic Word correction.' (TD.57 specification version 29.2, 2011) ___ 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: dracut-sshd in fedora - ssh access to early cryptsetup/dracut shell
On Sun, Jan 27, 2019 at 10:04:43AM -0500, Neal Gompa wrote: > If you'd like to integrate this into dracut proper, just propose it as > a pull request to dracut itself: https://github.com/dracutdevs/dracut > > Alternatively, you can become a packager in Fedora and follow the new > package process: > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#How_to_join_the_Fedora_Package_Collection_Maintainers.3F I'm already a packager in Fedora. Best regards Georg -- '*Warning:* Never, *never*, *NEVER* use Python string concatenation (+) or string parameters interpolation (%) to pass variables to a SQL query string. Not even at gunpoint.' (Psycopq 2.7.4.dev0, Basic module usage, 2017) ___ 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: Policy regarding redundant dependencies
On Wed, Mar 27, 2019 at 03:04:53PM +, Richard W.M. Jones wrote:
> On Tue, Mar 26, 2019 at 06:07:05PM +0100, Georg Sauthoff wrote:
> > because rpm automatically adds something like:
> >
> > libfoo.so.1()(64bit)
> >
> > Of course, I could still add a superfluous
> >
> > Requires: libfoo
> This could pull in the 32 bit version of the package so it's wrong as
> well as redundant. (You'd want to use %{_isa} I think)
> Is there a reason why you want to add extra Requires lines?
I don't want to add extra Requires lines.
On the contrary, I want to remove an extra Requires line but was
challenged by the maintainer to keep it (without providing a convincing
reason, I would say):
https://src.fedoraproject.org/rpms/maildrop/pull-request/1
Thus, to finally resolve this issue I googled for the Fedora policy,
without finding the relevant section - thus I asked on this list.
Best regards
Georg
--
Hofstadter's Law: "It always takes longer than you think it will
take, even when you take into account Hofstadter's Law"
___
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
Policy regarding redundant dependencies
Hello, when packaging a C/C++ program, the rpm automatic dependency feature usually works well for shared libraries. That mean when program 'bar' needs libfoo-devel at build time it's sufficient to add BuildRequires: libfoo-devel and I can omit Requires: libfoo because rpm automatically adds something like: libfoo.so.1()(64bit) Of course, I could still add a superfluous Requires: libfoo and then the resulting binary package would contain a redundant dependency like this: libfoo libfoo.so.1()(64bit) Has Fedora a policy against such redundant dependencies? Best regards Georg ___ 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
Policy regarding service preset enabled (e.g. performance co-pilot)
Hello,
is there a policy regarding auto-enabling/disabling an installed systemd
service?
I'm asking because installing the dstat replacement[1] in Fedora 29
resulted in 3 additional always running systemd services[2] and 2 open
ports.
In contrast, after installing postgresql the postgresql systemd service
has vendor preset disabled (i.e. it is disabled, by default).
Perhaps it's just me, but having 3 services enabled after installing the
dstat replacement ('which strives for 100% output compatibility with the
original dstat') feels like a violation of the principle of least
astonishment.
Best regards
Georg
[1]: i.e. pcp-system-tools
cf. https://fedoraproject.org/wiki/Changes/MergeDstatAndPerformanceCoPilot
[2]: pmcd, pmlogger and pmie
___
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: Policy regarding service preset enabled (e.g. performance co-pilot)
Hello,
On Sun, Feb 10, 2019 at 10:08:51AM +1100, Nathan Scott wrote:
> On Sun, Feb 10, 2019 at 6:47 AM Georg Sauthoff wrote:
> > [...]
> > I'm asking because installing the dstat replacement[1] in Fedora 29
> > resulted in 3 additional always running systemd services[2] and 2 open
> > ports.
> The new dstat script resides in the pcp-system-tools sub-package of
> PCP. This package depends on python3, python3-pcp and pcp-libs. None
> of these packages contain systemd services.
The {pmcd,pmlogger,pmie}.service files are provided by the 'pcp'
package. And pcp-system-tools *does* depend on pcp. See also:
# dnf remove pcp
Dependencies resolved.
PackageArch Version Repository Size
Removing:
pcpx86_64 4.3.0-3.fc29 @updates 4.2 M
Removing dependent packages:
pcp-system-tools x86_64 4.3.0-3.fc29 @updates 620 k
[..]
> I wonder if you have installed the (optional) pcp-zeroconf package,
> Georg? This is a convenience package which automates setup of
No, I don't have it installed:
# rpm -q pcp-zeroconf
package pcp-zeroconf is not installed
> frequently needed PCP services for use in customer support situations.
> You do not need to install this package to use dstat.
As-is, because of the dependencies (see above) I have to install them.
> The new dstat does not require running services, by default it runs in
Yes, this is true, the service don't need to be running for the new dstat.
> a standalone fashion.
[..]
> > Perhaps it's just me, but having 3 services enabled after installing the
> > dstat replacement ('which strives for 100% output compatibility with the
> > original dstat') feels like a violation of the principle of least
> > astonishment.
> Agreed - that's why the code is written the way it is, and the
> packages are structured the way they are. It is not the case that you
> need to have 3 additional services running when using the new dstat.
The problem is that pmie/pmcd/pmlogger are enabled by default because they have
their 'vendor preset' configured to 'enabled'. See also:
# systemctl status pmie pmcd pmlogger
● pmie.service - Performance Metrics Inference Engine
Loaded: loaded (/usr/lib/systemd/system/pmie.service; disabled; vendor
preset: enabled)
[..]
# find /usr/lib/systemd -name '*.preset' | xargs grep
'\<\(pmcd\|pmlogger\|pmie\)'
/usr/lib/systemd/system-preset/90-default.preset:enable pmcd.service
/usr/lib/systemd/system-preset/90-default.preset:enable pmlogger.service
/usr/lib/systemd/system-preset/90-default.preset:enable pmie.service
# dnf provides /usr/lib/systemd/system-preset/90-default.preset
fedora-release-29-7.noarch : Fedora release files
[..]
Do I need to create a Bugzilla tickets for fixing the pcp dependencies and
presets or do you take care of it?
Best regards
Georg
--
https://gms.tf/
___
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: Policy regarding service preset enabled (e.g. performance co-pilot)
On Mon, Feb 11, 2019 at 07:53:57AM -0500, Stephen Gallagher wrote:
> On Sun, Feb 10, 2019 at 4:40 AM Georg Sauthoff wrote:
> > On Sun, Feb 10, 2019 at 10:08:51AM +1100, Nathan Scott wrote:
> > > On Sun, Feb 10, 2019 at 6:47 AM Georg Sauthoff wrote:
> > > > [...]
> > > > I'm asking because installing the dstat replacement[1] in Fedora 29
> > > > resulted in 3 additional always running systemd services[2] and 2 open
> > > > ports.
[..]
> For the record, a Bugzilla ticket was filed when these were originally
> added (and if you looked at 90-default.preset instead of just grepping
> it, you'd notice that it was in a comment immediately above those
> enablements).
>
> The BZ is https://bugzilla.redhat.com/show_bug.cgi?id=1472350 and
> included the following text when it was filed:
>
> """
>
> * Does the service listen on a network socket for connections
> originating on a separate physical or virtual machine?
> Both pmcd and pmlogger can be configured to do so. However, for the
> purpose of this bugzilla and being enabled upon install, the default
> will be configured for with no listening on network sockets
> (adjustable later by the end-user if desired).
>
> """
>
> Because the default configuration did not (at the time) open any
> network sockets for listening, it was approved without FESCo
> exception, because it was within the guidelines from
> https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/#_enabling_services_by_default
> If you are asserting that it now *does* listen on those sockets by
> default, that's a problem and we need to open a FESCo ticket.
Yes, I'm asserting this and I already asserted it in my original mail.
See also:
# ss -lntp | grep 'pmlogger\|pmcd' | column -t
LISTEN 0 5 0.0.0.0:4330 0.0.0.0:* users:(("pmlogger",pid=6353,fd=9))
LISTEN 0 5 0.0.0.0:44321 0.0.0.0:* users:(("pmcd",pid=1135,fd=0))
LISTEN 0 5 [::]:4330 [::]:* users:(("pmlogger",pid=6353,fd=10))
LISTEN 0 5 [::]:44321 [::]:* users:(("pmcd",pid=1135,fd=3))
And yes, all I did on that machine regarding pcp was to execute a
`dnf install pcp-system-tools` to get the `dstat` command.
There are basically 2 issues:
1) The dependencies of the package that provides the dstat replacement
(i.e. pcp-system-tools)
2) The vendor presets of the pmlogger/pmcd/pmie services
(which are currently provided by pcp)
Perhaps we can agree to fix the current state to this user experience:
-- User wants to use dstat
=> User learns that the original dstat was replaced by the pcp tool of
the same name
=> User installs the pcp package that provides the dstat replacement
(e.g. pcp-system-tools)
=> User can successfully use the `dstat` command which behaves as the
old dstat command
=> No additional services are running
=> No additional ports are open
There are different ways to improve the user experience in that way:
a) Fix the dependencies of pcp-system-tools such that it doesn't require
the pcp package (which provides the pmcd/pmlogger/pmie services),
and/or
b) Change the vendor presets for the pmcd/pmlogger/pmie services to
disabled, or
c) Change the packaging in some other way
Best regards
Georg
___
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: Help needed with meson build for modem-manager-gui
On Sun, Feb 03, 2019 at 07:24:17PM -, Artur Iwicki wrote: Hello, [..] > The tl;dr version is that there seems to be some kind of race condition in > the build script, and sometimes it will run into a situation where it tries > to install a file that hasn't been created yet - this most often happens with > translation files. > If you want to help out, here's the most recent build log: > https://kojipkgs.fedoraproject.org//work/tasks/3908/32513908/build.log perhaps the root-cause is itstool - i.e. it errors out some time before the error message at the end of the log: BUILDSTDERR: Installing /builddir/build/BUILD/modem-manager-gui-0.0.19.1/resources/modem-manager-gui-symbolic.svg to /builddir/build/BUILDROOT/modem-manager-gui-0.0.19.1-5.fc30.x86_64/usr/share/icons/hicolor/symbolic/appsTraceback (most recent call last): BUILDSTDERR: File "/usr/bin/itstool", line 1611, in BUILDSTDERR: doc.merge_translations(translations, opts.lang, strict=opts.strict) BUILDSTDERR: File "/usr/bin/itstool", line 997, in merge_translations BUILDSTDERR: lcpar = lcpar.parent BUILDSTDERR: File "/usr/lib64/python3.7/site-packages/libxml2.py", line 296, in get_parent BUILDSTDERR: return nodeWrap(ret) BUILDSTDERR: File "/usr/lib64/python3.7/site-packages/libxml2.py", line 580, in nodeWrap BUILDSTDERR: if name[0:8] == "document": BUILDSTDERR: TypeError: 'NoneType' object is not subscriptable There is an open bug report that describes some similar non-determistic itstool behaviour - when called from gmake: https://github.com/itstool/itstool/issues/21 Best regards Georg ___ 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: Inconsistent dnf provides result
Hello, On Sat, Jun 01, 2019 at 11:28:37AM -0700, Samuel Sieb wrote: > On 6/1/19 10:40 AM, Georg Sauthoff wrote: > > $ mkdir -p o ; rpm2cpio dpm-copy-server-mysql-1.12.0-2.fc29.x86_64.rpm > > | cpio -di -D o -v > Why are you going through cpio, instead of just using rpm itself? because I want to read the man-page without installing the package. > $ rpm -qlp dpm-copy-server-mysql-1.12.0-2.fc29.x86_64.rpm > /etc/dpm-mysql/dpmcopyd.logrotate > /etc/logrotate.d/dpmcopyd > /usr/lib/.build-id > /usr/lib/.build-id/70/bf043a9b1a0954bb464faa59261f8edb0564d3 > /usr/lib/systemd/system/dpmcopyd.service > /usr/lib64/dpm-mysql/dpmcopyd > /usr/lib64/dpm-mysql/dpmcopyd.8 This still looks wrong. > /usr/sbin/dpmcopyd > /usr/share/dpm-mysql > /usr/share/dpm-mysql/dpmcopyd.service > /usr/share/man/man8/dpmcopyd.8.gz Strange. > I don't know why cpio isn't seeing the files. Did you try installing the > package? I don't want to do that because it pulls in a whole bunch of other No. > dependencies I don't want. Exactly. Best regards Georg ___ 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: Inconsistent dnf provides result
On Sat, Jun 01, 2019 at 09:29:33PM +0200, Georg Sauthoff wrote:
> > $ rpm -qlp dpm-copy-server-mysql-1.12.0-2.fc29.x86_64.rpm
> > /etc/dpm-mysql/dpmcopyd.logrotate
> > /etc/logrotate.d/dpmcopyd
> > /usr/lib/.build-id
> > /usr/lib/.build-id/70/bf043a9b1a0954bb464faa59261f8edb0564d3
> > /usr/lib/systemd/system/dpmcopyd.service
> > /usr/lib64/dpm-mysql/dpmcopyd
> > /usr/lib64/dpm-mysql/dpmcopyd.8
>
> This still looks wrong.
>
> > /usr/sbin/dpmcopyd
> > /usr/share/dpm-mysql
> > /usr/share/dpm-mysql/dpmcopyd.service
> > /usr/share/man/man8/dpmcopyd.8.gz
>
> Strange.
>
> > I don't know why cpio isn't seeing the files. Did you try installing the
This is caused by use of the %ghost directive in the %files
section of the .spec file:
%files -n dpm-copy-server-mysql
%{_libdir}/dpm-mysql/dpmcopyd
%ghost %{_sbindir}/dpmcopyd
%doc %{_libdir}/dpm-mysql/dpmcopyd.8*
%ghost %{_mandir}/man8/dpmcopyd.8*
Apparently %ghost marks those files as belonging to the package but
doesn't include them in the package. Thus, they aren't part of the cpio
archive. Common use-case for this seems to be log-files - such that they
are removed on package removal.
Anyhow, those lines look like a bug to me:
%doc %{_libdir}/dpm-mysql/dpmcopyd.8*
%ghost %{_mandir}/man8/dpmcopyd.8*
And the other question now is: Should `dnf provides` include ghost files
in its output?
I mean, the package really doesn't provide those ghost files ...
Best regards
Georg
--
'Apple denies that, based on their common meaning, the words "app
store" together denote a store for apps.'
http://www.theregister.co.uk/2011/05/20/apple_amazon_trademark_spat/
___
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
Inconsistent dnf provides result
Hello, I noticed a case where the `dnf provides` output is inconsistent. That means the actual rpm package doesn't provide the requested file: # cat /etc/fedora-release Fedora release 29 (Twenty Nine) # dnf provides /usr/share/man/man8/dpmcopyd.8.gz dpm-copy-server-mysql-1.12.0-2.fc29.x86_64 : DPM copy server with MySQL database : back-end Repo: updates Matched from: Filename: /usr/share/man/man8/dpmcopyd.8.gz But: $ dnf download dpm-copy-server-mysql Last metadata expiration check: 1:46:49 ago on Sat 01 Jun 2019 05:31:01 PM CEST. dpm-copy-server-mysql-1.12.0-2.fc29.x86_64.rpm $ mkdir -p o ; rpm2cpio dpm-copy-server-mysql-1.12.0-2.fc29.x86_64.rpm | cpio -di -D o -v ./etc/dpm-mysql/dpmcopyd.logrotate ./usr/lib/.build-id ./usr/lib/.build-id/70/bf043a9b1a0954bb464faa59261f8edb0564d3 ./usr/lib64/dpm-mysql/dpmcopyd ./usr/lib64/dpm-mysql/dpmcopyd.8 ./usr/share/dpm-mysql ./usr/share/dpm-mysql/dpmcopyd.service 1589 blocks $ ls -l o/usr/share/man/man8/dpmcopyd.8.gz ls: cannot access 'o/usr/share/man/man8/dpmcopyd.8.gz': No such file or directory That means there is no /usr/share/man/man8/dpmcopyd.8.gz - just: ./usr/lib64/dpm-mysql/dpmcopyd.8 Ok, I guess I could open a bug against dpm-copy-server-mysql - regarding fixing the location of the manpage. But what about the `dnf provides` output? It looks like something is going wrong in the process that generates the file-index. Should I open a bug for this, as well? And where? Best regards Georg -- 'The complexity for minimum component costs has increased at a rate of roughly a factor of two per year ... Certainly over the short term this rate can be expected to continue, if not to increase.' (Moore's law, 1965) ___ 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: Inconsistent dnf provides result
On Sat, Jun 01, 2019 at 11:14:40PM -0700, Samuel Sieb wrote: > On 6/1/19 12:29 PM, Georg Sauthoff wrote: > > On Sat, Jun 01, 2019 at 11:28:37AM -0700, Samuel Sieb wrote: > > > On 6/1/19 10:40 AM, Georg Sauthoff wrote: > > > > $ mkdir -p o ; rpm2cpio > > > > dpm-copy-server-mysql-1.12.0-2.fc29.x86_64.rpm | cpio -di -D o -v > > > > > Why are you going through cpio, instead of just using rpm itself? > > > > because I want to read the man-page without installing the package. > It looks like you do have the man page anyway, just in a different > directory. But you could file a bug on the "lcgdm" package in bugzilla. yes, this is basically what I wrote in my original email in this thread. Best regards Georg -- 'FROM: 221 2.7.0 Error: I can break rules, too. Goodbye.' (Postfix 2.10, 2014) ___ 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: Inconsistent dnf provides result
On Sun, Jun 02, 2019 at 08:04:25AM +0100, Sérgio Basto wrote:
> On Sat, 2019-06-01 at 21:47 +0200, Georg Sauthoff wrote:
> > This is caused by use of the %ghost directive in the %files
> > section of the .spec file:
> >
> > %files -n dpm-copy-server-mysql
> > %{_libdir}/dpm-mysql/dpmcopyd
> > %ghost %{_sbindir}/dpmcopyd
> > %doc %{_libdir}/dpm-mysql/dpmcopyd.8*
> > %ghost %{_mandir}/man8/dpmcopyd.8*
> >
> > Apparently %ghost marks those files as belonging to the package but
> > doesn't include them in the package. Thus, they aren't part of the
> > cpio
> > archive. Common use-case for this seems to be log-files - such that
> > they
> > are removed on package removal.
> Sort of, after lines 1023 [1] we understand the reason this package use
> alternatives , the really location on file is /usr/lib64/dpm-
Good find.
> mysql/dpmcopyd.8 so [2] should work
>
> [2]
> dnf provides /usr/lib64/dpm-mysql/dpmcopyd.8
I never questioned that `dnf provides /usr/lib64/dpm-mysql/dpmcopyd.8`
would work. It does. It's just a non-standard location and thus nothing
I would try when searching for the man page of dpmcopyd with `dnf
provides`.
Note that all the man-pages under Fedora a gzip-compressed, while this
file isn't.
> [1]
> https://src.fedoraproject.org/rpms/lcgdm/blob/master/f/lcgdm.spec#_1023
But does this even work?
%{_sbindir}/update-alternatives --install %{_sbindir}/dpmcopyd dpmcopyd \
%{_libdir}/dpm-mysql/dpmcopyd 20 \
--slave %{_mandir}/man8/dpmcopyd.8.gz dpmcopyd.8.gz \
%{_libdir}/dpm-mysql/dpmcopyd.8.gz
I mean the archive just contains:
usr/lib64/dpm-mysql/dpmcopyd.8
where:
$ file o/usr/lib64/dpm-mysql/dpmcopyd.8
o/usr/lib64/dpm-mysql/dpmcopyd.8: ASCII text, with escape sequences
While the update-alternatives commands references:
%{_libdir}/dpm-mysql/dpmcopyd.8.gz
Best regards
Georg
--
'If you think this sentence is confusing, then change one pig.'
(Hofstadter, 2007)
___
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: Using SCLs to build a C++ library for EL 7?
On Tue, Apr 30, 2019 at 08:58:08AM +0100, Jonathan Wakely wrote: > On 29/04/19 18:16 +0200, Georg Sauthoff wrote: > > On Mon, Apr 29, 2019 at 05:11:53PM +0200, Dan Čermák wrote: > > > John Reiser writes: > > [..] > > > > What is the nature of the incompatibilities, and what are specific > > > > examples? > > > > > > We switched to from the POSIX regex library to as it should be > > > provided by a C++11 compatible compiler. Unfortunately gcc 4.8.5 does > > > not properly implement and it made a lot of tests fail. We have > > > therefore switched to using the SCL gcc & clang compiler for now. > > > > Yes, at least GCC 4.8/4.9 (with the then current libstdc++) > > featured a severely broken (e.g. also on Fedora 19). > > GCC 4.8 does, but the std::regex in 4.9 is OK. > https://stackoverflow.com/questions/12530406/is-gcc-4-8-or-earlier-buggy-about-regular-expressions/12665408#12665408 There were also some std::regex issues in 4.9, e.g.: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64302 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64303 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63497 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 (still open) Best regards Georg -- "No one can write decently who is distrustful of the reader's intelligence, or whose attitude is patronizing." (William Strunk, Jr. and E.B. White, The Elements of Style, p. 70, 1959) ___ 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: Using SCLs to build a C++ library for EL 7?
On Mon, Apr 29, 2019 at 05:11:53PM +0200, Dan Čermák wrote: > John Reiser writes: [..] > > What is the nature of the incompatibilities, and what are specific > > examples? > > We switched to from the POSIX regex library to as it should be > provided by a C++11 compatible compiler. Unfortunately gcc 4.8.5 does > not properly implement and it made a lot of tests fail. We have > therefore switched to using the SCL gcc & clang compiler for now. Yes, at least GCC 4.8/4.9 (with the then current libstdc++) featured a severely broken (e.g. also on Fedora 19). If it's just an alternative is to fallback to Boost regex - e.g. like this: #ifdef SOME_MACRO_THAT_SIGNALS_PROPER_REGEX_AVAILABILITY #include namespace re = std; #else #include namespace re = boost; #endif And then use re::regex re::regex_match etc. in your code. Best regards Georg -- 'Embrace change' (Barack Ob^W^WKent Beck) ___ 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
manpath.be, man page package checks/policy
Hello, so I've created https://manpath.be - a site that provides access to the man pages of several distributions - including several Fedora and CentOS versions. See also its about page https://manpath.be/about for some of its features (e.g. permalinks, short links, reverse links ...). While working on this project I noticed a few issues with the man pages of Fedora packages: Some packages include man pages auto-generated by doxygen. In my experience, those man pages are usually pretty human un-readable and thus quite useless. Thus, I exclude them from manpath.be. Example: LAPACKE_cgges3_work(3) from the lapack package That package contains 10 thousand or so auto-generated man pages. Perhaps it makes sense to recommend packagers to exclude doxygen generated man pages from Fedora packages. For example, as part of the packaging policy. Perhaps it also makes sense to add some man-page related checks to rpmlint or fedora-review (?), e.g. to check - if a package creates sub-directories under /usr/share/man/man*/ Example: https://bugzilla.redhat.com/show_bug.cgi?id=1722350 - if a man page is empty - if a man page redirects to itself Example: https://bugzilla.redhat.com/show_bug.cgi?id=1720942 - if a man page has non-standard suffixes like 1.orig.gz instead of 1.gz - if the suffix of a man page matches the one of its subdirectory Examples: https://bugzilla.redhat.com/show_bug.cgi?id=1722440 https://bugzilla.redhat.com/show_bug.cgi?id=1722447 - if a man page contains verbatim escape sequences Example: https://bugzilla.redhat.com/show_bug.cgi?id=1725301 - if the man page display produces groff/grotty warnings/errors Example: https://bugzilla.redhat.com/show_bug.cgi?id=1725402 Thoughts? Best regards Georg ___ 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: manpath.be, man page package checks/policy
On Sun, Jul 14, 2019 at 04:49:40PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Jul 13, 2019 at 04:19:02PM +0200, Georg Sauthoff wrote: [..] > > See also its about page https://manpath.be/about for some of its > > features (e.g. permalinks, short links, reverse links ...). > > Looks interesting. One thing that seems missing at first sight is > search: it'd be great to have interactive search across sections. > Right now, it's only easy to find a page is one knows the section > and the exact name. Right now you can google search the site like this: memory management site:manpath.be/f30 This turns up the malloc and fork man pages, for example. I plan to add a search feature to the site. Probably first a search form in the left column that redirects the query to a google search like in the above example. In a second step perhaps I'll also add some internal search functionality. > One issue that I had before with similar services was that it was > never possible to rely on any given one to provide _all_ man > pages. In systemd we link to man pages online from online versions > of our pages under http://www.freedesktop.org/software/systemd/man/index.html, > and we have to link to a bunch of different services > (man7.org, linux.die.net, mankier.com), because we need to link > to kernel man pages, and various fringe tools, some distro-specific > man pages, etc. Two suggestions: 1. pull pages from many different My approach for Fedora/CentOS is to import all valid man pages from all available packages (i.e. what is available if you just enable the fedora/base + updates repositories). Thus, with respect to Fedora/CentOS the man page repository should be pretty complete. I plan to add more distributions/versions in the future. > sources, 2. include a suggestion box for people to mention what > they can't find. There is a suggestion feature when a requested page isn't found but is available in another section. For example: https://manpath.be/f30/2/popen yields: Page not found (404) No such man page: popen(2) Similar pages: popen(3) popen(3p) (where the alternatives are linked) If you navigate to a page that is available in a certain section but also in others the right column lists the alternatives - in case one wasn't aware of the alternatives - and/or used a suboptimal section. Example: https://manpath.be/f30/1/write lists the alternatives: write(1p), write(2) and write(3p) Best regards Georg ___ 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: How do I remove GLIBCXX_ASSERTIONS?
On Sat, Aug 03, 2019 at 07:29:34PM -0400, Sam Varshavchik wrote:
> I believe that the following construct trips this assertion:
>
> # std::vector foo;
> #
> # std::vector bar;
> #
> # // Populate foo with something.
> #
> # std::copy([0], [foo.size()], std::back_insert_iterator{bar});
It's true that something like
copy([0], [foo.size()], back_inserter(bar));
triggers an assertion when compiled with -D_GLIBCXX_ASSERTIONS. Because
the checking code just can't look at the context of its invocation.
Which is fine, because you really don't need to use such constructs.
> There's nothing wrong with this. There is no out of bounds access. I do not
> believe that this is undefined behavior. The defined semantics of
> std::vector, and its operator[], are well defined here.
It's defined behaviour but there is something wrong with it: it isn't
idiomatic C++ and it's tedious and error-prone.
> I ran into these new assertions with my own code as well, after updating to
> F28 (where they were enabled by default the first time, IIRC, not sure why
> this shows up only now, for that package).
>
> I ended up tweaking my code to avoid the assertions, rather than disabling
> them. For this particular situation, my original change was to try
>
> std::copy([0], [0]+foo.size(), std::back_insert_iterator{bar});
>
> But that still tripped the assertion when the foo vector was empty, so I had
> wrap this inside an if().
But why don't you use the idiomatic
copy(foo.begin(), foo.end(), back_inserter(bar));
?
No need to wrap it into an extra if statement.
With GCC, the generated code is basically the same as when using:
copy(foo.data(), foo.data()+foo.size(), back_inserter(bar));
vector::data() is available since C++11. This doesn't trigger
any assertion and works with an empty source vector, as well.
What also works in general and doesn't trigger any assertion is the
'ultra ugly':
copy(&*foo.begin(), &*foo.end(), back_inserter(bar));
But there is also really no need to use an back_insert_iterator here - a
direct solution:
bar.insert(bar.end(), foo.begin(), foo.end());
Best regards
Georg
___
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: Better interactivity in low-memory situations
On Fri, Aug 09, 2019 at 03:50:43PM -0600, Chris Murphy wrote: [..] > Problem and thesis statement: > Certain workloads, such as building webkitGTK from source, results in > heavy swap usage eventually leading to the system becoming totally > unresponsive. Look into switching from disk based swap, to swap on a > ZRAM device. > > Summary of findings (restated, but basically the same as found at [2]): > Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM, > Samsung SSD 840 EVO, Fedora Rawhide Workstation. > Test case, build WebKitGTK from source. [..] To avoid such issues I disable swap on my machines. I really don't see the point of having a swap partition if you have 16 or 32 GiB RAM. Even with 8 GiB I disable swap. With - say - 8 GiB the build of a large project might fail (e.g. llvm, e.g. during linking) but it then fails fast and I can just restart it with `ninja -j2` or something like that. Another source of IO related unresponsiveness is buffer bloat - I thus apply this configuration on my machines: $ cat /etc/sysctl.d/01-disk-bufferbloat.conf vm.dirty_background_bytes=107374182 vm.dirty_bytes=214748364 Best regards Georg -- 'Time your programs before making claims about efficiency' (Bjarne Stroustrup, The C++ Programming Language, 4th ed., p. 132, 2013) ___ 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: koji build failure but no build.log
On Mon, Sep 09, 2019 at 12:17:09AM +0200, Miro Hrončok wrote: > On 09. 09. 19 0:08, Miro Hrončok wrote: > > On 08. 09. 19 23:41, Georg Sauthoff wrote: > > > But this build.log file isn't linked from that page. > > > > > > How come? > > > > > > Bug or feature? > > > > The build was garbage collected because it is too old. A feature. Then it would be nice if the koji would display something like Output - already deleted instead of just Output > > Attempt to rebuild the package to see the logs. Do I have enough permissions trigger a rebuild if I'm not the owner of the python-asynctest package? > BTW if you seacrh Koji for the package anme: > > https://koji.fedoraproject.org/koji/search?match=glob=package=python-asynctest > > You'll see a never build attempt that still has the logs. Ok, but why wasn't/isn't the newer build linked from that commit overview: https://src.fedoraproject.org/rpms/python-asynctest/c/f7a6e498607f4635ec76c4759e8b51b3ea9367ab?branch=master It just shows 6 older garbage collected attempts. > The problem was copied to the bug report: > > https://bugzilla.redhat.com/show_bug.cgi?id=1739895 Thanks for the link. Best regards Georg ___ 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
koji build failure but no build.log
Hello, a dependency of a package of mine lately failed to be rebuilt for Python 3.8/f32: https://src.fedoraproject.org/rpms/python-asynctest/c/f7a6e498607f4635ec76c4759e8b51b3ea9367ab The result on the build page https://koji.fedoraproject.org/koji/taskinfo?taskID=37184775 reads: > BuildError: error building package (arch noarch), mock exited with > status 1; see build.log for more information But this build.log file isn't linked from that page. How come? Bug or feature? Best regards Georg -- 'BUGS So many numbers print out that its sometimes hard to figure out what to watch.' (vmstat(1), 3BSD, 1979) ___ 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
MiniDebugInfo support in tools like objdump and nm
Hello, perhaps it's just me but the Fedora switch to MiniDebugInfo [1] looks incomplete. For example, when I want to lookup the symbols of a system binary I have to remember to use eu-readelf -Ws --elf-section /usr/bin/dd instead of just being able to use `nm`. Similarly, when disassembling parts of a system binary, `objdump` doesn't use those symbols from the .gnu_debugdata and thus the expected function symbol labels are missing and symbolized jump targets are bogus (e.g. `4ea0 <__sprintf_chk@plt+0x2540>` instead of `0x4ea0 `). Sure, gdb automatically uses the symbols from .gnu_debugdata, but sometimes it's easier/more convenient to use binutils. Are there any plans to improve the Fedora MiniDebugInfo support in tools like nm and objdump? Best regards Georg [1]: cf. https://sourceware.org/gdb/current/onlinedocs/gdb/MiniDebugInfo.html https://fedoraproject.org/wiki/Features/MiniDebugInfo https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-November/002733.html ___ 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: Disabling Python Dependency Generator Challenges
On Tue, Dec 22, 2020 at 10:48:22AM +0100, Miro Hrončok wrote: [..] > As a side note, I wonder why do you need to resort to disabling the > automatic requires generator? If the dependency on pikepdf is bogus, work > with upstream to remove it. In the mean time, sed/patch it out form upstream > metadata in %prep. [..] img2pdf is a bit special. On the one hand it prefers pikepdf for writing PDF files, but on the other hand it also support several PDF engines (including an internal one). Thus, pikedf really is optional. Since EPEL nor RHEL8 provide pikepdf it makes sense to don't depend on it then, when building for EPEL. Ok, I'll try to work-around this by either disabling the generator like you suggested or by patching the setup.py INSTALL_REQUIRES. Best regards Georg -- 'Read this manual carefully as bad input values may cause libcurl to behave badly!' curl_easy_setopt(3) ___ 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
Disabling Python Dependency Generator Challenges
Hello,
I'm trying to build a fedora package for EPEL8 on Copr and I'm wondering
where its pikepdf dependency is coming from.
I conditionally disable the python dependency generator with a 0%{?epel}
guard
(cf.
https://github.com/gsauthof/copr-fedora/blob/c4bf0d2031b529e637d085a84837325dde36f1c2/python-img2pdf/python-img2pdf.spec#L62-L72
):
%if 0%{?epel} == 0
# this is basically equivalent to adding Requires: for
# pikepdf
# pillow
#
# the generator is enabled by default, since f30 or so
%{?python_enable_dependency_generator}
%else
%{?python_disable_dependency_generator}
Requires: python3-pillow
%endif
The guard seems to work (because e.g. the in the same way disabled tests
aren't executed, as I can see from the build.log.
However, the final rpm package still depends on pikepdf:
python3.6dist(pikepdf)
(cf. the end of
https://download.copr.fedorainfracloud.org/results/gsauthof/fedora/epel-8-x86_64/01843500-python-img2pdf/build.log.gz
)
Thus, it looks like disabling the dependency generator with the
python_disable_dependency_generator macro didn't work?
Best regards
Georg
--
'There have been no suggestions that Jay-Z's fellow rapper 50
Cent could be considering a move into a different currency.'
(Rapper Jay-Z dissing the dollar. 2007,
http://news.bbc.co.uk/2/hi/7097736.stm )
___
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: replace memtest86+ with pcmemtest, needs maintainer
Hello, On Sun, Aug 1, 2021 at 7:46 PM Chris Murphy wrote: [..] > We do have memtester in the repository, which is a user space memory > tester. But I can't really assess whether it's better or worse than > one that runs in the pre-boot environment. On the one hand, less > memory is being tested (possibly quite a bit less) with a user space > tester. But on the other hand, better memory testers find bad RAM > faster. They aren't all equally effective at this. At least over in > #btrfs land, we see evidence of bad RAM sourced corruption, and > occasionally it's tedious to find it (neither memtest86 or memtest86+ > finding it, but doing a bunch of compiles of the kernel with gcc does > find it - almost like gcc is a good memory tester, however unintended, > much like btrfs and probably also zfs). [..] I can confirm, in the last instances I had to deal with memory hardware corruption and I tried memtest86+, it didn't find any memory errors. Whereas, on the same hosts, memtester quickly found them. Best regards Georg ___ 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
Looking for a package reviewer for rubygem-gist
Hello, I packaged a command line gist uploader - rubygem-gist - a few weeks ago: https://bugzilla.redhat.com/show_bug.cgi?id=1979081 So far, nobody picked it up for review. Thus, if you have experience in reviewing ruby packages it would be great if you could review it. The package is quite small and I followed Fedora's Ruby packaging guidelines. Best regards Georg ___ 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
datamash long term FTBFS - how to apply for maintainership before it's retired
Hello, Datamash was mentioned in the last long term FTBFS announcement mail. I know how to fix the datamash build [1], however, its maintainer is currently inactive. [2] I think I could manage to maintain just another Fedora package (my fas handle is: gsauthof) - so, what is the best way to request maintainership of the datamash package? The announcement stated that it's going to be retired 'around 2023-02-08'. So I'm not 100 % sure if that retirement is instant or if it's going to be orphaned first, as part of that retirement process. Should I just wait for datamash being orphaned and then take it over via some button on the package's src.fedoraproject.org project page? Or is it better do apply for maintainer somehow now to avoid the orphaned stage? Best regards, Georg [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2056736#c10 [2]: cf. ftbfs bug: https://bugzilla.redhat.com/show_bug.cgi?id=2045298 -- "Don't let two mirrors 'see' each other, this causes problems." (Allen H. Blum III, Duke Nukem 3D, Sector Tags Reference Guide, 12. Tips from the Levelord, 1996) ___ 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: List of long term FTBFS packages to be retired next week
Hello, On Tue, Jan 31, 2023 at 01:44:26PM +0100, Miro Hrončok wrote: > datamashjhladky I have a build fix ready and volunteer to maintain it such that I can apply it. My FAS handle is: gsauthof Can you add me as a maintainer for the datamash package and exclude it from next weeks retirement run? See also: - discussion of the fix: https://bugzilla.redhat.com/show_bug.cgi?id=2056736#c10 - my previous message to this list regarding preventing datamash getting retired: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/TADIVWB3QXO3ASJ246WF4X5D2F2GL4SM/ Best regards, Georg -- 'Apple denies that, based on their common meaning, the words "app store" together denote a store for apps.' http://www.theregister.co.uk/2011/05/20/apple_amazon_trademark_spat/ ___ 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
Non-responsive maintainer check for datamash
Hello, I've entered Bug 2179536 - Non-responsive maintainer check for datamash to see whether the maintainer is still interested in maintaining that package. Background: That package was almost retired, and in the last months of that retirement process the maintainer didn't respond to any related bugzilla activity: https://bugzilla.redhat.com/show_bug.cgi?id=2045298 https://bugzilla.redhat.com/show_bug.cgi?id=2056736 It just wasn't retired because a proven packager applied a patch I provided, after I brought that issue to the mailinglist. Does anyone know how to contact jhladky? Best regards, Georg -- 'This bit is cleared only by a POR/PDR or by setting the WURST bit in the PMU_CTL register.' (GD32VF103 RISC-V MCU User Manual) ___ 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: List of long term FTBFS packages to be retired next week
Hello, On Thu, Feb 02, 2023 at 09:18:51AM +0100, Vít Ondruch wrote: [..] > But other than that, retiring would not be that bad thing in your case, > because after retirement, there is 8 weeks window to unretire the package > without re-review, that way you could pick it up ... ok, good to know. I didn't find that information online. First hit was the deprecated https://fedoraproject.org/wiki/Deprecate_FTBFS_packages which links to https://docs.pagure.org/releng/ but there I couldn't find anything useful on the exact FTBFS retirement process either. Perhaps it would also make sense to include that piece of information into each FTFBS announcement mail ... --- In case this comes up again - how does unretirement work, exactly? Does one request to unretire a package via writing to this mailing list or does the process work differently? Best regards, Georg -- 'Only bad boys use such recursive calls, but only good girls use this package. Thus the problem is of minor interest.' (Listings user guide) ___ 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: List of long term FTBFS packages to be retired next week
Hello, On Thu, Feb 02, 2023 at 02:45:23PM -0300, Mathias Zavala wrote: > I’m sorry for not answering sooner! I’ll be glad to receive help with the > current state of the package. Thanks in advance you are a datamash Fedora package maintainer? Judging from the FTBFS mail/Bugzilla/https://src.fedoraproject.org/rpms/datamash it looks like jhladky (Jiri Hladky) currently is the sole maintainer? Perhaps Co-maintainers aren't displayed corrently there? Btw, what is the canonical way to look up all the maintainers of a given Fedora package? A quick google search didn't point me in the right direction ... Anyhow, you (or someone with the sufficient permissions) may add me as a Co-Maintainer for the datamash package such that I can help out with that package in the future. See also: https://docs.fedoraproject.org/en-US/fesco/Policy_for_encouraging_comaintainers_of_packages/ Best regards, Georg -- 'Setting environment variables from .travis.yml Broadcast message from root@testing-gce-259341e4-fe5b-44da-9a00-6941f50689b5 The system is going down for power off NOW!' 2016, Travis CI log of a 'failed' 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: List of long term FTBFS packages to be retired next week
Hello, On Thu, Feb 02, 2023 at 12:58:11AM +, Sérgio Basto wrote: > I built the package for you ... thank you for helping to prevent datamash from early retirement! :) Best regards, Georg -- 'Programming X is like reading one of those French philosophers where afterwards you start wondering whether you really know anything for sure.' (Thomas Thurman, from 'The Real Story Behind Wayland and X', Daniel Stone, linux.conf.au, 2013) ___ 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
