and cities, that takes lots of time).
People got used to indulging in black magic accusations while reviewing
nothing and blocking everything, I hope they get something out of it
because it wasted a year of dev for no good reason.
Regards
--
Nicolas Mailhot
/redhat-rpm-config/pull-request/109
because I don’t have the time right now to beg people to look at it
again. Besides after months of the same unchanged code sitting in the
review queue I’m franckly sick of it all
Regards,
--
Nicolas Mailhot
___
golang
nim added a new comment to an issue you are following:
``
rpm dependencies are transitive. That means replace can not be supported in
rpm. That means the only sane way to handle replace is to remove it by patching
code imports (which is not long or hard)
As to why non-transitive deps and 'to
nim added a new comment to an issue you are following:
``
replace can not work in Fedora anyway because it is not transitive (it’s the
kind of broken by design idea people invent when their primary target is to
bundle piles of junk and avoid fixing their code).
source code that uses replace
Le 2020-09-01 15:17, Nicolas Mailhot a écrit :
Le 2020-08-20 22:05, Denis Fateyev a écrit :
Could anybody provide some more info: are Go rpm macroses not
fully backported to RHEL8 currently? Any kind of blockers, perhaps?
Unfortunately, while the Go-specific logic of the macros is quite
implementation in
stone and provide parallel updates (modularity & containers only work
for leaf features not core shared low level code)
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an e
gopath devel packages, unfortunately
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US
nim commented on the pull-request: `Remove tildes from goname` that you are
following:
``
That will work but it’s better to add tilde to the generic forbidden separator
cleanup rule:
> -- replace various separators rpm does not like with -
``
To reply, visit the link below or just reply to
nim commented on the pull-request: `Remove tildes from goname` that you are
following:
``
~ should be replaced with "-" then. "-" is safe as intra-name separator.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/26
)
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https
nim commented on the pull-request: `macros: Accept options for %gotest` that
you are following:
``
@atodorov It seems there are all too many of us in your case:(. Let’s try to
figure it a bit better before pushing changes that others will expect to be
perfectly baked.
Right now, our build
nim commented on the pull-request: `macros: Accept options for %gotest` that
you are following:
``
So what you really want, is better automation of the build stage, except the
testing module also requires you to use `go test` instead of `go build` as
build command?
I suppose I could revisit
nim commented on the pull-request: `macros: Accept options for %gotest` that
you are following:
``
I’m a bit wary of adding flags to such a low level macro: it sets an API in
stone, that will be quite hard to evolve later given how primitive and
constraining the rpm options parser is. Generic
Hi,
The Go font families (Go, Go Mono and Go Smallcaps) are now available
in Fedora 32 and 33 as normal system fonts.
You’ve all encountered them on godoc.org when reading Go source code
examples.
Regards,
--
Nicolas Mailhot
___
golang mailing list
ut tech does not
work but because our processes can not handle the pile of atomic
components generated by upstream practices. Since the problem is
process, not technical side, please work on the process side, instead
of trying to bypass the process with bad technical solutions.
Regards,
Le 2019-12-17 09:02, Neal Gompa a écrit :
On Tue, Dec 17, 2019 at 2:47 AM Nicolas Mailhot
wrote:
Le 2019-12-16 18:14, Neal Gompa a écrit :
> On Mon, Dec 16, 2019 at 12:06 PM Guillaume Rousse
> wrote:
>>
>> Le 14/12/2019 à 18:08, Neal Gompa (via dev Mailing List) a écrit
pm-config as a dependency is a bug. It *should*
require system-rpm-config, which is a virtual dependency that allows
us to swap among providers.
Right now it depends on quite a lot of lua code in redhat-rpm-config.
Unless this code has been imported mageia-side, things won’t work
Regards,
--
Nicola
nim commented on the pull-request: `rpm/macros.d: Make disabling Go modules
configurable for %gobuild and %gotest` that you are following:
``
@ngompa: please stay coherent with the exising macros and do not use `__`
prefixing
Apart from that, why not, but enabling modules will break things
nim commented on the pull-request: `Fix not listing packages with external
tests only` that you are following:
``
@jcajka the macros do not add any policy over golist output. Any policy is
manual use of override switches by packagers in their spec
As for upstreams… you realise that telling
nim commented on the pull-request: `Fix not listing packages with external
tests only` that you are following:
``
@jcajka I agree from a theoretical POW. I was just pointing out that from a
practical POW, asking all the Go parts we package to adhere strictly to the
specs, means dealing with a
nim commented on the pull-request: `Fix not listing packages with external
tests only` that you are following:
``
@obudai a lot of Go projects use internal in the package path to mean the same
thing as the internal keyword. Welcome to the wonderful land of underspecified
Go behaviour.
nim commented on the pull-request: `Fix not listing packages with external
tests only` that you are following:
``
That would wreck havoc on all package BRs since internal is a magic keyword
that forbids exposing the result to other Go packages.
Returning anything internal in `golist` must be
nim commented on the pull-request: `Expose Go build flags directly to spec
files as a macro` that you are following:
``
@berrange That’s awfully nice, both the runtime ifnarch removal and the
generalization to pie/nopie macros
If you think the PR is cooked and @jcajka agrees with it I see no
You are kindly invited to the meeting:
Go SIG Meeting on 2019-07-09 from 16:00:00 to 17:00:00 UTC
At fedora-gol...@irc.freenode.net
I will probably be late today, if I manage the meeting at all.
--
Nicolas Mailhot
___
golang mailing list
taking up from where he prepared, and checking the result builds in
koji and works for you, will accelerate things.
@eclipseo: please correct if I wrote something that does not make
things easier your side
Regards,
--
Nicolas Mailhot
___
golang mai
because the Fedora infra was not
ready yet.
Regards
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org
nim added a new comment to an issue you are following:
``
The whole logic is here:
https://pagure.io/go-rpm-macros/blob/master/f/rpm/macros.d/macros.go-rpm#_352
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/18
nim added a new comment to an issue you are following:
``
`gocheckflags` is here to pass exclusion information to `go-rpm-integration` in
`gocheck`, the same way `goinstallflags` works in `goinstall`.
To pass information explicitely to the `go test` layer, you need `gotestflags`.
Be careful
nim commented on the pull-request: `Always install SFiles whatever the arch`
that you are following:
``
Ok, weird that @jchaloup gone to all this pain for something that does not work
Reading the urfave/cli documentation (that I don’t know well, I used
jawher/mow.cli in modist), it seems you
nim commented on the pull-request: `Always install SFiles whatever the arch`
that you are following:
``
That looks good to me (I assume you checked it builds and works). That's how I
would have done it.
@qulogic up to you now
``
To reply, visit the link below or just reply to this email
nim added a new comment to an issue you are following:
``
@qulogic reading `golist` code, it should just need the same kind of processing
as for protobuf files
https://pagure.io/golist/blob/master/f/pkg/util/util.go#_77
(assuming we want all .s files added inconditionally)
``
To reply, visit
nim added a new comment to an issue you are following:
``
That’s not hard to do (just add the flag to %goinstallflags ) but this variable
is almost empty now, because all past file selection mistakes where fixed in
`golist`
@qulogic do you need the workaround added to `go-rpm-macros` or can
nim added a new comment to an issue you are following:
``
Closing, since the root cause is actually the same as issue #2
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/4
___
golang mailing list --
nim added a new comment to an issue you are following:
``
Closing, since the root cause is actually the same as issue #2
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/4
___
golang mailing list --
nim added a new comment to an issue you are following:
``
And the fix is now in rawhide, with go-rpm-macros 3.0.8
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/7
___
golang mailing list --
The status of the issue: `%goinstall should verify explicit paths exist` of
project: `go-rpm-macros` has been updated to: Closed by nim.
https://pagure.io/go-rpm-macros/issue/7
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe
nim added a new comment to an issue you are following:
``
This should be fixed with golist 0.10.0
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/1
___
golang mailing list --
nim added a new comment to an issue you are following:
``
A POC implementation is here
https://copr.fedorainfracloud.org/coprs/nim/macros-ng/builds/
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/2
nim added a new comment to an issue you are following:
``
A POC implementation is here
https://copr.fedorainfracloud.org/coprs/nim/macros-ng/builds/
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/2
nim added a new comment to an issue you are following:
``
Modules are now disabled by default, module mode will require a new tooling
stack refresh anyway. Closing
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/6
The status of the issue: `golist needs to be run outside the source tree to
avoid panics` of project: `go-rpm-macros` has been updated to: Closed by nim.
https://pagure.io/go-rpm-macros/issue/6
___
golang mailing list -- golang@lists.fedoraproject.org
nim added a new comment to an issue you are following:
``
So, the whole Go tooling update and cleanup is now finished in rawhide.
The corresponding tooling port to EL7 is here:
https://copr.fedorainfracloud.org/coprs/nim/macros-ng/builds/
(lightly tested, but it should handle all the
or not. The change page is up to
date, it’s the most recent rewrite)
Sincerely,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https
is a technology preview for
now.
Best regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
nim commented on the pull-request: `make it use the actual code that was merged
in redhat-rpm-config-130` that you are following:
``
@bex sadly there are not many (any?) good wills to do regular reviewing. The
repo history shows long periods of one-man commits, be it now or when the
nim commented on the pull-request: `make it use the actual code that was merged
in redhat-rpm-config-130` that you are following:
``
Ah, that
Just because it is trivial does not mean stupid typos can not happen, so the
commits cook in a private feature branch (where I can rewrite git history
nim commented on the pull-request: `make it use the actual code that was merged
in redhat-rpm-config-130` that you are following:
``
@ignatenkobrain sorry, I didn't know there was much interest in reviewing such
a trivial commit (or in go-rpm-macros PRs in general). If you have any comment
on
nim opened a new pull-request against the project: `go-rpm-macros` that you are
following:
``
make it use the actual code that was merged in redhat-rpm-config-130
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/16
nim merged a pull-request against the project: `go-rpm-macros` that you are
following.
Merged pull-request:
``
make it use the actual code that was merged in redhat-rpm-config-130
``
https://pagure.io/go-rpm-macros/pull-request/16
___
golang mailing
nim opened a new pull-request against the project: `go-rpm-macros` that you are
following:
``
small fixes
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/15
___
golang mailing list --
nim merged a pull-request against the project: `go-rpm-macros` that you are
following.
Merged pull-request:
``
small fixes
``
https://pagure.io/go-rpm-macros/pull-request/15
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe
nim opened a new pull-request against the project: `go-rpm-macros` that you are
following:
``
make use of golist --with-tests in dynamic buildrequires
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/14
nim merged a pull-request against the project: `go-rpm-macros` that you are
following.
Merged pull-request:
``
make use of golist --with-tests in dynamic buildrequires
``
https://pagure.io/go-rpm-macros/pull-request/14
___
golang mailing list --
nim commented on the pull-request: `Add option for querying main and test
simultaneously.` that you are following:
``
`--with-tests` (as suggested in the original issue) is a fine API with me. I
don’t have better ideas.
Please merge
``
To reply, visit the link below or just reply to this
nim merged a pull-request against the project: `go-rpm-macros` that you are
following.
Merged pull-request:
``
make use of golist 0.10.0 fixes
``
https://pagure.io/go-rpm-macros/pull-request/13
___
golang mailing list --
nim opened a new pull-request against the project: `go-rpm-macros` that you are
following:
``
make use of golist 0.10.0 fixes
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/13
___
golang
not be recorded and output
always has to be written in the same order.”
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Co
hat really begs for
https://github.com/rpm-software-management/rpm/issues/607
It's sad that eveyone is reinventing its own hack to implement
something taht should be done by default by rpm. If you have the time,
please explain rpm upstream why tracking this kind of info is useful.
> BUILDDATE=$(date +
nim merged a pull-request against the project: `go-rpm-macros` that you are
following.
Merged pull-request:
``
Force GO111MODULE=off till the macros grow Go module support
``
https://pagure.io/go-rpm-macros/pull-request/12
___
golang mailing list --
nim opened a new pull-request against the project: `go-rpm-macros` that you are
following:
``
Force GO111MODULE=off till the macros grow Go module support
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/12
nim merged a pull-request against the project: `go-rpm-macros` that you are
following.
Merged pull-request:
``
update licensing
``
https://pagure.io/go-rpm-macros/pull-request/11
___
golang mailing list -- golang@lists.fedoraproject.org
To
nim opened a new pull-request against the project: `go-rpm-macros` that you are
following:
``
update licensing
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/11
___
golang mailing list --
nim merged a pull-request against the project: `go-rpm-macros` that you are
following.
Merged pull-request:
``
Move a lot of code unrelated to srpm creation to srpm macros
``
https://pagure.io/go-rpm-macros/pull-request/10
___
golang mailing list --
nim opened a new pull-request against the project: `go-rpm-macros` that you are
following:
``
Move a lot of code unrelated to srpm creation to srpm macros
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/10
The status of the issue: `golist should be buildroot prefix aware` of project:
`golist` has been updated to: Closed by nim.
https://pagure.io/golist/issue/12
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to
nim opened a new pull-request against the project: `go-rpm-macros` that you are
following:
``
Use relative symlinks for goalts; workarounds https://pagure.io/golist/issue/12
https://github.com/rpm-software-management/rpm/issues/671
``
To reply, visit the link below or just reply to this email
nim merged a pull-request against the project: `go-rpm-macros` that you are
following.
Merged pull-request:
``
Use relative symlinks for goalts; workarounds https://pagure.io/golist/issue/12
https://github.com/rpm-software-management/rpm/issues/671
``
nim added a new comment to an issue you are following:
``
Ok, I found a workaround. Let’s focus on still broken things for now
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/12
___
golang mailing list --
nim commented on the pull-request: `WIP: Add output templating` that you are
following:
``
@qulogic Looks good (not tested). Not sure the `\n` is necessary for
`BuildRequires` but having the option to put everything on one line may be
useful for `go test`
``
To reply, visit the link below or
nim added a new comment to an issue you are following:
``
@eclipseo Please play a little with `modist` and tell us if it is better. I
tried to fix the CLI interface.
`cobra` is difficult to use in a core utility like `golist`. It has lots of
requirements, so bootsrapping a Go stack that
nim commented on the pull-request: `Add ignored Go files install list` that you
are following:
``
Indeed, it is very nice to see `golist` being improved at last!
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/pull-request/20
nim added a new comment to an issue you are following:
``
The download is a no-go since it will be blocked by CI/CD systems like `mock`.
It should be possible to avoid setting a build-specific `GOPATH` in golist, by
importing directly the directories golist operates on, and taking other code
nim added a new comment to an issue you are following:
``
> Do you need format string for file lists (or just the provided/installed)?
There's no need to format file lists, as long as the installation is left to
something else.
If golist was to take over installation (as is done by modist
nim added a new comment to an issue you are following:
``
I don't remember where the files end up (under `BUILD` or `BUILDROOT`) and I
may have mixed up the rpm variable representing rpm's last stage staging
directory.
The basic point is that for `Requires`/`Provides` we are not calling
nim merged a pull-request against the project: `go-rpm-macros` that you are
following.
Merged pull-request:
``
Fix missing variable in license detection
``
https://pagure.io/go-rpm-macros/pull-request/8
___
golang mailing list --
nim commented on the pull-request: `Fix missing variable in license detection`
that you are following:
``
Good catch, thanks, the variable was dropped in a recent code cleanup.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/8
nim added a new comment to an issue you are following:
``
Ok I've checked the current code and the problem also exists here.
I have a fix, will commit it once I'm somewhere that allows ssh access to
pagure (since pagure does not allow https commits)
``
To reply, visit the link below or just
nim added a new comment to an issue you are following:
``
(BTW did you check what happens with the current macro version? This part has
been refactored for more robustness, even though this is definitely a case I
didn't check so if it's fixed it's fixed as a side effect of something else ;))
``
nim commented on the pull-request: `Replace Go internals with go/build` that
you are following:
``
The v2 is module versioning. That's something we need to support to have
working Go packaging. It's good that your PR starts picking it up when the
previous code does not.
However you are right
nim added a new comment to an issue you are following:
``
Yes goinstall error checking should be improved (even though the target will be
modules soonish that should hopefully remove the need for custom install hacks)
``
To reply, visit the link below or just reply to this email
nim commented on the pull-request: `Replace Go internals with go/build` that
you are following:
``
Ok, after more work evolving to module support seems a bit simpler than I
though, because go mod need requires people to clean up their mess and that's
also the assumption of the current
The issue: `didn't find "github.com/google/go-cmp/cmp"` of project: `golist`
has been assigned to `nim` by nim.
https://pagure.io/golist/issue/6
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to
nim added a new comment to an issue you are following:
``
I will recheck. cloud.google.com/go is a full bag of nastiness, that even other
Google projects have problems with (most of them still import it under a legacy
name, which means they are afraid of using the latest code. The current
The issue: `incomplete import detection for tests ` of project: `golist` has
been assigned to `nim` by nim.
https://pagure.io/golist/issue/9
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to
nim added a new comment to an issue you are following:
``
golist does not uses this kind or regexes it plugs directly in the Go compiler
inner code to match the Go compiler view of what's in a project. This was a
deliberate choice by Fedora Go maintainers last year, my initial macro
nim added a new comment to an issue you are following:
``
BTW:
* thanks an *awful* lot for looking at golist code maintenance
* if you can figure how to make golist process module info, and spit out the
version constrains that only exists in those modules, that would be much nicer
than
nim added a new comment to an issue you are following:
``
Yes, I suppose an alternative would be to track the things that depends on this
bit of code and ask them to drop it.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/10
nim added a new comment to an issue you are following:
``
Ah ok. I think that's because we only hit it when executing tests. Will look at
it once more, maybe the logrus code was refactored since this was filed
``
To reply, visit the link below or just reply to this email
nim added a new comment to an issue you are following:
``
Sure it does, however till someone analyses both issues and concludes they are
the same, it's dangerous to track only one of them.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/8
The issue: `golist needs to be run outside the source tree to avoid panics` of
project: `go-rpm-macros` has been assigned to `nim` by nim.
https://pagure.io/go-rpm-macros/issue/6
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe
nim added a new comment to an issue you are following:
``
For readers that don't understand the latest exchange, the participants wrote
their piece here https://pagure.io/GoSIG/go-sig/issue/3
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/7
nim added a new comment to an issue you are following:
``
@jcajka: how do you expect anyone to understand your position? Months over
months of not accepting macro fixes, months over months of finding new reasons
not to look at them, refusal to discuss it in SIG meetings, no activity in the
nim added a new comment to an issue you are following:
``
That sucks since other projects *expect* to be in the source dir when run. So
I guess the shell wrapper will need to be changed to run golist outside this
dir and switch to it afterwards: (
I've filled it as
nim added a new comment to an issue you are following:
``
@qulogic this is all originally @jchaloup 's code. He asked to split it in a
separate repository, but I don't know what's the level of involvement he wants
(and can) provide here. Ask him politely how he wants to do things (of course
if
nim reported a new issue against the project: `golist` that you are following:
``
Because the naming of Go projects is a mess many of them (including core Google
modules) have started asserting how they should be named.
This results in golist panics.
Because golist is often called by other
nim added a new comment to an issue you are following:
``
Yes that's what I meant by a little tricky. The changes are not big or scary
but they are spread over several packages that call one another, it's easier to
publish a copr with all the small changes than try to walk you through it
nim added a new comment to an issue you are following:
``
The original reporter may not see the question since this is a migrated issue.
But even if tests were still being run (not sure about this), a panic is pretty
bad behavior: packagers are supposed to care about how builds proceed, we
nim added a new comment to an issue you are following:
``
It's kind of hard to diagnose without the spec file and build logs, but
basically there have been a lot of fixing and rewriting in the months since the
wiki page was written. Macro usage is still the same but the code itself has
changed
nim added a new comment to an issue you are following:
``
> How do we handle the case of when patches should be applied
> manually/conditionally?
That would actually be trivial to handle cleanly
```specfile
%if
%global source_patches3 6 87 456 # apply patches 6 87 456 after unpacking
source 3
nim reported a new issue against the project: `golist` that you are following:
``
`golist` only implements a single output format, which means this output needs
to be reprocessed in shell before being fed to other software, like rpm¹.
This shell reprocessing is brittle and adds noise to Go
1 - 100 of 201 matches
Mail list logo
