2013/10/7 "Jóhann B. Guðmundsson"
>
> 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
Hat), if you
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
https://admin.fedoraproject.org/
2013/9/9 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 explicit or prov
; --
> 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 (the OPEN alternative to F#)
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://
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 Co
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
perfo
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 qui
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 of
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 Chris
2013/8/7 Christopher Meng
> 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 suggest you
2013/6/4 Lennart Poettering
>
> 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 things like this sou
2012/8/6 Kalev Lember :
> 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
vacation too).
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
devel@lists.fedoraproject.o
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 "libgtksourceviewmm-1.0.so.2()(64b
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
https://admin.fedoraproject.org/mailman/listin
2012/2/10 Neal Becker :
>
> 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
> https://admin.fedoraprojec
2012/2/10 Neal Becker :
> 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.,
> numpy-1.6.1-py2.7.egg-info
>
2011/11/22 Matthew Garrett :
> 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 interpretation of the stabl
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 x11d
2011/6/14 Ralf Corsepius :
>
> Well, I would agree to tolerating /usr/lib// (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 executables and programs
2011/6/14 Ralf Corsepius :
> 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 kind of an
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
Some intels about the *mm modules orphaned (in short, they should just die).
> libgnomemm26
> lignomeuimm26
only required by gcdmaster and referencer. gcdmaster comes from
cdrdao and does not seem actively maintained, referencer is looking
for a new upstream maintainer and seriously needs some re
@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 hyperlink
2011/2/21 Remi Collet :
> Le 21/02/2011 09:41, 80 a écrit :
>
>> (you have to move documentation and fix devhelp index files),
>
> Not only .devhelp, but also .pc which is used to
> retrieve doc path by others packages.
>
> # pkg-config --variable=doxytagfile "cairo
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 /usr/share/gtk
26 matches
Mail list logo
