Re: F29 System Wide Change: i686 Is For x86-64

[Michael Cullen]

On Wed, 6 Jun 2018, at 2:38 AM, Dennis Gilmore wrote:
> El mar, 05-06-2018 a las 15:59 -0400, Adam Jackson escribió:
> > On Tue, 2018-06-05 at 13:20 -0500, Dennis Gilmore wrote:
> >
> > > as part of this change I suspect we would need to make kernel
> > > changes
> > > to stop building a i686 kernel, and all i686 deliverables would
> > > stop
> > > being made.
> >
> > We would?
> It may be a bad assumption on my part, I am assuming that
> optimising to> run on x86_64 means that we will not be able to run on any 
> actual
> x86_32 hardware.
>
> Dennis
> 

The optimisation proposed here wouldn’t technically prevent running on
P4 systems or the atoms that have been mentioned, as I understand it.
These systems would still benefit from a 32-bit kernel.
For reference, the last CPU I used that didn’t have SSE2 support was an
Athlon XP - introduced to compete with the P4 but actually had the
instruction set of a PIII more or less. I remember this because I tried
to run OpenSolaris on it. Which even about 15 years ago, required SSE2
How about instead of proposing to drop support for anything not using
x86-64 this was pushed as a proposal to stop supporting anything that
doesn’t do SSE2 (which seems to be the actual proposal) - does it sound
any different now?
To me, it does - because I’d suspect P4 and some Atom chips covers quite
a range of hardware that people still use.
Whether it’s worth running such a P4 machine nowadays is another
question of course, given how power hungry they are for not much
compute power...
To me? It’s perhaps worth dropping non-SSE2 support but i wouldn’t stop
building kernels for 32-bit
Michael
___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZ65EEUBDU7YHBUYKQ2X5IYX7KSSTDID/>
>  Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SS5IU7ORUY2IIFYZKPG7IG5JXGLEZYIM/

Re: ga (global arrays) package maintainer needed

[Michael Cullen]

If it genuinely is unmaintained (and this thread doesn’t wake up the
current maintainer - you might want to try a direct email) then you
might be the best person to help maintain it since you’re maintaining
something (the only thing?) that uses it
Michael


On Mon, 7 May 2018, at 10:31 PM, Marcin Dulak wrote:
> Hi,
>
> I have a problem with an unmaintained
> https://src.fedoraproject.org/rpms/ga, a dependency for
> https://src.fedoraproject.org/rpms/nwchem.
> Recently nwchem unbundled ga from its sources
> https://github.com/nwchemgit/nwchem/issues/28, but that requires a
> recent ga version, built
> in a way that makes `${EXTERNAL_GA_PATH}/bin/ga-config` available.
> ga seems unmaintaned
> https://bugzilla.redhat.com/show_bug.cgi?id=1432661, and therefore I'm> 
> looking for someone who can take it over.
>
> I believe I'm not allowed to bundle ga in nwchem
> https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries,>
>  and in this case if ga (in Fedora and EPEL) does not follow
> closely the> nwchem development cycle I'll need to retire nwchem.
> ga seems to be used only as nwchem dependency on Fedora/EPEL as seen
> from `repoquery --whatrequires ga-openmpi`
>
> Marcin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

The New Hotness builds failing with py2_dist macros

[Michael Cullen]

Has anyone  else notices this sort of thing? 

Skipping the scratch build because an SRPM could not be built:
['rpmbuild','-D', '_sourcedir .', '-D', '_topdir .', '-bs',
u'/var/tmp/thn-gkVzfc/python-twilio.spec'] returned 1: error: line 27:
Dependency tokens must begin with alpha-numeric, '_' or '/':
BuildRequires:%{py2_dist nose}

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Michael Cullen]

> because I can no longer cherry-pick between branches.

Not true at all - you’d be surprised how well git deals with cherry
picks across diverse branches. And even when it doesn’t there’s very
rarely anything in a spec file that would be a difficult conflict to
resolve. At work I often cherry pick across branches that have diverged
sometimes by hundreds of commits without too many problems!
Michael


On Thu, 7 Dec 2017, at 11:13 PM, Sérgio Basto wrote:
> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> > Hello,
> >
> > What do I have to do to stop random people
> > from making random changes to packages I maintain?
> >
> > How do people get this type of permission?
> >
> > Case in point;
> >
> > commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> > origin/master, origin/HEAD)
> > Author: Igor Gnatenko 
> > Date:   Tue Nov 7 16:31:21 2017 +0100
> >
> > Remove old crufty coreutils requires
> >
> > Signed-off-by: Igor Gnatenko > >
> > commit 66851ea12370a786844262620a40b0a2ac9632ce
> > Author: Igor Gnatenko 
> > Date:   Tue Nov 7 16:31:14 2017 +0100
> >
> > systemd-units -> systemd
> >
> > Signed-off-by: Igor Gnatenko > >
> > Where committed to the master branch and not to any other
> > branch make the maintenance of those branches a pain
> > because I can no longer cherry-pick between branches.
> > I have to make multiple commits to multiple branches
> > which sucks... Something random people do not understand!
> >
> > There is a pull mechanism... Why was that not used??
> >
> > Maintaining the stability of packages is hard enough
> > esp packages everybody uses... but that stability
> > goes out the window when random people allowed to
> > make random changes...
> >
> > Who are these super humans, how do they become
> > super humans and why aren't they required to
> > use the pull mechanism??
>
> I don't agree with you, you may contact the super human and ask him
> why> ? you may revert the commit .
>
> IMHO we shouldn't inhibit people do his best, we already have lots of> work, 
> is kernel updates , glibc updates , gcc updates , systemd , etc> etc ... 
> (hopefully)
>
> As wrote in coreuitls commit
> " Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
> stat) Those are gone in fc9, more than decade ago."
>
> Nobody takes care of opencv for example , despite a very long bug
> report, we got bugs like  822844 [1] opened in 2012-05-18  to update
> giflib, my problem here is I don't know if giflib is used
> anymore or if> have a replacement etc, so just do a monkey update is not 
> enough for
> me.
> I got more and more SELinux bugs, people more and more enable
> SELinux ,> but SE team doesn't have time to fix it or something like that .
>
> So I think you should write (offlist) to the people which made the
> commits , and understand the motivation , and organize with him the
> best way of committing in "your" packages.
>
> Best regards,
>
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=822844
>
> > steved.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org> --
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/libQxtWidgets-qt5.so: undefined reference to `vtable for QxtApplication'

[Michael Cullen]

At a guess, and not having looked at the code or logs, I would say it’s
either a virtual destructor defined in a header file (that can cause
problems with the vtable not being generated by any compilation unit)
or it has been built with -fvisibility=hidden and the class is not
marked with visibility(“default”) and so members are not exported from
the library
Michael


On Tue, 28 Nov 2017, at 10:35 PM, Michael Cullen wrote:
> At a guess, and not having looked at the code or logs, I would say
> it’s either a virtual destructor defined in a header file (that can
> cause problems with the vtable not being generated by any compilation
> unit) or it has been built with -fvisibility=hidden and the class is
> not marked with visibility(“default”) and so members are not exported
> from the library> 
> Michael
> 
> 
> On Tue, 28 Nov 2017, at 09:17 PM, Martin Gansser wrote:
> > Maybe someone can tell me which forum I can contact to fix this
> > error?> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org> 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fwd: Re: Unresponsive Maintainer: eponyme (EDB package)

[Michael Cullen]

I got a response to this, but he isn't a list member now so couldn't
respond to the list.
I'll take EDB - most of the other projects seem to be a bit dead
upstream - someone else can take them if they want!
I think you need to do it on
https://src.fedoraproject.org/rpms/edb/settings  though I'm sometimes
getting 503 errors from that site right now, so you might need to
wait a while.
Thanks,
Michael


- Original message -
 * From: Nicoleau Fabien <nicoleau.fab...@gmail.com>To: Michael Cullen 
<mich181...@fedoraproject.org>
Cc: devel@lists.fedoraproject.org
Subject: Re: Unresponsive Maintainer: eponyme (EDB package)
Date: Thu, 23 Nov 2017 19:51:31 +0100

Hello,

I appologize for being unresponsive. I actually have no more time to
take care of my packages.
If someone want's to take the package, I will give him the ownership
(tbh, I'm now so far prom the project that you will have to remind me
how to do :) )
Again, sorry for the silence,

Regards

Fabien Nicoleau (eponyme)

On Thu, Nov 23, 2017 at 7:30 PM, Michael Cullen <mich181...@fedoraproject.org> 
wrote:> Hi,
> 
>  I raised a ticket against EDB a while ago since it's quite out
>  of date:> https://bugzilla.redhat.com/show_bug.cgi?id=1502328
> 
>  I also raised a PR to update the package, again with no response:
> https://src.fedoraproject.org/rpms/edb/pull-request/1#commit_list
> 
>  As per the unresponsive maintainer process, has anyone got a way of
>  contacting the maintainer, eponyme (Nicoleau Fabien, also
>  copied in on>  this email)?
> 
>  Thanks,
>  Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Unresponsive Maintainer: eponyme (EDB package)

[Michael Cullen]

Hi,

I raised a ticket against EDB a while ago since it's quite out of date:
https://bugzilla.redhat.com/show_bug.cgi?id=1502328

I also raised a PR to update the package, again with no response:
https://src.fedoraproject.org/rpms/edb/pull-request/1#commit_list

As per the unresponsive maintainer process, has anyone got a way of
contacting the maintainer, eponyme (Nicoleau Fabien, also copied in on
this email)?

Thanks,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packages looking for new maintainers

[Michael Cullen]

I can take ccache if no one else wants it

Michael / mich181189


On Wed, 25 Oct 2017, at 10:52 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Oct 25, 2017 at 08:34:54AM +0300, Ville Skyttä wrote:
> > (Does a thing exist where I could search FAS users by real
> > name, BTW?)>
> I find it easiest to do
> /msg zodbot fas Name
> in IRC.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass rebuilds update

[Michael Cullen]

A few I've just tried to build chosen pretty much at random from the
above list:

> boinc-client
builds fine - there was a FTBFS months ago (#1251482) referring to
openssl but it's fine now

> activemq-cpp
Already tracked by  #1423204 - upstream have, slightly strangely,
included the fix in a comment but not their source repo
I've attached a working patch to the ticket. (I forked in Pagure but it
seems it won't let me push right now - I guess it needs longer to sync
than I expected or can be bothered to wait!)

> dvb-apps
Was about to say this was fine until I built for rawhide and saw the
problem.
https://patchwork.linuxtv.org/patch/43705/ removed the IOCTL it uses
with the comment that nothing uses it! not sure quite what to say about
this one. It's old and seems to have a few bugs reported against it -
https://git.linuxtv.org/v4l-utils.git contains replacements for some of
them, using the dvbv5 API rather than the dvbv3 API these apps use.
Easiest thing might be to remove the function the IOCTL is for from
dst-utils.
In future we should probably consider encouraging users to move to newer
utils though.

Michael


On Tue, 24 Oct 2017, at 10:24 AM, Michael Cullen wrote:
> A few I've just tried to build chosen pretty much at random from the
> above list:
> 
> > boinc-client
> builds fine - there was a FTBFS months ago (#1251482) referring to
> openssl but it's fine now
> 
> > activemq-cpp
> Already tracked by  #1423204 - upstream have, slightly strangely,
> included the fix in a comment but not their source repo
> I've attached a working patch to the ticket. (I forked in Pagure but it
> seems it won't let me push right now - I guess it needs longer to sync
> than I expected or can be bothered to wait!)
> 
> > dvb-apps
> Was about to say this was fine until I built for rawhide and saw the
> problem.
> https://patchwork.linuxtv.org/patch/43705/ removed the IOCTL it uses
> with the comment that nothing uses it! not sure quite what to say about
> this one. It's old and seems to have a few bugs reported against it -
> https://git.linuxtv.org/v4l-utils.git contains replacements for some of
> them, using the dvbv5 API rather than the dvbv3 API these apps use.
> Easiest thing might be to remove the function the IOCTL is for from
> dst-utils.
> In future we should probably consider encouraging users to move to newer
> utils though.
> 
> Michael
> 
> On Tue, 24 Oct 2017, at 12:53 AM, Ben Rosser wrote:
> > On Mon, Oct 23, 2017 at 9:49 AM, Xose Vazquez Perez
> > <xose.vazq...@gmail.com> wrote:
> > > On 10/22/2017 04:08 PM, Xose Vazquez Perez wrote:
> > >> Mat Booth wrote:
> > >>
> > >>> On 7 August 2017 at 15:35, Dennis Gilmore <den...@ausil.us> wrote:
> > >>>
> > >>>> [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.html
> > >>>>
> > >>>
> > >>> This file seems suspiciously small... I somehow don't believe that there
> > >>> were "0 failed builds" :-)
> > >> Current status?
> > >
> > > Digging a bit deeper, there are ~880 packages with building problems.
> > > Some of them since fedora 20/21:
> > >
> > 
> > > quasselc-0-3.20170111gita0a1e6b | fc26
> > > quassel-irssi-0-4.20170119git7b034e3 | fc26
> > 
> > Where is this list sourced from? I maintain both of these packages,
> > and to my knowledge, they're building fine. (And no FTBFS bugs have
> > been filed against them).
> > 
> > https://koji.fedoraproject.org/koji/packageinfo?packageID=23320
> > https://koji.fedoraproject.org/koji/packageinfo?packageID=23342
> > 
> > This makes me slightly dubious about the rest of the list.
> > 
> > Ben Rosser
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass rebuilds update

[Michael Cullen]

I have a PR up for edb - if i get chance I might take a look at a couple
of others on that list.
In in the case of edb it’s looking a lot like the maintainer is
unresponsive - probably like for many of the package on that list.
Thanks,
Michael


On Mon, 23 Oct 2017, at 08:56 PM, Sérgio Basto wrote:
> On Mon, 2017-10-23 at 15:49 +0200, Xose Vazquez Perez wrote:
> > On 10/22/2017 04:08 PM, Xose Vazquez Perez wrote:
> > > Mat Booth wrote:
> > >
> > > > On 7 August 2017 at 15:35, Dennis Gilmore 
> > > > wrote:
> > > >
> > > > > [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failure> > > 
> > > > > > > s.html
> > > > >
> > > >
> > > > This file seems suspiciously small... I somehow don't believe
> > > > that there
> > > > were "0 failed builds" :-)
> > >
> > > Current status?
> >
> > Digging a bit deeper, there are ~880 packages with building
> > problems.> > Some of them since fedora 20/21:
>
> maybe more , we got some bug trackers like :
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1423041
> https://bugzilla.redhat.com/show_bug.cgi?id=1305208
> https://bugzilla.redhat.com/show_bug.cgi?id=1239338
>
>
> > compat-gcc-296-2.96-146.1
> > fedora-package-config-apt-16.00-10
> > ivtv-firmware-20080701-32
> > reinteract-0.5.9-16
> > shim-signed-13-0.7
> > xml2dict-0-0.12.2008.6.1
> > rubygem-dynect_rest-0.4.3-6 | fc20
> > dia-gnomeDIAicons-0.1-5 | fc21
> > diveintopython-5.4-27 | fc21
> > jam-control-1.03-4 | fc21
> > libverto-jsonrpc-0.1.0-9 | fc21
> > NearTree-3.1.1-8 | fc21
> > OpenStego-0.5.2-14 | fc21
> > publican-fedora-4.0-2 | fc21
> > python-pylons-1.0.1-3 | fc21
> > ratbox-services-1.2.1-11 | fc21
> > R-BSgenome-1.32.0-1 | fc21
> > R-BSgenome.Celegans.UCSC.ce2-1.3.19-5 | fc21
> > R-GenomicFeatures-1.14.2-2 | fc21
> > rubygem-arrayfields-4.7.4-10 | fc21
> > rubygem-attributes-5.0.1-14 | fc21
> > rubygem-chunky_png-1.2.7-3 | fc21
> > rubygem-climate_control-0.0.3-5 | fc21
> > rubygem-coercible-1.0.0-3 | fc21
> > rubygem-dotenv-0.8.0-3 | fc21
> > rubygem-facets-2.8.0-9 | fc21
> > rubygem-git-1.2.5-9 | fc21
> > rubygem-gruff-0.3.6-8 | fc21
> > rubygem-hawler-0.3-13 | fc21
> > rubygem-hydra-0.24.0-6 | fc21
> > rubygem-kwalify-0.7.2-10 | fc21
> > rubygem-markaby-0.5-12 | fc21
> > rubygem-mixlib-authentication-1.3.0-6 | fc21
> > rubygem-mixlib-log-1.6.0-3 | fc21
> > rubygem-orm_adapter-0.5.0-2 | fc21
> > rubygem-pervasives-1.1.0-13 | fc21
> > rubygem-picnic-0.8.1-10 | fc21
> > rubygem-rails_autolink-1.1.6-1 | fc21
> > rubygem-resque-1.25.2-4 | fc21
> > rubygem-restr-0.5.0-10 | fc21
> > rubygem-reststop-0.4.0-10 | fc21
> > rubygem-rmail-1.0.0-11 | fc21
> > rubygem-rspec-longrun-0.1.2-4 | fc21
> > rubygem-rufus-scheduler-2.0.4-9 | fc21
> > rubygem-systemu-2.6.4-2 | fc21
> > rubygem-xmpp4r-0.5-11 | fc21
> > rubygem-xmpp4r-simple-0.8.8-11 | fc21
> > R-xtable-1.7.1-4 | fc21
> > umit-1.0-3 | fc21
> > eurephia-1.1.0-9 | fc22
> > gitstats-0-0.7.20141209gitc2310a8 | fc22
> > hail-0.8-0.16.gf9c5b967 | fc22
> > hive-0.12.0-5 | fc22
> > intrace-1.5-6 | fc22
> > ircd-ratbox-2.2.9-3 | fc22
> > kde-plasma-activitymanager-0.5-8 | fc22
> > kguitar-0.5.1-19.926svn | fc22
> > libkdtree++-0.7.0-8 | fc22
> > monodevelop-debugger-gdb-2.8.8.4-6 | fc22
> > oscap-anaconda-addon-0.7-1 | fc22
> > pam_radius-1.4.0-2 | fc22
> > pdfresurrect-0.12-5 | fc22
> > prozilla-2.0.4-18 | fc22
> > python-djvulibre-0.3.9-4 | fc22
> > python-pyblock-0.53-8 | fc22
> > rubygem-authlogic-3.4.2-1 | fc22
> > rubygem-cookiejar-0.3.2-5 | fc22
> > rubygem-facade-1.0.5-3 | fc22
> > rubygem-innertube-1.1.0-4 | fc22
> > rubygem-mono_logger-1.1.0-3 | fc22
> > rubygem-taskjuggler-3.5.0-1 | fc22
> > rubygem-text-format-1.0.0-13 | fc22
> > shim-0.8-1 | fc22
> > sslogger-0.96-13 | fc22
> > steadyflow-0.2.0-4 | fc22
> > telepathy-haze-0.8.0-3 | fc22
> > udev-browse-0.3-5 | fc22
> > auriferous-1.0.1-20 | fc23
> > brewtarget-2.1.0-3 | fc23
> > centerim-4.22.10-19 | fc23
> > cuneiform-1.1.0-20 | fc23
> > escape-200912250-12 | fc23
> > facter-2.4.3-1 | fc23
> > fbdesk-1.4.1-19 | fc23
> > fbreader-0.12.10-18 | fc23
> > fedorainfinity-screensaver-theme-1.0.0-10 | fc23
> > fedora-screensaver-theme-1.0.0-12 | fc23
> > freehdl-0.0.8-12 | fc23
> > gnue-common-0.6.9-16 | fc23
> > golang-github-influxdb-gomdb-0-0.2.git29fe330 | fc23
> > gtkmathview-0.8.0-19 | fc23
> > horst-3.0-6 | fc23
> > ibus-unikey-0.6.1-9 | fc23
> > kawa-2.0-2 | fc23
> > klatexformula-3.2.10-5 | fc23
> > kmplayer-0.11.3c-10 | fc23
> > libexplain-1.4-4 | fc23
> > libmimedir-0.4-14 | fc23
> > libtaginfo-0.2.0-5 | fc23
> > loki-lib-0.1.7-13 | fc23
> > manaplus-1.3.10.27.2-8 | fc23
> > mod_ruid2-0.9.8-3 | fc23
> > opal-3.10.10-9 | fc23
> > ortp-0.23.0-2 | fc23
> > pikdev-0.9.2-21 | fc23
> > piklab-0.16.1-12 | fc23
> > pyrrd-0.1.0-8 | fc23
> > python-jabberbot-0.15-4 | fc23
> > python-kiwi-1.9.38-5 | fc23
> > python-pottymouth-2.2.1-7 | fc23
> > python-subvertpy-0.9.1-6 | fc23
> > qdevelop-0.29-5 | fc23
> > qtoctave-0.10.1-19 | fc23
> > qutim-0.3.2-5.git.6f3a98a | fc23
> > 

New Package: PDC Branch already exists?

[Michael Cullen]

Can anyone give me a hint as to what happened here? Did the package
somehow get partially 
created?https://pagure.io/releng/fedora-scm-requests/issue/2269

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

EDB: a cross platform x86/x86-64 debugger - Status in Fedora

[Michael Cullen]

Hi,

I stumbled upon EDB [1] the other day and it looks fairly close to what
I've been looking for for a while now. It seems the Fedora package is
about 5 years out of date so I submitted a PR [2] for it. There's also a
COPR build of that branch [3] in case anyone wants to try it. Finally,
there's a ticket for the update here to match the usual process: [4]

There has been a FTBFS ticket [5] open since 2017-02-17 which this PR
also fixes (before removing the offending line completely!)  

As indicated in the PR, I am willing to take over this package if the
original maintainer is no longer interested.

Thanks,
Michael

[1] https://github.com/eteran/edb-debugger
[2] https://src.fedoraproject.org/rpms/edb/pull-request/1
[3] https://copr.fedorainfracloud.org/coprs/mich181189/edb-update-test/
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1502328
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1423511
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: icemon: icecream monitor - reviving a dead review

[Michael Cullen]

Thanks. Looks like the old one was already closed for being old.

New review is here: https://bugzilla.redhat.com/show_bug.cgi?id=1476014

I'm happy to swap with someone.

Thanks,
Michael

On Thu, 27 Jul 2017, at 07:55 PM, Jason L Tibbitts III wrote:
> >>>>> "MC" == Michael Cullen <mich181...@fedoraproject.org> writes:
> 
> MC> - would it be better to create a new review ticket or take over the
> MC> existing one?
> 
> Please create a new ticket and close the old one as a duplicate.  That
> way the original submitter can remove their address from the CC list if
> they're not interested, and things are kept reasonably tidy.
> 
>  - J<
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

icemon: icecream monitor - reviving a dead review

[Michael Cullen]

Hi,

I noticed there's an old review for icemon [1] which I'd like to revive
- would it be better to create a new review ticket or take over the
existing one?

Thanks,
Michael


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1311959
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Slightly Odd Package Status: dissy

[Michael Cullen]

Hi,

I retired dissy on master the other day (since it depends on an old
unmaintained webkit version that will disappear in f27) and while pkgdb
shows the correct status of in all releases except devel, it seems to
have ended up in 24, 25 and 27 but not 26 according to
https://apps.fedoraproject.org/packages/dissy - and the compose email
backed that up the other day.

Any ideas what happened there? I was perhaps a bit too keen to retire on
27 :-P

Thanks,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Michael Cullen]

On Thu, 5 Jan 2017, at 04:28 PM, Christian Schaller wrote:
> While most desktop applications have migrated to 64 bit at this point
> there are
> still many that hasn't. Steam for instance is still 32-bit afaict. So
> doing a clean
> cutover like this feel a bit to drastic to me and I am not sure we have
> the market power
> to 'force' vendors to quickly migrate to containers.
> 
> Christian
> 
> 
> 
> - Original Message -
> > From: "Stephen Gallagher" 
> > To: "Development discussions related to Fedora" 
> > 
> > Sent: Thursday, January 5, 2017 11:03:50 AM
> > Subject: Proposal: Rethink Fedora multilib support
> > 
> > # Overview
> > 
> > For many years, Fedora has supported multilib by carrying
> > parallel-installable
> > libraries in /usr/lib[64]. This was necessary for a very long time in order
> > to
> > support 32-bit applications running on a 64-bit deployment. However, in
> > today's
> > new container world, there is a whole new option.
> > 
> > I'd like to propose that we consider moving away from our traditional
> > approach
> > to multilib in favor of recommending the use of a 32-bit container runtime
> > when
> > needed on a 64-bit host.
> > 
> > 
> > ## Advantages
> > 
> > * Simplification of build-tree creation. We wouldn't have to maintain the
> > lists
> > and hacks that are required to make sure that multilib packages land in the
> > correct repositories.
> > 
> > * Less duplication of content in the mirror networks.
> > 
> > * It will be simpler to create module content without having to reimplement
> > all
> > the multilib hacks of above. This is directly relevant to the Base Runtime
> > module, whose prototype is today intentionally limited to the primary
> > architecture (no multilib).
> > 
> > * Requires us to maintain and keep up-to-date the 32-bit container base
> > images.
> > 
> > 
> > ## Disadvantages
> > 
> > * If we eliminate multilib entirely, all applications that use 32-bit libs
> > will
> > have to either install a 32-bit host OS or install into a container. This 
> > may
> > be
> > a difficult transition for some users.
> >   * Mitigation: develop and maintain tools to ease this transition.
> > 
> > * It is unlikely that any clean upgrade path would exist. (We could make it
> > *technically* possible, but likely not without breaking 32-bit software not
> > installed by RPM.
> > 
> > * Requires us to maintain and keep up-to-date the 32-bit container base
> > images.
> > (Yes, this is both an advantage and disadvantage.)
> > 
> > 
> > ## Open Questions (non-exhaustive):
> > 
> > * Can SSSD and systemd's 32-bit name-service modules work from within a
> > container, talking to their host's service? Without that, 32-bit containers
> > won't be able to resolve users, groups or hostnames.
> > 
> > * Can we have 32-bit containers communicate with other local system APIs 
> > such
> > as
> > D-BUS on the host?
> > 
> > * Do we need to care about 32-bit GUI applications on a 64-bit system? 
> > Should
> > we
> > decide that flatpak is the official answer for such cases?
> > 
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Doesn't sound great to me. At work I use a lot of 32-bit prebuilt
toolchains for embedded devices. While I actually do often run them in a
container, requiring using a container feels a bit heavy weight when
most of the time I would rather not think about them as 32-bit
executables - rather just executables! This is yet another case where
being able to run 32 and 64 bit tools along side each other without
thinking too much about it makes sense!

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Self Introduction: Michael Cullen

[Michael Cullen]

Hi!

I've just submitted a review request here
https://bugzilla.redhat.com/show_bug.cgi?id=1332344

I'm a software developer from the UK currently living and working in
London on Linux-based set top box middleware. I've been a Linux user for
a long time, but never really offered much back. I've tried many
distros, but always seem to keep coming back to Fedora. Anyway, I've
decided it's probably time I offered something back, and packaging seems
like as good an idea as any. 

Why this package? Well it seemed like a fairly easy one to start with
and I used to work on a Qt-based product so I know it well. Also it
plays into my interest in imaging and media.

My interests outside of software are travel and photography (even if I
do rather more of the latter) and I'm also sometimes found (literally)
hanging around local climbing centres. 

Anyway, let me know if you have any questions about this!

Thanks,
Michael
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org