2013/10/7 Jóhann B. Guðmundsson johan...@gmail.com
Or people turn a blind eye to the facts on what's actually taking place.
- It places distrust in the community ( as came completely clear on last
FESCO meeting )
Fesco members are all elected by contributors (no nominated members by Red
Hi,
as an emacs user, splitting emacs-common has little value to me, and
without a package requiring most of the splitted packages, it might even
turn into an annoyance (much like texlive).
My 2cts
Best regards.
--
devel mailing list
devel@lists.fedoraproject.org
2013/9/9 punto...@libero.it punto...@libero.it
hi
If there are no dissenting opinions
update testng to 6.8.7
regards
gil
Is it a bugfix release or does it bring some disruptive changes ?
In the former case, you need not to ping this list about it, in the latter,
you need to be more
but it still provides better isolation than
a mere chroot.
Secure containers as dwalsh described is a worthy improvement.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages
Ultimately, we ended up (again) discussing should we replace Koji by OBS ?
Unless there is commitment from people to maintain this, we can't even
consider this as a solution.
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora
Hi,
if you have a grudge against our infra team, OBS is the best option.
More seriously, OBS has a major flaw: it's a pain to deploy or update and
we need to have people able to fix bugs in a rails app.
I advise you to discuss this with infra team before considering further
this option.
One
I'm not a native speaker so i assume that's a misunderstanding, when i said
pretty much, i meant not as secure as KVM but much better than chroot.
The overhead of using KVM/Xen/Whatever hypervisor is non-negligeable,
container-based virtualization is a good compromise between security and
By mere curiosity, why didn't we follow the usual renaming process (and
avoid losing the previous history in git) ?
It was just an upstream rename due to a trademark issue.
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code
Dear Jonathan,
take a rest, and enjoy your vacations, then reconser co-maintaining D
packages.
You've worked really hard to get these into Fedora Packages Collection, and
as many told you, just ask for help if the load is too heavy for you.
We're only human beings, after all.
btw, kudos for
2013/8/7 Christopher Meng cicku...@gmail.com
Hi,
I have a POP3 mail server package, it's written in Go, are there any
people familiar with such packages?
https://bugzilla.redhat.com/show_bug.cgi?id=967258
Thanks.
Sent from Note I
We don't have yet go packaging guidelines, so may i
2013/6/4 Lennart Poettering mzerq...@0pointer.de
This sounds seriously misguided. I mean, I usually prefer attending
talks where I know that the presenter is actually involved in the
respective project, rather than just any random guy/gal.
I am all for levelling the playing field, but
2012/8/6 Kalev Lember kalevlem...@gmail.com:
Hi,
I'm on vacation through August 31 and away from computer. If any updates
or fixes are needed for the packages I maintain, please just push the
changes directly.
Thanks!
I'll keep an eye on the gtkmm stack until 15th august (then i'll be on
Le 31/07/2012 19:11, Bill Nottingham a écrit :
Package libgtksourceviewmm (fails to build)
retired, since nobody claimed it.
Package nvi (orphan)
Package torque (orphan)
Both taken and co-maintainers are very welcome !
best regards,
H.
--
devel mailing list
Hi,
libgtksourceviewmm can be safely (?) dropped since it is no more
actively maintained and all packages i'm aware of that relied on it
moved to newer gtksourceviewmm{,3} packages (repoquery didn't find any
other packages relying on it)
repoquery --whatrequires
Hi,
I filed a ticket 2 months ago, it requires a few dependencies to be
updated too (besides some of them brings python3 support)
https://bugzilla.redhat.com/show_bug.cgi?id=785607
best regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
2012/2/10 Neal Becker ndbeck...@gmail.com:
I've seen this repeatedly, with often very serious consequences (complete
failure of update from f15-f16 for example).
Between packages installed via pip, and packages installed via yum, some
packages seem to switch between
e.g.,
2012/2/10 Neal Becker ndbeck...@gmail.com:
Really? This is the only answer? Can't we tweek rpm/yum to accomodate this?
Does anyone understand what is causing it? Why would pip install the egg-info
differently than rpm?
--
devel mailing list
devel@lists.fedoraproject.org
2011/11/22 Matthew Garrett mj...@srcf.ucam.org:
The kernel ABI is the syscall interface, /sys and /proc. There is no
stable module ABI between kernels - even with a small security update,
the symbol versioning may change in such a way that the module ABI will
change. Given that any
Hi,
i cooked few patches for you:
* remove hunspell == basically, you just need to remove all
references to the bundled hunspell in texstudio.pro and use system
headers instead of bundled ones.
* force the use of xdg-open for viewers, this patch should be
upstreamed or at least, fix function
2011/6/14 Ralf Corsepius rc040...@freenet.de:
On 06/14/2011 12:26 AM, Kevin Kofler wrote:
Haïkel Guémar wrote:
I spent some time yesterday talking with opensuse guys on irc, since
/usr/libexec has not been blessed by FHS
libexecdir is GNU Standards for ages (decades).
It's supposed to be
2011/6/14 Ralf Corsepius rc040...@freenet.de:
Well, I would agree to tolerating /usr/lib/package/ (Which btw is the
current defacto rule in Fedora practice) but would disagree otherwise,
because
- /usr/share (aka datadir) is reserved for arch-independent data, i.e.
should not contain
Hi,
I'm reviewing osc and osc-source_validators (osc is Opensuse Build
Service CLI, the latter a plugin to the former).
An issue arose about helpers script location:
1) Fedora packaging guidelines suggests helpers *should go*
/usr/libexec for helpers == requires patching since osc search
helpers
Hi, i'm co-maintaining part of the gtkmm stack and a documentation
location issue has been raised
(https://bugzilla.redhat.com/show_bug.cgi?id=678981)
By default, gtkmm-related packages put their documentation in
/usr/share/doc, but for historical reason, fedora packages move them
to
2011/2/21 Remi Collet fed...@famillecollet.com:
Le 21/02/2011 09:41, 80 a écrit :
(you have to move documentation and fix devhelp index files),
Not only package.devhelp, but also package.pc which is used to
retrieve doc path by others packages.
# pkg-config --variable=doxytagfile cairomm
@krzesimir: thank you, if we settle to /usr/share/doc, then you should
move devhelp index to /usr/share/devhelp/books. Another issue is that
gtkmm doc subpackages should require base package documentation
packages (for libvtemm, at least gtkmm24-doc, glibmm24-doc,
libsigc++20-doc) so that
25 matches
Mail list logo
