11:01 a.m.
Hi!
After a bit of discussion on #fedora-devel I was directed here to start
some discussion.
The issue is that you guys have some neat stuff in Fedora which you
essentially are also upstream for. Now, usually when we (Ubuntu in my
case) package software, we go to a homepage or ftp site or whatever to
grab a tarball, add our packaging to that and upload it to our archive.
If I want to do the same with, say, system-config-samba, I've just
learned that I should go to koji, grab the SRPM, donwload it, extract
the "upstream" tar.bz2 from the SRPM and convert it to a tar.gz (yes, I
need a gzipped version, but don't worry about that). It's hard to
discover availability of new versions and equally hard to get my hands
on the corresponding tarball.
The short version is: It would be massively helpful to us (and possibly
others) if you could provide those tarballs in a more (for us) easily
accessible place, e.g. an ftp site or a web site of some sort.
Thanks in advance!
--
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/
2:28 p.m.
On Fri, 2007-08-31 at 18:01 +0200, Soren Hansen wrote:
Hi!
After a bit of discussion on #fedora-devel I was directed here to start
some discussion.
The issue is that you guys have some neat stuff in Fedora which you
essentially are also upstream for. Now, usually when we (Ubuntu in my
case) package software, we go to a homepage or ftp site or whatever to
grab a tarball, add our packaging to that and upload it to our archive.
If I want to do the same with, say, system-config-samba, I've just
learned that I should go to koji, grab the SRPM, donwload it, extract
the "upstream" tar.bz2 from the SRPM and convert it to a tar.gz (yes, I
need a gzipped version, but don't worry about that). It's hard to
discover availability of new versions and equally hard to get my hands
on the corresponding tarball.
The short version is: It would be massively helpful to us (and possibly
others) if you could provide those tarballs in a more (for us) easily
accessible place, e.g. an ftp site or a web site of some sort.
Agreed. In the case of system-config-samba the spec file has this
mention:
# We are upstream, thus the source is only available from within this
#source
# package.
Source0: %{name}-%{version}.tar.bz2
I'm cc'ing the maintainer on this to see if we could convince him to
move system-config-samba out to hosted.fedoraproject.org to solve the
above problem.
Nils,
Would you be willing to move things off of elvis and onto
hosted.fedoraproject.org to help with the use of system-config-samba by
other distros?
Thanks!
-sv
2:35 p.m.
seth vidal wrote:
Agreed. In the case of system-config-samba the spec file has this
mention:
# We are upstream, thus the source is only available from within this
#source
# package.
Source0: %{name}-%{version}.tar.bz2
I'm cc'ing the maintainer on this to see if we could convince him to
move system-config-samba out to hosted.fedoraproject.org to solve the
above problem.
Nils,
Would you be willing to move things off of elvis and onto
hosted.fedoraproject.org to help with the use of system-config-samba by
other distros?
Thanks!
-sv
Maybe the guidelines at
http://fedoraproject.org/wiki/Packaging/SourceURL#head-413e1c297803cfa9de...
can be modified to recommend using hosted instead of adding comments
that the SRPM is the canonical source?
L10N folks are moving from elvis to public cvs too. Maybe we can stop
using it entirely for Fedora.
Rahul
2:48 p.m.
On Sat, 2007-09-01 at 01:05 +0530, Rahul Sundaram wrote:
seth vidal wrote:
> Agreed. In the case of system-config-samba the spec file has this
> mention:
>
> # We are upstream, thus the source is only available from within this
> #source
> # package.
> Source0: %{name}-%{version}.tar.bz2
>
>
> I'm cc'ing the maintainer on this to see if we could convince him to
> move system-config-samba out to hosted.fedoraproject.org to solve the
> above problem.
>
> Nils,
> Would you be willing to move things off of elvis and onto
> hosted.fedoraproject.org to help with the use of system-config-samba by
> other distros?
>
> Thanks!
> -sv
Maybe the guidelines at
http://fedoraproject.org/wiki/Packaging/SourceURL#head-413e1c297803cfa9de...
can be modified to recommend using hosted instead of adding comments
that the SRPM is the canonical source?
L10N folks are moving from elvis to public cvs too. Maybe we can stop
using it entirely for Fedora.
So what Jeremy just mentioned to me is were delaying moving from elvis
until transifex is up.
-sv
3:48 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rahul Sundaram wrote:
Maybe the guidelines at
http://fedoraproject.org/wiki/Packaging/SourceURL#head-413e1c297803cfa9de...
can be modified to recommend using hosted instead of adding comments
that the SRPM is the canonical source?
We can add the recommendation but we can't eliminate the "SRPM is
canonical" language as long as people still want the SRPM to be the
canonical location. To remove the exception, you'll have to talk to the
devs involved to see whether they're against moving into hosted.fp.o.
If everyone wants to we'd be happy to get rid of the exception :-)
- -Toshio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG2H6dX6yAic2E7kgRAjZAAJ9D9Gh0wdFlIi4E8TiCY/GW3pdsAACePTfc
XD0mIPkzw2m0ZL8mRrWtRqo=
=zVth
-----END PGP SIGNATURE-----
3:51 p.m.
On Fri, 2007-08-31 at 13:48 -0700, Toshio Kuratomi wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rahul Sundaram wrote:
>
> Maybe the guidelines at
>
http://fedoraproject.org/wiki/Packaging/SourceURL#head-413e1c297803cfa9de...
> can be modified to recommend using hosted instead of adding comments
> that the SRPM is the canonical source?
>
We can add the recommendation but we can't eliminate the "SRPM is
canonical" language as long as people still want the SRPM to be the
canonical location. To remove the exception, you'll have to talk to the
devs involved to see whether they're against moving into hosted.fp.o.
If everyone wants to we'd be happy to get rid of the exception :-)
I'm betting the number of srpm-is-canonical pkgs is not a huge number.
I'm going to find out, though.
-sv
3:56 p.m.
On 8/31/07, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
We can add the recommendation but we can't eliminate the "SRPM is
canonical" language as long as people still want the SRPM to be the
canonical location. To remove the exception, you'll have to talk to the
devs involved to see whether they're against moving into hosted.fp.o.
If everyone wants to we'd be happy to get rid of the exception :-)
Makes sense to me to say CVS+lookaside is canonical, not SRPMs.
4:07 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Colin Walters wrote:
On 8/31/07, *Toshio Kuratomi* <a.badger(a)gmail.com
<mailto:a.badger@gmail.com>> wrote:
We can add the recommendation but we can't eliminate the "SRPM is
canonical" language as long as people still want the SRPM to be the
canonical location. To remove the exception, you'll have to talk to
the
devs involved to see whether they're against moving into hosted.fp.o.
If everyone wants to we'd be happy to get rid of the exception :-)
Makes sense to me to say CVS+lookaside is canonical, not SRPMs.
lookaside makes more logical sense in that the SRPMS are generated from
it. OTOH, SRPMS are available from http:// whereas you have to know the
Fedora Cvs song and dance to get access to lookaside. In either case,
it's less than ideal so I'd much rather have people decide to switch to
hosted than debate whether lookaside or SRPM more accurately describes
how we're doing things now.
- -Toshio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG2IMIX6yAic2E7kgRAjemAJ0Q9IeARJs0YOLlUw88lDOInI5wzQCfYcKh
iXfaZhPaJVfgh1qUnwPqVh8=
=+117
-----END PGP SIGNATURE-----
4:05 p.m.
Toshio Kuratomi wrote:
We can add the recommendation but we can't eliminate the
"SRPM is
canonical" language as long as people still want the SRPM to be the
canonical location. To remove the exception, you'll have to talk to the
devs involved to see whether they're against moving into hosted.fp.o.
If everyone wants to we'd be happy to get rid of the exception :-)
The next thing would be is to list out the packages which has the
packages as the canonical source, contact the developers and ask them if
they are willing to move to hosted. We might get valuable input on where
hosted is lacking for them and we can finally announce hosted as not
being in beta anymore if that is still the status.
IMO, we should avoid having SRPM as canonical source if not entirely get
rid of that practice.
Rahul
4:21 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rahul Sundaram wrote:
Toshio Kuratomi wrote:
> We can add the recommendation but we can't eliminate the "SRPM is
> canonical" language as long as people still want the SRPM to be the
> canonical location. To remove the exception, you'll have to talk to the
> devs involved to see whether they're against moving into hosted.fp.o.
>
> If everyone wants to we'd be happy to get rid of the exception :-)
The next thing would be is to list out the packages which has the
packages as the canonical source, contact the developers and ask them if
they are willing to move to hosted.
Seth is working on this. I haven't looked at it because not all
packages are reviewed yet.... and therefore not all packages are going
to have proper Source: lines or comments conforming to the Guidelines.
We might get valuable input on where
hosted is lacking for them and we can finally announce hosted as not
being in beta anymore if that is still the status.
That's true. Although there are a few things that hosted definitely
lacks before we're ready to take it out of beta. Off the top of my head:
* free form web space. That allows hosting yum repos for the projects,
download sites, non-trac-wiki space, etc.
* Move the repositories to a separate server from the one that hosts our
package SCM. (Waiting on hardware for this)
- -Toshio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG2IZvX6yAic2E7kgRAu7pAJ0c+hTwgaC+3QSjJGXFkrYUlGJL7gCgkFxK
bVETZWIIQMZO2zVnT5Xht1c=
=h9+V
-----END PGP SIGNATURE-----
4:56 p.m.
On Fri, 2007-08-31 at 14:21 -0700, Toshio Kuratomi wrote:
That's true. Although there are a few things that hosted
definitely
lacks before we're ready to take it out of beta. Off the top of my head:
* free form web space. That allows hosting yum repos for the projects,
download sites, non-trac-wiki space, etc.
Unless I'm mistaken currently the only way to put a tarball for a
project on hosted.fp.o at the moment is to add the tarball as an
attachment to Trac.
That's a less than wonderful way to manage the tarballs especially when
the SCM repository for the project is already on hosted.fp.o. It should
be easy to create the tarball from the SCM and then export it on
hosted.fp.o without a lot of gymnastics.
--
John Dennis <jdennis(a)redhat.com>
7:33 a.m.
On Fri, 2007-08-31 at 17:56 -0400, John Dennis wrote:
On Fri, 2007-08-31 at 14:21 -0700, Toshio Kuratomi wrote:
> That's true. Although there are a few things that hosted definitely
> lacks before we're ready to take it out of beta. Off the top of my head:
>
> * free form web space. That allows hosting yum repos for the projects,
> download sites, non-trac-wiki space, etc.
Unless I'm mistaken currently the only way to put a tarball for a
project on hosted.fp.o at the moment is to add the tarball as an
attachment to Trac.
That's a less than wonderful way to manage the tarballs especially when
the SCM repository for the project is already on hosted.fp.o. It should
be easy to create the tarball from the SCM and then export it on
hosted.fp.o without a lot of gymnastics.
I think we can find a way to simplify this problem.
Thanks,
-sv
10:22 a.m.
John Dennis wrote:
On Fri, 2007-08-31 at 14:21 -0700, Toshio Kuratomi wrote:
> That's true. Although there are a few things that hosted definitely
> lacks before we're ready to take it out of beta. Off the top of my head:
>
> * free form web space. That allows hosting yum repos for the projects,
> download sites, non-trac-wiki space, etc.
>
Unless I'm mistaken currently the only way to put a tarball for a
project on hosted.fp.o at the moment is to add the tarball as an
attachment to Trac.
This actually seems reasonable to me (uploading a tarball as an
attachment that can be linked to later) I've been doing this with
smolt. There's two issues currently though. 1) For some reason the
system doesn't work in FireFox and 2) The link to the actual download
page includes variables like &action=raw or something like that and RPM
hates it.
-Mike
9:33 a.m.
On Fri, 31 Aug 2007 14:21:51 -0700
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
* free form web space. That allows hosting yum repos for the
projects, download sites, non-trac-wiki space, etc.
* Move the repositories to a separate server from the one that hosts
our package SCM. (Waiting on hardware for this)
Agreed. These are the major two issues that have kept us from lifting
Hosted from a Beta program to a Production environment and advertising
it and actively seeking developers to host their projects with us.
fedorapeople.org is proving a great test run for providing webspace to
contributors, and we can learn from it when creating such a thing for
hosted.fp.o.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
6:19 p.m.
On Sun, 2007-09-02 at 10:33 -0400, Jesse Keating wrote:
On Fri, 31 Aug 2007 14:21:51 -0700
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
> * free form web space. That allows hosting yum repos for the
> projects, download sites, non-trac-wiki space, etc.
>
> * Move the repositories to a separate server from the one that hosts
> our package SCM. (Waiting on hardware for this)
Agreed. These are the major two issues that have kept us from lifting
Hosted from a Beta program to a Production environment and advertising
it and actively seeking developers to host their projects with us.
fedorapeople.org is proving a great test run for providing webspace to
contributors, and we can learn from it when creating such a thing for
hosted.fp.o.
Yes, at this point we could make a releases.fp.o with similar
restrictions as fedorapeople.o, but we need:
1. a host/instance to run it on
2. the disk space behind it - probably not that much 20-30gb
I don't think there is that resource available atm in a place where we
can allow ssh logins. I'll ask.
-sv
7:38 a.m.
On Fri, 2007-08-31 at 14:21 -0700, Toshio Kuratomi wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rahul Sundaram wrote:
> Toshio Kuratomi wrote:
>
>> We can add the recommendation but we can't eliminate the "SRPM is
>> canonical" language as long as people still want the SRPM to be the
>> canonical location. To remove the exception, you'll have to talk to the
>> devs involved to see whether they're against moving into hosted.fp.o.
>>
>> If everyone wants to we'd be happy to get rid of the exception :-)
>
> The next thing would be is to list out the packages which has the
> packages as the canonical source, contact the developers and ask them if
> they are willing to move to hosted.
Seth is working on this. I haven't looked at it because not all
packages are reviewed yet.... and therefore not all packages are going
to have proper Source: lines or comments conforming to the Guidelines.
Here's the results - I just did searches against devel and F-7 pkgs.
http://skvidal.fedorapeople.org/misc/source-without-url.txt
the script I used is here:
http://skvidal.fedorapeople.org/misc/look-for-no-url-source.sh
It should help us track down the ones we can control and help it.
some that are listed that spring to mind:
system-config-bind
system-config-boot
system-config-cluster
system-config-date
system-config-display
system-config-firewall
system-config-keyboard
system-config-kickstart
system-config-language
system-config-lvm
system-config-netboot
system-config-network
system-config-nfs
system-config-printer
system-config-rootpassword
system-config-samba
system-config-securitylevel
system-config-services
system-config-soundcard
system-config-users
system-switch-java
system-switch-mail
-sv
4:19 a.m.
On Fri, 2007-08-31 at 15:28 -0400, seth vidal wrote:
Nils,
Would you be willing to move things off of elvis and onto
hosted.fedoraproject.org to help with the use of system-config-samba by
other distros?
Sorry for the late reply, been busy and all that.
In fact, I've been prodding Soren to ask the question here -- he
approached me about it on IRC and I thought that this is an issue of
general interest, not only for system-config-samba.
Some points/ideas:
- I've already moved my system-config packages from elvis CVS to hosted
Mercurial.
- I think it's a good idea to offer the tarballs for download there as
well.
- I'm not sure whether having one project per system-config tool would
be wise, perhaps we can keep them under on larger "system configuration
tools" umbrella (as is done today in the Wiki).
- Uploading the tarballs must be possible to be done automatically/from
the command line. Having to do this manually (via a web browser) won't
fly, because sometimes my memory is more like a "forgettory".
- I'm willing to sacrifice my workflow a bit, but if at all possible I'd
like to keep it this way:
1. Change things, try them out in locally checked out source
code
2. "hg commit"
2.1 bump version
3. "make [...] archive" (which tags and pushes to hosted)
4. copy over stuff to Fedora dist CVS
5. "make new-source", "cvs commit", "make [force-]tag
build"
6. If the build doesn't succeed, repeat from step 1 on, skipping
step 2.1 (avoid version creep), force-tagging etc.
This works because the tarball hasn't been published yet -- being stored
behind an anonymous hash in the lookaside cache doesn't count ;-).
My idea would be:
7. Use a small script that (for a certain package) would do
this:
- checks what versions are on the "upstream" download
site
- checks what version are available for Rawhide in koji
- for all versions not yet available, pulls the SRPMS
from koji, extracts the tarballs and uploads them to the
"upstream" download site
Ideally this script would kick off automatically after a successful
build in Rawhide, but I don't know if this would be easily doable. It
could be hooked after "make build" or could be a separate "make
publish"
target in which case step 5 would become:
5. "make new-source", "cvs commit", "make [force-]tag
build
publish"
This would work if it is guaranteed that "make build" only succeeds if
the build is really successful. I think we can assume that.
I'd volunteer writing such a script.
Comments?
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
6085
days inactive
6091
days old
17 comments
10 participants
participants (10)
-
Colin Walters -
Florian La Roche -
Jesse Keating -
John Dennis -
Mike McGrath -
Nils Philippsen -
Rahul Sundaram -
Seth Vidal -
Soren Hansen -
Toshio Kuratomi