Re: Unretiring rudeconfig
On Mon, Oct 22, 2018 23:31:28 +0200, Robert-André Mauchin wrote: > On dimanche 21 octobre 2018 00:10:03 CEST Ankur Sinha wrote: > > > > Please feel free to ping me when you are looking for a reviewer in the > > future :) > > If I can take your offer, I have yet another simple Golang package that I had > forgotten to do: > https://bugzilla.redhat.com/show_bug.cgi?id=1641822 > > It builds in Koji and follows standard Golang template. Yes, of course. Taken. I'll have the review comments up in a day or two. -- Thanks again, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
On Sun, Oct 21, 2018 at 06:33:56PM -0700, Kevin Fenzi wrote: > On 10/21/18 6:12 PM, Stephen J. Turnbull wrote: > > Kevin Fenzi writes: > > > > > Huh. The only person I know of from Fedora at least that was > > > working on it was abompard. While he's working on other things now, > > > as far as I know he's still working on mailman3/hyperkitty as time > > > permits. > > > > pingu and abadger also contributed. Don't know their exact > > affiliations or what they're doing for Fedora's installation, but all > > three have stopped substantial upstream contribution for a couple > > Toshio (abadger) works on ansible now. Pierre (pingou) is still in the > Fedora engineering group but is focused on pagure and ci work. I only > see 2 commits ever from Toshio and all of pingou's commits were at the > very start of the project in 2012. Toshio and I implemented the early version of HyperKitty based on Máirín's designs at a time I was still a part-time contributor. Aurélien has been hired by RH a few months after HK took off and basically he took over from Toshio and I. Since then I did join RH and the Fedora engineering group but since we already had Aurélien working on HK, I kept hanging around a little but focused on other projects. This explains the profile of contributions you're seeing from the three of us :) Pierre signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
RHBZ#1639646 [OpenMPI issue]
Hello everyone. In reference to the bug https://bugzilla.redhat.com/show_bug.cgi?id=1639646, is anyone else ran into this problem with OpenMPI recently? -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x5E212EE1D35568BE GPG key server: https://keys.fedoraproject.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: builds using forge macros with tags broken on rawhide
Nicolas, On 10/22/2018 10:00 AM, Nicolas Mailhot wrote: Le lundi 22 octobre 2018 à 00:31 +0200, Robert-André Mauchin a écrit : Yeah all "gosetup -q" (which is gofed default) are broken because of your commit: Well I know no such a thing, there was never any gosetup macro in the macro set, and I think I told you a year ago I would not define a gosetup macro just to avoid typing forgesetup, unless it actually added some processing over the forgesetup macro. That would obfuscate specs for no good reason and increase gratuituously the maintenance surface (as we see *now*). Yet, you were aware of that. And, it was me who told you I am fine with most of the go macros you implemented, including their names. We both spent many hours improving the implementation, extending golist binary I provided. And the %gosetup was the only macro I wanted to keep so all the regular go macros are in %goVERB form. We have %gometa, %gosetup, %gobuild, %goinstall, %gotest on purpose so they reflect: - meta: after some effort even meta can be interpreted as a verb, i.e. meta the macros - setup: extract the tarball and prepare working dir - build: set gopath, build go binaries - install: install resources under proper directories - test: test installed go packages Do you ignore that fact on purpose? Since after discussion we had so many times you still seem to put more emphasis on your own and only your opinion. I though we made a compromise and that we agreed on that. I.e. I will respect all the macro names you choose up to the only one and you will respect the gosetup one. After having merged your changes you are sending me a message that even if we come to a common agreement you still don't care as long as you reach your own goals. I would really like to think I am wrong in this opinion. Though, you actions say otherwise. And I doubt -q is your problem, since (*precisely for backwards compatible reasons) it is still accepted by forgesetup (even though it's ignored, because it’s the default behaviour now). Oh, I see, I forgot to add a phantom -q to forgeautosetup as it already was already its default behaviour. So you're forcing somewhere a -q that I don't think was ever needed. I will add the -q to the macro definition if that makes you feel better. You were the one that implemented the forge macros (pardon me if I am wrong, I am unsure if it was all of it of most of it). And I love those macros since they save so much time and make the spec file a lot simpler. So its natural to be protective if anyone wants to change them they way that does not align with your world view. Yet, go macros started to rely on the forge macros and the change you made is not backward compatible (given we started using the macros in older versions of Fedora as well). So please, make the %forgeautosetup compatible with the %gosetup again. Once the %gosetup macro is functional again, we can discuss its removal in favor of forgesetup as part of global announcement so all go packagers have time to migrate to new macros. For future reference, please don't change the forge macros in any way that makes the go macros incompatible or broken until we have official Go packaging guidelines and set of macros the go-sig community agrees on. Thank you Nicolas So, no biggie. Easy to fix. That's why such changes hit -devel before anyone dreams of queuing them to stable. What package exactly installs your gosetup macro in /usr/lib/rpm so I can see what other things it tries to do? I see no macro file in the Fedora gofed package manifests. If you could PR your changes to the official Fedora packages that coordinate Fedora go macros (the go-macros repository on github, that will be rehosted in pagure as soon as the @rh contributors ok the move) instead of doing it in other places, that would be a tad easier to coordinate. Please revert this, we should be able to use whatever flag supported by %setup and %autosetup, not a small subset. How do you even pass the basic -n flags now? So basically, you have a macro, which sole purpose is to pass precomputed -n values to *setup, and you want to use it with manual -n flags. Why? Could you tell us what exactly is the point of 1. wrapping a Fedora macro in another name just because you do not like the official macro name in Fedora 2. overriding the only thing this macro does over autosetup 3. and then complaining all the argument passing to autosetup does not work as you wish it does So all this complexity, because what you really want is to use autosetup directly. Then just do. What's the problem exactly with typing autosetup in your spec? No one stops you from doing it. One reason I removed the -n in forgeautosetup and forgesetup precisely to stop packagers confusing themselves the way you are confusing yourself. The other being -n is incompatible with the processing of multiple archives that many people asked me to add to the macros. Which is finally implemented aft
Re: PSA: builds using forge macros with tags broken on rawhide
- Original Message -
> From: "Nicolas Mailhot"
> To: "Robert-André Mauchin" , jca...@redhat.com
> Sent: Monday, October 22, 2018 5:32:55 PM
> Subject: Re: PSA: builds using forge macros with tags broken on rawhide
>
> Le 2018-10-22 16:52, Nicolas Mailhot a écrit :
>
> >> -rpm.define("gosetup(a:b:cDn:Tq) %forgesetup %{?**}")
> >> +rpm.define("gosetup %forgesetup")
> >
> > Rhaa that's an old leftover of the time when Jan pulled a copy of the
> > forge macros in go macro copy, because he thought redhat-rpm-config
> > maintainers would take ages to review stuff. I thought every trace of
> > this had been eradicated long time ago. %gosetup is certainly not part
> > the use pattern documented in the wiki since march.
>
> Anyway Jan removed every trace of his attempt to internalise the the
> forge macros a week after the commit you point to, *except* for this
> stray line. Don't know if leaving this line was an afterthought, or if
> he didn't want to fix some specs that had been created in the weeks when
> he experimented with the internal forge macro implementation. The thing
> is done now.
>
> And what this line does is awfully dangerous and brittle. I could not
> put anything like this in redhat-rpm-config, it would be rejected
> directly.
>
> So, we probably need to spin another go-macros build with a normal
> gosetup declaration not hidden within another macro. And then live
> unhappily afterwards with the messup set in stone. Not exactly the kind
> of thing you want to do in the middle of a sig reorg.
>
> No chance to remove the problem call from the specs I suppose?
Bringing this back to devel as I don't understand why this discussion should be
held in private.
AFAIK unless you are volunteering to fix and rebuild all the affected packages,
it is not going away on its own. I don't think that playing the blame game will
move us anywhere. It has been there for some time so it got some considerate
adoption.
I don't understand why are you not following process for system wide changes
for such disruptive change. It seems to me that you are not realizing possible
impacts of your changes and are actively downplaying testing(IMO integral part
of the development) before pushing it in to the production(rawhide). I perceive
this kind of practices as extremely dangerous for sustainability of Fedora
packaging. Could we please revert the change(Igor?) and stop pushing it until
it is formalized(including docs, so it is outright obvious what is intended as
supported) as System Wide Change proposal and approved by FESCO(for F30)?
JC
>
> --
> Nicolas Mailhot
>
___
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: Attention Gmail users, please turn off HTML mail
On Fri, Oct 19, 2018 at 10:28:45PM -, Máirín Duffy wrote: > Please do. Neal and I are starting up an effort. I reached out to > Abhilash, the upstream lead, last night on the devel list and he was very > responsive to this idea. He's already created a gitlab subproject for our > efforts upstream. Okay; I'll be happy to. But I'll do it separately from this thread. > > list. The same is true for every other list I looked at. People just aren't > > using this. > Matthew, the target user for Hyperkitty isn't a devel-list reader. But devel is by far our most active and important list. -- Matthew Miller Fedora Project Leader ___ 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
Should we also list "Trivial" review tickets on Easyfix?
Hello, The EasyFix page[1] is a list of various issues/bugs that are considered simple enough for new contributors to work with. Currently, from bugzilla, tickets that use the "EasyFix" key word are listed here. The package review process suggests the use of "Trivial" on the Whiteboard for simpler tickets to aid new-comers. So, they seem to serve the same purpose as EasyFix. Would it be OK to also list these tickets on the EasyFix page? I've already opened a PR here for this to done[3]. So if the community agrees with my assessment, we'll get that merged and publicise the "trivial" whiteboard marker more. In the meantime, please mark your review tickets as "trivial" if they are appropriate for new-contributors to review unofficially when they're trying to get sponsored to the packagers group. [1] https://fedoraproject.org/easyfix/ [2] https://fedoraproject.org/wiki/Package_Review_Process#The_Whiteboard [3] https://github.com/fedora-infra/fedora-gather-easyfix/pull/13 -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Orphaned python2-astroid and python2-pylint
Hi, I've just orphaned python2-astroid and python2-pylint. I don't need them and I don't want to maintain legacy python2 packages. Those are needed for python2-spyder, python2-asttokens, python2-flake8-import-order. Please consider removing those, so we can retire python2-astroid and python2-pylint. If you need to keep them, please consider maintaining python2-astroid and/or python2-pylint. Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Self Introduction: Kefu Chai
thanks Ben! ___ 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: PSA: builds using forge macros with tags broken on rawhide
Le 2018-10-23 12:59, Jan Chaloupka a écrit : Jan So please, make the %forgeautosetup compatible with the %gosetup again. Once the %gosetup macro is functional again, we can discuss its removal in favor of forgesetup as part of global announcement so all go packagers have time to migrate to new macros. For future reference, please don't change the forge macros in any way that makes the go macros incompatible or broken until we have official Go packaging guidelines and set of macros the go-sig community agrees on. Thank you Nicolas So, no biggie. Easy to fix. That's why such changes hit -devel before anyone dreams of queuing them to stable. What package exactly installs your gosetup macro in /usr/lib/rpm so I can see what other things it tries to do? I see no macro file in the Fedora gofed package manifests. If you could PR your changes to the official Fedora packages that coordinate Fedora go macros (the go-macros repository on github, that will be rehosted in pagure as soon as the @rh contributors ok the move) instead of doing it in other places, that would be a tad easier to coordinate. Please revert this, we should be able to use whatever flag supported by %setup and %autosetup, not a small subset. How do you even pass the basic -n flags now? So basically, you have a macro, which sole purpose is to pass precomputed -n values to *setup, and you want to use it with manual -n flags. Why? Could you tell us what exactly is the point of 1. wrapping a Fedora macro in another name just because you do not like the official macro name in Fedora 2. overriding the only thing this macro does over autosetup 3. and then complaining all the argument passing to autosetup does not work as you wish it does So all this complexity, because what you really want is to use autosetup directly. Then just do. What's the problem exactly with typing autosetup in your spec? No one stops you from doing it. One reason I removed the -n in forgeautosetup and forgesetup precisely to stop packagers confusing themselves the way you are confusing yourself. The other being -n is incompatible with the processing of multiple archives that many people asked me to add to the macros. Which is finally implemented after months of work. And which just hit rawhide after more than a month of review. So, do you have actual spec files in Fedora with this use of the redhat- rpm-config macros? If that is the case, I can put those flags in the macros so you can continue shooting yourself in the foot using undefined known-broken use patterns. If not, I'd rather remove the possibility altogether before someone harms himself. With you mods, we have to edit hundreds of specs to remove the -q flags. And that concretely, if why pre-generating specs instead of making the effort to include default processing in the macro code Fedora ships is wrong. Regards, ___ 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 -- Nicolas Mailhot ___ 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: PSA: builds using forge macros with tags broken on rawhide
Jan, I do not recall this all the same way, but no matter, that was months ago, a long development tunnel away. The thing which is failing today is a brittle and dangerous rpm macro aliasing code that was added against my best technical advice. Sound advice as we see now. And I had honestly forgotten about it. It serves absolutely no technical purpose, it is buried inside an unrelated macro, and it is not documented anywhere¹. All the blame games in the world won't change where the technical failure is. So what do you want me to do now? Fix this aliasing code? That requires rewriting it. The way it was written it can not keep working reliably with or without redhat-rpm-config changes. Rewrite it just so gosetup calls can be removed from Fedora specs? I'd rather write the script to remove the problem calls directly. Rewrite it so removal can be postponed indefinitely via endless vetos by you or Jakub? That makes me the effective maintainer of code I have no use for and disagree with. I'm the one doing the work here. I'd appreciate if it was taken in account sometimes. Regards, ¹ Neither on https://fedoraproject.org/wiki/More_Go_packaging, nor on https://fedoraproject.org/wiki/PackagingDrafts/Go, nor in the macro files themselves. -- Nicolas Mailhot ___ 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
Orphaning pcb.
Hi all, I am orphaning pcb (https://src.fedoraproject.org/rpms/pcb) since I am not able to longer maintain. I have spoken with Alain (fas: avigne) and he is willing to take this package. Thanks a lot Alain. Best regards. -- *K.N* *GPG-KEY*: A81DB1D8 ___ 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: Orphaning several packages.
On Wed, Oct 17, 2018 at 10:11 AM Kiara Navarro wrote: > Hi all, > > I am orphaning a list of packages that I am not able to longer maintain. Most > of them are related to electronic applications. > > https://src.fedoraproject.org/rpms/emacs-verilog-mode Hi Kiara, I looked at this briefly a while ago-- it seems to me like verilog-mode is now part of emacs-common: $ rpm -qf /usr/share/emacs/26.1/lisp/progmodes/verilog-mode.elc emacs-common-26.1-3.fc28.x86_64 Is the stand-alone emacs-verilog-mode package necessary anymore, or can it just be retired? Ben Rosser ___ 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
Fedora 29 compose report: 20181022.n.1 changes
OLD: Fedora-29-20181021.n.0 NEW: Fedora-29-20181022.n.1 = SUMMARY = Added images:1 Dropped images: 4 Added packages: 0 Dropped packages:0 Upgraded packages: 2 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 24.76 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 67.79 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-29-20181022.n.1.ppc64le.tar.xz = DROPPED IMAGES = Image: AtomicHost qcow2 ppc64le Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20181021.n.0.ppc64le.qcow2 Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-29-20181021.n.0.s390x.tar.xz Image: AtomicHost raw-xz ppc64le Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20181021.n.0.ppc64le.raw.xz Image: Server dvd i386 Path: Server/i386/iso/Fedora-Server-dvd-i386-29-20181021.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: fedora-workstation-repositories-29-1.fc29 Old package: fedora-workstation-repositories-28-2.fc29 Summary: Repository files for searchable repositories RPMs: fedora-workstation-repositories Size: 9.05 KiB Size change: 300 B Changelog: * Thu Oct 18 2018 Stephen Gallagher - 29-1 - Make repo files %config(noreplace) so they aren't clobbered on upgrade if they have been modified (such as being enabled). Package: gnome-software-3.30.3-1.fc29 Old package: gnome-software-3.30.2-1.fc29 Summary: A software center for GNOME RPMs: gnome-software gnome-software-devel gnome-software-editor gnome-software-snap Size: 24.75 MiB Size change: 67.49 KiB Changelog: * Thu Oct 18 2018 Kalev Lember - 3.30.3-1 - Update to 3.30.3 = DOWNGRADED PACKAGES = ___ 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: Should we also list "Trivial" review tickets on Easyfix?
> "AS" == Ankur Sinha writes: AS> The package review process suggests the use of "Trivial" on the AS> Whiteboard for simpler tickets to aid new-comers. So, they seem to AS> serve the same purpose as EasyFix. Would it be OK to also list these AS> tickets on the EasyFix page? I don't see why not. Fedora has been using "Trivial" for this purpose since before the Core/Extras merge but there's no particular reason for it (other than the dictionary meaning of the word matching up with the usage). It could certainly be changed if it makes something easier. - J< ___ 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
Fedora 29-20181022.n.1 compose check report
No missing expected images. Failed openQA tests: 8/133 (x86_64), 8/23 (i386), 1/2 (arm) ID: 299838 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/299838 ID: 299845 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/299845 ID: 299864 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/299864 ID: 299879 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/299879 ID: 299880 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/299880 ID: 299883 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/299883 ID: 299886 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/299886 ID: 299901 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/299901 ID: 299925 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/299925 ID: 299932 Test: x86_64 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/299932 ID: 299933 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/299933 ID: 299980 Test: i386 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/299980 ID: 299981 Test: i386 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/299981 ID: 299988 Test: i386 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/299988 ID: 21 Test: i386 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/21 ID: 22 Test: i386 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/22 ID: 23 Test: i386 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/23 Soft failed openQA tests: 5/133 (x86_64), 8/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 299837 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/299837 ID: 299865 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/299865 ID: 299866 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/299866 ID: 299867 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/299867 ID: 299887 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/299887 ID: 299960 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/299960 ID: 299983 Test: i386 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/299983 ID: 299985 Test: i386 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/299985 ID: 299986 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/299986 ID: 299987 Test: i386 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/299987 ID: 299989 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/299989 ID: 20 Test: i386 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/20 ID: 24 Test: i386 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/24 Passed openQA tests: 120/133 (x86_64), 7/23 (i386) Skipped openQA tests: 1 of 158 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: PSA: builds using forge macros with tags broken on rawhide
Anyway, since no one answers when I list the possible fixes and ask to choose between them, I fixed the Fedora spec files myself. Feel free to reintroduce %gosetup calls if you really want them, once the %gosetup implementation has been fixed. -- Nicolas Mailhot ___ 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
[389-devel] please review: PR 49988 - dscreate should set the port selinux labels
https://pagure.io/389-ds-base/pull-request/49988 ___ 389-devel mailing list -- 389-de...@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-de...@lists.fedoraproject.org
Re: PSA: builds using forge macros with tags broken on rawhide
On mardi 23 octobre 2018 22:43:16 CEST Nicolas Mailhot wrote: > Anyway, since no one answers when I list the possible fixes and ask to > choose between them, I fixed the Fedora spec files myself. > > Feel free to reintroduce %gosetup calls if you really want them, once > the %gosetup implementation has been fixed. > > -- > Nicolas Mailhot Thanks for doing but you messed up the bumping of all the %changelog entries. ___ 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: PSA: builds using forge macros with tags broken on rawhide
On mardi 23 octobre 2018 23:47:05 CEST you wrote:
> On mardi 23 octobre 2018 22:43:16 CEST Nicolas Mailhot wrote:
> > Anyway, since no one answers when I list the possible fixes and ask to
> > choose between them, I fixed the Fedora spec files myself.
> >
> > Feel free to reintroduce %gosetup calls if you really want them, once
> > the %gosetup implementation has been fixed.
>
> Thanks for doing but you messed up the bumping of all the %changelog
> entries.
Used this Fish script to fix my SPEC:
for f in (grep --include=\*.spec -rnwl './' -e "redhat-rpm-config-123")
sed -i -e '/\* Tue Oct 23 2018 Nicolas Mailhot
/{n;d}' $f
set version (rpmspec -q --srpm --qf "%{version}-%{release}" $f | sed
's|\.fc2[0-9]||')
sed -i "s|\* Tue Oct 23 2018 Nicolas Mailhot |\*
Tue Oct 23 2018 Nicolas Mailhot - $version|" $f
pushd (dirname $f)
fedpkg ci -m "Fix changelog entry"
popd
end
Wish you would fix the rest.
___
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
startx unsets DBUS_SESSION_BUS_ADDRESS, which breaks user D-Bus session
Hello, I would like to draw some attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: startx unsets DBUS_SESSION_BUS_ADDRESS, which result in launching another D-Bus session which breaks communicating with user systemd services (and any D-Bus services started before launching X) from X session via D-Bus, since they use two different D-Bus daemons. I would really like this bug to be fixed. Thanks, Alexey Rochev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 29 Beta - Cannot add printer
Hi Zdenek, I'm doing a WIFI mode. Installation works fine using CUPS but It's not working through gnome-control-center. Thanks, Gilles On 12/10/18 8:42 pm, Zdenek Dohnal wrote: Hi, What type of printer do you want to add (ethernet/usb/wifi)? I tried to add ethernet and usb types in my clean F29 virtual machine and both worked. If the printer is usb or it is in the same network as your PC, then you should see it in CUPS web api when you try to add new printer (on localhost:631, when cups.service is running - tab Administration, 'Add new printer'). If you can add printer through CUPS web api, then the issue will be in gnome-control-center. On 10/12/18 12:28 AM, Gilles Dubreuil wrote: Added screenshot On 12/10/18 09:27, Gilles Dubreuil wrote: Hi, Using default Gnome shell on Wayland I cannot add a printer. In Gnome settings, after pressing "unlock" and "add" button and than selecting a driver, a pop up message "Failed to add new printer" There are no messages in system journal. PS: I've SELinux in permissive mode just in case. ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-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 -- Zdenek Dohnal Associate Software Engineer Red Hat Czech - Brno TPB-C -- Gilles Dubreuil Senior Software Engineer - Red Hat - Openstack DFG Integration Email: gil...@redhat.com GitHub/IRC: gildub Mobile: +61 400 894 219 ___ 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: Orphaned python2-astroid and python2-pylint
On 10/23/18 8:59 AM, Miro Hrončok wrote: > Hi, > > I've just orphaned python2-astroid and python2-pylint. > > I don't need them and I don't want to maintain legacy python2 packages. > > Those are needed for python2-spyder, python2-asttokens, > python2-flake8-import-order. Please consider removing those, so we can > retire python2-astroid and python2-pylint. If you need to keep them, > please consider maintaining python2-astroid and/or python2-pylint. > > Thanks, I think I can just drop python2 version of spyder. Thank you for letting me know. Mukundan. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 29 Beta - Cannot add printer
On 10/23/18 3:59 PM, Gilles Dubreuil wrote: I'm doing a WIFI mode. Installation works fine using CUPS but It's not working through gnome-control-center. I find that "system-config-printer" is much more useful and functional than trying to do it through the control center. I have had very little success in using the control center option. ___ 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: Orphaned python2-astroid and python2-pylint
On 24.10.2018 01:47, Mukundan Ragavan wrote> I think I can just drop python2 version of spyder. Thank you for letting me know. That would be awesome, it would also unblock: python-spyder-kernels python-cloudpickle python-rope python-pickleshare (after sagemath) python-QtAwesome -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Orphaned python2-astroid and python2-pylint
On Tue, Oct 23, 2018 at 02:59:28PM +0200, Miro Hrončok wrote: > Hi, > > I've just orphaned python2-astroid and python2-pylint. > > I don't need them and I don't want to maintain legacy python2 packages. > > Those are needed for python2-spyder, python2-asttokens, > python2-flake8-import-order. Please consider removing those, so we > can retire python2-astroid and python2-pylint. If you need to keep > them, please consider maintaining python2-astroid and/or > python2-pylint. I dropped python2-flake8-import-order and python2-asttokens now. Zbyszek ___ 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: PSA: builds using forge macros with tags broken on rawhide
Le mardi 23 octobre 2018 à 23:47 +0200, Robert-André Mauchin a écrit : > On mardi 23 octobre 2018 22:43:16 CEST Nicolas Mailhot wrote: > > Anyway, since no one answers when I list the possible fixes and ask > > to > > choose between them, I fixed the Fedora spec files myself. > > > > Feel free to reintroduce %gosetup calls if you really want them, > > once > > the %gosetup implementation has been fixed. > > > Thanks for doing but you messed up the bumping of all the %changelog > entries. How exactly please? -- Nicolas Mailhot ___ 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: PSA: builds using forge macros with tags broken on rawhide
Le mercredi 24 octobre 2018 à 00:52 +0200, Robert-André Mauchin a écrit : > On mardi 23 octobre 2018 23:47:05 CEST you wrote: > > On mardi 23 octobre 2018 22:43:16 CEST Nicolas Mailhot wrote: > > > Anyway, since no one answers when I list the possible fixes and > > > ask to > > > choose between them, I fixed the Fedora spec files myself. > > > > > > Feel free to reintroduce %gosetup calls if you really want them, > > > once > > > the %gosetup implementation has been fixed. > > > > Thanks for doing but you messed up the bumping of all the %changelog > > entries. > > Used this Fish script to fix my SPEC: > This does not need any fixing, it may not be the changelog format you're used to, but it's one of the changelog styles rpm understands, which is used by packages in Fedora, and which was documented at one point in guidelines (no idea where the corresponding paragraph is today with the doc.fedoraproject changes) Regards, -- Nicolas Mailhot ___ 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: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
How can I enable cgroups2 on my laptop?
On Fri, Oct 19, 2018, 17:27 Lennart Poettering wrote:
> On Fr, 19.10.18 09:12, Florian Weimer (fwei...@redhat.com) wrote:
>
> > >> (cross-posting to devel and desktop lists, ideally reply to both)
> > >
> > > Coincidentally, at All Systems Go! in Berlin last week I had some
> > > discussions with kernel people about RLIMIT_NOFILE defaults. They
> > > basically suggested that the memory and performance cost of large
> > > numbers of fds on current kernels is cheap, and that we should bump
> > > the hard limit in systemd for all userspace processes.
> >
> > Which kernel version is that? Is that a new patch? Or some older
> > kernel?
> >
> > It's definitely not true for kernel 4.18, see the script I posted.
>
> I inquired Tejun Heo about this all, this is what he replied:
>
>
> In cgroup1, socket buffers are handled by a separate memory
> sub-controller. It's cumbersome to use, somewhat broken and doesn't
> allow for comprehensive memory control. cgroup2, however, by default
> accounts socket buffer as part of a given cgroup's memory consumption
> correctly interacting with socket window management.
>
> OOM killer too fails to take socket buffer into account and high
> number of sockets can lead it to make ineffective decisions; however,
> this failure mode isn't confined to high number of sockets at all -
> fewer number of fat pipes, tmpfs, mount points or any other kernel
> objects which can be pinned by processes can trigger this.
>
> cgroup2 can track or control most of these usages and at least for us
> switching to oomd for workload health management solves most of the
> problems that we've encountered. In the longer term, the kernel OOM
> killer can be improved to make better decisions too.
>
>
> ("us" in the above is facebook btw.)
>
> So, yeah, if we'd use cgroupv2 on Fedora, then everything would be
> great (unfortunately the container messiness blocks that for now). But
> as long as we don't, lifting the fd limit is not really making things
> worse, given that there are tons of other easily exploitable ways to
> acquire untracked memory...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> 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
>
___
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: PSA: builds using forge macros with tags broken on rawhide
Le mercredi 24 octobre 2018 à 08:42 +0200, Nicolas Mailhot a écrit : > Le mercredi 24 octobre 2018 à 00:52 +0200, Robert-André Mauchin a > écrit : > > On mardi 23 octobre 2018 23:47:05 CEST you wrote: > > > On mardi 23 octobre 2018 22:43:16 CEST Nicolas Mailhot wrote: > > > > Anyway, since no one answers when I list the possible fixes and > > > > ask to > > > > choose between them, I fixed the Fedora spec files myself. > > > > > > > > Feel free to reintroduce %gosetup calls if you really want them, > > > > once > > > > the %gosetup implementation has been fixed. > > > > > > Thanks for doing but you messed up the bumping of all the > > > %changelog > > > entries. > > > > Used this Fish script to fix my SPEC: > > > > This does not need any fixing, it may not be the changelog format > you're > used to, but it's one of the changelog styles rpm understands, which > is > used by packages in Fedora, and which was documented at one point in > guidelines (no idea where the corresponding paragraph is today with > the > doc.fedoraproject changes) Concretely the * - version-release - changes format is a tad more flexible and allows publishing several fixes in a row without duplicating date lines * - version-release - changes - version-release - changes and so on And, our infra does not care if a changelog uses mixed style or not, since mass rebuilds will drop changelog entries in a single format in all Fedora specs, so you have many mixed style changelogs in the distribution today. (of course it's your specs, you can rewrite changelog entries any way that makes you feel better) Regards, -- Nicolas Mailhot ___ 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
