In the fmt.spec you posted, I see
>
> %mingw_cmake -G Ninja [...]
>
> this means that you are generating ninja build scripts, not Makefiles. If
> you want to use ninja, you should call
>
> %mingw_ninja
>
> after %mingw_cmake -G Ninja.
>
Thanks! That appears to be the right thing for the %build sec
I'm trying to add mingw build support to the fmt package spec. I've done
this previously with the pugixml and zipios packages, and submitted the
spec diffs to the package maintainer of those.. Both packages use cmake.
Both in the %build section use %cmake then %cmake_build, and in the
%install sect
What macro(s) should I use in an RPM spec to refer to a directory like
/usr/lib/modules-load.d, which is under /usr/lib even if libdir is
/usr/lib64? Is there something better than %{_usr}/lib/modules-load.d?
___
devel mailing list -- devel@lists.fedorap
Resurrecting a very old thread:
On Tue, May 13, 2014 at 11:02 AM, Jakub Jelinek wrote:
> On Tue, May 13, 2014 at 06:56:40PM +0200, Sandro Mani wrote:
> > apitrace 5.0 bundles libbacktrace, which looks like is living within
> > the gcc sources. libbacktrace is not build as a shared library from
>
On Mon, Dec 19, 2016 at 3:59 PM, Igor Gnatenko wrote:
> I found only one cross-compiler in repos -- arm-none-eabi-gcc-cs
>
> But it doesn't work:
This package is compiled in bootstrap mode and used only to solve circular
> build dependency. You don't want to use this package. It's not expected t
On Tue, Dec 13, 2016 at 4:38 PM, Orion Poplawski
wrote:
> Actually, you do need some more BuildRequires:
> but I can't reproduce your ghc() issue on EL7 or F25.
Thanks for looking at it! With your suggested BuildRequires, scratch builds
on Koji succeed for both F24 and F25, but the resulting F2
I'm trying to package BNFC, a Haskell program to translate labelled BNF
grammars to lexer and parser specifications for common lexer and parser
generators (Alex, JLex, Flex, Happy, CUP, and Bison). I've tried to follow
the Haskell packaging guidelines. My package builds locally, and if I
install it
On Sun, Mar 22, 2015 at 11:17 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> zfs-import-cache.service has After=cryptsetup.target, and
> zfs-mount.service has After=zfs-import-cache.service, so the ordering should
> be there.
Interesting, I didn't notice that the scripts in github already had
the "Aft
On Sun, Mar 22, 2015 at 9:15 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> I vaguely recall that zfsonlinux did some very strange things. How
> do the units you are using look?
These are the three that I think are relevant:
https://github.com/zfsonlinux/zfs/blob/master/etc/systemd/system/zfs-impor
On Sat, Mar 21, 2015 at 4:37 AM, Corey Sheldon wrote:
> did you rebuild the initramfs and /or initrd after this change?
I didn't. I'm not using ZFS on root (or anything else needed during
boot), so I didn't think that was necessary. I'll give it a try.
Thanks for the suggestion.
--
devel mailing
I'm using a non-Fedora filesystem (zfsonlinux) which provides
appropriate services and a target for systemd. The services state:
Requires=systemd-udev-settle.service
After=systemd-udev-settle.service
This works fine for basic usage, but if trying to use zfs over
dmcrypt/LUKS, the mount se
I think it's a great idea. IntelliJ is the basis for the new Android dev
env (though Eclipse can still be used). I looked at trying to package it
again, but as you say it looks like a pretty big task.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listi
On Sat, Jul 19, 2014 at 7:12 PM, Richard Shaw wrote:
> On Sat, Jul 19, 2014 at 7:20 PM, Eric Smith wrote:
>> That could lead to packages that happen to build some of the time due
>> to an undetected dependency on something that isn't in the BR but
>> happens to be in a
On Sat, Jul 19, 2014 at 7:26 AM, Richard Shaw wrote:
> How about not rebuilding the chroot every time... It's not like you have to
> worry about leftover BR's from building another package.
That could lead to packages that happen to build some of the time due
to an undetected dependency on someth
On Sat, Jul 19, 2014 at 5:30 AM, Richard W.M. Jones wrote:
> (1) Limit the use of macros in Source lines, so that only a simple,
> standard, perhaps pre-cached buildroot can be used.
How about just trying to parse the Source lines, and if that fails due
to use of macros that can't be evaluated in
On Mon, Jun 16, 2014 at 12:57 AM, Kalev Lember
wrote:
> Otherwise it could create a situation where software developed
> on Fedora relies on .pc files and doesn't work on other distros, and the
> other way around: software developed on other distros won't use the nice
> pkg-config integration ava
On Sun, Jun 15, 2014 at 4:16 PM, Kevin Kofler
wrote:
> Eric Smith wrote:
> > I don't really understand how this is "adding to the API" or results in
> > incompatibilities. Do other people think that doing this is a mistake?
> > Would it actually be bette
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Because a new version of the Free42 calculator has switched to the Intel
decimal floating point library (an implementation of the decimal part of
IEEE-754), I'm working on packaging it:
https://bugzilla.redhat.com/show_bug.cgi?id=1098820
Intel supplies it as portable code intended to be linke
On Thu, Jun 12, 2014 at 12:05 PM, Yaakov Selkowitz
wrote:
> IMHO it would be nice if this could stay in, but I'm not a Fedora packager
> (yet? :-).
FWIW, I just posted a patch for the FTBFS:
I'll take over the 1.x pre-smalltalk package, incorporate your patch
(thanks for that!), and otherwise
On Tue, Jun 10, 2014 at 5:49 PM, Kevin Kofler
wrote:
> Hunting for patents is one thing (I wouldn't recommend it either), but
> looking for obviously patent-encumbered stuff (like MP3 codecs) is another
> .
Unfortunately it is generally not obvious what things are "obviously
patent-encumbered".
On Mon, Jun 9, 2014 at 10:50 AM, Isaac Cortés González <
w.isaac.cor...@gmail.com> wrote:
> So, should I just clone the git repositories and build from those raw
> sources?
>
Sounds reasonable to me.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/list
On Sun, Jun 8, 2014 at 8:36 PM, Isaac Cortés González <
w.isaac.cor...@gmail.com> wrote:
> I can look for any "patented" or closed source software
>
IANAL, but multiple lawyers have told me that it is generally a bad idea to
go looking for patents, at least in the US. If they're brought to your
On Mon, Apr 28, 2014 at 2:24 AM, Florian Weimer wrote:
> On 04/28/2014 09:52 AM, Nikos Mavrogiannopoulos wrote:
>
> setjmp and longjmp are tools, that one may use in a good or bad way.
>> Along the same lines one could argue for dropping programs that use goto
>> in Fedora (because everyone know
In bug #1079767, it is requested that the default configuration for pam_abl
be changed such that multiple root login failures from a network host will
(temporarily) blacklist that host. The existing default configuration
deliberately does not do that, due to potential for a Denial of Service.
For
On Fri, Mar 21, 2014 at 8:07 PM, Lennart Poettering wrote:
> You do realize that if software engineering has shown something then
> yes, software development is never finished, it's a process. You do need
> maintains for such things.
>
The software in my microwave oven, coffee maker, thermostat,
On Feb 13, 2014 4:29 PM, "Sandro Mani" wrote:
> On 14.02.2014 00:12, Eric Smith wrote:
>> but several people suggested that it would be better to wait for OCE
(downstream) to be rebased on the new OpenCASCADE release, and the OCE
package to be moved from RPM Fusion into Fed
I wrote:
> but several people suggested that it would be better to wait for OCE
(downstream) to be rebased on the new OpenCASCADE release, and the OCE
package to be moved from RPM Fusion into Fedora.
I see that OCE 0.15 was released yesterday, and is now based on the
upstream OpenCASCADE 6.7.0, wh
but stalled of since it's quite an effort.
Anyone else interested in joining the effort?
>
> Eric Smith is packaging it already.
I asked on the Fedora Legal list whether it was OK to package it with the
new license, and the answer was yes. I worked on an RPM, but several people
sug
On Jan 24, 2014 10:29 AM, "Kevin Fenzi" wrote:
> The things they are working on have been known for years, but our 6
> month release cycle with no hope of being able to work on tooling
> hasn't allowed them to do so.
Thanks for the clarification. I'm certainly on board with lengthening a
release
On Jan 23, 2014 2:33 PM, "Kevin Fenzi" wrote:
>
> On Thu, 23 Jan 2014 19:03:02 +0100
> Thorsten Leemhuis wrote:
> > I'm still undecided if I overall like Fedora.next or fear it. But more
> > and more I tend to the latter position and wonder if it might be wise
> > to slow things down: Do one more
The problem was that it was non-executable. Thanks for the help!
On Fri, Nov 29, 2013 at 2:13 PM, Michael Schwendt wrote:
> On Fri, 29 Nov 2013 13:26:20 -0700, Eric Smith wrote:
>
> > I'm having a bit of trouble with RPM dependencies. I'm trying to package
> > faif
I'm having a bit of trouble with RPM dependencies. I'm trying to package
faifa, which manages HomePlug AV interfaces. There's a library (libfaifa)
and two executables, faifa and hpav_cfg. I'm putting the executables in
the main package (faifa), the shared library in a -libs subpackage, and the
h
On Thu, Jul 25, 2013 at 4:54 PM, Reindl Harald wrote:
> i really do not justify my decisions inside support cycles
> because *you* quote out of context and sound like "booh nobody
> is running Fedora in production"
And I didn't say that nobody is running Fedora in production.
--
devel mailing li
On Thu, Jul 25, 2013 at 4:14 PM, Adam Williamson wrote:
> On Thu, 2013-07-25 at 16:04 -0600, Eric Smith wrote:
>> On Thu, Jul 25, 2013 at 12:57 PM, Reindl Harald
>> wrote:
>> > if that would be the case i would not run Apache 2.4, and Zend Opcache
>> > in produc
On Thu, Jul 25, 2013 at 12:57 PM, Reindl Harald wrote:
> if that would be the case i would not run Apache 2.4, and Zend Opcache
> in production on Fdora 17
I wouldn't run *anything* in production on Fedora 17. That's what the
downstream "enterprise" distributions are for.
--
devel mailing list
d
On Mon, Jul 22, 2013 at 10:52 AM, "Jóhann B. Guðmundsson"
wrote:
> On 07/22/2013 04:41 PM, Stephen Gallagher wrote:
>> They chose to use a _downstream_ distribution. RHEL *is* Fedora, it's
>> just a Fedora that's been hardened and held to a certain level of
>> ABI/API compatibility.
> Which is my
On Thu, Jul 18, 2013 at 10:11 AM, James Hogarth wrote:
> Then you were not using it with a default installed Fedora anyway which has
> a default of LVM in place
I don't remember why there wasn't LVM. I don't remember whether I was
the one that installed Linux on that machine in the first place.
On Thu, Jul 18, 2013 at 9:54 AM, "Jóhann B. Guðmundsson"
wrote:
> Why not read this files on another Fedora host ( or some other distro that
> uses systemd )?
> What's the reason for this hard dependency on Windows?
Because I was about six hundred miles away from my office, didn't want
to take th
On Thu, Jul 18, 2013 at 1:56 AM, James Hogarth wrote:
>
>> > Oh how do you get your logs to read in windows from your lvm/ext4/btrfs
>> > filesystems currently in a disk boot scenario?
>>
>> Using ext2fsd:
>> http://www.ext2fsd.com
>>
>
> ... I'd suggest you read that page and then look at
On Jul 18, 2013 12:22 AM, "James Hogarth" wrote:
> Oh how do you get your logs to read in windows from your lvm/ext4/btrfs
filesystems currently in a disk boot scenario?
Using ext2fsd:
http://www.ext2fsd.com
Eric
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedorapr
On Wed, Jul 17, 2013 at 8:39 AM, "Jóhann B. Guðmundsson"
wrote:
> Allowing editing of log files is a pure security risk...
So is giving a sysadmin the root password, but we do it.
I generally make a copy of a log file and edit the copy, but I'd
oppose anything that took away the ability for log
On Wed, Jul 17, 2013 at 8:32 AM, drago01 wrote:
> On Wed, Jul 17, 2013 at 3:58 PM, Denys Vlasenko wrote:
>> Progress happens by removing stuff which works?
> Yes and replacing it by stuff that's better.
> You know people know use cars rather then horses. Not because horses
> stopped working but b
On Tue, Jul 16, 2013 at 6:13 PM, Matthew Miller
wrote:
> On Tue, Jul 16, 2013 at 08:58:40PM -0400, Ding Yi Chen wrote:
>> You still have not addressed the third party programs and scripts
>> that monitor /var/log/messages
> A) If someone is installing a program that expects this file, they can als
On Tue, Jul 16, 2013 at 2:22 PM, Reindl Harald wrote:
> /bin/sh is *not* a bash script
> /bin/sh is *whatever* your default shell would be
I certainly hope not. I've worked on plenty of Unix machines where
the default shell was csh or tcsh, but if /bin/sh had been csh or a
link to it, all hell w
On Tue, Jul 16, 2013 at 2:06 PM, Chris Adams wrote:
> I don't like things that have differing
> behavior between a TTY and a pipe.
I don't either, but that battle was lost many years ago with the 'ls'
command, which defaults to columnar output to a tty but not to a pipe.
Eric
--
devel mailing l
On Jul 15, 2013 5:51 PM, "Lennart Poettering" wrote:
>
> On Tue, 16.07.13 09:13, Dan Fruehauf (malko...@gmail.com) wrote:
>
> > > Well, there are certain things on Unix that are text files and many
> > > things that are not. Binary log files have a long tradition on Unix,
for
> > > example in wtmp
On Mon, Jul 15, 2013 at 3:53 PM, "Jóhann B. Guðmundsson"
wrote:
> And honestly I dont understand why people are ack/nack-ing this since this
> is FESCO decision
Some of us would like to think that FESCO members might be influenced
by arguments made on the development list. Maybe that's just wish
On Mon, Jul 15, 2013 at 3:46 PM, Lennart Poettering
wrote:
> But this specific usecase certainly warranted this, and the
> journal does deliver the requirements we cared for.
I'm sure it does. But I think those requirements mainly apply to
servers and enterprise installations, not the average Fe
On Mon, Jul 15, 2013 at 3:45 PM, Till Maas wrote:
> Oh, sorry, I was imprecise. Bash actually tells you when new mail is put
> into the spool. E.g. if you log in as root, touch /var/spool/root and
> wait up to 60 seconds and run e.g. ls, bash should tell you that there
> is new mail before the nex
On Mon, Jul 15, 2013 at 3:31 PM, Robert Nichols
wrote:
> So, all users on a multi-user system are now expected to dig through
> syslog output to see the output from their cron jobs?
A fair point, but in my experience the most common case is a
single-user system where the user doesn't even use cro
On Mon, Jul 15, 2013 at 3:21 PM, Lennart Poettering
wrote:
> (But
> really, the comparison is just wrong, since the registry is a
> configuration store, and not a log store.)
It's not a perfect analogy, yet the arguments for both seem very
similar, which is why I brought it up. We should try to l
On Mon, Jul 15, 2013 at 3:14 PM, Till Maas wrote:
> But the information cron sends via email is usually more important than
> the regular log entries, because output in cron jobs usually means there
> is an error. It seems wrong to store the important data hidden among
> less important data.
Then
On Mon, Jul 15, 2013 at 3:12 PM, Till Maas wrote:
> Bash usually tells you when there is mail in the spool, which is IMHO a
> big difference to /dev/null.
Funny, I just ssh'd into my machine, and it didn't tell me anything
about mail being in the spool, but when I do an ls on the spool
directory,
On Mon, Jul 15, 2013 at 3:06 PM, Lennart Poettering
wrote:
> On Mon, 15.07.13 14:53, Eric Smith (brouh...@fedoraproject.org) wrote:
>> If we go to having only binary logs by default, maybe we should also
>> go to having only binary configuration files by default. It's
&
On Mon, Jul 15, 2013 at 3:06 PM, Lennart Poettering
wrote:
> It's a matter of finding the right balance: i.e. what can be text files,
> and where we have to win more by making it binary. I am pretty sure this
> is a case where we win more by sticking to binary files. It's totally
> fine if you dis
On Mon, Jul 15, 2013 at 2:53 PM, Matthew Miller
wrote:
> I just want to look at the file without having to learn to type journalctl
> isn't very compelling to me, even though I do recognize the change cost.
>
> However, the diagnostic value of an easily-accessible /var/log/messages is
> pretty hig
On Mon, Jul 15, 2013 at 2:43 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> So removing the binary journal has huge downsides.
I don't dispute that removing it would have a downside. I might
dispute that the downside is "huge", but for now I'll let that pass.
> The need for
> /var/log/messages filter
On Mon, Jul 15, 2013 at 2:40 PM, Lennart Poettering
wrote:
> We created the journal with real
> usecases in mind, and we are not giving those up.
I don't actually care whether there's a binary journal or not, but far
more of us have real usecases for /var/log/messages, so we shouldn't
give up tha
> One process less in the system → faster bootup.
As has been pointed out, it could easily be the systemd journal
process that writes to /var/log/messages, so there wouldn't
necessarily be one fewer process.
> Logs not duplicated → less disk usage.
True. So keep /var/log/messages and make the bi
On Mon, Jul 15, 2013 at 12:01 PM, Lennart Poettering
wrote:
> (Just to mention this: we are neither the pioneer on the
> no-default-syslog feature nor on no-default-sendmail... A lot of other
> distros stopped installing an MTA by default a long time ago --
> including Ubuntu since 2007 or so -- a
On Mon, Jul 15, 2013 at 11:50 AM, DJ Delorie wrote:
> I worry about the security implications of mail that would have gone
> to root@ being either silently discarded or unknowingly ignored.
>
> If there is no other way to send mail to local users, we should have a
> local MTA configured for such.
I vote against this proposal as stated.
I want all the systems I administer to have a /var/log/messages
without any special configuration having to be done. I don't care
whether /var/log/messages is written by syslog or systemd journal, as
long as it has essentially the same text-based format as
+1 for this proposal.
One of the first steps I take after installing Fedora on a new machine
is to remove the MTA. It would be nice for this to be the default.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Jun 20, 2013 at 3:27 PM, Reindl Harald wrote:
> yes - why was such a basic service *not* a systemd-unit
> at the F15 release-day?
>
> in my understanding of develop quality software this
> would not have happened and systemd at all not be
> shipped as replacement until the rest of the dist
Does NM in F19 support statically assigning multiple subnets to the
same physical interface, WITHOUT using VLANs? I often need that on
server machines, and wasn't able to figure out any way to do it with
NM on F17, but I haven't yet tried it on F19.
With the old-style network configuration, it wa
On Tue, Jun 18, 2013 at 11:29 PM, Dhiru Kholia wrote:
> Some recent news,
>
> http://www.theregister.co.uk/2013/06/14/java_june_critical_patch_update/
>
> "The majority are vulnerable through browser plugins, 11 of which are
> exploitable for complete control of the underlying operating system,"
>
On Wed, Jun 19, 2013 at 4:23 AM, Nicolas Mailhot
wrote:
> You don't need a special trigger. You need your requirements to match the
> constraints declared at the rpm level, then incompatibilities will be
> caught at this level by normal distro tooling.
How does that work? A pointer to the docs i
On Mon, Jun 17, 2013 at 1:57 PM, Jeffrey Ollie wrote:
> In no way should packagers be expected to provide end-user support for
> packages, be an expert in every aspect of a package, or be expected to
> work with upstream to debug issues because the end user is unwilling
> to do the work themselves
On Mon, 17 Jun 2013 11:46:13 -0600 Eric Smith
wrote:
> Is the source code of the Red Hat Bugzilla instance published
> somewhere? A quick search didn't turn it up.
On Mon, Jun 17, 2013 at 1:18 PM, Kevin Fenzi wrote:
> It's very close to upstream bugzilla 4.4 at this point I
Is the source code of the Red Hat Bugzilla instance published
somewhere? A quick search didn't turn it up.
Eric
On Mon, Jun 17, 2013 at 11:45 AM, Eric Smith wrote:
> Is the source code of the Red Hat Bugzilla instance published
> somewhere? A quick search didn't turn it up.
&
Adam Williamson wrote:
> If I were you I'd just look at any app that's still using consolehelper
> and working, and copy its configuration. Shouldn't be too hard.
Makes sense. I already have mtr-gtk installed, and it uses
consolehelper. As it happens, it exhibits the same behavior, and uses
an
I have no idea how it's happening, but I do seem to get another pair
of these messages to /var/log/messages every time I click on
gsmartcontrol in the menu.
On Thu, Jun 13, 2013 at 9:19 AM, Eric Smith wrote:
> I have no idea how it's happening, but I do seem to get another pa
I have gsmartcontrol working with consolehelper in F17, but it fails
to launch in F18 and F19, and logs messages like this:
Jun 12 19:33:30 localhost /etc/gdm/Xsession[2594]: The password you typed is in\
valid.
Jun 12 19:33:30 localhost /etc/gdm/Xsession[2594]: Please try again.
I suspect that t
Tomasz Torcz wrote:
You need either to classify device in udev rules or tag it with "uaccess".
I made a writeup some time ago:
http://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/
I hope it helps.
Thanks Tomasz! That was extremely helpful! It completely solved my
ud
I'm trying to package something that talks to a USB device. Upstream has
a udev rule that uses the group "plugdev", which apparently is not used
in Fedora, and I've seen advice to instead use an ACL_MANAGE variable
and a udev-acl executable. However, I can't find any documentation on
either, a
On 01/28/2013 09:56 AM, inode0 wrote:
After four releases it isn't bad to step back and take a look at how
things are working out. I hope we can do that with an eye to where we
want to go in the future rather than looking to the past.
I couldn't have said it better. I'm much more concerned ab
On 01/28/2013 09:27 AM, Peter Robinson wrote:
The gnome desktop certainly isn't perfect but I see a lot more users
using it than most of the rest of the other options.
That's selection bias. It's the default, so of course it's going to get
more users. That doesn't necessarily mean that they
On 01/29/2013 05:25 AM, Dan Mashal wrote:
Lets have a poll. A very public one.
On the main website. Not somebody's blog. And let's let the users
decide what they want.
I'll tell you what, last time I checked #1 spin is KDE.
I like that idea. It's ultimately up to FESCo to decide, but a po
On 01/28/2013 08:47 AM, Máirín Duffy wrote:
I think switching the desktop that has been our default for over 10
years and 18 releases requires just a bit more research and reason
than that. ~m
I don't disagree with the "more research and reason" part, but the
current default desktop has only
Kevin Fenzi wrote:
See:
http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Binary_Firmware
Ralf Ertzinger wrote:
Question about that: The first requirement is that the file is
non-executable. Does that mean that Fedora cannot ship firmware for
hardware that has a CPU compatible with
Rahul Bhalerao wrote:
Is there a build compatible with WM8650 ARM 926 EJ-S or Cortex Nuvoton M0?
It is nearly guaranteed that there will never be a Fedora build for a
Cortex-M0 from any vendor. Or Cortex-M1, M3, or M4. The Cortex-M and
Cortex-R series cores don't have an MMU, so they can't
Seth Johnson wrote:
The positive/negative right formulation is a post-New Deal notion,
rooted in the question of whether it has been textually granted --
very different from the notion that we hold rights prior to
government.
Nevertheless, even prior to that formulation rights like freedom of t
I wrote:
I would claim that the moral right to run whatever software we wish on
hardware we own is a negative right; it doesn't put any obligation on
another party to help you do it. If you can hack up Fedora to run on a
Nokia Windows phone, more power to you, but Nokia and Microsoft aren't
obl
Andrew Haley wrote:
The problem with this claim is that it equivocates on the meaning of
"a right". There are at least two definitions of "a right" in this
sense: moral rights and legal rights. These are not the same. Moral
rights are not in the gift of any Government. While we may not have a
Jesse Keating wrote:
The point in which you find yourself arguing over the semantics of
Goodwin's law is also a clear indication that the thread has lost any
amount of usefulness.
Godwin's Meta-Law? Or maybe Keating's Corollary to Godwin's Law?
--
devel mailing list
devel@lists.fedoraproject
Stefan Schulze Frielinghaus wrote:
On Sat, 2012-06-02 at 10:21 -0400, Randall Berry wrote:
Does anyone plan to package MATE 1.2[1] for Fedora? MATE is a promising
A Gnome 2.3 fork. If so I would like to be a co-maintainer. Or if
nobody is planning on it I'll gladly start the project with a li
Neal Becker wrote:
I did try distro-sync, but it looked like there would be a lot of
issues, so I abandoned that idea.
I'd expect that if distro-sync has a lot of issues, preupgrade and
Anaconda are likely to as well. None of these do any magic.
--
devel mailing list
devel@lists.fedoraproj
Rob Spanton wrote:
There are an increasing number of ARM Cortex-M based boards around, and
I'd like to get a cross-compilation toolchain for them into the Fedora
repositories.
I hope you're more successful with that than I was. I found a
resounding lack of interest when I put an arm-none-eabi
Michel Alexandre Salim wrote:
LLVM is becoming an increasingly integral part of our distribution
(with mesa now using it to build the LLVMpipe renderer, for example)
that I don't really feel comfortable maintaining it mostly by myself.
I'm not sure how much help I'd be with maintaining the nati
Jonathan Underwood wrote:
Some months ago I requested commit on the el6 branch of djvulibre, but
the package owner (cc'd) hasn't responded. Please can someone grant me
commit access so I can make some updates?
There's a process to be followed for this kind of issue:
http://fedoraproject.org/wi
Corey Richardson wrote:
Getting source tarballs from github is a nightmare. See
http://lists.fedoraproject.org/pipermail/devel/2011-February/148676.html
The debian tool doesn't help very much because one still needs revision
garbage in the specfile. Is there any more recent ways to mitigate this
Michael Schwendt wrote:
Rather short files => suspicious! Read on. ;)
Thanks, I should have spotted that!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I'm working on packaging HP's LTFS filesystem (which uses fuse), and it
has binaries only in /usr/sbin. rpmlint complains that there are no
binaries, and the debuginfo package is empty.
[eric@p1 SPECS]$ rpm -qlvp ../RPMS/x86_64/hpltfs-1.2.2-1.x86_64.rpm
-rw-r--r--1 rootroot
DJ Delorie wrote:
Buy a trimslice and run it with iSCSI.
Pete Zaitcev wrote:
This is not good enough for me to become involved with Fedora on ARM.
Glad it works for you, but I need a real system, like a Netwinder.
You did see that there's a "Trimslice H" model that can accomodate a
2.5"
Bruno Wolff III wrote:
Rawhide inherits from updates of the most recent branch, which is
currently the branched release (f17). Updates will inherit from the
release. A package is only inherited if there are no builds for it at
the current level.
[and more good explanation]
Thanks! That's ex
The "Join the package collection maintainers" page gives the warning:
Be sure that you build for rawhide (master) branch before pushing
updates for any other branches! Otherwise, those updates will get
inherited into rawhide, which is almost certainly not what you want.
I've never really unde
Orion Poplawski wrote:
http://downloads.sourceforge.net/muparser/muparser_v2_2_2.zip
Thanks! I could have sworn that I tried that one, but I guess I must
have screwed it up somehow.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
In the process of updating the muParser package to the latest upstream
release, I am unable to construct a proper Sourceforge URL for the
upstream release that meets the Fedora packaging guideline. Can someone
more expert about Sourceforge URLs please give me a hand?
The file I want is mupars
I wrote:
Is there a way to query the package database to find out what packages
depend on a particular package (in this case, muParser)? I didn't see
anything obvious.
Vít Ondruch wrote:
$ repoquery --whatrequires muParser
Cool! I didn't even know of the existence of the repoquery tool, I
1 - 100 of 144 matches
Mail list logo
