> > Why those vectorised resources are only available as TeX users?
> > Why TeX is not prepared to use system wide Type1 font and is not able to
> > share those fonts with other applications?
> > Why most Type1/TTF fonts are at least served three times as: ghoscript
> > fonts, X11/Weyland fonts and
On 10/15/2016 02:21 PM, Gerard Ryan wrote:
> Hi all,
>
> I no longer use the following packages nor have the time to maintain
> them, so I'm going to orphan them:
Adopted:
aether-connector-okhttp
eclipse-m2e-core
maven-indexer
port-allocator-maven-plugin
--
Mikolaj Izdebski
Software Engineer,
On 10/16/2016 07:15 PM, Matthew Miller wrote:
On Sat, Oct 15, 2016 at 09:26:36PM +0100, Tomasz Kłoczko wrote:
3) Package *only* what is really need or requested by at last one person
What exactly is the *harm* in having things you are not using packaged
in Fedora? How does it affect you (or an
On 10/17/2016 06:46 AM, Tim Flink wrote:
On Mon, 3 Oct 2016 13:50:33 -0600
Tim Flink wrote:
One of the features for Taskotron that we've been planning since the
beginning was a way for contributors to maintain their own automated
tasks/tests which would be run during a package's lifecycle.
I'
Hi all,
I have a small parallelization library for review [1]. Any volunteers?
Cheers,
Christoph
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1382755
--
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedor
Am Sonntag, den 16.10.2016, 20:00 +0200 schrieb Kalev Lember:
> On 10/04/2016 10:18 AM, Björn Esser wrote:
> > All packages have been rebuilt, except for 'paraview', which FTBFS
> > [1]
> > [2]. It seems it needs a little patching for some small change in
> > jsoncpp. I will do that during the ne
Hi,
I plan to rebase poppler in rawhide to poppler-0.48.0 at Friday.
There are several API changes and soname bump of the base library
libpoppler.so.*.
I've prepared a scratch build of poppler-0.48.0 against which you can
test your packages. You can find the build here:
http://koji.fedoraprojec
On Mon, Oct 17, 2016 at 10:48:54AM +0200, Florian Weimer wrote:
> >>3) Package *only* what is really need or requested by at last one person
> >What exactly is the *harm* in having things you are not using packaged
> >in Fedora? How does it affect you (or any other user of Fedora) if the
> >number
On Mon, Oct 17, 2016 at 5:28 AM, Matthew Miller
wrote:
> On Mon, Oct 17, 2016 at 10:48:54AM +0200, Florian Weimer wrote:
> > >>3) Package *only* what is really need or requested by at last one
> person
> > >What exactly is the *harm* in having things you are not using packaged
> > >in Fedora? How
On Fri, Oct 14, 2016 at 1:24 AM, Florian Weimer wrote:
> On 10/14/2016 01:15 AM, Samuel Sieb wrote:
>
>> On 10/13/2016 12:04 PM, Richard Shaw wrote:
>>
>>> The following workaround was suggested by upstream and seemed to do the
>>> trick but upstream doesn't want to perform needless initializatio
On 10/17/2016 03:08 PM, Richard Shaw wrote:
On Fri, Oct 14, 2016 at 1:24 AM, Florian Weimer wrote:
On 10/14/2016 01:15 AM, Samuel Sieb wrote:
On 10/13/2016 12:04 PM, Richard Shaw wrote:
The following workaround was suggested by upstream and seemed to do the
trick but upstream doesn't want
2016-10-16 21:25 GMT+02:00 David Tardon :
> Hi,
>
> On Sat, Oct 08, 2016 at 12:16:53PM +0200, Philippe Makowski wrote:
> > Hi,
> >
> > Firebird 3.0.1 is released, I can upgrade the package in Fedora, I have a
> > Copr repo with it :
> > https://copr.fedorainfracloud.org/coprs/makowski/firebird/
>
On Mon, Oct 17, 2016 at 8:11 AM, Florian Weimer wrote:
> On 10/17/2016 03:08 PM, Richard Shaw wrote:
>
>>
>> Any specific recommendations for this issue? Should the variables be
>> initialized on x86_64 too or some kind of conditional implemented?
>>
>
> What's the definition of the float4 type?
Took nodejs-* packages.
Zuzka
- Original Message -
From: "Gerard Ryan"
To: devel@lists.fedoraproject.org
Sent: Saturday, October 15, 2016 2:21:44 PM
Subject: Orphaning packages
Hi all,
I no longer use the following packages nor have the time to maintain
them, so I'm going to orphan the
On Fri, Oct 14, 2016 at 03:00:58PM -0600, Nathanael D. Noblet wrote:
> On Thu, 2016-10-06 at 14:02 -0500, Dan Williams wrote:
> >
> > Try running 'iptables-save' before you start docker, and then running
> > 'iptables-save' after. Diff the results. Did docker remove
> > anything?
>
> Hello,
>
python-sep-1.0.0-1 has changed its license from "MIT and LGPLv3+" to
"MIT and BSD and LGPLv3+"
Regards
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
On 15 October 2016 at 23:38, Matěj Cepl wrote:
> On 2016-10-15, 21:55 GMT, Ian Malone wrote:
> to be one Red Hat employee who did a lot of TeXLive maintenance
> (not much how much in his free time), but he is gone from Red
> Hat and now the main maintainer is spot. He is my hero, but take
> a loo
Change in package status over the last 168 hours
26 packages were orphaned
-
ascend [master] was orphaned by sagitter
ASCEND modelling environment
https://admin.fedoraproject.org/pkgdb/package/ascend
eclipse-webtool
Start Date: 2016-10-10 10:08:01.749633
End Date: 2016-10-17 10:08:01.749633
Kevin Fenzi : 3
https://bugzilla.redhat.com/show_bug.cgi?id=1383445
python-requests_ntlm
https://bugzilla.redhat.com/show_bug.cgi?id=1382989 mirrormanager2
https://bugzilla.redhat.com/show
Missing expected images:
Workstation live i386
Workstation live x86_64
Failed openQA tests: 9/92 (x86_64), 3/16 (i386), 1/2 (arm)
New failures (same test did not fail in Rawhide-20161016.n.0):
ID: 41806 Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/t
Hi,
during last FPC meeting we agreed[0] that we need some standardization
of macro related to builds where builddir != srcdir (and with
possibility to make it builddir = srcdir).
I was working to make guidelines for ninja and meson. For ninja it
doesn't matter from where you build (it's like mak
On 10/17/2016 04:37 PM, Igor Gnatenko wrote:
Hi,
during last FPC meeting we agreed[0] that we need some standardization
of macro related to builds where builddir != srcdir (and with
possibility to make it builddir = srcdir).
I was working to make guidelines for ninja and meson. For ninja it
doe
On 17 October 2016 at 15:37, Igor Gnatenko wrote:
> during last FPC meeting we agreed[0] that we need some standardization
> of macro related to builds where builddir != srcdir (and with
> possibility to make it builddir = srcdir).
>
May I ask why? Is it any particular reason investing time on t
Update for engrid and passenger:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-a7aec14960
Test, if rebuild was successful and give karma, please. =)
Cheers,
Björn
Am Montag, den 17.10.2016, 12:50 +0200 schrieb Björn
> Am Sonntag, den 16.10.2016, 20:00 +0200 schrieb Kalev Lember:
> > O
Announcing the creation of a new nightly release validation test event
for Fedora 25 Branched 20161017.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
OLD: Fedora-25-20161016.n.0
NEW: Fedora-25-20161017.n.0
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 4
Dropped packages:0
Upgraded packages: 36
Downgraded packages: 0
Size of added packages: 1.26 MiB
Size of dropped packages:0.00 B
Size of
On Mon, 17 Oct 2016 11:16:22 +0200
Pavol Babincak wrote:
> On 10/17/2016 06:46 AM, Tim Flink wrote:
> > On Mon, 3 Oct 2016 13:50:33 -0600
> > Tim Flink wrote:
> >
> >> One of the features for Taskotron that we've been planning since
> >> the beginning was a way for contributors to maintain the
On Mon, Oct 17, 2016 at 09:42:51AM -0600, Tim Flink wrote:
> One of the differences in Fedora is that I expect most check/test
> contributions will come from package maintainers instead of dedicated
> QA folks. At this time, there just aren't enough available person hours
> among the Fedora QA folk
No missing expected images.
Failed openQA tests: 8/103 (x86_64), 1/17 (i386), 1/2 (arm)
New failures (same test did not fail in 25-20161016.n.0):
ID: 41940 Test: arm Minimal-raw_xz-raw.xz
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/41940
ID: 41956
On Mon, Oct 17, 2016 at 11:56:35AM -0400, Matthew Miller wrote:
> On Mon, Oct 17, 2016 at 09:42:51AM -0600, Tim Flink wrote:
> > One of the differences in Fedora is that I expect most check/test
> > contributions will come from package maintainers instead of dedicated
> > QA folks. At this time, th
On Mon, Oct 17, 2016 at 04:38:28PM +, Zbigniew Jędrzejewski-Szmek wrote:
> It's a good principle to require both tests and fixes required for
> those tests to pass to be submitted and merged as a single pull request.
> I'd love to see a PR that adds a test for one of my packages, exposes
> some
On Mon, Oct 17, 2016 at 12:45:30PM -0400, Matthew Miller wrote:
> On Mon, Oct 17, 2016 at 04:38:28PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > It's a good principle to require both tests and fixes required for
> > those tests to pass to be submitted and merged as a single pull request.
> > I'd
On Mon, 17 Oct 2016 17:18:25 +
Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Oct 17, 2016 at 12:45:30PM -0400, Matthew Miller wrote:
> > On Mon, Oct 17, 2016 at 04:38:28PM +, Zbigniew
> > Jędrzejewski-Szmek wrote:
> > > It's a good principle to require both tests and fixes required for
>
On Mon, 17 Oct 2016 11:56:35 -0400
Matthew Miller wrote:
> On Mon, Oct 17, 2016 at 09:42:51AM -0600, Tim Flink wrote:
> > One of the differences in Fedora is that I expect most check/test
> > contributions will come from package maintainers instead of
> > dedicated QA folks. At this time, there j
On Mon, Oct 17, 2016 at 05:18:25PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > those tests to pass to be submitted and merged as a single pull request.
> > > I'd love to see a PR that adds a test for one of my packages, exposes
> > > some bugs, but immediately fixes any fallout. I would be less
On Mon, Oct 17, 2016 at 11:57:03AM -0600, Tim Flink wrote:
> If we do keep going toward the goal of having more automation support
> for testing and gating builds from koji based on results from that
> automation, I don't understand how it makes sense to let more people
> have write access to the c
> Audacious 3.8 is landing in Rawhide and will need rebuilds of any
> external plugin packages, because the plugin API has changed again.
>
> You can find working rpms in fedora copr (or koji):
> https://copr.fedorainfracloud.org/coprs/mschwendt/audacious-next/
Has anyone used it yet or any objec
Hi all,
Now that I'm loving f25beta so much and refuse to go back to f24 I'm forced
to address a problem I've had for some time. Up through f24 I've had to
install the nvidia proprietary driver to be able to use more than 2
monitors on my GTX960 (if I connected more than 2 it locked up the machine
On Mon, 2016-10-17 at 16:58 -0600, patrick korsnick wrote:
> Hi all,
>
> Now that I'm loving f25beta so much and refuse to go back to f24 I'm forced
> to address a problem I've had for some time. Up through f24 I've had to
> install the nvidia proprietary driver to be able to use more than 2
> mon
On Tue, 18 Oct 2016 00:04:37 +0200
Michael Schwendt wrote:
> > Audacious 3.8 is landing in Rawhide and will need rebuilds of any
> > external plugin packages, because the plugin API has changed again.
> >
> > You can find working rpms in fedora copr (or koji):
> > https://copr.fedorainfracloud.o
Dear all,
You are kindly invited to the meeting:
Modularity WG on 2016-10-18 from 15:00:00 to 16:00:00 UTC
At fedora-meetin...@irc.freenode.net
The meeting will be about:
Meeting for the Modularity Working Group.
More information available at: [Modularity Working Group wiki
page](https://
Dear all,
You are kindly invited to the meeting:
Modularity WG on 2016-10-18 from 15:00:00 to 16:00:00 UTC
At fedora-meetin...@irc.freenode.net
The meeting will be about:
Meeting for the Modularity Working Group.
More information available at: [Modularity Working Group wiki
page](https://
The hardcoded upper limit of 16 jobs, passed to make via "-j" when you
use either %make_build or make %{?_smp_mflags} in the %build section of
your specfiles, is going away in rawhide. This may result in your jobs
being run with additional parallelization in some situations.
This change will appe
Dne 17.10.2016 v 06:46 Tim Flink napsal(a):
> Which brings me to the question that I'd like to get some feedback
> on: would it be preferable to store checks/tests within directories of
> existing dist-git repos or create a new namespace to store checks/tests
> and fiddle around with tooling etc.
44 matches
Mail list logo
