organisational thought, to be able to handle gracefully
objective divergences. Because those divergences *will* eventually
happen, and inventing a process at crunch time when things are on fire
and everyone is too busy dealing with the fire to listen to others, is
no fun.
al from a technical POW, its tooling is poor sure but
tooling reflects the values of the community creating and using the
tools, not the reverse.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
lls today did not notice? The next generation
of corp-funded enterprise code will use another language.
Sincerely,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproje
me
upstream git, we are hopping between branches in different forked repos
of the same upstream
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
ithout paying someone to copy and fork the
original code that this bytecode was generated from in the next
project.
The practical effect is technical stagnation and market capture by deep
pocket companies.
--
Nicolas Mailhot
___
dev
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
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
The difference, is that you can build a new kernel, while running an
old kernel. the kernel is not constantly breaking external kernel APIs
like gradle breaks the external gradle APIs a new gradle needs to be
built (when building gradle with gradle, the new build is a consumer of
external gra
kages.
BTW, that’s not a Fedora project limitation. The whole GNOME stack has
been trying for years to reduce the combination complexity, by forcing
the use of a limited number of stacks/runtimes.
--
Nicolas Mailhot
___
devel mailing list -- devel@l
the past.
So, no use looking for non-executable /usr/share. A lot of /usr/share
is executable and will stay that way.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an emai
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
years ago. :-)
It got truer since. The IA stuff people want to replace traditional
computing with is 100% data-driven execution.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
d mix things. Like systemd and rpm
did for multiarch. So if you care about security you’ll still need to
audit the non-executable root. Except the audit will be less painful,
because a lot of stuff would have been sorted by others.
Regards,
--
Nicolas Mailhot
___
nts.
Font work (creation and packaging) takes a lot of commitment and
attention to detail. It's hard to sustain so it comes and goes.
BTW
https://pagure.io/fork/nim/fonts-rpm-macros/commits/master
https://pagure.io/fork/nim/packaging-committee/tree/fonts-rpm-macros
(rebases hide the
e of DoH will serve to find ways to
track and profile you even further.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
h
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
designed to solve such generic situations.
Network management is no longer an enterprise-only concern.
Treating it as a sysadmin problem does not work.
The network happened. And not only internet side.
--
Nicolas Mailhot
___
devel mailing l
recate things
people found useful. Except that's not how actual people want to use
their networks. So all the things that IPv6 authors rejected are
slowly being standardized back because that's what people need.
Regards,
--
Nicolas Mailhot
___
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
few years to give packagers time to apply the new
guidelines.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
h
-rpm-macros for now. They will be
removed in a few years to give packagers time to apply the new
guidelines.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to deve
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
ution.
While that saves time, and insures dev funding, it also means it is
easier to go full power on things that end up requiring deep changes to
get non Red Hat adoption.
It's not anyone's fault, it's the inherent nature of internal and
external dev paths.
Regards,
--
Nicolas Mai
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 automatio
ning constrains into account, will only work for a
short period of time.
Unicorns do not exist in real life.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorapro
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
omplex that not filling this section (of course,
if you take someone else’s spec and it depends on this section, you get
to define BRs manually if you void it)
Regards
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
Creating
a new project around rpm will evolve into something very close to
Fedora/Suse/etc. Creating a new deployment tech within Fedora will
evolve into something very close to rpm (different implementation, same
behaviour).
Changing either Fedora or rpm requires making both the org, and the
rtain that the changes needed
in packages themselves, to provide the additionnal info required by
this solver, will turn out to be minimal.
Without a working solver multiple version streams won’t work out,
upstream has not more clue (and quite often a lot less clue) on what
the dep graph should
at obscures all
dependency chain checks?
Regards,
--
Nicolas Mailhot
___
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/
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
format will exist directly in rpm.
Modules started with the end-user management framework (porcelain)
part, and got lost somewhere trying to decide how to map it to low
level concepts. That, does not work. Start from fundations before
arguing about the roof decorations.
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
> c
at means maintainers of modular things will get the rug
pulled under them whenever the default stream changes in incompatible
ways. Tough luck. The only reliable way we have to coordinate Fedora
activity is this default stream.
Regards,
--
Nicolas Mailhot
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:
>
to make actual mass
rebuilds, triggered by upstream changes, faster.
regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://
ifically inside a stream. And that's just a
Requires: something with stream(streamname)
> * All standard Conflicts/Requires/Obsoletes/… will simply work
Yes, please make it back a single unified rpm-level dependency graph
instead of separate module universes that don't behave wi
ad of moving some package
creation steps outside our the shared and audited build infra.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Co
e the requirements of each plugin from the requirements of the
others
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
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
... I know that I usually
just install all of them on new systems.
TEX includes things shared with the rest of the system (for example
fonts), forcing the users of those things to install a huge TEX blob
just to get the subset they need is not a good user experience.
Regards,
--
Nicolas Ma
do it and find their own contributors. We’ll see if they still
dismiss concerns of current contributors when *they* have to do the
work.”
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an emai
ts.
As long a you do it this way it’s fairly easy to manipulate the
filelist in %build (or even %install) if the automated process made
mistakes.
But, generally, a well tested automated generation process will make
less errors than a human toiling by rote.
Regards,
--
Nicolas Mailhot
__
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
ion worthwhile.
The only people it makes happy are the devs that loathed any community
or
distribution engagement in the first place.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
fairy will ever materialize to contradict
you, is easier design-side. But, it’s 100% a gamble that can (and most
often will) misfire.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to dev
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
e than coping with Linux systems fragmentation.
Trying to invent desktop-only things, when the Linux desktop market
share is marginal, and a large part of this marginal userbase is people
also working on Linux servers, is not likely to succeed.
Regards,
--
Nicolas M
ide are trying to shove all the language bindings in a single
homogeneous hierarchy. That ends up conflicting with the conventions of
each language.
Anything Thrift-related definitely requires a lot of packager care.
Regards,
--
Nicolas Mailhot
___
st
humans.
That’s even the case in ultra-secure environments like the NSA. How do
you think wikileaks happened?
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.or
oose a layout) are not
configured properly by the distribution and will fallback to qwerty.
Really, we should try to change the default to Azerty or the Russian
layout for a release. That would teach qwerty users what is hostile to
users of other layouts or not.
--
Nicolas Mailhot
_
classical technical debt accumulations. Lots of
unhealthy technical compromises, to be first to market, and get adopted
(that worked fine), and no plan to deal with what happens afterwards
(long term maintenance, evolution, and support).
Regards,
--
Nicolas Mailhot
t methods, one for their primary language, the other to
deal with all the latinicisms pushed on them by the ways computers work
today.
American and UK users are the only ones the low-level computer tech has
been designed for. Don’t take them as exemple, they are not
representative.
--
N
participants contains cycle breaking bootstrap conditionals
If that fails, refuse the update and wait till humans deal with the mess
It's not rocket science, I've already described multiple times on this list
how to handle cycles gracefully, because Go is full of those
--
Nicol
package, or you may unadvertently still depend on things
you think you removed
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
not a way to state you're not using
pkgconfig, it's a way to get broken builds when the package you depend
on gets restructured.
rpm filename deps are less reliable than rpm font package deps, which
are themselves less reliable than automatically computed virtual deps
--
Nicol
have default settings.
Default-less unconfigured apps are just painful to use.
Having httpd default to realaudio mime types for rpm files was quite
painful…
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe se
tiple providers
> exists.
>
> One example is pkgconfig(openssl)
In quite a lot of cases versionned requires can disambiguate
Otherwise I suppose it would make sense to add a
Provides: pkgconfig(foo)(default)
in the package providing the primary Fedora implementation
Regards,
--
Nicolas Mail
instances, that are supposed to tell those things to the
generous sponsor, and keep it informed of the real state of its
sponsored project. And, they are clearly failing to pass the message.
Regards,
--
Nicolas Mailhot
___
devel mailing lis
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
edora as a packaging org will become a legacy pile.
rpm, dnf, koji, pagure… they’re all components of the general packaging
experience stack. Dropping some of them means the project as a whole
does not believe in its own future.
Regards,
--
Nicolas Ma
ributors, that’s because they’ve
been tasked to do minimal changes without rocking the boat (and given
the corresponding resources).
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
cursor moved enough x86 kernels are
being retired, there would be nothing wrong in moving this functional
split at another technical level.
Old hardware and new hardware will always exist. Trying to handle both
in a single arch is just going to clash somewhere.
Regards,
--
Nicolas Mailhot
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
s reposync, since one typically wants the system to use
the remote repos once synced, so every repo has one personality for
reposync, and another for the system dnf itself.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproj
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
cros
https://pagure.io/fork/nim/fonts-rpm-macros
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros-noreg/builds/
[5]
https://lists.freedesktop.org/archives/fontconfig/2019-June/006546.html
--
Nicol
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
only in the minimal install, because some users could
not be bothered to select the fonts group when they needed a system
with fonts, and pestered maintainers till a font was added to the
default install (and DejaVu Sans is good value for that, because it
provide
single %gpgverify call that loops over all the
available variables.
With a declarative syntax there is less boilerplate in spec files, the
implementation can be changed later, or even moved outside the build
process, without requiring the rewrite of thousands of spec files
Regards,
--
Nicolas
could not test new Fedora devel kernels for
about a month, because newer kernels exposed a bug in networkd, and the
current systemd release + packaging process was unable to produce a
Fedora devel systemd, that worked with Fedora devel kernels
Regards,
--
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
> >
> &
lities, than the ones we built in our tools. TLS stacks
are heavily biaised towards refusing to connect as soon as something
does not matches their expectations (and they usually forget to tell
you what they didn't like).
--
Nicolas Mailhot
___
devel ma
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
anything else that works for
everyone (and many tried).
The preversion in semver is basically "it will break right and left,
who cares, no one will use it". Written by idealists that forgot the
point of preversions is to be used and deployed so some testing is done
before final release.
--
to reduce confusion.
Therefore, banning the 24:00 notation is necessary for interoperability,
even if one does not agree with the IETF decision. (00:00 however is
well-defined and not ambiguous)
Regards,
--
Nicolas Mailhot
___
devel mailing list -- d
Le 2019-09-02 19:27, Kevin Kofler a écrit :
Nicolas Mailhot via devel wrote:
2. However the IETF explicitely forbid it when defining the ISO 8501
subset allowed on the Internet
RFC 3339> Although ISO 8601 permits the hour to be "24", this profile
of
ISO
RFC 3339> 8601 on
dy manages.
Regards,
--
Nicolas Mailhot
___
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 Guideli
) not explicit package name)
Regards,
--
Nicolas Mailhot
___
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/co
Le 2019-09-13 10:39, Kevin Kofler a écrit :
Nicolas Mailhot via devel wrote:
The correct thing would have been never to create a narrow liberation
subpackage in the first place since narrow is just a face of a font
(like bold).
In theory, in an ideal world, that makes sense. But in practice
Le vendredi 13 septembre 2019 à 12:18 +0200, Kevin Kofler a écrit :
> Nicolas Mailhot via devel wrote:
> > That's an historical artefact, that made sense when everyone used
> > the
> > same dozen font on windows, and when each and everyone of them
> > could
kes harder.
However, because out packa
--
Nicolas Mailhot
___
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-
Le 2020-01-06 19:05, Nicolas Mailhot a écrit :
Handling those checks is where the packaging toil is (that is, as long
as Fedora is a deployment project). It is not something the packaging
format makes harder.
However, because our packaging format streamlines those checks, and
forces to apply
k/Amazon/Microsoft
oligopoly. People feel "free" to switch corporate masters, they to not
feel the urge to make commons work.
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@
t that good marketing has something to do with it.
They had good marketing in the form of a billionaire publicly showering
cash around “in the public interest”. The press (especially the non-
technical press) loves this kind of story. Unfortunately, it’s not
something cheap or easy to replic
Le mardi 07 janvier 2020 à 18:37 +0100, Clement Verna a écrit :
>
>
> On Tue, Jan 7, 2020, 18:21 Nicolas Mailhot via devel <
> devel@lists.fedoraproject.org> wrote:
> > Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit :
> > >
> > > I'm
without swap, with or without heavy
copying. The kernel does not seem to understand the difference between
latency-sensitive usb input and throughput-sensitive non input usb
traffic.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel
in slightly different
conditions, but also triggers app bugs. The old files are not
"harmless".
> As it stands, having more than *.otb causes the weird hex number
> rectangle glyph "Terminus Italic",
Regards,
--
Nicolas Mailhot
_
901 - 1000 of 1099 matches
Mail list logo
