Re: dnf history - change in how rpmdb checksum is computed

[Dusty Mabe]

On 07/18/2018 09:24 AM, Daniel Mach wrote:
> Hi everyone,
> The DNF team is currently reviewing DNF compatibility with YUM 3 and we'd 
> like to get feedback on this one: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1120253
> 
> rpmdb checksum is a checksum of all installed RPMs
> It has no cryptographical value, it's just an unique ID of RPMs on a system 
> before and after each transaction and it's used in dnf history info and dnf 
> history list.
> If checksums of 2 following transactions do not match, DNF indicates that.
> This happens if a user installs an RPM by hand via rpm command.
> 
> Then `dnf history list` looks like:
>  2 | install bar | 2018-01-01 02:00 | Install    |    2  <
>  1 | install foo | 2018-01-01 01:00 | Install    |    7 >
> the "<" and ">" characters indicate discontinuity in rpmdb hashes
> 
> Here's the question:
> DNF computes the checksum from RPM N-E:V-R.A
> while YUM computed it from E:N-V-R.A

Could we just update dnf/"newyum" to calculate both checksums and
only represent the discontinuity if neither match? Obviously this
increases the chance of a collision, but could put this conversation
to rest.

At some distant point in the future we can stop calculating 'E:N-V-R.A'
since all new transactions would have been calculated based on 'N-E:V-R.A'

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2ZG45QT7AW54UKW2OVYTDHGF6OZ7VNXU/

Re: [atomic-devel] Starting a Container SIG

[Dusty Mabe]

On 07/25/2018 01:09 PM, Clement Verna wrote:
> 
> Please Reply if you're interested with helping out making the
> Container story great in Fedora. If there is a good response, I will
> create a Container SIG wiki page, and I guess we can ask for
> container-devel mailing list for SIG discussions.

Unfortunately I can't sign up to do a bunch of work but I would like to join
and help represent Fedora CoreOS and related interests in the SIG.

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QPTYH5DDCPYUCUCBZGGNOATXYHO5O2HG/

Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.

[Dusty Mabe]

On 06/29/2018 08:42 AM, Stephen Gallagher wrote:
> 
> 
> On Fri, Jun 29, 2018 at 8:32 AM Daniel Walsh  > wrote:
> 
> Users of OpenSHift Origin require CRI-O 1.10 right now.  But Kubernetes
> users want to try out the latest packages for kubernetes 1.11 which
> would require CRI-O 1.11.  Origin might not be ready to move to
> Kubernetes 1.11 for a while.
> 
> Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> releases in the same Fedora 28.
> 
> I believe this is what Modularity was designed to fix.
> 
> Can I do this with Modularity?  If I can how do I use fedpkg to make
> this happen?'
> 
> 
> 
> Yes you can, we can help you get set up in #fedora-modularity on Freenode if 
> you like.
> 
> The basics are documented at 
> https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/making-modules/adding-new-modules.html
> 

Did we decide to convert the CRI-O / kube stack to a module?

If it needs a self contained change request the deadline is today!

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5XGFYXFUL6JEP75YHCAKQO6T2WJYAOWM/

make yum repo when we build things in koji

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I often build an rpm in koji to make sure it builds but in order to
consume that rpm using our tools most of the time it needs to be in
a yum repo somewhere. I could create a repo locally and serve it locally
or even push it to somehwere to fedorapeople. The problem is, I'm lazy.
I'll often just take the srpm from koji and import it into copr and then
consume that repo once the build has finished over there (thanks copr)

The problem with this is that it's kind of a waste of resources. It would
be much more convenient if koji just output a repo I could consume (similar
to how copr does) even if the repo is only for a single rpm. 

Is this a feature request that exists? Has this been discussed before and 
rejected?

Dusty
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlpiuNUACgkQMwLb1zlS
5nE4kRAA7bxZAu63kU/x5rNer1ZJlOpAMGdSJXUr9CX/Lz9pLm3YM5JQdeX/rz+W
T/kvpQlpGrBqU/zxl1L+yMMg2zXxXlm+O/bbUudz6KD8pH80mILKVwKpLdM0/xH5
cNMWXZS3QzonsM3jsXBc8F8cDTnbJmS7xSR2WXCcxykZvdeLKRUDxE9LC8+FH5fA
OWfZw0pwUBnF6+v0DGRvrtNDeQ9yUhYR0/ZlZ/8bJV+lPREErSw2Nx1wHg+9GvA6
Lv2RzH7kI4Th1R6GVc5yy2Veors1hQDCUHQspigVbFP0DVos8onwJn8ZR5wk+TO4
WrduH1mloZPLoBh73v8TPU4UVjbIjP2CD9VGUFiWkopT9bggJ/+FkwlhBXgIeMCb
qFz53qySxT2XE+lDgU7tVoBuMohqielsCa/0moviNvx68uOQhVNvPP42EHJujxN2
NvDAmLl/6q/PyXu03baqyQeV00gtrqUnv/6dwXFput4+0YtEXF+LHabtiJXtRqkQ
OUWsout98l8LVUVQF5mwddZHpE+NoLOgcOpXhyFqflKAN/c7hh7qZPr4dDFc216J
3DSzNgysdlBO/uUThKzhRA2Uwm/M7458YOwt475rcvxtZocKaPFAgigkmMbeadCJ
lkGzR1ZymDtg232m3UdTanjjtpFjP+ADTVOlsRRcBFrdbJnminE=
=Dazs
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: make yum repo when we build things in koji

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 01/19/2018 10:39 PM, Reindl Harald wrote:
> 
> 
> [harry@srv-rhsoft:~]$ cat /etc/yum.repos.d/koji.repo
> [koji]
> name=Koji Repo
> baseurl=https://koji.fedoraproject.org/repos/f$releasever-build/latest/$basearch/
> enabled=0
> skip_if_unavailable=1
> gpgcheck=0
> sslverify=0

Thanks!
I didn't know about this, but it's not exactly what I'm looking for because 
that seems
to includ everything that has been built. I'm looking more specifically for 
just a repo
with a particular rpm in it. So for example. I currently want to test the new 
grub2 update
for f27, but I only want to test that update and I want to compose a new ostree 
with it. If
I use the repo you provided then I get all new latest built packages included.

Another reason to have the feature I request is so that scratch builds can be 
easily tested.

Dusty 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlpivTcACgkQMwLb1zlS
5nHc3Q//aVb2kDaSHl44k3mM5Aei7UX3N+v1JmIezGXUQiknNR02+dm+UiL/cFeu
Tzkd7g54owI4lf5Ao3XW18Et+HmO1c6woHHIRUpCY4cE382eeMyIeHCvCpfrtx0S
NfAqMS/wILRWLw/DQB1pjENcbq8Ryqgx8KFo9a2lSh8kgH5FZwMegKjt4YMhXeBB
PH5P+HxkGP7CNNY/M/5Uk5TzgHhh8wO2iHwwluLd5fyJHtwcKtynwHtAfyQSapck
cKN8P2gDUIos6ZNFNpYCG/7cQu2exCMFORn9Ao91oJSOHAd33iF0sRvT+iR92g4S
cc7o+QZtHR9kTWezAGzzIL9Y/hDDWYg6Qft+5ACwrIYiDyad2pm8qggKuMoSloLT
XB0azuuc7+w3s0xv3tdIxgAv06c6PZJFNBucQY5G3IjPKYW79wS88Kc4wmMmwmVr
UXJtsgmPbFDjBGSXooGo8vQDjwdL9+yO0unz9pSR+9pCI+Xr9KaS/JvlshrV+Vf2
Ct+XoUxa/GS5dOCFapP4eBUWHLgUE84mrPjat4srdDeznVhJHanSf6P/UvifBgC9
n/rF8+P3hfxuFq0Sk7eQj0SwtmzOnfICOe9LjpWpbT2p/Y0qwvJNoynFuJKlCBpl
IKQHfvadpala/EZ4bG38xlMR8ElVkUxAq/ENTK9Vb4NGhhRwW7c=
=sTzE
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 02/28/2018 01:38 PM, Daniel P. Berrangé wrote:
> On Wed, Feb 28, 2018 at 01:12:03PM -0500, Matthew Miller wrote:
>> On Wed, Feb 28, 2018 at 05:57:53PM +, Daniel P. Berrangé wrote:
>>> mistake that caused files to go missing, and was never detected by the 
>>> person
>>> making the change, because of the use of globs. So I agree it is good 
>>> practice
>>> to explicitly list files without globs whereever it is practical todo so. 
>>> I'd
>>> make an exception for files which don't have functional impact eg don't list
>>> 1000 HTML files individually, but it is always worth listing everything in
>>> /usr/bin, and /usr/lib(64) explicitly without globs.
>>
>> I used to agree with this, but I've come around to thinking that spec
>> files should be smaller, less complicated, and more automatable. I
>> think we'd be better having a post-build test warning that this package
>> has files missing from the previous build. That could be advisory, or
>> it could even gate, with the packager clearing the gate by updating the
>> file list in the test, rather than in the spec file.
> 
> The further down the workflow a problem is detected the more time expensive
> / disruptive it is to fix it. So while having post-build tests to validate
> lots of things is great (and I wish we had more of it in Fedora), I see it
> as complementary to anything that we can do to detect problems earlier. I
> rather see failures right away when I test the new RPM build locally, than
> waiting to push it through koji and wait again for post-build tests to find
> the problem, as by that time I've context switched my mind away to a
> different bit of work.

Agree with this. We need to have something that is automated and also happens as
soon as possible. Gating rawhide should give us the ability to do something 
like this
and enforce it (i.e. making sure rebuilt dependent packages get pushed along 
with
the package that introduced the soname bump). I know this isn't clearly black 
and
white (i.e. oftentimes it's more than just a rebuild, and requires code 
changes) but
should give us a good start.

Dusty 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqXTJsACgkQMwLb1zlS
5nFCUBAAuh+tHA9yIm6W8Ge4KMLahDzypb64/pXFZ4FkOcQf0TO6KpAhzXtvI+jj
/zLdZqOsfttjtSCYdOTSrjaTg9HX7g1v8r3KnpmqX1OKMDF83kZc+RiUHULnuCPR
OUv8yQ3fFc+yTlSeW3UScJ+xbnZnB/pZp9TFilDC7Ny33qs7pnzzp71QgguIUtp2
XlQm07aY7iZz0JqajQRnXWAhRJGYVPA9MR29SXU9a7LJ0HMrBpgRCQruiCaWozpz
LclhVV9sMGVeKs5yuxroI1t2DSBkjrl6umlvklMEtx22SpKFo8xWNoAScEWR8zXY
W1F2dY5Kxdv6Y4N1ACj3g/m+xziTqsy/acnDkqoK7Afpj51J0poZnIuwKk/SReft
a3nPJSSMrowxMn9+ZZVpuonvK0L3D+ACmJkPSI6arCmPWaXJqcBn2IcRUOV5Ok49
VL6Kl6AP7UdDQkW06T5Ub1wjjK4yjRiWVoNxrqp0y24wFzMi/NVUwelZlKbs6jjR
AbPE9ucNnYWrqqAQMHXjPC7Q+I64sfdkUmVadLqp3mAz0VToeRsJEdhq6ZMyk65h
eYz4prhfAL7mbxmAhQNdOnihALcftOE9MOxOGL3MF3Il5WQAGkqqXwbVUW9Ryg40
NqoVzQtQjGif2O3oRFFKlR5vLpvntzOkISB+gQV/lIs1bhYKW8I=
=1cnG
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Atomic Working Group VFAD 03/09

[Dusty Mabe]

Hi everyone,

This is a reminder that tomorrow we have a VFAD (Virtual Fedora Activity Day) 
for everyone who 
can and wants to join in on the discussions: 
https://pagure.io/atomic-wg/issue/429

--
Location:

https://bluejeans.com/dmabe

--
Topics:

[upstream technology]

  * rpm-ostree rojig - short presentation/demo [5 minutes]
  * rpm-ostree rojig - Q [ max 10 minutes ]
  * podman - pros/cons to including it in the host vs using as a container [ 10 
minutes ]

[community]

  * discussion on whether Project Atomic needs to step away from the "umbrella" 
and make it clear what it's about, spin off projects [ 40 minutes ]

[Atomic Workstation]

  * suggestion for rebranding atomic workstation [ 20 minutes ]
  * dev/pet container tools - gather links to examples/docs [ 10 minutes ]
  * Minimizing content set in FAW [ 10 minutes ]
  o https://pagure.io/workstation-ostree-config/pull-request/74

[Q for users]

  * Q session for atomic host/workstation users [ 20 minutes ]

--

See you there,
Atomic WG
___
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: Fedora Rawhide-20180308.n.2 compose check report

[Dusty Mabe]

On 03/09/2018 09:49 PM, Adam Williamson wrote:
> 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.
> 

We made #1 #2 and #3 happen!

https://pagure.io/pungi-fedora/pull-request/577
https://pagure.io/pungi-fedora/pull-request/578
https://pagure.io/pungi-fedora/pull-request/579
___
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]

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

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

Re: Fedora-Atomic 27-20180407.0 compose check report

[Dusty Mabe]

On 04/07/2018 03:54 AM, Fedora compose checker wrote:
> No missing expected images.
> 
> Passed openQA tests: 2/2 (x86_64)
> 

Can we get these emails to go to ato...@lists.fedoraproject.org?

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

Re: Fedora Atomic Host Two Week Release Announcement: 27.122

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 04/19/2018 05:55 PM, nore...@fedoraproject.org wrote:
> 
> A new Fedora Atomic Host update is available via an OSTree update:
> 
> Version: 27.122
> Commit(x86_64): 
> 931ebb3941fc49af706ac5a90ad3b5a493be4ae35e85721dabbfd966b1ecbf99
> Commit(aarch64): 
> 837cd0c5e3a5656316ebf6142315ac107c8592d5c8d64a02e8a62919eee9f46f
> Commit(ppc64le): 
> a1f565d73f1f1b6f6d7ef992251f21a704c4a8de40c41fc62be69c5ec2a65329
> 
> 
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
> 
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
> 
> Corresponding image media for new installations can be downloaded from:
> 
> https://getfedora.org/en/atomic/download/
> 
> Alternatively, image artifacts can be found at the following links:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/Atomic/aarch64/iso/Fedora-Atomic-ostree-aarch64-27-20180419.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/Atomic/ppc64le/iso/Fedora-Atomic-ostree-ppc64le-27-20180419.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/Atomic/x86_64/iso/Fedora-Atomic-ostree-x86_64-27-20180419.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/aarch64/images/Fedora-Atomic-27-20180419.0.aarch64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/aarch64/images/Fedora-Atomic-27-20180419.0.aarch64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/ppc64le/images/Fedora-Atomic-27-20180419.0.ppc64le.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/ppc64le/images/Fedora-Atomic-27-20180419.0.ppc64le.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180419.0.x86_64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180419.0.x86_64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/x86_64/images/Fedora-Atomic-Vagrant-27-20180419.0.x86_64.vagrant-libvirt.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/x86_64/images/Fedora-Atomic-Vagrant-27-20180419.0.x86_64.vagrant-virtualbox.box
> 
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/Atomic/aarch64/iso/Fedora-Atomic-27-20180419.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/Atomic/ppc64le/iso/Fedora-Atomic-27-20180419.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/Atomic/x86_64/iso/Fedora-Atomic-27-20180419.0-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/aarch64/images/Fedora-CloudImages-27-20180419.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/ppc64le/images/Fedora-CloudImages-27-20180419.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/x86_64/images/Fedora-CloudImages-27-20180419.0-x86_64-CHECKSUM
> 
> For direct download, the "latest" targets are always available here:
> https://getfedora.org/atomic_iso_latest
> https://getfedora.org/atomic_qcow2_latest
> https://getfedora.org/atomic_raw_latest
> https://getfedora.org/atomic_vagrant_libvirt_latest
> https://getfedora.org/atomic_vagrant_virtualbox_latest
> 
> Filename fetching URLs are available here:
> https://getfedora.org/atomic_iso_latest_filename
> https://getfedora.org/atomic_qcow2_latest_filename
> https://getfedora.org/atomic_raw_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_latest_filename
> 
> For more information about the latest targets, please reference the Fedora
> Atomic Wiki space.
> 
> 
> https://fedoraproject.org/wiki/Atomic_WG#Fedora_Atomic_Image_Download_Links
> 
> Do note that it can take some of the mirrors up to 12 hours to "check-in" at
> their own discretion.
> 
> Thank you,
> Fedora Release Engineering
>

Hi everyone!

We apologize for the delay in getting this release out the door. As a
bonus for the wait we have AMIs that are available in additional regions
(ap-northeast-2, ap-south-1). We'll be adding additional regions (the
remaining missing regions) next release.

Additionally, this will most likely be our last release of Fedora 27 Atomic
Host. Very soon Fedora 28 will be released and we will 

Re: runroot changing during the course of a rawhide pungi run

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 02/26/2018 07:51 PM, Kevin Fenzi wrote:
> On 02/22/2018 07:34 PM, Dusty Mabe wrote:
>>
>> If I understand correctly there was a new lorax build [1] that completed
>> at 01:11 UTC (02/23) that then made it into the runroot of a task [2] that
>> was part of a pungi compose [3] that started at 14:54 UTC (02/22).
> 
> runroot is confusing here as we have a koji plugin called runroot that
> runs tasks in a chroot. I think you mean buildroot here?

Yeah the buildroot (since that is where the runroot installs packages from).
 
> 
>> I think this caused problems with the build, but that isn't really
>> important. The real question is: if our runroot changes during the run then
>> we could have some tasks (lorax imagebuild etc) that run with some versions
>> of software and other tasks that run with others. This is probably especially
>> maddening when trying to debug why one failed when others didn't.
>>
>> Is my understanding correct?
> 
> Yes, the rawhide buildroot is updated as soon as builds complete and are
> signed (plus a small time for the newrepo to run).

this is kind of unfortunate because a developer could torpedo a pungi run 8
hours in.

> 
> This is not the case with any of the bodhi enabled releases. They only
> update the buildroot from base packages + stable updates + specific
> packages that are added as buildroot overrides.

Yeah there is more control over bodhi, which is good. What about branched 
composes?

Dusty 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqUrX8ACgkQMwLb1zlS
5nGmXRAA332NcrKhpJkAEkst2XHTAknWtrvEgLl0SRTsD6vB7b6ndxmX4Uq1w4eu
44wSPzsI2KEkslEEktxdlS5tTtGOs2ogNzDZD0JWp013uWOvxYsYF84/qq/Cv7cT
re67+HA0sdHKvZ4+BRwOcEtzzqqPbZmWbOssT3Zn4eOtxuZD1W19zsXwCdMl9tc6
vz1G5SO5Refj0jE19R9sHccRUv3+6QFagwiWW/tCE1kgo/qmbbIcgSwKzRIAkWhX
rTgjNABJ6Q40wWrPyU0HgT5kzl6+htPgo7r4JlGyk7Kqo9OkaeN2jdCyn3tsQRJX
TDr+kY2yh/IPtUegp0ULQuU/+QhxMG98GmmqiFIufniJPe3uySJYSlXSnuwe/P0L
5zfx89GL5YE2lfPM7mtnqnYJtpzYD6UyHKNUNRE1HKbZvdlM3vB/QfvQLQWcKXkB
KFkLM53p3JqEvAJy4QnKsK4/w3zP9h9oDZ/r3DMyT8ECejwY6jP7pNwuAh6ADObT
6ZmRi091cbynveEmJX2aEsEVb6cWqbSbxwiba7JMwMHOW9ERtBAeLzH5dtze7Eie
4y8HYHC3GGsbPDc5M2uKZ7T6XcZdxKtxQ8VmOtBA1Gjvc3uxCeg/4ywae/ldkaO0
lZjMFyhvsx3qZKuqpQqwrxdGFd30nUVMo1bHUMfUx1QGDitvo+0=
=5UWC
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement: 27.93

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 02/27/2018 10:47 AM, nore...@fedoraproject.org wrote:
> 
> A new Fedora Atomic Host update is available via an OSTree update:
> 
> Version: 27.93
> Commit(x86_64): 
> da0bd968610aa1e29c5bb37065649407fbbfffa53e63831afdadbd34a3b05327
> Commit(aarch64): 
> 6607b02ff08bd0f0fc488772b398c25de28345a0bda0508ef45b433b91839ccd
> Commit(ppc64le): 
> 848b618bd36e8b03bbcedf2d9ff881450440d8434f62cdb80006d3e899ebaa28
> 
> 
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
> 
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
> 
> Corresponding image media for new installations can be downloaded from:
> 
> https://getfedora.org/en/atomic/download/
> 
> Alternatively, image artifacts can be found at the following links:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/Atomic/aarch64/iso/Fedora-Atomic-ostree-aarch64-27-20180226.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/Atomic/ppc64le/iso/Fedora-Atomic-ostree-ppc64le-27-20180226.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/Atomic/x86_64/iso/Fedora-Atomic-ostree-x86_64-27-20180226.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/aarch64/images/Fedora-Atomic-27-20180226.0.aarch64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/aarch64/images/Fedora-Atomic-27-20180226.0.aarch64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/ppc64le/images/Fedora-Atomic-27-20180226.0.ppc64le.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/ppc64le/images/Fedora-Atomic-27-20180226.0.ppc64le.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180226.0.x86_64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180226.0.x86_64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/x86_64/images/Fedora-Atomic-Vagrant-27-20180226.0.x86_64.vagrant-libvirt.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/x86_64/images/Fedora-Atomic-Vagrant-27-20180226.0.x86_64.vagrant-virtualbox.box
> 
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/Atomic/aarch64/iso/Fedora-Atomic-27-20180226.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/Atomic/ppc64le/iso/Fedora-Atomic-27-20180226.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/Atomic/x86_64/iso/Fedora-Atomic-27-20180226.0-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/aarch64/images/Fedora-CloudImages-27-20180226.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/ppc64le/images/Fedora-CloudImages-27-20180226.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180226.0/CloudImages/x86_64/images/Fedora-CloudImages-27-20180226.0-x86_64-CHECKSUM
> 
> For direct download, the "latest" targets are always available here:
> https://getfedora.org/atomic_iso_latest
> https://getfedora.org/atomic_qcow2_latest
> https://getfedora.org/atomic_raw_latest
> https://getfedora.org/atomic_vagrant_libvirt_latest
> https://getfedora.org/atomic_vagrant_virtualbox_latest
> 
> Filename fetching URLs are available here:
> https://getfedora.org/atomic_iso_latest_filename
> https://getfedora.org/atomic_qcow2_latest_filename
> https://getfedora.org/atomic_raw_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_latest_filename
> 
> For more information about the latest targets, please reference the Fedora
> Atomic Wiki space.
> 
> 
> https://fedoraproject.org/wiki/Atomic_WG#Fedora_Atomic_Image_Download_Links
> 
> Do note that it can take some of the mirrors up to 12 hours to "check-in" at
> their own discretion.
> 
> Thank you,
> Fedora Release Engineering
> 

We have a new kernel (4.15), ostree [1], and rpm-ostree [2] in this release.
It is also worth noting that now the `rpm-ostree status` output will prefix
the remote:ref with `ostree://` in order to denote the system is following
an ostree repository remote (see example below). This is in preparation of
some upstream changes related to rpm-ostree jigdo, where updates can be 
delivered via a special 

march VFAD for the atomic working group

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

https://pagure.io/atomic-wg/issue/429

In the Atomic working group in Fedora we have occasionally used virtual
Fedora Activity Days (VFADs) to get the community together to discuss 
in a high bandwidth setting (video conference) some techical issues we're
having or some direction of where we're going. 

We have scheduled a VFAD for next Friday (march 9th). We'd like to get
some input on some topics to discuss during this VFAD. Please discuss
and add topics to the ticket.

It would be preferable if we keep discussion in one place so please add
responses to the ticket.

Thanks!
Atomic Working Group
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqW4BkACgkQMwLb1zlS
5nFk+g/+MInPWyUZcBt1ZmBHgPxkyaaE3vDkNIB2upt4nzABVmiOQIFvijnPie37
pN6jRhTChCSFxgDD2NIklNvoJN9CEwSWogD/IFHsr3Ty2p2+5RDHDHaGQVNsEn0a
nD9Ye6E05C0A/iQ3QFbTS+Fin4go+P5Z/ZekCrnaC+6VE12MNf6L1v3y3hXplepo
HuYVf9nfrQr+pw4m/4E1zcWDbxWkDVWv3l76HsVMMzCevgWoj/I6/GGzl0oIgnfy
oMmw9wgpWst72EKMP5bTEpLl1VfG6UU0MVquv4sWpoP3eM7zSjXbwZ1DFuf3gWHS
R4yjWN9vk+haRbyDnfLDZ6/a1hvqXd91rGA9XSNaMVSpSx2ePjBPAj9zO/i4b9ZI
0/04NM3A4ru0jxzDljZmHSolkPh3qmNK9TYFF1Vl3c0ukOAjE1g3JoGHeHCbpyp9
uks1ImatgkhWduV3OyrtpblmxUfZLbn2GxkGKZIavK7z9sN8mStI6Ids4WYMO2PC
Z8k5TYge9lQpUOUQYOSQEEiCxtzuwEJGAzWI7JMW6hECO7xd6XFCqPcrYDChgkAr
PIHJH9/puurhLUmP/3MUpx3nK1V6g26mgs5oeYwYdu7SmSz9RvrlhH5lihWO6njM
6J9A0Pwh8pSgmymXnrBtYZAIgFGmH8ZCuRdgkLDTeJ+GD4aiWy4=
=1Vdx
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Frequently broken Rawhide/Branched composes

[Dusty Mabe]

On 03/01/2018 11:52 AM, Kevin Kofler wrote:
> Vít Ondruch wrote:
>> Speaking of that, it seems that the Rawhide compose failed yesterday due
>> to some KDE/QT soname bump:
> [actually a typo in a Requires, as was already pointed out]
>>
>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log
>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/i386-x86_64/livemedia-Spins-KDE.i386-x86_64.log
>> https://kojipkgs.fedoraproject.org//work/tasks/8910/25368910/root.log
> 
> Well, the real issue is that the entire Rawhide compose fails just because 
> one release-blocking deliverable failed to compose. In this case, it was the 
> KDE Spin, but it has been happening with any other release-blocking 
> deliverable, e.g., Atomic ostree composes.

FYI: atomic ostree composes are not release blocking so that is not why a 
compose
will fail.

> 
> Why can we not just deliver the parts that succeeded and keep the last 
> working version of the deliverables that failed to compose this time? In 
> other words, why can we not just upload the 20180228 compose and keep the 
> 20180227 or whatever KDE ISO that last built? Why does it have to be all or 
> nothing?
> 
> Kevin Kofler
> ___
> 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: Fedora 28 Atoimic Host RC 1.1 available for testing

[Dusty Mabe]

On 04/25/2018 04:58 PM, Colin Walters wrote:
> 
> 
> On Wed, Apr 25, 2018, at 4:35 PM, Dusty Mabe wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> The Atomic Host compose based on RC 1.1 is available for testing now.
>>
>> The toplevel directory is: 
>> https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-28-20180425.0
>>
>> The cloud images are under the compose/AtomicHost/$arch/images/ directories.
> 
> I've been playing with the Vagrant boxes mostly lately locally, things have 
> seemed fine.
> 
> Only thing I notice today is:
> 
> # rpm-ostree upgrade
> error: Upgrade target revision 
> '030a6775611902b56bf26dbb20889c83bfdbd9f35b4a19b38f0a58fd574cf65e' with 
> timestamp 'Wed 25 Apr 2018 12:25:17 PM UTC' is chronologically older than 
> current revision 
> '94a9d06eef34aa6774c056356d3d2e024e57a0013b6f8048dbae392a84a137ca' with 
> timestamp 'Wed 25 Apr 2018 07:14:57 PM UTC'; use --allow-downgrade to permit
> 
> But I assume that'll be fixed post-release.

Yes, that will be fixed when we run through the release process.

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

Fedora 28 Atoimic Host RC 1.1 available for testing

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The Atomic Host compose based on RC 1.1 is available for testing now.

The toplevel directory is: 
https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-28-20180425.0

The cloud images are under the compose/AtomicHost/$arch/images/ directories.
The ISO images are under the compose/AtomicHost/$arch/iso/ directories.

We don't yet have AMIs. Will update you when those are available.

- - Atomic WG
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlrg5qUACgkQMwLb1zlS
5nGKkhAAwOTjZGsnlYSpL6uGbMeNrLLkEfaRzzMpJX77PiR6yIAggm1JmtDtZyDo
qtI8A2/2ibxGoapzBXWieWOvBus1MC2x4VSVpRqAxlCeUXH2wW4d7dBU5KQRWIev
GDCfK7Lq6PML/dgrukgRP6RR8nQZPeVj22BEHG3Wp3YbXgR550R23jBBdqfTuP9z
8vph26jY/9d9MavFa9QfyUYt6jvAlprhZ4jFyEfLYlEHxeuqcJkb3HrF40XTzC8s
+6W+qaPkcP2r7Ogz0wf0RQ4nVDwS+B/Z+LFG6ivhXiqNf/SIR9CnMiCN/Y/Qu+XP
w+XrKNVSccj4gTLBFjib0n7BL8UegLf3FSuBKufQ7e9akSmBcOgPZmoyuYvbN3AI
M/4dfdpelqm0gJr+fQipp3XH4jJPaBtXdDbjizg7ZH8oRJmITtPDY2C2V8p5oJUU
5xZL+ba7td+cn+iETIeKGMGGHoKzoFp5EfIjnwIxBB1WZhRbPhV1jaJO81XoGf3e
SkAe/bO8n2/awTjsrsKJhN3QqO9s4O77tkGt5zgBsn0oSUvCZnAq867qMdMJrZcz
lskj8FbRFn4mH7UBI/zyh1kWMz5f/7EICZJtckhIn1YrrEvPkY1QpaYd+hgrfPou
ONlZ18jqDNaxiJle79SMLFW+tTXtMEJwkiDqUOaQNppbsKJC8fs=
=ROaE
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [atomic-devel] Fedora 28 Atoimic Host RC 1.1 available for testing

[Dusty Mabe]

On 04/26/2018 08:54 AM, Sinny Kumari wrote:
> 
> 
> On Thu, Apr 26, 2018 at 2:05 AM, Dusty Mabe <du...@dustymabe.com 
> <mailto:du...@dustymabe.com>> wrote:
> 
> The Atomic Host compose based on RC 1.1 is available for testing now.
> 
> The toplevel directory is: 
> https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-28-20180425.0
>  
> <https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-28-20180425.0>
> 
> The cloud images are under the compose/AtomicHost/$arch/images/ directories.
> The ISO images are under the compose/AtomicHost/$arch/iso/ directories.
> 
> 
>> Tested Atomic Host RC 1.1:
>> * Both ISO and cloud images look good  on all arches
>> * AMIs are working as expected including openshift cluster set-up
>> * Ran couple of podman commands and it worked as expected on all arches,
>>   One thing I noticed that, since both docker and podman are available on 
>> host,
>>   running "podman run -t fedora bash" didn't have network connectivity
>>   inside container. So, I ran podman with option --net=host and network was 
>> fine
>>   later on.


Weird. I think I'm seeing the same thing. If I disable docker and reboot I get 
the
expected behavior. For now we can just advise to disable docker if they want
to use podman. It doesn't make a lot of sense to try to use both on the same 
system
anyway.

Sinny can you open an issue for this in atomic-wg and we'll ask brent for 
input. 

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

resume= kernel cmdline arg by default on servers

[Dusty Mabe]

For BZ1206936 [1] we started adding resume= kernel command line by
default [2] in fedora installs. This is causing issues for ostree
based systems, which I haven't fully investigated yet, but figured
I would ask the question:

Is resume=/path/to/swap something we really want on server installs
like Fedora Server and Fedora Atomic Host?

Dusty

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1206936
[2] 
https://github.com/poncovka/anaconda/commit/07c8591b107c34f3825dfa2d2b20c5c95cb3b892
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: resume= kernel cmdline arg by default on servers

[Dusty Mabe]

On 10/18/2018 07:58 AM, Stephen Gallagher wrote:
> On Wed, Oct 17, 2018 at 11:27 PM Dusty Mabe  wrote:
>>
>>
>> For BZ1206936 [1] we started adding resume= kernel command line by
>> default [2] in fedora installs. This is causing issues for ostree
>> based systems, which I haven't fully investigated yet, but figured
>> I would ask the question:
>>
>> Is resume=/path/to/swap something we really want on server installs
>> like Fedora Server and Fedora Atomic Host?
>>
> 
> It seems *unnecessary*, but I'm not sure I understand what problems it
> causes. Could you got into more detail there?

Yeah. https://pagure.io/atomic-wg/issue/513#comment-536736

Basically for some reason on ostree based systems the LV isn't available
before the systemd unit for hibernation runs and boot has to wait for that
unit to timeout before continuing. I'm still investigating why that is.

> 
> I can't see anyone putting a Server or Atomic Host into hibernation,
> though. Does this just direct the kernel where that should go if
> hibernation is requested, or does it reserve space or something for
> it?
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 29 Final Go/No-Go meeting

[Dusty Mabe]

On 10/12/2018 10:08 PM, Trever L. Adams wrote:
> On 10/12/18 9:27 AM, Ben Cotton wrote:
>> Dear all,
>>
>> The Go/No-Go meeting for the Fedora 29 Final release will be held on
>> Thursday, 2018-10-18 at 17:00 UTC in #fedora-meeting-1. For more
>> information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting
>>
>> View the meeting on Fedocal at
>> https://apps.fedoraproject.org/calendar/Fedora%20release/2018/10/18/#m9379
>>
> I am not part of the groups that are at these meetings. Please, consider
> Bug #1636811 about FreeRadius. It is a simple fix.

Good news! You can propose it yourself here and it will be considered:

https://qa.fedoraproject.org/blockerbugs/propose_bug
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi update pushes are now automated

[Dusty Mabe]

On 11/7/18 1:35 PM, Michael Cronenworth wrote:
> On 11/7/18 10:44 AM, Mohan Boddu wrote:
>> For a long time now updates are pushed manually everyday. It was troublesome 
>> and 
>> someone has to own it for a week and look after it.
>>
>> Now, the pushes are automated and are pushed everyday at 00:00 UTC. If 
>> anything 
>> fails there will be an oncall person (same person who used to do the pushes) 
>> who 
>> will take care of the failure.
>>
>> During release freezes these automated pushes are disabled and are manually 
>> pushed 
>> by RelEng/Infra. Since freezes should be handled differently this will give 
>> RelEng 
>> more control over the pushes.
>>
>> Please let us know if you have any questions or contact us on #fedora-releng 
>> on 
>> Freenode.
> 
> While many may not see this as significant I see this as a giant leap 
> forward. Great 
> job everyone!

+1 - great news!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

where to put udev rules for to support cloud providers

[Dusty Mabe]

context: https://github.com/coreos/fedora-coreos-tracker/issues/104

There are some udev rules that support various hardware on different cloud 
providers
that we'd like to provide as part of Fedora CoreOS so it can operate on those 
platforms
as expected. In the past these udev rules could be provided by the cloud-init 
package
or by the cloud specific agent for a particular cloud provider. In Fedora 
CoreOS we are
attempting to not ship both cloud-init or any platform specific cloud agents. 
We would like
to ship various bits like these udev rules. The question is: where (what 
package) should 
provide these rules?

One thing to think about is that we think this work would benefit the Fedora 
Cloud Base
image as well, so we are trying not to make it specific to Fedora CoreOS.

- Should they go into a `fedora-release-coreos` and `fedora-release-cloud` 
package?
- Both of these share the same srpm
- Should they go into a `cloud-platforms` package where we could possibly put 
other
  cloud supporting bits as well?

Thanks
Fedora CoreOS Team



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction - Robert Fairley

[Dusty Mabe]

On 1/17/19 12:31 PM, Robert Fairley wrote:
> Hi all,
> 
> I'm an intern at Red Hat in Toronto, Canada. I'm working on Fedora CoreOS, 
> and helping bring aspects of Container Linux to Fedora. I'll be maintaining a 
> package upstream, console-login-helper-messages. I also help out with 
> ostree/rpm-ostree upstream. Looking forward to contributing further in the 
> Fedora space!
> 
> Best regards,
> Robert Fairley

If you haven't had a chance to interact with Robert yet please do say hi to 
`rfairley`
on freenode (in the #fedora-coreos channel). He's done some amazing work in a 
short
amount of time.

Welcome Robert!

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Atomic 29: ostree upgrade failed because of libdnf

[Dusty Mabe]

On 12/5/18 5:14 AM, arnaud gaboury wrote:
> 
> 
> On Tue, Dec 4, 2018 at 6:57 PM Dusty Mabe  <mailto:du...@dustymabe.com>> wrote:
> 
> 
> 
>     On 12/4/18 11:40 AM, Dusty Mabe wrote:
> 
> >
> > I will look at the configs and see if I can figure out where things are 
> going wrong.
> >
> 
> I think this a a regression is some of the new yaml parsing in pungi. I 
> opened a bug
> to see https://pagure.io/pungi/issue/1092
> 
> The updates-testing runs are running right after the updates runs and 
> overwriting the ref.
> For now we can disable updates-testing composes for silverblue so that it 
> won't overwrite
> the updates run.
> 
> Here is a PR for that:
> 
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/LGL6LPHSOPNKQUWGYHGZVSDOX466WHFH/
> 
> Dusty
> 
> 
> My issue has been solved and could upgrade

Yep. We put in a workaround yesterday. We should be good now. Sorry about that.

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Atomic 29: ostree upgrade failed because of libdnf

[Dusty Mabe]

On 12/4/18 11:40 AM, Dusty Mabe wrote:

> 
> I will look at the configs and see if I can figure out where things are going 
> wrong.
> 

I think this a a regression is some of the new yaml parsing in pungi. I opened 
a bug
to see https://pagure.io/pungi/issue/1092

The updates-testing runs are running right after the updates runs and 
overwriting the ref.
For now we can disable updates-testing composes for silverblue so that it won't 
overwrite
the updates run.

Here is a PR for that: 
https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/LGL6LPHSOPNKQUWGYHGZVSDOX466WHFH/

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Atomic 29: ostree upgrade failed because of libdnf

[Dusty Mabe]

On 12/4/18 5:11 AM, arnaud gaboury wrote:
> -
> $ cat /etc/os-release
> NAME=Fedora
> VERSION="29.20181129.0 (Workstation Edition)"
> ID=fedora
> VERSION_ID=29
> PLATFORM_ID="platform:f29"
> PRETTY_NAME="Fedora 29.20181129.0 (Workstation Edition)"
> ---
> 
> now upgrading:
> 
> --
> 
>  # rpm-ostree upgrade 
> 1 metadata, 0 content objects fetched; 569 B transferred in 1 seconds
> Checking out tree 33b20cd... done
> Enabled rpm-md repositories: updates fedora yarn rpm-fusion
> rpm-md repo 'updates' (cached); generated: 2018-12-04T02:37:23Z
> rpm-md repo 'fedora' (cached); generated: 2018-10-24T22:20:15Z
> rpm-md repo 'yarn' (cached); generated: 2018-11-07T20:05:15Z
> rpm-md repo 'rpm-fusion' (cached); generated: 2018-10-23T11:05:19Z
> Importing metadata [=] 100%
> Resolving dependencies... Forbidden base package replacements:
>   libdnf 0.22.3-1.fc29 -> 0.22.0-8.fc29 (updates)
> failed
> error: Some base packages would be replaced



I saw this over the weekend but didn't have a lot of extra time to investigate. 
My theory
here is that one of your layered packages (can you give the output of 
`rpm-ostree status`?)
contains a package that depends on the newer libdnf. This should not happen but 
I suspect
an rpm that depends on the newer libdnf made it into the updates repo before 
the newer libdnf
made it into the updates repo.


On a side note I also found that my local installation of silverblue contains 
podman-0.11.1-1.gita4adfe5.fc29.x86_64, which, according to bodhi, isn't in 
updates:
https://bodhi.fedoraproject.org/updates/?packages=podman

So it's possible either there are some issues with our repos or our silverblue 
composes
might be pulling wrong content somehow.

And... After a little investigation I can see there is some different content 
between
the atomic host updates compose and the silverblue compose:


```
[dustymabe@media fedora-ostree-repo-mirror]$ ostree log 
onerepo:fedora/29/x86_64/silverblue  | head -n 5
commit 33b20cd7f31286861c7f7cdd78fe6211d76f2a1683141ed78290bc990ce64a52
ContentChecksum:  
cd3e6a7624f4638a8627032e3c9e7cb21cfb898456e1e7efad698eb194b2db8d
Date:  2018-12-04 03:43:35 +
Version: 29.20181204.0 
(no subject)
[dustymabe@media fedora-ostree-repo-mirror]$ ostree log 
onerepo:fedora/29/x86_64/updates/atomic-host  | head -n 5
commit f6086b9fff20af1f4b1a9c172191026a56dd36342933da9344b38004fe4dd758
ContentChecksum:  
db363011cbbe8a5e3796cdaecb0ff47f64f5ac931fca7d4fcf92027c25a262a6
Date:  2018-12-04 00:57:30 +  
Version: 29.20181204.0
(no subject)   
[dustymabe@media fedora-ostree-repo-mirror]$
[dustymabe@media fedora-ostree-repo-mirror]$ rpm-ostree --repo=./ db diff 
f6086b9fff20af1f4b1a9c172191026a56dd36342933da9344b38004fe4dd758 
33b20cd7f31286861c7f7cdd78fe6211d76f2a1683141ed78290bc990ce64a52
ostree diff commit old: 
f6086b9fff20af1f4b1a9c172191026a56dd36342933da9344b38004fe4dd758
ostree diff commit new: 
33b20cd7f31286861c7f7cdd78fe6211d76f2a1683141ed78290bc990ce64a52
Upgraded: 
  NetworkManager 1:1.12.4-2.fc29 -> 1:1.12.6-1.fc29
  NetworkManager-libnm 1:1.12.4-2.fc29 -> 1:1.12.6-1.fc29
  cryptsetup 2.0.5-1.fc29 -> 2.0.6-1.fc29   
  cryptsetup-libs 2.0.5-1.fc29 -> 2.0.6-1.fc29
  fedora-release 29-4 -> 29-5 
  fuse-overlayfs 0.1-5.dev.gitd40ac75.fc29 -> 0.1-6.dev.git3d48bf9.fc29
  kernel 4.19.5-300.fc29 -> 4.19.6-300.fc29
  kernel-core 4.19.5-300.fc29 -> 4.19.6-300.fc29
  kernel-modules 4.19.5-300.fc29 -> 4.19.6-300.fc29 
  pam 1.3.1-8.fc29 -> 1.3.1-13.fc29 
  podman 1:0.10.1.3-4.gitdb08685.fc29 -> 1:0.11.1-1.gita4adfe5.fc29
  runc 2:1.0.0-57.dev.git9e5aa74.fc29 -> 2:1.0.0-59.dev.gitccb5efd.fc29
Removed:
```

Looking at the commit timestamps from above and the timestamps from the compose 
logs
it looks like the silverblue ref was written by the updates-testing compose [1] 
rather than the updates compose [2].

I will look at the configs and see if I can figure out where things are going 
wrong.

Dusty


[1]  
https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-updates-testing-20181204.0/logs/x86_64/Everything/ostree-4/
[2] 
https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-updates-20181204.0/logs/x86_64/Everything/ostree-4/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Any plans to support .heic files in Fedora?

[Dusty Mabe]

On 12/3/18 6:53 PM, Leigh Scott wrote:
>> On 11/30/18 5:20 AM, Leigh Scott wrote:
>>
>> Thanks Leigh. I see those have already made progress in code review. +1000
>>
>> Is there a definitive reason why those are necessary to go in RPM fusion? 
>> Was 
>> Tom Hughes right?
>>
>> Dusty
> 
> This sums up the situation
> 
> http://gnome-apps.13852.n7.nabble.com/High-Efficiency-Image-File-Format-HEIF-HEIC-support-td70229.html

Thanks! That helps a lot!

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Any plans to support .heic files in Fedora?

[Dusty Mabe]

On 11/30/18 5:20 AM, Leigh Scott wrote:
> Reviewers welcome.
> 
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=5089
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=5090

Thanks Leigh. I see those have already made progress in code review. +1000

Is there a definitive reason why those are necessary to go in RPM fusion? Was 
Tom Hughes right?

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Atomic 29: ostree upgrade failed because of libdnf

[Dusty Mabe]

On 12/6/18 6:20 AM, arnaud gaboury wrote:
> 
> 
> On Wed, Dec 5, 2018 at 4:13 PM Dusty Mabe  <mailto:du...@dustymabe.com>> wrote:
> 
> 
> 
> On 12/5/18 5:14 AM, arnaud gaboury wrote:
> >
> >
>     > On Tue, Dec 4, 2018 at 6:57 PM Dusty Mabe  <mailto:du...@dustymabe.com> <mailto:du...@dustymabe.com 
> <mailto:du...@dustymabe.com>>> wrote:
> >
> >
> >
> >     On 12/4/18 11:40 AM, Dusty Mabe wrote:
> >
> >     >
> >     > I will look at the configs and see if I can figure out where 
> things are going wrong.
> >     >
> >
> >     I think this a a regression is some of the new yaml parsing in 
> pungi. I opened a bug
> >     to see https://pagure.io/pungi/issue/1092
> >
> >     The updates-testing runs are running right after the updates runs 
> and overwriting the ref.
> >     For now we can disable updates-testing composes for silverblue so 
> that it won't overwrite
> >     the updates run.
> >
> >     Here is a PR for that:
> >     
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/LGL6LPHSOPNKQUWGYHGZVSDOX466WHFH/
> >
> >     Dusty
> >
> >
> > My issue has been solved and could upgrade
> 
> Yep. We put in a workaround yesterday. We should be good now. Sorry about 
> that.
> 
> 
> Don't be sorry and be proud for your very quick action and for the good work 
> you do with this wonderful distro.

Thanks! It's an incredible team of people that help pull it off. I'm thankful 
for everyone who contributes!

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

prevent accidentally creating branches in dist-git

[Dusty Mabe]

I've certainly made the mistake of accidentally creating branches
in dist-git and now being stuck with them because we can't delete
them. Now that src.fedoraproject.org (dist-git) is backed by a newer
version of pagure you can prevent creating new branches by `git push`.

For your project in the web UI:

- Go to the `Settings` menu
- Select `Hooks` from the left hand side
- Expand `Prevent creating new branches by git push`
- Click the checkbox
- Click `Update`

I personally think this should be the default for all projects but
I don't know if there is a way to easily make that happen when a project
gets created.

Hope this helps someone! 
Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Any plans to support .heic files in Fedora?

[Dusty Mabe]

Seems like Apple converted their phones over to using a new file format
to store pictures. I was copying some pictures from a phone and noticed
my linux box couldn't read them and they had an interesting extension .heic.

Looks like there is a new image format in town and we need the libheif and
libde265 libraries in order to read it according to the gimp plugin [1]. The
plugin docs say it should be included by default now in gimp but the gimp on
my f29 system says it can't read the file. This is probably because we don't
have the underlying libraries in Fedora.

Anybody been down this road? Is it as simple as getting the libraries in or
is there much more pain involved that I haven't discovered yet?

Thanks,
Dusty

[1] https://github.com/strukturag/heif-gimp-plugin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement: 28.20180917.0

[Dusty Mabe]

On 09/17/2018 03:19 PM, nore...@fedoraproject.org wrote:
> 
> A new Fedora Atomic Host update is available via an OSTree update:
> 
> Version: 28.20180917.0
> Commit(x86_64): 
> 17b11d74047ded1264a57555a64ae6fc5d02a332c556679bfcf32864fc91f11e
> Commit(aarch64): 
> 95cdc6d02ed7f3645bdd513b07b2c2db9b04e91d8aae897fa88e378285a2b551
> Commit(ppc64le): 
> ca3012e5792f84499783510e5586526b9eaf8d98f535e3de0157ec7f7ad369ae
> 

FYI. With this release you may notice long boot times for VMs as the VM waits 
for
enough entropy to continue. This should be fixed soon. Follow this [1] issue and
this [2] bodhi update in order to receive updates on that status. 

[1] https://pagure.io/atomic-wg/issue/511
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2018-f93103ae20



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packit is released: Packaging as a Service

[Dusty Mabe]

On 3/21/19 9:40 AM, Tomas Tomecek wrote:
> We are pleased to announce the initial version of Packit.
> 
> Packit makes it easy to bring and integrate your upstream projects
> into Fedora, right now we are focused to bring upstream
> releases into Fedora rawhide. You can use packit now as a command-line
> tool, soon Packit will run as a hosted service (much like Travis CI)
> and run these tools automatically.
> 
> The project is hosted on Github and available in Fedora as "packit":
> * https://github.com/packit-service/packit
> 
> For more info please read two blog posts covering the upstream
> releases of packit:
> * 0.1.0 - https://github.com/packit-service/packit/blob/master/docs/01.md
> * 0.2.0 - https://github.com/packit-service/packit/blob/master/docs/02.md
> 
> There is also detailed documentation for workflows which packit covers:
> * https://github.com/packit-service/packit#workflows-covered-by-packit
> 
> This is just a beginning for the project and we are excited to receive
> your feedback.
> 
> Tomas, on behalf of the whole Packit team.

Nice work Tomas, team! I'm really excited to give this a spin. 

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Removing Atomic Host from Fedora Rawhide

[Dusty Mabe]

Hello Fedora Atomic Host users,

With the switched focus to Fedora CoreOS for the future of our immmutable, 
container
oriented operating systems the last major release of Fedora Atomic Host was 
Fedora
29. Considering this we are removing the builds for Fedora Atomic Host from 
rawhide
and will no longer be building that stream.

If you are currently using Fedora Atomic Host on rawhide, please rebase to 
Fedora
29 so you'll continue to receive updates until Fedora 29 EOL. You can rebase 
with
the command below. Please test this on some non-critical systems first. 

```
rpm-ostree rebase fedora/29/x86_64/atomic-host
```

If you have trouble find me in #atomic or #fedora-coreos on freenode.

Dusty



signature.asc
Description: OpenPGP digital signature
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement: 29.20190513.0

[Dusty Mabe]

On 5/15/19 8:25 AM, Sven Kieske wrote:
> Hi,
> 
> is there a reason why _all_ links below:
> 
> https://getfedora.org/en/atomic/*
> 
> are dead?
> 
> I always get, e.g.:
> 
> Not Found
> 
> The requested URL /en/atomic/download/ was not found on this server.
> Apache Server at getfedora.org Port 443

Hey Sven,

Thanks for reporting this. There was a recent update to the getfedora.org 
website and I imagine the redirects that we had set up no longer work.

I have opened this ticket to track fixing it: 
https://pagure.io/fedora-infrastructure/issue/7802

Dusty

> 
> Am 13.05.19 um 21:09 schrieb nore...@fedoraproject.org:
>> Corresponding image media for new installations can be downloaded from:
>>
>> https://getfedora.org/en/atomic/download/
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement: 29.20190516.0

[Dusty Mabe]

On 5/16/19 6:27 PM, nore...@fedoraproject.org wrote:
> 
> A new Fedora Atomic Host update is available via an OSTree update:
> 
> Version: 29.20190516.0
> Commit(x86_64): 
> 7f719bf60b865ca96aacd0e8ae3e6074c7eb5783d8ceb9003dbba5dfd5a29ba3
> Commit(aarch64): 
> 3930a03b8ffcce1aa66f17b8811e2a4da80aedb8234a1f47b62d603986b580ec
> Commit(ppc64le): 
> 144bb02d1485234b79ba385b47dc64199a7df159d3a0a3f17837cc7fb90cf7e1
> 
> 
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
> 
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
> 
> Corresponding image media for new installations can be downloaded from:
> 
> https://getfedora.org/en/atomic/download/
> 
> Alternatively, image artifacts can be found at the following links:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190516.0.aarch64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190516.0.aarch64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190516.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190516.0.ppc64le.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190516.0.ppc64le.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190516.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190516.0.x86_64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190516.0.x86_64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190516.0.x86_64.vagrant-libvirt.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190516.0.x86_64.vagrant-virtualbox.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190516.0.iso
> 
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190516.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190516.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190516.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190516.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190516.0-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190516.0-x86_64-CHECKSUM
> 
> For direct download, the "latest" targets are always available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest
> https://getfedora.org/atomic_raw_x86_64_latest
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest
> 
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest
> https://getfedora.org/atomic_raw_aarch64_latest
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest
> 
> ppc64le:
> https://getfedora.org/atomic_qcow2_ppc64le_latest
> https://getfedora.org/atomic_raw_ppc64le_latest
> https://getfedora.org/atomic_dvd_ostree_ppc64le_latest
> 
> Filename fetching URLs are available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest_filename
> https://getfedora.org/atomic_raw_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename
> 
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest_filename
> https://getfedora.org/atomic_raw_aarch64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename
> 

Re: How to consume fedora-messaging?

[Dusty Mabe]

On 6/10/19 12:06 PM, Adam Williamson wrote:
> On Mon, 2019-06-10 at 09:24 +0900, Tristan Cacqueray wrote:
>> On Mon, Jun 10, 2019 at 01:24 Igor Gnatenko wrote:
>>> Hello,
>>>
>>> I have been trying to write some script which would listen on
>>> generation of new repository / successful build is tagged in Koji and
>>> do some actions locally. Or basically whenever someone pushes commits,
>>> I want to fetch repo locally.
>>>
>>> I was reading 
>>> https://fedora-messaging.readthedocs.io/en/latest/consuming.html,
>>> but it is not very clear to me where I can find list of topics and
>>> what data messages will contain...
> 
> As well as the doc, there is a sample consumer:
> https://github.com/fedora-infra/fedora-messaging/blob/master/fedora_messaging/example.py
> and a couple of sample config files:
> https://github.com/fedora-infra/fedora-messaging/blob/master/configs/fedora.toml
> https://github.com/fedora-infra/fedora-messaging/blob/master/configs/fedora.stg.toml
> that you will probably find useful.
> 
>>
>> Hi Igor,
>>
>> you can find the list of topics and their associated schema here:
>> https://fedora-fedmsg.readthedocs.io/en/latest/topics.html
> 
> Treat this with caution, because it is...sometimes a lie. 


related: https://github.com/fedora-infra/fedora-messaging/issues/180

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement: 29.20190625.0

[Dusty Mabe]

On 6/25/19 1:38 PM, nore...@fedoraproject.org wrote:
> 
> A new Fedora Atomic Host update is available via an OSTree update:
> 
> Version: 29.20190625.0
> Commit(x86_64): 
> c50cc86ad7972f85853f1deafda3899eb86a0e5220c613744eed64320298716e
> Commit(aarch64): 
> 0e82ac50808a1513cab1f8ad4c6262c091b19f39e3dfad8f22c2252aec38fd34
> Commit(ppc64le): 
> 72c06a8c8c18ff47ae9f7385a322dee325480ccc8a9276eafe9ac18b9a296422
> 
> 
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
> 
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
> 
> Corresponding image media for new installations can be downloaded from:
> 
> https://getfedora.org/en/atomic/download/
> 
> Alternatively, image artifacts can be found at the following links:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190625.0.aarch64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190625.0.aarch64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190625.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190625.0.ppc64le.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190625.0.ppc64le.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190625.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190625.0.x86_64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190625.0.x86_64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190625.0.x86_64.vagrant-libvirt.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190625.0.x86_64.vagrant-virtualbox.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190625.0.iso
> 
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190625.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190625.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190625.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190625.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190625.0-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190625.0-x86_64-CHECKSUM
> 
> For direct download, the "latest" targets are always available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest
> https://getfedora.org/atomic_raw_x86_64_latest
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest
> 
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest
> https://getfedora.org/atomic_raw_aarch64_latest
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest
> 
> ppc64le:
> https://getfedora.org/atomic_qcow2_ppc64le_latest
> https://getfedora.org/atomic_raw_ppc64le_latest
> https://getfedora.org/atomic_dvd_ostree_ppc64le_latest
> 
> Filename fetching URLs are available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest_filename
> https://getfedora.org/atomic_raw_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename
> 
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest_filename
> https://getfedora.org/atomic_raw_aarch64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename
> 

Re: Fedora Rawhide-20190625.n.0 compose check report

[Dusty Mabe]

On 6/25/19 6:32 PM, Adam Williamson wrote:
> On Tue, 2019-06-25 at 17:45 +, Fedora compose checker wrote:
>> Missing expected images:
>>
>> Atomichost raw-xz x86_64
>> Atomichost qcow2 x86_64
>>
>> Compose FAILS proposed Rawhide gating check!
>> 3 of 47 required tests failed, 4 results missing
>> openQA tests matching unsatisfied gating requirements shown with **GATING** 
>> below
> 
> So, quite a few of these failures were down to some appearance changes
> in GNOME; I've updated the needles and am re-running those tests in
> prod now.
> 
> Dusty, Colin, and atomic@ : you got this mail because fedfind / check-
> compose considered the Atomic Host images to be "missing", and I just
> implemented a thing in check-compose yesterday to send you reports when
> there is an Atomic-related failure (like we used to do with the
> separate Fedora-Atomic composes):
> 
> https://pagure.io/fedora-qa/check-compose/issue/2
> 
> there is of course a bug there - fedfind shouldn't consider Atomic Host
> to be expected for Rawhide any more. I noticed that problem for F30+
> updates composes and fixed it prior to rolling out the new check-
> compose, but didn't notice it also needed fixing for Rawhide and
> Branched. I will fix that now and send a new fedfind out.
> 

Thanks Adam
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning cloud-init, python-boto

[Dusty Mabe]

On 8/10/19 9:06 PM, Garrett Holmstrom wrote:
> Hi,
> 
> My time to work on Fedora cloud-related things has diminished in
> recent months, so I have not been able to give the cloud-init and
> python-boto packages the care they deserve.  They are free to a good
> home.
> 

Maybe larks (cc) would be interested.

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Xen / EC2 release criteria proposal

[Dusty Mabe]

On 8/9/19 8:56 PM, Adam Williamson wrote:
> Hey folks! I'm starting a new thread for this to trim the recipient
> list a bit and include devel@ and coreos@.

Hey Adam!

> 
> The Story So Far: there is a Fedora release criterion which requires
> Fedora to boot on Xen:
> 
> "The release must boot successfully as Xen DomU with releases providing
> a functional, supported Xen Dom0 and widely used cloud providers
> utilizing Xen."
> 
> We (QA group) had a discussion about removing this criterion entirely.
> That has now morphed into the idea that we should tweak it to be
> focused exclusively on the "widely used cloud providers utilizing
> Xen"...by which we mean EC2. At the time this criterion was invented,
> all EC2 instance types used Xen; now, some still use Xen, and some use
> KVM.
> 
> So it seems like this would also be a good opportunity to revisit and
> nail down more specifically exactly what our cloud requirements are.
> bcotton suggested  that we require two sample instance types to be
> tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas
> Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed
> like it might be worthwhile - he's promised to get back to me).
> 
> So, for now, let me propose this as a trial balloon: we rewrite the
> above criterion to say:
> 
> "Release-blocking cloud disk images must be published to Amazon EC2 as
> AMIs, and these must boot successfully and meet other relevant release
> criteria on c5.large and t3.large instance types."

Sounds good to me if we trim it down to a few instance types that we think
will cover Xen and KVM based booting in EC2. For Fedora CoreOS we'll be doing
some automated testing in EC2. I don't know if we have a certain set of instance
types we'll be using for that, but the information that Matt provided should
help us decide.

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning cloud-init, python-boto

[Dusty Mabe]

On 8/10/19 9:06 PM, Garrett Holmstrom wrote:
> Hi,
> 
> My time to work on Fedora cloud-related things has diminished in
> recent months, so I have not been able to give the cloud-init and
> python-boto packages the care they deserve.  They are free to a good
> home.
> 

Can you give cloud-init to me and major hayden (@mhayden) for now?

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora-29-updates-testing-20190819.0 compose check report

[Dusty Mabe]

On 8/19/19 1:18 AM, Sinny Kumari wrote:
> From the build logs [1] [2] , it looks like disk got full which could be 
> builder specific. We can dig in more if it happens again.
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=37134473
> [2] 
> https://kojipkgs.fedoraproject.org//work/tasks/4473/37134473/screenshot.ppm
> 
>

Thanks for looking Sinny!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement: 29.20190820.0

[Dusty Mabe]

On 8/21/19 5:46 AM, Normand wrote:
> 
> 
> On 8/20/19 7:56 PM, nore...@fedoraproject.org wrote:
>> We are releasing images from multiple architectures but please note
>> that x86_64 architecture is the only one that undergoes automated
>> testing at this time.
> 
> Is there wiki pages that describe what are those automated tests, and 
> how/where they have been run ?
> 


We run tests in openqa and autocloud. The links are listed in the release doc
that we follow:

https://pagure.io/atomic-wg/blob/master/f/docs/two-week-release-steps.md

For Fedora CoreOS we'll be using kola for automated tests in clouds.
Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-gpg-keys not updated yet again

[Dusty Mabe]

On 8/23/19 12:21 PM, Kevin Fenzi wrote:
> On 8/23/19 4:12 AM, Dusty Mabe wrote:
>>
>>
>> On 8/22/19 12:58 PM, Kevin Fenzi wrote:
>>> On 8/21/19 9:27 AM, Dusty Mabe wrote:
>>>>
>>>>
>>>> On 8/19/19 6:59 AM, Pavel Raiskup wrote:
>>>>> On Monday, August 19, 2019 10:50:52 AM CEST Zbigniew Jędrzejewski-Szmek 
>>>>> wrote:
>>>>>> Can we *please* send out the FN+1 and FN+2 keys a month before branching,
>>>>>> to *all* releases of Fedora, so we can avoid this pointless scramble?
>>>>>
>>>>> What about to have F33 keys right now, when the fresh F31 branch is out?
>>>>>
>>>>
>>>> +1. Go ahead and make the f33 keys when we branch for f31. 
>>>
>>> I don't see how this helps any. I agree we should push out the f33 keys
>>> before next branching, but why now?
>>>
>>
>> For me it solves any "timing" issues. We often get into a state where we're
>> trying to upgrade to something that is signed with a key we don't have yet.
> 
> Yes, but it would also be solved by pushing the F33 key out a few weeks
> or a month or so before branching next time right?
> 

It depends on how often people update. If they wait a month to do an update we
still get into a situation like this where fedora-gpg-keys doesn't have the key
but they are trying to update to a system that has content signed by it.

Creating the key for the next next rawhide at time of branching would also mean
that we make minimal changes to our existing SOPs. The ONLY change is that now
we're creating the key for the next next rawhide instead.   

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [atomic-announce] Fedora Atomic 29 EOL date?

[Dusty Mabe]

On 8/24/19 6:27 AM, Feilong Wang wrote:
> Hi team,
> 

Hi Feilong! I'm adding in Spyros who has worked with us in the past on Atomic 
Host and Magnum.

> Could you please help me understand when will be the EOL date for Fedora 
> Atomic 29? I understand generally it takes 13 months. But given Fedora Atomic 
> 29 -> Fedora CoreOS 30 is a big jump, is there any special considering for 
> this case?

Fedora 29 Atomic Host will follow the EOL schedule for Fedora 29. It will EOL 
approximately a month
after Fedora 31 is released. Fedora 31 is scheduled to be released at the end 
of October, so the EOL
for Fedora 29 will probably be around the end of November. 

> 
> The background is OpenStack Magnum is using Fedora Atomic as the base 
> operating system to deploy Kubernetes cluster, but because of the big change 
> from FA29 to FCOS 30, we haven't got enough resources on this work. So it 
> would be really helpful if the Fedora Atomic/CorOS community can help me 
> understand the roadmap and plan. Thank you very much.
> 

The Fedora CoreOS preview release is out now. We're hoping to bring that to 
stable ASAP but we've got
some things we'd like to finish before we make that declaration. The best thing 
that can be done is to
get some experience trying out OpenStack Magnum on Fedora CoreOS so that we can 
get in fixes now before
we declare stable. 

We'd like to work with you more closely to make sure the transition is smooth 
for the Magnum project. Can
you all share some time/resources to work with us to make sure we smooth out 
any wrinkles?

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-gpg-keys not updated yet again

[Dusty Mabe]

On 8/19/19 6:59 AM, Pavel Raiskup wrote:
> On Monday, August 19, 2019 10:50:52 AM CEST Zbigniew Jędrzejewski-Szmek wrote:
>> Can we *please* send out the FN+1 and FN+2 keys a month before branching,
>> to *all* releases of Fedora, so we can avoid this pointless scramble?
> 
> What about to have F33 keys right now, when the fresh F31 branch is out?
> 

+1. Go ahead and make the f33 keys when we branch for f31. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-gpg-keys not updated yet again

[Dusty Mabe]

On 8/22/19 12:58 PM, Kevin Fenzi wrote:
> On 8/21/19 9:27 AM, Dusty Mabe wrote:
>>
>>
>> On 8/19/19 6:59 AM, Pavel Raiskup wrote:
>>> On Monday, August 19, 2019 10:50:52 AM CEST Zbigniew Jędrzejewski-Szmek 
>>> wrote:
>>>> Can we *please* send out the FN+1 and FN+2 keys a month before branching,
>>>> to *all* releases of Fedora, so we can avoid this pointless scramble?
>>>
>>> What about to have F33 keys right now, when the fresh F31 branch is out?
>>>
>>
>> +1. Go ahead and make the f33 keys when we branch for f31. 
> 
> I don't see how this helps any. I agree we should push out the f33 keys
> before next branching, but why now?
> 

For me it solves any "timing" issues. We often get into a state where we're
trying to upgrade to something that is signed with a key we don't have yet.

With ostree we hit this every time we branch. Here is where a user hit it this
time: 
https://discussion.fedoraproject.org/t/unable-to-update-gpg-signatures-found-but-none-are-in-trusted-keyring/2703/3?u=dustymabe

There could be other problems that won't be solved but if we get the key out
now for the next release we'll at least solve any races and problems like this.

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: 'showme' RPM dependency visualizer (was: Minimization Objective report)

[Dusty Mabe]

On 8/23/19 6:35 AM, Dominik 'Rathann' Mierzejewski wrote:
> Hi, Adam.
> 
> On Wednesday, 21 August 2019 at 15:41, Adam Samalik wrote:
> [...]
>> == Toolbox ==
>>
>> The 'showme' tool [3] for visualising and inspecting RPM dependencies
>> now supports weak dependencies and a package list output.
> 
> I didn't have a chance to tell you this at Flock, but could you rename
> the binary to something like rpm-showme? Plain showme is very generic
> and unsuitable for such a specific tool.
> 

I agree. It also means people are less likely to "discover" the tool and
must be told about it or otherwise find it through indirect searches.

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Help update Hugo

[Dusty Mabe]

On 8/22/19 12:46 AM, Robert-André Mauchin wrote:
> Hello,
> 
> Feel free to help review these packages needed to update Hugo:
> 

Thanks for the effort here Robert-André. I might be able to help
with a few of these since I use Hugo. Will let you know next week.

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [atomic-announce] Fedora Atomic 29 EOL date?

[Dusty Mabe]

On 9/10/19 10:18 PM, Feilong Wang wrote:
> Hi Dusty,
> 
> Now Spyros and I are trying to ask for support in Ignition for multi part 
> MIME, see https://github.com/coreos/ignition/issues/849 It would be nice if 
> we can get your review and support. Thanks.

Any chance you could drop by #fedora-coreos on freenode IRC and we can discuss?

We do have a meeting today in #fedora-meeting-1 at 16:30 UTC. We could discuss 
with
the broader group then.

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Team Weekly Update

[Dusty Mabe]

On 9/27/19 9:18 AM, Aoife Moloney wrote:
> Hi everyone,
> 
> 
> I’d like to introduce myself first, my name is Aoife Moloney and I recently 
> started with the Community Platform Engineering (CPE) team. My role within 
> this team is going to be a hybrid role of a Product Owner / Project Manager.
> 
> As part of that, I want to send a weekly update to the lists to give an 
> insight into what the CPE team have worked on over the past week or so. This 
> will also be mirrored as a higher level blog to give maximum visibility.
> 
> We, as a team, welcome your input and comments and please do let us know how 
> we can improve this community facing information segment!
> 
> As you know, the CPE team looks after interests in both Fedora and CentOS, so 
> this update is also going to include work done on areas that are not your 
> Community, but for transparency, we are including it :)

Hi Aoife, Great to virtually meet you!

I think this report is great! Thank you so much for sending it and for
committing to doing so in the future!

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement: 29.20191001.0

[Dusty Mabe]

On 10/2/19 5:25 PM, nore...@fedoraproject.org wrote:
> 
> A new Fedora Atomic Host update is available via an OSTree update:
> 
> Version: 29.20191001.0
> Commit(x86_64): 
> 15b8a10f8b587c2a037a592806dc04e9cdf6ab1c73c6e49fdaacab1b1174b9ab
> Commit(aarch64): 
> 2b83282e976249b8e1910a7292379753b006851078e9bcea279ff3b6483ee602
> Commit(ppc64le): 
> 7ed4f0395e22000ffe372132c791a8dded291063d5c184e2470dde13c0eb3ba2
> 
> 
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
> 
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
> 
> Corresponding image media for new installations can be downloaded from:
> 
> https://getfedora.org/en/atomic/download/
> 
> Alternatively, image artifacts can be found at the following links:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0.aarch64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0.aarch64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20191001.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0.ppc64le.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0.ppc64le.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20191001.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0.x86_64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0.x86_64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191001.0.x86_64.vagrant-libvirt.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191001.0.x86_64.vagrant-virtualbox.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20191001.0.iso
> 
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20191001.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20191001.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20191001.0-x86_64-CHECKSUM
> 
> For direct download, the "latest" targets are always available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest
> https://getfedora.org/atomic_raw_x86_64_latest
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest
> 
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest
> https://getfedora.org/atomic_raw_aarch64_latest
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest
> 
> ppc64le:
> https://getfedora.org/atomic_qcow2_ppc64le_latest
> https://getfedora.org/atomic_raw_ppc64le_latest
> https://getfedora.org/atomic_dvd_ostree_ppc64le_latest
> 
> Filename fetching URLs are available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest_filename
> https://getfedora.org/atomic_raw_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename
> 
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest_filename
> https://getfedora.org/atomic_raw_aarch64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename
> 

Fedora Atomic Host Nearing End Of Life

[Dusty Mabe]

This content also exists at: 
https://www.projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/

Last year we [introduced the plans for Fedora CoreOS] [1] including that 
Fedora CoreOS would be the successor to Fedora Atomic Host and Container
Linux (from CoreOS Inc.). As part of that succession plan we decided that
Fedora 29 Atomic Host would be the last stream of Fedora Atomic Host to be
released.

Fedora 29 Atomic Host has served us well, but with Fedora 29 End of
Life coming soon [2], so will the last release of Fedora 29 Atomic Host.
The next release of Fedora 29 Atomic Host (in the next few weeks) will be
the last two-week release. It will contain all of the latest content
from Fedora 29. After that release, Fedora 29, and Fedora 29 Atomic
Host will no longer receive any updates.

Please try out the Fedora CoreOS preview to help us get it towards
stable. Documentation and download links can be found at 
https://getfedora.org/coreos/

The Atomic Host Team

[1] https://fedoramagazine.org/announcing-fedora-coreos/
[2] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VUK3CJ5LO4ROUH3JTCDVHYAVVYAOCU62/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Atomic Host Nearing End Of Life

[Dusty Mabe]

On 11/25/19 11:41 AM, Normand wrote:
> 
> 
> On 11/21/19 11:33 PM, Dusty Mabe wrote:
>> This content also exists at: 
>> https://www.projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/
>>
>> Last year we [introduced the plans for Fedora CoreOS] [1] including that
>> Fedora CoreOS would be the successor to Fedora Atomic Host and Container
>> Linux (from CoreOS Inc.). As part of that succession plan we decided that
>> Fedora 29 Atomic Host would be the last stream of Fedora Atomic Host to be
>> released.
>>
>> Fedora 29 Atomic Host has served us well, but with Fedora 29 End of
>> Life coming soon [2], so will the last release of Fedora 29 Atomic Host.
>> The next release of Fedora 29 Atomic Host (in the next few weeks) will be
>> the last two-week release. It will contain all of the latest content
>> from Fedora 29. After that release, Fedora 29, and Fedora 29 Atomic
>> Host will no longer receive any updates.
>>
>> Please try out the Fedora CoreOS preview to help us get it towards
>> stable. Documentation and download links can be found at 
>> https://getfedora.org/coreos/
>>
>> The Atomic Host Team
>>
>> [1] https://fedoramagazine.org/announcing-fedora-coreos/
>> [2] 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VUK3CJ5LO4ROUH3JTCDVHYAVVYAOCU62/
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
> 
> 
> Thanks for the info,
> 
> But what about arches that are not x86_64 ?
> Where could we found for exemple the ppc64le coreos replacement of 
> Atomic Host ? Is there already a web page to retrieve them ?
> 

Hi Normand,

Thank you for bringing this up. You have indeed pointed out a gap in what we're 
currently
delivering with Fedora CoreOS preview and what we were delivering with Atomic 
Host. The good
news is that we have done enablement work to allow for Fedora CoreOS to be run 
on other
platforms. The bad news is that we don't currently run our build infrastructure 
in an environment
that has other architectures available.

So while you can build it yourself today, there is currently no where to 
download it from the Fedora
website. I have added Jakub Cajka who was working on getting some space to host 
unofficial builds of
Fedora CoreOS for other architectures for now. I'll also link you to our open 
issues where we're working
through our strategy for delivering multi-arch FCOS:

- https://github.com/coreos/fedora-coreos-tracker/issues/262
- https://pagure.io/fedora-infrastructure/issue/8370

- Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

new maintainer for tmuxinator

[Dusty Mabe]

It was orphaned recently. Anybody care to pick it up? :) 

https://src.fedoraproject.org/rpms/tmuxinator

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do with simple-koji-ci?

[Dusty Mabe]

On 2/7/20 9:30 AM, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> I while back I wrote a small service named simple-koji-ci, which reacts to
> every pull-request opened on dist-git and fires a (scratch) build of the 
> package
> with the proposed changes merged, and report the outcome as a "flag" to the
> pull-request.
> This is a very simple service, so simple that it has some issues, including 
> the
> fact that it uses the default mock configuration to build the SRPM for the
> scratch build. This can break the SRPM generation in a few cases.
> 
> This is the very first service we have had triggering of PRs on dist-git and
> giving some CI feeling/taste to our workflow.
> Since then, the CI pipeline managed by the Fedora CI SIG folks has appeared, 
> is
> running and is also doing a scratch build like simple-koji-ci and then some 
> more
> testing.
> 
> simple-koji-ci has been running in the openstack instance hosted by the Fedora
> Infrastructure. However, this openstack is being decommissioned and 
> applications
> running there are being asked to find another place to run, an option being
> openshift.
> 
> I'd like to ask for your input about this service. Is it worth keeping? Is it
> duplicating what the CI pipeline does?
> Is someone interested in working on it?

I like having it. It's a direct link to a koji scratch build. I think the CI 
pipeline
does a koji scratch build too but you have to dig through logs to find the 
links. Also,
does the CI pipeline run if you don't have any tests defined?

> 
> If this service is deemed important enough, I don't mind moving it to 
> openshift
> but in all honestly, what I would prefer would be to help someone move it to
> openshift.
> 
> 
> Looking forward to read your thoughts,
> 
> Thanks,
> Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vague proposal: ship prebuilt initramfs images

[Dusty Mabe]

On 1/20/20 7:57 PM, Matthew Garrett wrote:

> 
> I've been thinking about ways to solve this for a while, and I'm coming 
> to the conclusion that the best plan is probably to just ship pre-built 
> initramfs images. I can think of three main reasons to want to use 
> system-specific images:

For what it's worth, this is what is done for OSTree based systems (Fedora 
Atomic
Host, Fedora CoreOS, Fedora Silverblue). There is an option for the user to 
generate
an initramfs client side, but I don't think it's used very much at all.

I know in the case of OSTree based systems you are shipping more of an image 
than a
case like Fedora Server where you are assembling a new system from a set of 
defined
RPMs, but it's at least a data point.

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

co-maintainer wanted for fuse-sshfs in EPEL8

[Dusty Mabe]

The current maintainer of fuse-sshfs is looking for a co-maintainer for it
in epel8. It's currently not in EPEL 8 so if you go from RHEL or CentOS 7->8
you'll lose it. I have users of vagrant-sshfs who would like to have it there.

https://bugzilla.redhat.com/show_bug.cgi?id=1758884#c4

Anybody interested?

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: co-maintainer wanted for fuse-sshfs in EPEL8

[Dusty Mabe]

Thanks Vascom,

I'm not the maintainer so I can't add you, but I'll copy the
maintainer here as well, just to see if he'll see it. In case he
doesn't can you reply to the comment over in the BZ as well? See 
https://bugzilla.redhat.com/show_bug.cgi?id=1758884#c4

When we get you added as a co-maintainer we'll then need
to add a epel8 branch and build against it.

Thanks so much!
Dusty

On 3/8/20 12:33 PM, Vascom wrote:
> You can add me as comaintainer.
> FAS name: vascom
> 
> вс, 8 мар. 2020 г., 19:32 Dusty Mabe  <mailto:du...@dustymabe.com>>:
> 
> The current maintainer of fuse-sshfs is looking for a co-maintainer for it
> in epel8. It's currently not in EPEL 8 so if you go from RHEL or CentOS 
> 7->8
> you'll lose it. I have users of vagrant-sshfs who would like to have it 
> there.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1758884#c4
> 
> Anybody interested?
> 
> Dusty
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> <mailto:devel-le...@lists.fedoraproject.org>
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Should logrotate timer be enabled by default on all installations?

[Dusty Mabe]

On 3/18/20 8:04 AM, Kamil Dudka wrote:
> logrotate is a utility designed to simplify the administration of log files 
> on 
> a system which generates a lot of log files.  It used to be triggered by 
> cron.  
> The cron hook was unconditionally installed with logrotate but it took effect 
> only if a cron daemon was installed.
> 
> Starting with Fedora 30, logrotate is triggered by a systemd timer instead.  
> In order to make updates smoother, the timer was enabled on updates in case
> a cron daemon was configured on the system.
> 
> The timer is currently not enabled on fresh installs to avoid surprises (such 
> as data lost) on systems where logrotate is installed but not actually used.  
> logrotate can also be triggered independently of systemd/cron and can be even 
> run by non-privileged users to rotate logs they have access to.
> 
> Some people think that the logrotate timer should be enabled by default on 
> all 
> systems where the logrotate package is installed:
> 
> https://bugzilla.redhat.com/1655153#c4
> 
> Do you think it would be a good idea?

I chimed in in the ticket too, but +1 from me.

I guess it would be worth analyzing the problem space a bit:

- in the past how many people do we think had logrotate installed and not cron?
- what are the worst case scenarios if logrotate.timer defaults to off?
- what are the worst case scenarios if logrotate.time defaults to on?

Dusty

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Emerging editions, Fedora 32 Beta, and bureaucracy

[Dusty Mabe]

On 3/17/20 2:01 PM, Adam Williamson wrote:

Hey Adam,



> 
> 3) CoreOS - CoreOS is just a *whole* other thing. It is not built like
> the rest of Fedora at all. It's not built as Pungi composes, whatever
> compose process it does have doesn't run alongside our other compose
> processes or output to the same locations, it's like a whole other
> product. It also doesn't seem to be terribly well documented (I can't
> find any detail on the wiki, docs sites, or any of the git repos I
> happen to know of) or even introspectable - for instance, ISO locations
> look like
> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200223.3.0/x86_64/fedora-coreos-31.20200223.3.0-live.x86_64.iso
> , but if you try and browse around that tree by visiting URLs like
> https://builds.coreos.fedoraproject.org/prod/streams/ , you just
> get 'Access Denied'. So if the process appears to have broken down and
> some poor monkey like me is left trying to help people figure out where
> they can get a 'Fedora CoreOS 32' image to try - it isn't very easy.
> Right now I simply have no clue if there is something you could
> reasonably call 'Fedora CoreOS 32 Beta' or a decent analogue of it.
 

You have reasonable points here. I do agree that the current state of 
integration
between Fedora CoreOS and the rest of Fedora is not quite complete. Part of the
reason for this is that we've been working hard on building Fedora CoreOS from
the ground up and getting it out the door. There are two things here worth being
explicit about:

1. Fedora CoreOS is today not composed by pungi on Fedora infra. It is composed 
   using coreos-assembler[1] in CentOS CI. I think this fundamental difference
   is the root to a lot of the mystery here surrounding FCOS. People integrated
   into Fedora processes are familiar with pungi and how it works. OTOH, I'm 
   sure not many of us are familiar with coreos-assembler.
   
2. Fedora CoreOS follows a rolling release model, where by design, we don't want
   people to care about whether they're on f31 or f32 (at least in principle).
   For FCOS, the f32 update just goes out like any other update when we're ready
   to do the cutover. Thus, sentences like "Fedora CoreOS 32" don't have quite
   the same meaning as for e.g. Workstation or Server. That said, Fedora CoreOS
   does have more streams than just stable and testing, and one of those streams
   should be $((N+1))-based. So we definitely could have some 
marketing/banners/whatever
   to point people at. Right now there is not yet a F32 based coreos, but there
   will be soon as part of our `next` stream [2].

That said, we know there is work to do to make things better understood and more
predictable from the rest of Fedora's point of view. Note that there was a lot 
of
hard work to integrate and participate in more Fedora processes as Fedora Atomic
Host matured. Know that this work will come as we finish building out the more
foundational pieces of Fedora CoreOS. We have opened a discussion ticket [3] for
this in our issue tracker, which is where our meeting topics get sourced from 
and
our discussions generally take place.

[1] https://github.com/coreos/coreos-assembler
[2] https://github.com/coreos/fedora-coreos-tracker/issues/283
[3] https://github.com/coreos/fedora-coreos-tracker/issues/426.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

September Fedora CoreOS update for the Fedora Council

[Dusty Mabe]

The Fedora CoreOS working group periodically gives status updates to the
Fedora Council. Since we compiled this list I figured it would be nice to
share more widely:

- Rebased the `next` stream to Fedora 33
- https://github.com/coreos/fedora-coreos-tracker/issues/611
- Added better afterburn support and image artifacts for IBM Cloud
- 
https://github.com/coreos/fedora-coreos-tracker/issues/277#issuecomment-678677137
- The bootupd (Distribution-independent updates for bootloaders) project exists
- https://github.com/coreos/bootupd/
- Migrated to from podman 1.x to 2.x
- https://github.com/coreos/fedora-coreos-tracker/issues/575
- Stepped up efforts to make package layering more reliable
- https://github.com/coreos/fedora-coreos-tracker/issues/400
- Upstream projects documentation
- See "Projects documentation" subsections on our docs site:
- https://docs.fedoraproject.org/en-US/fedora-coreos/
- New rpm-ostree release with:
- compatibility for rpmdb sqlite migration
- prep work for better package layering support
- https://github.com/coreos/rpm-ostree/releases/tag/v2020.5
- New Zincati release with plenty of new metrics exposed
- https://github.com/coreos/zincati/releases/tag/v0.0.13
- Support for root-on-LUKS using Clevis pinning
- https://github.com/coreos/fedora-coreos-config/pull/609
- New console-login-helper-messages releases with various bug fixes and 
improvements
- Notably, support for displaying complex networking devices and devices 
with custom names:
- 
https://github.com/coreos/console-login-helper-messages/releases/tag/v0.19

Originally posted at:
https://github.com/coreos/fedora-coreos-tracker/issues/608#issuecomment-705168980
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 beta: where are my Rust packages?

[Dusty Mabe]

On 10/12/20 9:24 AM, Fabio Valentini wrote:
> On Mon, Oct 12, 2020 at 9:15 AM Artur Frenszek-Iwicki
>  wrote:
>>
>> I wrote to Igor a week ago, but it seems he's away currently, as I didn't 
>> get an answer yet.
>>
>> Do you know of some document that describes how to "go through Igor's whole 
>> weird rust side tag build procedure"? Or, if it's not too complicated, would 
>> you mind explaining it?
> 
> Here's the "documentation" for the weird procedure:
> https://gist.github.com/ignatenkobrain/f2529a3f9e34848fa63587db94089a0f
> 
> Beware that the shell commands expect to be run inside fish, not bash,
> and it's also weird with respect to requesting branches in PDC without
> corresponding git branches ... etc.
> 

I adapted that sometime back. Here's what I've been using recently:


https://dustymabe.fedorapeople.org/rustbuild.sh
https://dustymabe.fedorapeople.org/rust-buildroot.py

Once you download those into the same directory then you can use them.

Assuming you've already done a `fedpkg build` for rawide you can then build
against f33 like so:

# cd /path/to/distgit/folder/
# git checkout master && git pull
# /path/to/rustbuild.sh 33

Dusty  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

[Dusty Mabe]

On 10/1/20 8:20 AM, Peter Robinson wrote:
>> Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
> (rpm)ostree variants are Fedora variants - please don't using phrasing 
> implying otherwise.
> IOW you just say: *all* Fedora variants use NetworkManager.
 They are not the same. Regular Fedora is considerably more
 customizable post-installation than OSTree-based variants. That's why
 I made that point.
>>>
>>> "All Fedora variants, both with ostree and without..." maybe? OSTree-based
>>> variants are also "regular Fedora".
>>>
>>
>> I would only even remotely consider agreeing with that premise for
>> Silverblue. Neither Fedora CoreOS nor Fedora IoT qualify for that, in
>> my view, since they completely sidestep the normal release engineering
> 
> IoT is *NOT* side stepping the normal release engineering process,
> we're using exactly the same process, it just runs independently, just
> cloud cloud and container images do nightlies post release.

Fedora CoreOS does differ here. We use a build pipeline that runs inside of
Jenkins on top of OpenShift. All it's doing in the background is running
coreos-assembler, which anyone can easily do on their laptop. One of the
guiding principles when we first started was we wanted it to be dead simple
for anyone to develop and build FCOS locally so we pursued this path.

https://github.com/coreos/coreos-assembler

> 
>> process, don't use the same repositories, and have the power to
>> include and exclude packages from the total available package set at
>> their leisure.
> 
> Fedora IoT uses the same repositories, we don't have seprate, we do
> have an overrides repo so we can get fixes quicker.

Same for Fedora CoreOS. We use the exact same RPMs built by release engineering
and we pull from the same repositories to seed our pipelines but we do have a
different cadence for releases (i.e. bake time) and the flexibility to pin
or fast-track packages based on needs.

> 
> Matthew has expressed interest in *any* spin to be able to release
> whenever they are ready to enable them to release on a schedule that
> suits them, IoT is being uses as the proving ground for that. It
> doesn't mean we can pull in whatever we want and have different
> repositories. Please get your facts correct!
> 
>> There is no expectation with those variants that anything you do will
>> necessarily show up there. Heck, Fedora CoreOS is reverting a
>> system-wide change in its variant (SQLite rpmdb), and had previously
>> also reverted another one (cgroup v2). The merits of those changes
>> aside, this makes the experience materially different than everything
>> else we have.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

[Dusty Mabe]

On 10/1/20 12:00 AM, Joe Doss wrote:
> On 9/30/20 7:14 PM, Colin Walters wrote:
>> That's not true, you can `rpm-ostree override remove`.  It'd still be
>> there in the ostree repository on disk, but you don't see it in the
>> "deployment" (what you actually boot into).  Few people care about
>> disk space that much, and if you do you can do custom builds.
> 
> ...but can we can do that and will updates to FCOS work after? I am 
> pretty sure currently the answer is no, unless I don't fully understand 
> the impacts of https://github.com/coreos/fedora-coreos-tracker/issues/400

You can `rpm-ostree override remove` without making upgrades less reliable,
assuming you don't remove a core component. The less reliable part comes when
you package layer a new package on top that wasn't in the base. We're fixing
that issue very soon though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Testing out container runtimes in F33

[Dusty Mabe]

If you're already on Fedora 33 would you please help us test out the pending 
updates
to our container runtimes and give a +1 or -1 in the bodhi update?

podman and friends:
- https://bodhi.fedoraproject.org/updates/FEDORA-2020-7b6058fec9
- sudo dnf upgrade --advisory FEDORA-2020-7b6058fec9

moby-engine (docker):
- https://bodhi.fedoraproject.org/updates/FEDORA-2020-1c86f64265
- sudo dnf upgrade --advisory FEDORA-2020-1c86f64265


Thanks!
Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

New CoreOS Assembler release v0.8.1

[Dusty Mabe]

https://github.com/coreos/coreos-assembler/releases/tag/v0.8.1

Some highlights for this release:

- Many UX improvements to `cosa run`
- A lot of work around enhancing our support for GCP image uploads and 
manipulations.
- Add support for offline installs
- More multi-arch fixes and improvements
- Support installed tests in `/usr/lib/coreos-assembler/kola`
- There are now two new commands for making it easier to iterate faster
- `cosa build-fast` and `cosa buildinitramfs-fast`. See their help output 
for more information.

And of course many more fixes and features! Thanks to all the contributors!

```
Ben Howard  (1):
  2a92600a Use shutil.move over os.rename in python code.

Benjamin Gilbert  (1):
  5a07e8a5 mantle: bump Ignition to 2.3.0

Colin Walters  (47):
  3d51185e qemu: Use a single temporary directory
  9aa2d390 qemu: Unlink non-multipath/nbd disks
  dd883aa7 devshell: Print serial console as status line, dump when 
interrupted
  8480daf5 cmdlib: Don't dump serial console to stdout
  087ff23f installer: Inject stamp file 
/etc/coreos-legacy-installer-initramfs
  42773b9c qemu: Ensure tmpdir is allocated for swtpm
  3094bfbd devshell: More output validation
  16f1c556 create_disk: Use ostree admin init-fs --modern
  e89b75d3 qemu: Propagate errors from disk attachment
  5a3a4645 devshell: Don't print error on EOF from serial console
  574b6bed mantle/qemu: Set a short hostname
  95c3c8ea Add qemu API to stream journal, use it in devshell
  6b5b86f4 installer: More code cleanup
  e0841351 testiso: Print which message we were waiting for if we hit EOF
  f2f7af8f testiso: Rename --console to --debug and skip initramfs failures
  d5fe653d testiso: Show which scenario failed on error
  66807dfc upload-oscontainer: New command
  494d99e8 kola: Write ignition-virtio-dump.txt to test dir
  45807fb7 Add cosa supermin-shell
  6724a4c1 installer: Refactor initramfs code
  44bdfbbc installer: Use consistent variable to refer to built initramfs
  afeb3c3f mantle: Build binaries in parallel
  e1d5c2cc kola: Support distros and tags in external test metadata
  0e5118e1 kola: Add option to configure RAM
  e54c5268 runc: New command
  1fef2340 buildinitramfs-fast: New command to iterate on initramfs quickly
  dc13aced buildextend-live: Squash unused variable
  04f94bfe Revert "mantle: Build binaries in parallel"
  71518abc installer: Put rootfs on ISO
  583f7f1f kola: Avoid losing "external" tag
  df6fa87b kola: Support loading tests from 
/usr/lib/coreos-assembler/tests/kola
  30a93de1 qemu: IgnoreOnIsolate=true for journal streaming
  e3905fd2 create_disk: Add known UUIDs for /boot and /root
  43c274a8 testiso: Gather logs
  629a22e3 mantle: Remove setenforce 1 by default
  ca6cfed4 cmdlib: Don't hardcode manifest path in overrides
  ca3c5c3e kola: Add RHCOS LUKS upgrade test
  4fbc3c7d testiso: Also capture initramfs virtio dumps
  e0846677 kola: Replace download code with executing coreos-installer
  919bd067 cmdlib: Stop parsing rojig/license
  26a1cc25 mantle: Move the FCOS stream URL from kola into mantle
  419efd20 Remove dead code relating to detecting Ignition version
  8003edea testiso: Fix use of global `outputDir`
  4f2a1e26 kola: Add --no-net flag
  021b6c8a supermin-shell: Support passing through qemu arguments
  ca97e50c create_disk: Ensure filesystem journal on rootfs is clean
  4c8d41f3 osmet-pack: Mount RHCOS LUKS rootfs

Dusty Mabe  (20):
  6df34a21 mantle: bump google.golang.org/api library to latest
  a11197f2 mantle/ore: glcoud: add --create-image option to upload.go
  02653cad cosalib/gcp: remove unused argument
  91297ff2 mantle/ore: gcloud: fix error detection, add some error checking
  d9c90cec mantle/ore: gcloud: add ability to attach license to image
  74787089 mantle/ore: gcloud: fix --image arg for deprecate-image
  f0427bdb mantle: switch to v0.alpha for gcloud compute API
  6d0ce985 mantle/ore: add ore gcloud update-image
  c5e108b6 cosalib/gcp: attach to image family in separate API call
  a1312708 mantle/ore: gcloud: fix error detection for deprecate-image
  4dedce33 mantle/platform: gcloud: add new getImageAPIEndpoint func
  92efaf05 mantle/platform: gcloud: use API endpoint for replacement in 
DeprecateImage
  0cd1771c mantle/platform: gcloud: enhance api.ListImages to filter by 
image family
  d27f297f mantle/ore: gcloud: add promote-image command
  f7eebc17 cmd-kola: also detect --platform=
  a42a6b0d cosalib/gcp: Add more gcp information to meta.json
  b18d76a5 cosalib/gcp: shchema: make gcp image project optional
  6c0c1851 kola: don't error if external tests directory doesn't exist
  df161488 cosalib/gcp: pass the log level to ore
  560c2dc6 mantle/ore: gcloud: support speci

Fedora CoreOS rebasing to Fedora 32: known issues; upcoming test day

[Dusty Mabe]

  
  
Today we’ve released the first Fedora
  CoreOS testing release based on Fedora 32. We expect
  that this release will promote to the stable channel
  in two weeks, on the usual schedule.
  New features include:
  
Support for the Ignition
3.1.0 config specification. Use this with the FCC
1.1.0 config specification. For more on the new
  features, see here.
It’s now easier
to enable SSH password authentication.
  
  There are a few quirks that may affect you:
  
New releases are signed with the Fedora 32 key. Accordingly,
  bare metal installations require coreos-installer 0.2.1 or
  greater. If you’re installing from media that matches the
  release you’re installing, you’ll already have the correct
  installer version.
Ignition currently fails to set SELinux labels on absolute
  symlinks. For more info and a workaround, see #512.
AWS instances may produce a kernel warning on shutdown. For
  more info, see #507.
  
  On Monday, June 8, we’ll be joining the Fedora QA team for a
Fedora CoreOS test day. Join us in #fedora-coreos on Freenode to
test Fedora CoreOS based on Fedora 32! For more information, see
the
  mailing list post.
  Thanks for helping us make Fedora CoreOS awesome!
  Dusty Mabe, for the Fedora CoreOS team

  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

rust-ipnetwork license change

[Dusty Mabe]

The license for rust-ipnetwork changed to "MIT or Apache-2.0" upstream [1].
This is reflected in the PR to distgit [2] to update to the latest version.

Dusty

[1] 
https://github.com/achanda/ipnetwork/commit/fa128680b51fbcf9c37db99f011c91204c4a3b0d
[2] https://src.fedoraproject.org/rpms/rust-ipnetwork/pull-request/1
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 in GCP

[Dusty Mabe]

On 11/19/20 11:10 PM, Matthew Miller wrote:
> On Thu, Nov 19, 2020 at 07:41:02PM -0500, Dusty Mabe wrote:
>> We have published an image into GCP for Fedora 33 (see [1]).
>> The details are:
>> image project: fedora-cloud
>> image name:fedora-cloud-base-gcp-33-1-2-x86-64
>> We're hoping to get this information added to the website at some point.
> 
> What's needed for that?
> 

Just someone with web dev skills to update the source for 
cloud.fedoraproject.org
to mention the information above.

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Dusty Mabe]

On 12/2/20 12:33 PM, Adam Williamson wrote:



> 
> Note that if you go to getfedora.org and click on CoreOS *right now*,
> it offers you a Fedora 32-based CoreOS. This is the kind of thing that
> is kinda fine so long as it's an Emerging Edition. It would *not*,
> IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
> months after Fedora 34 is "released", our "stable" CoreOS is still
> Fedora 33-based, that seems like the sort of thing that would look bad.
> 

There are three update streams for Fedora CoreOS. The "stable" stream is still
on Fedora 32 but has been receiving bi-weekly updates and should be switched 
over
to Fedora 33 soon (probably this week). The `next` and `testing` streams have 
been
updated to Fedora 33 and the `next` stream has been on F33 since early october. 
My
point here is that if you want Fedora 33 and you are a Fedora CoreOS user you 
can
easily adopt a stream that has it.

Why is our FCOS stable stream still on Fedora 32? Our FCOS instances have 
automatic
updates on by default and we're trying very hard to not break systems on 
upgrade and
require human intervention. There are several changes in Fedora 33, including 
migrating
to systemd-resolved and also systemd changing the default fallback hostname 
from `localhost`
to `fedora` that are causing issues for people and we're trying to consider 
these things first.

Ideally we update our stable stream closer to Fedora's actual release date but 
I think it's
important to maybe release Fedora CoreOS from the notion that it's tightly 
coupled with the
Fedora major release date for a few reasons:

- we have people follow update streams and systems update automatically
- it's more of a "rolling" release, with incremental feature improvements and 
major rebases periodically
- this is a departure from Atomic Host where you had to manually decide 
when to do a major rebase
- new features get added all the time, mid stream, so it's more of a 
continuous development model

Ultimately it's just a slightly different release/development model (adopted 
from CoreOS Container
Linux) than what Fedora has traditionally used, but I don't think that's any 
reason to treat it like
it's not Fedora. We should embrace it and see the positives along with the 
negatives of the model.

Dusty

P.S. For more info on our various update streams see: 
https://docs.fedoraproject.org/en-US/fedora-coreos/update-streams/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Dusty Mabe]

On 12/2/20 12:57 PM, Ben Cotton wrote:
> On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
>  wrote:
>>
>> So to boil this down into a representative question: when we are doing
>> the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
>> whether to release "Fedora CoreOS 34"?
>>
> This question is relevant to my interests.

That's fair. I think the answer to this question is that we need to consider
the way the Fedora CoreOS update streams/release model can play into this.
In short I think we'll all need to evolve a bit. It's just not going to be
the exact same as traditional Fedora major releases have been.

> 
> On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
>  wrote:
>>
>> Note that if you go to getfedora.org and click on CoreOS *right now*,
>> it offers you a Fedora 32-based CoreOS. This is the kind of thing that
>> is kinda fine so long as it's an Emerging Edition. It would *not*,
>> IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
>> months after Fedora 34 is "released", our "stable" CoreOS is still
>> Fedora 33-based, that seems like the sort of thing that would look bad.
> 
> I agree. I understand the reasoning, but I'd really like to see FCOS
> align with the rest of the schedule or at least develop a clear and
> succinct explanation of why it's delayed so that the public and the
> tech press can easily understand.

I 100% would like to get to a point where we rebase to the latest Fedora
major soon after release. As jlebon mentioned earlier this does mean working
harder to get ahead of the curve by adopting a rawhide development stream
(not exposed to users) and taking more part in the Changes process.

> 
> On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa  wrote:
>>
>> I would personally rather see Fedora CoreOS pulled *back* into the
>> fold more as an Edtion
> 
> From a program management perspective, I've largely closed my eyes and
> gone "la la la" when it comes to FCOS, in part because it is so
> separate from what we know as Fedora. Making FCOS work more like what
> we know as Fedora would certainly be helpful from my perspective, but
> at the same time there are technical challenges to that. And maybe
> what FCOS does from a distro-building standpoint is more like what we
> should move toward. Maybe not.

Yes. I think we should consider it with a slightly different perspective
than we do other editions, but I'm definitely not asking for a pass. Let's
work together to define the future.

> 
> In any case, part of the work to be done here, if the Change is
> approved, is for me to figure out how to include FCOS in some of the
> program management work.
> 
> I wonder if it would be better to target this for Fedora 35, with some
> of the work starting now. Given the work it took to get IoT into the
> fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
> feels pretty optimistic here.

I think that's reasonable, but maybe we can meet sooner to try to get some
answers to foundational questions answered so that we can be prepared to
be in better compliance for the Fedora 35 timeframe.

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

November Fedora CoreOS update for the Fedora Council

[Dusty Mabe]

The Fedora CoreOS working group periodically gives status updates to the
Fedora Council. Here's the update for this past month: 

 * Enablement work on getting the new LUKS path used in OKD
 * Informational fedora messages are now sent by the FCOS pipeline for 
integration with other services (e.g. openQA, AWS Marketplace)
 * OpenStack artifacts are now being tested on every pipeline build
 * The FCOS `testing` stream has been rebased to Fedora 33
 * Enablement work for Full disk RAID support (will land soon)
 * Reordered disk partitions in the OS image to simplify repartitioning 
with Ignition configs
 * https://github.com/coreos/fedora-coreos-tracker/issues/669
 * Added empty BIOS-BOOT partition to 4Kn image for consistency
 * Ignition [v2.8.0](https://github.com/coreos/ignition/releases/tag/v2.8.0)
 * Support unmasking systemd units
 * Zincati [v0.0.14](https://github.com/coreos/zincati/releases/tag/v0.0.14)
 * Deadend status is now shown in MOTD
 * Added documentation for Networking Configuration
 * 
https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-network-configuration/
 * Design discussions on supporting kargs via Ignition
 * 
https://github.com/coreos/fedora-coreos-tracker/issues/318#issuecomment-724234961

Sorry for the markdown formatting. You can view it with slightly better 
formatting
at the original location, which was posted at:

https://github.com/coreos/fedora-coreos-tracker/issues/688#issuecomment-737463005

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 in GCP

[Dusty Mabe]

We have published an image into GCP for Fedora 33 (see [1]).

The details are:

image project: fedora-cloud
image name:fedora-cloud-base-gcp-33-1-2-x86-64

We're hoping to get this information added to the website at some point.

Dusty

[1] https://pagure.io/cloud-sig/issue/318
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

October Fedora CoreOS update for the Fedora Council

[Dusty Mabe]

The Fedora CoreOS working group periodically gives status updates to the
Fedora Council. Since we compiled this list I figured it would be nice to
share more widely:

- Shipped Fedora CoreOS based on Fedora 33 in the `next` stream
- [migrated existing systems to 
systemd-resolved](https://github.com/coreos/fedora-coreos-tracker/issues/646) 
to match Fedora change
- Created the `fedora-repos-archive` subpackage and [added it to 
FCOS](https://github.com/coreos/fedora-coreos-config/pull/673)
- Enables [package layering to be more 
reliable](https://github.com/coreos/fedora-coreos-tracker/issues/400)
- Added [bootupd](https://github.com/coreos/fedora-coreos-config/pull/595) to 
Fedora CoreOS
- More context in [the tracker 
issue](https://github.com/coreos/fedora-coreos-tracker/issues/510)
- New Afterburn release 
([v4.5.3](https://github.com/coreos/afterburn/releases/tag/v4.5.3)) with 
enhancements for VMware and OpenStack 
- Ignition spec 3.2.0/FCCT spec 1.2.0 stabilized
- LUKS support, partition resizing, user/group deletion
- part of Ignition 
[v2.7.0](https://github.com/coreos/ignition/releases/tag/v2.7.0) and FCCT 
[v0.7.0](https://github.com/coreos/fcct/releases/tag/v0.7.0).
- AWS CI tests are now passing reliably again
- switched instance type, still debugging a [kernel issue with Xen + kernel 
spectre/meltdown 
mitigations](https://github.com/coreos/fedora-coreos-tracker/issues/606)
- Patches to [systemd](https://github.com/systemd/systemd/pull/17149) and 
[dracut](https://github.com/dracutdevs/dracut/pull/959) for supporting 
Tang-pinned LUKS
- Added kexec-tools package to the host for [kdump 
support](https://github.com/coreos/fedora-coreos-tracker/issues/622)
- Delivered podman-plugins in the base layer
- previously had removed it because of dnsmasq but we [added it 
back](https://github.com/coreos/fedora-coreos-config/pull/693)
- Shipped [systemd-networkd as a subpackage in Fedora 
33](https://github.com/coreos/fedora-coreos-tracker/issues/610#issuecomment-707809280)

Sorry for the markdown formatting. You can view it with slightly better 
formatting
at the original location, which was posted at:
https://github.com/coreos/fedora-coreos-tracker/issues/650#issuecomment-718228610

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora CoreOS stable stream now rebased to Fedora 34

[Dusty Mabe]

Over the next two days we're rolling out the first Fedora 34 based
Fedora CoreOS into the `stable` stream. 
 
Some notable issues/configurations:

- Very old systems (Fedora 32 and earlier) may not be able to update [0]
- systemd-resolved is still enabled but not used yet [1]

Here are some highlights of recently added features in Fedora CoreOS:

- The `/boot` partition is now mounted read-only.
- This continues the work to protect more of the OS from accidental damage.
- It is now possible to configure boot disk RAID 1 mirroring via Ignition [2].
- Better introspection into the state of Zincati (the update agent) from 
`rpm-ostree status`.
- Better support for disk encryption.
- Initial (non-automatic) support for updating the bootloader. [3]

Here are some new features landing in the coming months:

- Support for specifying kernel arguments via Ignition [4].
- Move to cgroup v2 by default [5].
- DNF Count Me support for Fedora CoreOS [6].

Thanks to everyone who participated in the test day [7] and to everyone that
run the `testing` and `next` streams to help us identify and fix issues
before they get to `stable`.

Dusty Mabe, for the Fedora CoreOS team

[0] 
https://github.com/coreos/fedora-coreos-tracker/issues/749#issuecomment-843446996
[1] https://github.com/coreos/fedora-coreos-tracker/issues/834
[2] 
https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_reconfiguring_the_root_filesystem
[3] https://docs.fedoraproject.org/en-US/fedora-coreos/bootloader-updates/
[4] https://github.com/coreos/ignition/issues/1168
[5] https://github.com/coreos/fedora-coreos-tracker/issues/292
[6] https://github.com/coreos/fedora-coreos-tracker/issues/717
[7] https://testdays.fedoraproject.org/events/113
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 34 GCP image

[Dusty Mabe]

FYI - I published the Fedora 34 GCP image to the `fedora-cloud` project in GCP.

See https://pagure.io/cloud-sig/issue/328 for more details. 

Currently you do have to provide cloud-init userdata to the instance (via the 
user-data key).
This hopefully won't be the case once we include the newly added google compute 
enging config rpm.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re:  Advice on packaging azure-cli

[Dusty Mabe]

On 5/25/21 8:29 AM, Major Hayden wrote:
>  Hello there,
> 
> I'm eager to package Azure's CLI tools for Fedora that would allow users 
> to manage their Microsoft Azure cloud infrastructure. This would help 
> with CI/CD, information security, monitoring, and of course, deployments.

I don't have much feedback for you, but just wanted to say thank you for
working on this. It's so nice when we can just pull packages from our 
repos and just start using them. A lot of cloud providers have containers
these days for their CLI tools, but I'd prefer to use the CLI tool in
an environment I've customized, rather than a container which might be
built from an environment I'm unfamiliar with.

We have the AWS and OpenStack CLIs in Fedora. Are there others? Would be
nice to have ones for gcloud, ibmcloud, digitalocean, vultr, and others
packaged.

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re:  Advice on packaging azure-cli

[Dusty Mabe]

On 5/25/21 9:01 AM, Miro Hrončok wrote:
> On 25. 05. 21 14:29, Major Hayden wrote:

> 
> The culprit of trying to maintain them in one component is that they are 
> released independently. Maintaining various subpackages with different 
> versions 
> and release cycles from the same spec file is a huge PITA.
> 
> However, so is maintaining 100 packages. There is no clear win. I'd 
> personally 
> rather maintain the 100 packages with automatically generated build 
> dependencies, but I would not say it is a *should*.
> 
> Have a look at https://src.fedoraproject.org/rpms/pyproject-rpm-macros
> 

I'm not a sophisticated packager so please take my questions here in good faith:

Are the 100 individual packages are only useful in this one case (i.e. would 
anyone
else use them for anything)?

If not, and the 100 individual packages versus the one large package with lots 
of
spec file complexity are about the same effort wise, then...

Should we consider the overhead costs (storage, compute, accounting etc) for 
doing
100 small versus one large package? 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora CoreOS stable stream now rebased to Fedora 34

[Dusty Mabe]

On 5/20/21 12:13 PM, Ron Olson wrote:
> If I may, I think the issue is right there in the name: Fedora CoreOS. The 
> Fedora name brings some expectations and it seems CoreOS, by its nature, 
> can’t be at parity with the other Fedora flavors and that leads to confusion. 
> I can attest that I was surprised when I learned Fedora CoreOS didn’t support 
> cgroups v2 and that confused me; it’s Fedora, of course it would have the 
> latest-n-greatest.

One clarification here.. It does support cgroups v2, it's just not enabled by 
default. It's just a kernel parameter.

Specifically for cgroups v2, the default is changing here in the next month. So 
FCOS will default to cgroups v2.
We're trying to make sure users have a good experience. Docker users are a big 
part of that. Changing the default
before Docker supported cgroups v2 was really not an option for us at the time.

> 
> I used CoreOS before it bought by RH, and I could accept whatever limitations 
> it had because there were no expectations. Here’s a specialized distro that 
> does things in its own way.
> 
> I’m guessing this is laughably not possible, but I’m going to suggest anyway 
> that maybe it be renamed either back to simply “CoreOS” or something new like 
> “Bowler” or whatever that indicates that it is its own special thing and 
> expectations can be set accordingly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)

[Dusty Mabe]

On 6/2/21 5:28 AM, Peter Boy wrote:
> 
> 
> 
> very nicely put. According to Matthew and others cloud wg did virtually not 
> exist for more than a year, no meetings, silence on mailing list beyond 
> bi-weekly announcement of a „standing“ meeting nobody attended to, there was 
> discussion to „kill“ it, great reluctance on the side of Dusty in our meeting 
> March 3 to make any changes on the artefacts at all, new start of 2-weekly 
> meetings March 30, „months of conversation“ which spell down to 4 meetings in 
> 2 months, and then such a very fundamental change. Well, the wording may be a 
> bit offhand, but by no means farfetched.

We typically run meetings every two weeks, but that did stop happening when I 
was away earlier this year. There is some truth in here though.
It's very true that the cloud WG needs a leader. I'm mostly just trying to keep 
the lights on. I don't have significant amounts of time to
put into it. When people show up with ideas and are willing to execute on them 
I try not to get in the way assuming the change isn't vastly
fundamental.

> 
> And lest there be any misconception, Cloud WG may decide what or about what 
> they deem useful. That is not my business. But regarding the planned 
> discussion about cooperation and alignment of server and Cloud WG and 
> artifacts, I am "not amused" and can't really take it seriously anymore. 
> There are more serious and urgent tasks waiting for us.

Bear with me and try to assume good faith. When this was first brought up in 
the cloud WG meeting recently I did ask of the implications on
our pending talks to merge with Server. I thought it had been discussed in the 
Server WG first.

https://meetbot-raw.fedoraproject.org/teams/fedora_cloud_meeting/fedora_cloud_meeting.2021-05-11-15.58.log.txt
16:18:15  There is also the discussion of merging with the server WG 
- if we change to BTRFS does that inhibit that potential path for us (i.e. 
should we get server to buy in on the FS change too, or maybe they have 
already)?

But.. at the end of the day I'm mostly just trying to do the best I can with 
limited time. Maybe we can get everyone together to discuss all
the various options and the best path forward?

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)

[Dusty Mabe]

On 4/6/21 10:58 AM, Fabio Valentini wrote:
> On Tue, Apr 6, 2021 at 4:43 PM Colin Walters  wrote:
>>
>> Hi,
>>
>> On Tue, Apr 6, 2021, at 6:42 AM, Fabio Valentini wrote:
>>> Hi everybody,
>>>
>>> It's that time of the year again, and this time there's not that many
>>> downgrades to complain about (packages with "obvious" causes, like
>>> F34FTBFS, already excluded from the list).
>>>
>>> However, the list also includes some pretty important "critpath"
>>> packages (ostree (!), rpm-ostree, libuv, ...), which should probably
>>> be fixed before F34 is released. Shipping with old ostree packages
>>> OOTB seems like a bad idea, especially for the Editions that are built
>>> on top of it.
>>
>> Hi, thanks for raising this.  The two updates are
>> https://bodhi.fedoraproject.org/updates/FEDORA-2021-33f693d20d
>> https://bodhi.fedoraproject.org/updates/FEDORA-2021-971f672259
> 
> Thanks! It would probably be a good idea to request freeze exceptions
> for them sooner rather than later, so testing of the candidate images
> will be done with the new versions.
> 

The following two bugs have been proposed as FE:

- https://bugzilla.redhat.com/show_bug.cgi?id=1946727
- https://bugzilla.redhat.com/show_bug.cgi?id=1946731
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Thanks to everyone who participated in the FCOS 35 test day/week

[Dusty Mabe]

I'd like to say the test day/week has been a huge success. We had reported 
results from 15 participants and found the following issues/docs updates:

- FCOS with 5.14+ kernel fails to boot on xen instances
- https://github.com/coreos/fedora-coreos-tracker/issues/997
- kargs: interactive changes through editor always result in 'No changes'
- https://github.com/coreos/rpm-ostree/issues/3182
- provisioning/ibmcloud: a few updates
- https://github.com/coreos/fedora-coreos-docs/pull/334
- provisioning/gcp: Define not supported login methods for GCP
- https://github.com/coreos/fedora-coreos-docs/pull/333
- tutorial-services: Add Wants=network-online.target
- https://github.com/coreos/fedora-coreos-docs/pull/331
- os-extensions: fix yaml file for dns issue
- https://github.com/coreos/fedora-coreos-docs/pull/330
- Fix 404 link to DigitalOcean's droplet metadata
- https://github.com/coreos/fedora-coreos-docs/pull/328
- provisioning-vmware: fix explanation of govc argument limit
- https://github.com/coreos/fedora-coreos-docs/pull/327


#997 corresponds to an F35 blocker bug 
[BZ#2010058](https://bugzilla.redhat.com/show_bug.cgi?id=2010058) and prevented 
us from shipping a change to our `stable` stream that would have guaranteed 
breakage for some users. This also led us to expand our automated test coverage 
for this case in the future:

- kola-aws: also run on m4.large
- https://github.com/coreos/fedora-coreos-pipeline/pull/416

The full test day results page can be viewed at: 
https://testdays.fedoraproject.org/events/122

We do still have some platforms that weren't tested so feel free to execute 
those test cases!

Dusty Mabe
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CoreOS next stream rebased to Fedora Linux 35

[Dusty Mabe]

Hi all,

Fedora Linux 35 Beta was released today [1]. Our Fedora CoreOS `next` stream
has been migrated to Fedora Linux 35 content. Existing nodes on the `next`
stream will update as normal over the following days. Please test it out and
report any issues in our issue tracker [2].

Thank you to everyone helping find issues by running the `next` stream!

The Fedora CoreOS Team

[1] https://fedoramagazine.org/announcing-fedora-35-beta/
[2] https://github.com/coreos/fedora-coreos-tracker/issues
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CoreOS 64 bit ARM artifacts

[Dusty Mabe]

Hi all,

A few weeks ago we started shipping 64 bit ARM (aarch64) artifacts
for our Fedora CoreOS streams. The download page [1] has been
updated to show the new artifact downloads and you should be able to
retrieve aarch64 information from all relevant stream and release
metadata.

Please report any issues upstream in our issue tracker [2]!

The Fedora CoreOS Team

[1] 
https://getfedora.org/en/coreos/download?tab=metal_virtualized=stable=aarch64
[2] https://github.com/coreos/fedora-coreos-tracker/issues
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [CoreOS] Fedora CoreOS Community Video Meeting 2021-10-06

[Dusty Mabe]

On 10/5/21 5:53 PM, Dusty Mabe wrote:
> Hi All,
> 
> Tomorrow we will be holding a video meeting for the Fedora CoreOS community.
> 
> Harshal Patil will be joining us to give a brief overview of how Fedora 
> CoreOS is used
> for the e2e node tests in upstream Kubernetes. 
> https://github.com/coreos/fedora-coreos-tracker/issues/984
> 
> We'll also be discussing any meeting tickets and possibly revisit our list of 
> high level
> issues.
> 
> 
> Time: 16:30 UTC (same as normal) on Wednesday October 6th
> Location: https://meet.google.com/cgh-oxhd-axg (will be recorded)
> Agenda/Notes: https://hackmd.io/vMWlKGH5TAOsLKYiqce61Q


Thanks to everyone who attended! Here is a link to the meeting recording:

https://dustymabe.fedorapeople.org/meetings/2021-10-06_FCOS-Community-Meeting.mp4
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Self Introduction: Saqib Ali

[Dusty Mabe]

On 9/20/21 9:02 AM, Saqib Ali wrote:
> Hey everyone,
> 
> First post on this list :) I'm Saqib Ali and I'm a student at the University 
> of Toronto. I'm currently an intern at Red Hat on the CoreOS team. 
> I've been working with Fedora CoreOS and attended the last Flock to Fedora 
> (nice to see all the cool things people are working on). 
> I'm going to be co-maintaining 
> https://src.fedoraproject.org/rpms/console-login-helper-messages/ 
> 
> Thanks and nice to meet you!

Welcome Saqib. Thanks for working on and contributing to Fedora!

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CoreOS Community Video Meeting 2021-10-06

[Dusty Mabe]

Hi All,

Tomorrow we will be holding a video meeting for the Fedora CoreOS community.

Harshal Patil will be joining us to give a brief overview of how Fedora CoreOS 
is used
for the e2e node tests in upstream Kubernetes. 
https://github.com/coreos/fedora-coreos-tracker/issues/984

We'll also be discussing any meeting tickets and possibly revisit our list of 
high level
issues.


Time: 16:30 UTC (same as normal) on Wednesday October 6th
Location: https://meet.google.com/cgh-oxhd-axg (will be recorded)
Agenda/Notes: https://hackmd.io/vMWlKGH5TAOsLKYiqce61Q

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CoreOS Meeting Minutes 2021-11-17

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-17/fedora_coreos_meeting.2021-11-17-16.31.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-17/fedora_coreos_meeting.2021-11-17-16.31.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-17/fedora_coreos_meeting.2021-11-17-16.31.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:31:24 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-17/fedora_coreos_meeting.2021-11-17-16.31.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:31:28)

* Action items from last meeting  (dustymabe, 16:36:21)
  * jlebon filed
https://github.com/coreos/fedora-coreos-tracker/issues/1024
(jlebon, 16:36:48)

* During major version rebases, align FCOS testing with GA  (dustymabe,
  16:38:23)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1024
(dustymabe, 16:38:32)
  * we'll discuss this in january 2022 when the F35 rebase has landed in
our stable stream and any currently unknown issues have been fleshed
out  (dustymabe, 16:46:19)

* work items awaiting some action   (dustymabe, 16:47:22)
  * LINK:

https://github.com/coreos/fedora-coreos-tracker/issues?q=is%3Aissue+is%3Aopen+label%3Astatus%2Fpending-action
(dustymabe, 16:47:34)

* - call for topics  (dustymabe, 16:51:40)

* Make publicly accessible coreos-assembler builds for architectures !=
  x86_64  (dustymabe, 16:53:52)
  * LINK: https://github.com/coreos/coreos-assembler/issues/2470
(dustymabe, 16:53:57)
  * LINK: https://github.com/coreos/enhancements/pull/7 makes the OSBS
alignment much stronger  (walters, 16:57:30)
  * we'll investigate OSBS further to see if that solution can possibly
solve our needs here without too many contraints  (dustymabe,
17:05:17)

* open floor   (dustymabe, 17:05:52)

Meeting ended at 17:15:27 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (84)
* jlebon (25)
* zodbot (22)
* walters (12)
* travier[m] (11)
* davdunc (8)
* jdoss (6)
* lucab (3)
* jmarrero (2)
* nemric (1)
* miabbott (1)
* ravanelli (1)
* mnguyen_ (1)
* bgilbert (1)




Generated by `MeetBot`_ 0.3

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CoreOS streams rebasing to Fedora Linux 35

[Dusty Mabe]

Over the next few weeks we're rolling out Fedora Linux 35 to the
`testing` and `stable` streams of Fedora CoreOS. During the Fedora 35
development cycle we followed the Fedora Change process more closely [1]
in order to provide a smoother transition of incoming Fedora Changes.

Current known issues with recent kernels (F34 & F35):

- AWS `m6i` instances fail to boot [2]
- Some OKD [3] and Kubernetes [4] workloads cause kernel deadlock

Some highlights of recently added features:

- cgroups v2 is now the default [5]
- Ignition now supports setting/updating kernel arguments [6]
- DNF Count Me support was added and is now enabled by default [7].
- 64-bit ARM (aarch64) artifacts are now available [8]
- Raspberry Pi 4 install documentation is now available [9]
- systemd-resolved is now fully enabled [10]

Some new features landing in the coming months:

- Support for Virtualbox [11]
- Support for a minimal ISO image [12]
- Support for Nutanix [13]
- Switching to iptables-nft by default [14]

Thanks to everyone who participated in the test day [15] and to everyone that
follows the `testing` and `next` streams to help us identify and fix issues
before they get to `stable`.

Dusty Mabe, for the Fedora CoreOS team

[1] https://github.com/coreos/fedora-coreos-tracker/issues/856
[2] https://github.com/coreos/fedora-coreos-tracker/issues/1004
[3] https://github.com/coreos/fedora-coreos-tracker/issues/957
[4] https://github.com/coreos/fedora-coreos-tracker/issues/940
[5] https://github.com/coreos/fedora-coreos-tracker/issues/292
[6] https://github.com/coreos/ignition/issues/1168
[7] https://github.com/coreos/fedora-coreos-tracker/issues/717
[8] https://github.com/coreos/fedora-coreos-tracker/issues/13
[9] 
https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-raspberry-pi4/
[10] https://github.com/coreos/fedora-coreos-tracker/issues/834
[11] https://github.com/coreos/fedora-coreos-tracker/issues/1008
[12] https://github.com/coreos/fedora-coreos-tracker/issues/868
[13] https://github.com/coreos/fedora-coreos-tracker/issues/1007
[14] https://github.com/coreos/fedora-coreos-tracker/issues/676
[15] 
https://github.com/coreos/fedora-coreos-tracker/issues/973#issuecomment-947834145
















Over the next two days we're rolling out the first Fedora 34 based
Fedora CoreOS into the `stable` stream. 
 
Some notable issues/configurations:

- Very old systems (Fedora 32 and earlier) may not be able to update [0]
- systemd-resolved is still enabled but not used yet [1]

Here are some highlights of recently added features in Fedora CoreOS:

- The `/boot` partition is now mounted read-only.
- This continues the work to protect more of the OS from accidental damage.
- It is now possible to configure boot disk RAID 1 mirroring via Ignition [2].
- Better introspection into the state of Zincati (the update agent) from 
`rpm-ostree status`.
- Better support for disk encryption.
- Initial (non-automatic) support for updating the bootloader. [3]

Here are some new features landing in the coming months:

- Support for specifying kernel arguments via Ignition [4].
- Move to cgroup v2 by default [5].
- DNF Count Me support for Fedora CoreOS [6].

Thanks to everyone who participated in the test day [7] and to everyone that
run the `testing` and `next` streams to help us identify and fix issues
before they get to `stable`.

Dusty Mabe, for the Fedora CoreOS team

[0] 
https://github.com/coreos/fedora-coreos-tracker/issues/749#issuecomment-843446996
[1] https://github.com/coreos/fedora-coreos-tracker/issues/834
[2] 
https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_reconfiguring_the_root_filesystem
[3] https://docs.fedoraproject.org/en-US/fedora-coreos/bootloader-updates/
[4] https://github.com/coreos/ignition/issues/1168
[5] https://github.com/coreos/fedora-coreos-tracker/issues/292
[6] https://github.com/coreos/fedora-coreos-tracker/issues/717
[7] https://testdays.fedoraproject.org/events/113
___
CoreOS mailing list -- cor...@lists.fedoraproject.org
To unsubscribe send an email to coreos-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/cor...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CoreOS Meeting Minutes 2021-11-24

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-24/fedora_coreos_meeting.2021-11-24-16.28.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-24/fedora_coreos_meeting.2021-11-24-16.28.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-24/fedora_coreos_meeting.2021-11-24-16.28.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:28:50 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-24/fedora_coreos_meeting.2021-11-24-16.28.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:29:04)

* Action items from last meeting  (dustymabe, 16:35:24)

* Make publicly accessible coreos-assembler builds for architectures !=
  x86_64  (dustymabe, 16:36:18)
  * LINK: https://github.com/coreos/coreos-assembler/issues/2470
(dustymabe, 16:36:29)
  * AGREED: We will use our existing multi-arch-builders to build COSA
for all architectures and also find a way to push them to quay using
archful manifests so that a single tag in quay can be pulled for any
architecture we support.  (dustymabe, 16:50:24)

* m6i instances fail to boot - kernel crashlooping  (dustymabe,
  16:52:49)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1004
(dustymabe, 16:52:59)

* open floor   (dustymabe, 16:56:53)
  * LINK:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KQKCFXG4CTT6IGCGWAXIX5SLHFBFCEAI/
(walters, 16:57:58)
  * all streams of FCOS have now been rebased to Fedora Linux 35 content
(dustymabe, 16:59:10)
  * LINK: https://fedoraproject.org/wiki/Releases/36/ChangeSet
(dustymabe, 17:01:28)

Meeting ended at 17:13:43 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (96)
* jlebon (28)
* zodbot (21)
* davdunc (19)
* travier[m] (12)
* walters (8)
* ravanelli (8)
* copperi[m] (6)
* nemric (4)
* mnguyen (1)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora CoreOS Community Video Meeting 2021-11-02

[Dusty Mabe]

Correction in the subject: 2021-11-03

And in the Body: Time: 16:30 UTC (same as normal) on Wednesday November 3rd

On 11/2/21 10:19 PM, Dusty Mabe wrote:
> Hi All,
> 
> Tomorrow we will be holding a video meeting for the Fedora CoreOS community.
> 
> Colin Walters will be presenting on a new proposal for "CoreOS Layering".
> https://github.com/coreos/enhancements/pull/7
> 
> We'll also be discussing any meeting tickets and possibly revisit our list of 
> high level
> issues.
> 
> Time: 16:30 UTC (same as normal) on Wednesday October 6th
> Location: https://meet.google.com/igd-ekxw-nzi (will be recorded)
> Agenda/Notes: https://hackmd.io/5bdC2OLjQYmB5ErZ4AzpdA
> 
> Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CoreOS Community Video Meeting 2021-11-02

[Dusty Mabe]

Hi All,

Tomorrow we will be holding a video meeting for the Fedora CoreOS community.

Colin Walters will be presenting on a new proposal for "CoreOS Layering".
https://github.com/coreos/enhancements/pull/7

We'll also be discussing any meeting tickets and possibly revisit our list of 
high level
issues.

Time: 16:30 UTC (same as normal) on Wednesday October 6th
Location: https://meet.google.com/igd-ekxw-nzi (will be recorded)
Agenda/Notes: https://hackmd.io/5bdC2OLjQYmB5ErZ4AzpdA

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CoreOS Meeting Minutes 2021-10-27

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-10-27/fedora_coreos_meeting.2021-10-27-16.27.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-10-27/fedora_coreos_meeting.2021-10-27-16.27.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-10-27/fedora_coreos_meeting.2021-10-27-16.27.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:27:53 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-10-27/fedora_coreos_meeting.2021-10-27-16.27.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:27:59)

* Action items from last meeting  (dustymabe, 16:34:21)
  * ACTION: dustymabe to write docs for rpi4 including updating eeprom
(dustymabe, 16:34:53)

* F35: CHANGE: More flexible use of SSSD fast cache for local users
  (dustymabe, 16:35:17)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/875
(dustymabe, 16:35:23)
  * LINK:

https://github.com/coreos/fedora-coreos-tracker/issues/875#issuecomment-952867863
(dustymabe, 16:36:07)
  * the report by travier indicates we shouldn't have any issues with
the "More flexible use of SSSD fast cache for local users" change
(dustymabe, 16:38:01)

* Handle re-invocations of coreos-installer on a new disk  (dustymabe,
  16:38:22)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/976
(dustymabe, 16:38:27)
  * AGREED: we will look for multiple boot filesystems at the start and
end of the initramfs and fail if detected. we will add a stamp file
to the bootfs to ensure 1:1 binding between bootfs and rootfs.
(jlebon, 17:01:42)

* Open Floor  (dustymabe, 17:03:52)
  * reminder about the FCOS release process surrounding Major Fedora
Linux GA

https://github.com/coreos/fedora-coreos-tracker/blob/main/Design.md#major-fedora-version-rebases
(dustymabe, 17:07:15)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/998 is
so cool  (jdoss, 17:10:35)
  * we will have a video meeting next week Nov 3rd.   (dustymabe,
17:19:38)
  * the fedora coreos meetings stick with UTC time. Regardless of what
happens in your local TZ, we'll be here at 16:30 UTC  (dustymabe,
17:21:05)

Meeting ended at 17:22:05 UTC.




Action Items

* dustymabe to write docs for rpi4 including updating eeprom




Action Items, by person
---
* dustymabe
  * dustymabe to write docs for rpi4 including updating eeprom
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (82)
* jlebon (36)
* zodbot (28)
* jdoss (16)
* travier (11)
* walters (8)
* lucab (7)
* bgilbert (6)
* jaimelm (5)
* miabbott (4)
* copperi[m]1 (3)
* lorbus (2)
* ravanelli (1)
* jmarrero (1)
* jbrooks (1)
* saqali (1)
* gursewak_ (0)




Generated by `MeetBot`_ 0.3

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [CoreOS] Fedora CoreOS Community Video Meeting 2021-11-02

[Dusty Mabe]

On 11/2/21 10:19 PM, Dusty Mabe wrote:
> Hi All,
> 
> Tomorrow we will be holding a video meeting for the Fedora CoreOS community.
> 
> Colin Walters will be presenting on a new proposal for "CoreOS Layering".
> https://github.com/coreos/enhancements/pull/7
> 
> We'll also be discussing any meeting tickets and possibly revisit our list of 
> high level
> issues.
> 
> Time: 16:30 UTC (same as normal) on Wednesday October 6th
> Location: https://meet.google.com/igd-ekxw-nzi (will be recorded)
> Agenda/Notes: https://hackmd.io/5bdC2OLjQYmB5ErZ4AzpdA

Thanks to everyone who attended! Here is a link to the meeting recording:

https://dustymabe.fedorapeople.org/meetings/2021-11-03_FCOS-Community-Meeting.mp4
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [CoreOS] Fedora CoreOS Community Video Meeting 2021-11-02

[Dusty Mabe]

On 11/3/21 5:45 PM, Eduard Lucena wrote:
> Would you like to have this meeting uploaded to Fedora Project's YouTube 
> channel?
> 
> 

Not really sure on that one. Maybe grab me and we'll discuss it.

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure