Re: python
On Wed, Apr 22, 2015 at 6:38 PM, Jacek Konieczny jaj...@jajcus.net wrote: On 2015-04-22 17:41, Elan Ruusamäe wrote: http://git.pld-linux.org/?p=packages/python-setuptools.git;a=commitdiff;h=64c5aa5e97487c2879a621605724e4e64f85a933 blah, i do not understand what should i use in new specs python-setuptools or python-distribute? setuptools i thought setuptools is old and distribute is new? That was true at some time. But that had changed again long time ago. So its complicated. In short: Python has provided 'distutils' in its standard library for long time, but that was quite limited, so setuptools appeared. For some it was not enough either, so it was forked and 'distribute' appeared. Soon, 'distribute' become the standard. In the meantime another project 'distutils2' was announced, which was to supersed both setuptools and distribute, but that didn't really happen. Instead, 'distribute' was merged back to 'setuptools' and 'setuptools' is what the world uses now. Also, pip is the blessed way of installing the modules now, see https://www.python.org/dev/peps/pep-0453/#abstract Some notes about setuptools https://www.python.org/dev/peps/pep-0453/#automatic-installation-of-setuptools [...] Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: texlive 2012
Does it make sense to have texlive.spec and texlive-texmf.spec? I understand that the latter deals with much larger source file, but then we have to deal with problems like the following - amstex.1 manual is provided by texlive.spec - amstex format and other files are provided by texlive-texml.spec Also, due to two spec files we create some artificial packages, i.e. - texlive-texmf.spec: texlive-latex-bibtex-data - texlive.spec: texlive-latex-bibtex - it requires the above, but you have to build texlive.spec first I would suggest to merge those two specs again. Bit more painful to build, but much simpler to maintain. Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
texlive-texmf bootstrap
Hi, What's the point of bootstrap in texlive-texmf? foiltex build? IMHO, foiltex should go to separate spec. This way we could simplify texlive-texmf.spec. Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
texlive 2012
Hi, What is the status of TexLive 2011 in the repo at the moment? Does it work at least a bit? TexLive 2012 is out - anything against to skip 2011 and move to 2012 directly? Regards, w ___ 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/14 Bartosz Taudul wolf@gmail.com: 2012/8/14 Artur Frysiak wi...@pld-linux.org: Zanim Bartek dostanie ponownie RW to myślę, że osoby które dają mu +1 powinny robić review jego kodu. Czyli mamy rozumieć, że sięgająca ponad rok historia podsyłanych patchy jest niewystarczającym probierzem? Nie. Masz po prostu przestac rznac glupa. Jedna osoba wczesniej zasugerowala, ze Bartek powinien wykazac sie konkretna inicjatywa. Druga wlasnie zaproponowala jak ta inicjatywa moglaby wygladac. Jak grochem o sciane. Jak widzisz ludzie ciagle sa dosyc otwarci. Zaproponuj z Bartkiem jakas formule wspolpracy i skonczmy z ta brazyliana. Tylko przestan udawac jakby nigdy nic sie nie stalo. [...] w ___ 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/15 Bartosz Taudul wolf@gmail.com: 2012/8/15 Artur Wroblewski wrob...@pld-linux.org: Czyli mamy rozumieć, że sięgająca ponad rok historia podsyłanych patchy jest niewystarczającym probierzem? Nie. To się określ czy 20 czy 30 lat wystarczy. Moze. Popracuj nad kompromisem skoro Ci tak zalezy... jesli nie, to przestan marnowac nasz czas. [...] w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
kernel 3.5.0 and initrd
Hi, When starting system using kernel 3.5.0, then I am getting something around BusyBox v1.19.3 (2012-01-13 00:33:55 CET) multi-call binary. Usage: mknod [-m MODE] NAME TYPE MAJOR MINOR Before that info that /dev/sda1 is missing and after some nice kernel oops. Sorry for such lame bug report, but maybe someone else has something similar? Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: kernel 3.5.0 and initrd
On Wed, Aug 1, 2012 at 8:50 PM, Elan Ruusamäe g...@pld-linux.org wrote: On 01/08/12 22:38, Artur Wroblewski wrote: On Wed, Aug 1, 2012 at 7:01 PM, Artur Wroblewskiwrob...@pld-linux.org wrote: Hi, When starting system using kernel 3.5.0, then I am getting something around BusyBox v1.19.3 (2012-01-13 00:33:55 CET) multi-call binary. Usage: mknod [-m MODE] NAME TYPE MAJOR MINOR Before that info that /dev/sda1 is missing and after some nice kernel oops. Sorry for such lame bug report, but maybe someone else has something similar? yes it's lame, start with geninitrd -v output when generating initrd # geninitrd -v -f /boot/initrd-3.5.0-1.gz 3.5.0-1 geninitrd: # $Revision: 12530 $ $Date:: 2012-03-30 14:41:13 + #$ (geninitrd) geninitrd: find_tool: found /usr/lib64/initrd/busybox geninitrd: find_tool: found /usr/lib64/initrd/cryptsetup geninitrd: find_tool: found /usr/lib64/initrd/lvm geninitrd: find_tool: found /usr/lib64/initrd/blkid geninitrd: find_tool: found /usr/lib64/initrd/udevd geninitrd: find_tool: found /usr/lib64/initrd/udevadm geninitrd: find_tool: found /usr/lib64/initrd/v86d geninitrd: Finding USB keyboard modules geninitrd: Finding SATA modules (class=0x0106) geninitrd: Using /dev/sda1 as device for rootfs geninitrd: Finding modules for device path /dev/sda1 geninitrd: is_luks: /dev/sda1 is not device mapper name geninitrd: Finding SCSI modules using scsi_hostadapter geninitrd: Building initrd... geninitrd: + cp /usr/lib64/initrd/busybox /root/tmp/initrd.SgpGRl/bin/busybox geninitrd: Loading module [scsi_mod] with options [scan=sync ] geninitrd: Loading module [libata] geninitrd: Loading module [libahci] geninitrd: Loading module [ahci] geninitrd: Loading module [crc-t10dif] geninitrd: Loading module [sd_mod] geninitrd: Loading module [scsi_wait_scan] geninitrd: Loading module [jbd] geninitrd: Loading module [mbcache] geninitrd: Loading module [ext3] geninitrd: Adding BLKID support to initrd geninitrd: + cp /usr/lib64/initrd/blkid /root/tmp/initrd.SgpGRl/bin/blkid geninitrd: Adding rootfs finding based on kernel cmdline root= option support. geninitrd: + cp /dev/sda1 /root/tmp/initrd.SgpGRl/dev/sda1 geninitrd: image size: 3072 KiB (/root/tmp/initrd.SgpGRl) geninitrd: Creating initramfs image /root/tmp/initrd.img-agk5Xc geninitrd: finding compressor: lzo gzip xz lzma bzip2 (via yes) geninitrd: Compressing /boot/initrd-3.5.0-1.gz with gzip w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: kernel 3.5.0 and initrd
On Wed, Aug 1, 2012 at 9:04 PM, Paweł Sikora pl...@agmk.net wrote: [...] try to install udev-initrd, set USE_UDEV=yes in /etc/sysconfig/geninitrd and regen initrd. that helped. thanks. w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
git - removing repository
Hi, How to remove repository? BTW. The HOWTO claims that ~/rpm/packages/builder shall be used to build a package, but this one tries to fetch spec files from CVS actually. Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git - removing repository
On Mon, Jul 30, 2012 at 7:05 PM, Lord Blick lordbl...@gmail.com wrote: In reply on message at 30.07.2012 20:02, from Artur Wroblewski: Hi, How to remove repository? http://www.pld-linux.org/dokuwiki/cvs2git http://www.pld-linux.org/dokuwiki/howto-git Nothing there. Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git - removing repository
On Mon, Jul 30, 2012 at 7:45 PM, Kacper Kornet drae...@pld-linux.org wrote: On Mon, Jul 30, 2012 at 07:29:50PM +0100, Artur Wroblewski wrote: On Mon, Jul 30, 2012 at 7:05 PM, Lord Blick lordbl...@gmail.com wrote: In reply on message at 30.07.2012 20:02, from Artur Wroblewski: Hi, How to remove repository? http://www.pld-linux.org/dokuwiki/cvs2git http://www.pld-linux.org/dokuwiki/howto-git In http://www.pld-linux.org/dokuwiki/cvs2git action delete package in the table. ok, thanks, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ipython and python 2.x
On Tue, Jul 24, 2012 at 8:15 AM, Jacek Konieczny jaj...@jajcus.net wrote: On Tue, Jul 24, 2012 at 12:47:01AM +0100, Artur Wroblewski wrote: I am planning to upgrade IPython to version 0.13, but for Python 3.x only. Python 2.7 is the last 2.x release (released over 2 years ago), so IMHO it is pointless to maintain two versions at the moment. There is still many software written in Python 2.7, there is still a lot of development made using Python 2.7, as some libraries are still only python2 and costs of porting some projects to python3 is too big to be worth it. And IPython is a python development tool. As long as we provide Python 2.7 package we should also provide ipython for it. It may be the last IPython version available upstream for Python2, but it should not be dropped all together just because Python 3.x is the current one. 1. Last change in the spec was in October 2011 (for version 0.11). 2. Between 0.11 and 0.13 releases there were two IPython versions - 0.12 and 0.12.1. IMHO, no one is interested in IPython for Python 2.x in our distro at the moment, so maintaining IPython for Python 2.x and 3.x is waste of time. If you still disagree I can put it into separate spec (ipython3.spec). Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ipython and python 2.x
On Tue, Jul 24, 2012 at 6:58 PM, Artur Wroblewski wrob...@pld-linux.org wrote: On Tue, Jul 24, 2012 at 8:15 AM, Jacek Konieczny jaj...@jajcus.net wrote: On Tue, Jul 24, 2012 at 12:47:01AM +0100, Artur Wroblewski wrote: I am planning to upgrade IPython to version 0.13, but for Python 3.x only. Python 2.7 is the last 2.x release (released over 2 years ago), so IMHO it is pointless to maintain two versions at the moment. There is still many software written in Python 2.7, there is still a lot of development made using Python 2.7, as some libraries are still only python2 and costs of porting some projects to python3 is too big to be worth it. And IPython is a python development tool. As long as we provide Python 2.7 package we should also provide ipython for it. It may be the last IPython version available upstream for Python2, but it should not be dropped all together just because Python 3.x is the current one. 1. Last change in the spec was in October 2011 (for version 0.11). 2. Between 0.11 and 0.13 releases there were two IPython versions - 0.12 and 0.12.1. IMHO, no one is interested in IPython for Python 2.x in our distro at the moment, so maintaining IPython for Python 2.x and 3.x is waste of time. If you still disagree I can put it into separate spec (ipython3.spec). We agreed off-line on creating ipython3.spec - and it is done. Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
ipython and python 2.x
Hi, I am planning to upgrade IPython to version 0.13, but for Python 3.x only. Python 2.7 is the last 2.x release (released over 2 years ago), so IMHO it is pointless to maintain two versions at the moment. About Python 2.8 un-release http://www.python.org/dev/peps/pep-0404/#un-release-schedule Any thoughts? Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe...
On Mon, Jul 9, 2012 at 9:50 PM, Jacek Konieczny jaj...@jajcus.net wrote: On Mon, Jul 09, 2012 at 10:05:10PM +0200, Lukasz Kies wrote: 2012/7/9 Elan Ruusamäe g...@pld-linux.org: in irc questions rise up, including those and i proposed: 1. https://github.com/pld-linux - mirror of git.pld-linux.org/packages Why we need mirror of our git in external system? Having the project in github may give us a lot of publicity. And github gives great tools for third parties to work with our repos (fork them, do work based on them). That may introduce some developers or patches. Can we do the same with bitbucket? [...] Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [PATCH] kernel-vanilla
On Thu, May 31, 2012 at 11:13 PM, Bartosz Świątek shad...@gmail.com wrote: 2012/5/31 Przemo Firszt prz...@firszt.eu: On Wed, 2012-05-30 at 22:54 +0200, Bartosz Świątek wrote: 2012/5/30 Przemo Firszt prz...@firszt.eu: The patch not finished (new config options), but it allows to build the vanilla kernel. So? What should be done with it now? Oh wait! I know! You should finish the patch, start your mails with a 'Hallo' and say nicely what you expect from the developers. Easy, right? Good luck! Let's make a nice flame out of this. I don't expect _anything_ from the developers. If my patch is useful apply it, if it's not ignore/comment back. I personally don't like people not saying anything and expecting everything [...] Szadzik, could you please stop trolling and shut up if you have nothing constructive to say (as it is for last couple of weeks)? Please? Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [PATCH] xorg-driver-input-wacom 0.13.0-0.15.0
applied, thanks regards, w ___ 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)
On Sat, Apr 21, 2012 at 10:14 AM, Tomasz Pala go...@polanet.pl wrote: On Fri, Apr 20, 2012 at 22:07:14 +0100, Artur Wroblewski wrote: I really really am confused now. You're pretending your side of the story is how it's always been done in PLD. It's really not. HEAD was always reserved for stable package releases. right... especially in Ra and Ac times... Ra and Ac was detached from HEAD when they were released (i.e. frozen). Th is not. You keep avoiding one simple answer: why don't you want to use DEVEL? This is the tag designated _exactly_ for this purpose. 1. DEVEL is for unstable versions - we are talking about RC. 2. the release announcement contains the following statement The changes in GIMP 2.8rc1 since 2.7.5 are mostly not user-visible. We merely updated the code to work with newer versions of GEGL and babl, fixed GFig rendering issues and used all the translation updates we got to the point. 3. it does not look like there are major issues with 2.8rc1. 4. on top of that, i have tested it with my workflows before sending the very first email proposing the merge on HEAD. 5. babl and gegl are on HEAD anyway. therefore, imho, it is worth _starting_ upgrading (but if you send it to builders, then it is your stupidity). i was quite often putting rc versions on HEAD (depending on a project progress). it was not a problem until now. it seems like some people want some more strict rules about th development - iron them out and propose them on this list. if not, then we are wasting each other time. regards, w ___ 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/21 Bartosz Świątek shad...@gmail.com: W dniu 21 kwietnia 2012 13:14 użytkownik Artur Wroblewski wrob...@pld-linux.org napisał: 2012/4/21 Bartosz Świątek shad...@gmail.com: [...] Stable is boring(tm). well, why you have switched from the Ac and jumped on the development distro line? you know, Ac was supposed to be the stable version with multiple releases until it got abandoned by people like you. i have proposed TH-STABLE tag. not enough for you? then create new stable line. it is simple like that. No. HEAD is your proposed TH-STABLE, and DEVEL is for alphas, betas and RCs ;) It's as simple as that. there is no direct mapping between th ready or th test and CVS HEAD. check by yourself. regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: authconfig/authconfig.spec - fix python packaging, now things exe...
On Fri, Apr 20, 2012 at 5:47 PM, Jacek Konieczny jaj...@jajcus.net wrote:
On Fri, Apr 20, 2012 at 06:40:53PM +0300, Elan Ruusamäe wrote:
it doesn't behave here so:
here it creates .pyc only for imported modules, if invoked via
#!/shebang, no .pyc is created for the script itself:
[...]
In case if %{_bindir} or %{_sbindir} - no script should be named *.py
there (actually there are some, but they should be fixed).
any explanation why (not that i have against)
The problem is, that if script name is something.py, then
if any other python script in the same directory does
'import something' (on purpose or because of a name collision) the
script will be compiled to pyc.
There should be no *.py files in %{_bindir}. If a script is supposed to
be importable, then it should be stored in %{py_sitescriptdir}, and only
a wrapper script should be kept in %{_bindir}.
The wrapper can be something like that:
#!/usr/bin/python
import something
somethig.run()
or
#!/bin/sh
exec /usr/bin/python -m something $@
Whatever the module expects.
python3.spec simply creates aliases in /etc/shrc.d.
regards,
w
___
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/20 Bartosz Świątek shad...@gmail.com: W dniu 20 kwietnia 2012 01:03 użytkownik Artur Wroblewski wrob...@pld-linux.org napisał: On Thu, Apr 19, 2012 at 9:44 PM, Caleb Maclennan ca...@pld-linux.org wrote: 2012/4/19 Artur Wroblewski wrob...@pld-linux.org: 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. Ac is stable release for which we have appropriate branch and Th is in constant development mode, isn't it? I am asking because I am bit lost with above arguments - do we have some new rules for Th? When they changed? :P You tell us. AFAIK official rules state that no Betas and RCs are allowed on HEAD and exceptions need to be discussed. I can't remember to have read any new rules lately that differ from what I just said, so if you know something more, please share it with us. I do not remember discussing such rule. But I remember that if a package on HEAD has non-integral release number (i.e. 0.1) then it means that the work is still in progress. To repeat myself cvs head != Th ftp. If you send it to the builders, then it is your fault. In general CVS != FTP, but as we all know the first step to get a package to main FTP is to put it on CVS HEAD. Putting there unstable versions is very confusing. The release number is not confusing, IMHO. Let me rephrase - is anyone planning any work related to Gimp 2.6 on CVS HEAD in near future? If not, then I will do the merge from DEVEL (but please let non-IRC people know if any rules changed regarding Th and what's the plan). That's not an argument. Noone's gonna know if for some reason Gimp 2.6 will need to be patched, fixed, rebuilt or our chief only knows what else. What's the problem with having an _unstable_ version on DEVEL anyway? What is so importand in this version to you so desperately need to put it on HEAD? The gegl and babl are stable now and they are on HEAD. IMHO, it is time to _start_ (as in CVS) migrating to gimp 2.8... until you know that there is something wrong with 2.6 and will need fixing soon (I assume no as there are ftp related arguments only so far)? Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
th stable (Re: gimp 2.8.0 rc1, gimp plugins)
On Fri, Apr 20, 2012 at 1:55 PM, Caleb Maclennan ca...@pld-linux.org wrote: 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. it seems this discussion would not happen if not the problem summarized above. 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? [...] regards, w ___ 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)
On Fri, Apr 20, 2012 at 7:57 PM, Caleb Maclennan ca...@pld-linux.org wrote: 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. it is very simple. th-stable, ac-stable or whatever... provide meaningful, self documenting names to things. you want to discuss strategy on CVS HEAD, then... well... you have few things to consider - in the past Ra or Ac could be on CVS HEAD, which one it should be back then? - now it could be Th... but why not Ti? - what about future if some other distro lines happen? again, meaningful tag names do not cause above problems. [...] w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
gimp 2.8.0 rc1, gimp plugins
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 ___ 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 Bartosz Świątek shad...@gmail.com: W dniu 19 kwietnia 2012 21:32 użytkownik Artur Wroblewski wrob...@pld-linux.org napisał: hi, i would like to move gimp 2.8.0 rc1 from DEVEL to HEAD. any argument against? Yes. New gegl and babl break API/ABI compatibility with earlier versions. Gimp 2.8 RC1 needs them. Also as statet on gimp.org, they need to fix some bugs and are looking for more bugs. That's always a release stoper. But I'm sure noone else will find these arguments critical and we will soon see more and more Alpha, Beta and RC version on HEAD and main ftp. I was asking to put it on HEAD. _Not_ to put it on ftp. Regards, w ___ 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
On Thu, Apr 19, 2012 at 9:44 PM, Caleb Maclennan ca...@pld-linux.org wrote: 2012/4/19 Artur Wroblewski wrob...@pld-linux.org: 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. Ac is stable release for which we have appropriate branch and Th is in constant development mode, isn't it? I am asking because I am bit lost with above arguments - do we have some new rules for Th? When they changed? :P To repeat myself cvs head != Th ftp. If you send it to the builders, then it is your fault. Let me rephrase - is anyone planning any work related to Gimp 2.6 on CVS HEAD in near future? If not, then I will do the merge from DEVEL (but please let non-IRC people know if any rules changed regarding Th and what's the plan). Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: babl/babl.spec - ver. 0.1.8 (nfy - builds without vala 0.16 and w...
On Wed, Apr 18, 2012 at 6:55 PM, Jakub Bogusz qbo...@pld-linux.org wrote: On Wed, Apr 18, 2012 at 02:06:26AM +0200, wrobell wrote: BuildRequires: autoconf = 2.54 BuildRequires: automake = 1:1.11 +BuildRequires: elfutils-devel Where did this come from? libtool: link: gcc -o /home/users/wrobell/rpm/BUILD/babl-0.1.10/babl/tmp-introspectUAe1Xd/.libs/Babl-0.1 /home/users/wrobell/rpm/BUILD/babl-0.1.10/babl/tmp-introspectUAe1Xd/Babl-0.1.o -pthread -Wl,--export-dynamic -Wl,--export-dynamic -L. ./.libs/libbabl-0.1.so -lm /usr/lib64/libgio-2.0.so -lz -lresolv /usr/lib64/libgobject-2.0.so /usr/lib64/libffi.so /usr/lib64/libgthread-2.0.so /usr/lib64/libgmodule-2.0.so -ldl /usr/lib64/libglib-2.0.so /usr/lib64/libpcre.so -lpthread -lrt -lelf -pthread /usr/bin/ld: cannot find -lelf Try: $ grep -r elf /usr/lib64/*.la Not sure where to add the dependency... glib2-devel? Regards, w Best regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: systemd summary/podsumowanie
On 27 Jan 2012 15:30, Elan Ruusamäe g...@pld-linux.org wrote: On 27.01.2012 15:26, Jan R�korajski wrote: Questions? Comments? what if i don't want systemd, i want legacy sysvinit/rc-scripts imho, systemd decision is similar to choosing xorg over old xfree86, texlive over tetex, udev over devfs and so on. you might have valid reasons to use old system, but benefits of new one are too good for too many people... maintaining two different approaches is pointless and waste of time. w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python weakestref
2011/8/13 Elan Ruusamäe g...@delfi.ee: no attention there, so maybe gets here https://bugs.launchpad.net/pld-linux/+bug/800148 yes, it should. best regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python weakestref
2011/8/14 Elan Ruusamäe g...@delfi.ee: On 08/14/2011 01:33 PM, Artur Wroblewski wrote: 2011/8/13 Elan Ruusamäeg...@delfi.ee: no attention there, so maybe gets here https://bugs.launchpad.net/pld-linux/+bug/800148 yes, it should. should what? ticket proposes (questions) several options, you can't anser to multiple conflicting questions with an answer yes. the first question :) :P purpose of python-libs is to run minimal python scripts (i.e. within gnumeric in the past). put weakestref in python-libs. regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: *.py packaging, again
On Thu, Jul 14, 2011 at 8:44 AM, Jacek Konieczny jaj...@jajcus.net wrote: [...] We lose: - a little bit of the disk space - some 'purity' some people see in not distributing 'sources' IMHO, it was not about purity but quite practical aspect of file distribution (src vs. bin) - we treated byte compiled files for Java and Python the same way, no src allowed. Now, Python's idea about byte compiled files evolved into different concept - cache files? Another game changer is pypy, of course. Few months ago we agreed on *.py distribution for Python 3.2 (IMHO, that implies we do not longer support 3.0 and 3.1 in python-*.spec). Lack of 3.2 in Th is matter of time and resources to recompile the packages, not __pycache__ problem. We should treat cpython and pypy as we would treat two compilers, which optimize code in different way. We will not build code with gcc and Intel compilers and put two versions of packages on ftp. IMHO, at the moment, we should settle on one Python compiler. Obvious choice is cpython, now. You want pypy - use its mechanism (hopefully it exists) to put compiled bytecode in temp directory (or whatever). [...] Best regards, Artur ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: *.py packaging, again
On Thu, Jul 14, 2011 at 8:26 PM, Jeff Johnson n3...@mac.com wrote: On Jul 14, 2011, at 2:31 PM, Artur Wroblewski wrote: On Thu, Jul 14, 2011 at 8:44 AM, Jacek Konieczny jaj...@jajcus.net wrote: [...] We lose: - a little bit of the disk space - some 'purity' some people see in not distributing 'sources' IMHO, it was not about purity but quite practical aspect of file distribution (src vs. bin) - we treated byte compiled files for Java and Python the same way, no src allowed. All depends on what you want to emphasize in the comparison. E.g. man pages are generated and cached and none is asking for support from RPM for handling ownership and integrity of the generated man pages. The ached aspects of __pycache__ aren't that different (but are executable so the audit is more complex than for data files). Sure. I just re-stated our approach we took in the past. Best regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python3.2+ compiled files
On Fri, May 20, 2011 at 11:34 AM, Jacek Konieczny jaj...@jajcus.net wrote: Maybe we should have some automation for packaging (or not packaging) __pycache__ and its contents? So it doesn't have to be listed explicitly for every python package. I am thinking about something like %find_lang – e.g. %find_pybytcode, or '%py_listmodules modul1e module2' %find_pymod mod1 mod2... ? it has to find egg files (on the same level as mod1 and mod2 exist), *.py, *.so and directories (it will get __pycache__ then too). Do I miss anything? regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python3.2+ compiled files
On Thu, May 19, 2011 at 6:08 PM, Artur Wroblewski wrob...@pld-linux.org wrote: [...] Anyway, if no one objects then I will finish packaging of Python 3.2 during the weekend using source files and __pycache__. Done. I have upgraded few packages, too. Some of them are not done in nice way (i.e. python3 vs. python2), but that has to wait few days, sorry. Best regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python3.2+ compiled files
On Sat, May 21, 2011 at 1:12 PM, Jacek Konieczny jaj...@jajcus.net wrote:
On Sat, May 21, 2011 at 12:22:04PM +0100, Artur Wroblewski wrote:
On Fri, May 20, 2011 at 11:34 AM, Jacek Konieczny jaj...@jajcus.net wrote:
Maybe we should have some automation for packaging (or not
packaging) __pycache__ and its contents? So it doesn't have to be listed
explicitly for every python package. I am thinking about something like
%find_lang – e.g. %find_pybytcode, or '%py_listmodules modul1e module2'
%find_pymod mod1 mod2... ?
it has to find egg files (on the same level as mod1 and mod2 exist), *.py,
*.so and directories (it will get __pycache__ then too).
Do I miss anything?
I don't think we want any directory found packaged. All python
modules/packages should be explicitely listed and only files
belonging to them for sure should be included. Only this way we can
notice things that should not go to %py_sitedir or new modules/packages
that we may want to package separately.
IMO
%find_pymod mod1 mod2
should include (by listing each file, wildcards below
just for my convenience)
%dir %{py_sitedir}/mod1
%dir %{py_sitedir}/mod1/submod1
%{py_sitedir}/mod1/*.py
%{py_sitedir}/mod1/__pycache__
%attr(...) %{py_sitedir}/mod1/*.so
%{py_sitedir}/mod1/submod1/*.py
%{py_sitedir}/mod1/submod1/__pycache__
%attr(...) %{py_sitedir}/mod1/submod1/*.so
but would skip
%{py_sitedir}/mod1/submod1/*.txt
%{py_sitedir}/mod1/submod1/test{,s}
%{py_sitedir}/mod1/adir # this directory contains no __init__.py
%{py_sitedir}/mod1/adir/somedata.file.txt
There is a problem with egg-info files then - they may not match exactly
the python module/package name.
If I reckon well, we never skipped any egg files.
Regards,
w
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python3.2+ compiled files
On Sat, Apr 2, 2011 at 7:11 PM, Jakub Bogusz qbo...@pld-linux.org wrote: [...] So we have to decide how to package python distribution (and possibly all python3 modules, if distutils use __pycache__ too) - there are two solutions: - package all modules in source form together with __pycache__ subdirectories - stick to old way - manually py_comp/py_ocomp all python files, package *.py[co] without using __pycache__ subdirectories Looking at PEP 3147 and looking around on the net it seems that some people should be happy that sourceless module distribution is still supported at all [1][2]. The Python devs even do not care so much about missing pyc/pyo files in __pycache__ dir [3]. It seems that we need to follow the crowd and include .py files as default. :/ Regards, w [1] http://www.python.org/dev/peps/pep-3147/#case-4-legacy-pyc-files-and-source-less-imports [2] http://sayspy.blogspot.com/2010/05/maintaining-backwards-compatibility.html [3] http://mail.python.org/pipermail/python-dev/2011-February/108110.html ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python3.2+ compiled files
There is also http://web.archiveorange.com/archive/v/jA6s9GD0sh2vKRhR2zat to study. We could also think about zipping of the modules later... Anyway, if no one objects then I will finish packaging of Python 3.2 during the weekend using source files and __pycache__. Is that OK? Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ssh: send/accept GIT_* env vars
On Thu, May 05, 2011 at 03:26:46PM +0300, Elan Ruusamäe wrote: On 04.05.2011 16:18, Kacper Kornet wrote: So if someone (glen?) can give good a good reason why the GIT_* variables are propagated in PLD it would be great. arekm already answered: To avoid a need to set all that on each remote system. On 04.05.2011 16:51, Artur Frysiak wrote: I think Send/AcceptEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL instead of GIT_* should be enough. I see no use case for setting other GIT_* for remote host. i'm fine with that (setting up author/commiter id was the goal) even perhaps: GIT_AUTHOR_* GIT_COMMITTER_* to support future extensions so what's next? svn, qmail? i mean... why it is distro wide and not in your local configuration? what about ssh'ing to different (i.e. corporate) environment? regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python3.2+ compiled files
2011/4/10 Jakub Bogusz qbo...@pld-linux.org:
On Sat, Apr 09, 2011 at 09:03:44PM +0200, Jan Rękorajski wrote:
On Sat, 09 Apr 2011, Elan Ruusamäe wrote:
as for the .py sources packaging, i'd move them to -debuginfo package so
the could be installed optionally
Are you aware that some python apps do runtime feature checking and
setting based od the presence of .py files? That those apps can't live
without them? python-numpy being an example.
Actually this one is a weak argument - detecting python modules by searching
some hardcoded (or, even worse, scanned throughout /usr/*/python*) file
paths instead of import availability is rather a hack.
Indeed, modules searching caused us problems in few cases, but patches
were always accepted by the authors of the offending software.
While speaking about rules, IMHO, we can treat such problems in exactly
the same way as autoconf/automake problems - we patch configure.{in,ac}
and Makefile.am not configure and Makefile files. More work for us in
first place, but better outcome in longer term for everyone.
Best regards,
w
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: th - package cleanup
2010/11/16 Elan Ruusamäe g...@pld-linux.org: [...] the following list of packages were removed from th-main (still available in th-obsolete) they were removed because the packages were renamed or some other reason why .spec does not exist in cvs HEAD as well, i would remove all gtk+/glib 1.x stuff if it is still there. regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
th@ppc
Hi all, Does anyone have a TH builder for PowerPC (more or less updated?) Best regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
2010/6/24 Jeff Johnson n3...@mac.com: On Jun 24, 2010, at 9:36 AM, Paweł Zuzelski wrote: On Thu, 24 Jun 2010, Jeff Johnson wrote: [...] Did Poland do well in South Africa? Not so bad, we have not lost any game yet. Lots of ties eh? ;-) No ties, it is just impossible for us to loose. :) Best regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: repcached
2010/5/6 Elan Ruusamäe g...@delfi.ee: hi there what you think about repcached http://repcached.lab.klab.org/ should we create new package, or just patch our memcached? have repcached guys ever proposed the patch to memcached authors and what was the outcome? as well, problem can be with newer versions of memcached and repcached not catching up, then you have to disable it from time to time or wait. regards, w ___ 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 Mon, Mar 29, 2010 at 3:05 PM, Caleb Maclennan ca...@pld-linux.org wrote: 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. Just don't be afraid to commit - there will be always someone, who will correct you - nothing wrong with that (just ignore rudeness, which may happen when someone has bad day ;). You may ask on the list or irc if not sure about some stuff. Best regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wed, Feb 3, 2010 at 11:02 AM, Marcin Krol h...@limanowa.net wrote:
So what are exact rules at the moment?
What if someone wants to create another branch of distro?
I'd like to know that too. When I've created Titanium I was keeping
separate branches on some specs. That was baad, because I wasn't merging
my changes/updates to HEAD.
But that's not our fault, is it? :)
So I started using %if %{pld_release}
macros instead and keeping my changes on HEAD. For over two years no one
had problems with that.
If I reckon well, I had problems with that, because such laziness
leads to situations
like we have now. It was discusses twice or something in the past.
My point is - in the past it was decided that distro branches are kept
on separate
branches and it worked in case of Ra, Ac and Th (aka nest)
Now, if you want new rules then please state them. Or we will end up
with mess on
HEAD.
Cheers,
w
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wed, Feb 3, 2010 at 11:51 AM, Marcin Krol h...@limanowa.net wrote: I'd like to know that too. When I've created Titanium I was keeping separate branches on some specs. That was baad, because I wasn't merging my changes/updates to HEAD. But that's not our fault, is it? :) Yes it is. Hawk working on Titanium and not merging his changes because of -ENOTIME - bad, some developers are unhappy that they must merge to HEAD themselves. So Hawk starts working on HEAD separating Titanium specific changes - also bad, some developers are unhappy that Titanium stuff is on HEAD despite its separated and doesn't affect Th at all. Well, until I had to clean up mess in some of the spec files and non-building packages. Not speaking about some stupid commit war around ac/ti/th/whatever changes, which would not happen if appropriate changes were kept on a branch. [...] My point is - in the past it was decided that distro branches are kept on separate branches and it worked in case of Ra, Ac and Th (aka nest) I'll be honest. Moving all specs to Titanium branch will mean death of my fork. I simply have no time to track each and every spec for changes to be merged or branch point to be moved. I don't have as much time as I had in the past to maintaint PLD. Thats my problem, I agree. Probably I missed some discussion on irc or pld-devel-pl... but what is exact purpose of Titanium? Why it started in first place? w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wed, Feb 3, 2010 at 2:19 PM, Tomasz Pala go...@polanet.pl wrote:
On Wed, Feb 03, 2010 at 12:33:58 +0100, Marcin Krol wrote:
Seems fine for me, but it will still be trashing HEAD for some people
I'm afraid. The only thing that will change is %if. Instead of
%if %{pld_release} == ti
[...]
we will have
%if %{with titanium}
No, you didn't understand. It's not supposed to be '--with titanium' but
'--with alternative_option_for_this_package', just like in iceweasel.
You mean system xulrunner, right?
w
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: JDK/JRE packaging
2009/12/31 Paweł Zuzelski z...@xatka.net:
Hello,
currently in PLD it is impossible to install few JDKs or JREs on
single system, because of files in %{_mandir} and %{_bindir}. All
the files in %{_bindir} are symlinks to some path containing JVM
vendor and version number (for example:
/usr/lib/jvm/java-sun-1.6.0.17).
If we create a new subpackage containing only these files, it will
be possible to install few JDKs/JREs and choose the default one by
installing apropriate symlinks subpackage. Other JDKs/JREs can be
accessed using JAVA_HOME env variable.
or drop idea of links and provide package which sets PATH and
JAVA_HOME in /etc/sh.d?
regards,
w
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
