Heya !
Welcome here and I'm glad that you finally jumped onboard :)
Feel free to ping me if you're looking for a sponsor.
best regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
2014-04-22 16:10 GMT+02:00 Máirín Duffy du...@fedoraproject.org:
To be honest, I'm fairly uncomfortable discussing this without Fedora Legal
weighing in. I don't see any problem with re-visiting the decisions made
along this path, but I also am pretty confident the folks who decided things
Since AGPL is fedora-compliant license, there's no blocker to get
libdb6 into packages collection.
Besides, libdb5 is still critical for many packages (like RM), until
we get rid of it, I can only agree with your proposal.
Maybe, it's still time to rename the current libdb = libdb5 and get
newer
+1 Mesos is definitively an asset for the Fedora Cloud Product and
would fit in some of our use cases.
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2014-03-20 12:22 GMT+01:00 Kevin Kofler kevin.kof...@chello.at:
Hi,
GHC (Haskell) was broken for (at least) over a year because of a bug in the
workaround for stupid SELinux restrictions:
https://ghc.haskell.org/trac/ghc/ticket/7629
https://bugzilla.redhat.com/show_bug.cgi?id=907515
How
Hi,
I don't think that worrying about perpetuating offensive stereotypes
is specifc to the US, we have similar controversies in Europe:
http://en.wikipedia.org/wiki/Banania#Controversy
http://en.wikipedia.org/wiki/Zwarte_Piet#Controversies
Anyway, the line between what is acceptable and
Hi,
I'm back.
2014-02-22 11:19 GMT+01:00 Matthias Runge mru...@matthias-runge.de:
Does that also mean, you're changing jobs? You mentioned something like
you're at least interested in a jobs at Red Hat in the cloud area?
Sadly enough, I haven't changed jobs, yet.
I can't dwell upon this
Use createrepo, its man page should be more than enough.
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
About boto:
Mitch Garnaat (upstream maintainer) is focusing on botocore and awscli,
botocore is a rethinking of boto low-level plumbing which is python3
compatible. In the long run, boto3 will be based upon botocore and support
python3.
I have packages of botocore and awscli, i still have to
My *personal* opinion is that we should disable this kind of feature by
default.
Actually, unless it tracks users, i don't think that our guidelines forbids
it, though it may influence our choice for the packages set installed by
default.
Has anyone tried to contact Mozilla Corporation about it
About boto:
Mitch Garnaat (upstream maintainer) is focusing on botocore and awscli,
botocore is a rethinking of boto low-level plumbing which is python3
compatible. In the long run, boto3 will be based upon botocore and support
python3.
I have packages of botocore and awscli, i still have to
I'm not fond of keeping spins around when we're focusing on products.
That gives the message that they are second-class citizens in Fedora.
I'd rather define a process that allows current spins to become either
sub-products or full-featured products
when they meet a set of requirements (that is
It's also a negative message to the 1.4 k active contributors in fedora.
Or do you assume that most of them are paid by RH which is unlikely.
Don't forget that fp.o has been founded with two stakeholders: RH and the
community
H.
--
devel mailing list
devel@lists.fedoraproject.org
I disagree about keeping spins around in the long term.
Current spins:
* hinders our communication (each spin is supposed to get proper coverage
from marketing, ambassadors etc.), some users think that actually
installing KDE requires reinstalling from the spin !
* prevents spins with a striving
Hi,
I think we should keep spins as long as we don't have a formal process to
accept new products.
Something like = proposal = crop (aka product-to-be) = validation =
product
When we'll have that, drop the whole spin thing, any spin that isn't fit to
be a product should be reclassified as remix.
Hi,
I agree that we can't support more than a limited number of products.
The point is to make a validation process sufficiently strict so we can
guarantee that the would-be product would be sustainable.
After all, if there are people willing to maintain it on the long term
*and* our
Hi,
thank you for taking the time to join us.
If you want to speed things up, I'd suggest that you start doing informal
reviews of other pending reviews and when you're done, link them to your
review.
Many sponsors will ask you that to assess your packaging knowledge anyway,
just do it and do it
Ruby collections ? Did you mean SCL ? At the moment, the cloud WG hadn't
discuss any other options.
We're not the only stakeholders on that matters, these are topics requiring
collaboration with other WG.
H.
--
devel mailing list
devel@lists.fedoraproject.org
/me wants the ability to push force on *private* branches
2014/1/15 Dridi Boukelmoune dridi.boukelmo...@gmail.com
On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch vondr...@redhat.com wrote:
Dne 14.1.2014 21:41, Andrew Lutomirski napsal(a):
I have some trivial cleanups I want to make to a
only over my dead body i would start wrap more and more layers on top of
already virtualized infrastructures
Containers have little to almost no overhead, they bring more isolation
(and i can't wait docker/selinux integration for more security), the FS
layered approach allows to save spaces.
My apologies if you felt i misquoted you, i didn't intend that.
I do plenty of SaaS deployments at $DAYJOB, and i can easily pack hundreds
to thousands // running containers on a single machine.
Remember that Fedora is on the innovative side of the distro spectrum, yes
vhost is the present, but
What's the point ? There's absolutely no benefit in keeping Gtk+2 longer.
Gtk+ 2.24.0 has been released 3 years ago (january, 2011) and is only
receiving bugfix due to existing apps who didn't move to Gtk+3.
By migrating more apps, we can drop Gtk+ 2.24 (at least from images),
firefox is one of
2014/1/14 Daniel P. Berrange berra...@redhat.com
In fact Fedora still ships GTK *1*. If we can't even get rid of GTK1,
then talk of killing GTK2 seems wildly over optimistic.
Regards,
Daniel
I'll quote myself again: at least from base images , not removing it from
repositories.
H.
--
Hi,
there's a draft, i suggest that you start checking it.
http://fedoraproject.org/wiki/PackagingDrafts/Go
Taking a peek at Debian and OpenSuSE Go guidelines might be worthy:
http://pkg-go.alioth.debian.org/packaging.html
http://en.opensuse.org/openSUSE:Packaging_Go
Best regards,
H.
--
devel
My apologies for linking opensuse guidelines, i missed that point in your
mail.
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
This discussion has now reached the phoronix point
http://www.phoronix.com/scan.php?page=news_itempx=MTU2MTE
Has anyone filed any tickets so we could move forward or will we continue
wasting time here ?
Best regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
Congratulations for lowering the level of this discussion even lower than
it already was !
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Welcome in Fedora :)
Out of curiosity, are you only packaging it or also developing it ?
Anyway, it will be a useful library (no trolling about the rdrand
instruction ;))
Best regards,
H.
Le 5 janv. 2014 21:14, Jan Tulak jtu...@redhat.com a écrit :
Hi all
I'm an IT university student. With
2013/10/28 Jóhann B. Guðmundsson johan...@gmail.com
On 10/27/2013 11:34 AM, Nobrakal wrote:
2013/10/27, Frank Murphyfrankl...@gmail.com:
On Sun, 27 Oct 2013 19:05:37 +0800
Christopher Mengcicku...@gmail.com wrote:
It seems that most of members from the new formed groups are
working
Hi,
Fesco is entitled to delegate their authority to anyone they see fit to
do so.
For instance, FPC members are designated by Fesco and rule packaging
guidelines.
Besides, the final decision was taken by Fesco.
H.
--
devel mailing list
devel@lists.fedoraproject.org
Hi,
Thanks for your concern on that topic, off course, fedora.next would be an
half-assed
initiative if we forget communication and community mgmt. And i'm pretty
sure that
everyone here agrees with you on that point.
As for myself, I also intend to represent users inside the Cloud WG, so
i'll
Hi,
I think that coordinators and Fesco tried to integrate as much as possible
community members.
But truth is that most people who self-nominated were RH employees, so i'd
rather say that RH employees even had an handicap.
As for the Cloud WG -i can't speak for other WG-, we wish that
Hi,
Thank you for sharing that sad issue :(
i wish that we could review regularly all packages but that's obviously not
feasible.
What is doable:
* automated review of packages: git hooks ? regular mass fedora-review
checks ? triggering a mail to a list ? our scm watchdogs do a great job at
Hi,
since Gazpacho hasn't been maintained fro years and it requires an older
version of python-kiwi than currently packaged in F20, i'm retiring.
It has been superseeded by Glade 3 and no other packages should require it.
Best regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
git branch -a will show you all branches (remote included)
Until fedpkg is updated, to track any remote branch other than master
(ie: F-13):
git checkout -b f13 remotes/origin/F-13
Then, you juste have to do for switching: git checkout my_branch
Best regards,
H.
--
devel mailing list
Just one thing, the title is misleading since Django 1.2.x is not an
unsafe version.
So what's the plan ? The update was also pushed in previous release like F12.
Best regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I agree with Kevin on this one.
Since Josef Radinger (fas: Cheese) is already a sponsored maintainer
and the package legibly and properly accepted into packages
collection,
it should fall under the non responsive maintainer policy. We're
already short on reviewers not to waste time over petty
magit is already packaged as emacs-magit
https://admin.fedoraproject.org/pkgdb/acls/name/emacs-magit
Check this with the maintainer, if you're interested by maintaining
it, ask co-maintainership.
best regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
And so what ?
In OpenArena's case, last stable releases were:
* 0.8.5: 02/23/2010
* 0.8.1: 10/31/2008
You can't blame OpenArena's maintainer for that, do you ?
The same goes for Wesnoth, 1.8.1 maintenance release was issued 2 May
so less than two weeks ago (1.8 was released 1st april !)
Best
It is not part of a default package set.
Even if it were, blocking bugfixes in order to reduce updates size is
nothing but stupid.
We have presto/deltarpm for that (since these packages mostly contain
unchanged binary data like images, it should work pretty well).
What's the point in having new
This is useful enough that it is worth considering for inclusion
in /etc/profile.
during development cycle: +1
for stable/production release: not so much (users would hate us for that)
regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
@Dennis: i appreciated your work on the Gtkmm stack.
took : gtksourceviewmm;, libnotifymm, gstreamermm, libxml++, libgda,
bakery, glom
btw, libgnomedb is dead package as it's abandonned by upstream and
most of it will be integrated in libgda-ui 4.2
Co-maintainers are welcome
H.
--
devel
frysk is long dead (and who was using it anyway ?), frysk developers
are working on gdb/Archer now.
http://sources.redhat.com/frysk/
I suggest that both frysk and old gnome java wrappers to be dropped
from packages collection.
H.
--
devel mailing list
devel@lists.fedoraproject.org
Sounds pretty sensible.
We should also keep in mind that one size does not fit all. While core
and widely used packages should have a more conservative update path,
some packages could benefit from faster release. karma mechanism +
feedback integration in PK looks like a total win for the latter.
2010/2/25 Kevin Kofler kevin.kof...@chello.at:
Well, if you had talked to us about it, we could have bundled the rebuild
together with the big update, like we did for a couple other apps which
needed rebuilds for some reason.
But it doesn't matter now, I see your updates are queued for
I'll take me-tv, co-maintainers are welcome.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
looks like packages are not orphaned yet.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
47 matches
Mail list logo
