[ANNOUNCEMENT] Bugzilla /dev/null, switching to launchpad.net
From now on bugs.pld-linux.org redirects to https://bugs.launchpad.net/pld-linux. Old bugzilla is available under, well, oldbugzilla.pld-linux.org with the only modification being that the 'add new bug' form redirects to the appropriate launchpad form, meaning it's not possible to add new bugs to the old bugzilla. Plan is for the migration to be a natural process without any forced bug db migration. Bugs already inside bugzilla are to be resolved there, unless they're some kind of uber important long-term bugs in which case ppl are free to manually close them in bugzilla and reopen in launchpad (with a url pointing to bugzilla where appropriate). For ppl still working on some already opened bugzilla bugs, should there be any problems, describe them inside this email thread. Rationale: Launchpad was chosen because (a) we don't have to maintain it, (b) we don't have to host it (backups, whatever), (c) we don't have to develop it and (d) it has some nice feature for upstream integration. Oh, just to make one thing clear -- launchpad has been in use by some developers for some time now and all of the current RM's either are for this switch or don't care either way. I really hope there are no bugzilla zealots or launchpad haters :) -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Packaging .py files
Hi, Following up on a Jabber discussion with arekm I'd like to start packaging .py files along with their bytecode counterparts. The reasoning: 1) It's much easier to find bugs in your own code (or the code you're packaging at the moment) when the libraries are available at hand (currently I'm forced to do `builder -bp python-foo`). 2) It's much easier to trace faulty applications when you can just copy the path from a traceback and open the file in vim (yes, yes, or emacs). 3) We'll no longer need to patch multiple applications that either use codegen.py (patches for this are all over the place) or use glob(*.py) to find their plugins. I'm not planning a mass commit or anything but I'll start packaging the sources instead of removing them when commiting from now on. Please no save the 1k of disk space arguments. -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
(moving to -en) On Wed, Jul 16, 2008 at 03:31:41PM +0200, Patryk Zawadzki wrote: On Wed, Jul 16, 2008 at 3:17 PM, Mateusz Korniak [EMAIL PROTECTED] wrote: On Wednesday 16 of July 2008, Patryk Zawadzki wrote: I'd like to start packaging .py files along with their bytecode counterparts. The reasoning: 1) It's much easier to find bugs in your own code (...) 2) It's much easier to trace faulty applications (...) 3) We'll no longer need to patch multiple applications that either use codegen.py (patches for this are all over the place) or use glob(*.py) to find their plugins. I'm not planning a mass commit or anything but I'll start packaging the sources instead of removing them when commiting from now on. Please no save the 1k of disk space arguments. We can pack *.py and *.pyo (instead of *.pyc *.pyo) archiving almost same and having save the 1k of disk space ;) Yeah, having .pyc files next to their optimized versions would be useless. That's false, replacing .pyc with .py is very bad idea. 1. .pyo files are used only when python is called with -O option. 2. if module .pyc file is not present, python (called without -O) attempts to write it - so using some python module with root privileges would create .pyc files not belonging to any package And when presenting your idea, use real numbers, not disdained 1k. I bet it's about 10-20MB on average system (depending on usage of some GNOME/KDE python applications or python frameworks like Twisted or Django). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Wed, Jul 16, 2008 at 6:49 PM, Jakub Bogusz [EMAIL PROTECTED] wrote: (moving to -en) On Wed, Jul 16, 2008 at 03:31:41PM +0200, Patryk Zawadzki wrote: On Wed, Jul 16, 2008 at 3:17 PM, Mateusz Korniak [EMAIL PROTECTED] wrote: On Wednesday 16 of July 2008, Patryk Zawadzki wrote: I'd like to start packaging .py files along with their bytecode counterparts. The reasoning: 1) It's much easier to find bugs in your own code (...) 2) It's much easier to trace faulty applications (...) 3) We'll no longer need to patch multiple applications that either use codegen.py (patches for this are all over the place) or use glob(*.py) to find their plugins. I'm not planning a mass commit or anything but I'll start packaging the sources instead of removing them when commiting from now on. Please no save the 1k of disk space arguments. We can pack *.py and *.pyo (instead of *.pyc *.pyo) archiving almost same and having save the 1k of disk space ;) Yeah, having .pyc files next to their optimized versions would be useless. That's false, replacing .pyc with .py is very bad idea. Then we can/should package them all. I don't want to fix correct code to look for .pyc files instead of .py (all packages using codegen). 1. .pyo files are used only when python is called with -O option. True, sorry but I'm in zombie state today due to weather changes (no, coffee does not help). 2. if module .pyc file is not present, python (called without -O) attempts to write it - so using some python module with root privileges would create .pyc files not belonging to any package Also true. And when presenting your idea, use real numbers, not disdained 1k. I bet it's about 10-20MB on average system (depending on usage of some GNOME/KDE python applications or python frameworks like Twisted or Django). On these systems 10MB is the same as 1k. -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Wednesday 16 of July 2008, 15:07, Patryk Zawadzki wrote: Hi, Following up on a Jabber discussion with arekm I'd like to start packaging .py files along with their bytecode counterparts. Then put them in separate packages, named python-FOO-src or sth like that. [...] -- Tomasz Wittner ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Wednesday 16 July 2008 16:07, Patryk Zawadzki wrote: Please no save the 1k of disk space arguments. can the packaging be automated like -debuginfo is right now? i'd vote for -pysource, -source names :) -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
vim-rt size (was Re: Packaging .py files)
On Wednesday 16 July 2008 19:57, Patryk Zawadzki wrote: On these systems 10MB is the same as 1k. can vim-rt files be compressed somehow? i know vim can read .gz files and write them, can it do same for help/ and syntax/ files i'm also thinking perhaps create -doc subpackage. as i have few systems where /usr is really small and can't be grown . (do not ask why), but i like vim, mostly due it's syntax hiliting feature. -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: vim-rt size (was Re: Packaging .py files)
On Wed, Jul 16, 2008 at 22:00:33 +0300, Elan Ruusamäe wrote: i'm also thinking perhaps create -doc subpackage. It's only 5MB... as i have few systems where /usr is really small and can't be grown . (do not ask why), but i like vim, mostly due it's syntax hiliting feature. Use excludedocs Luke. -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Wed, Jul 16, 2008 at 21:56:00 +0300, Elan Ruusamäe wrote: can the packaging be automated like -debuginfo is right now? i'd vote for -pysource, -source names :) +1 -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: vim-rt size (was Re: Packaging .py files)
On Wednesday 16 July 2008 23:07, Tomasz Pala wrote: as i have few systems where /usr is really small and can't be grown . (do not ask why), but i like vim, mostly due it's syntax hiliting feature. Use excludedocs Luke. /usr/share/vim/vim71/doc is not marked as %doc. it's not online help for vim application (F1 fires it) -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: vim-rt size (was Re: Packaging .py files)
On Wed, Jul 16, 2008 at 23:56:08 +0300, Elan Ruusamäe wrote:
Use excludedocs Luke.
/usr/share/vim/vim71/doc is not marked as %doc.
Isn't it?
~: du -sh /usr/share/vim/vim71/doc
280K/usr/share/vim/vim71/doc
%doc %{_datadir}/vim/v*/doc/*.txt
%lang(pl) %doc %{_datadir}/vim/v*/doc/*.plx
it's not online help for vim application (F1 fires it)
I know it is and I have never had it installed on my workstation.
--
Tomasz Pala [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Wed, Jul 16, 2008 at 23:07:38 +0200, Mariusz Mazur wrote: Over the years I've grown quite tired of a lot of cases where PLD tries to be I'm tired too but it is a must have for reliable system. smarter then upstream and/or other distros and does something completely insignificant differently which results in having to patch up perfectly working apps. These 'perfectly working apps' used to be security holes, functionality breakers etc. On the one hand I've got a lot of stuff to make my life easier (hey, vserver out of the box!) and on the other there are those little pesky oddities. If you don't value being The Right Way just use some FC, Debian, Ubuntu or other. Python packaging is one such case. That's one I don't care for much. (Others would be e.g. /bin/sh) Yeah, let's use fucked up bash. The next step would be to use FC spec files and simple package - * instead of file listings in subpackages. The end of this road is even much simplier - ./configure; make; make install. -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
Dnia czwartek, 17 lipca 2008, Tomasz Pala napisał: On Wed, Jul 16, 2008 at 23:07:38 +0200, Mariusz Mazur wrote: Over the years I've grown quite tired of a lot of cases where PLD tries to be I'm tired too but it is a must have for reliable system. It's not a reliable system when any application can fail because it either expects something that all of the other distros, except us, have (sh - bash) or we've done something to it without having much clue about original developers' reasons for a particular choice (ripping out internal versions of various libs). smarter then upstream and/or other distros and does something completely insignificant differently which results in having to patch up perfectly working apps. These 'perfectly working apps' used to be security holes, functionality breakers etc. If they in fact are, to the extent we're not as much of security zealots as, say, openbsd, it's obviously better to patch them. Both the python and /bin/sh cases don't fall under any of the above. Let's try to be specific. On the one hand I've got a lot of stuff to make my life easier (hey, vserver out of the box!) and on the other there are those little pesky oddities. If you don't value being The Right Way just use some FC, Debian, Ubuntu or other. PLD also has The Right Way, the Have It Just Work rule. Non-interactive rpm installations, sane and working out-of-the-box default configs, a lot of %post scripts to make sure everything's integrated, etc, etc. Going against de facto standards (/bin/sh) and actual standards (python -- I'm quite sure it's authors never meant for it to be distributed the way we do) both break the rule. (Others would be e.g. /bin/sh) Yeah, let's use fucked up bash. The next step would be to use FC spec files and simple package - * instead of file listings in subpackages. The end of this road is even much simplier - ./configure; make; make install. The only part where we actually prefer not to have bash is where our own (made in-house) scripts are concerned. All other scripts should be run with what their authors expected, and that's bash (the Have It Just Work rule). The solution is quite trivial -- have our scripts invoke pdksh directly and leave bash under /bin/sh. Bottom line is -- we're quite an invasive distro anyway, as far as patching apps goes, so it's in our best interest to get rid of those modifications that have no real life value and are only a pain in the ass. I'd urge the Th RM (well, Ti too ;) to Do The Right Thing wrt to both python and sh/bash. If it's really an unpopular decision, it'll get overruled in CDG. And if not, we'll have a few less quirks to irritate us. -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Thu, Jul 17, 2008 at 12:30:40AM +0200, Mariusz Mazur wrote: It's not a reliable system when any application can fail because it either expects something that all of the other distros, except us, have (sh - bash) Yes, condoning bad code practices is the way to go. Go install your ubuntu. or we've done something to it without having much clue about original developers' reasons for a particular choice (ripping out internal versions of various libs). Half the time the original developers don't have a clue, so your argument fails. (python -- I'm quite sure it's authors never meant for it to be distributed the way we do) The more I know about python the more I am assured it's a joke language. The only part where we actually prefer not to have bash is where our own (made You and who else? in-house) scripts are concerned. All other scripts should be run with what their authors expected, and that's bash (the Have It Just Work rule). The Bullshit. The scripts that expect bash have #!/bin/bash in header, not #!/bin/sh. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
Dnia czwartek, 17 lipca 2008, Bartosz Taudul napisał: Yes, condoning bad code practices is the way to go. Go install your ubuntu. It's bad in theory. In practice, for the past mny years nobody gives a shit about theory in case of /bin/sh. So that's top score for theory and a FAIL on the reality check. or we've done something to it without having much clue about original developers' reasons for a particular choice (ripping out internal versions of various libs). Half the time the original developers don't have a clue, so your argument fails. Then fix upstream. You have no idea whether they do or don't have a clue if you don't ask first. I'd rather default to assuming that the guys who wrote the stuff know better than Joe Random Developer does. I'm actually *using* their code, so I kind of assume they have some kind of clue. (python -- I'm quite sure it's authors never meant for it to be distributed the way we do) The more I know about python the more I am assured it's a joke language. That's not an argument. Anything more on point you'd like to add wrt to the python discussion? The only part where we actually prefer not to have bash is where our own (made in-house) scripts are concerned. You and who else? And concerning the point of that sentence? Anything you'd like to say? Maybe that it's false or sth? With some specific reasons as to why? All other scripts should be run with what their authors expected, and that's bash (the Have It Just Work rule). The Bullshit. The scripts that expect bash have #!/bin/bash in header, not #!/bin/sh. That's true only for the scripts whose authors (a) know there are distros that don't use bash as sh and (b) give a shit. That's a minority. Doing it 'our way' is simply pointless (what exactly do we gain?). -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Jul 16, 2008, at 6:14 PM, Mariusz Mazur wrote: All other scripts should be run with what their authors expected, and that's bash (the Have It Just Work rule). The Bullshit. The scripts that expect bash have #!/bin/bash in header, not #!/bin/sh. That's true only for the scripts whose authors (a) know there are distros that don't use bash as sh and (b) give a shit. That's a minority. Doing it 'our way' is simply pointless (what exactly do we gain?). I prefer to use software written by people who Give A Shit. Aria Stewart [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
