Le mardi 28 avril 2020 à 08:43 +0200, Petr Pisar a écrit :
> On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote:
> >
> > %_use_ncurses %{lua:
> > if rpm.expand("%{name}") == "yourpackage1"
> > or rpm.expand("%{name}") == "yourpackage2" then
> > print(rpm.expand("%{bcond_with foo}%{wit
Le mercredi 29 avril 2020 à 16:27 +0200, Tomas Orsava a écrit :
Hi,
> I’m working on a change to rename pythonXY packages to pythonX.Y,
> e.g. python39 to python3.9.
>
> Motivation:
> When you install an additional Python interpreter, the command that
> runs it contains a dot (e.g. /usr/bin/pytho
Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit :
> All [compat packages] MUST include the base name suffixed by either:
Well we are not creating a compat package here and not adding an hyphen
creates an artificial numeric/non numeric special case.
But, I see someone formalised the
Le mercredi 29 avril 2020 à 19:57 +0200, Miro Hrončok a écrit :
> Such automation is broken anyway, because it cannot tell if python-
> requests is a
> Python library or a Python "qualifier".
It is no more broken than automation that "knows" test means
is a version. Of course before you apply
Le mercredi 29 avril 2020 à 19:43 +0200, Miro Hrončok a écrit :
> On 29. 04. 20 19:37, Nicolas Mailhot wrote:
> > Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit :
> >
> > > All [compat packages] MUST include the base name suffixed by
> > > either:
> > Well we are not creating a comp
Le mercredi 29 avril 2020 à 19:57 +0200, Miro Hrončok a écrit :
> And I don't understand what kind of automation are we
> talking about that needs to parse the "3.9" part and figure out it is
> a "qualifier".
It mostly hits you in the package creation code. The Go macro code will
just dump -qualif
Le jeudi 30 avril 2020 à 00:38 +0200, Miro Hrončok a écrit :
>
> My sentence was about "python3.9" not being more annoying than
> "python-3.9".
>
> I wonder, why do you consider periods in names confusing?
…
> jboss-jsf-2.1-api
Another example where the hyphen helps reading. The version is mid
Le jeudi 30 avril 2020 à 10:03 +0200, Nicolas Mailhot a écrit :
>
> Clever “it’s obvious in the few cases we imagine today, we do not
> need a clean version separator” syntaxes fail hard once exposed to
> the real world.
Also, to get back to the original subject, the whole python package
renaming
Le jeudi 30 avril 2020 à 10:03 +0200, Nicolas Mailhot a écrit :
>
> Old human languages did not use word separators like space in
> writing, because "everyone knew" where one word started and the next
> finished. Even scholars that spent their life studying one of those
> past civilizations find t
Le jeudi 30 avril 2020 à 10:49 +0200, Petr Šabata a écrit :
> On Tue, Apr 28, 2020 at 9:55 AM Nicolas Mailhot via devel
> wrote:
> > Le mardi 28 avril 2020 à 08:43 +0200, Petr Pisar a écrit :
> > > On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote:
> &
Le lundi 09 mars 2020 à 00:26 +0100, clime a écrit :
Hi,
> the code would fail because at that point, the
> git metadata is already missing (they are not included in srpms).
Can’t storage of built-time information in srpms be fixed instead of
adding a whole new overlay over existing tools, that
Le lundi 04 mai 2020 à 17:31 +0100, José Abílio Matos a écrit :
> On Monday, 4 May 2020 16.41.26 WEST Richard Shaw wrote:
>
> > For the longest time I at least overrode it so it wouldn't mix
> everything
> > together by putting the package name in the mix: rpmbuild//...
>
> So did I, for the las
Hi,
Also Fedora is driving a lot of spec syntax enhancements, both at the
rpm and the macro layer. Pushing spec files upstream is a sure way to
freeze spec syntax in stone and have everything behave in rpm 3.x mode
(with rpm 3.x limitations) 20 years from now.
The whole thing is just a variation
Hi,
Well, *my* packaging workflow is pretty simple:
1. point to the upstream git repo in my spec file with %{forgeurl} and
the rest of the forge macros
2. point to the target upstream tag or commit with the associated
variable
3. spectool (or co from lookaside if already there)
4. build
If I nee
Le mercredi 13 mai 2020 à 15:17 -0400, Josh Boyer a écrit :
Hi,
> If the consensus from the Fedora community is that RHEL should shift
> development elsewhere, the Fedora Council can always reach out to me
> and I can start that internal conversation. I do not believe for a
> second that's actual
Le jeudi 14 mai 2020 à 11:53 +0200, Michal Srb a écrit :
>
> Since there is no standard place for shared Java libraries on your
> laptop,
Of course there is one /usr/share/java, which has been defined and used
by Linux distributions since jpackage times (circa ~2000).
Java is not special from a
Le jeudi 14 mai 2020 à 06:33 -0500, Ty Young a écrit :
>
> I could literally go on and on. The "my-shit-don't-stink" attitude is
> so terrible it's borderline sad.
And years of terminally broken build practices Java-side have finally
resulted in complete capture of all the Java big data code the
Le vendredi 15 mai 2020 à 11:11 -0400, Simo Sorce a écrit :
>
> So, another way that could work, with minimal tooling is that we
> keep
> the master branch strictly mirroring whatever upstream branch we
> follow,
For some projects we are not hopping between branches of the same
upstream git, we
Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
> On Fri, 15 May 2020 08:02:34 +0200
> Michal Srb wrote:
>
> An aside, just to clarify for myself. That means that all Java apps
> are
> the equivalent of statically linked, right? And are related to
> things
> like flatpaks and mo
Le samedi 16 mai 2020 à 11:09 +0200, Nicolas Mailhot a écrit :
> Le vendredi 15 mai 2020 à 11:11 -0400, Simo Sorce a écrit :
> > So, another way that could work, with minimal tooling is that we
> > keep
> > the master branch strictly mirroring whatever upstream branch we
> > follow,
>
> For some
Le lundi 18 mai 2020 à 14:12 +0200, Michal Srb a écrit :
> Hello,
>
> On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel <
> devel@lists.fedoraproject.org> wrote:
> > Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
> > > On Fri, 15 May 202
Le lundi 18 mai 2020 à 08:34 -0500, Ty Young a écrit :
>
> The "toolchain" isn't broken, other than Gradle developers not
> caring about backwards compatibility but... It works for them, just
> as constantly breaking internal kernel APIs works for the Linux
> kernel
The difference, is that you c
Le mercredi 20 mai 2020 à 22:18 +0200, Miro Hrončok a écrit :
>
> We could have parallel installable multiple Python version stacks
> w/out Modularity just fine. The "only little problem" is we hardly
> have the enough maintainers to maintain the 3k+ existing Python
> packages.
BTW, that’s not a
Le vendredi 22 mai 2020 à 10:30 -0400, Steve Grubb a écrit :
> The /usr/share hierarchy is for all read-only architecture
> independent data
> files.
The important part of the FHS definition is “read-only architecture
independent“. Because everything on computing storage is data depending
on how
Le vendredi 22 mai 2020 à 20:41 +0200, Nicolas Mailhot via devel a
écrit :
>
> So, no use looking for non-executable /usr/share. A lot of /usr/share
> is executable and will stay that way.
Also moving executable things somewhere else would make multiarch (more
of) a major hassle. Be
Le vendredi 22 mai 2020 à 16:48 -0400, Steve Grubb a écrit :
> On Friday, May 22, 2020 4:23:50 PM EDT Przemek Klosowski via devel
> wrote:
> >
> > In general, data is code is data.
>
> I know this argument well (Weird Machines). I was making the same
> argument 10 years ago. :-)
It got true
Le vendredi 22 mai 2020 à 21:31 -0400, Steve Grubb a écrit :
>
> Over a couple emails I kind of realized that originally this was
> framing the
> question wrong. My question now is how can we determine what is meant
> to be
> executable by system applications vs examples and other cruft?
There
Le mercredi 30 octobre 2019 à 12:53 -0400, Stephen John Smoogen a
écrit :
> On Wed, 30 Oct 2019 at 11:59, Iñaki Ucar
> wrote:
> > Hi all,
> >
> > I incidentally discovered today that, since quite recently, there's
> > a
> > Red Hat font [1]. And this led me to think about the popularity of
> > th
Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
>
>
> I don't agree with centralisation. You should run your own DoH
> endpoint,
> using Google's, Cloudflare's or Quad9's servers is a shortcut.
DoH has zero integration and manageability. “It’s not centralized” (but
you have to
Le mercredi 06 novembre 2019 à 07:11 +0100, Tomasz Torcz a écrit :
> On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel
> wrote:
> > Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
> > >
> > > I don't agree with centralis
Le jeudi 07 novembre 2019 à 18:32 +0100, Sheogorath via devel a écrit :
>
> The talk is right on many points, but I think it dismisses the most
> essential point DoH does right: DNS is a decision of the device
> owner.
And the owner should be able to delegate this decision to the network
manager.
Le samedi 09 novembre 2019 à 01:15 +0100, Sheogorath via devel a
écrit :
> And the owner should be able to delegate this decision to the
> network
> > manager.
> >
>
> Then let's talk on how we properly implement this delegation process
> instead of asking ourselves whenever we want DoH or DoT o
Le samedi 09 novembre 2019 à 11:09 +0100, Tomasz Torcz a écrit :
> On Thu, Nov 07, 2019 at 06:18:46PM +0100, Nicolas Mailhot via devel
> wrote:
> > > >
> Here's a network management lesson for you:
> - run DoH resolver* not on ::1, but on IP available on your LAN
&g
Le samedi 09 novembre 2019 à 12:04 +0100, Nicolas Mailhot a écrit :
> Le samedi 09 novembre 2019 à 11:09 +0100, Tomasz Torcz a écrit :
> > On Thu, Nov 07, 2019 at 06:18:46PM +0100, Nicolas Mailhot via devel
> > wrote:
> > Here's a network management lesson for you:
>
Le samedi 09 novembre 2019 à 12:46 +0100, Marius Schwarz a écrit :
> Am 09.11.19 um 10:12 schrieb Nicolas Mailhot via devel:
> > That’s why DoH is intrinsically centralized and rotten to the core.
> >
> > DoH supporters are perfectly happy with a world where there i
Hi,
A fonts packaging policy rewrite proposal has been pushed to FPC today:
https://pagure.io/packaging-committee/pull-request/934
It should be clearer, more opinionated, and take into account:
– updates of The OpenType standard
– variable fonts
– web fonts
– upstream depreciation of non Open
Hi,
A fonts packaging policy rewrite proposal has been pushed to FPC today:
https://pagure.io/packaging-committee/pull-request/934
It should be clearer, more opinionated, and take into account:
– updates of The OpenType standard
– variable fonts
– web fonts
– upstream depreciation of non Ope
Le 2019-11-12 10:06, Akira TAGOH a écrit :
On Tue, Nov 12, 2019 at 5:01 PM Nicolas Mailhot
wrote:
Hi Akira
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
showcases the new policy on 62 real-world source packages, generating
139 installation packages. Some of those are
Le mardi 12 novembre 2019 à 17:02 +0100, Aleksandra Fedorova a écrit :
> Hi, Igor,
>
> On Tue, Nov 12, 2019 at 4:20 PM Igor Gnatenko
> wrote:
> > >
> > > On Tue, Nov 12, 2019 at 10:50 AM Dominik 'Rathann' Mierzejewski
> > > wrote:
> > > >
> > So is it really about making tooling (writing new,
Le mardi 12 novembre 2019 à 09:00 +0100, Nicolas Mailhot a écrit :
> Hi,
>
> A fonts packaging policy rewrite proposal has been pushed to FPC
> today:
> https://pagure.io/packaging-committee/pull-request/934
>
> It is based on the new fonts-rpm-macros project for automation:
https://pagure.io/fo
Le mercredi 13 novembre 2019 à 00:19 +0200, Aleksandar Kurtakov a
écrit :
>
>
> On Wed, Nov 13, 2019 at 12:02 AM John M. Harris Jr <
> joh...@splentity.com> wrote:
> > On Tuesday, November 12, 2019 9:02:07 AM MST Aleksandra Fedorova
> > wrote:
> > > Again, no one forces you or any other packager
Le mercredi 13 novembre 2019 à 06:43 +0100, Nicolas Mailhot via devel a
écrit :
>
> The native Go component format (also, confusingly, named
> module) handles those 3 constrains and won't present any core
> difficulty in rpm packaging once it is finished upstream.
And, B
Le mercredi 13 novembre 2019 à 06:43 +0100, Nicolas Mailhot via devel a
écrit :
>
> Fedora modules are an horrifically complex way to pretend those basic
> three constrains do not exist, while actually implementing them
> (except in a broken non-working way, because the *pretence* i
Le 2019-11-13 07:39, Nicolas Mailhot a écrit :
Le mercredi 13 novembre 2019 à 06:43 +0100, Nicolas Mailhot via devel a
And anyway, if anyone feels the module design is actually needed (I
don’t, because the problems are elsewhere), it could have been *easily*
implemented within existing tools
Le 2019-11-13 10:14, Aleksandra Fedorova a écrit :
Exactly the same way as "stay away" won't work for automatic
BuildRequires generator feature, which we voted for in this cycle.
Sure you can, automated BRs are a specific section in the spec file,
staying away no more complex that not filling
Le mardi 12 novembre 2019 à 16:09 -0500, Stephen John Smoogen a écrit :
> On Tue, 12 Nov 2019 at 15:36, Stephen Gallagher
> wrote:
> > On Tue, Nov 12, 2019 at 12:40 PM Stephen John Smoogen <
> > smo...@gmail.com> wrote:
> > >
> > The technology allows you to do this. The policy can restrict this.
Le jeudi 14 novembre 2019 à 13:45 -0500, Stephen Gallagher a écrit :
> On Thu, Nov 14, 2019 at 1:33 PM John M. Harris Jr <
> joh...@splentity.com> wrote:
> > On Thursday, November 14, 2019 11:15:15 AM MST Stephen Gallagher
> > wrote:
> > > I'm not sure what you're asking here. I thought it was pret
Le 2019-11-14 22:01, Stephen Gallagher a écrit :
On Thu, Nov 14, 2019 at 4:00 PM Miro Hrončok
wrote:
On 14. 11. 19 21:32, Stephen Gallagher wrote:
>I proposed earlier around the major
> upgrade rebuilds (letting us set other modules as `buildrequires:` of
> `python: [ ]` for stream expansion)
Hi Igor
On Fri, Nov 15, 2019, 10:03 Nicolas Mailhot via devel
wrote:
Le 2019-11-14 22:01, Stephen Gallagher a écrit :
wrote:
On 14. 11. 19 21:32, Stephen Gallagher wrote:
I proposed earlier around the major
upgrade rebuilds (letting us set other modules as
`buildrequires:` of
`python
Le samedi 16 novembre 2019 à 03:38 +0100, clime a écrit :
> > A true solution would be blending modularity into RPM.
> > At build time as well as at installation time.
>
> I agree this would be the best. Basically, final
> product of a module build should be an rpm. modulemd
> file should be kind
Le samedi 16 novembre 2019 à 08:37 +0100, Nicolas Mailhot a écrit :
>
> Sure, do some rpm fixing if necessary so the result feels less like a
> kludge than %dist. But, don’t rely on an external framework to do
> things for you instead of doing the necessary work (if any) at the
> component format
Le samedi 16 novembre 2019 à 09:35 +0100, Lukas Ruzicka a écrit :
>
>
> > Either the strategy should be:
> >
> > "We offer alternate Perl versions for containers etc. they conflict
> > with the
> > default Perl version and with the non-modular apps. That is known
> > and accepted."
That won't
Le samedi 16 novembre 2019 à 18:42 +0100, clime a écrit :
> On Sat, 16 Nov 2019 at 08:38, Nicolas Mailhot via devel
> wrote:
> > Le samedi 16 novembre 2019 à 03:38 +0100, clime a écrit :
> > > > A true solution would be blending modularity into RPM.
> > &
Le samedi 16 novembre 2019 à 19:05 +0100, clime a écrit :
> On Sat, 16 Nov 2019 at 18:54, Nicolas Mailhot via devel
> wrote:
> > Le samedi 16 novembre 2019 à 18:42 +0100, clime a écrit :
> > > On Sat, 16 Nov 2019 at 08:38, Nicolas Mailhot via devel
> > > wrote:
>
Le jeudi 21 novembre 2019 à 01:02 +0100, Kevin Kofler a écrit :
> Fabio Valentini wrote:
> > Today, builds submitted by MBS made up more than 80% of total
> > builds,
> > or over 5x the number of "normal" builds.
> > What an incredible waste of resources.
>
> Especially considering what small perc
Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit :
Hi, Igor
> And we can't actually
> have multiple versions of a package with same name (without "mangled"
> names) in a repo due to the way how our buildsystem works (and not
> only buildsystem, with some caveats).
I suppose you're
Le 2019-11-27 08:08, Tom Hughes a écrit :
On 27/11/2019 01:49, Chris wrote:
I kind of like the way nagios-plugins breaks apart it's check_scripts
into many sub-packages, but 50+ subpackages seems a bit extreme... or
is it? It certainly seems like a bit of a nightmare to maintain; it
would be
Le 2019-11-27 07:44, Igor Gnatenko a écrit :
No, 50 is perfectly fine. As others mentioned, we have much bigger
amount of them in texlive.
It's not just about the number of subpackages. Each package you publish
will end up as a separate node in the dependency graph.
Since functional plugins
Le 2019-11-27 10:37, Tom Hughes a écrit :
On 27/11/2019 09:30, Nicolas Mailhot via devel wrote:
The clean way to do it is to put the list of things to generate
against in a spec variable, and write the generator logic in a (lua)
rpm macro. That keeps the generation inside the spec instead of
Le 2019-11-27 11:45, Ian McInerney a écrit :
Tex isn't really the best example for the insane package numbers
(since the main Tex system, CTAN, actually does define them as
separate packages). It would be interesting to know if anyone actually
does just install one or two rather than all... I kno
Le 2019-11-29 11:39, Felix Schwarz a écrit :
Am 29.11.19 um 11:18 schrieb Miro Hrončok:
My effort is to raise the awareness about he failure. Despite my large
effort,
I cannot possibly fix all the build failures in Fedora.
I just wanted to mention that I appreciate your efforts.
I think the
Le samedi 30 novembre 2019 à 12:54 -0500, Neal Gompa a écrit :
> On Sat, Nov 30, 2019 at 12:49 PM Miro Hrončok
> wrote:
> > On 30. 11. 19 17:26, Dominik 'Rathann' Mierzejewski wrote:
> > >
> > > 2. It would be useful if it generated the file list
> > > automatically, too.
> > > I had to drop .egg
Le 2019-12-02 07:23, Igor Gnatenko a écrit :
On Tue, Nov 26, 2019 at 9:23 PM Nicolas Mailhot via devel
wrote:
Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit :
> And we can't actually
> have multiple versions of a package with same name (without "mangled&quo
Le 2019-12-02 08:17, Igor Gnatenko a écrit :
I simply can't. If somebody gets a package into repo just because he
wants to build foo, it is probably not very reasonable to ask them to
"properly" maintain it.
It is very reasonable to expect anyone building in Fedora, reusing the
work of countle
Le 2019-12-02 07:47, Igor Gnatenko a écrit :
Hi Neal,
On Sat, Nov 30, 2019 at 11:58 PM Neal Gompa wrote:
I think we need to recognize that we've done some poor optimization
for the majority of packager workflows. Even if we consider modules,
the vast majority of components will never be modu
Le 2019-12-02 08:38, Igor Gnatenko a écrit :
On Mon, Dec 2, 2019 at 8:28 AM Nicolas Mailhot via devel
Having all build elements in the package repos themselves is the CORE
feature that makes the “share” community dimension of Fedora work.
Anyone
can take the packages and do whatever he wants
Le 2019-12-02 10:45, Igor Gnatenko a écrit :
On Mon, Dec 2, 2019 at 8:48 AM Nicolas Mailhot via devel
wrote:
Le 2019-12-02 08:17, Igor Gnatenko a écrit :
Building communities takes time and energy and has no immediate
benefit.
But, long-term, it's the most efficient way to do things
Le 2019-12-02 10:49, Igor Gnatenko a écrit :
On Mon, Dec 2, 2019 at 8:58 AM Nicolas Mailhot via devel
wrote:
Le 2019-12-02 07:47, Igor Gnatenko a écrit :
> Hi Neal,
>
> On Sat, Nov 30, 2019 at 11:58 PM Neal Gompa wrote:
>> I think we need to recognize that we've done so
Le lundi 02 décembre 2019 à 18:16 +, Zbigniew Jędrzejewski-Szmek a
écrit :
>
> How often do you ssh *into* your laptop?
I use the same tech desktop and home server side. If it does not work
on my home server, I don’t want to see it on my desktops. I have other
things to do in life than coping
Le mercredi 04 décembre 2019 à 20:50 -0700, Orion Poplawski a écrit :
>
> Interesting. Thrift appears to have pretty broken perl packaging as
> well (classes inside of files with a different name).
Thrift is broken for all languages (maybe not Java). It's upstream devs
Apache-side are trying
Le mercredi 04 décembre 2019 à 16:59 -0700, John M. Harris Jr a écrit :
> On Wednesday, December 4, 2019 12:38:20 PM MST Przemek Klosowski via
> devel
> wrote:
> > - stolen/lost laptop: I think this is the most important one for
> > most
> > people; it is mitigaged by a trusted-network-based de
Le mercredi 04 décembre 2019 à 17:37 -0700, John M. Harris Jr a écrit :
>
> > The traditional way is unquestionably hostile to international
> > users,
> > and doing better, however untraditional, is absolutely something I
> > strongly favor.
>
> How is it "hostile to international users"? "inter
Le jeudi 05 décembre 2019 à 16:42 -0700, John M. Harris Jr a écrit :
>
> Why in the world was Docker removed? Docker is the most popular
> container
> technology, so if we must embrace the "container" systems, why not
> include the most popular in Fedora?
Because moby (née docker) is a trainwrec
Le mardi 10 décembre 2019 à 07:36 -0700, John M. Harris Jr a écrit :
> Most users,
> just like most American and UK users, set their keyboard layout to
> their primary layout, and then don't change it,
Actually, most non western users spend their time switching between
several input methods, one
The builsystem should rebuild all the other participants in the cycle against
the new link, then rebuild the new link against the updated cycle, then rebuild
again the rest of the cycle against the new link
If that fails, attempt to do the same with a bootstrap pass, hoping one of the
cycle par
Le mardi 16 juillet 2019 à 18:53 +0200, Björn 'besser82' Esser a
écrit :
>
>
> Which build chain does look cleaner, shorter, and more semantically
> correct?
>
> 1. systemd (no cryptsetup) --> json-c (new so-ver) --> cryptsetup
> --> systemd (with cryptsetup) --> other consumers in chai
As stated in
https://docs.fedoraproject.org/en-US/packaging-guidelines/PkgConfigBuildRequires/
pkgconfig(foo) is a more reliable marker of what ships the devel files,
than the package name.
It does not matter if the config process uses pkgconfig or not.
Depending on the package name is not
Le 2019-07-18 15:51, Zdenek Dohnal a écrit :
On 7/18/19 3:39 PM, Vitaly Zaitsev via devel wrote:
Hello, Zdenek Dohnal.
Thu, 18 Jul 2019 13:44:56 +0200 you wrote:
What's your opinion? Is it useful feature of Vim and it should stay
as
default, or it needs to be disabled?
I think, that *.spec f
Le vendredi 19 juillet 2019 à 08:48 +0200, Remi Collet a écrit :
> Le 18/07/2019 à 18:26, Nicolas Chauvet a écrit :
> > > "Build dependencies on Fedora packages which provide pkg-config
> > > files SHOULD be expressed
> > > as pkgconfig(foo) and not foo-devel, whether the dependent
> > > package u
Le 2019-07-22 10:22, Miro Hrončok a écrit :
Personally, I wish we had spent less engineering time in
infrastructure on Modularity and more on the contributor UX :(
It’s not just Modularity. Modularity is just a symptom. There is
something deeply broken in the Red Hat / Fedora interface.
RHE
Le 2019-07-22 17:29, Pierre-Yves Chibon a écrit :
On Mon, Jul 22, 2019 at 11:19:17AM +0200, Nicolas Mailhot via devel
wrote:
Le 2019-07-22 10:22, Miro Hrončok a écrit :
> Personally, I wish we had spent less engineering time in
> infrastructure on Modularity and more on the contribu
Le 2019-07-22 21:04, Jeremy Cline a écrit :
On Mon, Jul 22, 2019 at 06:59:04PM +0300, Alexander Bokovoy wrote:
On ma, 22 heinä 2019, Jeremy Cline wrote:
It is mostly due to supportability of the packages in Fedora. Java
products tend to be split into smaller packages and an overhead for
maint
Le 2019-07-23 08:32, Alexander Bokovoy a écrit :
On ma, 22 heinä 2019, Jeremy Cline wrote:
On Mon, Jul 22, 2019 at 06:59:04PM +0300, Alexander Bokovoy wrote:
On ma, 22 heinä 2019, Jeremy Cline wrote:
> On Sun, Jul 21, 2019 at 05:37:10PM -0400, Neal Gompa wrote:
> > Keycloak is not generally Fed
Le 2019-07-23 07:02, drago01 a écrit :
Please just take back this change and come back at April first if it
was supposed to be a joke - if not then submit again in about 10
years.
Fedora used to have the x86 repo for old hardware, and the x86_64 repo
for new hardware. Now that the tech cursor
Le 2019-07-23 09:23, Mikolaj Izdebski a écrit :
On Mon, Jul 22, 2019 at 11:20 AM Nicolas Mailhot via devel
wrote:
Huge Red Hat investments, in the Java ecosystem, that fail to
translate
into an healthy Fedora Java ecosystem. To the point that when IBM
wants
its Java guys to join there is
Le 2019-07-23 12:01, Fellipe Henrique a écrit :
Hi
First, Thanks very much for you reply...
I need to add a "global" argument so I can change the layer of a
repository... For example:
$ dnf repolist --set-layer=mylayer
$ dnf install -y any_repo --set-layer=mylayer
On our setup we approximat
Le 2019-07-23 12:48, Peter Robinson a écrit :
On Tue, Jul 23, 2019 at 11:31 AM Nicolas Mailhot via devel
wrote:
Le 2019-07-23 07:02, drago01 a écrit :
> Please just take back this change and come back at April first if it
> was supposed to be a joke - if not then submit again in ab
Le 2019-07-23 14:09, Stephen John Smoogen a écrit :
On Tue, 23 Jul 2019 at 08:00, Nicolas Mailhot via devel
wrote:
Le 2019-07-23 12:01, Fellipe Henrique a écrit :
Hi
First, Thanks very much for you reply...
I need to add a "global" argument so I can change the layer of a
reposit
Hi,
Now that things are starting to move fonts-side[1], I’d like the various
actors to agree on a common font model target.
Without a a common target, we’ll end up working at odds with one
another. Upstream font files can not serve as a an officious target.
They are full of quirks, you end u
Le 2019-07-24 13:49, Akira TAGOH a écrit :
Hi Akira
On Tue, Jul 23, 2019 at 10:45 PM Nicolas Mailhot
wrote:
No foo variable, foo hebrew, foo narrow, foo caption, just a single
foo
with different available features (full variability or fixed states on
the default axis, real upstream provided
Le mercredi 24 juillet 2019 à 14:37 +0200, Kevin Kofler a écrit :
Hi, Kevin
Thank you for taking the time to answer,
> Nicolas Mailhot wrote:
> > 2. fontconfig strives to hide all the legacy ways to designate
> > different
> > parts of this ideal font, and strives to expose a single "font"
> > o
Le mercredi 24 juillet 2019 à 20:05 +0200, Clement Verna a écrit :
> On Wed, 24 Jul 2019 at 16:58, Matthew Miller <
> mat...@fedoraproject.org> wrote:
> > On Wed, Jul 24, 2019 at 07:09:24AM +0200, Clement Verna wrote:
> > > Last couple days a bigger change [2] have been introduced in the
> > > fedo
Le 2019-07-25 12:17, Björn Persson a écrit :
Hit,
An RPM spec is not a place for golfing. Readable code takes priority
over saving keystrokes.
Then it should be implemented cleanly in a declarative syntax,
with %{gpg_signatureX} and %{gpg_keyringX} variables matching
%{sourceX}, and a single
Le 2019-07-31 14:13, Lennart Poettering a écrit :
Hi Lennart
Note that there's a "stable" backport tree maintained outside of the
main repo:
https://github.com/systemd/systemd-stable
Either way, I doubt this discussion is relevant to Fedora, is it?
It was when a lot of users could not test
Le mercredi 31 juillet 2019 à 17:03 +0200, Andreas Tunek a écrit :
>
>
> On Wed, 31 Jul 2019, 16:10 Nicolas Mailhot via devel, <
> devel@lists.fedoraproject.org> wrote:
> > Le 2019-07-31 14:13, Lennart Poettering a écrit :
> >
> > Hi Lennart
> >
> &
Le mercredi 31 juillet 2019 à 12:25 -0500, Jason L Tibbitts III a
écrit :
> > > > > > "KF" == Kevin Fenzi writes:
>
> KF> * If you use metalinks, rpm signatures are just gravy on top, in
> the
> KF> end you are still just trusing SSL CA's.
>
> Only if you trust every mirror to always serve authe
Le mercredi 31 juillet 2019 à 13:34 -0700, Kevin Fenzi a écrit :
> On 7/31/19 12:05 PM, Nicolas Mailhot via devel wrote:
> > Le mercredi 31 juillet 2019 à 12:25 -0500, Jason L Tibbitts III a
> > écrit :
> > > > > > > > "KF" == Kevin Fenzi wri
Le mercredi 31 juillet 2019 à 16:10 -0700, Brian C. Lane a écrit :
> On Wed, Jul 31, 2019 at 09:05:21PM +0200, Nicolas Mailhot via devel
> wrote:
> > Le mercredi 31 juillet 2019 à 12:25 -0500, Jason L Tibbitts III a
> > écrit :
> > > > > > > > "KF&quo
Le mercredi 31 juillet 2019 à 21:05 +, Zbigniew Jędrzejewski-Szmek
a écrit :
> On Wed, Jul 31, 2019 at 08:52:36PM +0200, Nicolas Mailhot via devel
> wrote:
> > And when,
> > finally, systemd makes a new release, it does not even use
> > integrator
> > and automa
Le jeudi 01 août 2019 à 00:27 -0700, Samuel Sieb a écrit :
> On 7/31/19 11:41 PM, Nicolas Mailhot via devel wrote:
> > Le mercredi 31 juillet 2019 à 16:10 -0700, Brian C. Lane a écrit :
> > > If so you can pass
> > > inst.noverifyssl to anaconda to tell it to ignor
101 - 200 of 313 matches
Mail list logo
