from:"Jorge Gallegos"

Re: Kubernetes Development SIG

2020-09-18 Thread Jorge Gallegos

Count me in :)

On Tue, Sep 15, 2020 at 10:45:07AM -0300, Leonardo Rossetti wrote:
> Hello all,
> 
> I would like to present a Kubernetes Development SIG.
> 
> I initially thought of an "operator SIG" but I think a wider SIG about
> programming components and services with Kubernetes APIs and internal
> components made more sense (inspired by the "Programming Kubernetes" book).
> 
> I am using some of the fields/titles described in this document [1] as the
> proposal template.
> 
> Proposal Name
> 
> 
> SIG: Kubernetes Development
> 
> Summary
> ===
> 
> A SIG for people interested in using, developing, extending kubernetes for
> Fedora components and services.
> 
> Owner
> =
> 
> Name: Leonardo Rossetti (lrossett)
> Email: lross...@redhat.com
> 
> Benefit to Fedora
> =
> 
> Development Experience and Learning
> 
> 
> A place to exchange and discuss kubernetes development design and patterns.
> 
> Extending kubernetes is not that straightforward so this SIG would be a
> good place to learn more about it.
> 
> Kubernetes can be extended in the following areas:
> 
> * Kubectl Plugins
> * Custom API Servers
> * Custom Controllers / Operators
> 
> Operator Development
> ---
> 
> The Operator SDK [3] is the shining new framework when developing custom
> kubernetes controllers nas has become a popular tool for packaging and
> deploying applications in kubernetes.
> 
> Some Fedora services and components could leverage the usage of an operator
> (as we are doing with MBBOX [2]) but other services could be deployed via
> operators as well and even the mbbox operator could be split into smaller
> operators.
> 
> Kubernetes DevOps
> ---
> 
> The SIG could also be a place for sysadmins and ops engineers to discuss
> the challenges, practices and tooling of monitoring, deploying and running
> operators, api servers and other related kubernetes components in
> production.
> 
> [1] - https://fedoraproject.org/wiki/Changes/EmptyTemplate
> [2] - https://github.com/fedora-infra/mbbox
> [3] - https://github.com/operator-framework/operator-sdk
> 
> -- 
> 
> Leonardo Rossetti
> 
> Senior Software Engineer,
> 
> Red Hat 
> 
> lross...@redhat.com
> 

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


-- 
"So, will the Andover party have a cash bar?"
"No, there's free beer."
"Uh-oh, Stallman's gonna be pissed..."
-- overheard at the Bazaar, 1999


signature.asc
Description: 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Many packages unnecessarily link to libpython

2020-05-15 Thread Jorge Gallegos

Hi,

On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote:
> Hello everyone,
> 
> As of Python 3.8, python C extensions modules should not link to libpython, 
> unless they embed the interpreter in their code. Relevant upstream PR: 
> https://github.com/python/cpython/pull/12946
> If your package links to libpython without requiring it, it won't be possible 
> to use the python3-debug binary with your python C extension, unless you 
> recompile the extension against it.
> 
> On Fedora Rawhide, there are at this point 144 packages linking to libpython, 
> many of those possibly without any need for it.
> 
> If your package links to libpython but it does not embed the interpreter, I 
> would like to ask you to unlink it. Usually the fix needs to be done at the 
> package's build system.
> 
> If you are not sure if your package links to libpython, a way to figure this 
> out  is to inspect the code for the Py_Initialize and the Py_Finalize calls 
> [0]. If the code includes those calls, no action is required from your side. 
> If it does not, linking to libpython is not required.
> 
> I might mass file bugzillas at a later date, but I wanted to provide you the 
> heads up before that.
> 
> [0] 
> https://docs.python.org/3/c-api/init.html#initializing-and-finalizing-the-interpreter
> 
> List of possibly affected packages, provided through $ repoquery 
> --repo=rawhide --source --whatrequires 'libpython3.8.so.1.0()(64bit)'
> 
> Maintainers by package:
> 
> COPASI   sagitter
> HepMC3   ellert
> Io-language  limb
> OpenImageIO  hobbes1069
> PyQt4rdieter than
> YafaRay  luya roma slaanesh
> apbs rathann sagitter
> babeltrace2  mjeanson
> blender  design-sw hobbes1069 ignatenkobrain kwizart luya roma 
> s4504kr slaanesh
> boostdenisarnaud jwakely
> calamareskkofler mattia
> calibre  chkr heliocastro kevin nushio zbyszek
> cantor   jreznik rdieter than
> ceph adeza branto dmick ke4qqq kkeithle ktdreyer steve 
> stingray
> clingo   thofmann
> collectd fab kevin mhlavink ruben xaeth
> condor   bbockelm bcotton eerlands matt matyas stevetraylen 
> tstclair ttheisen valtri
> createrepo_c dmach jrohel mblaha pkratoch tmlcoch
> csound   pbrobinson sdz
> cvc4 brouhaha jjames
> dionaea  rebus
> dmlite   adev andreamanzi gbitzes okeeble rocha
> fontforgefrixxon kevin pnemade
> freecad  hobbes1069 jkastner zultron
> gdb  jankratochvil keiths kevinb sergiodj
> gdcm ankursinha ignatenkobrain mrceresa sebp
> gdl  orion
> getdpignatenkobrain smani
> gladekalev
> globus-net-manager   ellert
> glom hguemar
> gnucash  notting
> gnuradio jskarvad mmahut
> gpaw marcindulak
> gplugin  ignatenkobrain
> gr-air-modes jskarvad
> gr-fcdproplusjskarvad
> gr-hpsdr jskarvad
> gr-iqbal jskarvad
> gr-osmosdr   cottsay jskarvad
> gr-rds   jskarvad sharkcz
> hamlib   hobbes1069 jskarvad lucilanga
> hexchat  ohaessler tingping
> hokuyoaist   rmattes
> huginbpostle cicku denisarnaud
> insight  lkundrak monnerat
> kdevelop-python  dvratil jgrulich minh
> kernel-tools jcline jforbes jwboyer labbott pbrobinson
> kicadavigne coremodule lkundrak stevenfalco tnorth
> kig  jreznik kkofler rdieter
> kittyatim
> kritaheliocastro rdieter
> lammps   ellio167 junghans
> ldns pemensik pwouters thozza
> libCombine   sagitter
> libarcus churchyard gferon
> libarcus-lulzbot spot
> libbatch smani
> libcec   pbrobinson
> libcomps akozumpl dmach jluza jmracek mblaha pkratoch
> libdnf   dmach jmracek jrohel mblaha pkratoch
> libftdi  hobbes1069 lucilanga
> libkml   smani
> libkolabxml  tpokorra
> libldb   abbra asn gd iboukris jhrozek lslebodn sgallagh simo
> libnuml  sagitter
> libpeas  amigadave hadess nacho
> libplist hadess pbrobinson
> libreoffice  caolanm dtardon erack sbergmann
> librepo  dmach pkratoch tmlcoch
> libsavitar   churchyard gferon
> libsbml  sagitter zbyszek
> libsedml sagitter
> libsigrokdecode  mrnuke
> libtallocasn gd iboukris jhrozek lslebodn sgallagh simo
> libyang  tkorbar
> libyui-bindings  makowski ngompa tpokorra
> link-grammar devos fabiand limb
> lldb airlied daveisfera jankratochvil sergesanspaille 
> siddharths

Re: pagure ssh key

2020-04-14 Thread Jorge Gallegos

On Tue, Apr 14, 2020 at 02:14:40PM -0700, Samuel Sieb wrote:
> I'm wanting to make a pull request on src.fedoraproject.org, so I need to
> setup an ssh key.  According to the docs at
> https://docs.pagure.org/pagure/usage/first_steps.html, there should be an
> authentication section in my settings, but there isn't.  Then I remembered
> that I added an ssh public key to my FAS profile on admin.fedoraproject.org.
> I checked that and it's valid and matches my key.  I've given it some time
> (hours) in case there's some delay needed after forking.  However, I'm still
> getting an authentication error when trying to clone using git over ssh.
> ss...@pkgs.fedoraproject.org: Permission denied (publickey)
> 
> Is there something I'm missing?  I'm not a packager, but I have a FAS
> account and it let me fork the repo.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Hi Samuel,

What happens if you go to https://pagure.io/settings#nav-ssh-tab while
logged in with your FAS account in pagure?


Cheers,

-- 
I can resist anything but temptation.


signature.asc
Description: 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Reminder: GitHub etc. auto-generated archives are not stable in time

2017-05-24 Thread Jorge Gallegos

On Wed, May 24, 2017 at 04:19:05PM +0200, Jan Pokorný wrote:
> Hello,
> 
> today, I've accidentally attested there are no stability guarantees
> with the on-demand archives from common git hosting sites when preparing
> a new pacemaker update, redownloading "spectool -s 0 pacemaker.spec"
> of the original (-0.1.rc1, from 2 weeks ago) spec and comparing the

Are you pointing to a _tag_ (or as github likes to call them: release) ?
As far as I know tags can be re-created, isn't that what is happening
here?

> hashes, which (surprisingly to me) didn't match (they were at any similar
> test in the past).  Then I looked at the adiff output:
> 
> > diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac 
> > Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac
> > --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 
> > 00:55:15.0 +0200
> > +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 
> > 00:55:15.0 +0200
> > @@ -1159,7 +1159,7 @@
> >  AC_PATH_PROGS(GIT, git false)
> >  AC_MSG_CHECKING(build version)
> >  
> > -BUILD_VERSION=0459f40
> > +BUILD_VERSION=0459f40958
> >  if test  != ":%h$"; then
> > AC_MSG_RESULT(archive hash: )
>  
> for configure.ac that indeed has export-subst git attribute set
> and the change itself arises from "$Format:%h$" substitution.
> This likely means GitHub was internally updated to use equivalent
> of git 2.11 feature of abbreviation length autoscaling within
> last 14 days.

This is the other bit that makes me think it was actually the
maintainers hand that moved this, I don't believe github does anything
special to the code once it's stored there. There is no way for github
to alter code afaik? This would suggest to me the maintainer:

a) Modified the code (either via script or otherwise)
b) Deleted the tag (and thus, the github "release")
c) Submitted a new tag (and created a new gh release)

Of course if the .spec is pointing to an archive url pointing to a git
SHA my theory is busted.

> 
> Hope this will be useful for some (e.g. fedora-review tool
> has a check to redownload and diff sources against SRPM content,
> IIRC).
> 
> -- 
> Jan (Poki)



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


-- 
~kad


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Cannot dnf group remove "Cinnamon Desktop"

2017-05-10 Thread Jorge Gallegos

On Mon, May 08, 2017 at 12:02:40PM -0400, Dan Book wrote:
> On Mon, May 8, 2017 at 10:40 AM, Jorge Gallegos <k...@blegh.net> wrote:
> 
> Hi,
> 
> I found out the Cinnamon Desktop group is behaving like Hotel
> California. I had ``dnf group install "Cinnamon Desktop"`` some time in
> the past, and was trying to cleanup now after finishing fiddling with
> it. It turns out that Cinnamon Desktop's dependencies somehow bind to
> protected dependencies, i.e.
> 
> ```
> [root@ragnia ~]# dnf group remove "Cinnamon Desktop"
> Last metadata expiration check: 2:18:50 ago on Mon May  8 07:18:18 2017.
> Dependencies resolved.
> Error: The operation would result in removing the following protected 
> packages: dnf, systemd, systemd-udev.
> ```
> 
> Is this intended? A cursory search in bugz turns out no real results,
> but wanted to make sure if maybe I am missing something here, if not I
> will be opening a new bug.
> 
> 
> Try setting clean_requirements_on_remove=False in /etc/dnf/dnf.conf. See 
> http://dnf.readthedocs.io/en/latest/
> conf_ref.html#main-options

This appears to have no effect on dnf group operations?

```
[root@ragnia ~]# dnf --setopt "clean_requirements_on_remove=False" group remove 
"Cinnamon Desktop"
Last metadata expiration check: 2:25:11 ago on Wed May 10 10:42:51 2017.
Dependencies resolved.
Error: The operation would result in removing the following protected packages: 
dnf, systemd-udev, systemd.
```

I tried editing /etc/dnf/dnf.conf as well with the same results

>  

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


-- 
~kad


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Cannot dnf group remove "Cinnamon Desktop"

2017-05-10 Thread Jorge Gallegos

On Tue, May 09, 2017 at 12:09:48PM +0200, Rafal Luzynski wrote:
> Hi,
> 
> 8.05.2017 16:40 Jorge Gallegos <k...@blegh.net> wrote:
> > [...]
> > [root@ragnia ~]# dnf group remove "Cinnamon Desktop"
> > Last metadata expiration check: 2:18:50 ago on Mon May 8 07:18:18 2017.
> > Dependencies resolved.
> > Error: The operation would result in removing the following protected
> > packages: dnf, systemd, systemd-udev.
> 
> 1. Have you fixed your problem already?

I have not, but since it's not my main workstation I can live with that
for now

> 2. I guess that dnf history undo would do the job.

Hrm, I haven't looked at dnf history, fwiw this is the rough timeline of
events:

1. install fedora 23 workstation (comes with gnome)
2. dnf group install "Cinnamon Desktop"
3. live with it for a year or so
4. fedora-upgrade to fedora 24, then to 25
5. found the alleged bug

As you can see, the "original" DE was gnome, unsure how Cinnamon
packages are taking over dependencies, I am going to test Dan's approach
and not uninstall dependencies (only components of the group)

> 3. What is your Fedora version (or what is your distro if it is
> not Fedora) and what desktop environment did you have installed
> before installing Cinnamon Desktop? My guess is that Cinnamon
> replaced (uninstalled) some components of your previous desktop
> which are required by whole OS. So now when you uninstall Cinnamon
> you also uninstall those obligatory components. Instead (or rather
> before) uninstalling them you'd have to reinstall your previous
> desktop. But that's my guess only.
> 
> It may be a bug or it may not be a bug. We will not know without
> trying to reproduce. Or it may be a bug but not worth fixing because
> probably a workaround exists and probably switching desktops is
> considered too advanced to be worth making easier.
> 
> Regards,
> 
> Rafal

-- 
~kad


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Cannot dnf group remove "Cinnamon Desktop"

2017-05-08 Thread Jorge Gallegos

Hi,

I found out the Cinnamon Desktop group is behaving like Hotel
California. I had ``dnf group install "Cinnamon Desktop"`` some time in
the past, and was trying to cleanup now after finishing fiddling with
it. It turns out that Cinnamon Desktop's dependencies somehow bind to
protected dependencies, i.e.

```
[root@ragnia ~]# dnf group remove "Cinnamon Desktop"
Last metadata expiration check: 2:18:50 ago on Mon May  8 07:18:18 2017.
Dependencies resolved.
Error: The operation would result in removing the following protected packages: 
dnf, systemd, systemd-udev.
```

Is this intended? A cursory search in bugz turns out no real results,
but wanted to make sure if maybe I am missing something here, if not I
will be opening a new bug.


Cheers

-- 
~kad


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Renaming the cloud-utils package

2014-02-19 Thread Jorge Gallegos

If upstream (in this case ubuntu) renamed it totally makes sense to
rename. As for the rpm implications I believe you:

1) notify the list package(s) renaming
2) add the appropriate Obsoletes tag in the new packages

That's it I think? someone else may want to weigh in tho.

On Wed, Feb 19, 2014 at 06:18:30PM +0100, Juerg Haefliger wrote:
 Hi,
 
 I'm trying to figure out if it makes sense to rename the cloud-utils (sub-)
 package for EPEL7 and F21.
 
 Upstream (Ubuntu) used to have a single package named cloud-utils which we
 decided to split up into two packages, cloud-utils and cloud-utils-growpart.
 The reason being that cloud-utils pulls in a lot of additional packages which
 is sub-optimal for cloud images.
 
 Now Ubuntu followed suit and provides cloud-guest-utils and cloud-image-utils
 sub-packages. My question is if we should align with Ubuntu and rename our
 packages or stick with what we have?
 
 I admit I'm ignorant to all the ramifications of renaming a package but from a
 user's perspective it's definitely a benefit if package names match across
 distros.
 
 Thanks
 ...Juerg
 

 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


-- 
~kad


pgpALIIG4zPPh.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sub-package dropped upstream

2014-01-09 Thread Jorge Gallegos

On Thu, Jan 09, 2014 at 10:45:44PM +0100, Michael Schwendt wrote:
 On Thu, 9 Jan 2014 22:20:10 +0100, Alec Leamas wrote:
 
  Yes, still it's an interesting issue... perhaps one count how many which
  actually are installed,
 
 Installed and used actively would be more interesting.
 
 Especially with regard to optional plugins, which perhaps are not
 loaded/executed at runtime automatically. For example, multimedia users
 follow instructions found on the web that lead to installing all codec
 packages, whether they need them or not. Watching statistics you might
 think hey, there are WavPack or Musepack users, but maybe they never
 use files of that type.

it'd be interesting to know how debian QA takes metrics like these:

http://qa.debian.org/popcon-graph.php?packages=python-bottle%2C+python-flaskshow_installed=onwant_legend=onfrom_date=to_date=hlght_date=date_fmt=%25Ybeenhere=1

I haven't looked but pretty sure these are not recorded via some
unauthorized callback (being debian and all), perhaps these are just
rough download statistics.

 
  but many problems also here: users privacy/opt-in,
  easily spoofed, infrastructure.
 
 And it wouldn't force a packager in any way, maybe serve as some minor
 influence only.
 
 It would not be the first plugin/subpackage that has been discontinued
 during the lifetime of a distribution.
 
 If a package were considered popular enough, the packager would
 not want to upgrade the software to a newer version that removes the
 package? There are other more important factors when considering a
 version upgrade.
 
 And probably most important, you cannot get an obsolete package to
 reinstall automatically once it would become available again. User
 would need to take notice and reinstall manually (unless packager
 plays tricks or makes it a new requirement).

The package may not come back any time soon, and I actually have no idea
if patching it back from the old sources would be feasible (I haven't
looked to what extent it is broken.) If it does come back in the future
I understand it should be named something else... should that potential
future package _also_ obsolete this one? (I don't think so?)

 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
~kad


pgpI50ulv0_vh.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sub-package dropped upstream

2014-01-09 Thread Jorge Gallegos

On Thu, Jan 09, 2014 at 02:38:50PM -0800, Jorge Gallegos wrote:
 On Thu, Jan 09, 2014 at 10:45:44PM +0100, Michael Schwendt wrote:
  On Thu, 9 Jan 2014 22:20:10 +0100, Alec Leamas wrote:
  
   Yes, still it's an interesting issue... perhaps one count how many which
   actually are installed,
  
  Installed and used actively would be more interesting.
  
  Especially with regard to optional plugins, which perhaps are not
  loaded/executed at runtime automatically. For example, multimedia users
  follow instructions found on the web that lead to installing all codec
  packages, whether they need them or not. Watching statistics you might
  think hey, there are WavPack or Musepack users, but maybe they never
  use files of that type.
 
 it'd be interesting to know how debian QA takes metrics like these:
 
 http://qa.debian.org/popcon-graph.php?packages=python-bottle%2C+python-flaskshow_installed=onwant_legend=onfrom_date=to_date=hlght_date=date_fmt=%25Ybeenhere=1
 
 I haven't looked but pretty sure these are not recorded via some
 unauthorized callback (being debian and all), perhaps these are just
 rough download statistics.

Hah!, found it right after I sent the email: http://popcon.debian.org

 
  
   but many problems also here: users privacy/opt-in,
   easily spoofed, infrastructure.
  
  And it wouldn't force a packager in any way, maybe serve as some minor
  influence only.
  
  It would not be the first plugin/subpackage that has been discontinued
  during the lifetime of a distribution.
  
  If a package were considered popular enough, the packager would
  not want to upgrade the software to a newer version that removes the
  package? There are other more important factors when considering a
  version upgrade.
  
  And probably most important, you cannot get an obsolete package to
  reinstall automatically once it would become available again. User
  would need to take notice and reinstall manually (unless packager
  plays tricks or makes it a new requirement).
 
 The package may not come back any time soon, and I actually have no idea
 if patching it back from the old sources would be feasible (I haven't
 looked to what extent it is broken.) If it does come back in the future
 I understand it should be named something else... should that potential
 future package _also_ obsolete this one? (I don't think so?)
 
  -- 
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 
 -- 
 ~kad



-- 
~kad


pgpgbpHaw4nIi.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

License change for uwsgi

2013-10-08 Thread Jorge Gallegos

Hello,

The author of uwsgi has decided to change the license:

 GPL2 + linking exception

 instead of GPL2

From http://lists.unbit.it/pipermail/uwsgi/2013-October/006516.html

This announcement was made after 1.9.17 so the new license should come
into effect in 1.9.18.
Anyone knows how to properly add such a change to the spec file?
Currently it has:

License:GPLv2

And I believe I should change it to 

License:GPLv2 with exceptions

If anyone sees anything wrong with the above please let me know.


Thanks.
-- 
~kad


pgpkb4g_kHJFd.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: using rpms for non-root installs

2013-01-30 Thread Jorge Gallegos

On Wed, Jan 30, 2013 at 04:06:35PM -0600, Mátyás Selmeci wrote:
 Hi,
 
 This may be a long shot, but I am interested in repackaging some RPMs (for
 example, some of the Globus packages in EPEL, as well as grid software that my
 group builds) such that the software in them may be installed by unprivileged
 users, or into a non-standard location such as an NFS share. I'd like to use
 existing RPMs, preferably binaries, as a starting point to avoid duplicating
 work. (Naturally a lot of post-install scripting would be needed to fix
 binaries such that they'd work with the path they were installed into).

Going out on a limb here but, probably you can use yum --installroot,
sorta like mock does.

 
 Have there been any projects with this goal in mind?
 Have any of you had experience with this sort of thing and have tips, tools,
 etc. that might help me out in this?
 
 Thanks in advance,
 -Mat
 --
 -Matyas Selmeci
 Open Science Grid Software Team
 Center for High Throughput Computing
 University of Wisconsin-Madison



 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel



pgpmMO_vTgmO_.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PEAR not entirely in EPEL?

2012-07-13 Thread Jorge Gallegos

That explains it. Thanks a lot!

~kad (android'ed)
On Jul 12, 2012 10:31 PM, Remi Collet fed...@famillecollet.com wrote:

 Le 13/07/2012 07:22, Jorge Gallegos a écrit :
  Hello everyone,
 
  Am I reading this right? the main PEAR package is not in any EPEL
  version:
 
  https://admin.fedoraproject.org/pkgdb/acls/name/php-pear
 
  However some PEAR libraries *are* in EPEL, which confuses me a
  little bit. How come some libraries are there but not php-pear?

 php-pear is part of the main repository.

 version 1.4.9 on RHEL-5
 version 1.9.4 on RHEL-6

 remi
 
 
  Thanks in advance
 
 
 


 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning two Drupal modules

2012-02-21 Thread Jorge Gallegos

I can take drupal6-yubikey unless someone else wants it.

On Tue, Feb 21, 2012 at 11:37:05AM -0500, Eric Sparks Christensen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
I am orphaning the following packages:
 
drupal6-video
drupal6-yubikey
 
Each module has a bug (728803 and 728804) against them involving bundling
of external source which was not caught during the packaging or review.
 Anyone wishing to take ownership fo these pacakges should work to remedy
these bugs.
 
- -- Eric
 
- --
Eric H Christensen        [1]e...@christensenplace.us
Sparks                  [2]spa...@fedoraproject.org
   .. .-.. .-.. ---   .-- --- .-. .-.. -..
097C 82C3 52DF C64A 50C2  E3A3 8076 ABDE 024B B3D1
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
 
iQIcBAEBAgAGBQJPQ8Z9AAoJEIB2q94CS7PRToUP/iWvoEP3s2yxmV8ShAz7SRR7
Xvp7WvKiPejowjtMUKvpQRQhWhlJsQfM3wwlOitHP8lLU8oNFtx2n5NaJcDaGPKY
2ptyHgqUlpNzTeumRCbqfLsT2jMblLBsmwgiNIY7Ft41hYqduhtcWsqyo2AZ2MRZ
e6FJYjtnvk4Oz8kNv0h+mcUmbQ23p+cT/BEfFhMPvdXeYCRI+X8UlX5+PawVY4m7
Ac4jYj5vQHyKXowYtDcFZW+XcQg3FEIIjmGyo8VA9OUw/H7p5JsE5F7htvfwSzVE
7v1Sq77RlQMryH4ja0AMFyux4UYxu6Xk0+aWOVb4ZL9kfYGnZrcqu5tzSFnk0070
yaBPjo3D55zX60wDNGGRTab76nwOe1N70FnNF1er2xZlzA41upmIKrzGtNFiQAFz
zr6z6i5RWud1dsNpFJDn7cFamRxSKOLEA6+P5mNLYEVXDCq1OXI/e4qf3arrUJLD
wnGQuQaVt5pDkR6nFl5E92q3IpLBuJbCALyUuwGmGcc7o3zrj0QLBVMwOer9P/AT
LUUolEfplF5kfK8vhPBto8EEG/Ubl3qrAk89/94+txtsPGzzJatSejhmXNAj4KZg
SZpel2oa4q1LgirosqySkA6XyegWGD3c1Uvd8rvRnCHw4JsIugbL/liP0Me6/PcK
UQnZh+E56z0wyXsxKDfs
=2IWa
-END PGP SIGNATURE-
 
 References
 
Visible links
1. mailto:e...@christensenplace.us
2. mailto:spa...@fedoraproject.org

 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel



pgpVSxCmjevJ2.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Yum S3 plugin

2011-09-16 Thread Jorge Gallegos

Hi,

On Thu, Sep 15, 2011 at 11:57:51AM -0400, James Antill wrote:
 On Wed, 2011-09-14 at 21:48 -0700, Jorge Gallegos wrote:
  So, I gather no one can shed some light on this? anyone? bueller?
  
  The bug (point #2) doesn't really stop the plugin from working, but it is 
  annoying.
  
  Any help would be much appreciated
 
  You'd probably have been better off mailing this to the yum devel ML
 and not fedora-devel. Anyway...

*Facepalm* you're right. My apologies... I guess I gotta work a little less 
because I don't know what I'm thinking half the time :-/

 
- Fix an annoying bug where the plugin creates an empty yum cachedir in
   the current directory. This is because the way the plugin works, it
   creates a copy of the original repo with a different grabber based on
   boto/urllib2 and then copies the rest of the attributes. However when
   the [3]new repo is created, basecachedir is empty. Can any of you fine
   people spot a way around that? it's been bugging me for a good week now.
 
  This is due to the switch you are doing on the repo. objects ... using
 itermitems() seems like it's clever, to get all the data from the
 swapped out repo. ... but that's actually inherited from the config.
 object, so all you are setting are the config. options.

Actually I did this because a bunch of attrs like name and etc. weren't set. I 
thought this would be easier than fishing for the missing attrs

  The RHN plugin just manually sets .base_persistdir, IIRC, and that will
 probably fix it for you too. For your usecase I'd be very tempted to not
 do the swapout at all (as it requires a lot of testing/etc.) as all you
 really need is to override the grab object and set a couple of things.
 

I'll take a look at the RHN plugin (should've seen that one sooner too ~.~ ) 
and maybe you're right... I _should_ be able to just override the grabber. I'll 
explore both.

Thanks a lot!

 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel


pgpDwe1QIAKuA.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Yum S3 plugin

2011-09-14 Thread Jorge Gallegos

So, I gather no one can shed some light on this? anyone? bueller?

The bug (point #2) doesn't really stop the plugin from working, but it is
annoying.

Any help would be much appreciated

On Fri, Sep 09, 2011 at 01:03:24PM -0700, Jorge Gallegos wrote:
(to both cloud@ and devel@)

I was interested in a yum plugin to support S3, and discovered [1]this
forum post, where Seth and James basically gave their thumbs up. The
author (Robert Mela, even though he's not the original author either)
made it work and there was some feedback provided, which I incorporated,
along with a bunch of small improvements in my [2]github branch.

Robert says in the forum post that he'll be happy if someone shepherds
this into completion and I'm more than happy to try.

Right now the plugin works, is a bit more aligned with the yum plugin
architecture I think (I'd really like it to be true :) and also allows
you to set the S3 credentials on a global, per-repo or using environment
variables.

There are 2 things I want to complete/need help with:
- Package it as an RPM: I have a half-finished spec for this and I
should have no problems finishing as long as I can deal with the item
below:
- Fix an annoying bug where the plugin creates an empty yum cachedir in
the current directory. This is because the way the plugin works, it
creates a copy of the original repo with a different grabber based on
boto/urllib2 and then copies the rest of the attributes. However when
the [3]new repo is created, basecachedir is empty. Can any of you fine
people spot a way around that? it's been bugging me for a good week now.

thoughts? comments? suggestions? let me know :)

Cheers
~kad

PS if you're asking yourselves: Why would you need this plugin if you
can create websites off an S3 bucket? the answer is: using S3 offers
more granularity to share, instead of just opening up the contents of
the bucket to the entire world.

[1]
http://www.bluequartz.us/phpBB2/viewtopic.php?p=568109sid=d3462de3a07fc65561c69f5b940ac6df
[2] https://github.com/thekad/yum-s3-plugin/tree/v1.1.x
[3] https://github.com/thekad/yum-s3-plugin/blob/v1.1.x/s3.py#L228

pgp8Ua5Wve8KX.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Yum S3 plugin

2011-09-09 Thread Jorge Gallegos

(to both cloud@ and devel@)

Robert says in the forum post that he'll be happy if someone shepherds
this into completion and I'm more than happy to try.

thoughts? comments? suggestions? let me know :)

Cheers
~kad

signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Yum/Bugzilla feature requests

2011-09-03 Thread Jorge Gallegos

Regarding bugzilla, you can close your bug report and mark it as a duplicate
of the earlier bug report (you provide the number). This will also add a
note to the the original bug report about the duplicate.

Hth.
On Sep 2, 2011 11:19 AM, Barry Fishman barry_fish...@acm.org wrote:
 Recently while running Fedora 16, my attempt at:

 yum update --skip-broken

 failed with:

 warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID
069c8460: NOKEY
 Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64


 The GPG keys listed for the Fedora 16 - x86_64 repository are already
installed but they are not correct for this package.
 Check that the correct key URLs are configured for this repository.

 Looking at bug #735037, It seems that there was a problem with package
 btrfs-progs.

 Couldn't yum refers to 'this package' but does not say which package was
 the problems. If it at least said which package was involved, I could
 have uninstalled that package and updated everything else.

 Better yet 'yum --skip-broken' could have removed that package from
 consideration, redid the dependencies and updated the remaining
 packages.

 As a side note, I checked bugzilla for problems with yum and finding
 none submitted bug #735235. It takes a while for bug reports to show up
 in the bugzilla search, so a day or so later when I got a confirmation I
 found the earlier bug report.

 I found no way in bugzilla to close my bug report by merging it into the
 earlier bug report. I think such an ability by the original submitter
 would help the people working on fixing bug, (and bug submitters,) by
 prefiltering the individual bug reports to which they needed to look at.

 --
 Barry Fishman

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Oh god, my eyes (packaging a hairball of bundled PHP stuff, tt-rss)

2011-08-31 Thread Jorge Gallegos

On Tue, Aug 30, 2011 at 11:46:36PM -0700, Adam Williamson wrote:
 On Wed, 2011-08-31 at 07:52 +0200, Remi wrote:
  From : 
  https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries
  
  At this time JavaScript intended to be served to a web browser is 
  specifically exempted from this but this will likely change in the future.
  
  This explain why so much .js libraries are bundled in so much wedapps.
 
 Ah, thanks. I missed that. Still, it seems bad to be duplicating some
 very popular js quite so much:
 

Actually, it makes perfect sense. Different frameworks release versions with
different versions of jQuery or prototype. Trying to force all those packages
to play nice with a single system-wide library is hell.

Just imagine the scenario where, say, rails wants to ship version 1.1.5 but
there's a security patch in Django that relies on 1.2.1 and they are not 
backwards
compatible.

There's no hard-set rule of how big a file has to be to be considered for 
packaging
on its own afaik but I'd say these are copylibs with good reason.

 [root@adam lib]# repoquery -f */prototype.js
 rubygem-thin-doc-0:1.2.11-3.fc16.x86_64
 rubygem-railties-0:3.0.9-2.fc16.noarch
 rt3-0:3.8.10-4.fc16.noarch
 rubygem-json_pure-doc-0:1.5.1-1.fc16.noarch
 zabbix-web-0:1.8.6-1.fc16.noarch
 frepple-0:0.8.1-4.fc16.x86_64
 rubygem-scruffy-doc-0:0.2.6-2.fc15.noarch
 zikula-0:1.2.3-2.fc15.noarch
 rubygem-gettext_rails-doc-0:2.1.0-3.fc14.noarch
 rubygem-railties-0:3.0.10-1.fc16.noarch
 horde-0:3.3.11-2.fc15.noarch
 turba-0:2.3.5-2.fc15.noarch
 rubygem-actionpack-1:3.0.10-1.fc16.noarch
 WebCalendar-0:1.2.3-4.fc16.noarch
 pnp4nagios-0:0.4.14-5.fc15.x86_64
 frepple-0:0.8.1-4.fc16.i686
 dogtag-pki-tps-theme-0:9.0.6-1.fc16.noarch
 mantis-0:1.2.4-2.fc15.noarch
 imp-0:4.3.9-2.fc15.noarch
 wordpress-0:3.2.1-2.fc16.noarch
 mediatomb-0:0.12.1-12.fc16.x86_64
 mythweb-0:0.24.1-1.fc15.x86_64
 rubygem-shoulda-doc-0:2.11.3-1.fc15.noarch
 rubygem-calendar_date_select-0:1.15-4.fc13.noarch
 rubygem-locale_rails-doc-0:2.0.5-7.fc15.noarch
 ingo-0:1.2.5-1.fc15.noarch
 rubygem-json-doc-0:1.4.6-3.fc15.x86_64
 smokeping-0:2.4.2-12.fc15.noarch
 kronolith-0:2.3.4-2.fc15.noarch
 asterisk-0:1.8.5.0-1.fc16.2.x86_64
 rubygem-activeldap-doc-0:1.2.2-2.fc15.noarch
 wordpress-0:3.2.1-2.fc16.noarch
 zabbix-web-0:1.8.6-1.fc16.noarch
 python-Scriptaculous-0:1.8.2-6.fc15.noarch
 rubygem-actionpack-1:3.0.9-1.fc16.noarch
 
 erk.
 
 Still, it means for now I only need to worry about the PHP stuff...
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
 http://www.happyassassin.net
 
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel


pgp7NHmiFa0Uy.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bug in fuse-s3fs

2011-08-23 Thread Jorge Gallegos

Hi,

I opened the pasted review request above because fuse-s3fs (hint: need
sponsor :) wouldn't work in my machine.
When I went to the Google code page I saw it had been three years with no
commit while it never left alpha status, that's why I submitted a new
request for s3fs.
On Aug 23, 2011 4:47 AM, Neil Horman nhor...@redhat.com wrote:
 On Tue, Aug 23, 2011 at 11:12:55AM +0300, Muayyad AlSadi wrote:
 is this project still active ?

 Yes, the project is still active.

 if not then fedora should have rpm for the other s3fs project 
 http://code.google.com/p/s3fs

 if so then the following lines in the code should be fixed
 Then please open a bug.


 #Set the env correctly
 if self.AWS_ACCESS_KEY_ID != None:
 os.putenv(AWS_ACCESS_KEY_ID,self.AWS_ACCESS_KEY_ID)
 if self.AWS_SECRET_ACCESS_KEY != None:
 os.putenv(AWS_SECRET_ACCESS_KEY,
 self.AWS_SECRET_ACCESS_KEY)

 if (os.environ.get(AWS_ACCESS_KEY_ID) == None):
 print Need to specify AWS_ACCESS_KEY_ID
 if (os.environ.get(AWS_SECRET_ACCESS_KEY) == None):
 print Need to specify AWS_SECRET_ACCESS_KEY

 as python docs says  http://docs.python.org/library/os.html#os.putenv

 When putenv() is supported, assignments to items in os.environ are
 automatically translated into corresponding calls to putenv();
 however, calls to putenv() don’t update os.environ, so it is actually
 preferable to assign to items of os.environ.

 the code above set's env with putenv then read it with environ
 the docs says just set it with environ and it will call putenv

 so it should be

 if self.AWS_ACCESS_KEY_ID != None:
 os.environ[AWS_ACCESS_KEY_ID]=self.AWS_ACCESS_KEY_ID
 if self.AWS_SECRET_ACCESS_KEY != None:
 os.environ[AWS_SECRET_ACCESS_KEY]=self.AWS_SECRET_ACCESS_KEY
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bug in fuse-s3fs

2011-08-23 Thread Jorge Gallegos

On Tue, Aug 23, 2011 at 12:52:42PM -0400, Neil Horman wrote:
 On Tue, Aug 23, 2011 at 09:33:55AM -0700, Jorge Gallegos wrote:
  Hi,
  
  I opened the pasted review request above because fuse-s3fs (hint: need
  sponsor :) wouldn't work in my machine.
  When I went to the Google code page I saw it had been three years with no
  commit while it never left alpha status, that's why I submitted a new
  request for s3fs.
 what you're doing doesn't make any sense, the fuse-s3fs package thats included
 in RHEL, is the same one that you have a review request open for.  No one is
 going to review a package request when the package is already part of Fedora.
 

Interesting, I am now confused:

[kad@shinon ~]$ uname -r
2.6.40.3-0.fc15.x86_64
[kad@shinon ~]$ yum search s3fs
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile
updates/metalink
 |  17 kB 00:00 
 * fedora: mirror.fdcservers.net
  * updates: mirror.fdcservers.net
  updates   
   | 4.7 kB 00:00 
  updates/primary_db
   | 4.1 MB 00:00 
  updates/pkgtags   
   |  44 kB 00:00 
  == N/S Matched: s3fs 
===
  fuse-s3fs.noarch : FUSE filesystem using Amazon Simple Storage Service as 
storage

Name and summary matches only, use search all for everything.
[kad@shinon ~]$ yum info fuse-s3fs
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile
 * fedora: mirror.fdcservers.net
  * updates: mirror.fdcservers.net
  Available Packages
  Name: fuse-s3fs
  Arch: noarch
  Version : 0.7
  Release : 5.fc15
  Size: 25 k
  Repo: fedora
  Summary : FUSE filesystem using Amazon Simple Storage Service as 
storage
  URL : https://fedorahosted.org/s3fs

If you go to https://fedorahosted.org/s3fs/browser you'll see there has been no 
commits for the last 3 years.

I did a search before submitting my review request:

https://bugzilla.redhat.com/buglist.cgi?quicksearch=s3fs

The only result that comes back is my ticket. I am packaging 
http://code.google.com/p/s3fs, if this is packaged for RHEL then I'd have to 
ask why this is not in fedora and if it was at some point.


 No one ever packaged the google code s3fs, because as you've noted, 
 development
 on it is dead.
 
 If you're having trouble getting fuse-s3fs from Fedora to work, open a bug, 
 and
 I'll help you get it going.
 Neil
 
  On Aug 23, 2011 4:47 AM, Neil Horman nhor...@redhat.com wrote:
   On Tue, Aug 23, 2011 at 11:12:55AM +0300, Muayyad AlSadi wrote:
   is this project still active ?
  
   Yes, the project is still active.
  
   if not then fedora should have rpm for the other s3fs project 
   http://code.google.com/p/s3fs
  
   if so then the following lines in the code should be fixed
   Then please open a bug.
  
  
   #Set the env correctly
   if self.AWS_ACCESS_KEY_ID != None:
   os.putenv(AWS_ACCESS_KEY_ID,self.AWS_ACCESS_KEY_ID)
   if self.AWS_SECRET_ACCESS_KEY != None:
   os.putenv(AWS_SECRET_ACCESS_KEY,
   self.AWS_SECRET_ACCESS_KEY)
  
   if (os.environ.get(AWS_ACCESS_KEY_ID) == None):
   print Need to specify AWS_ACCESS_KEY_ID
   if (os.environ.get(AWS_SECRET_ACCESS_KEY) == None):
   print Need to specify AWS_SECRET_ACCESS_KEY
  
   as python docs says  http://docs.python.org/library/os.html#os.putenv
  
   When putenv() is supported, assignments to items in os.environ are
   automatically translated into corresponding calls to putenv();
   however, calls to putenv() don’t update os.environ, so it is actually
   preferable to assign to items of os.environ.
  
   the code above set's env with putenv then read it with environ
   the docs says just set it with environ and it will call putenv
  
   so it should be
  
   if self.AWS_ACCESS_KEY_ID != None:
   os.environ[AWS_ACCESS_KEY_ID]=self.AWS_ACCESS_KEY_ID
   if self.AWS_SECRET_ACCESS_KEY != None:
   os.environ[AWS_SECRET_ACCESS_KEY]=self.AWS_SECRET_ACCESS_KEY
   --
   devel mailing list
   devel@lists.fedoraproject.org
   https://admin.fedoraproject.org/mailman/listinfo/devel
   --
   devel mailing list
   devel@lists.fedoraproject.org
   https://admin.fedoraproject.org/mailman/listinfo/devel
 
  -- 
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
 
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel


pgphuQuDcPaEy.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman

Re: Strange rpath behavior

2011-08-14 Thread Jorge Gallegos

On Sun, 2011-08-14 at 14:47 +0900, TASAKA Mamoru wrote:
 Jorge Gallegos wrote, at 08/14/2011 09:22 AM +9:00:
  Hi,
 
  I am looking for a sponsor for uwsgi server in this ticket
  https://bugzilla.redhat.com/show_bug.cgi?id=682704 however I am trying
  to fix the rpath issues I commented there because otherwise i think it
  simply won't pass. I am faced with some... weird behavior.
 
  The software does not use the standard configure/makefile approach,
  instead it is built using a python program (uwsiconfig.py) to decide
  what flags it should use, then simply calls them (os.system(bla)) to
  build it.
 
  When I build the package using the python program I get warnings about
  rpath being present (sure enough I inspect the binaries and I can
  see /usr/lib64 in there) but, when I basically pipe the output of the
  program to another shell file (sans comments) and execute that shell
  file, I get no warning whatsoever and /usr/lib64 is nowhere to be found
  in the binaries.
 
  Now, I could cheat and patch uwsgiconfig.py to write the shell script
  instead of calling os.system (actually I have a patch/spec I just tested
  and works just fine) but that sounds like bad form. Can any of you
  veterans tell me why this is happening?
 
  My initial thought would be: python _has_ rpath issues, which the
  binaries inherit because they are compiled under python's scope
 
  Thoughts?
 
 
 Only commenting about rpath issue here (fixing packaging issues is also
 needed).
 
 Try finding LD_RUN_PATH string in uwsgi source. This string is actually
 there and this causes rpath to be embedded in built binaries.
 
 Note that there seems some API change in jansson and your srpm won't build
 in F-16 currently.
 
 Regards,
 Mamoru
 
 
 

Mamoru:

Excellent! thanks for the tip, that is actually what was happening: the
LD_RUN_PATH env var was being set in two of the plugins at build time,
affecting the rest as well. When I was running the build instructions
manually no environment was set, so that was the difference.

Thanks a lot, will update the ticket.

~kad


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Strange rpath behavior

2011-08-13 Thread Jorge Gallegos

Hi,

I am looking for a sponsor for uwsgi server in this ticket
https://bugzilla.redhat.com/show_bug.cgi?id=682704 however I am trying
to fix the rpath issues I commented there because otherwise i think it
simply won't pass. I am faced with some... weird behavior.

The software does not use the standard configure/makefile approach,
instead it is built using a python program (uwsiconfig.py) to decide
what flags it should use, then simply calls them (os.system(bla)) to
build it.

When I build the package using the python program I get warnings about
rpath being present (sure enough I inspect the binaries and I can
see /usr/lib64 in there) but, when I basically pipe the output of the
program to another shell file (sans comments) and execute that shell
file, I get no warning whatsoever and /usr/lib64 is nowhere to be found
in the binaries.

Now, I could cheat and patch uwsgiconfig.py to write the shell script
instead of calling os.system (actually I have a patch/spec I just tested
and works just fine) but that sounds like bad form. Can any of you
veterans tell me why this is happening?

My initial thought would be: python _has_ rpath issues, which the
binaries inherit because they are compiled under python's scope

Thoughts?


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Self introduction

2011-07-24 Thread Jorge Gallegos

Hey all,

Just another self-introduction email. I just created
https://bugzilla.redhat.com/show_bug.cgi?id=725292 and it needs some
love/feedback. I've been a small contributor to fedora for some years
now, in the infrastructure project mostly. My $DAYJOB is mostly done on
debian and there aren't really that many packages I've had to re-package
for fedora myself but in the last weeks I've had two. I am sending this
package for review and at the same time I'd like to direct some
attention to another package request:
https://bugzilla.redhat.com/show_bug.cgi?id=682704 this one got
submitted by another user back in march but I couldn't find if he
actually introduced himself to the list or not. In any case I've put
some feedback on that REQ and would love to help if needed.

Cheers.


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Kubernetes Development SIG

Re: Many packages unnecessarily link to libpython

Re: pagure ssh key

Re: Reminder: GitHub etc. auto-generated archives are not stable in time

Re: Cannot dnf group remove "Cinnamon Desktop"

Re: Cannot dnf group remove "Cinnamon Desktop"

Cannot dnf group remove "Cinnamon Desktop"

Re: Renaming the cloud-utils package

Re: Sub-package dropped upstream

Re: Sub-package dropped upstream

License change for uwsgi

Re: using rpms for non-root installs

Re: PEAR not entirely in EPEL?

Re: Orphaning two Drupal modules

Re: Yum S3 plugin

Re: Yum S3 plugin

Yum S3 plugin

Re: Yum/Bugzilla feature requests

Re: Oh god, my eyes (packaging a hairball of bundled PHP stuff, tt-rss)

Re: bug in fuse-s3fs

Re: bug in fuse-s3fs

Re: Strange rpath behavior

Strange rpath behavior

Self introduction

24 matches

Site Navigation

Mail list logo

Footer information