Brandon Lozza writes:
[...]
>
> Most of us KDE users want deliberate visible changes to the user.
> That's the point in having the latest version.
Sorry if this has been already answered before, but what about having
the KDE SIG issuing its own respin'ed DVDs, along with its own backport
repo f
Rex Dieter writes:
[...]
>> On Tue, 28 Sep 2010 09:17:23 +0200
>> Dodji Seketeli wrote:
>>
>>> Brandon Lozza writes:
>
>>> > Most of us KDE users want deliberate visible changes to the user.
>>> > That's the point in having the lates
Michael Scherer a écrit:
> > Am Sonntag, den 09.10.2011, 12:58 +0200 schrieb drago01:
> > How else would you install an extension globally for all users?
>
> Or automate the installation of the addon ( like cobbler/pxe
> installation )
I think for that, we need upstream to provide a way to scri
"Joshua C." writes:
> Or maybe "being on the edge" isn't why we all use this distro?
Yeah maybe :-)
I like being as close as reasonable to the edge, but not closer.
--
Dodji
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/d
Kevin Kofler writes:
> Personally, I think we should just push the new stuff into updates
> whenever it makes sense (i.e. not for something like KDE 3 to 4 or
> GNOME 2 to 3 ;-) ).
Or we can encourage more people to use Rawhide proper. I know it might
sound too wild for some, but it's my belief
Dennis Gilmore a écrit:
> Chris its the teminology we have always used.
> each phase has a series of release candidates.
>
> for alpha we do a series of RC composes until we get one that meets the
> release criteria, it then becomes the alpha release.
>
> for beta we do a series of RC composes
On Mon, Feb 08, 2010 at 02:19:41PM +, Rawhide Report wrote:
> geglmm-0.1.0-2.fc12.i686 requires libbabl-0.0.so.0
> geglmm-0.1.0-2.fc12.x86_64 requires libbabl-0.0.so.0()(64bit)
I have just rebuilt these, so it should hopefully be fixed in the next
push.
http://koji.fedoraproject
Hello Roland,
On Mon, Feb 08, 2010 at 05:37:13PM -0500, Roland Grunberg wrote:
[...]
> Also, packages that have failed to build under these new changes can
> be found here :
>
> https://fedoraproject.org/wiki/DSOLinkBugs
I have patched and re-built the ghex package, so it probably won't
belon
On Fri, Feb 26, 2010 at 02:04:20PM +, Rawhide Report wrote:
> Broken deps for i386
> --
> geglmm-0.1.0-3.fc13.i686 requires libgegl-0.0.so.0
> Broken deps for x86_64
> --
>
On Sun, Feb 28, 2010 at 01:23:21AM +0100, Dominik 'Rathann' Mierzejewski wrote:
> Speaking as someone who is still on F11, I want the latest software as
> long
> as it doesn't break anything, because most often there are new useful features
> in it.
I think one of the problems is precisely that "
Adam Williamson writes:
[...]
>> The packages which depends on mpfr should be rebuild against the new
>> versio. The list is:
>
> It would be much better to either do the rebuilds yourself or arrange a
> tag for the new soname and ask the packagers of the below packages to
> rebuild them in the
Hello,
I am orphaning the following packages:
gedit-plugins (I don't own this one)
geglmm
marlin
All the best.
--
Dodji
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kevin Fenzi writes:
[...]
> It seems that Peter has been unavailable for Fedora packaging work for
> a while now.
[...]
> He maintains:
[...]
> nemiver -- A GNOME C/C++ Debugger
FWIW, I actively co-maintain this one. If Peter is really overworked I
wouldn't mind taking ownership of the pac
Kevin Fenzi writes:
> This new path requires you to convince an existing maintainer
> to mentor you in the processes and guidelines of package maintenance,
> and would allow you to be sponsored by FESCo or an existing sponsor to
> co-maintain those package(s) with your mentor guiding you.
Thank
>> nemiver -- A GNOME C/C++ Debugger
I maintain Nemiver upstream and co-maintains it in Fedora so I am taking
it.
--
Dodji
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hello,
Martin Krizek a écrit:
> From what I understood, the current status of the ABI comparison is that it
> only
> works with C/C++ programs.
Right.
> Have you given a thought on how do we know that the build under test
> includes a C program and so we should run the comparison on it?
The
Kamil Paral a écrit:
>> Then, when the package N-udpate-V-R is later submitted to Bodhi, the
>> update creation process would query ResultDB for the result of the
>> relevant ABI check that happened at build time. The decision to allow
>> an automatic push of the update to stable will depend on
Hello,
Following up on the ABI checking topic raised in the "API Break
Detection" section near the end of the post
https://lists.fedoraproject.org/pipermail/server/2015-June/001904.html,
I'd like to summarize where we stand at the moment and what we plan do.
We discussed this topic on the #fedora
Stephen Gallagher a écrit:
>> On Fri, Jun 05, 2015 at 10:34:19AM +0200, Dodji Seketeli wrote:
>>
>> > When the "abipkgdiff" command line tool is ready , I guess the plan
>> > is
>> > to use it in a new Taskotron task that, when invoked on a giv
> On Fri, Jun 05, 2015 at 10:34:19AM +0200, Dodji Seketeli wrote:
>> We are currently working on a tool named "abipkgdiff"[3] that takes
>> two RPMs
Zbigniew Jędrzejewski-Szmek a écrit:
> About the name: "package" is fairly generic, but "
> On Fri, 2015-06-05 at 10:34 +0200, Dodji Seketeli wrote:
[...]
>> To start, we'd like to have an automated way to check the ABI
>> compatibility of binaries embedded in packages that are submitted to
>> the
>> updates-testing repository. When an incomp
Nikos Mavrogiannopoulos a écrit:
> On Fri, 2015-06-05 at 08:00 -0400, Stephen Gallagher wrote:
>
>> >
>> > and
>> > here is what stuck to my mind. Others are of course welcome to add
>> >
>> > what
>> > I have forgotten and to correct me when I a wrong.
>> >
>> > To start, we'd like to have
Nikos Mavrogiannopoulos a écrit:
> On Mon, 2015-06-08 at 11:53 +0300, Alexander Bokovoy wrote:
>
>> > I have not seen the output of abicheck (I use abi-compliance
>> > -checker
>> > personally but I guess abidiff is as good). However, I'm not sure
>> > about
>> > which changes which are not brea
> On Mon, 08 Jun 2015, Nikos Mavrogiannopoulos wrote:
[...]
>> I have not seen the output of abicheck (I use abi-compliance-checker
>> personally but I guess abidiff is as good).
It's abidiff :-)
>> However, I'm not sure about which changes which are not breakages you
>> mean? I'm not aware of
Hello,
A little update about this project we have been tinkering about.
First thing first, a tracking ticket has been opened against the
Taskotron project to follow the progress of this effort:
https://phab.qadevel.cloud.fedoraproject.org/T490.
Just so you remember the big picture, for each stab
Rahul Sundaram a écrit:
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
This is really nice. I wasn't aware people could have access to remote
Rawhide machines for testing purposes. I guess it won't be really
useful for maintainers of packages that requires Xorg
Kévin Raymond a écrit:
> Just to remind you that we are having our next planning meeting today,
> Thursday, at 6PM UTC, #fedora-meeting.
> This time is going to be used for our weekly meetings.
Do we have some minutes somewhere for this?
Cheers,
--
Dodji
--
devel mailing list
Thank you very much guys.
--
Dodji
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Dennis Gilmore a écrit:
> f18-candidate is the target name and has nothing at all to do with any
> tags, a target has 2 things the tag used to populate the buildroot and
> the tag that resulting builds are tagged into.
>
> Right now the f18-candidate target is setup to populate the
> buildroot us
Luya Tshimbalanga a écrit:
> I have gdm graphical login screen operational, the entire desktop is
> slow compared to the previous gnome 3.4.2 on Fedora 17running on a AMD
> E350 powered laptop. I don't know what exactly cause slowdown, it
> appears to be a regression.
I am seeing a slow gnome-sh
Tomasz Torcz a écrit:
>> I am running this rawhide box using init 3
>> (/lib/systemd/system/multi-user.target) as the default init level, and I
>> am running the desktop by doing:
>>
>> xinit /dev/gnome-session
>>
>> So somewhere something is failing to make my user be properly acl'd
>> ont
"eduard.vopicka" a écrit:
> Adding your username to the "video" group and logout/login does not
> help?
As I implied in my initial email at:
>> For now I have just added my user into the video group to have the
>> r300 driver be loaded properly.
that is what I have done and it worked. But it
Todd Zullinger a écrit:
> I placed git-prompt.sh in /etc/profile.d where it should be sourced
> for normal login shells. This should make the change transparent to
> most users.
>
> https://admin.fedoraproject.org/updates/git-1.7.12-2.fc18
Great. Thank you for doing this.
Do you think it woul
Hello,
Fedora Rawhide Report a écrit:
> firefox-14.0.1-3.fc19
> -
> * Wed Aug 22 2012 Dan Horák - 14.0.1-3
> - add fix for secondary arches from xulrunner
With this update and ...
> xulrunner-15.0-1.b6.fc19
>
> * Wed Aug 22 2012 Martin Stransky -
Peter Robinson a écrit:
>> I naively thought 'yum downgrade xulrunner' would get me back to the
>> previous xulrunner, but it just doesn't do anything. Is that expected?
>
> In rawhide yes because the old version is no longer in the repository.
I see, thanks.
> You can get the old version from
Kevin Fenzi a écrit:
> https://bugzilla.redhat.com/show_bug.cgi?id=847418
>
> downgrade to:
>
> systemd-188-3.fc18
>
> (NOTE: NOT fc19)
Just so that I understand. What version of systemd and kernel should
Rawhide users *not* use to avoid the issue?
I couldn't figure this out by reading the a
Kevin Fenzi a écrit:
> Get a nice group of at least 10 or so folks who are active on this list
> to agree to run it full time on their main machine.
Amen brother. Count me in that group if this ever happens.
I already run rawhide on a dedicated box for daily duties like email,
web browsing
"Nicolas Mailhot" a écrit:
> Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :
>
>> Just having a dedicated Rawhide Swat Team of die hard volunteers who
>> could spot issues early, file more bugs, gently push for fixes in
>> Rawhide and last but not leas
Kevin Fenzi a écrit:
> On Mon, 05 Nov 2012 10:45:00 +0100
> Dodji Seketeli wrote:
>
> ...snip...
>
>> Could we have a rawhide-list for this? I know fighting proliferation
>> of mailing list is a good thing, but practically speaking, being able
>> to quickly s
Fernando Nasser a écrit:
> And _maintain_ them, with all security fixes.
>
> The problem with duplication is above all one of scalability of
> maintenance.
Please, avoiding top-posting like this would be very welcome here.
Otherwise, it is quite hard to know what you are replying to exactly.
Th
"Darryl L. Pierce" a écrit:
> BZ#848774
>
> This bug is nearly a year old, requesting that package offlineimap be
> upgraded to what was then the latest release (6.5.4, now it is
> 6.5.5-rc2). There has been no response from the maintainer.
>
> I posted a bug comment on 01 July asking for somethi
"Darryl L. Pierce" a écrit:
> Hi, Dodji. It's now been two months since you said you were planning to
> test the latest version. Since then another version has been promoted to
> RC.
Indeed. And I have been testing that 6.5.5 rc version. And it didn't
eat any of my emails. I guess I should st
"Darryl L. Pierce" a écrit:
>> [1]: http://koji.fedoraproject.org/koji/buildinfo?buildID=466672
>
> Installed and it works for me.
OK.
> I had to add configuration options for certificate fingerprints and
> it's all good.
Yeah, that option is mandatory with SSL now.
> +1 on the package.
Than
Hello,
Dan Horák a écrit:
> one more case for enabling libabigail tests in bodhi ...
Well, task-abicheck that is automatically run on all koji builds
actually *caught* this issue. I can see that in the taskotron logs from
2016-08-12 at:
https://taskotron.fedoraproject.org/resultsdb/results?pag
Josh Boyer a écrit:
> I agree. This would have been caught by libabigail/abicheck as far as
> I know.
Right, as I said in another message, the Taskotron's task-abicheck task
actually caught it at Koji build time, asking the maintainer to review
the change at:
https://taskotron.fedoraproject.or
Josh Boyer a écrit:
[...]
>> At the moment, the ABI changes that are reported do not trigger the
>> blocking of the build, so we need collaboration from critpath package
>> maintainers. Whenever Taskotron says "please review this ABI change",
>> the review is needed.
>
> Perhaps it would make s
Matthew Miller a écrit:
> On Thu, Sep 15, 2016 at 05:03:40PM +0530, Sinny Kumari wrote:
>> >> one more case for enabling libabigail tests in bodhi ...
>> > I agree. This would have been caught by libabigail/abicheck as far as I
>> > know.
> ...
>> > Does anyone know what the blockers are for en
Josh Boyer a écrit:
> No. However, bodhi maintenance is changing to a new owner and now
> would be a good time to start filing tickets/issues for function adds
> like this.
Right.
I have thus filed two issues for this:
https://github.com/fedora-infra/bodhi/issues/932
https://github.com/fedora
Dodji Seketeli a écrit:
> I'll file a Bodhi ticket asap.
There you go:
https://github.com/fedora-infra/bodhi/issues/932
https://github.com/fedora-infra/bodhi/issues/933
Cheers,
--
Dodji
--
devel mailing list
devel@lists.fedoraproject.o
Adam Williamson a écrit:
>> Though, we also need to sort out how maintainers can do to say "I
>> reviewed the ABI change, and it's OK" -- a kind of waiving mechanism for
>> cases where the ABI change is harmless.
>
> If we only make it so failed automated tests disable *autopush* for
> now, we ha
Hello xining,
xning a écrit:
> Shall we should modify '-g' to '-g3' to have gcc save the macro info?
> So when we install *-debuginfo packages, we can look up a macro
> definition, just like we can look up a function definition.
For what it's worth, I believe that would be useful, yes. Though
Hello,
After upgrading this box from F18 to Rawhide between yesterday night
and today and tried several times to type my password to no avail, I
realized the system (systemd actually) couldn't load my "fr" keymap.
You can see something like this in the logs:
$ loadkeys fr
unknown keysym
Kevin Fenzi a écrit:
>> modify yum-local to keep say 5 copies?
>> (in case something hits the fan)
>
> Yeah, although you can always get them from koji.
... provided your Rawhide system is in good enough shape to reach koji.
:)
--
Dodji
--
devel mailing list
devel@lists.fedor
Dennis Jacobfeuerborn a écrit:
> Also MySQL 5.6 gains some of its speed through commercial extensions (like
> e.g. the thread pool). Since these cannot be packaged in Fedora you will be
> able to make a better/more fair comparison between the two based on the
> same Platform (Fedora).
You mean n
Petr Machata a écrit:
> The soname didn't change. I reviewed the actual changes using abidiff,
> and the only thing reported that I think is an actual ABI violation is
> insertion of one virtual method. I don't think that's real however:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id
Hello,
Richard Shaw a écrit:
[...]
>> https://fedoraproject.org/wiki/Packaging:Guidelines#Downstream_.so_name_versioning
>
>
> It's neat to see reference to abi-compliance-checker (hint, I maintain
> it!)
And thank you for maintaining it! I believe that checking for ABI
compatibility is an im
Hello,
I have retired libabigail from EPEL 9 because the package is now shipped
in RHEL 9.2 onward.
You can see that the files have been removed from the SCM at
https://src.fedoraproject.org/rpms/libabigail/tree/epel9.
The Rawhide, f39, f38, f37, EPEL7 and EPEL8 package are still
maintained.
Ch
Daniel P. Berrangé a écrit:
> On Mon, Nov 27, 2023 at 04:20:16PM +0100, Fabio Valentini wrote:
>> On Fri, Nov 24, 2023 at 12:08 PM David King wrote:
>> >
>> > The latest released versions of libxml2 have a couple of important
>> > changes in header files that have unintentionally caused some pac
Hello,
Petr Pisar a écrit:
> V Tue, Nov 28, 2023 at 12:24:45PM +0100, Dodji Seketeli napsal(a):
[...]
>> For what it's worth, the ABI compatibility verifier caught this change
>> between libxml2.so.2.11.5 and libxml2.so.2.12.0 and categorized it as
>> being
Kevin Kofler a écrit:
> Justin Forbes wrote:
>> * #1810 Let's flip the switch on January 15th: gating in Fedora
>> (jforbes, 16:15:51)
>> * LINK: https://pagure.io/fesco/issue/1810 (jforbes, 16:16:05)
>> * LINK: https://src.fedoraproject.org/rpms/waiverdb (pingou,
>> 16:24:22)
>>
60 matches
Mail list logo
