Re: Donate 1 minute of your time to test upgrades from F36 to F37
> Do you want to make Fedora 37 better? Please spend 1 minute of your time and > try to run: Hi. I've got the following errors: > Error: > Problem 1: package openjfx-devel-3:11.0.9.2-6.fc35.x86_64 requires openjfx(x86-64) = 3:11.0.9.2-6.fc35, but none of the providers can be installed > - openjfx-3:11.0.9.2-6.fc35.x86_64 does not belong to a distupgrade repository > - problem with installed package openjfx-devel-3:11.0.9.2-6.fc35.x86_64 > Problem 2: package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 requires libQt5Core.so.5(Qt_5.15.2_PRIVATE_API)(64bit), but none of the providers can be installed > - package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 requires qt5-qtbase(x86-64) = 5.15.2, but none of the providers can be installed > - qt5-qtbase-5.15.2-31.fc35.x86_64 does not belong to a distupgrade repository > - problem with installed package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 (try to add '--skip-broken' to skip uninstallable packages) Should I report them in Bugzilla (for the appropriate packages)? I use Fedora 35. Nevertheless, the F35→F37 path should be also supported. Marcin ___ 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: "Conditional recommends" for packages
On 2022-04-23 21:06, Igor Raits wrote: > Or exactly opposite: > > Supplements: (NetworkManager-sstp and gnome-shell) > > … from within NetworkManager-sstp-gnome subpackage Thanks Igor, that could be also an option, especially for the independent 3rd party extensions. Good to know. However, in my case all the three packages have the same (upstream) author and the same packager, so forward hint in sstp-client is not a problem and seems more natural. Marcin > > On Sat, Apr 23, 2022 at 8:51 PM Neal Gompa wrote: >> >> On Sat, Apr 23, 2022 at 2:32 PM Marcin Zajączkowski wrote: >>> >>> Hi. My package sstp-client (a SSTP VPN client) can be used on it's own, >>> but usually it is recommended to have also the NetworkManager-sstp >>> plugin. "Recommends" seems to be a good idea here as NM is usually >>> available by default. >>> >>> However, there is also NetworkManager-sstp-gnome which adds an applet >>> for Gnome Shell. I'm reluctant to use "Recommends" here, as it would >>> propose an user to install the whole GNOME ecosystem (assuming LXQT or >>> something else it already used instead). >>> >>> Is there a way to use "conditional recommends" to only propose >>> NetworkManager-sstp-gnome (e.g. when NetworkManager-sstp itself is >>> installed) if gnome-shell is already installed? >>> >> >> Recommends: (NetworkManager-sstp-gnome if (NetworkManager-sstp and >> gnome-shell)) >> -- https://blog.solidsoft.pl/ - Working code is not enough ___ 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: "Conditional recommends" for packages
On 2022-04-23 20:40, Neal Gompa wrote: > On Sat, Apr 23, 2022 at 2:32 PM Marcin Zajączkowski wrote: >> >> Hi. My package sstp-client (a SSTP VPN client) can be used on it's own, >> but usually it is recommended to have also the NetworkManager-sstp >> plugin. "Recommends" seems to be a good idea here as NM is usually >> available by default. >> >> However, there is also NetworkManager-sstp-gnome which adds an applet >> for Gnome Shell. I'm reluctant to use "Recommends" here, as it would >> propose an user to install the whole GNOME ecosystem (assuming LXQT or >> something else it already used instead). >> >> Is there a way to use "conditional recommends" to only propose >> NetworkManager-sstp-gnome (e.g. when NetworkManager-sstp itself is >> installed) if gnome-shell is already installed? >> > > Recommends: (NetworkManager-sstp-gnome if (NetworkManager-sstp and > gnome-shell)) That's exactly what I wanted! Big thanks! Sadly, I wasn't able to find it before in the documentation. I will have to check how to contribute to: https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/#_weak_dependencies Marcin -- https://blog.solidsoft.pl/ - Working code is not enough ___ 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
"Conditional recommends" for packages
Hi. My package sstp-client (a SSTP VPN client) can be used on it's own, but usually it is recommended to have also the NetworkManager-sstp plugin. "Recommends" seems to be a good idea here as NM is usually available by default. However, there is also NetworkManager-sstp-gnome which adds an applet for Gnome Shell. I'm reluctant to use "Recommends" here, as it would propose an user to install the whole GNOME ecosystem (assuming LXQT or something else it already used instead). Is there a way to use "conditional recommends" to only propose NetworkManager-sstp-gnome (e.g. when NetworkManager-sstp itself is installed) if gnome-shell is already installed? Marcin -- https://blog.solidsoft.pl/ - Working code is not enough ___ 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: Fedora Contributor Tee Shirt Giveaway
On 2022-04-22 20:52, Chris Murphy wrote: > On Fri, Apr 22, 2022 at 3:45 AM Vipul Siddharth > wrote: >> >> On Fri, Apr 22, 2022 at 12:49 PM Leigh Scott wrote: >>> >>> Why post something that has expired? >> Hi leigh, When I shared the email, the giveaway was still active :) >> given it was just for 24 hours, It had to expire after some time (This >> is mentioned in the blog) >> I definitely could have highlighted in the email as well! >> Hope it was useful to some > > > I tried it 15 hours after the email was posted, and it was already expired. I had a similar behavior. Maybe the limit of items were reached before that time. Marcin -- https://blog.solidsoft.pl/ - Working code is not enough ___ 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: Best way to enable -mbranch-protection for package
On 2022-04-22 11:01, Petr Pisar wrote:
> V Thu, Apr 21, 2022 at 11:12:41PM +0200, Marcin Zajączkowski napsal(a):
>> Upgrading NetworkManager-sstp to the latest version, I've noticed that
>> there is a failed test related to missing branch protection on AArch64
>> [1].
>
> Check annocheck version installed when building your package (root.log). There
> was a bug manifesting as -mbranch-protection=standard failure on AArch64 and
> fixed in 10.66:
>
> * Wed Apr 13 2022 Nick Clifton - 10.66-1
> - Annocheck: Do not complain about missing -mbranch-protection option in
> AArch64 binaries if compiled in LTO mode.
Thanks Petr! It might be that. When I increase the build verbosity I
clearly see that "-mbranch-protection=standard" is used [3] (it was
missing on my x86_64 for obvious reasons :) ).
The test itself was executed with:
> annocheck: Version 10.65.
Everything explained. Thanks.
[3] -
https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/96013/testReport/(root)/tests/_annocheck/
Marcin
>
>> After reading that and [2], I know what it is all about, however, I
>> wonder what is the best way to apply it to my package?
>>
>> Should I check if the build is for AArch64 and for Fedora 33+ (35+?) and
>> just add "-mbranch-protection=standard"? Or there is some magic macro to
>> add that (and maybe some other useful security options), similar to
>> %{?_smp_mflags} (or maybe even included in %make_build on ARM64)?
>>
> The option is already presented in system-wide CFLAGS. Check any build.log.
> If you package respects the flags (check your build.log), you don't need to do
> anything. Otherwise, you should correct your package use all the options from
> CFLAGS enviroment variable or %{build_cflags} RPM macro.
>
> -- Petr
>
___
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
Best way to enable -mbranch-protection for package
Hi,
Upgrading NetworkManager-sstp to the latest version, I've noticed that
there is a failed test related to missing branch protection on AArch64
[1]. After reading that and [2], I know what it is all about, however, I
wonder what is the best way to apply it to my package?
Should I check if the build is for AArch64 and for Fedora 33+ (35+?) and
just add "-mbranch-protection=standard"? Or there is some magic macro to
add that (and maybe some other useful security options), similar to
%{?_smp_mflags} (or maybe even included in %make_build on ARM64)?
[1] -
https://sourceware.org/annobin/annobin.html/Test-branch-protection.html
[2] - https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication
Marcin
___
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: Conflicting build-ids in chromium and chromium-freeworld
On 2020-09-21 12:08, Mark Wielaard wrote: > Hi, > > On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote: >> On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: >>> Hi. There is an ongoing problem with conflicting build-ids in chromium >>> and chromium-freeworld [1][2]: >>>> Error: Transaction test error: >>>>file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>> >>> There is no clear idea why it happens, but my assumption is that due to >>> the fact of building with the same source code (with similar patches), >>> some generated shared libraries are the same which generates conflict(s). > > The error message could probably be improved. > You might want to look at where the /usr/lib/.build-id/xx/ symlinks > are pointing at to get a better idea which binaries are identical > between the packages. > >>> The quick look at the algorithm for build-id generation [3] doesn't >>> answer my question what exactly is taken into account for their >>> generation and more precisely is there is way to add some "fuzz" (having >>> different buildroots doesn't help) to distinguish those libraries. > > The build-id is calculated over all relevant build environment bits (by > the linker, not rpm). This includes the debuginfo in the original (not > split) ELF file. The debuginfo contains the build paths (which should > be different for different NVRs and include the compiler version and > flags). This really should prevent identical build-ids whenever > something is really build from source. Normally you only get identical > build-ids when building the same source code in the same package with > the same compiler flags. Identical build-ids between packages are > really very rare and are often caused by some binary blob simply being > copied between packages (is there a blob in the upstream tar ball that > isn't build from source?) or if debuginfo (-g) is missing. > >>> To wrap up: >>> 1. Is there a better way to deal with the aforementioned build-id >>> conflicts than disable their generation on one side (with "%global >>> _build_id_links none")? >> >> Instead of disabling entirely, you could tell rpm to put it all into >> -debuginfo packages (ie the original debuginfo layout). Which would >> still conflict, but fewer people are affected: >> >> %global _build_id_links alldebug > > Yes, that is a much better workaround than using none. It sounds very sensible :). Especially, as a workaround, in the situation that solving issues with duplicated shared libraries between packages was problematic. Thanks you guys for suggestions. Marcin > >>> 2. Maybe my assumption about the same generated shared libraries is >>> wrong and there is something else what can be done to fix the root problem? >> >> That's exactly the cause, build-id's are engineered to reproducably >> identify identical built objects, regardless of their location. Which >> causes conflicts when the house rules of not shipping multiple idental >> copies is broken (one might call this a feature). > > Yes, I would call this a feature :) > >> Short of unbundling the shared libraries, I guess a reasonable >> workaround would be patching them to include some identifier string >> based on the containing package name, which would cause them to have >> different build_ids. > > If build from source and building with debuginfo that should already be > the case because the build-id is calculated o
Conflicting build-ids in chromium and chromium-freeworld
Hi. There is an ongoing problem with conflicting build-ids in chromium and chromium-freeworld [1][2]: > Error: Transaction test error: > file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 There is no clear idea why it happens, but my assumption is that due to the fact of building with the same source code (with similar patches), some generated shared libraries are the same which generates conflict(s). The quick look at the algorithm for build-id generation [3] doesn't answer my question what exactly is taken into account for their generation and more precisely is there is way to add some "fuzz" (having different buildroots doesn't help) to distinguish those libraries. To wrap up: 1. Is there a better way to deal with the aforementioned build-id conflicts than disable their generation on one side (with "%global _build_id_links none")? 2. Maybe my assumption about the same generated shared libraries is wrong and there is something else what can be done to fix the root problem? [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869037 [2] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5743 [3] - https://github.com/rpm-software-management/rpm/blob/505fe16f863f83637c9577417a7ae959df674a61/build/files.c#L1803 [4] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5758 Marcin P.S. There are cases where it would be best to have those two packages installed simultaneously [4]. -- https://blog.solidsoft.pl/ - Working code is not enough ___ 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: Downloading modularized packages from Koji
On 2019-02-17 03:30, Mamoru TASAKA wrote: > Marcin Zajączkowski wrote on 2019/02/17 6:55: >> Hi, >> >> After some packages (such as Fish [1]) are released to Fedora modular >> repository I would like to download them from Koji and play with them >> (to provide feedback) not having to wait until a request to move to the >> testing repository is accepted. >> >> Unfortunately there are no RPM packages for modular builds in Koji UI >> [2]. >> >> Q. Have can I download built RPM packages available only in Koji? >> >> >> [1] - >> https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2818ffed6e >> [2] - https://koji.fedoraproject.org/koji/buildinfo?buildID=1211219 >> >> Marcin >> > > https://kojipkgs.fedoraproject.org/packages/fish/3/2920190216163513.139e1eeb/files/module/modulemd.x86_64.txt > > says: > artifacts: > rpms: > - fish-0:3.0.1-1.module_f29+2923+49f4083f.src > - fish-0:3.0.1-1.module_f29+2923+49f4083f.x86_64 > - fish-debuginfo-0:3.0.1-1.module_f29+2923+49f4083f.x86_64 > - fish-debugsource-0:3.0.1-1.module_f29+2923+49f4083f.x86_64 > > so you can download them from: > https://kojipkgs.fedoraproject.org/packages/fish/3.0.1/1.module_f29+2923+49f4083f/ Thanks. I wasn't able to find it (the repository name) in the documentation. It's important also in a case of a rollback need to the previous version. Marcin -- https://blog.solidsoft.info/ - Working code is not enough ___ 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
Downloading modularized packages from Koji
Hi, After some packages (such as Fish [1]) are released to Fedora modular repository I would like to download them from Koji and play with them (to provide feedback) not having to wait until a request to move to the testing repository is accepted. Unfortunately there are no RPM packages for modular builds in Koji UI [2]. Q. Have can I download built RPM packages available only in Koji? [1] - https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2818ffed6e [2] - https://koji.fedoraproject.org/koji/buildinfo?buildID=1211219 Marcin -- https://blog.solidsoft.info/ - Working code is not enough ___ 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
Compilation issue after gcc removal
On 2018-07-20 00:26, Artur Iwicki wrote: > I looked at libattr and in the changelog, there's this: >> * Tue Jul 17 2018 Kamil Dudka 2.4.48-3 >> - temporarily provide attr/xattr.h symlink until users are migrated >> (#1601482) > > The bugzilla ticket says that attr/xattr.h was removed from libattr and is > now a symlink to sys/xattr.h. Taking a look at those two files, the old > attr/xattr.h has these lines in it: >> #ifndef ENOATTR >> # define ENOATTR ENODATA/* No such attribute */ >> #endif > These are absent in sys/xattr.h, so the compiler rightfully complains that it > does not know of ENOATTR. I guess you should either add a patch that replaces > usages of ENOATTR to ENODATA, or a patch that adds this define somewhere. Thanks Artur for your findings! Trying to report that problem upstream I founded this thread: https://github.com/iustin/pyxattr/pull/15 I will give it a few days to work out some general way to solve it. Marcin -- https://blog.solidsoft.info/ - Working code is not enough ___ 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/XDBPYWNUBEMRVB3KH2BJGUGCTY2NTO5A/
Compilation issue after gcc removal
Hi,
After the recent gcc removal from build root [1] I added explicit
dependency on gcc [2], but even though my pyxattr package started to
fail with [3][4]:
> xattr.c:532:56: error: 'ENOATTR' undeclared (first use in this function); did
> you mean 'ENOTTY'?
I've checked it and ENOATTR should be defined in attr/xattr.h which is
provided by the build dependency - libattr-devel. In addition are
installed glibc-headers [5].
I haven't been programming in C for years. Do you know what can be a reason?
[1] - https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
[2] -
https://src.fedoraproject.org/rpms/pyxattr/c/3e584e38e14140ee9c4287cfcff75a79268ba3da?branch=master
[3] - https://kojipkgs.fedoraproject.org//work/tasks/2137/28452137/build.log
[4] - https://koji.fedoraproject.org/koji/taskinfo?taskID=28452137
[5] - https://kojipkgs.fedoraproject.org//work/tasks/2137/28452137/root.log
> gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
> -fstack-protector-strong -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -fexceptions -fstack-protector-strong -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
> -fstack-protector-strong -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC
> -D_XATTR_VERSION="0.5.3" -D_XATTR_AUTHOR="Iustin Pop"
> -D_XATTR_EMAIL="iu...@k1024.org" -I/usr/include/python2.7 -c xattr.c -o
> build/temp.linux-x86_64-2.7/xattr.o -Wall -Werror
> xattr.c: In function 'get_all':
> xattr.c:532:56: error: 'ENOATTR' undeclared (first use in this function); did
> you mean 'ENOTTY'?
> } else if(errno == ENODATA || errno == ENOATTR) {
> ^~~
> ENOTTY
> xattr.c:532:56: note: each undeclared identifier is reported only once for
> each function it appears in
> error: command 'gcc' failed with exit status 1
Marcin
--
https://blog.solidsoft.info/ - Working code is not enough
___
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/CX7NL6VOXD7JMM3Q2SZU7K46VS2SDITR/
Re: BuildError: package sstp-client is blocked for tag f26
On 2016-08-16 16:43, Sérgio Basto wrote: > On Ter, 2016-08-16 at 15:54 +0200, Marcin Zajączkowski wrote: >> Hi, >> >> Trying to build just unretired package I've got: >>> >>> 15275573 build (rawhide, /rpms/sstp- >>> client:35a9c870ac0ce9d1c01e93929dea2513d9bfb366): open (arm02- >>> builder20.arm.fedoraproject.org) -> >>> FAILED: BuildError: package sstp-client is blocked for tag f26 >> (https://koji.fedoraproject.org/koji/taskinfo?taskID=15275573) >> >> Who can unblock this (sstp-client) package for f26? > > I think you should open an rel-eng ticket like I did > > https://fedorahosted.org/rel-eng/ticket/6464 Thanks for a tip. I created https://fedorahosted.org/rel-eng/ticket/6466 and we will see. Marcin -- http://blog.solidsoft.info/ - Working code is not enough -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
BuildError: package sstp-client is blocked for tag f26
Hi, Trying to build just unretired package I've got: > 15275573 build (rawhide, > /rpms/sstp-client:35a9c870ac0ce9d1c01e93929dea2513d9bfb366): open > (arm02-builder20.arm.fedoraproject.org) -> > FAILED: BuildError: package sstp-client is blocked for tag f26 (https://koji.fedoraproject.org/koji/taskinfo?taskID=15275573) Who can unblock this (sstp-client) package for f26? Marcin -- http://blog.solidsoft.info/ - Working code is not enough -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Taking over orphaned sstp-client package
Hi guys, I plan to take over sstp-client package [1] which has been orphaned two months ago in F24+. It is required by my new package - NetworkManager-sstp [2]. [1] - https://admin.fedoraproject.org/pkgdb/package/rpms/sstp-client/ [2] - https://admin.fedoraproject.org/pkgdb/package/rpms/NetworkManager-sstp/ Marcin -- http://blog.solidsoft.info/ - Working code is not enough -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Problem with exact provides in pre-release version
On 2016-06-30 04:27, Ahmad Samir wrote:
> On 30 June 2016 at 01:21, Marcin Zajączkowski <msz...@wp.pl> wrote:
>>
>> Hi,
>>
>> I'm a maintainer of NetworkManager-sstp package and before 1.2.0 final
>> will be released I experimenting in my CORP repo with pre-release Git
>> version. I've encountered a situation which - I'm not sure - is a
>> problem with my configuration or some issue with dependencies resolving.
>>
>> $ sudo dnf install NetworkManager-sstp-gnome
>> Error: nothing provides NetworkManager-sstp(x86-64) =
>> 1.2.0-0.20160514git86c2737d.fc24 needed by
>> NetworkManager-sstp-gnome-1:1.2.0-0.20160514git86c2737d.fc24.x86_64
>> (try to add '--allowerasing' to command line to replace conflicting
>> packages)
>>
>> While already installed corresponding NetworkManager-sstp reports:
>> $ rpm -q --provides NetworkManager-sstp
>> NetworkManager-sstp = 1:1.2.0-0.20160514git86c2737d.fc24
>> NetworkManager-sstp(x86-64) = 1:1.2.0-0.20160514git86c2737d.fc24
>> config(NetworkManager-sstp) = 1:1.2.0-0.20160514git86c2737d.fc24
>>
>> I don't know why I have that error - NetworkManager-sstp seems to
>> provide what is needed.
>>
>> In the SPEC file I have (for NetworkManager-sstp-gnome):
>>> Requires: NetworkManager-sstp%{?_isa} = %{version}-%{release}
>>
>
> You should add the epoch to the requires:
> Requires: NetworkManager-sstp%{?_isa} = %{epoch}:%{version}-%{release}
That was the reason. Thanks for a tip!
Marcin
--
http://blog.solidsoft.info/ - Working code is not enough
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Problem with exact provides in pre-release version
Hi,
I'm a maintainer of NetworkManager-sstp package and before 1.2.0 final
will be released I experimenting in my CORP repo with pre-release Git
version. I've encountered a situation which - I'm not sure - is a
problem with my configuration or some issue with dependencies resolving.
$ sudo dnf install NetworkManager-sstp-gnome
Error: nothing provides NetworkManager-sstp(x86-64) =
1.2.0-0.20160514git86c2737d.fc24 needed by
NetworkManager-sstp-gnome-1:1.2.0-0.20160514git86c2737d.fc24.x86_64
(try to add '--allowerasing' to command line to replace conflicting
packages)
While already installed corresponding NetworkManager-sstp reports:
$ rpm -q --provides NetworkManager-sstp
NetworkManager-sstp = 1:1.2.0-0.20160514git86c2737d.fc24
NetworkManager-sstp(x86-64) = 1:1.2.0-0.20160514git86c2737d.fc24
config(NetworkManager-sstp) = 1:1.2.0-0.20160514git86c2737d.fc24
I don't know why I have that error - NetworkManager-sstp seems to
provide what is needed.
In the SPEC file I have (for NetworkManager-sstp-gnome):
> Requires: NetworkManager-sstp%{?_isa} = %{version}-%{release}
where:
> %global snapshot .20160514git86c2737d
> Version: 1.2.0
> Release: 0%{snapshot}%{?dist}
A branch with my pre-release changes:
http://pkgs.fedoraproject.org/cgit/rpms/NetworkManager-sstp.git/log/?h=user/szpak/NetworkManager-1.2-git
My CORP repo:
https://copr.fedorainfracloud.org/coprs/szpak/NetworkManager-sstp/
Do you know could be the reason?
Marcin
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Recommended way of proposing changes in someone else Fedora packages configuration
Thanks for your responses, guys! On 2015-10-18 16:57, Christopher wrote: > To support this, I try to keep a mirror in GitHub for my packages... But > it's hard to stay in sync sometimes and nobody really knows it's there. > It'd be nice if this were supported directly, perhaps by automatically > mirroring all packages in GitHub, like the ASF does, and emailing > maintainers when activity occurs. I like the idea with mirroring Fedora Git to GitHub. Read only mirror just to be a dedicated place for that kind of contributions (via pull requests). GitHub is currently probably the most popular Git hosted repositories provider. Maintainers could subscribe to their project on GitHub to get notifications about the new PRs (or it could be done automatically if GitHub login is associated with FAS). There could be optionally a support in fedpkg for merging that PRs easily (or just an Git alias to do it - with one precised repo location it would not be a problem). Automatic mirroring could be probably done automatically by GitHub. Things like GitHub account association in FAS or CLA verification (https://github.com/google/guava/pull/2163#issuecomment-141642504) would require some additional work. Nevertheless I agree with Kevin about dependence on GitHub in that element of the workflow (although not the crucial one). Maybe GitHub integration would not be so beneficial as probably most of the contributions come from people already related to Fedora and it would be better to have that interface in the internal Fedora infrastructure one day. Marcin > On Sun, Oct 18, 2015, 09:36 Marcin Zajączkowski <msz...@wp.pl> wrote: > >> Hi, >> >> I would like to propose a minor (yet important) change in one of the >> Fedora packages configuration (a SPEC file and/or a patch). Is it >> possible to create (something like) a pull request which could be >> reviewed by the maintainer in some convenient way (*) and optionally >> merged? Or the only way is to create a patch and put it into a Buzilla >> ticket? >> >> >> (*) - a given package repo could be forked and published to GitHub with >> a change in a separate branch. The new repo could be added locally by a >> maintainer (as a new remote Git repository) and that new branch could be >> merge into master and pushed to Fedora repository. Nevertheless it >> requires some knowledge about Git and a few manual Git commands to execute) >> >> >> Marcin >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Recommended way of proposing changes in someone else Fedora packages configuration
Hi, I would like to propose a minor (yet important) change in one of the Fedora packages configuration (a SPEC file and/or a patch). Is it possible to create (something like) a pull request which could be reviewed by the maintainer in some convenient way (*) and optionally merged? Or the only way is to create a patch and put it into a Buzilla ticket? (*) - a given package repo could be forked and published to GitHub with a change in a separate branch. The new repo could be added locally by a maintainer (as a new remote Git repository) and that new branch could be merge into master and pushed to Fedora repository. Nevertheless it requires some knowledge about Git and a few manual Git commands to execute) Marcin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Retiring fuse-smb package
Hi, I plan to retire fuse-smb which allows to mount SMB/Samba shares as local directories before F21 is branched (2014-07-08). There have been no new versions since 2008 and the maintainer is not going to fix problem with crashes related to multi threading issues in libsmbclient 3.2+. There had been also building issues with Samba 4.0. Ubunty recommends [1] smbnetfs project [2] as a replacement, but I don't use this feature anymore and even I have access to Windows machines to test this use case, so I would not be able to test it carefully with all further Fedora updates. Maybe there would be someone else willing to package smbnetfs? [1] - https://help.ubuntu.com/community/FuseSmb [2] - https://sourceforge.net/projects/smbnetfs/ Marcin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
pylibacl-0.4 - a license change from GPLv2+ to LGPLv2+
Hi, Starting from the version 0.4 pylibacl Python extension changed its license from GPLv2+ to LGPLv2+. As the new license is less restrictive I don't see any negative implications. Regards Marcin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
