From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1169#note_598017347
Acked-by: Justin Forbes
(via approve button)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1167#note_596781310
Acked-by: Justin Forbes
(via approve button)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1167#note_596780470
> I prefer cutting this down to be arm-specific and "trade the spec file
complexity", since I see no reason for x86 (and other arch) customers (which I
believe is a majority) to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_596135080
> is it worth throwing a 'include in release' label and seeing if this can
build in eln?
I have tagged it with "include in release" and done a test build with it
against ELN koji:
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595919862
> glibc 2.34 will detect `-march=z14` and refuse to run on z13 or earlier, to
avoid hard-to-diagnose crashes later. We learned the hard way that this very
desirable during the ppc64le
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595910611
> do we know which s390x machines ELN builds on?
The koji builders are Z13. They are running a Fedora kernel to do the build,
so the 5.13-rc5 eln build was done in koji running
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1167#note_595825564
Curious on this, as Fedora has been building with CORESIGHT for a bit now
(since July 2020). We did not case the changes on arch, and simply added
openscd-devel as a buildreq for
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1155#note_595488507
We have been building with it here since rc4.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1085#note_592234983
Acked-by: Justin Forbes
(via approve button)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1165#note_592015240
I haven't had a request to turn on UV for Fedora, and I am not sure that there
is anyone interested in it, but I don't have an issue with flipping it on if
anyone is.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1162#note_591410772
Acked-by: Justin Forbes
(via approve button)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1163#note_591028806
Acked-by: Justin Forbes
(via approve button)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1162#note_590350124
Added "include in releases" as the kernel will not build without it. I added
it to dist-git for rc4 in Fedora, which is building with this patch now
successfully.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_590315781
Acked-by: Justin Forbes
(via approve button)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_587024136
So it seems Jens is against this for upstream, as IO_URING is "a core feature,
and something that more and more apps or libraries are relying on", which is
the direction it is heading.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_586022475
Or just wait it out, I submitted it upstream. Pavel has at least acked it:
https://lore.kernel.org/io-
uring/0d335e81-9a94-ca60-5659-bb46080b9...@gmail.com/T/#t
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_585992923
And x86_64 at least has completed the build successfully for ELN with expert
removed and CONFIG_IO_URING turned off:
```
>cat
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_585939162
Not sure what Kconfig options you are saying it adds. In this case, it only
adds one for CONFIG_IO_URING. Running a test with the following diff show no
unset config options or
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_585922609
ugh, you are correct, and annoyingly it doesn't show in our config prior to
build. I think I would rather see this patch changed to remove EXPERT than to
change the default on
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_585905834
This patch seems completely unnecessary. As it stands, CONFIG_IO_URING is
locked behind CONFIG_EXPERT which is disabled for both Fedora and ELN/RHEL.
If that situation changes, and it
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1155#note_585871204
I added the tag, so it should be in tomorrow's build. Not really happy with an
additional 76 lines to the spec, but I don't see another way.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_585698139
> If I need to push an other version I can add the Fedora update as well. This
MR already got way bigger than I expected. So I don't see a problem in adding
one more commit.
Either
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1063#note_584373061
Acked-by: Justin Forbes
(via approve button)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_583699147
Acked-by: Justin Forbes
(via approve button)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1150#note_583670885
Acked-by: Justin Forbes
(via approve button)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1152#note_582708834
Acked-by: Justin Forbes
(via approve button)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1148#note_581053570
I have just tested with similar changes to kernel-tools in Fedora
(libtraceevent is not packaged for F33, but is for F34+). Seems this is
worthwhile.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_579901839
As this is the merge request creating the dependency on those, the best
path forward is to put them in common instead of pending-common. The
make dist-configs breakage doesn't happen
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_579494927
I would suggest not changing pending-common. That is the location for
pre-reviewed, automated defaults. Nothing should be created there
without a corresponding MR to get that config
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1035#note_578321120
Right, so the Makefile generates vmlinux.h if the value is null, and
copies it over if the value is set to something. We could probably
simplify this even more. I assumed there was a
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1140#note_577067435
This is how we build in Fedora.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/#note_575712896
Not sure about a scratch build, but this is merged as of 3 days ago, so
the actual builds of the ELN kernel from the last couple of days are
using it.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1042#note_573638944
We have been building with this for a couple of days now, and I haven't
seen any issues on test systems.
___
kernel mailing list --
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1126#note_572523304
I am okay with it. I will just need to see if it is something I need to
keep on for the existing stable Fedora releases, but turning it off for
F35 and newer is acceptable.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1063#note_572520688
The scripts that generate these requests also go through RHMAINTAINERS
and look for the proper reviewer. They are added via the Cc Lines in
the MR, and that is how they are added as
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/#note_571904765
There is now a patch queued for upstream, which fixes the build issue. I
am okay with this going in, if it is merged before that patch lands, I
will do a temp MR to include it in
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/351#note_571531270
Reverting this for now, it seems to not work as intended:
fatal: 'ark/patches/master' is not a commit and a branch 'ark/master'
cannot be created from it
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1117#note_570447318
I don't know that it would be worthwhile, I think it might be easier to
write something to check it after the fact, or even the script to verify
against sources. Honestly, if we stop
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1117#note_570334250
It should work both ways, the email bridge seems a big laggy today
though. instead of instant, it is on a delay. Email comments end up on
gitlab and gitlab comments should end up in
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1117#note_570289882
We do want it to ignore files that do not actually exist, othrewise we
would have to change the extras list to be per arch, and frankly that
sounds like more than I want to deal with.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1042#note_570158863
I added an include in releases to this patch. Note, while the build
fails, it is only aarch64 that is failing. Koji is still producing build
and rpms for all other arch, you just have
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1042#note_570157165
@dzickusrh Not that I am aware of, the patches I have seen thrown around
upstream are to pahole, not the kernel. This is still being actively
discussed, with the last message in the
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/#note_570153780
So, it turns out this can be problematic for ARK/Rawhide. I just added
this to the kernel-tools package for rawhide, and the issue is, libbpf-
devel is missing hashmap.h. My ongoing
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1117#note_569297906
There is something coming that will help with that. When rpminspect is
used for autoqa in bodhi, we should see a notification when files move.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/40#note_569259804
I was waiting until the merge window closes to do the Fedora configs,
which would properly test this. Either close it, and I can reopen if it
doesn't, or I will close the issue once I have done
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_569259385
I thought this was fixed with MR https://gitlab.com/cki-project/kernel-
ark/-/merge_requests/1061
___
kernel mailing list --
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/#note_569176912
Is libbpf a separate package in RHEL? In Fedora it is built as part of
the kernel-tools package, but that package is not ported over to
ELN/RHEL because kernel-tools is built as part
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/#note_569180382
Nevermind, looks like it is a separate package in Fedora as well with an
epoch set so it overrides the kernel-tools package. Which begs, the
question, why weren't we just told to drop
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1103#note_568799018
Yes, sorry. Just meant I should have caught it when looking at other
differences between the fedora tools package, and the ark tools
subpackage.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1103#note_567984832
Not sure how this was missed here, Jiri added it to kernel-tools in
Fedora a couple of years ago.
___
kernel mailing list --
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/48#note_567145528
Wait just a minute on that, there is a filter issue with the surface
modules merge. I am testing a fix, but your x86_64 build will fail until
I get that pushed.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/48#note_567130107
No, it is not, the issue came up a while ago in Linux next, and they
fixed it for everything but aarch64. I have brought it up with upstream
maintainers and was told:
> the fix is being worked
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/47#note_567069865
Did a test build with # CONFIG_DEBUG_INFO_BTF is not set, this is not
the problem, I get the same output.
___
kernel mailing list --
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1088#note_566256679
Ahh, sorry. there are plenty of things in the spec that I just don't
ever use, but as long as they are useful, I am happy to keep them. My
comment had the desired effect, in that I
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1088#note_566198724
As I recall, the problem with --with-vanilla is rpm complains over
-vanilla. I think there are 2 possible fixes, changing the variant from
"-vanilla" to ".vanilla", or just dropping
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/788#note_566098257
Steve, I left it off in Fedora because of "This is intended for
developers only. The READ_PLUS operation has been shown to have issues
under specific conditions and should not be used
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/45#note_566062987
Of note, the commit log from 8da650b56e4fec39041edc15f2c328e2b7d29717:
> A few more fixes for local builds. None of this works until .1
Until I have tagged and pushed kernel-5.12.1-0, do not
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/45#note_566036154
Tags are there, I never did a tag push because I hadn't gotten that far
in the release yet for 5.12.1 and 5.11.18 builds. I changed my sync
script to push them when I pull from greg though.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/44#note_565170086
This was fixed with f23ad26468fce25011739cf9980761ef81483c43 Sorry, was
getting to it, today's build was broken in multiple ways, and I have
been workign through them.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1061#note_563988223
Thanks for doing this, it looks good.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1060#note_563122710
Looks good to me. I will definitely give it a good workout when I start
moving the Fedora configs
___
kernel mailing list --
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1024#note_562824788
While I am not particularly happy about it, I understand the situation.
I said it could be merged when it gets the acks, as the code is RHEL
only, and the patch will be dropped from
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_562665828
Of note, I think the reason this does not exist, and no one has cared to
put in the effort, is because dist-git is still considered the canonical
source of truth for Fedora builds, and if you
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_562648033
> We want to use this exact moment as the date in the NVR. But, I
believe we should read that from the commit date for that tag, not from
the shell script checking the system clock after it has
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_562593935
Koji has nothing to do with the date tag in the n-v-r, the date tag is
when 'make release' was run, which may not be the same date that release
is pushed to dist-git with 'make dist-git', and
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/968#note_557234552
I guess we get to test that additional failure path more quickly than I
had hoped. Since this was merged, the nightly 'Prepare Release' script
fails with
`$ git push gitlab "$(git
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/43#note_555971912
Fixed with https://gitlab.com/cki-project/kernel-
ark/-/commit/8691fd224224aa9aecce9ad2105e4b0828f5cd8d
___
kernel mailing list --
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/42#note_555188897
> `kernel` and `kernel-debug` are both just metapackages.
>
> When `%{debugbuildsenabled}` is 0, can we still produce a `kernel-
debug` metapackage?
This would be a possible solution. Don't
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/42#note_555185290
It is not a use case that has an easy solution within the confines of
rpm/dnf right now, though the simple way to do it would be to write up
repo builder script that grabs the latest build daily
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/42#note_555112975
> Ok, that's what I had assumed. Can we make the naming consistent
though, while still accomplishing that?
The naming is inline with package guidelines. rcX releases are in fact
upstream
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/42#note_555069659
The reason that this is set is because there is overhead in running
debug builds. We have a whole lot of users willing to run a rawhide
kernel for day to day, and the testing we get from that is
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1034#note_553977999
This is addressed by MR 1033, though it turns it off.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_553972180
Yes, this seems correct. For the default case, no one should have to
care beyond "origin"
___
kernel mailing list --
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1029#note_553909018
This does seem to work as expected. kernel/drivers/gpu/drm/tiny/ is
moved from kernel-core to kernel-modules on armv7 and aarch64, etc.
Thanks for cleaning this up!
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1029#note_552940252
Given the nature of it, I did an include-in-release for Fedora, will
compare the next builds with the previous.
___
kernel mailing list --
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/837#note_552600093
@sgarzarella That wouldn't be a part of this MR, but I just turned it on
for Fedora, it will be enabled starting with kernel-5.11.15.
___
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/41#note_551800150
Just as an update, for a quick temp fix, I modified the fedora-5.11 tree
to always set it to 0, and I can manually bump it if I end up doing a
second build for any reason. Better solution to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/41#note_550951201
> This would be handy. Because, otherwise I can't determine a tagname
automatically based only on a "package-version" name. Currently, I need
first to grep all available tags for kernel-5.11.13,
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/41#note_550913432
There are a couple of things here:
> Fedora RPM tagging in the ARK kernel began in May 2020 for fc33.
This line is not entirely accurate, as ARK was only used for Rawhide
from May of 2020
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1024#note_550884624
I have to be honest, I am not too thrilled at the idea of taking a patch
set which has been rejected upstream into ARK. RHEL is one thing, with
he guarantee of a stable ABI. there is
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/40#note_548390887
Two more odd observations about the error. First, I closed all of those
MRs yestrday, and when the script ran again, it just recreated them,
even though there should be no config issues (files
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547946553
It is an important distinction that the typical package has an upstream
source repository, and dist-git. We have essentially 2 different
upstream repositories and dist-git, so having the date
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547944992
kernel-5.11.0-155
kernel-5.11.0-156
kernel-5.11.0-157
kernel-5.11.0-158
These are tags by an autogenerated by scripts and have nothing to do
with dist-git because most of them were not used.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547885204
https://www.kernel.org/ for reference.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547881033
rc releases such as kernel-5.12.0-0.rc6.184 are built as release kernels
which is why they differ. It is an actual upstream release.
___
kernel
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547745411
Date in this case is very much important and different in that the git
commit there is the upstream (Linus tree) commit, and not the kernel-ark
commit id. Date gives us a bit more information as
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547725975
The decision to drop `` to 1 was made after 5.12 started as the
numbers are climbing inconsistently with what we want. Realistically
100/200/300 have special meaning for Fedora stable releases,
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547598365
As a prerelease kernel, we have never relied on for ordering, nor
should we. This is not a valid 5.12 release. 5.12.0-1 should supercede
it. I will say that the release bump is not entirely
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_546051611
When you create a fork on gitlab, it should automatically keep it in
sync with the project that you sync from, which means origin/master
doesn't really go out of date any more than
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_545178822
@dzickusrh Our documentation has been wrong for a year. Cloning the
project to your own namespace should grab all branches, so origin/master
should still just work. origin/ should point
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_544834861
Yes, for the stable branches, we don't care about master. I use
$UPSTREAM as a variable for the git --log, upstream is passed as an
argument for genspec and defined in
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/991#note_544408706
Looks like this is upstream now, closing this one out.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/991#note_543049010
I have just tagged it with "include in releases". This will bring it
into dist-git builds without having to merge the MR, and it can just
stay this way until it is properly merged
From: Justin Forbes on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/321
NOTE: Truncated patchset due to missing @redhat.com email
address on your GitLab profile at https://gitlab.com/-/profile.
Once that is fixed, close and reopen the merge
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/894#note_535065257
That seems comical
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/894#note_535063843
Ugh, sorry, I thought I did, but that was when I accidentally closed it
instead. I failed hard that day.
Acked-by: Justin Forbes
___
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/977#note_533479061
GL usernames are much less likely to map to whoami.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/968#note_526661348
I am okay with the added time and failure path, the benefit to the
community is strong with this.
___
kernel mailing list --
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/961#note_526354022
Thanks, for what it is worth, I think there is value in enabling them,
but watching the upstream conversation, I am not convinced that we will
get a practical solution in the near term.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/961#note_526217454
While I am all for flipping these options on, GCC_PLUG_IN options are
hugely problematic in practice right now, to the point that I am going
to have to disable the previous batch before
1 - 100 of 124 matches
Mail list logo
