Fedora-Atomic 27-20180310.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
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

Re: test gate failures (again)

[Adam Williamson]

On Fri, 2018-03-09 at 12:02 +0100, Pavel Zhukov wrote:
> Hello,
> Gating is failed for some weird reason:
> 
> # Test died: command 'dnf -y install bodhi-client git createrepo koji'
> failed at /var/lib/openqa/share/tests/fedora/lib/utils.pm line 383.
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-fda9fed6fd
> 
> I suppose it's known issue. Is there any way to override such false
> failures? It's not needed for this particular update but waiting 6
> hours for next run is not optimal solution in case of security fixes
> etc.

No openQA tests are currently gating. Whatever was considered as
blocking your update, it was not any openQA test. At present the update
is not blocked, it seems (it shows as 'Tests Passed').

For the record, all openQA F28 update tests are failing because the
commented-out baseurls in fedora-repos (which openQA uncomments and
uses, because it can't go through the mirror system for reasons I won't
bore you with) are incorrect, and will be until this bug is fixed:

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

unless I find a few minutes to hack around it in openQA.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Kevin Kofler]

Kevin Fenzi wrote:
> yeah, but you would have even better workflow with a side tag.

The problem with a workflow relying entirely on side tags is that it is 
going to increase the risk of conflicts with concurrent changes (a 
phenomenon already somewhat present where side tags are used, but using side 
tags for everything is going to make it worse).

If my package depends on liba and libb, and if we have side tags f29-liba 
and f29-libb at the same time, when they are merged, the rebuild merged 
later will replace the one merged earlier and we will still end up with a 
half-broken package, or if we're lucky, the gating will fail the second 
merge (but only if the gated merges are serialized, otherwise there is a 
possible race condition there too).

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

Re: Gating packages in Rawhide

[Kevin Kofler]

Kevin Fenzi wrote:

> On 03/09/2018 05:42 AM, Kevin Kofler wrote:
> 
>> Because a broken dependency in ANY package included on ANY
>> release-critical deliverable now fails the ENTIRE compose process. It is
>> clear that this does not scale.
> 
> That is not what is causing the broken composes. See my last email.

At least one of the daily composes failed due to that (the last before 
things started working again). And I think several previous ones either also 
failed the same way, or the error was masked by a failure earlier in the 
process. The KDE Spin unfortunately had several issues with broken 
dependencies in those 2 weeks, e.g., I had to fight with a qt5-qtwebengine 
FTBFS caused by a GCC 8 regression that took us a few days to work around 
(and the GCC team a few more days to fix in GCC, but at least the workaround 
worked), which prevented rebuilding it for a new Qt and a new soname of some 
other library. (I do not follow the other release-blocking deliverables 
closely enough to know what their state was in those 2 weeks.)

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

Re: Fedora Rawhide-20180308.n.2 compose check report

[Adam Williamson]

On Fri, 2018-03-09 at 21:42 -0500, Dusty Mabe wrote:
> 
> On 03/09/2018 09:33 PM, Dusty Mabe wrote:
> > 
> 
>  
> > I honestly think we should 
> > 
> > - #1 - make Cloud an empty variant (It's useless, and we build repos for no 
> > reason)
> > - #2 - Cloud base images get built from Everything and put in Cloud/ 
> > directory
> 
> Note, This is exactly what we do for Container images today: 
> https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_302-315
> 
> > - #3 - Atomic Host cloud images get put in AtomicHost/ directory

In theory this sounds fine to me. There's a lot of hoary details and
history around this area, not all of which I know/understand, but for
all I know, and after talking it over with dgilmore on IRC, I can't see
any reason not to do this.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Rawhide-20180308.n.2 compose check report

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 03/09/2018 09:33 PM, Dusty Mabe wrote:
> 
 
> I honestly think we should 
> 
> - #1 - make Cloud an empty variant (It's useless, and we build repos for no 
> reason)
> - #2 - Cloud base images get built from Everything and put in Cloud/ directory

Note, This is exactly what we do for Container images today: 
https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_302-315

> - #3 - Atomic Host cloud images get put in AtomicHost/ directory
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqjRgYACgkQMwLb1zlS
5nEQMBAAyQcq9kc5yhCf8r7mtexWxEcoA25+f/ZwlTgTHIrWgmTDU+U/75ZzAZBi
w4nFYJJ21PMeA0b4XTXRHugFGdPPLynHJ1ihsdUKY5sK6Vswap3z9ZqcRXtk8A9j
V18ng4Q2RQCqTeCRP0weWD0VSFN2OwOtyjdTwD847gKRMpNA9izPwFfzCEjnh4Ap
JoSAZnMxIjvrCkgGhfxocWpKiU7bAx0NTnoq07GOWZWNk68o4gixsEF3XQB6Mc6M
LIYMRJF3gHpSJTMhYmdeKp9HuMPIii3aF/QZLYnbuhKaXHqYuagj5KbXppu6Dukq
wPx8zO648OWHrcPU90DzouVGhMSqra8cfgbLHhvLoC2CPc4FEcDnsJErfDWxeGEj
CuiJT1rPEqEvimKGUUGSv07STk/gYN0C8cGj+iThFqnB3xXYNb8t6FIWEZt/ZRGw
uOF+sN1b4aaWnr9eW5fyn8C4pKhlw+HOAczx+ANd3MeMERm8mYdfPVlKDuBguYME
B/1K5zlZXKBPN4cDgjXZUqQBCYkD06HzBknCKE4UYHnZ0KdEhVLV0ASbkj/kwI9g
eNdRkqcp7DadwZWdd/HdSkntSMVJfpOlc45IWYuyWD+I8Pif5Ugke3TPP7d8+rjo
/1l9oDn6IywCIAVEUuB0j8RE4U2TZH0SFJiqkAps4768slTWTAM=
=UbF1
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Rawhide-20180308.n.2 compose check report

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 03/08/2018 11:18 PM, Adam Williamson wrote:
> On Thu, 2018-03-08 at 22:25 -0500, Dusty Mabe wrote:
>>
>> On 03/08/2018 08:17 PM, Fedora compose checker wrote:
>>> Missing expected images:
>>>
>>> Atomichost qcow2 x86_64
>>> Atomichost raw-xz x86_64
>>
>> This is kind of interesting.. I see these images in the compose: 
>>
>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180308.n.2/compose/CloudImages/x86_64/images/
>>
>> I wonder if the name should be 
>> Fedora-AtomicHost-Rawhide-20180308.n.2.x86_64.qcow2
>> and that's why it's complaining? We should be able to fix that by updating
>> this line: https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_376
> 
> Well, nearly. It's not in fact based on the filename, but the
> subvariant property of the metadata. But you're nearly there, as you
> can see just a few lines below:
> 
> 'subvariant': 'Atomic',
> 
> I didn't realize / remember, when reviewing your changes, that only the
> ostree installer images are actually produced from the AtomicHost
> variant (note: these images wind up with AtomicHost as their subvariant
> as well as their variant, IIRC we use the variant as the subvariant any
> time there isn't an *explicit* subvariant), while the other Atomic
> images are produced in the CloudImages variant.

I honestly think we should 

- - #1 - make Cloud an empty variant (It's useless, and we build repos for no 
reason)
- - #2 - Cloud base images get built from Everything and put in Cloud/ directory
- - #3 - Atomic Host cloud images get put in AtomicHost/ directory

> 
> I'd suggest that, yes, we should change the names *and* subvariants for
> those image definitions.

PR https://pagure.io/pungi-fedora/pull-request/575#

> 
> (Note, it annoys me immensely that we just flat out specify all these
> 'name' fields. They should be generated from the metadata, not
> just...written down. But that's another issue.)
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqjQ98ACgkQMwLb1zlS
5nGAfA//e5WS5LvChfBOIqpmNPIk6WXofao+5R8JyOPDcRuWZII9nyJZDDMjYoEp
yy/ljvqJTgL/QZMcv6fNjSO4lYZo0NAx2LQlLW1WP5zrbVFMzpEpYc4+TJ/zUr3D
G30g+aytCeg/Nw1Dhz8zHIc8UwkpiToDIVPKzhhPBhgiedLkeQC+a/nNghMlFJPj
kAOcHRDfdXQazK0pYV+Wf5eTAPLbSeXz1kv3OXEqg8uYMM1eS0zVgZ3C2X7uDlUi
1m+f9LrEIKW789FpjCf08nu1HXLoikmJrzvoNHM/j+V3PQCA7nFfY0eN2iFL/6ML
loYc/Xa9nKi/6xNsSTYio7GlrQvrzmtVh6uQB1zrLyZHduaEVE2m+tmQl12UvuhW
Z5YBAU2XU2tC0w+KUekB0tsv60YP6zJDD5c1ElBqwSj+U7jK6AL0lUUXf8aAs126
LxTSvLsXtjh1q5wDu/t/50jYmZ8+du3VbYtwVkcC3u8ekN2VNNJlW/bPTgGi+K2F
81y2AG5ZABFhLZjT5F0BSDYCrQOufUDJ/BDjdnfHn9V/MeZ3qm0mDT4cm8XtpbZS
+/3KXoMOfLSSALW86lFvcFuj/xBacfQqkxupfiL9E8f9iw4np85qFGmQZUCxGUF+
VMeV7aERcEGlGrVAvsAtgSnXXshlRdylioD7QkvE7Nux4umYaRE=
=2A4d
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Debugging mock error “Failed to synchronize cache for repo 'updates'”

[Kevin Fenzi]

On 03/09/2018 09:12 AM, Florian Weimer wrote:
> On 03/09/2018 06:03 PM, Sérgio Basto wrote:
>> On Fri, 2018-03-09 at 17:47 +0100, Florian Weimer wrote:
>>> I'm trying this, on a relatively up-to-date Fedora 27 machine
>>> (mock-1.4.9-1.fc27.noarch):
>>>
>>> mock -r fedora-28-x86_64 --init
>>>
>>> and get:
>>>
>>> Start: dnf install
>>> Error: Failed to synchronize cache for repo 'updates'
>>> WARNING: Machine 00b000ffcd4543ddbe52926cee6d50d5 still running.
>>> Killing...
>>> ERROR: Command failed:
>>>    # /usr/bin/dnf --installroot /var/lib/mock/fedora-28-x86_64/root/
>>> --releasever 28 --disableplugin=local --setopt=deltarpm=False
>>> install
>>> @buildsys-build
>>> Error: Failed to synchronize cache for repo 'updates'
>>
>> disable updates ! updates will be empty until GA
> 
> I have not enabled it.  It came with the mock configuration.   Why isn't
> the metalink service handling this properly?

It is here... try clearing the mock cache?

Does:

curl
'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f28&arch=x86_64'

return a metalink with mirrors for you?

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Kevin Fenzi]

On 03/09/2018 05:42 AM, Kevin Kofler wrote:

> Broken dependency notifications are disabled because the scripts are broken: 
> they still use yum, which does not support the boolean dependencies. It is 
> sad that this was still not fixed after months. Instead of wasting their 
> time on annoyances such as update batching and now Rawhide gating, the 
> infrastructure team should instead spend it to fix the existing essential QA 
> tools.

Note that this script was disabled only 16 days ago. True it didn't
understand rich deps, but until then it was reporting all the rest
correctly. Also that tool would fall under releng, and as far as I know
infrastructure has "wasted" no time on update batching or rawhide
gating, nor really spent any time on it at all. I have definitely
personally spent time answering emails and tickets and talking in fesco
meetings, but thats as a fesco member and has nothing to do with
infrastructure.

If this tool is important to you, perhaps you would like to step up and
help fix it?
Or as a workaround you could run dnf repoclosure or look at:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180308.n.2/logs/x86_64/repoclosure-Everything.x86_64.log

https://pagure.io/releng/issue/6365  is the releng ticket tracking this
work.

...snip...
> 
> Because a broken dependency in ANY package included on ANY release-critical 
> deliverable now fails the ENTIRE compose process. It is clear that this does 
> not scale.

That is not what is causing the broken composes. See my last email.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Attempting to contact unresponsive maintainers - ggillies, vpodzime

[Kevin Fenzi]

On 03/09/2018 04:08 AM, Vratislav Podzimek wrote:
> Hi,
> 
> I don't really know how I got to this list. I do have my new email
> address in FAS and I haven't gotten any questions about the AADG recently.

As long as your email address is up to date in fas you should be fine. :)

kevin
--
> 
> 
> Regards,
> 
> Vratislav
> 
> 
> On 03/05/2018 09:10 PM, Kevin Fenzi wrote:
>> Greetings, we've been told that the email addresses for these package
>> maintainers are no longer valid. I'm starting the unresponsive
>> maintainer policy to find out if they are still interested in
>> maintaining their packages (and if so, have them update their email
>> addresses in FAS).
>>
>> If they're not interested in maintaining or we can't locate them in 1
>> week, I'll have FESCo orphan the packages so that others can take them
>> over.
>>
>> If you have a way to contact these maintainers, please let them know
>> that we'd appreciate knowing what to do with their packages. Thanks!
>>
>> ggillies:
>>
>> rpms/rubygem-amq-protocol
>> rpms/rubygem-eventmachine
>> rpms/rubygem-em-worker
>> rpms/rubygem-sigdump
>>
>> vpodzime:
>>
>> Fedora Documentation/anaconda-addon-development-guide
>>
>> kevin
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: test gate failures (again)

[Kevin Fenzi]

On 03/09/2018 03:02 AM, Pavel Zhukov wrote:
> Hello,
> Gating is failed for some weird reason:
> 
> # Test died: command 'dnf -y install bodhi-client git createrepo koji'
> failed at /var/lib/openqa/share/tests/fedora/lib/utils.pm line 383.
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-fda9fed6fd
> 
> I suppose it's known issue. Is there any way to override such false
> failures? It's not needed for this particular update but waiting 6
> hours for next run is not optimal solution in case of security fixes
> etc.

I think you can unpush the update, then re-request testing and it should
fire the tests again. Unfortunately, I think you loose karma doing that.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: grubby - /boot on btrfs support

[Nathaniel McCallum]

Thomasz, could you please leave karma on the bodhi update?

https://bodhi.fedoraproject.org/updates/grubby-8.40-10.fc28

I already have a patch against anaconda.

https://github.com/rhinstaller/anaconda/pull/1375

On Fri, Mar 9, 2018 at 4:04 AM, Tomasz Kłoczko 
wrote:

> On 7 March 2018 at 04:12, Nathaniel McCallum 
> wrote:
> >
> > https://bodhi.fedoraproject.org/updates/grubby-8.40-10.fc28
> >
> > We've built grubby with support for /boot on btrfs. We're trying to
> > land this in F28. But we need testers. That's where you come in! If
> > you ever interact with grubby and especially if you have an exotic
> > grub2 setup, please download and test this release. As usual provide
> > feedback in Bodhi (link at the top of this email). Thanks!
>
> Just tested new grubby on two systems. Here is my subvols layout from one
> of those systems (my laptop):
>
> # btrfs subvolume list -R /
> ID 257 gen 1381846 top level 5 received_uuid -
>path root
> ID 535 gen 1381846 top level 257 received_uuid -
>  path var
> ID 536 gen 1376990 top level 257 received_uuid -
>  path home
> ID 537 gen 1381838 top level 257 received_uuid -
>  path boot
> ID 746 gen 1381846 top level 535 received_uuid -
>  path var/lib/mysql
> ID 1287 gen 1364400 top level 535 received_uuid -
>path var/lib/machines
> ID 1325 gen 1381846 top level 536 received_uuid -
>path home/tkloczko
> ID 1326 gen 1381756 top level 1325 received_uuid -
>path home/tkloczko/git
> ID 1327 gen 1381846 top level 1326 received_uuid -
>path home/tkloczko/git/fedora
> ID 1328 gen 1381756 top level 1326 received_uuid -
>path home/tkloczko/git/linux-git
> ID 1329 gen 1380131 top level 1325 received_uuid -
>path home/tkloczko/src-packages
> ID 1331 gen 1381807 top level 1329 received_uuid -
>path home/tkloczko/src-packages/fedora
> ID 1332 gen 1381082 top level 1329 received_uuid -
>path home/tkloczko/src-packages/suse
> ID 1333 gen 1381554 top level 1329 received_uuid -
>path home/tkloczko/src-packages/altlinux
> ID 1334 gen 1380955 top level 1329 received_uuid -
>path home/tkloczko/src-packages/centos
> ID 1335 gen 1381188 top level 1329 received_uuid -
>path home/tkloczko/src-packages/mageia
> ID 1336 gen 1381748 top level 1329 received_uuid -
>path home/tkloczko/src-packages/debian
>
> Looks like it works.
> On the second system, I have no separated /boot and grub2.cfg has been
> updated correctly as well.
> Good job 👍💪
> Now it would be good to remove from anaconda blocking use btrfs on roofs
> as well 😃
>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Kevin Fenzi]

On 03/08/2018 11:10 PM, Milan Crha wrote:
> On Thu, 2018-03-08 at 11:24 -0800, Kevin Fenzi wrote:
>> * CI/automated tests run on it, and if all is ok goes out in the next
>> rawhide compose.
>> * If not ok, you could wave the results or build more things/edit the
>> update until it passes.
> 
>   Hi,
> so it looks like you are going to remove chain-build from fedpkg,

yeah, but you would have even better workflow with a side tag.

> right? It's kind of pain it doesn't work for stable, but if you want to
> get rid of it for rawhide too, or add some unnecessary obstacles for
> its usage, then it's a downgrade like the kerberos usage (it's a pain
> to write my password all the time when I want to do something in
> packaging, with compare of once-per-year replace of the certificate,
> but that's another story, which only adds to the feeling of making
> process more and more painful instead of simpler (I heard some time ago
> something like this "security by obscurity", with which I fully
> agree)). 

Note that if you use KCM (now default) and it works (It has some bugs),
you only need to enter your password once a week. Also note that it's
much more industry standard, and its much harder to have someone just
take your cert and do things as you.

I chain-build like this "A : B : C D", which means in stable
> that I build A, then fill override, then I build B, then fill an
> override, the I build C and D and then I fill the update. I hope the
> difference in stable and chain-build usage is obvious.

Sure, with this proposal you would:

* request a side tag
* build a, wait for it to be added to the repo, build b, etc.
You would not need to file overrides, just build them in the right order
with wait-repo between them.

> Anyway, could you enlighten what you call "if all is ok"? That's pretty
> important measure.
If all the tests we determine should gate packages pass.

I'd like to see a 'no new broken deps' test/check... but we could change
the tests over time.

> 
> What do I do if it's not ok?

Fix your package(s) and resubmit for new tests, or if you feel the test
is wrong file a bug on it and waive the results.

> I do maintain a package which is in critpath. I'm not a proven
> packager, thus I cannot touch anyone's package (I hesitate to do it
> anyway, even there are cases where are not many other options). If my
> critpath package changes API and soname versions, then other packages,
> for which I do not have commit rights, will be broken by that update,
> but the update as such will build and look just fine. What do I do now?

You request a side tag, build your new package in that, then tell all
the dependent package maintainers to use that side tag to rebuild all
their packages. Once everyone is done, you (or someone else) submits it
for testing as a unit.

> Will I hunt for respective maintainers and co-maintainers kindly asking
> them to do something about it? The paper work around this (finding who
> it is, their email addresses, writing them a mail) would be a pain on
> its own, but more painful would be the delay in the delivery. It will
> not be rawhide anymore, from my point of view.

yes. You can use dnf repoquery to tell what uses your package and needs
rebuilding. All those people should be watching your package or at least
easy to communicate to.

sure, it might not be rawhide, it will be much more sane.

> I'd rather prefer to have detected issues in updates early (though it's
> understandable that doing API/ABI checks after each package update is
> not doable at least due to resource requirements - thus you'd not
> detect it with the gating too, right?), or at least like once a day.

Not sure what you mean here... yes, we could do a check right before a
compose, but then you have a lag after you build your package until it
gets kicked out before the compose. Much better to check it as soon as
we can so you can know and act on it.

> I did a soname version bump in one of my packages recently and
> announced it, with a list of "possibly affected packages". I know my
> work flow is wrong in this regard, but I kind of rely on the
> notifications of broken dependencies to rebuild what is really needed
> to be rebuilt, because the packages sometimes requires something bigger
> in the build time, which is not actually used in the run time (just my
> feeling, no prove available). I didn't receive any single notification
> of broken dependencies this time. While it's possible someone was just
> quicker than me, I believe it's highly unlikely. I also believe I
> didn't filter out any such "broken dependencies" mail notifications
> from my notification settings, they used to come in the past.

As mentioned downstream the broken deps checking script was turned off
because it doesn't understand rich deps. Also, we have had very few f28
or rawhide composes this last week.
> 
> That's also another disadvantage of the gating. I recall seeing broken
> dependencies messages for package I've no commit righ

Re: Gating packages in Rawhide

[Mathieu Bridon]

On Fri, 2018-03-09 at 10:38 +0100, Pierre-Yves Chibon wrote:
> On Fri, Mar 09, 2018 at 10:12:37AM +0100, Mathieu Bridon wrote:
> > We could take a hint from how we make software upstream these days:
> > 
> > 1. submit a pull request for the package in src.fp.o on the master
> >branch
> > 2. a CI automatically builds this package in Koji
> > 3. merge the pull request into master
> > 4. the build (from step 2) is tagged for Rawhide, without a rebuild
> > 
> > Gating is achieved by preventing merges if the build/tests fail.
> 
> This has been discussed but requires a way for koji to "promote"
> scratch builds
> to real builds and this isn't a small task.
> Long term, I do think this is a good idea anyway yes.

It doesn't have to be scratch builds, it could be real builds in a side
tag.


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

Summary/Minutes for today's FESCo meeting (2018-03-09)

[Zbigniew Jędrzejewski-Szmek]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-09/fesco.2018-03-09-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-09/fesco.2018-03-09-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-09/fesco.2018-03-09-15.00.log.html

Meeting summary
---
* Roll Call  (sgallagh, 15:01:06)

* #1853 F29 System Wide Change: Enable dbus-broker  (zbyszek, 15:05:16)
  * LINK: https://pagure.io/fesco/issue/1853   (zbyszek, 15:05:17)

* #1845 389-ds-base and freeipa on 32 bit arches  (zbyszek, 15:07:13)
  * LINK: https://pagure.io/fesco/issue/1845   (zbyszek, 15:07:13)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1530832#c9 has
more info  (sgallagh, 15:08:26)
  * LINK:
https://src.fedoraproject.org/rpms/389-ds/blob/master/f/389-ds.spec:
(zbyszek, 15:19:12)
  * LINK:
https://src.fedoraproject.org/rpms/389-ds/blob/f28/f/389-ds.spec
(bowlofeggs, 15:23:22)
  * LINK:
https://src.fedoraproject.org/rpms/389-ds/blob/master/f/389-ds.spec
(bowlofeggs, 15:24:20)
  * LINK:

https://src.fedoraproject.org/rpms/389-ds-base/blob/f28/f/389-ds-base.spec#_5
(nirik, 15:24:30)
  * AGREED: FESCo requires that a Change be filed for F28, and involved
are otherwise free to sort out the issue (+6, 0, -0)  (zbyszek,
15:30:18)
  * If the change is accepted, releng changes will be required
(zbyszek, 15:30:21)

* #1820 Adjust/Drop/Document batched updates policy  (zbyszek, 15:30:52)
  * LINK: https://pagure.io/fesco/issue/1820   (zbyszek, 15:30:52)
  * AGREED: Ask QA about batch testing plans, go back to normal pushes,
discuss bodhi/other plans on list, revisit next week (+7, 0, -0)
(zbyszek, 16:01:00)

* #1745 F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
  (zbyszek, 16:01:49)
  * LINK: https://pagure.io/fesco/issue/1745   (zbyszek, 16:01:50)
  * AGREED: F28 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
is reapproved (+6, 0, 0)  (zbyszek, 16:05:21)

* FESCo meeting time  (zbyszek, 16:05:31)
  * LINK: http://whenisgood.net/fesco2018roundtwo/results/ss5khfp
(zbyszek, 16:05:48)

* #1861 F28 Changes not in ON_QA status (<100% completed)  (zbyszek,
  16:11:30)
  * LINK: https://pagure.io/fesco/issue/1861   (zbyszek, 16:11:30)
  * AGREED: Django packages which are incompatible with Django2.0 will
be retired after one more week (+5, 0, 0)  (zbyszek, 16:19:23)

* #1859 Review of release blocking deliverables for F28  (zbyszek,
  16:19:36)
  * AGREED: Wait another week for changes not in ON_QA status (+6, 0,
-0)  (zbyszek, 16:35:08)

* #1859 Review of release blocking deliverables for F28  (zbyszek,
  16:35:31)
  * LINK: https://pagure.io/fesco/issue/1859   (zbyszek, 16:35:59)
  * AGREED: Proposed list is approved. Modular deliverables may be added
to the list later when there are testing guidelines and release
criteria for them (+6, 0, -0)  (zbyszek, 16:47:11)
  * ACTION: sgallagh to start a thread on the mailing lists (devel and
test) about the criteria  (zbyszek, 16:47:15)

* #1858 Proposed Fedora 29 schedule  (zbyszek, 16:48:12)
  * LINK: https://pagure.io/fesco/issue/1858   (zbyszek, 16:48:12)
  * AGREED: Punt on Proposed Fedora 29 schedule for a week to discuss
moving "infra freeze" one day after bodhi activation (+7, 0, 0)
(zbyszek, 16:58:56)

* #1860 allow major version bump of rpkg utility  (zbyszek, 16:59:02)
  * LINK: https://pagure.io/fesco/issue/1860   (zbyszek, 16:59:03)
  * AGREED: Proposed allow major version bump of rpkg utility is
accepted (+8, 0, 0)  (zbyszek, 17:01:59)

* Next week's chair  (zbyszek, 17:02:02)
  * ACTION: jsmith will chair next meeting  (zbyszek, 17:08:26)
  * ACTION: jsmith will get the world to stop doing DST and have
everyone just switch to UTC  (bowlofeggs, 17:08:44)

* Open Floor  (zbyszek, 17:09:15)

Meeting ended at 17:10:38 UTC.


Action Items

* sgallagh to start a thread on the mailing lists (devel and test) about
  the criteria
* jsmith will chair next meeting
* jsmith will get the world to stop doing DST and have everyone just
  switch to UTC


Action Items, by person
---
* jsmith
  * jsmith will chair next meeting
  * jsmith will get the world to stop doing DST and have everyone just
switch to UTC
* sgallagh
  * sgallagh to start a thread on the mailing lists (devel and test)
about the criteria
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

referenced in section, defined in discarded section linking failure

[Julian Sikorski]

Hi list,

latest F28 mame build [1] has failed at the linking stage on x86_64 only
with the following error:

`_ZSt20__replacement_assertPKciS0_S0__end' referenced in section
`.gnu.build.attributes' of
../../../../linux_gcc/bin/x64/Release/mame_mame/libsega.a(model1.o):
defined in discarded section
`.text._ZSt20__replacement_assertPKciS0_S0_[_ZSt20__replacement_assertPKciS0_S0_]'
of ../../../../linux_gcc/bin/x64/Release/mame_mame/libsega.a(model1.o)

Strangely enough, the same build has succeeded on rawhide [2]. This is
confusing, as both branches were using the same gcc release,
8.0.1-0.16.fc28 and 8.0.1-0.16.fc29, respectively. Any ideas what might
be causing this? Thanks for the input in advance.

Best regards,
Julian

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25582153
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=25577453
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Debugging mock error “Failed to synchronize cache for repo 'updates'”

[Florian Weimer]

On 03/09/2018 06:03 PM, Sérgio Basto wrote:

On Fri, 2018-03-09 at 17:47 +0100, Florian Weimer wrote:

I'm trying this, on a relatively up-to-date Fedora 27 machine
(mock-1.4.9-1.fc27.noarch):

mock -r fedora-28-x86_64 --init

and get:

Start: dnf install
Error: Failed to synchronize cache for repo 'updates'
WARNING: Machine 00b000ffcd4543ddbe52926cee6d50d5 still running.
Killing...
ERROR: Command failed:
   # /usr/bin/dnf --installroot /var/lib/mock/fedora-28-x86_64/root/
--releasever 28 --disableplugin=local --setopt=deltarpm=False
install
@buildsys-build
Error: Failed to synchronize cache for repo 'updates'


disable updates ! updates will be empty until GA


I have not enabled it.  It came with the mock configuration.   Why isn't 
the metalink service handling this properly?


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

Re: Debugging mock error “Failed to synchronize cache for repo 'updates'”

[Sérgio Basto]

On Fri, 2018-03-09 at 17:47 +0100, Florian Weimer wrote:
> I'm trying this, on a relatively up-to-date Fedora 27 machine 
> (mock-1.4.9-1.fc27.noarch):
> 
> mock -r fedora-28-x86_64 --init
> 
> and get:
> 
> Start: dnf install
> Error: Failed to synchronize cache for repo 'updates'
> WARNING: Machine 00b000ffcd4543ddbe52926cee6d50d5 still running.
> Killing...
> ERROR: Command failed:
>   # /usr/bin/dnf --installroot /var/lib/mock/fedora-28-x86_64/root/ 
> --releasever 28 --disableplugin=local --setopt=deltarpm=False
> install 
> @buildsys-build
> Error: Failed to synchronize cache for repo 'updates'

disable updates ! updates will be empty until GA 

> And that's it.   Adding -vv doesn't provide more information, e.g.
> which 
> URL download is failing.
> 
> I tried --dnf-cmd, but the -vv for that is still processed by mock
> only, 
> it seems.
> 
> Any suggestions?
> 
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Debugging mock error “Failed to synchronize cache for repo 'updates'”

[Florian Weimer]

I'm trying this, on a relatively up-to-date Fedora 27 machine 
(mock-1.4.9-1.fc27.noarch):


mock -r fedora-28-x86_64 --init

and get:

Start: dnf install
Error: Failed to synchronize cache for repo 'updates'
WARNING: Machine 00b000ffcd4543ddbe52926cee6d50d5 still running. Killing...
ERROR: Command failed:
 # /usr/bin/dnf --installroot /var/lib/mock/fedora-28-x86_64/root/ 
--releasever 28 --disableplugin=local --setopt=deltarpm=False install 
@buildsys-build

Error: Failed to synchronize cache for repo 'updates'

And that's it.   Adding -vv doesn't provide more information, e.g. which 
URL download is failing.


I tried --dnf-cmd, but the -vv for that is still processed by mock only, 
it seems.


Any suggestions?

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

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 03/06/2018 05:55 PM, Sérgio Basto wrote:

Again, IMHO, wiki page should be updated (add something like: -z defs
was postponed ... ) and still it should be added a link to
buildflags.md .


Okay, I made some edits.


BTW "%define _strict_symbol_defs_build 1" will enable -z defs ?


Yes.

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

Re: Re: Broken system upgrade due to rich dependencies

[Stephen John Smoogen]

On 8 March 2018 at 14:37, Tony Nelson  wrote:
> On 18-03-07 14:14:38, Nicolas Mailhot wrote:
>>
>> Le mercredi 07 mars 2018 à 12:18 -0500, Josh Boyer a écrit :
>> > On Wed, Mar 7, 2018 at 12:11 PM, Nicolas Mailhot
>> >  wrote:
>> > > Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a écrit
>> > > :
>> > > >
>> > > > I don't know if this is useful but in the RHL and early Fedora
>> > > > days,
>> > > > the way to do inplace upgrades was to first update just the 'core'
>> > > > tools needed by rpm.
>> >
>> > This is a totally unrelated comment, but I will personally send you $5
>> > if you can configure your email client to stop adding  in the
>> > Subject line for every thread you reply to.
>>
>> I'm pretty sure that's added by one of the MTAs in the chain between
>> Fedora SMTP and my ISP MTA, to attest they did DKIM verification, since
>> I see it already positioned on some received messages before I ever
>> replied to them.
>
>
> Presumably by bastion01.phx2.fedoraproject.org (Postfix), which adds the
> lines:
>

No, I don't think so. I can't find anything in the configuration which
would do this and I have a sneaking suspicion that if it was bastion
then most emails would get their subject changed. After going through
most of the email logs for the last 2 days, the only emails which
consistently passed DKIM tests were SPAM from various shady sources.
Most user email do not pass DKIM tests on any of the spamassassin logs
we have. So I would expect a lot of people to see DKIM in their
headers. The only one I could find is email from Nicholas.

The problem looks to be what Nicholas said in a different email about
mailman not stripping headers. The laposte servers are particular
about how they interpret simple DKIM signatures versus wraparound and
this is where his replies seem to fork a new thread. [There are
multiple types of DKIM headers depending on whether email servers only
limit to X characters per line or similar limitations].

In any case, the mailman3 server will now dkim from emails and will
see if that fixes the issue. If it doesn't then we will go to see what
else could be causing the issue.


> DKIM-Filter: OpenDKIM Filter v2.11.0 bastion01.phx2.fedoraproject.org
>  2E4116051DFD
> Authentication-Results: bastion01.phx2.fedoraproject.org;   dkim=fail
>  reason="signature verification failed" (2048-bit key) header.d=laposte.net
>  header.i=@laposte.net header.b="bKrmUuvt"
>
> --
> 
> TonyN.:'   
>   '  
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: Fedora 28 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze

[Till Hofmann]

On 03/08/2018 03:54 PM, Kevin Kofler wrote:
> I wrote:
>> Fedora:
>>> Beta and Final freezes are in effect from 00:00 UTC of the freeze day.
>>
>> KDE:
>>> All deadlines are due 23:59 UTC, but if you need a few more hours, notify
>>> someone from the release team.
> 
> PS: The deadlines I encountered for academic CfPs were also KDE style (23:59 
> in a specified time zone), or in very rare occasions at a specified time 
> during the say, e.g., noon (12:00), but never Fedora style (00:00).

Academic deadlines are often even 23:59 UTC-12, so you can always submit
on the day of the deadline at any time of your local time, no matter
where you live.

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

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Florian Weimer]

On 03/09/2018 04:26 PM, Michael Schwendt wrote:

On Fri, 9 Mar 2018 16:14:39 +0100, Florian Weimer wrote:


On 01/29/2018 03:38 PM, Michael Schwendt wrote:

The reason why I ask is that Claws Mail still uses encrypt() with the sole
purpose of being able to decrypt old passwords. It doesn't convert them to
different encryption algorithms automatically, unless the user changes the
password, and it doesn't force the user to set a Master Password either.
Only the latter would add security since Claws Mail 3.14.0 (2016), which
added that as a new feature.


Which cryptographic library does Claws Mail use to implement the other
encryption algorithm?


GnuTLS


GnuTLS uses Nettle, but does not provide access to DES.  You can use 
Nettle directly:


https://www.lysator.liu.se/~nisse/nettle/nettle.html#DES

OpenSSL will work as well, but as Nettle is a preexisting dependency, 
it's probably the right choice here.


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

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

On Fri, 9 Mar 2018 16:14:39 +0100, Florian Weimer wrote:

> On 01/29/2018 03:38 PM, Michael Schwendt wrote:
> > The reason why I ask is that Claws Mail still uses encrypt() with the sole
> > purpose of being able to decrypt old passwords. It doesn't convert them to
> > different encryption algorithms automatically, unless the user changes the
> > password, and it doesn't force the user to set a Master Password either.
> > Only the latter would add security since Claws Mail 3.14.0 (2016), which
> > added that as a new feature.  
> 
> Which cryptographic library does Claws Mail use to implement the other 
> encryption algorithm?

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

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Florian Weimer]

On 01/29/2018 03:38 PM, Michael Schwendt wrote:

The reason why I ask is that Claws Mail still uses encrypt() with the sole
purpose of being able to decrypt old passwords. It doesn't convert them to
different encryption algorithms automatically, unless the user changes the
password, and it doesn't force the user to set a Master Password either.
Only the latter would add security since Claws Mail 3.14.0 (2016), which
added that as a new feature.


Which cryptographic library does Claws Mail use to implement the other 
encryption algorithm?


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

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

On Mon, 29 Jan 2018 15:38:00 +0100, Michael Schwendt wrote:

> On Tue, 9 Jan 2018 18:46:06 +0100, Jan Kurik wrote:
> 
> > = System Wide Change: Replace glibc's libcrypt with libxcrypt =
> > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
> > 
> > Change owner(s):
> > * Björn Esser 
> > * Florian Weimer 
> > 
> > There are plans to remove libcrypt from glibc, so we should have a 
> > replacement.
> >   
> 
> Please clarify what exactly the plan is.
> 
> To replace libcrypt with a compatible library and with a grace period for
> apps to stop using deprecated functions that may be removed in the future?
> 
> Or to replace libcrypt with an incompatible library immediately with no
> grace period?
> 
> 
> The reason why I ask is that Claws Mail still uses encrypt() with the sole
> purpose of being able to decrypt old passwords. It doesn't convert them to
> different encryption algorithms automatically, unless the user changes the
> password, and it doesn't force the user to set a Master Password either.
> Only the latter would add security since Claws Mail 3.14.0 (2016), which
> added that as a new feature.

I had hoped there would be a response to this.
Another try with the two change owners in Cc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Vít Ondruch]

Dne 9.3.2018 v 15:23 Colin Walters napsal(a):
> A more modern architecture would be something closer to pull requests on 
> dist-git;
> tests report into the PR the same way github works today.

May be if we had all .spec files in single repository .

V.


>
> This would work *particularly* well if it was easy to make a pull request 
> across
> multiple packages, which would be obvious and easy if we just one git repo
> rather than thousands.  (Or perhaps core/extras git repos).
>
> Examples of systems that work this way:
>
>  https://github.com/NixOS/nixpkgs
>  https://github.com/openembedded/openembedded-core
>  https://github.com/clearlinux/clr-bundles
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: unresponsive maintainer: nss-mdns

[Adam Goode]

> On Do, 08.03.18 16:51, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) 
> wrote:
> 
> 
> Urks. That form doesn't support searching by real name. Adam, what's
> you fedora user name?
> 

My FAS name is "agoode".


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

Re: Gating packages in Rawhide

[Colin Walters]

On Fri, Mar 9, 2018, at 9:23 AM, Colin Walters wrote:
> A more modern architecture would be something closer to pull requests on 
> dist-git;
> tests report into the PR the same way github works today.
> 
> This would work *particularly* well if it was easy to make a pull request 
> across
> multiple packages, which would be obvious and easy if we just one git repo
> rather than thousands.  (Or perhaps core/extras git repos).
> 
> Examples of systems that work this way:
> 
>  https://github.com/NixOS/nixpkgs
>  https://github.com/openembedded/openembedded-core
>  https://github.com/clearlinux/clr-bundles

Oh and how could I forget:

https://github.com/coreos/coreos-overlay/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Colin Walters]

A more modern architecture would be something closer to pull requests on 
dist-git;
tests report into the PR the same way github works today.

This would work *particularly* well if it was easy to make a pull request across
multiple packages, which would be obvious and easy if we just one git repo
rather than thousands.  (Or perhaps core/extras git repos).

Examples of systems that work this way:

 https://github.com/NixOS/nixpkgs
 https://github.com/openembedded/openembedded-core
 https://github.com/clearlinux/clr-bundles
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Improving the glibc32 situation

[Florian Weimer]

On 03/09/2018 03:01 PM, Dennis Gilmore wrote:

El vie, 09-03-2018 a las 14:55 +0100, Florian Weimer escribió:

On 03/09/2018 02:52 PM, Josh Boyer wrote:


Stepping back a bit, I'm curious why glibc32 would land in the
composes.  It shouldn't...  it should only be tagged in the fNN-
build
tags, which the composes should not pull from.  Where do we have
recent issues of it getting pulled into a compose?


It happens after every single mass rebuild.  The package is rebuilt
and
tagged, and then *boom*.

Thanks,
Florian


I think we can resolve this by adding glibc32 to the mass rebuild
blacklist. then it will not be rebuilt.  the sources for it is
precompiled binaries so rebuilding does nothing


Looks that this would be a small but helpful step forward.

What would we have to do, as package maintainers, in order to avoid the 
same issue when rebuilding the package manually?  I would like to put a 
bit fat warning into the glibc32.spec file.


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

Re: Improving the glibc32 situation

[Dennis Gilmore]

El vie, 09-03-2018 a las 14:55 +0100, Florian Weimer escribió:
> On 03/09/2018 02:52 PM, Josh Boyer wrote:
> 
> > Stepping back a bit, I'm curious why glibc32 would land in the
> > composes.  It shouldn't...  it should only be tagged in the fNN-
> > build
> > tags, which the composes should not pull from.  Where do we have
> > recent issues of it getting pulled into a compose?
> 
> It happens after every single mass rebuild.  The package is rebuilt
> and 
> tagged, and then *boom*.
> 
> Thanks,
> Florian

I think we can resolve this by adding glibc32 to the mass rebuild
blacklist. then it will not be rebuilt.  the sources for it is
precompiled binaries so rebuilding does nothing

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Improving the glibc32 situation

[Florian Weimer]

On 03/09/2018 02:52 PM, Josh Boyer wrote:


Stepping back a bit, I'm curious why glibc32 would land in the
composes.  It shouldn't...  it should only be tagged in the fNN-build
tags, which the composes should not pull from.  Where do we have
recent issues of it getting pulled into a compose?


It happens after every single mass rebuild.  The package is rebuilt and 
tagged, and then *boom*.


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

Re: Improving the glibc32 situation

[Josh Boyer]

On Fri, Mar 9, 2018 at 8:44 AM, Florian Weimer  wrote:
> On 03/09/2018 02:21 PM, Josh Boyer wrote:
>
>>> So as a stop-gap measure, I'd like to add this:
>>>
>>> Conflicts: kernel
>>
>>
>> That's a metapackage now, which isn't actually required for installs.
>> Better to do it on kernel-core, however..
>
>
> Noted.
>
>>> to the glibc32 package, to make it very unlikely that end users can
>>> install
>>> it and completely break there Fedora installation.  Buildroots shouldn't
>>> have kernels, so it wouldn't affect them.
>>>
>>> Comments?  Suggestions?
>>
>>
>> Buildroots have kernels all the time.  Various packages like
>> libguestfs require it because they run virt tests during RPM build.
>> The 4.16-rc4 kernel-core was a component of gnome-software,
>> libtaskotron, plasma-discover, etc.  Now, whether or not those also
>> needed glibc32 in the buildroot is a different question.  I'm simply
>> pointing out it might not be a safe assumption to assume the
>> kernel/kernel-core packages are never installed in the buildroot.
>
>
> Hmm.  Do you think it's still worth a try?

Maybe.  We could add it and see what breaks.  Might be a nice way to
figure out if people have incorrect dependencies on things too, but I
suspect there are a few cases where this might cause issues with valid
usage.

>> Perhaps it would be better to put:
>>
>> %ifarch x86_64
>> Conflicts:glibc32
>> %endif
>>
>> in the kernel spec?
>
>
> What's the improvement compared to the glibc32 change?  Would we still add
> that to the kernel-core package?

I guess, now that I've had coffee, there isn't really a difference.

Stepping back a bit, I'm curious why glibc32 would land in the
composes.  It shouldn't...  it should only be tagged in the fNN-build
tags, which the composes should not pull from.  Where do we have
recent issues of it getting pulled into a compose?

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

Re: Gating packages in Rawhide

[Kevin Kofler]

Pierre-Yves Chibon wrote:
> I had a different idea in mind, basically try to keep the experience as
> close as what it is now.

Your proposal makes sense, it sounds like how I would do it too. If we want 
gating at all, it should be done that way.

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

Re: Gating packages in Rawhide

[Kevin Kofler]

Kevin Fenzi wrote:
> To be fair, there was a suggestion that we show results in
> pagure/src.fedoraproject.org, but to me, that definitely sounds like the
> wrong place for such things.

I think they should be displayed in Koji on the build info page for the 
particular build that was tested. That seems the most logical place to me. 
It is where I would look for it first, in any case.

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

Re: Improving the glibc32 situation

[Florian Weimer]

On 03/09/2018 02:21 PM, Josh Boyer wrote:


So as a stop-gap measure, I'd like to add this:

Conflicts: kernel


That's a metapackage now, which isn't actually required for installs.
Better to do it on kernel-core, however..


Noted.


to the glibc32 package, to make it very unlikely that end users can install
it and completely break there Fedora installation.  Buildroots shouldn't
have kernels, so it wouldn't affect them.

Comments?  Suggestions?


Buildroots have kernels all the time.  Various packages like
libguestfs require it because they run virt tests during RPM build.
The 4.16-rc4 kernel-core was a component of gnome-software,
libtaskotron, plasma-discover, etc.  Now, whether or not those also
needed glibc32 in the buildroot is a different question.  I'm simply
pointing out it might not be a safe assumption to assume the
kernel/kernel-core packages are never installed in the buildroot.


Hmm.  Do you think it's still worth a try?


Perhaps it would be better to put:

%ifarch x86_64
Conflicts:glibc32
%endif

in the kernel spec?


What's the improvement compared to the glibc32 change?  Would we still 
add that to the kernel-core package?


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

Re: Gating packages in Rawhide

[Kevin Kofler]

Milan Crha wrote:
> so it looks like you are going to remove chain-build from fedpkg,
> right? It's kind of pain it doesn't work for stable, but if you want to
> get rid of it for rawhide too, or add some unnecessary obstacles for
> its usage, then it's a downgrade like the kerberos usage (it's a pain
> to write my password all the time when I want to do something in
> packaging, with compare of once-per-year replace of the certificate,
> but that's another story, which only adds to the feeling of making
> process more and more painful instead of simpler (I heard some time ago
> something like this "security by obscurity", with which I fully
> agree)). I chain-build like this "A : B : C D", which means in stable
> that I build A, then fill override, then I build B, then fill an
> override, the I build C and D and then I fill the update. I hope the
> difference in stable and chain-build usage is obvious.

+1

> Anyway, could you enlighten what you call "if all is ok"? That's pretty
> important measure.
> 
> What do I do if it's not ok?

I guess then you will need to fix whatever the gating is complaining about 
and start all over again. :-(

> I do maintain a package which is in critpath. I'm not a proven
> packager, thus I cannot touch anyone's package (I hesitate to do it
> anyway, even there are cases where are not many other options). If my
> critpath package changes API and soname versions, then other packages,
> for which I do not have commit rights, will be broken by that update,
> but the update as such will build and look just fine. What do I do now?
> Will I hunt for respective maintainers and co-maintainers kindly asking
> them to do something about it? The paper work around this (finding who
> it is, their email addresses, writing them a mail) would be a pain on
> its own, but more painful would be the delay in the delivery. It will
> not be rawhide anymore, from my point of view.

+1

> I did a soname version bump in one of my packages recently and
> announced it, with a list of "possibly affected packages". I know my
> work flow is wrong in this regard, but I kind of rely on the
> notifications of broken dependencies to rebuild what is really needed
> to be rebuilt, because the packages sometimes requires something bigger
> in the build time, which is not actually used in the run time (just my
> feeling, no prove available). I didn't receive any single notification
> of broken dependencies this time. While it's possible someone was just
> quicker than me, I believe it's highly unlikely. I also believe I
> didn't filter out any such "broken dependencies" mail notifications
> from my notification settings, they used to come in the past.

Broken dependency notifications are disabled because the scripts are broken: 
they still use yum, which does not support the boolean dependencies. It is 
sad that this was still not fixed after months. Instead of wasting their 
time on annoyances such as update batching and now Rawhide gating, the 
infrastructure team should instead spend it to fix the existing essential QA 
tools.

> That's also another disadvantage of the gating. I recall seeing broken
> dependencies messages for package I've no commit rights for for weeks.
> Either the maintainer (or co-maintainer) didn't receive those messages
> similar like me, or they just didn't care. How would I force them to
> rebuild/correct (I am definitely willing to help to correct the
> packages when an API change requires it) their packages, when they
> already ignore/filter out broken dependencies notifications? Should I
> hunt for a proven packager to move things forward, thus other packages
> can rely on the provided change? Proven packagers have their own work
> to do to, they cannot be disrupted from their work every other day by
> hundreds of packages to help with the packages their update broke.

+1. As a provenpackager, I have other things to do than rebuilding packages 
24/7 because everything blocks on the rebuild.

> By the way, why was the compose of rawhide broken for several days?

Because a broken dependency in ANY package included on ANY release-critical 
deliverable now fails the ENTIRE compose process. It is clear that this does 
not scale.

> Corresponding people/packagers not being available? It looks to me that
> you just want to move the issue to a slightly upper level, but then
> you'll have working rawhide compose, which will not use the
> recent/bleeding code. It is, from my point of view, the main credit of
> Rawhide, to be on the bleeding edge.
> 
> It would be very sad to turn Rawhide from 'package update' to 'people
> hunt' task.

And I have to +1 these last 2 paragraphs as well.

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

Re: Gating packages in Rawhide

[Kevin Kofler]

Martin Kolman wrote:
> That would be really nice! There are often cases where a fix or
> enhancement needs to land in at least two components at once (in our cases
> usually pykickstart & anaconda and/or blivet & anaconda) and the only
> "atomic" way of doing that is doing a chainbuild, which, frankly, sucks:
> 
> - cryptic CLI syntax, no Web UI
> - totally different process from branched releases
> - you need to have commit right to all involved packages
> - no automated tests run on the results whatosoever
> - no way to tell list inidividual scratchbuilds in the past (AFAIK)
> 
> So having the option to use Bodhi to group atomic package updates for
> Rawhide to a Bodho update would be really useful!
> 
> - consistent with branched Fedora process
> - no need to be commiter for all packages, just tell the other maintainers
> to
>   add their new build to the update
> - tests could be easily hooked to the update
> - Web UI
> - ability to see & link people to pending & past updates
> 
> I might be missing some of the technicalities but this really seems like
> a win-win solution while keeping the current process in place due to the
> updates being optional.

A chain build is much more effective than the Bodhi process though. See 
Milan Crha's reply.

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

Re: Improving the glibc32 situation

[Josh Boyer]

On Fri, Mar 9, 2018 at 8:07 AM, Florian Weimer  wrote:
> Some x86_64 packages need a 32-bit glibc during build time.  Koji does not
> provide it.
>
> Unfortunately, there is no way to permanently block glibc32 from entering
> composes.  We have repeatedly asked for it.  It simply does not happen.  If
> end users install glibc32, there system may be irrevocably broken as a
> result.
>
> A few of the current consumers are simply broken in the sense that they
> really should build for i686 and get the package thorough the compose
> process, instead of building a native x86_64 package.  Others may have a
> genuine need.
>
> I thought about removing glibc32 altogether, but this is probably difficult.
> I can look at adding a hack to Koji, but there's probably a reason why this
> hasn't been fixed in fifteen years (whether it's technical or not), so it's
> unlikely to be a good use of my time.
>
> So as a stop-gap measure, I'd like to add this:
>
> Conflicts: kernel

That's a metapackage now, which isn't actually required for installs.
Better to do it on kernel-core, however..

> to the glibc32 package, to make it very unlikely that end users can install
> it and completely break there Fedora installation.  Buildroots shouldn't
> have kernels, so it wouldn't affect them.
>
> Comments?  Suggestions?

Buildroots have kernels all the time.  Various packages like
libguestfs require it because they run virt tests during RPM build.
The 4.16-rc4 kernel-core was a component of gnome-software,
libtaskotron, plasma-discover, etc.  Now, whether or not those also
needed glibc32 in the buildroot is a different question.  I'm simply
pointing out it might not be a safe assumption to assume the
kernel/kernel-core packages are never installed in the buildroot.

Perhaps it would be better to put:

%ifarch x86_64
Conflicts:glibc32
%endif

in the kernel spec?

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

Improving the glibc32 situation

[Florian Weimer]

Some x86_64 packages need a 32-bit glibc during build time.  Koji does 
not provide it.


Unfortunately, there is no way to permanently block glibc32 from 
entering composes.  We have repeatedly asked for it.  It simply does not 
happen.  If end users install glibc32, there system may be irrevocably 
broken as a result.


A few of the current consumers are simply broken in the sense that they 
really should build for i686 and get the package thorough the compose 
process, instead of building a native x86_64 package.  Others may have a 
genuine need.


I thought about removing glibc32 altogether, but this is probably 
difficult.  I can look at adding a hack to Koji, but there's probably a 
reason why this hasn't been fixed in fifteen years (whether it's 
technical or not), so it's unlikely to be a good use of my time.


So as a stop-gap measure, I'd like to add this:

Conflicts: kernel

to the glibc32 package, to make it very unlikely that end users can 
install it and completely break there Fedora installation.  Buildroots 
shouldn't have kernels, so it wouldn't affect them.


Comments?  Suggestions?

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

Re: Gating packages in Rawhide

[Martin Kolman]

On Thu, 2018-03-08 at 11:24 -0800, Kevin Fenzi wrote:
> On 03/08/2018 11:11 AM, Richard Shaw wrote:
> > What about making side tags easily available to packagers directly? I could
> > build my package that includes an ABI breaking update and rebuild the
> > dependencies within that side tag and then submit when everything is
> > complete.
> 
> Yes, teaching bodhi about side tag management was one idea talked about.
> 
> Then you would do:
> 
> * get a side tag from bodhi
> * build all your stuff, test it, etc.
> * CI/automated tests run on it, and if all is ok goes out in the next
> rawhide compose.
> * If not ok, you could wave the results or build more things/edit the
> update until it passes.
That would be really nice! There are often cases where a fix or enhancement
needs to land in at least two components at once (in our cases usually
pykickstart & anaconda and/or blivet & anaconda) and the only "atomic" way
of doing that is doing a chainbuild, which, frankly, sucks:

- cryptic CLI syntax, no Web UI
- totally different process from branched releases
- you need to have commit right to all involved packages
- no automated tests run on the results whatosoever
- no way to tell list inidividual scratchbuilds in the past (AFAIK)

So having the option to use Bodhi to group atomic package updates for Rawhide
to a Bodho update would be really useful! 

- consistent with branched Fedora process
- no need to be commiter for all packages, just tell the other maintainers to
  add their new build to the update
- tests could be easily hooked to the update
- Web UI
- ability to see & link people to pending & past updates

I might be missing some of the technicalities but this really seems like
a win-win solution while keeping the current process in place due to the
updates being optional.

> 
> The only downsides to this is that it means more code for bodhi, and
> more newrepos for koji.
> 
> kevin
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Node.js: Would anyone be interested in a Node.js/JavaScript SIG?

[Stephen Gallagher]

On Fri, Mar 9, 2018 at 7:06 AM Tom Hughes  wrote:

> On 09/03/18 11:56, Elliott Pardee wrote:
> > The goal I have in mind for such a SIG would be to:
> >
> > * Maintain the Node.js packages (npm/nodejs)
> > * Promote Node.js usage in Fedora!
> > * Establish a community of JavaScript devs to share code, fixes, etc.
> >
> > I noticed that there wasn't a SIG already for this, so I hope that this
> > isn't inconvenient.
>
> There already is a nodejs SIG.
>
>

Yep, our information page is at https://fedoraproject.org/wiki/SIGs/Node.js and
you can subscribe to the mailing list (low volume) at
https://admin.fedoraproject.org/mailman/listinfo/nodejs
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Attempting to contact unresponsive maintainers - ggillies, vpodzime

[Vratislav Podzimek]

Hi,

I don't really know how I got to this list. I do have my new email
address in FAS and I haven't gotten any questions about the AADG recently.


Regards,

Vratislav


On 03/05/2018 09:10 PM, Kevin Fenzi wrote:
> Greetings, we've been told that the email addresses for these package
> maintainers are no longer valid. I'm starting the unresponsive
> maintainer policy to find out if they are still interested in
> maintaining their packages (and if so, have them update their email
> addresses in FAS).
>
> If they're not interested in maintaining or we can't locate them in 1
> week, I'll have FESCo orphan the packages so that others can take them
> over.
>
> If you have a way to contact these maintainers, please let them know
> that we'd appreciate knowing what to do with their packages. Thanks!
>
> ggillies:
>
> rpms/rubygem-amq-protocol
> rpms/rubygem-eventmachine
> rpms/rubygem-em-worker
> rpms/rubygem-sigdump
>
> vpodzime:
>
> Fedora Documentation/anaconda-addon-development-guide
>
> kevin
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

F29 Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer

[Jan Kurik]

= Proposed Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer =
https://fedoraproject.org/wiki/Changes/OpenLDAPdropMozNSSCompatibilityLayer


Owner(s):
  * Matus Honek 


Since Fedora 28, OpenLDAP is compiled with OpenSSL instead of NSS and
includes MozNSS Compatiblity Layer (i.e. TLSMC) to assure backwards
compatiblity. After this change the TLSMC will be removed.



== Detailed description ==
This change drops support for NSS-like configuration style for TLS in
OpenLDAP. Only PEM files will be supported. This is the expected
follow-up to the Changes/OpenLDAPwithOpenSSL [1].
The change will be accomplished by dropping a downstream patch that
brings the feature and removing all the related statements from the
SPEC file, including --enable-moznss-compatiblity=yes configure
option.

[1] https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL


== Scope ==
* Proposal owners:
Drop downstream patching as described in #Detailed Description

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
[https://pagure.io/releng/issue/7382 #7382]

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Node.js: Would anyone be interested in a Node.js/JavaScript SIG?

[Tom Hughes]

On 09/03/18 11:56, Elliott Pardee wrote:

The goal I have in mind for such a SIG would be to:

* Maintain the Node.js packages (npm/nodejs)
* Promote Node.js usage in Fedora!
* Establish a community of JavaScript devs to share code, fixes, etc.

I noticed that there wasn't a SIG already for this, so I hope that this
isn't inconvenient.


There already is a nodejs SIG.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Node.js: Would anyone be interested in a Node.js/JavaScript SIG?

[Elliott Pardee]

The goal I have in mind for such a SIG would be to:

* Maintain the Node.js packages (npm/nodejs)
* Promote Node.js usage in Fedora!
* Establish a community of JavaScript devs to share code, fixes, etc.

I noticed that there wasn't a SIG already for this, so I hope that this
isn't inconvenient.

I'm Elliott Pardee, I'm a computer science student with 10 years of
hobby programming experience. My main driver for the past 2 years has
been Node.js and I'm sure that I'm not the only one.

I'll make a Node.js SIG wiki page once I have a few people who are
interested.

--
Regards,
Elliott Pardee
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

test gate failures (again)

[Pavel Zhukov]

Hello,
Gating is failed for some weird reason:

# Test died: command 'dnf -y install bodhi-client git createrepo koji'
failed at /var/lib/openqa/share/tests/fedora/lib/utils.pm line 383.

https://bodhi.fedoraproject.org/updates/FEDORA-2018-fda9fed6fd

I suppose it's known issue. Is there any way to override such false
failures? It's not needed for this particular update but waiting 6
hours for next run is not optimal solution in case of security fixes
etc.

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

Re: Gating packages in Rawhide

[Vít Ondruch]

Dne 9.3.2018 v 11:24 Pierre-Yves Chibon napsal(a):
> On Fri, Mar 09, 2018 at 10:52:27AM +0100, Vít Ondruch wrote:
>>  I had a different idea in mind, basically try to keep the experience as 
>> close as
>>  what it is now.
>>  for single package:
>>- packager commit
>>- packager build
>>- build is tagged into a specfic koji tag
>>- test are run on this tag
>>  -> results go to src.fp.o
>>- if tests pass
>>  - package is moved to another koji tag
>>  - package is signed
>>  - package is pushed to rawhide
>>- if tests do not pass
>>  - do nothing
>>  - if the user submits a waiver
>>- move the package to the next koji tag for signing it
>>  If a packager does not want to run the tests, we could have a fedpkg build
>>  --noci that would directly build the package in the koji tag used for 
>> signing
>>  the package (useful for mass-rebuild for example)
>>
>>  for multi-package:
>>- packager requests a new side-tag (I'd propose via bodhi)
>>- packager build all the different packages in that side-tag
>>- packager asks for the side tag to be merged
>>- tests are run on all these packages
>>  -> results go to src.fp.o
>>  --> We probably want to also report them on the bodhi request to merge 
>> the
>>  tag as otherwise the packager will have to go through all the 
>> package to
>>  find the one(s) that failed
>>- if tests pass
>>  -> cf above
>>
>>I more or less like your proposal. But I have to highlight one danger of
>>sidetags and that is you have use the "--target" option. If you forget it
>>by accident (and it is quite easy to forget), you will unintentionally
>>mess the main Rawhide repository. From this POV is much safer to use build
> You wouldn't mess the main repo as  it would not have been built against the 
> new
> version of the library you updated and are trying to rebuild against.

It depends what you are building. If are building package foo with
soname bump and its dependencies, the if you build the foo by accident
into the official tag, then you are in troubles.

And for that dependencies, it depends. If you bum some dependency in the
middle of the chain, to be compatible with the new soname, but it
requires some other runtime dependencies, and you build it in the
official tag instread of the side tag, you are in trouble again.

>  So for
> that package there is no change compared to what was already in rawhide. And 
> for
> the side-tag when trying to merge it changes are that the tests would fail no?
>
>>overrides. Also, using buildroot overrides is probably more infrastructure
>>resources friendly. BTW the buildroot overrides could be submitted
>>automatically by "fedpkg build", with possible opt-in/out (depends what
>>will qualify to be better default).
> Buildroot override means we gate the packages for an unknown time. The 
> buildroot
> override means: adding to the buildroot something that isn't already there. So
> how would we know when to wait (depending libraries need a rebuild) and when 
> not
> to wait (single-package update)?
> If we always push, we end up with the current rawhide situation no?

The buildroot override can be sumbitted or expired. You can't do that in
Rawhide now. So there are two possibilities:

1) We automatically submit override, but it could be expired based on
testing.
2) If more packages are needed to build, the override can be submitted
manually.

> If we default to wait, we end up with what we have currently in stable 
> releases
> and are changing quite our packaging workflow.
> I'm not saying it's not an option, just that it needs to be made clear to
> everyone.


>
>>Also, using side-tags without appropriate branches is wasted opportunity.
>>If I could have "master-mysidetag" branch, I would use to build my
>>packages and side-tag merge would mean to merge dist-git as well as the
>>repository, it would be even more meaningful.
> This seems a lot of work without necessary a lot of gain tbh.

It was just me dreaming :) I realize it is a lot of work so this would
be just NTH.


V.


>
>
> Pierre
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.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

Re: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Fri, Mar 09, 2018 at 10:52:27AM +0100, Vít Ondruch wrote:
>  I had a different idea in mind, basically try to keep the experience as 
> close as
>  what it is now.
>  for single package:
>- packager commit
>- packager build
>- build is tagged into a specfic koji tag
>- test are run on this tag
>  -> results go to src.fp.o
>- if tests pass
>  - package is moved to another koji tag
>  - package is signed
>  - package is pushed to rawhide
>- if tests do not pass
>  - do nothing
>  - if the user submits a waiver
>- move the package to the next koji tag for signing it
>  If a packager does not want to run the tests, we could have a fedpkg build
>  --noci that would directly build the package in the koji tag used for signing
>  the package (useful for mass-rebuild for example)
> 
>  for multi-package:
>- packager requests a new side-tag (I'd propose via bodhi)
>- packager build all the different packages in that side-tag
>- packager asks for the side tag to be merged
>- tests are run on all these packages
>  -> results go to src.fp.o
>  --> We probably want to also report them on the bodhi request to merge 
> the
>  tag as otherwise the packager will have to go through all the 
> package to
>  find the one(s) that failed
>- if tests pass
>  -> cf above
> 
>I more or less like your proposal. But I have to highlight one danger of
>sidetags and that is you have use the "--target" option. If you forget it
>by accident (and it is quite easy to forget), you will unintentionally
>mess the main Rawhide repository. From this POV is much safer to use build

You wouldn't mess the main repo as  it would not have been built against the new
version of the library you updated and are trying to rebuild against. So for
that package there is no change compared to what was already in rawhide. And for
the side-tag when trying to merge it changes are that the tests would fail no?

>overrides. Also, using buildroot overrides is probably more infrastructure
>resources friendly. BTW the buildroot overrides could be submitted
>automatically by "fedpkg build", with possible opt-in/out (depends what
>will qualify to be better default).

Buildroot override means we gate the packages for an unknown time. The buildroot
override means: adding to the buildroot something that isn't already there. So
how would we know when to wait (depending libraries need a rebuild) and when not
to wait (single-package update)?
If we always push, we end up with the current rawhide situation no?
If we default to wait, we end up with what we have currently in stable releases
and are changing quite our packaging workflow.
I'm not saying it's not an option, just that it needs to be made clear to
everyone.

>Also, using side-tags without appropriate branches is wasted opportunity.
>If I could have "master-mysidetag" branch, I would use to build my
>packages and side-tag merge would mean to merge dist-git as well as the
>repository, it would be even more meaningful.

This seems a lot of work without necessary a lot of gain tbh.


Pierre


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Vít Ondruch]

Dne 8.3.2018 v 10:13 Vít Ondruch napsal(a):
>
>
> Dne 8.3.2018 v 09:19 Igor Gnatenko napsal(a):
>> On Wed, 2018-03-07 at 16:39 +0100, Vít Ondruch wrote:
>>
>> > Dne 7.3.2018 v 15:08 Jerry James napsal(a):
>> >> On Wed, Mar 7, 2018 at 12:43 AM, Igor Gnatenko
>> >>  wrote:
>> >>> This is the second iteration of my mass-scratch-rebuild without
>> >>> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
>> >>> original mail still applies.
>> >>
>> >> The abe and flocq packages should be considered false
>> >> positives.  The
>> >> configure script in abe checks for a C++ compiler, but the makefile
>> >> only uses a C compiler.
>>
>> > I think the same happens to Ruby. It checks for C++ while C++ is not
>> > needed. I might try to query upstream about it.
>>
>> Yes, please.
> >
>
> https://bugs.ruby-lang.org/issues/14590

The answer is:

~~~
Some extension libraries, e.g., ones using swig, need a C++ compiler.
~~~

This is depressing, because it is essentially the same issue as:

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


Vít



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Workaround for Re: Broken system upgrade due to rich dependencies

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have built RPM with backported with/without/unless rich deps for F26.

https://copr.fedorainfracloud.org/coprs/ignatenkobrain/rpm-4.13.x-richd
eps/

Just update from this repo before doing distro-sync/system-upgrade and
you should be good.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqiXIMACgkQaVcUvRu8
X0ysVhAAgFIYwX2GUMxT2PGWjhEXuVyvuunLl5maKoHqDCsRGQcfm2SH1iiiWLKi
4Q9d1A3/GWZycxKez4P1sZ7Cqj8hvs9eUmJVzyxqH1ubRMk9Ws/RKDe2cwzUkm68
z9/5yIEIqHPqLc9mU+0xZ4mM6FbsLNS1Ps1V5TOn7OVpYnoxS56OeNbakjGBtuBB
Y00tkKyjancnJYwzAVzqSh5unRGpJ7+VxX5qNS630zN6YZMKDHA1lLJCUq50/f7C
T+CBDY19gKoUiNnPGHhDT/DJwDBhjw0nRUmQqu7wKLoLx2iwq5w9bMSZBTL4EnIJ
3RuVBwVMg0U5r9u18pO4vRp83tnK8ErIZQlPUAIng7ZeYObFnyhJQALRylTln65u
YbNh/Aee729SX+o75M22d4FN/tQYM2/Ef/sf/T2pFg2cNuV7miHS5iG721fbarFb
ZSgJf2cM717awF7TOq76XKwoepyQop5J95NO/AqGo3l0ta3Z6mM/MXYFbhujjuBY
biukhAprEoMG2zqU+lTw9kktZXsIdMosuLPyUVDMesdrc8AJZjoNUpdJFsWWhaMS
xbao+vqHqiZLCBedP9fbsrQcx2AiGAbnkucquONDlPHgXiXBkVUnO3LjleK4l3gf
+1lL+xq0oLZzNjprujHzkWglq0BASUiN3PdgdaC19Jaeky+iSGM=
=y67K
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Vít Ondruch]

Thanks for starting this discussion and I really want to thank you for
offering Bodhi to handle the Rawhide. It would be really sad I some
other system was used for Rawhide then for stable versions.


Dne 9.3.2018 v 10:20 Pierre-Yves Chibon napsal(a):
> On Thu, Mar 08, 2018 at 01:00:32PM -0500, Randy Barlow wrote:
>> I would like to kick off a general discussion about how we might gate
>> packages in Rawhide. I think it would be nice to get something in place
>> for the Fedora 29 timeframe.
> I was waiting to have some more time to work on it to kick off that 
> discussion.
> This is cool as it means there are more people interested in having this :)
>
>> As one of the Bodhi contributors, I am inclined to suggest that we could
>> use Bodhi on Rawhide, similar to how we use it for our stable/branched
>> releases, with more relaxed rules (perhaps 1 day in testing or something
>> simple).
>>
>> It may be possible to automate the process a bit to make it less heavy
>> for developers, though there is some complication for multi-package
>> updates (more on that in a bit). For simple package updates, we may be
>> able to detect new commits on dist-git, and react to those by
>> automatically starting a Koji build, and automatically filing a Bodhi
>> update when that build is complete. I think that would be pretty nice,
>> and pingou created a PoC[0] to do this about a year ago.
>>
>> Multi-package updates won't be so easy though. It's not uncommon for us
>> to need to update packages together, and the above workflow would be
>> problematic since it would result in updates with single packages in
>> them rather than updates with multiple packages. Of course, buildroot
>> overrides would be a problem too, since multi-package updates often
>> depend on each other at build time too.
>>
>> We could create some way for packagers to indicate that a commit (or
>> possibly even a whole repo) is not intended to be "autobuilt/updated".
>> If the packager indicates this then their builds would go into a
>> rawhide-pending (similar to what we do for f27 today). Once they have
>> all their builds (and buildroot overrides) the way they want them, they
>> can create the update.
>>
>> Another idea that was tossed around in some chats I had with people
>> about this involved a system for packagers to use to create Koji side
>> tags. Bodhi manages BuildRoot Overrides today (with expirations), so
>> perhaps Bodhi could be expanded to also manage Koji side tags (also with
>> expirations). I can't remember all the details about this approach or
>> why it was suggested over the former approach, but I wanted to list it
>> to invite others to chew on it and see if it could work.
>>
>> If you have other suggestions on how we might gate packages in Rawhide
>> that are wildly different than the above, please feel free to share!
> I had a different idea in mind, basically try to keep the experience as close 
> as
> what it is now.
> for single package:
>   - packager commit
>   - packager build
>   - build is tagged into a specfic koji tag
>   - test are run on this tag
> -> results go to src.fp.o
>   - if tests pass
> - package is moved to another koji tag
> - package is signed
> - package is pushed to rawhide
>   - if tests do not pass
> - do nothing
> - if the user submits a waiver
>   - move the package to the next koji tag for signing it
> If a packager does not want to run the tests, we could have a fedpkg build
> --noci that would directly build the package in the koji tag used for signing
> the package (useful for mass-rebuild for example)
>
> for multi-package:
>   - packager requests a new side-tag (I'd propose via bodhi)
>   - packager build all the different packages in that side-tag
>   - packager asks for the side tag to be merged
>   - tests are run on all these packages
> -> results go to src.fp.o
> --> We probably want to also report them on the bodhi request to merge the
> tag as otherwise the packager will have to go through all the package 
> to
> find the one(s) that failed
>   - if tests pass
> -> cf above

I more or less like your proposal. But I have to highlight one danger of
sidetags and that is you have use the "--target" option. If you forget
it by accident (and it is quite easy to forget), you will
unintentionally mess the main Rawhide repository. From this POV is much
safer to use build overrides. Also, using buildroot overrides is
probably more infrastructure resources friendly. BTW the buildroot
overrides could be submitted automatically by "fedpkg build", with
possible opt-in/out (depends what will qualify to be better default).

Also, using side-tags without appropriate branches is wasted
opportunity. If I could have "master-mysidetag" branch, I would use to
build my packages and side-tag merge would mean to merge dist-git as
well as the repository, it would be even more meaningful.
> For this to work we could need:
> - one new koji tag on rawhide (easy)

Re: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Fri, Mar 09, 2018 at 10:12:37AM +0100, Mathieu Bridon wrote:
> We could take a hint from how we make software upstream these days:
> 
> 1. submit a pull request for the package in src.fp.o on the master
>branch
> 2. a CI automatically builds this package in Koji
> 3. merge the pull request into master
> 4. the build (from step 2) is tagged for Rawhide, without a rebuild
> 
> Gating is achieved by preventing merges if the build/tests fail.

This has been discussed but requires a way for koji to "promote" scratch builds
to real builds and this isn't a small task.
Long term, I do think this is a good idea anyway yes.


Pierre


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Thu, Mar 08, 2018 at 01:00:32PM -0500, Randy Barlow wrote:
> I would like to kick off a general discussion about how we might gate
> packages in Rawhide. I think it would be nice to get something in place
> for the Fedora 29 timeframe.

I was waiting to have some more time to work on it to kick off that discussion.
This is cool as it means there are more people interested in having this :)

> As one of the Bodhi contributors, I am inclined to suggest that we could
> use Bodhi on Rawhide, similar to how we use it for our stable/branched
> releases, with more relaxed rules (perhaps 1 day in testing or something
> simple).
> 
> It may be possible to automate the process a bit to make it less heavy
> for developers, though there is some complication for multi-package
> updates (more on that in a bit). For simple package updates, we may be
> able to detect new commits on dist-git, and react to those by
> automatically starting a Koji build, and automatically filing a Bodhi
> update when that build is complete. I think that would be pretty nice,
> and pingou created a PoC[0] to do this about a year ago.
> 
> Multi-package updates won't be so easy though. It's not uncommon for us
> to need to update packages together, and the above workflow would be
> problematic since it would result in updates with single packages in
> them rather than updates with multiple packages. Of course, buildroot
> overrides would be a problem too, since multi-package updates often
> depend on each other at build time too.
> 
> We could create some way for packagers to indicate that a commit (or
> possibly even a whole repo) is not intended to be "autobuilt/updated".
> If the packager indicates this then their builds would go into a
> rawhide-pending (similar to what we do for f27 today). Once they have
> all their builds (and buildroot overrides) the way they want them, they
> can create the update.
> 
> Another idea that was tossed around in some chats I had with people
> about this involved a system for packagers to use to create Koji side
> tags. Bodhi manages BuildRoot Overrides today (with expirations), so
> perhaps Bodhi could be expanded to also manage Koji side tags (also with
> expirations). I can't remember all the details about this approach or
> why it was suggested over the former approach, but I wanted to list it
> to invite others to chew on it and see if it could work.
> 
> If you have other suggestions on how we might gate packages in Rawhide
> that are wildly different than the above, please feel free to share!

I had a different idea in mind, basically try to keep the experience as close as
what it is now.
for single package:
  - packager commit
  - packager build
  - build is tagged into a specfic koji tag
  - test are run on this tag
-> results go to src.fp.o
  - if tests pass
- package is moved to another koji tag
- package is signed
- package is pushed to rawhide
  - if tests do not pass
- do nothing
- if the user submits a waiver
  - move the package to the next koji tag for signing it
If a packager does not want to run the tests, we could have a fedpkg build
--noci that would directly build the package in the koji tag used for signing
the package (useful for mass-rebuild for example)

for multi-package:
  - packager requests a new side-tag (I'd propose via bodhi)
  - packager build all the different packages in that side-tag
  - packager asks for the side tag to be merged
  - tests are run on all these packages
-> results go to src.fp.o
--> We probably want to also report them on the bodhi request to merge the
tag as otherwise the packager will have to go through all the package to
find the one(s) that failed
  - if tests pass
-> cf above

For this to work we could need:
- one new koji tag on rawhide (easy)
- support for side-tags in bodhi
- likely improving the side-tags generation in koji
- a few services, likely fedmsg-based, to link the different services (tests
  results to src.fp.o/bodhi, migrate package to the next koji tag when test
  results is published, when a waiver is submitted push the package to the next
  koji tag...)

The idea to automatically build upon commit is neat and something we can look
into, but I think it can be approached separately from gating rawhide, one
doesn't require the other.
Speaking of both changes in one go might confuse things a little.


Pierre


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Mathieu Bridon]

On Fri, 2018-03-09 at 10:06 +0100, Pierre-Yves Chibon wrote:
> On Thu, Mar 08, 2018 at 08:26:30PM -0800, Kevin Fenzi wrote:
> > On 03/08/2018 07:53 PM, Kevin Kofler wrote:
> > > Randy Barlow wrote:
> > > > It may be possible to automate the process a bit to make it
> > > > less heavy
> > > > for developers, though there is some complication for multi-
> > > > package
> > > > updates
> > > 
> > > Some automation would help, sure. But if we are going to do
> > > things 
> > > automatically, why bother with Bodhi at all?
> > 
> > Well, we don't currently have another tool to show results and
> > allow
> > waving of them. We could come up with another app and have yet a
> > different place and workflow from regular releases, but why not
> > stick to
> > the same workflow and avoid making yet another app.
> > > 
> > > We are already building into a pending tag for the autosigning,
> > > from which 
> > > the packages are moved into the final tag when they are signed.
> > > The same 
> > > process should work for autotesting. Just add it before or after
> > > the 
> > > autosigning in the pipeline, possibly with another intermediate
> > > tag.
> > > 
> > > I think that Bodhi is really the wrong tool for the job here.
> > > What you are 
> > > trying to hit with your shiny hammer may look like a nail to you,
> > > but it is 
> > > really a screw. ;-)
> > 
> > I don't think thats the case here, it's more than we don't want to
> > build
> > another different tool for something that could work with the
> > hammer we
> > have.
> > 
> > To be fair, there was a suggestion that we show results in
> > pagure/src.fedoraproject.org, but to me, that definitely sounds
> > like the
> > wrong place for such things. We want tests tied to a specific
> > update,
> > not the entire package as a whole. (Even thought we could fudge
> > this by
> > having git tags or something to tie results to).
> 
> For regular Fedora releases I definitely agree with you, but for
> rawhide where
> the only time we bundle package together would be via side-tags, I
> think
> reporting test results to src.fp.o would be a valid approach.

We could take a hint from how we make software upstream these days:

1. submit a pull request for the package in src.fp.o on the master
   branch
2. a CI automatically builds this package in Koji
3. merge the pull request into master
4. the build (from step 2) is tagged for Rawhide, without a rebuild

Gating is achieved by preventing merges if the build/tests fail.


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

Re: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Thu, Mar 08, 2018 at 08:26:30PM -0800, Kevin Fenzi wrote:
> On 03/08/2018 07:53 PM, Kevin Kofler wrote:
> > Randy Barlow wrote:
> >> It may be possible to automate the process a bit to make it less heavy
> >> for developers, though there is some complication for multi-package
> >> updates
> > 
> > Some automation would help, sure. But if we are going to do things 
> > automatically, why bother with Bodhi at all?
> 
> Well, we don't currently have another tool to show results and allow
> waving of them. We could come up with another app and have yet a
> different place and workflow from regular releases, but why not stick to
> the same workflow and avoid making yet another app.
> > 
> > We are already building into a pending tag for the autosigning, from which 
> > the packages are moved into the final tag when they are signed. The same 
> > process should work for autotesting. Just add it before or after the 
> > autosigning in the pipeline, possibly with another intermediate tag.
> > 
> > I think that Bodhi is really the wrong tool for the job here. What you are 
> > trying to hit with your shiny hammer may look like a nail to you, but it is 
> > really a screw. ;-)
> 
> I don't think thats the case here, it's more than we don't want to build
> another different tool for something that could work with the hammer we
> have.
> 
> To be fair, there was a suggestion that we show results in
> pagure/src.fedoraproject.org, but to me, that definitely sounds like the
> wrong place for such things. We want tests tied to a specific update,
> not the entire package as a whole. (Even thought we could fudge this by
> having git tags or something to tie results to).

For regular Fedora releases I definitely agree with you, but for rawhide where
the only time we bundle package together would be via side-tags, I think
reporting test results to src.fp.o would be a valid approach.


Pierre


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: grubby - /boot on btrfs support

[Tomasz Kłoczko]

On 7 March 2018 at 04:12, Nathaniel McCallum  wrote:
>
> https://bodhi.fedoraproject.org/updates/grubby-8.40-10.fc28
>
> We've built grubby with support for /boot on btrfs. We're trying to
> land this in F28. But we need testers. That's where you come in! If
> you ever interact with grubby and especially if you have an exotic
> grub2 setup, please download and test this release. As usual provide
> feedback in Bodhi (link at the top of this email). Thanks!

Just tested new grubby on two systems. Here is my subvols layout from one
of those systems (my laptop):

# btrfs subvolume list -R /
ID 257 gen 1381846 top level 5 received_uuid -
   path root
ID 535 gen 1381846 top level 257 received_uuid -
 path var
ID 536 gen 1376990 top level 257 received_uuid -
 path home
ID 537 gen 1381838 top level 257 received_uuid -
 path boot
ID 746 gen 1381846 top level 535 received_uuid -
 path var/lib/mysql
ID 1287 gen 1364400 top level 535 received_uuid -
 path var/lib/machines
ID 1325 gen 1381846 top level 536 received_uuid -
 path home/tkloczko
ID 1326 gen 1381756 top level 1325 received_uuid -
   path home/tkloczko/git
ID 1327 gen 1381846 top level 1326 received_uuid -
   path home/tkloczko/git/fedora
ID 1328 gen 1381756 top level 1326 received_uuid -
   path home/tkloczko/git/linux-git
ID 1329 gen 1380131 top level 1325 received_uuid -
   path home/tkloczko/src-packages
ID 1331 gen 1381807 top level 1329 received_uuid -
   path home/tkloczko/src-packages/fedora
ID 1332 gen 1381082 top level 1329 received_uuid -
   path home/tkloczko/src-packages/suse
ID 1333 gen 1381554 top level 1329 received_uuid -
   path home/tkloczko/src-packages/altlinux
ID 1334 gen 1380955 top level 1329 received_uuid -
   path home/tkloczko/src-packages/centos
ID 1335 gen 1381188 top level 1329 received_uuid -
   path home/tkloczko/src-packages/mageia
ID 1336 gen 1381748 top level 1329 received_uuid -
   path home/tkloczko/src-packages/debian

Looks like it works.
On the second system, I have no separated /boot and grub2.cfg has been
updated correctly as well.
Good job 👍💪
Now it would be good to remove from anaconda blocking use btrfs on roofs as
well 😃

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Changes in wireshark package name

[Michal Ruprich]

On 03/06/2018 03:40 PM, Kevin Kofler wrote:
> Michal Ruprich wrote:
>> the plan to drop the GTK+ GUI [1] was approved by FESCO, so I will be
>> dropping the wireshark-gtk package in rawhide(currently F29). Also I
>> would like to propose that we change the name of wireshark-qt. There are
>> three packages now - wireshark-cli, wireshark-gtk and wireshark-qt.
>> Since the wireshark-gtk is going away I would like to suggest that we
>> change the wireshark-qt to something more generic like wireshark-gui. If
>> you feel like there is a reason why I should not do that, please just
>> respond to this email.
> Why not just "wireshark", if the CLI has its own name anyway?
>
> Kevin Kofler
Good point, wireshark-qt will just be wireshark. Thanks
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 
Michal Ruprich
Associate Software Engineer

Email: mrupr...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org