Re: HEADS UP: DynamicBuildRequires are available

2019-06-26 Thread Miroslav Suchý
Dne 26. 06. 19 v 15:39 Richard W.M. Jones napsal(a): > On Tue, Jun 18, 2019 at 03:27:41AM +0200, Igor Gnatenko wrote: >> Hi folks, >> >> as of today, builders have been updated (thanks to Kevin) and >> DynamicBuildRequires finally work in Rawhide. >> >> Change Page:

Re: Bootstrapped Packages

2019-06-26 Thread Miroslav Suchý
Dne 26. 06. 19 v 12:53 Brian (bex) Exelbierd napsal(a): > Can someone point me at step by step instructions for how to handle > new packages that require bootstrapping because of a circular > depedency? https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping -- Miroslav Suchy,

Re: ABRT CLI rework

2019-06-24 Thread Miroslav Suchý
Dne 21. 06. 19 v 19:00 Chris Murphy napsal(a): > I only ever use abrt-cli. I don't even have abrt on Fedora Workstation > (or Server). This is a lot of abrt stuff... Do not judge by the number of packages. Most of those packages have only few files. -- Miroslav Suchy, RHCA Red Hat, Associate

Re: HEADS UP: DynamicBuildRequires are available

2019-06-18 Thread Miroslav Suchý
Dne 18. 06. 19 v 11:42 Igor Gnatenko napsal(a): > * Koji -- yes > * Mock -- yes Since https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.15 but it has to be enabled manually in config. Since version 1.4.17 (yet to be released) it will be enabled by default, and you will

Re: HEADS UP: DynamicBuildRequires are available

2019-06-18 Thread Miroslav Suchý
Dne 18. 06. 19 v 3:27 Igor Gnatenko napsal(a): > Hi folks, > > as of today, builders have been updated (thanks to Kevin) and > DynamicBuildRequires finally work in Rawhide. > > Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires > Example of real build: >

Re: Any new restriction in Koji added recently in Rawhide?

2019-06-13 Thread Miroslav Suchý
Dne 13. 06. 19 v 11:43 Peter Lemenkov napsal(a): > Hello All! > I've noticed that I cannot build Elixir in Rawhide anymore. It got > stuck at tests and all I've got is a cryptic (at least to me) message: > > > + RPM_EC=0 > BUILDSTDERR: ++ jobs -p > + exit 0 > > > See this link for full build

Re: Heads-up: rpm 4.15 alpha coming to rawhide

2019-06-12 Thread Miroslav Suchý
Dne 10. 06. 19 v 13:39 Panu Matilainen napsal(a): > More info and details available in the preliminary release notes at > https://rpm.org/wiki/Releases/4.15.0 and the change > page linked at the start of this message. Where can I read more about this: > Add support for rootless

Re: Weak RPM dependencies which are not automatically re-installed on update

2019-06-04 Thread Miroslav Suchý
Dne 04. 06. 19 v 15:48 Neal Gompa napsal(a): > he's aware that it's possible and some work could be > done to support this depending on demand for the feature. I do demand this feature :) I would love to see "dnf mark" command to utilize for this. Something like: dnf mark soft-remove I.e.

[EPEL-devel] EPEL8 ?

2019-06-04 Thread Miroslav Suchý
What is the status of EPEL8? Or more precise - can I - as Mock maintainer - do something so we can have EPEL available immediately when RHEL is out? Obviously it is too late for RHEL 8, but I am looking in future (RHEL9). -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno,

Re: Replacing glibc langpacks

2019-06-04 Thread Miroslav Suchý
Dne 27. 05. 19 v 11:34 Florian Weimer napsal(a): > I'm investigating whether it makes sense to switch to a scheme where the > glibc locale data is built from source, during package installation, > based on the langpack configuration system. This is similar to what > Debian does. I cannot comment

Re: Mock - signal reaction

2019-06-04 Thread Miroslav Suchý
Dne 03. 06. 19 v 13:00 Kamil Dudka napsal(a): >> Now I'm working on signal SIGTERM handling and I would like to kill all >> processes related to the main mock process. >> What do you think is it a good >> idea to kill all processes, or do we want to kill the main process only? >> And what about

Re: Modularity tooling intro?

2019-05-30 Thread Miroslav Suchý
Dne 30. 05. 19 v 11:16 Paul Howarth napsal(a): > Any pointers anyone? http://frostyx.cz/posts/how-to-build-modules-in-copr -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list --

requesting feedback on Mock default

2019-05-30 Thread Miroslav Suchý
Hi, you - fedora developers - are most significant users of Mock. Therefore I would like to ask you about feedback on: https://github.com/rpm-software-management/mock/issues/266 The summary is: Previously all output - both stdout and stderr - were mixed together. Like you will get on normal

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

2019-05-30 Thread Miroslav Suchý
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a): > If we did this, wouldn't it make it very difficult to use tools like > mock on RHEL / CentOS 7 to build for Fedora 3x? Speaking of Mock: Either the RPM on host need to understand the new format/compression **or** the packages in @buildsys group

Fedora GPG keys

2019-05-16 Thread Miroslav Suchý
Can someone enlighten me what happened to: https://getfedora.org/keys/ ? There used to be GPG keys of Fedora, but now it just return 404. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list --

Re: Fedora 30 officially released!

2019-05-02 Thread Miroslav Suchý
Dne 02. 05. 19 v 8:29 Samuel Sieb napsal(a): > Didn't the upgrade process suggest that you use --allowerasing?  Yes, it does. I tried to use it for few past realeases and ... I cannot personally recommend it. Sometimes it works, sometimes it is trying to remove crucial packages like rpm or dnf.

Re: Fedora 31 Self-Contained Change proposal: Minimal GDB in buildroot

2019-04-28 Thread Miroslav Suchý
Dne 26. 04. 19 v 23:49 Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot > > == Summary == > Create gdb-minimal package (without XML support, Python > support, Syntax Highlight and such) and switch to it in buildroot. The change will likely affect Mock and

Re: Fedora 32 System-Wide Change proposal: Retire Python 2

2019-04-25 Thread Miroslav Suchý
Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a): > Removed packages that would block the upgrades to Fedora 32 will be > obsoleted from {{package|fedora-obsolete-packages}}. Which effectively means all python2-* packages. Right? Miroslav ___ devel mailing

Re: FF v dnf needs-restarting

2019-04-23 Thread Miroslav Suchý
Dne 17. 04. 19 v 9:54 Kamil Paral napsal(a): > The question is which tool is correct. My current guess is tracer. +1 needs-restarting is very simple plugin. Tracer [1] is more sophisticated and I encourage everyone to use Tracer instead of needs-restarting. Miroslav [1]

Re: vanishing abrt logs

2019-04-09 Thread Miroslav Suchý
Dne 09. 04. 19 v 8:56 Zbigniew Jędrzejewski-Szmek napsal(a): > Can you point me to it? rpm -ql $(rpm -qa|grep dnf)|grep abrt doesn't > yield anything. What and how it is collected is determined by libreport with configs in /etc/libreport Some of those configs even have man page. You can start

Re: vanishing abrt logs

2019-04-08 Thread Miroslav Suchý
Dne 08. 04. 19 v 13:18 jfi...@fedoraproject.org napsal(a): > Hi Kevin, > > I was under the impression that the problem with many emails from Bugzilla > has already been fixed: > https://bugzilla.redhat.com/show_bug.cgi?id=1660157 >

Re: Modularity UX Questions

2019-04-02 Thread Miroslav Suchý
Dne 01. 04. 19 v 18:57 Stephen Gallagher napsal(a): > === A module has a profile that contains zero RPMs === > > In this case, a profile definition has been made in the module > metadata and it explicitly contains zero RPMs within it. Such an > example might be for compatibility: the module

Re: Loopy rpm subpackages dependencies

2019-03-28 Thread Miroslav Suchý
Dne 28. 03. 19 v 13:57 Tomasz Kłoczko napsal(a): > dnf does not provide any signing functions and I was not even aware that > someone implemented in base dnf building > functionalities (someone is using that?) No, DNF likely does not user rpmb and rpms. Both libraries has 21K + 15K. It is really

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

2019-03-27 Thread Miroslav Suchý
Dne 26. 03. 19 v 18:38 Tomasz Kłoczko napsal(a): > If yes I can propose simpler solution like create .post_build_preserve.lst > file in source build root and whatever will > be added to that file should be archived in some > --.tar.xz file to be accessible over koji > web interface. > If such

Re: Is SELinux enforcing on the koji builders?

2019-03-27 Thread Miroslav Suchý
Dne 27. 03. 19 v 4:33 Jerry James napsal(a): > Thanks for confirming. I am really puzzled. I can consistently get > good builds in mock, across all arches I am able to test, and > consistently get segfaults on every single arch when building in koji. > I'm going to have to do the trick of

Re: Is SELinux enforcing on the koji builders?

2019-03-25 Thread Miroslav Suchý
Dne 25. 03. 19 v 4:26 John M. Harris, Jr. napsal(a): > What is the reason for builders running permissive, rather than with a > tailored targeted policy? Technical details from Mock POV: When Mock install the chroot using: dnf --installroot=/var/lib/mock/fedora-29-x86_64-bootstrap/root/

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

2019-03-25 Thread Miroslav Suchý
Dne 22. 03. 19 v 18:03 Japheth Cleaver napsal(a): > RPM should IMHO indicate scriptlets are to be written in Bourne shell, give a > 'SHOULD'-level recommendation for > POSIX-correctness, and provide a mechanism for distros to override that > default. BTW any maintainer can easily indicate that

Re: RHEL8 and Mageia7 available in Copr

2019-03-19 Thread Miroslav Suchý
Dne 19. 03. 19 v 7:51 Gerd Hoffmann napsal(a): > Hi, > >> rhelbeta-8-x86_64 > > CRB repo is missing here. I put there copy of: http://downloads.redhat.com/redhat/rhel/rhel-8-beta/rhel-8-beta.repo and I see no CRB traces there. If you have suggestion to add there some other public baseurl,

Re: /etc/yum.repos.d -> /etc/distro.repos.d

2019-03-13 Thread Miroslav Suchý
Dne 13. 03. 19 v 13:50 Kalev Lember napsal(a): > Please don't, it's just pointless renaming that invalidates all end user > documentation and makes it harder for other programs such as packagekit > and gnome-software that all need to adopt for the new paths. Not exactly true. When documentaion

Re: /etc/yum.repos.d -> /etc/distro.repos.d

2019-03-13 Thread Miroslav Suchý
Dne 13. 03. 19 v 14:03 Dridi Boukelmoune napsal(a): > Why not /etc/dnf/repos.d and a symlink for /etc/yum.repos.d? Currently DNF reads both of them. So you will end with duplicate repositories, because DNF would see them twice. Miroslav ___ devel

/etc/yum.repos.d -> /etc/distro.repos.d

2019-03-13 Thread Miroslav Suchý
Hi, I am curious whether we can move our repo files from /etc/yum.repos.d to /etc/distro.repos.d In Fedora 31 we are going to wipe away last left overs of YUM, so it really does not have sense to keep `yum.repos.d`. DNF for ages parse config files from: {"/etc/yum.repos.d",

Re: Updating Rawhide vs GPG keys

2019-03-13 Thread Miroslav Suchý
Dne 12. 03. 19 v 19:49 Kevin Fenzi napsal(a): > We need to revamp this entirely, and as luck would have it, we have a plan: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5UVGSBRLX352A4S2CBZ2CGBXPAGQTYKB/ I am afraid that this will not help in this

Re: Orphaned packages to be retired (Java packages in 3 weeks)

2019-03-12 Thread Miroslav Suchý
Dne 12. 03. 19 v 12:34 Neal Gompa napsal(a): > This whole process was handled in the worst possible way. To sum up: > * No one knew Java SIG was having manpower issues because Mikolaj > didn't know how to ask for help > * Now it's too late because he orphaned nearly 1700 packages to force >

RHEL8 and Mageia7 available in Copr

2019-03-11 Thread Miroslav Suchý
Hi, I just added those chroots to Copr: rhelbeta-8-x86_64 mageia-7-i586 mageia-7-x86_64 Please be aware that there is no available EPEL for rhelbeta-8-x86_64 yet. This chroot is intended for some initial bootstraping and testing prior RHEL 8 release and it will be removed from Copr once

Re: modular repositories in mock configs: please don't

2019-03-07 Thread Miroslav Suchý
Dne 06. 03. 19 v 14:00 Mikolaj Izdebski napsal(a): > - create a proper modulemd document > - build some (zero or more) RPM packages using rpmbuild > - create YUM repodata from built packages using createrepo_c > - attach modulemd to repodata using modifyrepo_c Yes. But the first and last steps

Fedora 30 added to FAF

2019-03-06 Thread Miroslav Suchý
Hi, I added Fedora 30 to https://retrace.fedoraproject.org/faf/summary/ Reporting from Fedora 30 works now and you should start to issues from Fedora 30 there. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Re: modular repositories in mock configs: please don't

2019-03-05 Thread Miroslav Suchý
Dne 04. 03. 19 v 17:34 Ken Dreyer napsal(a): > > I'm there with you Richard. I don't really get how I can get started building > a module outside of the Fedora > infrastructure's system (Koji or Copr). In fact, Copr support building modules for ages - even before the modularity has been

Re: Is dnf update --releasever=30 supposed to work with modules?

2019-03-03 Thread Miroslav Suchý
Dne 04. 03. 19 v 7:30 Richard W.M. Jones napsal(a): > Bonus question: Are "Problem 1" (etc) in each section of the error > message supposed to relate to each other in some way? Or is the > second list a new list of problems? You mean this error: - nothing provides module(platform:f30) needed

Re: Donate 1 minute of your time to test upgrades from F29 to F30

2019-03-03 Thread Miroslav Suchý
Dne 04. 03. 19 v 7:36 Richard W.M. Jones napsal(a): > Why is the --setopt parameter needed? Couldn't that be based on > $releasever? For the record - we are speaking about: --setopt=module_platform_id=platform:f30 I spoke to DNF team and: * there is no definition of platform_id * while

Re: Donate 1 minute of your time to test upgrades from F29 to F30

2019-03-01 Thread Miroslav Suchý
Dne 01. 03. 19 v 12:59 Marcin Juszkiewicz napsal(a): > My system was Fedora 19 when first time I installed Fedora. Now I have > packages from > each release from F20 to F29 ;d In fedora-upgrade(8) I run package-cleanup --orphans | grep -v kernel which: --orphans List

Re: Donate 1 minute of your time to test upgrades from F29 to F30

2019-03-01 Thread Miroslav Suchý
Dne 01. 03. 19 v 12:11 Diogo Galvao napsal(a): > Problem 4: package darktable-2.6.0-2.fc30.x86_64 requires > libexiv2.so.26()(64bit), but none of the providers can be installed > - problem with installed package darktable-2.6.0-2.fc29.x86_64 > - exiv2-libs-0.26-12.fc29.x86_64 does not belong

Re: modular repositories in mock configs: please don't

2019-03-01 Thread Miroslav Suchý
Dne 01. 03. 19 v 10:28 Fabio Valentini napsal(a): > Either way, I'm just strongly opposed to enable modular repos in mock > by default (yet). *nod* With the all issues it brought, it is pragmatic move to remove the modular repo. In fact, I will just set enabled=0. Done:

Re: modular repositories in mock configs: please don't

2019-03-01 Thread Miroslav Suchý
Dne 01. 03. 19 v 0:22 Miro Hrončok napsal(a): > On 01. 03. 19 0:05, Fabio Valentini wrote: >> I don't want or need modules installed for this package to build. It may be true if your specific case. But generally this is not true. AFAIK Some packages are not available in normal repo any more and

Re: abrt auto deleting problem dirs

2019-02-28 Thread Miroslav Suchý
Dne 01. 03. 19 v 1:51 Chris Murphy napsal(a): > Any suggestion on how to prevent abrt from deleting its own problem > directories? I assume it's doing this because the package isn't > signed? > > Feb 28 17:44:44 flap.local abrt-server[5743]: Package 'firefox' isn't > signed with proper key > Feb

Re: Donate 1 minute of your time to test upgrades from F29 to F30

2019-02-28 Thread Miroslav Suchý
Dne 28. 02. 19 v 18:55 Kalev Lember napsal(a): > It's difficult to obsolete subpackages correctly from > fedora-obsolete-packages when F29 keeps moving and bumping package > versions; the versioned obsoletes in fedora-obsolete-packages The rule of versioned obsolete is that the version is the

Donate 1 minute of your time to test upgrades from F29 to F30

2019-02-28 Thread Miroslav Suchý
Do you want to make Fedora 30 better? Please spend 1 minute of your time and try to run: sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync If you get this prompt: ... Total download size: XXX M Is this ok [y/N]: you can answer

Re: Broken modules on rawhide

2019-02-27 Thread Miroslav Suchý
Dne 27. 02. 19 v 12:30 Lukas Ruzicka napsal(a): > > However, you cannot upgrade from Fedora 29 to Fedora 30 with Modular > repositories allowed. It fails with an error > similar to what Mirek has reported. Disabling modular repositories fixed the > problem and an upgrade was possible, but I >

Re: Broken modules on rawhide

2019-02-27 Thread Miroslav Suchý
Dne 27. 02. 19 v 10:57 Miro Hrončok napsal(a): > If not, why do we have them in mock, that is certainly not OK. Mock has them because fedora-repos has them. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email

Broken modules on rawhide

2019-02-26 Thread Miroslav Suchý
From: https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2 When you try to run: mock -r fedora-rawhide-x86_64 shell You will get: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by module stratis:1:20181215204600:a5b0195c-0.x86_64 Problem 2: conflicting

Re: Fedora 30 Mass Branching Starting Today

2019-02-21 Thread Miroslav Suchý
Dne 19. 02. 19 v 14:26 Mohan Boddu napsal(a): > Hello All, > > Fedora 30 will be branched from rawhide today as per the Fedora 30 > schedule[1]. The process takes about a day and > everything should be ready by tomorrow. You can still be able to build > packages normally until then, but after

Re: Debugging ppc64le

2019-02-06 Thread Miroslav Suchý
Dne 06. 02. 19 v 1:47 Christoph Junghans napsal(a): > Is there a good way (qemu or something) to debug this interactively? https://github.com/rpm-software-management/mock/wiki/Feature-forcearch Miroslav ___ devel mailing list --

Re: MBI (Playground 2.0)

2019-02-01 Thread Miroslav Suchý
Dne 31. 01. 19 v 13:24 Igor Gnatenko napsal(a): > * > > COPR has been starved of resources for years, which has impaired its > ability to provide reliable service at scale. > Fedora Infrastructure refuses to consider supporting it officially and > Fedora Release Engineering seems to

Re: MBI (Playground 2.0)

2019-02-01 Thread Miroslav Suchý
Dne 01. 02. 19 v 13:21 Mikolaj Izdebski napsal(a): > - builds failing due to failure to download packages from official > Fedora mirror dl.fedoraproject.org This is not first time I hear this. So I will open discussion to (again) alter builder's mock config to point to PHX location, which is

Orphaning glacier-cli

2019-01-29 Thread Miroslav Suchý
Hi, I just orphaned `glacier-cli` package. It is command line utility for AWS Glacier service. I no longer use the Glacier and instead I am using B2, therefore I am not using this package at all. It need some love: update to recent version, migrate to python3 and I do not want to spend my time

Re: F30: System-Wide Change proposal: DNF UUID

2019-01-08 Thread Miroslav Suchý
Dne 08. 01. 19 v 11:35 Nicolas Mailhot napsal(a): > *which* *do* *not* *permit* *or* *no* *longer* *permit* *the* > *identification* *of* *data* *subjects* How do you identify data subject solely on UUID? Miroslav ___ devel mailing list --

Re: F30: System-Wide Change proposal: DNF UUID

2019-01-08 Thread Miroslav Suchý
Dne 08. 01. 19 v 11:14 Reindl Harald napsal(a): > but the UUID is sent over TCP and so you receive the current IP at the > same time with the UUID and that way you can even pofile how that > machine is moved around the country But it is not - or to be precise - will not be stored as couple, so

Re: F30: System-Wide Change proposal: DNF UUID

2019-01-08 Thread Miroslav Suchý
Dne 08. 01. 19 v 11:04 Miroslav Suchý napsal(a): > IANAL but I disagree. With IP address, I can very easily guess your > town/village. With more effort I can track you to > individual house and individual device. > You cannot say the same about UUID. I just checked and UUID is defin

Re: F30: System-Wide Change proposal: DNF UUID

2019-01-08 Thread Miroslav Suchý
Dne 08. 01. 19 v 10:10 Zbigniew Jędrzejewski-Szmek napsal(a): > I an IP address qualifies as "personal data", then an installation UUID does > too. IANAL but I disagree. With IP address, I can very easily guess your town/village. With more effort I can track you to individual house and

Re: F30: System-Wide Change proposal: DNF UUID

2019-01-08 Thread Miroslav Suchý
Dne 07. 01. 19 v 17:34 Ben Cotton napsal(a): > * We need to be able to distinguish between short-lived instances > (like temporary containers or test machines) and actual installations. How Mock should handle this? DNF executed by Mock cannot send VERSION_ID and VARIANT_ID of chroot(ed)

Hi. i wish to contribute

2018-12-07 Thread Miroslav Suchý
Dne 07. 12. 18 v 0:05 Suraj Rajendra Patil napsal(a): > Hi, my name is Suraj and I have an idea for an article which is Linux commands > im newbie to this word please guide me with proper steps . im very > enthusiastic person to > start contribute to my favorite os that is fedora

Re: Proposal: Move to an annual platform release starting at F30

2018-11-29 Thread Miroslav Suchý
Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): >> In other words, the "technical debt" we are trying to solve here is >> not project wide and doesn't justify slowing down the whole project >> permanently. > I completely disagree. Our release process and tooling is built on > heroism and tech debt.

Re: Bugzilla outage/upgrade on 2 December 2018

2018-11-27 Thread Miroslav Suchý
Dne 26. 11. 18 v 16:57 Ben Cotton napsal(a): > Bugzilla 5.0 introduces a new REST endpoint to replace XML-RPC and > JSON-RPC. The XML-RPC and JSON-RPC APIs will remain available. Before someone jumps into porting their code to the new REST API (my team tried that) - it is undocumented, the few

Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

2018-11-27 Thread Miroslav Suchý
Dne 26. 11. 18 v 17:03 Matthew Miller napsal(a): > * embrace Taiga (an open source kanban tool) for project planning > * fix the compose speed (target: one hour!) > * really actually for real gated Rawhide > * better CI pipeline tests for everything > * define a base platform -- Red Hat wants to

Re: [EPEL-devel] rhel 8 beta mock configs and EOLed mock configs

2018-11-19 Thread Miroslav Suchý
Dne 16. 11. 18 v 23:45 Orion Poplawski napsal(a): > On 11/15/18 3:05 PM, Miroslav Suchy wrote: >> Hi, >> I just released [1] new mock-core-config package which include new >> rhelbeta-8-* configs. >> This will allows you to build packages on top of RHEL 8 Beta. This is >> temporary config. I put

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

2018-11-19 Thread Miroslav Suchý
Dne 16. 11. 18 v 23:07 Jonathan Dieter napsal(a): >1. Downloading a new release of a zchunked rpm would be larger than > downloading the equivalent deltarpm. This is offset by the fact > that the client is able to work out which chunks it needs no matter > what the original

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Miroslav Suchý
Dne 14. 11. 18 v 21:11 Ben Rosser napsal(a): > Instead of working on a new "Fedora LTS" for this usage case, > would time be better spent improving EPEL and CentOS for the > desktop/laptop use case? +1 Instead of building bigger kernel team, rel-engs, security team... we can focus on CentOS

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-14 Thread Miroslav Suchý
Dne 14. 11. 18 v 0:36 Matthew Miller napsal(a): > I'd love to change these things. To do that, we need > something that lasts for 36-48 months. So that means we will be supporting something like Fedora 23 nowadays. That is Firefox 41, mock 1.2, dnf 1.1.3, ruby 2.2. systemd 222, kernel 4.2.3,

Re: could Fedora please reverse its policy re End-Of-Life

2018-11-14 Thread Miroslav Suchý
Dne 14. 11. 18 v 2:23 steve schooler napsal(a): > I recognize that since Fedora is FREE, the developers face an enormous > burden. However, I suspect that many will feel as I do that it is an onerous > user-burden to have to frequently upgrade/re-install. Further, > forum-technical-support,

Re: Ursa Major (modules in buildroot) enablement

2018-11-13 Thread Miroslav Suchý
Dne 05. 11. 18 v 16:22 Justin Forbes napsal(a): > It > is possible that some of this could be alleviated with a fairly simple > change to mock. There is no need for a change in Mock. Mock can consume modules for looong time. You can put in mock config something like: # This is executed just

Re: Upstream tip wanted: CI service for Big Endian acrhes

2018-11-12 Thread Miroslav Suchý
Dne 12. 11. 18 v 13:32 Miro Hrončok napsal(a): >  * COPR (but there is no big endian arch) >  * (Ab)using Koji (I guess that would be considered a bad practice?) >  * using QUEMU on Travis CI [1] Use Mock builds (on Travis?) with --forcearch. See

Re: Safe to remove yum?

2018-11-06 Thread Miroslav Suchý
Dne 04. 11. 18 v 14:08 Dominik 'Rathann' Mierzejewski napsal(a): > Unless you're building packages for EPEL locally using mock, > but then you can use mock --dnf. Or `mock --bootstrap-chroot`, which build in two stages. First install small root with DNF from e.g. F29 and then will use this DNF

Re: how to detect Atomic Rawhide?

2018-10-16 Thread Miroslav Suchý
Dne 16.10.2018 v 16:11 Lennart Poettering napsal(a): > Quite frankly, you are doing it wrong. It's not me. It is either author of python-distro or mantainers of fedora-release. But you are right, *someone* is doing *something* wrong. I am just trying to figure what is "someone" and "something".

how to detect Atomic Rawhide?

2018-10-16 Thread Miroslav Suchý
Hi, in DNF's Copr plugin we are detecting whether you are running in Rawhide or not, so we can enable you rawhide chroot (or numbered). We use this code: import distro distro.linux_distribution(full_distribution_name=False) which returns triplet: ('Fedora', '30', 'Rawhide') ('Fedora',

Re: Testing / feedback request: DNF 3 crashes

2018-10-12 Thread Miroslav Suchý
Dne 11.9.2018 v 21:26 Adam Williamson napsal(a): > Can anyone who is still struggling with DNF crashes on *basic* > operations on F29 or Rawhide please reply, and provide a few details on > what you're seeing and any workarounds or fixes you've found? Obviously:

Re: DNF and Modularity

2018-09-24 Thread Miroslav Suchý
Dne 24.9.2018 v 17:17 Kevin Fenzi napsal(a): > On 09/24/2018 03:24 AM, M A Young wrote: >> On Mon, 24 Sep 2018, Petr Šabata wrote: >> >>> >>> Definitely an error. >>> >>> Could be another case of >>> https://bugzilla.redhat.com/show_bug.cgi?id=1629396, but it >>> should have been fixed last week.

DNF and Modularity

2018-09-24 Thread Miroslav Suchý
Hi, I have to admit that I am a bit puzzled about DNF behavior with modularity. I have installed repo files with modularity repos, but all of them are disabled. I have no module enabled on my system (F29 BTW). To be precise: output of `dnf module list`

Retiring pgtune

2018-09-14 Thread Miroslav Suchý
I want to retire pgtune https://src.fedoraproject.org/rpms/pgtune The original upstream is dead and python2 only: https://github.com/gregs1104/pgtune There is a new upstream based on the original version: https://github.com/le0pard/pgtune But it is far of being simple. It is made in ruby

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

2018-08-27 Thread Miroslav Suchý
Dne 22.8.2018 v 22:41 Zbigniew Jędrzejewski-Szmek napsal(a): > Can we patch rpm not to show this useless line? https://github.com/rpm-software-management/rpm/issues/534 Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

Re: Fedora 29 Mass Branching

2018-08-15 Thread Miroslav Suchý
Dne 15.8.2018 v 00:37 Mohan Boddu napsal(a): > Hi All, > > Fedora 29 has now been branched, please be sure to do a git pull > --rebase to pick up the new branch, as an additional reminder > rawhide/f30 has been completely isolated from previous releases, so > this means that anything you do for

fedora-messaging for Copr - what do you need?

2018-08-11 Thread Miroslav Suchý
As part of migration of fedmsg from ZMQ to AMQP, I would like to revisit what is Copr sending to fedmsg. Right now we are sending: 'build.start': { 'what': "build start: user:{user} copr:{copr}" \ " pkg:{pkg} build:{build} ip:{ip} pid:{pid}", },

Re: RFC: make $releasever return "rawhide" on Rawhide

2018-08-02 Thread Miroslav Suchý
Dne 31.7.2018 v 15:04 Kamil Paral napsal(a): > In short, package managers on Rawhide would no longer replace $releasever > variable with a numerical value (like '29' at > this moment, soon '30'), but with 'rawhide' string instead. I hope this > change will make life a bit easier for >

Re: Packages which needlessly use %defattr

2018-07-30 Thread Miroslav Suchý
Dne 4.7.2018 v 12:18 Zbigniew Jędrzejewski-Szmek napsal(a): > What about just doing a mass specfile update now? I think asking > individual maintainers to fix their packages isn't worth their > time. -1 I like the Jason attitude much more. It gives time to discuss it. To find false positives.

Re: When will mock make it into copr?

2018-06-29 Thread Miroslav Suchý
Dne 28.6.2018 v 18:18 Radka Janekova napsal(a): > Hi, we've got some issues that were resolved[1] and I was wondering if anyone > could give me a bit better idea when would > it make into copr? It's now fixed in Mock git/master. First, it must be in proper mock release. I made last release 2

Re: F29 Self Contained Change: Deprecate YUM 3

2018-06-28 Thread Miroslav Suchý
Dne 27.6.2018 v 13:44 Vít Ondruch napsal(a): > So is it actually possible to use DNF to prepare bootstrap buildroot > containing YUM from RHEL and then the buildroot itself being managed by > YUM? Last time I tried to come up with setup like this I failed > (rhbz#1467314) ... Right. Still not

Re: F29 Self Contained Change: Deprecate YUM 3

2018-06-28 Thread Miroslav Suchý
Dne 28.6.2018 v 02:00 Kevin Kofler napsal(a): > How about changing the default config to use DNF instead? Last I checked, > the tenor was that it should work and that you just prefer using YUM 3 to > ensure the results are the same as when running mock on an EL machine, but > if YUM 3 is not

Re: F29 Self Contained Change: Deprecate YUM 3

2018-06-27 Thread Miroslav Suchý
Dne 27.6.2018 v 12:14 Vít Ondruch napsal(a): > Isn't yum required to build {RH,EP}EL{6,7} packages using Mock? > Actually, the Mock "bootstrap" feature could be used to fetch YUM from > {RH,EP}EL using DNF, but I am not sure it can be configured like this Yes, YUM is required. Technically it

Re: upcoming systemd-239 release — call for testing

2018-06-18 Thread Miroslav Suchý
Dne 18.6.2018 v 14:16 Zbigniew Jędrzejewski-Szmek napsal(a): > PS. There seems to be a regression in copr with building from src.fp.o > git. Previously I was able to point copr at the right git URL and it > would build the package. That fails [3] now with a strange error about > missing

Re: Multi-arch support in Mock

2018-06-15 Thread Miroslav Suchý
Dne 15.6.2018 v 08:40 Alexander Ploumistos napsal(a): > ERROR: Could not find useradd in chroot, maybe the install failed? I have seen this error when there was old root cache (created prior rename of unprivileged user in buildroot). Try `-r fedora-29-i386 --scrub=all`. If this is the case, it

Re: Multi-arch support in Mock

2018-06-15 Thread Miroslav Suchý
Dne 15.6.2018 v 08:40 Alexander Ploumistos napsal(a): > ERROR: Could not find useradd in chroot, maybe the install failed? I have seen this error when there was old root cache (created prior rename of unprivileged user in buildroot). Try `-r fedora-29-i386 --scrub=all`. If this is the case, it

Multi-arch support in Mock

2018-06-13 Thread Miroslav Suchý
Hi, I just pushed into updates-testing new release of Mock (1.4.11). It has nice new feature: $ sudo dnf install qemu-user-static # weak dependency $ mock -r fedora-28-ppc64le --forcearch ppc64le shell This will give you Fedora shell on different architecture. Emulated by QEMU. And of course

Re: Detecting building package on rawhide

2018-06-07 Thread Miroslav Suchý
Dne 6.6.2018 v 14:24 Jan Pazdziora napsal(a): > What would people recommend to distinguish rawhide from non-rawhide? > For now I'm running the builds in copr but eventually I'd like for > it to work in koji as well. There is nothing I can recommend. But if you asked for a hack...: * if

Re: Change in Copr retention policy?

2018-06-04 Thread Miroslav Suchý
Dne 4.6.2018 v 10:03 Jan Pazdziora napsal(a): > In any case, it'd be nice to notify the owners of those repos to give > them chance to review what they have and potentially rebuild their > content on newer buildroots, or just mark their repos "alive" and > extend the expiration for another 180

Change in Copr retention policy?

2018-06-01 Thread Miroslav Suchý
Hi, I would like to open discussion about Copr retention policy change. Right now we have: > How long do you keep the builds? ¶ > We keep the last successful build from each package indefinitely. All other > builds (old packages, failed builds) are deleted after 14 days. This means that we

Re: How to make DNS resolving fail early in mock?

2018-05-31 Thread Miroslav Suchý
Dne 30.5.2018 v 16:24 Todd Zullinger napsal(a): > But testing this briefly, the host resolv.conf still ends up > in the chroot. I'm probably overlooking something obvious. > At least, I hope I am. No, you do not overlook anything. I checked systemd code and they simply generate resolv.conf

heads up: mock's fedora-29-x configs

2018-05-02 Thread Miroslav Suchý
I just released new `mock-core-configs` and there is a new feature. It contains: $ ls -l /etc/mock ... lrwxrwxrwx. 1 root mock26 May 2 09:13 fedora-29-aarch64.cfg -> fedora-rawhide-aarch64.cfg lrwxrwxrwx. 1 root mock25 May 2 09:13 fedora-29-armhfp.cfg -> fedora-rawhide-armhfp.cfg

Re: Orphaning some Spacewalk packages

2018-04-25 Thread Miroslav Suchý
Dne 25.4.2018 v 12:03 Miro Hrončok napsal(a): > If that's the case, shouldn't they rather be retired? It is not clear (especially in this case). I decided for orphan so anyone can step in, if they want to. Miroslav ___ devel mailing list --

Re: Orphaning some Spacewalk packages

2018-04-25 Thread Miroslav Suchý
Dne 25.4.2018 v 09:33 Miroslav Suchý napsal(a): > I am going to orphan some Spacewalk packages: > perl-Satcon > spacewalk-proxy-html > spacewalk-proxy-docs > spacewalk-config > > They does not have sense to be in Fedora without additional Spacewalk > packages.

Orphaning some Spacewalk packages

2018-04-25 Thread Miroslav Suchý
I am going to orphan some Spacewalk packages: perl-Satcon spacewalk-proxy-html spacewalk-proxy-docs spacewalk-config They does not have sense to be in Fedora without additional Spacewalk packages. They live in Copr repos. But if anyone want it, feel free to grab it. Miroslav

Re: starting services in fedora

2018-04-17 Thread Miroslav Suchý
Dne 17.4.2018 v 09:23 Zbigniew Jędrzejewski-Szmek napsal(a): > Actually we do. If systemd is running and dnf is installing packages > into the same root from which it is running, it's a live system. Hmm, this will work for Mock. Thou I am not sure about others environments. Miroslav

Re: starting services in fedora

2018-04-17 Thread Miroslav Suchý
Dne 17.4.2018 v 07:46 Petr Pisar napsal(a): > Maybe nobody knows how to determine a system is live. +1 Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

  1   2   3   4   5   >