librsvg SPEC patch
Building the DEVEL branch of librsvg seems to require rpm-pythonprov.
Index: librsvg.spec
===
RCS file: /cvsroot/SPECS/librsvg.spec,v
retrieving revision 1.99.2.7
diff -u -r1.99.2.7 librsvg.spec
--- librsvg.spec28 Feb 2006 15:04:12 - 1.99.2.7
+++ librsvg.spec9 Mar 2006 16:53:20 -
@@ -25,6 +25,7 @@
Source0:
http://ftp.gnome.org/pub/gnome/sources/librsvg/2.14/%{name}-%{version}.tar.bz2
# Source0-md5: 35f1a4f80cda377efecf5525ae6742b9
URL: http://librsvg.sourceforge.net/
+BuildRequires: rpm-pythonprov
BuildRequires: autoconf
BuildRequires: automake
BuildRequires: cairo-devel >= 1.0.2
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
new spec (lyricue)
Hello all,
My thanks to everyone who has contributed to make PLD the great
distro that it is. I have been a user since a little before RA
was finalized and haven't missed a beat since. At last count
I have 5 TH and 14 AC systems and am the systems guru for 27 more
AC systems at a local ISP.
Up until now my contributions have been made by proxy through
aredridel, but I have been lurking here on the devel list for some
time and decided there was no reason I couldn't offer to be
involved more directly. I am experienced as a systems administrator
and familiar with PLD, but am fairly green as a developer. If
someone is willing to help me over the humps I would be glad to
become a contributor and help with specs and docs.
Attached is a new spec of an app I use that I would like to see
added at some point. It installs and runs correctly on TH, although
I have yet to check it on AC, and I am stumped as to why the
.desktop entry isn't working.
Caleb
# $Revision:$, $Date:$
Summary:The GNU Lyric Display System
Name: lyricue
Version:1.9.6
Release:0.4
License:GPL
Group: X11/Applications/Graphics
Source0:http://www.adebenham.com/debian/%{name}_%{version}.tar.gz
URL:http://www.adebenham.com/lyricue/
Requires: mysql-client
Requires: perl-DBI
Requires: perl-URI
Requires: perl-Gnome2-Canvas
Requires: perl-DBD-mysql
Requires: perl-Gtk2-GladeXML
Requires: perl-Gtk2-Spell
Suggests: perl-Gtk2-TrayIcon
Suggests: perl-Locale-gettext
BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
Patch0: %{name}-makefile.patch
Patch1: %{name}-desktop.patch
%description
This application is used to edit/display song lyrics and passages of
text on a second screen/projector for use at live events such as
church services, concerts and seminars.
%prep
%setup -q
%patch0
%patch1
mv docs doc
%build
%{__make}
%install
rm -rf $RPM_BUILD_ROOT
%{make} install DESTDIR=$RPM_BUILD_ROOT
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(644,root,root,755)
%doc %{_docdir}/lyricue/*
%dir %{_docdir}/lyricue
%dir %{_sysconfdir}/lyricue
%dir %{_datadir}/lyricue
%config(noreplace) %{_sysconfdir}/lyricue/*
%lang(en_US) %dir %{_datadir}/locale/en_US
%lang(en_US) %dir %{_datadir}/locale/en_US/LC_MESSAGES
%lang(en_US) %{_datadir}/locale/en_US/LC_MESSAGES/lyricue.mo
%lang(es_ES) %dir %{_datadir}/locale/es_ES
%lang(es_ES) %dir %{_datadir}/locale/es_ES/LC_MESSAGES
%lang(es_ES) %{_datadir}/locale/es_ES/LC_MESSAGES/lyricue.mo
%lang(de) %dir %{_datadir}/locale/de
%lang(de) %dir %{_datadir}/locale/de/LC_MESSAGES
%lang(de) %{_datadir}/locale/de/LC_MESSAGES/lyricue.mo
%lang(fr) %dir %{_datadir}/locale/fr
%lang(fr) %dir %{_datadir}/locale/fr/LC_MESSAGES
%lang(fr) %{_datadir}/locale/fr/LC_MESSAGES/lyricue.mo
%lang(nl) %dir %{_datadir}/locale/nl
%lang(nl) %dir %{_datadir}/locale/nl/LC_MESSAGES
%lang(nl) %{_datadir}/locale/nl/LC_MESSAGES/lyricue.mo
%lang(sv) %dir %{_datadir}/locale/sv
%lang(sv) %dir %{_datadir}/locale/sv/LC_MESSAGES
%lang(sv) %{_datadir}/locale/sv/LC_MESSAGES/lyricue.mo
%attr(755,root,root) %{_bindir}/lyricue
%attr(755,root,root) %{_bindir}/lyricue_server
%attr(755,root,root) %{_bindir}/lyricue_remote
%attr(755,root,root) %{_bindir}/import_media
%{_datadir}/lyricue/*
%{_desktopdir}/*
%define date%(echo `LC_ALL="C" date +"%a %b %d %Y"`)
%changelog
* %{date} PLD Team <[EMAIL PROTECTED]>
All persons listed below can be reached at @pld-linux.org
$Log:$
--- Makefile2007-08-06 20:14:47.0 -0600
+++ Makefile2007-11-09 14:00:17.099116935 -0700
@@ -2,8 +2,8 @@
SHARE = lyricue.glade images/lyricue.png images/lyricue-icon.png
SQL = mysql/MySQL_create_Table.sql mysql/MySQL_create_media.sql
mysql/Update_1.2.sql mysql/Update_1.9.sql mysql/Update_1.9.4.sql
DESKTOP = lyricue.desktop lyricue_server.desktop
-ETC = default.conf
-DOCS = docs/Development.txt docs/example_song.txt docs/AUTHORS docs/NEWS
docs/README docs/song_template.txt docs/TODO
+ETC = default.conf access.conf
+DOCS = doc/Development.txt doc/example_song.txt doc/AUTHORS doc/NEWS
doc/README doc/song_template.txt doc/TODO
INSTALL = /usr/bin/install -c -m 755
INSTALLDATA = /usr/bin/install -c -m 644 -D
POFILES = po/de.po po/en_US.po po/fr.po po/nl.po po/sv.po po/es_ES.po
@@ -33,8 +33,8 @@
mkdir -p $(DESTDIR)/usr/share/applications
$(INSTALLDATA) $(DESKTOP) $(DESTDIR)/usr/share/applications
- mkdir -p $(DESTDIR)/usr/share/docs/lyricue
- $(INSTALLDATA) $(DOCS) $(DESTDIR)/usr/share/docs/lyricue
+ mkdir -p $(DESTDIR)/usr/share/doc/lyricue
+ $(INSTALLDATA) $(DOCS) $(DESTDIR)/usr/share/doc/lyricue
@for t in $(MOFILES); do l=`basename $$t .po.mo`; $(INSTALLDATA) $$t
$(DESTDIR)/usr/share/locale/$$l/LC_MESSAGES/lyricue.mo;done
--- lyricue.desktop 2007-08-06 20:14:47.0 -0600
+++ lyricue.desktop 2007-11-09 13:43:38.068525315 -0700
@@ -8,6 +8,5 @@
X-GNOME-DocPath=
Terminal=false
Re: new spec (lyricue)
On Fri, Nov 09, 2007 at 06:11:19PM -0700, Aria Stewart wrote: > On Nov 9, 2007, at 5:49 PM, Andrzej Krzysztofowicz wrote: > > We try to keep the BuildRoot entry as the last in this section. > > Patch# just > > after Sources. > > Indeed. The ./adapter script in the SPECS repo does a lot of this. The adapter script did not catch that ordering, but I have fixed it in my spec. I'm trying to sort out the lang stuff Andrzej mentioned and I will resubmit. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: new spec (lyricue)
Thanks for the pointers Andrzej. I am attaching an updated
spec file with your changes.
Caleb
# $Revision:$, $Date:$
Summary:The GNU Lyric Display System
Name: lyricue
Version:1.9.6
Release:0.6
License:GPL
Group: X11/Applications/Graphics
URL:http://www.adebenham.com/lyricue/
Source0:http://www.adebenham.com/debian/%{name}_%{version}.tar.gz
Patch0: %{name}-makefile.patch
Patch1: %{name}-desktop.patch
Requires: mysql-client
Requires: perl-DBD-mysql
Requires: perl-DBI
Requires: perl-Gnome2-Canvas
Requires: perl-Gtk2-GladeXML
Requires: perl-Gtk2-Spell
Requires: perl-URI
Suggests: perl-Gtk2-TrayIcon
Suggests: perl-Locale-gettext
Suggests: sword-devel
BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
%description
This application is used to edit/display song lyrics and passages of
text on a second screen/projector for use at live events such as
church services, concerts and seminars.
%prep
%setup -q
%patch0
%patch1
mv docs doc
%build
%{__make}
%install
rm -rf $RPM_BUILD_ROOT
%{make} install DESTDIR=$RPM_BUILD_ROOT
mv $RPM_BUILD_ROOT%{_datadir}/locale/es{_ES,}
%{find_lang} %{name}
%clean
rm -rf $RPM_BUILD_ROOT
%files -f %{name}.lang
%defattr(644,root,root,755)
%dir %{_docdir}/lyricue
%doc %{_docdir}/lyricue/*
%dir %{_sysconfdir}/lyricue
%dir %{_datadir}/lyricue
%{_datadir}/lyricue/*
%config(noreplace) %{_sysconfdir}/lyricue/*
%attr(755,root,root) %{_bindir}/*
%{_desktopdir}/*
%define date%(echo `LC_ALL="C" date +"%a %b %d %Y"`)
%changelog
* %{date} PLD Team <[EMAIL PROTECTED]>
All persons listed below can be reached at @pld-linux.org
$Log:$
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: new spec (lyricue)
On Sat, Nov 10, 2007 at 04:14:38AM +0200, Elan Ruusamäe wrote:
> > %{_desktopdir}/*
>
> this is dangerous -- you might package %{_desktopdir}/kde if you don't look
> each time what you package.
Ok, I have specified these individually. I tried globing them with {,_server}
but that kind of globing apparently doesn't work there.
> this is usually wrapped:
> %{make} install \
> DESTDIR=$RPM_BUILD_ROOT
done.
> %file list order of items seems usually to
> be %{_sysconfig}, %{_bindir}, %{_datadir}, then rest
done.
Caleb
# $Revision:$, $Date:$
Summary:The GNU Lyric Display System
Name: lyricue
Version:1.9.6
Release:0.7
License:GPL
Group: X11/Applications/Graphics
URL:http://www.adebenham.com/lyricue/
Source0:http://www.adebenham.com/debian/%{name}_%{version}.tar.gz
Patch0: %{name}-makefile.patch
Patch1: %{name}-desktop.patch
Requires: mysql-client
Requires: perl-DBD-mysql
Requires: perl-DBI
Requires: perl-Gnome2-Canvas
Requires: perl-Gtk2-GladeXML
Requires: perl-Gtk2-Spell
Requires: perl-URI
Suggests: perl-Gtk2-TrayIcon
Suggests: perl-Locale-gettext
Suggests: sword-devel
BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
%description
This application is used to edit/display song lyrics and passages of
text on a second screen/projector for use at live events such as
church services, concerts and seminars.
%prep
%setup -q
%patch0
%patch1
mv docs doc
%build
%{__make}
%install
rm -rf $RPM_BUILD_ROOT
%{make} install \
DESTDIR=$RPM_BUILD_ROOT
mv $RPM_BUILD_ROOT%{_datadir}/locale/es{_ES,}
%{find_lang} %{name}
%clean
rm -rf $RPM_BUILD_ROOT
%files -f %{name}.lang
%defattr(644,root,root,755)
%dir %{_sysconfdir}/lyricue
%config(noreplace) %{_sysconfdir}/lyricue/*
%attr(755,root,root) %{_bindir}/*
%dir %{_datadir}/lyricue
%{_datadir}/lyricue/*
%dir %{_docdir}/lyricue
%doc %{_docdir}/lyricue/*
%{_desktopdir}/lyricue.desktop
%{_desktopdir}/lyricue_server.desktop
%define date%(echo `LC_ALL="C" date +"%a %b %d %Y"`)
%changelog
* %{date} PLD Team <[EMAIL PROTECTED]>
All persons listed below can be reached at @pld-linux.org
$Log:$
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: new spec (lyricue)
On Sat, Nov 10, 2007 at 04:16:36AM +0200, Elan Ruusamäe wrote:
> but rather using rpmbuildroot paths use relative %doc from builddir, then
> documents get compressed too:
>
> %doc docs/*
Ok, this didn't quite make sense to me but I think I figured out
what you were after. See if this fits the bill. It throws a warning
about unpackaged (doc) files on build, but they do end up getting
included and installed correctly so I guess it makes sense.
Thanks for the help.
Caleb
# $Revision:$, $Date:$
Summary:The GNU Lyric Display System
Name: lyricue
Version:1.9.6
Release:0.8
License:GPL
Group: X11/Applications/Graphics
URL:http://www.adebenham.com/lyricue/
Source0:http://www.adebenham.com/debian/%{name}_%{version}.tar.gz
Patch0: %{name}-makefile.patch
Patch1: %{name}-desktop.patch
Requires: mysql-client
Requires: perl-DBD-mysql
Requires: perl-DBI
Requires: perl-Gnome2-Canvas
Requires: perl-Gtk2-GladeXML
Requires: perl-Gtk2-Spell
Requires: perl-URI
Suggests: perl-Gtk2-TrayIcon
Suggests: perl-Locale-gettext
Suggests: sword-devel
BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
%description
This application is used to edit/display song lyrics and passages of
text on a second screen/projector for use at live events such as
church services, concerts and seminars.
%prep
%setup -q
%patch0
%patch1
%build
%{__make}
%install
rm -rf $RPM_BUILD_ROOT
%{make} install \
DESTDIR=$RPM_BUILD_ROOT
mv $RPM_BUILD_ROOT%{_datadir}/locale/es{_ES,}
%{find_lang} %{name}
%clean
rm -rf $RPM_BUILD_ROOT
%files -f %{name}.lang
%defattr(644,root,root,755)
%dir %{_sysconfdir}/lyricue
%config(noreplace) %{_sysconfdir}/lyricue/*
%attr(755,root,root) %{_bindir}/*
%dir %{_datadir}/lyricue
%{_datadir}/lyricue/*
%doc docs/*
%{_desktopdir}/lyricue.desktop
%{_desktopdir}/lyricue_server.desktop
%define date%(echo `LC_ALL="C" date +"%a %b %d %Y"`)
%changelog
* %{date} PLD Team <[EMAIL PROTECTED]>
All persons listed below can be reached at @pld-linux.org
$Log:$
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: new spec (lyricue)
On Fri, Nov 09, 2007 at 07:40:18PM -0700, Caleb Maclennan wrote:
> It throws a warning
> about unpackaged (doc) files on build
Would it be appropriate to throw something like the following at
the end of %install to suppress the error?
rm -rf $RPM_BUILD_ROOT%{_datadir}/docs/%{name}
Caleb
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Amazon EC2 AMI for pld-linux
I have been working on setting up some servers using Amazons Elastic Cloud Computing offering. If anyone is interested, I have created a base image that can be used as a starting point for anyone else wishing to run PLD as an Amazon Machine Image. The process of getting a new image up and running is a little bit painful and this might save you some hastle. I have posted a plubic AMI that runs TH. http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1652&categoryID=101 Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Commit access
Can somebody tell me who to get in touch with regarding commit access to PLD spec files? I requested access back in Nov of 2007 after submitting some patches and specs. I was +1'd by Aria and Krystian as well as feedback from Andrzej and Elan. I was then contacted and asked to turn in my desired cvs login info which I did a couple times but never heard anything after that. I have continued to maintain and update my own spec files and frequently update things that end up getting done by somebody else later anyway. Sometimes it's frustrating to be doing this duplicate work. With the re-arrangement of specs recently I need to update a bunch of my stuff. I was wondering if CVS write access was ever going to be in the cards or if I should just organize my own stuff? Thanks, Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: new spec (lyricue)
Should I give a holler here or directly to somebody when I have a commit or will things been seen and reviewed? Question about log messages. I noticed after I committed a bump to the version of hugin last night that most log messages for spec file commits start with a leading dash. Does this have a special meaning or is it just convention that I should follow or did I fail in some other way? I'm working on that lyricue spec i started with three years ago, but it needs some upgrading now seeing that it's a few versions old! Caleb 2010/3/29 Elan Ruusamäe : > are you all aware who gave +1, that you should be mentoring his commits? :) > > On Saturday 10 November 2007 01:53:33 Aria Stewart wrote: >> +1 for me for commit access. > > On Saturday 10 November 2007 02:06:07 Krystian Tomczyk wrote: >> +1 > > On Tuesday 13 November 2007 01:56:42 Arkadiusz Patyk wrote: >> +1 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: new spec (lyricue)
Thanks for the links to relevant current developer documentation. I'll keep an eye on those guidelines. I have to say that even having been an avid PLD user for 10+ years the lack of clear easy to find documentation (and the amount of outdated, irrelevant and contradictory documentation floating around in dozens of locations) is making me dizzy. I have subscribed to the cvs commit list and will try to keep up with what's current that way. Caleb 2010/3/29 Elan Ruusamäe : > On Monday 29 March 2010 14:48:05 Caleb Maclennan wrote: >> Question about log messages. I noticed after I committed a bump to the >> version of hugin last night that most log messages for spec file >> commits start with a leading dash. Does this have a special meaning or >> is it just convention that I should follow or did I fail in some other >> way? > > it is explained in here: > http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/PLD-doc/HACKING > > also you mind find this useful: > http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/PLD-doc/BuildRequires.txt > > and these two (depending on your language preference) > http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/PLD-doc/devel-hints-en.txt > http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/PLD-doc/devel-hints-pl.txt > > however, these may not be exactly up to date, most of the knowledge comes imho > via monitoring of spec commits. > > and when creating new .specs, there are somewhat useful templates: > http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/template-specs/ > > -- > glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Builder fault
I have the same problem with the builder script on my local machine after upgrading rpm-build-tools. cvs up builder did not fix it although there was a newer version. Caleb 2010/4/9 Jan WIdeł : > On Thu, 8 Apr 2010 20:51:38 +0200, Zsolt Udvari > wrote: >> Hi all! >> >> I've a problem on carme-server: >> >> [uzs...@carme-pld-i686 ~]$ builder irssi >> builder: SMP make flags are set to -j16 >> Warning: No CVS access defined - using local .spec file >> cvs update: CVSROOT is set but empty! Make sure that the >> cvs update: specification of CVSROOT is legal, either via the >> cvs update: `-d' option, the CVSROOT environment variable, or the >> cvs [update aborted]: CVS/Root file (if any). >> Error: spec file not stored in CVS repo. > > cvs up builder? > > -- > Poz, > JW > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: icedtea6/TODO (NEW), icedtea6/icedtea6.spec (NEW) - new package, ...
2010/4/14 Elan Ruusamäe : > even now the version: tag matches Yes, the version tag matches, but the base package is different and they are in fact different versions! I looked at the upstream project files the other day and they apparently have different branches of the project that share parallel version numbers. Only the base package name is different. Crazy? Yes, but real enough. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Adapter problem, difference between make and %{__make}
In an attempt to get emerillon packaged for PLD I've been working on
specs for the two missing deps, librest and libethos. Librest went ok
but I'm having fits with libethos.
Most PLD packages use the macro %{__make} for the build, but for some
reason that breaks the build whereas just make runs and builds fine.
Can somebody tell me what is different and therefore how to fix the
build process so it can get a clean bill of health from adapter and
still build!
http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/libethos/libethos.spec?rev=1.1
Also, while it builds fine on two out of three of my TH systems, the
third bombs during configure with this cryptic error:
...
Running intltoolize...
Running gtkdocize...
Running gnome-doc-common...
Running aclocal-1.11...
configure.ac:34: warning: AM_NLS is m4_require'd but not m4_defun'd
m4/intltool.m4:27: IT_PROG_INTLTOOL is expanded from...
configure.ac:34: the top level
Running autoconf...
configure.ac:34: warning: AM_NLS is m4_require'd but not m4_defun'd
m4/intltool.m4:27: IT_PROG_INTLTOOL is expanded from...
configure.ac:34: the top level
configure:5568: error: possibly undefined macro: AM_NLS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
error: Bad exit status from /home/users/caleb/tmp/rpm-tmp.88172 (%build)
Thanks for any input.
Caleb
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Adapter problem, difference between make and %{__make}
2010/4/24 Patryk Zawadzki :
> If %{__make} fails, your first target is -j1 :)
Good to know, thanks. Is the proper way to do this just to run
%{__make} -j1? I noticed this gets executed as make -j6 -j1 which
seems kinda clumsy.
In this case that did not fix my problem, but with some help from
deejay1 it looks like my problem was before the make routine, the
configure steps needed to be pld-ified as well.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: flvtool2/flvtool2.spec, flvtool2/flvtool2-ruby19.patch (NEW) - up...
2010/5/1 caleb :
> - patched setup script to run on ruby-1.9
> +Patch0: %{name}-ruby19.patch
> +%patch0 -p1
Some [widely bemoaned] changes to the way ruby handles string encoding
from 1.8 to 1.9 require changes in some scripts to run reliably. I
took a cue from several other patched pld packages and patched the
setup script for flvtools2 sot that it runs on ruby-1.9. The only
other way to make it run was to force the LANG to a non-utf8
selection, which didn't seem like the right option.
However this breaks the package build on ruby 1.8 systems. Is there an
acceptable way to mark a patch in the spec for inclusion only if the
host system is running a certain version of a package?
Caleb
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Old kernel without udev
Does anybody have any input on keeping a TH system up to date while being forced to run an old kernel (2.6.16) not compatible with current udev packages? Is it possible these days to not have udev packages installed at all? Or should I work on setting up a custom udev package with an an older version: something from the same generation as the kernel? Thanks and regards, Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Native upstart scripts
2010/5/4 Jacek Konieczny : > I think Upstart support should be implemented as an option, coexisting > with current solution, so the administrator may choose what he prefers > and even use init.d for some services and upstart for other. +1 > - chkconfig would link/unlink the files when requested (global > configuration option and command line option to prefer upstart) Your implementation sounds reasonable. I have several systems I will be interested in trying this out on. > P.S. Does anybody read those 'long' posts I send to pld-devel-en? ;) Yes. Particularly as a new developer seeing verbose discussion of various decisions is quite helpful. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: devel-hints-pl.txt thread
2010/6/2 Elan Ruusamäe : > it's not 1st of april to do those jokes, is it? > hint: the source: > http://translate.google.com/#pl|et|Pawel%20Golaszewski Epic fail. For icing on the cake note that this translation is used in ANY target language. Apparently Elan Ruusamäe is the new Pawel Golaszewski world-wide? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: HELP: New PLD Rescue CD
2010/6/5 Arkadiusz Miskiewicz : > New PLD RescueCD is hopefuly to be produced at the end of this month but areq > needs help with fixing packages. Great timing. I was just now beating my head against a problem using the old rescue cd wondering if it would ever be updated. I would be happy to help iron out some of the issues, but it looks like many of the issues are specific to the build environment for the rescue cd and are not manifest building against TH. Can somebody point me toward docs on how to setup a build env that matches so I can test? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: perl-Clutter-GStreamer/perl-Clutter-GStreamer.spec - release 5
2010/6/6 arekm > > Author: arekm Date: Sun Jun 6 15:36:42 2010 GMT > Module: packages Tag: HEAD > Log message: > - release 5 > > Files affected: > packages/perl-Clutter-GStreamer: > perl-Clutter-GStreamer.spec (1.3 -> 1.4) Why did the rel get bumped on this package? Is the %define rel that I used to indicate the upstream release number we are downloading the wrong way to do this? Our package release is 1, but the upstream package we need to download is release 4. If it get's bumped this needs to be done with our release number, not the upstream number! Should that variable be called something else? I saw this done in other packages and so assumed it was the right scheme. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD-doc: devel-hints-en.txt - notes on Release tag and %rel macro
2010/6/7 pawelz :
> + Fractional release (0.1, 0.5, 3.14 etc) means package is not yet ready to
> + be sent to builders. If you think that package is ready to be build,
> + increase release to the next integer.
How does this information apply to packages such as open-iscsi which
has a release of 0.%{subver}.%{rel} where subver is from the upstream
project and rel is the pld release incrementor. The reason I ask is
this 0.x.y number looks like a fraction release to me, but it is built
and in the TH tree. How should I have incremented this to indicate
that it isn't ready to be built again yet? Should the rel also be a
fraction? Why the 0. before the subver?
Caleb
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Arch / Locale packaging issue.
I'm having some trouble packaging trac-0.12. The current spec compiles, but the languages files are not generated properly. If I remove BuildArch: noarch, everything builds and runs fine but it doesn't seem that trac should be architecture specific just because of some locale files. What is the correct way to get them to build and package properly? I played with the %find_lang macro a little bit but I couldn't figure out how to make it handle python site-packages properly. Thanks, Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Arch / Locale packaging issue.
2010/6/15 Elan Ruusamäe : > i don't see any lang files with disabled bulldarch: noarch either. Try building on i686. I don't get them on x86_64. Also it's possible that python-Babel >= 0.9.5 is a BR. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Arch / Locale packaging issue.
2010/6/15 Elan Ruusamäe : > yet it was missing python-genshi dep Thanks for sorting that and the rest of the lang file mess out. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: GoogleEarth/GoogleEarth.spec - %lang
2010/8/16 glen : > %define buildid 3533.1731 Where can the correct source package version be downloaded from or how should this be built? Building with the package from the URL listed in the spec leads to: + [ 5.2.1.1547-1 != 5.1.3533.1731-1 ] + exit 1 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: openswan.spec up to 2.6.28
2010/8/18 Marcin Rybak : > Updated to 2.6.28 (changelog: http://www.openswan.org/download/CHANGES ), I committed for you at rev 1.50, and thanks for contributing. You might look at the following messages and consider if either of these should get packaged, particularly the index.html file under docs? Or is this a duplication of docs in another format? Just something to consider in the future. - Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/users/caleb/tmp/openswan-2.6.28-root-caleb warning: Installed (but unpackaged) file(s) found: /usr/share/doc/openswan/index.html /usr/share/doc/openswan/ipsec.conf-sample - ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: GoogleEarth/GoogleEarth.spec - %lang
2010/8/18 Elan Ruusamäe : > On 18/08/10 02:57, Caleb Maclennan wrote: >> 2010/8/16 glen : >>> %define buildid 3533.1731 >> >> Where can the correct source package version be downloaded from or how >> should this be built? Building with the package from the URL listed in >> the spec leads to: >> >> + [ 5.2.1.1547-1 != 5.1.3533.1731-1 ] >> + exit 1 > > well, from the same url. > > as you see the url has no VERSION component inside, meaning all versions > "share" same url > > and also as the url is NOSOURCE then the copy is not downloaded to > distfiles. > > i've updated md5 and version for now, did not test the app itself. I just wondered if with a recent commit you had actually gotten it to build and run. My experience is the spec hasn't been operational for a while and it's been over my head to fix. With your last couple updates it now builds and installs for me, but it crashes at runtime. --- (process:16194): GLib-GObject-CRITICAL **: gtype.c:2706: You forgot to call g_type_init() (process:16194): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (process:16194): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed Google Earth has caught signal 11. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [PATCH] NetworkManager & ModemManager
On Sat, Sep 25, 2010 at 19:21, Mariusz Mazur wrote: > On Friday 13 of August 2010, Pawel Golaszewski wrote: >> I think we should give you chance to work on your own account. >> >> me: +1 > > +1 > > Anyone else? :) +1 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [PATCH] NetworkManager & ModemManager
On Mon, Sep 27, 2010 at 12:04, Tomasz Pala wrote: > Who? This voting is too stripped to know who about it is. If you follow the whole email thread this came up after Przemo Firszt sent in a bunch of stuff to be committed for NetworkManager. 2010/9/27 Elan Ruusamäe : > do you know, that if you say +1, you must mentor his commits, i.e > correct him and explain things, not just say "yes" And yes, Elan, I'm willing to help him out with the basic ropes. I don't know all the ins and outs but having just been through the process myself I'm willing to help pass on what I've learned. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
kernel-xenU on non-64bit EC2 instance
Alright guys I'm lost. I've been poking around in specs trying to figure this out and can't make out what I'm supposed to use or what I need to work on if there isn't the right thing available. I am trying to maintain several TH machines on i386 instances over on EC2. They have recently opened up their systems to running custom kernels inside the instance using pv-grub. I can't figure out what pld kernel package to use for this. The kernel-xenU package is set to x86_64 only? The kernel-xen package was last maintained in 2008? The kernel package doesn't have xen block drivers. What path should I be pursuing here? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: VirtualBox-bin/VirtualBox-bin.spec - Up to 3.2.10
On Wed, Oct 13, 2010 at 13:50, caleb wrote: > - Up to 3.2.10 Sorry guys neglected to mark this commit NFY without a release number. There are some path changes and such that need to be fixed in this upgrade, and I had only just started. The commit was just to switch to a different devel box. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
A couple questions about the website
Three questions about the main pld-linux.org site: 1) How does one get a working wiki user? I've tried signing up with my cvs editor name and with a WikiName and every other suggestion but no-way-no-how am I able to edit the wiki pages. 2) How are changes from the PLDWWW cvs module pushed to the live site? 3) Are the moinmoin package files and storage dir that run the site somewhere in version control? If so where and if not why? At the very least I'd like to tend to some basic fixes around the site. It could use some love. Caleb On Mon, Nov 8, 2010 at 16:29, caleb wrote: > - Removed links to dead domains ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: poppler/poppler.spec - Up to 0.15.1
On Mon, Nov 8, 2010 at 21:55, Artur Frysiak wrote: > On Mon, Nov 8, 2010 at 20:25, caleb wrote: >> Author: caleb Date: Mon Nov 8 19:25:19 2010 GMT >> Module: packages Tag: HEAD >> Log message: >> - Up to 0.15.1 >> >> Files affected: >> packages/poppler: >> poppler.spec (1.117 -> 1.118) > > This is unstable/test release. Please use DEVEL branch for it. You're right, sorry my bad -- I missed that that was an unstable branch AND that there already was a devel tag going for it. Is the best way just to reverse the diff on that commit? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: poppler/poppler.spec - Up to 0.15.1
On Tue, Nov 9, 2010 at 08:37, Jakub Bogusz wrote: > Also cairomm 1.9.x and AFAIR fribidi 0.19.x are development versions... > (stable cairomm is 1.8.x) The specs for poppler and cairomm have been reset to their proper stable branches. For fribidi, I would argue that it might be just as well to keep 0.19.x as stable. It is a pre release branch for 2.x but the upstream project has recommended it for production use for over a year now. Thoughts? I can tag it devel and build it separately for my purposes if there are problems with it, but I'm seeing more issues with the old 0.10.x than this branch. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD-doc: PLD-update-TODO - updated
On Tue, Nov 9, 2010 at 13:20, arekm wrote: > -busybox(42) [OLD] 1.16.2 [NEW] 1.17.3 I've been thinking a little about the notify script that generates these messages. I'm working on a special purpose live-cd project and upgrading the software that will go into it, so it's been a useful little script. However it doesn't seem that there is a formalized way of dealing with different lines (devel, stable) or partial upgrades. For example above busybox is no longer marked as needing an upgrade because I started work on it yesterday. However I was unable to finish the process and the current spec has a non-integer release number and does not build. I committed the work so that the patches I was able to update are available to someone else trying to get it upgraded, but not because it ought to be marked off of a to-do list. Also, there are lots of packages that have specific devel numbering schemes (example: perl cpan packages where x.x[13579]x is devel and x.x[24680]x is stable). The pldnotify.awk script doesn't seem to have a way to understand these. Even the ispre() function doesn't seem to work in many cases where it should. Am I missing some available tools or is this really a hit-and miss operation right now? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Future direction of official PLD website (Was: A couple questions about the website)
2010/11/11 Elan Ruusamäe : > there actually exists dokuwiki install: > http://www.pld-linux.org/dokuwiki/ > > currently it uses pldusers.org theme, so if somebody would > create theme similar to current www in dokuwiki format, > i'd finish the data migration and replace the moinmoun install > > moinmoin install is outdated, unmaintained (at least in pld side), > dokuwiki i use at least myself, so i could improve and tech support it. Does anybody have any ideas or strong opinions about MoinMoin vs. DokuWiki? I have none. Both upstream projects seem to be pretty well supported and updated, although DokuWiki seems to have a smaller community and periodic spells of stagnation. In it's favor Elan knows it already and is willing to help support it. It seems like either one can be adapted for our needs. My original thought was to add the current state of affairs including the modified moinmoin source that currently powers the site to cvs and then work through upgrading moinmoin keeping appropriate modifications, then get all the broken bits working and start cleaning up the site from there. Future site maintenance would then be easier to continue or tweak by anyone with cvs access. However, the moinmoin install is so old (modified 1.3.3) that it looks like upgrading through 5 major releases will be as much work as switching to another engine if that's what folks want to see. Also the file structure has changed significantly several times, making cvs and it's lack of move/rename functions a cumbersome way to deal with this. Perhaps subversion or git would be a better option to manage whatever site source code we end up with? Additionally, can someone explain what is up with pld-users.org? It looks like this was an attempt to actually do what pld-linux.org ought to have been doing while it was actually stagnating. It seems like some of the best content there should be pulled over, and the parts of it that are now themselves out of date should be jettisoned. Thoughts on this? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Future direction of official PLD website (Was: A couple questions about the website)
On Sat, Nov 20, 2010 at 17:54, Marcin Rybak wrote: > I don't know if I have a law to say something :) - but, I'm not sure if > dokuwiki with revisions and recent changes is what should appear on PLD > site. IMO it is better for guides (like docs.pld-users.org was) I hear your concern about the nature of the site root pages, but the current site is built on a wiki engine and unless somebody has a clear idea of what should make up the site root instead, I don't see any reason not to keep going that direction. We could use some combination of ACL's and namespaces to not show things like the revision history or edit options for root pages to non-commiters, but still encourage the community to help maintain the site. The other options would be to code up something by hand or bring a different kind of CMS into the mix, such as drupal. I'd be happy to move that route too and there would be some advantages. Thoughts? > AFAIR pld-users was for users :), to make them chance to support pld, share > their own content and experiences. They do not have to ask for right to > change sth, and if something is outdated, everybody can change it. I think this was the idea behind making the main site a wiki in the first place, but with the user system broken, it's fallen a few years out of date itself. If we do continue with a wiki as the primary CMS, we could easily have a users name-space so that people can contribute new content and since it would be the same format, we could easily promote this content to being top level without needing to reformat, relink everything such as if the site was managed with drupal or another CMS. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: proftpd compromised sources
On Thu, Dec 2, 2010 at 15:02, Marcin Rybak wrote: > I have no idea if it's important to PLD, but if we take sources from oficial > ftp.proftpd.org this should be taken into account: > > http://sourceforge.net/mailarchive/message.php?msg_name=alpine.DEB.2.00.1012011542220.12930%40familiar.castaglia.org PLD's spec file was last updated on the 25th before the above mentioned compromise took place and the md5 checksum we have for our sources is the correct validated one. Thanks for the heads up. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages (DEVEL): roundcubemail/roundcubemail.spec - include release on tri...
I noticed while doing some testing of the roundcube beta package that
it will not build using older rpm-build-macros. Specifically I had a
machine with 561 that died trying to run the first %sed macro, after
upgrading to 596 it builds fine.
Is this something that should be noted as a BR? If so does anybody
know what version of rpm-build-macros would have effected ${__sed}
recently?
Caleb
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages (DEVEL): roundcubemail/roundcubemail.spec - include release on tri...
2010/12/8 Elan Ruusamäe : > On 08/12/10 21:12, Caleb Maclennan wrote: >> I noticed while doing some testing of the roundcube beta package that >> it will not build using older rpm-build-macros. Specifically I had a >> machine with 561 that died trying to run the first %sed macro, after >> upgrading to 596 it builds fine. > > you need to show the error itself, the magic numbers say absolutely nothing I was afraid you were going to ask that and I was doing to have to downgrade everything to try it again. I got lucky and found the old build in my screen logs. Here is the important bit: + /bin/sed -i -e s,\r$,, -f php,inc,js,css /bin/sed: couldn't open file php,inc,js,css: No such file or directory And to close here is the whole thing just in case it's helpful: $ builder roundcubemail builder: Sticky tag DEVEL active. Use -r TAGNAME to override. P roundcubemail/roundcubemail.spec # $Revision: 1.107.2.2 $, $Date: 2010/12/08 14:21:13 $ No conditional flags passed from available: --with : password_anon_ldap_bind postfixadmin spamfilter --without: Available branches: DEVEL AC-branch roundcubemail-0.5-beta.tar.gz having proper md5sum already exists rcpfa-105.tgz having proper md5sum already exists Building target platforms: noarch-pld-linux-gnu Executing(%prep): env -i PATH=/bin:/usr/bin:/usr/sbin:/sbin:/usr/X11R6/bin HOME=/home/users/caleb TMPDIR=/home/users/caleb/tmp /bin/sh -e /home/users/caleb/tmp/rpm-tmp.23317 + umask 022 + cd /home/users/caleb/rpm/BUILD + cd /home/users/caleb/rpm/BUILD + rm -rf roundcubemail-0.5-beta + tar -xf - + /bin/gzip -dc /home/users/caleb/rpm/packages/roundcubemail/roundcubemail-0.5-beta.tar.gz + STATUS=0 + [ 0 -ne 0 ] + cd roundcubemail-0.5-beta + /bin/id -u + [ 502 = 0 ] + true . + /bin/chmod -Rf -Rf a+rX,u+w,g-w,o-w . + echo Patch #0 (roundcubemail-config.patch): Patch #0 (roundcubemail-config.patch): + patch -p1 -s + < /home/users/caleb/rpm/packages/roundcubemail/roundcubemail-config.patch + echo Patch #5 (use-iconv.patch): Patch #5 (use-iconv.patch): + patch -p1 -s + < /home/users/caleb/rpm/packages/roundcubemail/use-iconv.patch + xargs -r rm -rf + find -name .svn + /bin/sed -i -e s,\r$,, -f php,inc,js,css /bin/sed: couldn't open file php,inc,js,css: No such file or directory error: Bad exit status from /home/users/caleb/tmp/rpm-tmp.23317 (%prep) RPM build errors: Bad exit status from /home/users/caleb/tmp/rpm-tmp.23317 (%prep) Error: package build failed. (no more info) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages (DEVEL): roundcubemail/roundcubemail.spec - include release on tri...
2010/12/8 Paweł Zuzelski : >> + /bin/sed -i -e s,\r$,, -f php,inc,js,css >> /bin/sed: couldn't open file php,inc,js,css: No such file or directory > Looks like %undos macro. It BRs rpmbuild(macros) >= 1.566. Thank you Paweł. I could have cyphered that out if I hadn't had a blind eye to that line in the spec file! Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: gobject-introspection/gobject-introspection.spec - reverted: dupl...
On Thu, Dec 9, 2010 at 19:40, qboosh wrote: > BuildRequires: libffi-devel > -BuildRequires: libffi-devel Huh what? These were not back to back when I edited, adapter did that :-) Trying to build was failing during configure with something about missing ffi.h or some such. I ran `poldek -i libffi-devel` and it worked so I figured it was that simple. Why did the original BR not warn me my system didn't have it? Or are we actually dealing with a version problem and it needs >= X? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: mysql/mysql.spec - requires versioned mawk (see http://www.opensu...
2010/12/13 Zsolt Udvari : > Bug report: > http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2010-November/021902.html That link isn't a bug report so much as a request for one. Also it was suggested what information would be helpful to include in the bug report. I just looked in the bug tracker and don't see a bug report at all much less the requested conf file. I did look at the spec briefly and was unable to duplicate the problem using my own confs. If someone who is having this issue can file a bug report and include their confs we might be able to find something. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: exim in PLD-AC
> Does anybody maintain AC? Is there any chance that exim will be patched or > upgraded to 4.7x in case of this bug: > http://seclists.org/bugtraq/2010/Dec/77 ? I imagine for a security issue like that someone will step in and update AC. However it might be pertinent to ask whether that should be an upgrade to 4.7x or a patch to the 4.6x line used in AC. Does anybody know if a back-port of te the security patch will be available for 4.6x? I see some other distros "patching" their old trees just by removing the root privs from exim at least as a temporary measure. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: mysql/mysql.spec - requires versioned mawk (see http://www.opensu...
Bug in the tracker: https://bugs.launchpad.net/pld-linux/+bug/689563 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [Bug 689563] Re: packages: mysql/mysql.init, mysql/mysql.spec - allow spaces and tabs after ...
>>> ...pff, make temp var "key" there
>> you have write access.
> no, fix yourself,
Hey guys don't forget we're on the same team here.
I tried making this change myself, but either my smattering of awk
knowledge is not enough or something else is going on here. I made up
a variable and striped the spaces from it and used that for the tests,
but it gives the same error we started with. Then I realized that the
original variable was already being stripped (see line 199)! The ~
comparison must be doing something other than just stripping spaces as
per the regex.
Anybody know what else is going on there? Here is my attempted patch.
Index: mysql.init
===
RCS file: /cvsroot/packages/mysql/mysql.init,v
retrieving revision 1.144
diff -u -r1.144 mysql.init
--- mysql.init 13 Dec 2010 15:09:11 - 1.144
+++ mysql.init 14 Dec 2010 09:24:43 -
@@ -209,22 +209,25 @@
next;
}
+ key = $1;
+ gsub(/[ \t]*/, "", $key);
+
section == "mysqld" {
- if ($1 ~ /^datadir[ \t]*$/) {
+ if ($key == "datadir") {
printf("MYSQL_DATA_DIR=%s;", $2);
- } else if ($1 ~ /^user[ \t]*$/) {
+ } else if ($key == "user") {
printf("MYSQL_USER=%s;", $2);
- } else if ($1 ~ /^pid-file[ \t]*$/) {
+ } else if ($key == "pid-file") {
printf("MYSQL_PIDFILE=%s;", $2);
- } else if ($1 ~ /^socket[ \t]*$/) {
+ } else if ($key == "socket") {
printf("MYSQL_SOCKET=%s;", $2);
- } else if ($1 ~ /^port[ \t]*$/) {
+ } else if ($key == "port") {
printf("MYSQL_PORT=%s;", $2);
- } else if ($1 ~ /^bind-address[ \t]*$/) {
+ } else if ($key == "bind-address") {
printf("MYSQL_BIND_ADDRESS=%s;", $2);
- } else if ($1 ~ /^skip-networking[ \t]*$/) {
+ } else if ($key == "skip-networking") {
printf("MYSQL_SKIP_NETWORKING=1;");
- } else if ($1 ~ /^log-error[ \t]*$/) {
+ } else if ($key == "log-error") {
printf("MYSQL_LOG_ERROR=%s;", $2);
}
}
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: kernel-xenU/kernel-xenU.spec - up to 2.6.36.2 - please, test i686
On Tue, Dec 14, 2010 at 03:35, pawelz wrote: > - up to 2.6.36.2 > - please, test i686 This builds fine on i686 for me. I don't know why you had a problem with it. What kind of error did you get? Are you cross-compiling? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: kernel-xenU/kernel-xenU.spec - up to 2.6.36.2 - please, test i686
2010/12/14 Paweł Zuzelski : > It does not build on th-i686 builder: > http://buildlogs.pld-linux.org/index.php?dist=th&arch=i686&ok=0&name=kernel-xenU&id=39eeab1b-c086-4036-b8df-31473ed7822c&action=tail Roger that ... I think I know what that's about. I'll try to fix it when I get back to a computer late tonight if you haven't by then. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: mono/mono.spec, mono/mono-encryption.patch (REMOVED) - Up to 2.8....
2011/1/10 Michał Lisowski > > > - Removed patch8, applied upstream > > > ^^^ if you remove patch, make sure you also remove it from cvs. I did, the whole action was in one commit. This is noted in the subject of the notification email sent to the list: mono/mono.spec, mono/mono-encryption.patch (REMOVED) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cdg: regulations.txt - spelling
I had a look at the cdg regulations file, and the English version is very rough. I took the liberty of re-writing it in clearer English. Since I do not speak Polish I am unable to compare this to the original. I am attatching my update for review before attempting to commit to to CVS. Since I am not a member of the CDG I figure I'll wait for a nod from somebody before commiting this. There should be no factual content changes, only better English. Caleb [ NOTE: this document contains a translation of Polish version, which is the official one at the moment ] Core-Developers-Group ~ The Core Developers Group operates on behalf of the PLD Linux Distribution. CDG makes decisions democratically. The CDG is responsible for making decisions that are critical for the distribution and for solving conflicts among the management. CDG members are appointed by general ellection. Belinging to the CDG is the second stage of developer status (after being granted RW). *** Conflicts. CDG is able to make decisions which cannot be made by other developers in the course of discussion. For example: 1. Revoking somebody's RW in CVS 2. Disputes about the contents of a specific specfile *** Decisions. Decisions about issuing sequential versions of the distribution and the timing. *** Membership. The admision/removal of a CDG member is accomplished by a 2/3 majority vote with a minimum of 50% turnout. Only CDG members vote. A proposal for removing a member is to be voted on after 3 months of that members inactivity as a CDG (lack of comments, no voting, etc.). A CDG member may resign. This does not require a vote. A member who temporarily cannot participate in CDG activities may choose to suspend themselves. This is done by adding the text ":suspended till " after their login in sklad.txt. Suspension is effective the next day (by UTC time) after commiting the entry and lasts until the specified day. A member may return to the CDG earlier by removing the suspention entry from the file - in which case the last day of suspension is the day prior (according to the UTC timezome) to removing the entry. Durring suspension: - the member is not counted idle as defined in the Membership section. - the member is not taken into account when calculating a quarum for a vote held entirely inside of the suspension period. The total period of suspension must not exceed six months durring a calendar year. Withdrawal from CDG does not imply the revoking of RW access. A list of active CDG members can be found in "sklad.txt" *** Voting. A proposal for a vote may be filled by any PLD developer (not just mebmers of the CDG). The proposal must stay in CVS for at least 24h durring which time it should be discussed and, if needed, modified. A proposal must be seconded by three members of the CDG before being taken to a vote. If a proposal does not gain enough support in the 30 days following being filed it is automatically withdrawn. A proposal may also be withdrawn by its author provided that the voting phase has not yet begun. Voting is accomplished in the cdg cvs module (cvs://cvs.pld-linux.org/cdg/). Voting is public and motes maybe changed durring the durration of the voting phase. CDG members may also cast their votes by sending a PGP-signed email to the CDG mailing list. The public key should be placed in the PGP-keys module on the cvs server. The voting period is 48h from the time it is announced on the list. In the event of an insufficient turnout, voting may be extened for another 48h to a maximum of three extentions. After the completion of voting, uncast votes are treated as abstentions. Changes to these regulations or modifications to the membership of CDG require the number of YES votes to be at least twice as high as the number of NO votes, a minimum turnout of at least 50% and at least one non-abstain vote. All other votes require a simple majority of votes, regardless of the turnout. *** Changes Changes to this document are managed by the CDG. # vi: encoding=utf-8 tw=72: ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cdg: regulations.txt - spelling
2011/1/27 Elan Ruusamäe : > thanks, verified you didn't add your secret clause :) I won't say I didn't think about it. I figured since I was sending it to the list and not just slipping in a commit that it might not be subltle enough to get away with ;-) Then again there is always `cvs annotate`. > and commited with few spelling fixes. My grammar is good; but I confess my spelling is not. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: mm-common/mm-common.spec - %files fix - rel. 2
2011/3/22 wiget :
> - %files fix
> ...
> +%{_npkgconfigdir}/mm-common-util.pc
Widget ... sorry I guess I broke that, but that file did not show up
when I built the first time. It does now. Any idea what I was doing
wrong?
Caleb
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: telepathy-glib/telepathy-glib.spec - merge DEVEL branch
2011/3/22 wiget : > - merge DEVEL branch Is there a magic CVS command for doing that merge or did you do it by hand? I've wanted to do it to a few other specs and not known what was the best practice. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: telepathy-glib/telepathy-glib.spec - merge DEVEL branch
2011/3/22 Bartosz Taudul : >> cvs up -jDEVEL Thanks widget. > http://images.mylot.com/userImages/images/postphotos/2130671.jpg Wolf, I feel like I'm on the outside of an insider joke. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ntfs-3g and ntfsprogs merge
>> or how do you foresee the upgrade path in pld if both package names just >> dissapear? > > Some Provides and Obsoletes should be sufficient. Correct meif i'm wrong. Yes, the Provides and Obsoletes will take care of being able to upgrade and replace the previous package names. The problem is that there is no notification feature for the OLD packages, they just get stuck at an old version and eventual disappear from the stable package set. However this is not a unique problem to this issue, it happens regularly and even I have been known to ask on this list where to find the "new" package name for something project that morphed into something else. I think your request for a spec COPY not a move/rename is appropriate. People may still need to be able to build the original package for a while, but work can continue under the new package name. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ntfs-3g and ntfsprogs merge
> http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/obsoleted/obsoleted.spec?rev=HEAD > > It works by building an empty package that marks the upgrade target > and immediately gets obsoleted by said target. There is nothing to > clean up then. Where have you been all my life? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: transmission/transmission.spec - ta_LK (Sri Lanka Tamil) unsuppor...
> caleb, why only this one? :) Valid question. The workings of find_lang and some other rpm ninja tricks are still slightly magic to me. In this case, because it worked. That one language was causing RPM to fail to install, and removing it allowed it to be installed without errors. Right now I'm struggling through cleanup of packages that have fallen out of TH because they stopped building when Gnome3 was introduced. Lots of software I have works fine as long as there are some legacy packages on the system (gnome 2.32.x libraries such as gnome-media) but on new TH installs nothing seems to be working well right now. Suggestions for what I can be working on to fix this? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: transmission/transmission.spec - ta_LK (Sri Lanka Tamil) unsuppor...
>> >> - ta_LK (Sri Lanka Tamil) unsupported, rel 2 >> >> >> > caleb, why only this one? :) >> >> Valid question. The workings of find_lang and some other rpm ninja >> tricks are still slightly magic to me. >> >> In this case, because it worked. That one language was causing RPM to >> fail to install, and removing it allowed it to be installed without >> errors. >> > > ok, my first through was that we drop languages that it's impossible that > PLD user will ever use, and second... "why only this one" :) There are an awful lot that could not realistically be used. Has the possibility of a whitelist of fully included languages been considered? It seems like every spec has a different list of problematic languages that have to be cleaned up, but across the distro there isn't a lot of consistency here. > on what environment it fails to build? I had no problems with transmission. It didn't fail to build, the resulting rpm fails to install with a dependency error on a tl_LK language directory. (TH 64) Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Deps in TH
The current zsh package on the main mirror site for TH x86_64 is zsh-4.3.12-1. When I try to upgrade to it from 4.3.11-1 I get something like this: > error: zsh-4.3.12-1.x86_64: req libc.so.6(GLIBC_2.14)(64bit) not found The version of glibc in the same TH tree is 2.13-6. Only the th-test tree has glibc-2.14. Is this a "wait it out" until all the packages come through? Why did things that depend on new glibc move over from th-test before glibc? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Deps in TH
> "ready" is a place where packages are moved over longer period of time to get > kind of package set ready to be moved to "main". So is there a reason Gnome3 skipped the "ready" tree? > Because there is no checking in python scripts for that. Shouldn't there be some kind of test using rpm to check that dependencies for anything in a tree are provided by packages in the same tree? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: pacgraph: ERRORS: keenerd-pacgraph-e495c03.tar.gz
On Sat, Jul 23, 2011 at 11:35, caleb wrote: > wget -nv --no-check-certificate --user-agent=PLD/distfiles -O > ./tmp/9c4646a0-f84d-45c6-9e96-8c9a251e6297/fdf09c8cdea9c9e58c6fc2acc79a0528/keenerd-pacgraph-e495c03.tar.gz > "https://download.github.com/keenerd-pacgraph-e495c03.tar.gz": > https://download.github.com/keenerd-pacgraph-e495c03.tar.gz: > 2011-07-23 10:35:24 ERROR 404: Not Found. What's the proper way to specify a source tarball from github at a specific commit? The URL in this package works, but seemingly only after you hit the trunk download url: https://github.com/keenerd/pacgraph/tarball/master Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: pacgraph: ERRORS: keenerd-pacgraph-e495c03.tar.gz
2011/7/25 Elan Ruusamäe : > or just use our distfiles upload... Would you believe I don't know how to do that? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
poldek hooks
Does poldek offer any hooks or way to trigger actions at any point? For example are there pre/post transaction hooks that I could modify to run something before and/or after any rpm action is taken? How about an "on exit if any package installed / upgraded / uninstalled" during the lifetime of the process? If so where is the best place to find documentation on this? On a related note, is it possible to globally add something to the rpm %pre/%post/%preun/%postun macros? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: poldek hooks
On Tue, Aug 23, 2011 at 17:54, Patryk Zawadzki wrote: > If you're only interested in a particular > group of packages, consider faking install-time expansion by calling a > common shell script in %post or %posttrans. I am interested in ALL packages, however I don't understand what you mean by "faking install-time expansion" or what %posttrans is. Could you explain? I am specifically trying to port etckeeper to PLD. For example yum has an API that you can get callbacks pre-transaction and post-transaction. Apt has command hooks that can be triggered before and after any call to dpkg (or rpm). Pacman likewise has a hook system that can invoke something pre/post any upgrade or install. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: poldek hooks
On Tue, Aug 23, 2011 at 19:14, Patryk Zawadzki wrote: > Yes, other rpm wrappers support triggers. I think the proper way would > be to add these to rpm itself rather than trying to hack them into > poldek. Add add system wide %pre-transaction %post-transaction macros to rpm itself? That sounds fair enough. > On the other hand our current rpm (4.5) is not supported by either > rpm5.org or rpm.org. What's the deal there? Are we happily patching up a dinosaur? What's the barrier to moving to one of the newer branches? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Segfaults on across the board in TH
-- Forwarded message -- From: "Caleb Maclennan" Date: Mar 26, 2012 1:51 PM Subject: Segfaults on across the board in TH To: "PLD Devel" Recently I've upgraded several desktop oriented machines against the latest TH repositories. The two I'm looking at right now both use the proprietary nvidia drivers from the PLD packages and pulseaudio. Anything that uses pulseaudio or accelerated graphics seems to be segfaulting. Simple examples are mplayer and glxgears. Both segfault instantly. Output of dmesg is as follows: [776933.882860] mplayer[29278]: segfault at ff700120 ip 7f1c42a440fb sp 7fff77474d90 error 4 in libGL.so.285.05.09[7f1c429a8000+c2000] [776944.697186] glxgears[29282]: segfault at ff700120 ip 7f5b04cd60fb sp 7fff00b7edc0 error 4 in libGL.so.285.05.09[7f5b04c3a000+c2000] Interestingly, running most things under strace will make the segfault go away. `strace 2> /dev/null glxgears` runs like a charm. Which direction do I need to go to work around whatever bug (timing?) is being triggered here? Do I need use nvidia drivers directly from the binary install packages rather than PLD's compiled ones? Do I need a different kernel or older glibc for now? I can't make out which piece is even broken so I don't know if this is a glibc bug or an nvidia nightmare or a PLD compile issue. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Segfaults on across the board in TH
> I have reported this problem long time ago on a polish devel list. There was > no solution given (only "we must wait for the next nvidia release") and I've > switched to nv. Then pluto suggested to try: I started seeing this with a 290.x nvidia driver version and never figured it out, but I've waited to whine about it until 295.x came to TH and I'm seeing the same problem. There has to be a better answer. I have nvidia drivers on other distros and it's not doing this. What is different? > valgrind --tool=helgrind glxinfo I'm attaching my output from this ... honestly it doesn't tell me much. Caleb ==7959== Helgrind, a thread error detector ==7959== Copyright (C) 2007-2011, and GNU GPL'd, by OpenWorks LLP et al. ==7959== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==7959== Command: glxinfo ==7959== --7959-- WARNING: Serious error when reading debug info --7959-- When reading debug info from /usr/lib/nvidia/libGL.so.295.20: --7959-- Can't make sense of .got.plt section mapping --7959-- WARNING: Serious error when reading debug info --7959-- When reading debug info from /usr/lib/nvidia/libnvidia-glcore.so.295.20: --7959-- Can't make sense of .got section mapping Helgrind: hg_main.c:4273 (is_in_dynamic_linker_shared_object): Assertion 'soname' failed. ==7959==at 0x380337AB: ??? (in /usr/lib/valgrind/helgrind-x86-linux) ==7959==by 0x3803390F: ??? (in /usr/lib/valgrind/helgrind-x86-linux) ==7959==by 0x3801D589: ??? (in /usr/lib/valgrind/helgrind-x86-linux) ==7959==by 0x3804B645: ??? (in /usr/lib/valgrind/helgrind-x86-linux) ==7959==by 0x380D1E62: ??? (in /usr/lib/valgrind/helgrind-x86-linux) ==7959==by 0x3804DF40: ??? (in /usr/lib/valgrind/helgrind-x86-linux) ==7959==by 0x3807B1D7: ??? (in /usr/lib/valgrind/helgrind-x86-linux) ==7959==by 0x3808C31C: ??? (in /usr/lib/valgrind/helgrind-x86-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==7959==at 0x484B1C9: ??? (in /usr/lib/nvidia/libnvidia-glcore.so.295.20) ==7959==by 0x484B0D8: ??? (in /usr/lib/nvidia/libnvidia-glcore.so.295.20) ==7959==by 0x400F00C: call_init (in /lib/ld-2.15.so) ==7959==by 0xBEE494A6: ??? ==7959==by 0x49444E44: ??? Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Segfaults on across the board in TH
> http://www.nvnews.net/vbulletin/showthread.php?p=2538961 > > Fixed a bug that caused OpenGL applications to crash with some libc > versions, such as eglibc 2.15. Eh? Now that looks promising. I'm trying to build PLD's packages now. Silly me I would have thought nvidia would fix major bugs like that in the next major release not in some future point iteration. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Segfaults on across the board in TH
2012/3/27 Caleb Maclennan : >> http://www.nvnews.net/vbulletin/showthread.php?p=2538961 >> >> Fixed a bug that caused OpenGL applications to crash with some libc >> versions, such as eglibc 2.15. And ... that did the trick. 295.33 with the 3.3.3 kernel from th-test runs without a hitch. The sooner that comes down the pipe to th-ready/main ... Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: gimp 2.8.0 rc1, gimp plugins
2012/4/19 Artur Wroblewski : > hi, > > i would like to move gimp 2.8.0 rc1 from DEVEL to HEAD. > > any argument against? > > btw. we have some quite old gimp plugins on ftp, i.e. build in 2010, 2009. > shall > they be removed, rebuilt? > > regards, > > w Yes. That is an RC for a major release version and there aren't any show-stopper bugs or comparability issues in the previous release that would force us to skip ahead to get the bugs ironed out. At this point I'm having a heck of a time keeping stable systems using TH which is supposed to be STABLE. Adding more backwards incompatible libraries to the dependency mess is going to make that worse, not better. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: gimp 2.8.0 rc1, gimp plugins
> Ac is stable release for which we have appropriate branch and Th > is in constant development mode, isn't it? This is one area where PLD's release system is actually pretty wonky. Other than a few emebeded or very static applications, AC is simply too old to use for most stable systems. This puts the pressure on TH -- as in reality, most folks use PLD for it's rolling constant development branch. Anything that breaks that breaks production systems. > I am asking because I am bit lost with above arguments - do we > have some new rules for Th? When they changed? :P As far as I know, nothing has changed. This has been my understanding of the status quo since I started using PLD nearly a decade ago. > To repeat myself "cvs head != Th ftp". If you send it to the builders, > then it is your fault. I understand the difference beteween HEAD and FTP servers. The thing is, by introducing unstable packages to HEAD, you make life complicated for some of us. I for one compile a lot of software using builder from CVS HEAD. Sometimes if there are holdups on TH, stuff will actually be ahead of TH in my personal repos. When something gets introduced to HEAD that is a complete mis-match with what is currently in TH, it makes building software harder. Let's turn this question around. Since you're the one asking to do something non-standard, what is your rational? What do you gain by putting an RC version in HEAD? If you are compiling it anyway, why can't you just use the DEVEL tag until the package goes stable and people should start testing it to go into TH? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
> well... if you need more stable line, then why not to create one with > appropriate > branch in CVS? of course, the problem is that somebody needs to maintain that, > which I believe is full time job and lack of resources causes the stable > branch > to freeze. therefore, imho, it is not good idea to link CVS HEAD with stable > line - and that was the result of similar discussions in the past if i > reckon well. > > if you need more reassurance, then what about introducing TH-STABLE tag and > sending packages to builders only when they are tagged with above? A tag scheme like that could of course work. Again I would ask ask how, other than different tag names, this is different from the status quo. Please answer this: what do you see as the advantage to having an RC release tagged HEAD instead of DEVEL? How does merging DEVEL into HEAD before it's going to be a candidate for FTP make life any different for you? What's the motivation? I honestly don't understand what you're trying to accomplish and thus I feel like you're presenting a solution to something that isn't a problem and thereby introducing a problem. Does that make sense? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
> Caleb, "stop trolling"*! You're asking very inconvenient questions :) Wink wink. I'm not actually trying to troll or be inconvenient. I'm also not interested in pointing fingers. I am a system administrator having a hard time keeping up with all the broken systems. I think a contributing factor to that is PLD's current lack of a clear set of release/use/development patterns. I'd like to see these develop not deteriorate. If we're going to all keep making use of this thing, our practices as commiters need to at least gradually grow in both innovation and maintainability. When things come along that appear to be steps in the opposite of these directions, I think we should bring them up as something to solve. So I'm listening. How does this proposed CVS tagging of RC as HEAD further these ends? What's the gain? How can we all help? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
2012/4/20 Artur Wroblewski : > it is very simple. "th-stable", "ac-stable" or whatever... provide > meaningful, self documenting names to things. Hey guys, how does this compute? My version control experience is mostly subversion with a bit of git lately. CVS is still black magic to me. Would a change like this (Tagging stable stuff that's headed to ftp somewhere instead of pulling HEAD?) Also to throw this out there, how does all this figure into the git migration? Are we barking up a tree that is about to be felled anyway? Artur ... I'm still not clear on what you GAIN by using HEAD instead of DEVEL? In spite of the name, isn't HEAD basically functioning as th-stable (plus some mess)? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
CVS rename for nautilussvn
The upstream project NautilusSVN has been renamed to RabbitVCS. Can we get our CVS module renamed or should I work on a new spec? Thanks, Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: CVS rename for nautilussvn
> Package copied/renamed server-side. Thank you! Can I ask why our gedit module is called gedit2 on cvs? The upstream project seems to be at 3.4.1, which is what we have in that spec file. Is there any point in keeping that legacy name in our cvs module? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: gedit2 (Re: CVS rename for nautilussvn)
2012/5/6 Elan Ruusamäe : > feel free to merge gedit2.spec to gedit.spec (and drop the former), just > remember to handle obsoletes properly As a latecomer to CVS (backporting my knowledge of VCS from subversion, git, etc) I am not sure which button to push here. Since these two specs aren't a branch scenario, merge doesn't seem like the right option to me and I wouldn't know how to do it if it was. Shouldn't this be 1) remove the current gedit module 2) rename gedit2 to gedit and 3) cleanup the spec, setup obsoletes, and go through other specs for dependency issues? If so, I can take care of #3 if somebody else does the cvs server side stuff in #1 and #2. If not, then I have no idea what I'm doing. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: gedit2 (Re: CVS rename for nautilussvn)
2012/5/7 Elan Ruusamäe : > 1. rename gedit dir to gedit0 in cvs server side and optionally drop it > client side > 2. rename gedit2 dir to gedit in cvs server side, and adjust names in files > on cvs client side This sounds good. If somebody takes care of the server side bit I'll help cleanup the resulting spec. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Cluster stuff (cman, dlm, heartbeat, corosync, openais, pacemaker, drbd, lvm)
2012/7/1 Jacek Konieczny : > On Sun, Jul 01, 2012 at 10:47:19PM +0300, Elan Ruusamäe wrote: >> On 07/01/2012 11:51 AM, Jacek Konieczny wrote: >> > Do we need clvmd in the main lvm2 package? It pulls some dependencies >> > irrelevant for non-clustered setups. >> i'm in for moving clustered deps to subpackages. if it's doable. > > Already done. Theoretically this could break a cluster on upgrade, but > I don't think it would be a mass problem among PLD users ;) And > production clusters are not a thing one upgrades without testing. I have a cluster setup but nobody is going to die if it breaks on an upgrade ;) While I think in a case like this it is probably more important that we have current working packages than that we don't break old ones, I do think this kind of talk happening on the forum highlights the need for some sort of warning channel: If some package upgrade is EXPECTED to break current configurations, poldek should warn and even expect acknowledgement before proceeding with that package. Has the possibility of manually adding some sort of warning flag between certain upgrades been considered? Ideally all upgrades would just work, but with the number of developers and amount of testing we have right now, that is simply not practical. Sometimes we do things that we know will require intervention to work. We need a fool proof way to warn folks before their systems break. Thoughts about where this functionality should be introduced? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cdg: proponowane-glosowania/cdg_membership_caleb - temporarily withdraw my ...
> - temporarily withdraw my second; let's wait a week or two and see how caleb's > current projects with regards to the cdg go; if he succeeds, that means he > might be of use at conflict resolution; if he fails, he fails, and there's > no point in granting him cdg membership at the present time So was my nomination to CDG based sole on my suggestions relevant to a particular problem? With that problem taken care of another way is my participation considered irrelevant? Should I apply through another channel if I'm actually interested for other reasons too? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cdg: proponowane-glosowania/cdg_membership_caleb - temporarily withdraw my ...
2012/7/6 Bartosz Taudul : > I told you it's just a stupid kindergarten power play. Some people > never learn... Look. If all you guys want is to make me part of a power play, please just count me out. Don't vote for me. I'm not interested in joining a pre-school. I skipped that the first time around and don't think I really missed out in life. On the other hand if folks around here (you too wolf) have something else in mind -- a little more mature perhaps -- maybe working together in a professional manner -- step by step moving things forward in a way that is useful to us and keeping things as clean as possible to encourage new participation, then consider a vote. I realize CDG doesn't have the power to command forward motion, but it can help settle internal disagreements as they come up. If this is done effectively we can cultivate an environment where innovation continues. If you don't have reason to believe I would act with good judgement when the time comes for that, don't vote. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
2012/7/9 Kacper Kornet : > * Some documentation > > > For some basic introduction to git and how to use it to work with PLD > repositories please see: > > http://www.pld-linux.org/dokuwiki/howto-git Two simple questions: 1) I haven't seen any notes in the docs about comment formatting. Are we still prefixing all changelog entries with "- "? This isn't a very usual thing to do with git and seems like a hack we've dragged in from processing cvs output. 2) Is there a way to set git's user.email config variable without doing it globally? I use git for other things where my pld nick is not my email. However with each package being a separate repository, setting it in the repository config file instead of the global one means having to set it in a couple thousand places. Is there a way to match the git origin server or some other way of marking that everything under rpm/packages gets a certain set of configuration values? Thanks, Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
2012/7/10 Jakub Bogusz : > On Tue, Jul 10, 2012 at 03:40:58PM +0200, Kacper Kornet wrote: >> On Tue, Jul 10, 2012 at 04:26:00PM +0300, Caleb Maclennan wrote: >> > 2) Is there a way to set git's user.email config variable without >> > doing it globally? I use git for other things where my pld nick is not >> > my email. However with each package being a separate repository, >> > setting it in the repository config file instead of the global one >> > means having to set it in a couple thousand places. Is there a way to >> > match the git origin server or some other way of marking that >> > everything under rpm/packages gets a certain set of configuration >> > values? >> >> The solution that I know is to define a wrapper around git, that calls >> call "git -c user.email=whatever", where whatever depends on the current >> path. It's cumbersome, but maybe better then nothing. > > Is it possible to include user.* setting in per-package .git/config? > > If so, slug.py or builder could set it based on some PLD-specific config > file or environment variable. Yes it is possible. It would look like this as a separate section: [user] email = ca...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
2012/7/10 Mariusz Mazur : > Or one can alias the 'git' command to a simple script that checks for > .git/config, check if remote origin is git.pld-linux.org and if so, uses a > different user.email. > > Hm, I could use that. Wonder if anyone already wrote it. I thought of that too and could code it up, but as I thought about it, it seemed like something somebody else would already have done long ago. I just couldn't figure out what to search for to find a canonical solution. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
2012/7/10 Kacper Kornet :
> The solution that I know is to define a wrapper around git, that calls
> call "git -c user.email=whatever", where whatever depends on the current
> path. It's cumbersome, but maybe better then nothing.
Here's my current hack as function for my zsh shell:
function git () {
case "$PWD"; in
$HOME/rpm/*)
command git -c user.email=$u...@pld-linux.org "$@"
;;
*)
command git "$@"
;;
esac
}
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/cryptsetup] Providing and obsoleting itself makes no sense Release 2
2012/8/7 baggins :
> Providing and obsoleting itself makes no sense
> Release 2
> -Provides: cryptsetup-luks = %{version}-%{release}
> -Obsoletes: cryptsetup-luks < 1.4.1-2
Actually it does make sense in the case where a different package used
to provide something of the same name (and may still) but what it
provides is an older version. Without the complementary
provides/obsolete pair you don't get a clean upgrade path to the
package that should be doing the providing.
As far as I know this is the only case where this is necessary, but
there are several instances of it scattered through our packages.
Caleb
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/cryptsetup] Providing and obsoleting itself makes no sense Release 2
2012/8/7 Jan Rękorajski : > You missed the real change, I did not remove P/O for cryptsetup-luks. > I removed P/O for cryptsetup i.e itself A... sure enough. Looks like I missed that one too. Sorry to bother you, but having broken upgrade paths myself in the past over that mistake... Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Can these deps be legitimate?
I've been playing around with a script that generates a live-cd based off of Th for a special purpose machine. I'm generating the target file system using `poldek --install-dist`. My current package set installs, but later in the script when I try to run some commands having chrooted into the target, I get errors that make it look like the package set failed to identify all their own dependencies. > mount: error while loading shared libraries: libselinux.so.1: cannot open > shared object file: > No such file or directory Is selinux currently required for all systems? If so why do no packages trigger it as a dependency? If not, why does mount want to see it? > poldek: error while loading shared libraries: libxml2.so.2: cannot open > shared object file: > No such file or directory Is it possible that poldek should have a dep for libxml2? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: w32codec updated
2012/8/7 Bartosz Taudul : > Ponieważ Bartek cały czas jest żywotnie zainteresowany rozwojem > dystrybucji i aktywnie przyczynia się do wprowadzania zmian, proponuję > aby dać mu dostęp RW do repozytorium. Aren't you rather skipping over a number or relevant issues? First of all, the user you are suggesting for RW access previously had such access and voluntarily dropped it, publicly resigning from the project. For a fresh user new to the project, bringing up their patch history, offering to mentor and nominating them for access makes sense. For a user who has previously resigned, I think we need something else. Like a notice of intent from the user perhaps? Which brings us to the next problem. This user has been banned from the development lists for bad behavior, in particular a consistent series of posts that people felt were trolling and non-constructive. Since being on the devel lists is a requirement for all developers, this seems like a show stopper for repo access until such a time as it is resolved. If you or another user with RW access would like to handle the interaction with this user and be responsible for the commits, there is nothing to stop them. Before nominating them for direct access, they would need to show some good faith to be in better standing with the community. Do they plan to take any steps to fix that? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: w32codec updated
> Search the mailing list archives for "mkochano" who also dropped his > RW access, also sent a number of patches to the list afterwards and > was asked many times to send the password hash, so he would regain his > access. Quite honestly, that has nothing to do with the present case. Even if a situation were to be considered setting a precedent for this one, that user was not banned from the lists per CDG vote. > Very nice. Creating new rules when the old ones do not fit you. I'm not just making stuff up here. Quite frankly our rules don't even cover this case, nor do I think they should be expanded to cover every possible scenario. A little bit of common sense should be applied, and discussion on the list is one way to start. Only if that fails would we need to make a rule out of this, which would require a CDG vote. I'd like to avoid that. > He asked me personally to give him a vote of confidence. That's not the same thing. Just because you don't agree with the decision to ban him doesn't give you the right to run rough shod over the whole thing and ignore the problem as if it never happened. > Maybe I also shouldn't be a developer because some people filter me in > their mail clients? You are going too far. The ban is on the mailing > list access, not on being developer. By the current rules, shadzik > should be a developer, since he got the customary 3 votes for him. I didn't say you shouldn't be a dev. The current rules don't say anything about people who have been banned for bad behavior. They don't even cover what to do when somebody gets +3 votes but also collects several negatives. Hence the discussion here. So how would you propose handling the fact that he's collected several -1 votes as well as +1's? > Yes, we get that, you don't want shadzik to have RW access. I didn't say that either. In fact I'd like to see him back IF a satisfactory arrangement can be worked out where his track record for being inflammatory towards other developers can be mitigated. Does your vote of confidence extend to this? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: w32codec updated
2012/8/10 Bartosz Świątek : > should be punished This isn't about punishment. It's about civility and cooperation. If you're interested in those things, start practicing them instead of trying to stir things up. People would be fine with your participation if you did. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Is there a merged git repository?
Is there any place where the entire PLD git repository can be cloned as single repository? I realize this would be a read-only thing, but the multiple repository layout is problematic for some things such as the code and commiter analysis done by sites like Ohloh (https://www.ohloh.net/p/pld-linux). The slug.py script is able to automate the cloning of the entire package set, but this does't work for the above. There is also the flat SPECS repository, but this doesn't include all the code in patches and supporting files. Also the commits show up as all being made by one author "git". Is it possible to setup access to the packages directory as a repository with all the individual repositories listed as sub-modules? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Is there a merged git repository?
> I'm afraid ohloh might be overwhelmed by *all* the things you do > (just as it was when facing *all* the ALT Linux gear repos when Their recent takeover by BlackDuck has given them a few more resources and they've got a lot of stuff cleaned up. I don't think they would give us the boot do to DoS effect right now. Unfortunately they haven't' cleaned up their CVS import process and they've been trying to get through our old CVS package repo for months now. They do keep trying but headway is slow. > Might be better to feed it only the things *you* do, like poldek > and friends. I see the reasoning, but I think poldek & friends can be their own separate projects there. The package repo IS something *we* do and is a large part of both PLD. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages case sensitivity
2012/9/29 Aria Stewart : >> seems github packages are case insensitive, perhaps we should limit >> similarily in pld to disallow creating packages that differ just >> character case? > > +1. And lowercase be the norm. +1, the current mix-n-match case is kind of a mess and is more of a pain than it's worth. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Package rename
Can we rename the terminator package to gnome-terminator? There are actually two projects by this name and I'd like to introduce the one we don't have to a couple of my systems. I looked at the upstream projects and it looks like the one currently in our specs repo is already partially renamed upstream and is the logical one to get a new package name on our side. http://gnometerminator.blogspot.com/ https://code.launchpad.net/~gnome-terminator/terminator/trunk Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
CRI images
Are there sanely recent CRI images for TH to be had anywhere? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Missing kernel packages from TH repos
I tried to do an install via Rescue CD and poldek --root the other day only to discover that apparently a lot of packages (including the kernel) are missing from the current main TH ftp repository. What's the deal with this? How is anybody supposed to get a system up and running without a way to bootstrap (CRI images are hopelessly old) and without a complete current repository to do a full base system install from? Even knowing the system will I can't figure out how I'm supposed to proceed! Sorry this is half a question half a rant. I'm a bit frustrated with half a dozen systems to replace. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th 2013 snapshot released
On Tue, Dec 31, 2013 at 10:46 PM, Aria Stewart wrote: > On Tue, Dec 31, 2013 at 09:36:40PM +0100, Jan Rękorajski wrote: > > As promised I made a new snapshot of the PLD Th line. > > See the announcment on http://www.pld-linux.org/ for details. > > And there was much rejoicing! > Excellent, keep up the good work. Now if there was just a way to install it... Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/asterisk] Note about the ASTERISK_12 branch
On Fri, Jan 24, 2014 at 11:14 PM, Jacek Konieczny wrote: > Before merging on master I would like to see opinion of anybody using > the asterisk package. > I am using the 1.8 packages in production but the boxes are EOLed and I'm in the process of migrating the services, so I don't plan on upgrading it even if they hit TH. Sorry I won't be much help testing Asterisk on PLD. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
