Re: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for...
Cezary Krzyzanowski wrote: > 1. I use vim to develop python code and the bindings are good. > 2. I got some plugins from vim.org that assist. I've got so many of them > I actually am afraid to try packaging them for PLD as I'm not sure I'll > recognize now all the plugins in my ~/.vim dir. Are there really using the Python bindings or just manage Python code using the built-in language? (I think the latter is more likely) -- regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Thank you geninitrd for screwing my evening
Patryk Zawadzki wrote: > - geninitrd generates initromfs images by default (why isbeyond my > imagination, I can only think about bootsplash bling bling here) Why should it not? -- regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
SoC 2006
Djurban said it has been different last year but it seems (according to the FAQ) that the mentor of a SoC 2006 project can be a company or even private person. Maybe we should consider applying? Long story short: $4500 for the participating student + $500 for the mentor organization (or for the mentor himself) for a OpenSource project finished by 1st September 2006. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: udev
Jan Rekorajski napisał(a): > On Thu, 05 Jan 2006, Fryderyk Dziarmagowski wrote: > >> --- Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote: >> >>>> is the hotplug issue by any chance related to the fact that after booting >>>> i >>>> got on screen message "starting udev" and it stays there forever stopping >>>> maching bootup. can't even kill it with SAK. >>> Shouldn't but who knows... >>> There was a solution mentioned on pld-users-pl consisting on changing >>> the udev start command from rc-scripts with a less complicated one (I >>> don't quite remember the details now). >> the trick was: >> replacing >> [ -x /sbin/start_udev ] && run_cmd "Starting udev" /sbin/start_udev >> with >> /sbin/start_udev >> in /etc/rc.d/rc.sysinit > > Does not work for me :( > Staring udev always hangs my laptop when started on battery and > sometimes with power supply. Could you try to do some straces? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: udev
Fryderyk Dziarmagowski napisał(a): > --- Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote: > >>> is the hotplug issue by any chance related to the fact that after booting i >>> got on screen message "starting udev" and it stays there forever stopping >>> maching bootup. can't even kill it with SAK. >> Shouldn't but who knows... >> There was a solution mentioned on pld-users-pl consisting on changing >> the udev start command from rc-scripts with a less complicated one (I >> don't quite remember the details now). > > the trick was: > replacing > [ -x /sbin/start_udev ] && run_cmd "Starting udev" /sbin/start_udev > with > /sbin/start_udev > in /etc/rc.d/rc.sysinit And what's the real difference between this two? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: udev
havner napisał(a): > On Wed, Jan 04, 2006 at 12:43:33PM +0100, Fryderyk Dziarmagowski wrote: >> On Wed, 4 Jan 2006 11:52:15 +0100 >> havner <[EMAIL PROTECTED]> wrote: >> >>> Revision 1.137 2005/11/16 15:35:22 freetz >>> - removed hotplug symlink (it can't be done this way until /sbin/hotplug >>> is >>> a default kernel hotplug handler), added cleaned up hotplug_map.rules >>> (instead of creating it with script at build time), rel.1 >>> >>> So how should it be done? Cause now we end up with a booted system: >>> >>> $ sudo sysctl kernel.hotplug >>> kernel.hotplug = /sbin/hotplug >>> $ ls -l /sbin/hotplug >>> ls: /sbin/hotplug: No such file or directory >>> >>> /sbin/udev_start sets this to /sbin/udevsend but rc-scripts set it back >>> to hotplug. I dont care how it will be done (maybe remove it from >>> rc-scripts) but for now it cant stay this way. What was wrong in this >>> symlink? Cause i dont really get the "it can't be done this way until >>> /sbin/hotplug is a default kernel hotplug handler". Why? This package is >>> PLD specific and our rc-scripts set this to /sbin/hotplug so for us its >>> default. >> Symlink was wrong because was called after / is mounted and before udev >> was ready to start. That was leading to propagating device nodes on >> readonly filesystem. > > Was called by what? Existance of a file means its executed? I dont get > something here. And why this does not affect hotplug package itself > where /sbin/hotplug exists and /dev/ is on ro filesystem for whole > sysinit phase (no tmpfs) Because hotplug wasn't creating any device nodes? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: udev
Elan Ruusamäe napisał(a): > is the hotplug issue by any chance related to the fact that after booting i > got on screen message "starting udev" and it stays there forever stopping > maching bootup. can't even kill it with SAK. Shouldn't but who knows... There was a solution mentioned on pld-users-pl consisting on changing the udev start command from rc-scripts with a less complicated one (I don't quite remember the details now). > usually (happened before too), i boot with init=/bin/sh and run 'start_udev&' > once from commandline. and after that start udev hung dissapears. I found that it ,,just works'' sometimes (it seemed to vary across defferent computers; sometimes it worked more often then not and sometimes it was the other way around) > but today this trick didn't work because i couldn't send any input to started > shell!!!, i guess this is because my /dev is empty and no udev started. Your dev should not be empty (there are at least static /dev/null and /dev/console from the udev rpm package) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: udev
havner napisał(a): > Revision 1.137 2005/11/16 15:35:22 freetz > - removed hotplug symlink (it can't be done this way until /sbin/hotplug > is > a default kernel hotplug handler), added cleaned up hotplug_map.rules > (instead of creating it with script at build time), rel.1 > > So how should it be done? Cause now we end up with a booted system: > > $ sudo sysctl kernel.hotplug > kernel.hotplug = /sbin/hotplug > $ ls -l /sbin/hotplug > ls: /sbin/hotplug: No such file or directory > > /sbin/udev_start sets this to /sbin/udevsend but rc-scripts set it back > to hotplug. I dont care how it will be done (maybe remove it from > rc-scripts) but for now it cant stay this way. Set this conditionally in rc-scripts based on the existence of /sbin/hotplug. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
Tomasz Pala napisał(a): > On Fri, Dec 23, 2005 at 13:54:01 +0100, Jakub Piotr Cłapa wrote: > >> We have because some of them depend on others. OTOH Samba, Squid, Apache >> and DHCPd rarely depend on each other. ;] > > So we can give them the same priority and introduce feature from patrys' > blog: run everything with the same prio parallel. It MUCH more easier > transition as we only need some piece of forking code. But he also proposed automatic generation of priorities (to relieve the pain of guessing the proper magic numbers from developers). Configurable daemon supervising is IMHO a good thing on its own. We could probably also look at Apple's launchd for a (according to what I've heard) completely new look at running all kinds of processes (it includes some kind of cron and init replacement). ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
Tomasz Pala napisał(a): > On Tue, Dec 13, 2005 at 18:14:48 +0100, Jakub Piotr Cłapa wrote: > >> boost from concurrency since most programs/daemons don't depend on each >> other and don't need to wait for others to start first. > > If they don't depend, why do we have priorities in current init scripts? > If we abandon priorities, we must introduce dependencies. We have because some of them depend on others. OTOH Samba, Squid, Apache and DHCPd rarely depend on each other. ;] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
I have a suggestion: Lets stop feeding the troll. -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
[EMAIL PROTECTED] wrote: > Dnia Mon, 12 Dec 2005 15:13:06 +0100, Tomasz Pala <[EMAIL PROTECTED]> > napisał: > >>> Maybe you need just to have a choice ? >> Exactly. >> > Choice means maintaining two stes of init scripts. Nope. The current init scripts could be modified to expose all the needed functionality and their startup could be even created according to the dependency database. The current init scripts' sequence numbers would be simply autogenerated. It's all about extending them and making them more powerful. Read more about Patrys' proposal for new init process. It's all there. > The alternative to this is the workground made now - that the initng > doesn't start services/daemons dirrectely, but runnes old inint scripts, > but that sounds lame ;/ It surely does but that's the immediate stage. -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
[EMAIL PROTECTED] wrote: > Dnia Sun, 11 Dec 2005 19:56:55 +0100, Tomasz Pala <[EMAIL PROTECTED]> > napisał: > >> Anyway I simply do not believe, that >> it's 'proven' to be two times faster, especially when speaking of >> machines which have some real load. > > I'm testing it right now on my laptop( yea - it doesn't have this much > load, but it runnes few server-like daemons, like apache and mysql + pgsql > ). The boot speeds up *really*! X starts in like < 10sec from powering on > the laptop! > > The problem is with tracing what runns and what doesn't. Since all starts > parallel, there is a lot of output and things start in different places, > sometimes between of other msgs. There is need for something more graphical and/or interactive than classical boot messages stream. Maybe an ncurses interface allowing the admin to browse the save logs from various daemon and showing which are already up, which failed and what is currently running. This architecture will allow also fancy graphical bootup trees showing the startup (it will rock even more than Windows blue floating bar at the bottom of the screen ;) and whats more important (but contains less hype) would allow easy browsing of these logs with a GUI or web interface (including checking what is running and what can but turned on/off) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
Tomasz Pala wrote: > On Tue, Dec 13, 2005 at 02:55:35PM +0100, [EMAIL PROTECTED] wrote: >> I'm testing it right now on my laptop( yea - it doesn't have this much >> load, but it runnes few server-like daemons, like apache and mysql + pgsql >> ). The boot speeds up *really*! X starts in like < 10sec from powering on >> the laptop! > > I had already written that it can be nice feature on desktops. But when > your system becomes operational? Means working services - that's what > customers may be interested with. Faster because many things are taking place at the same time. The boot process is probably a best example of a process which can get tremendous boost from concurrency since most programs/daemons don't depend on each other and don't need to wait for others to start first. >> trinary > more. Why? Example: I've forgot to connect my pen and mount >> outputed an error, which resulted in failure of running the mounting init >> script, which stopped > 50% of the system from running, which is insane! > > Hiehheiehe, I knew it;) No comments. -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
Tomasz Pala wrote: > On Mon, Dec 12, 2005 at 22:48:45 +0100, Jakub Piotr Cłapa wrote: > >> http://initng.thinktux.net/index.php/Boot_charts_Official >> >> First check, than argue. > > With pleasure. Just tell me what to install and I will do it on one of > my backup systems. I've tried once to make it run on PLD but failed to get the expected results. I don't quite remember why... All I know is that I've abandoned this... You could give it a try: bootchart.org >> remain simillar. The simplest reason I can think of (there are other >> too) is that there are deamons whose startup is CPU bound (Apache? > > I'm aware of the reason and don't think I'll profit much. There are still some that will just sit there and wait for sth. stupid before starting. (and you can't start two of these at a time now) > Well, unless we're talking about 486 and floppy... Not everybody has RAID with ultra fast SCSI discs, dual core 64bit processors and 8GB of RAM in every server. ;] -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
Andrzej Krzysztofowicz wrote: > =?UTF-8?B?TWFyY2luIEtyw7Ns?= wrote: >>> I can't see what's >>> bothering ppl bout dying ac and th. Windows 98 and 95 and ME died as well, >>> other distros also make new versions and move on forward. >> For me personally if we will switch to "awlays in developement" distro >> it would be easier to: >> >> 1) Maintain my machines, by simply doing poldek --upgrade-dist out of >> stable tree. Occasionally there will be need to do some manual upgrades >> like from postgres 8.0 to 8.1 which requires database dump/restore. Now > > But if you leave one machine not upgraded, after some time it may become > not upgradeable. Because of missing triggers, package splits, missing > obsoletes, etc. Maybe there is need for a better package update system (some kind of incremental triggers that would support upgrades from almost every version)? The restrictions on adding a new version to the main tree could also become more strict just like they were on man pages in the early UNIX days. You don't add a good migration banner/script/readme[1] <=> you won't get the new version to the main tree. [1] This would also allow notes with changelogs and general information passed from packager for the admin. Splitting this (together with %descriptions and maybe installation time scripts) from main package building to some kind of database that could be modified without rebuilding the package could also be worthy but would require deep rpmbuild changes. (I'm not totally convinced about this one) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
Tomasz Pala wrote: > On Sun, Dec 11, 2005 at 21:29:59 +0100, [EMAIL PROTECTED] wrote: > >> These two alternatives are where we should search for a way out. Or we >> hold an enviroment to build patches and so on (the question is how long >> and how many steps back). >> >> The '???' alternative sound great - but we have to invet it :> > > It already is - distro lines. But it doesn't really work. Ra is stable but hopelessly old. Ac is newer but not stable. The releasing process is painful. We can have ready and test. Ready could be then used for bug-fixes and critical updates before the whole new environment is complete. This way we could have a constantly current distro with snapshots that are retrospectively tagged as stable (with ISO releases and FTP directories) and can be used on servers and with updates that apply almost without a problem (comparing to what we have with Ra->Ac migration) because all the developers would try to make them better (contrary to the current state, when all developers are using Ac or Th and almost none of them are bothered by Ra update). The true idea behind this whole proposal is to sanction the process that's already taking place in Ac. To stop thinking about the release and focus on making infrastructure and architectural changes [1] to ease the continuous development process that is already a taking place. It won't solve all our problems and double the effect halving the required effort at the same time but I think it could work better than the current scheme. It would also make PLD different from other distros giving more stress on the constantly up-to-date aspect of it. No one have ever proved that this is a bad idea and what's more nobody I am aware of event tried it so maybe it's worth trying. [1] - FTP revisions and their tagging (so you can always downgrade or simply use an older version until you gain confidence that newer is better) - giving developers more access to the builders (as was proposed by mmazur for Th) - adding things like automatic* filesystem snapshooting based on UnionFS allowing you to reverse all changes done to a filesystem (or a part of it) to fix after broken upgrades * it could be triggered automatically by poldek (configurable) or manually before large administration changes -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
Tomasz Pala wrote: > On Sun, Dec 11, 2005 at 18:56:28 +0100, Jacek Konieczny wrote: > >> Irrevelant? My customers _do_ care if a maintenance break (e.g. reboot >> during kernel upgrate) lasts 5 or 10 minutes. > > If so, why don't you use some HA? Anyway I simply do not believe, that > it's 'proven' to be two times faster, especially when speaking of > machines which have some real load. http://initng.thinktux.net/index.php/Boot_charts_Official First check, than argue. Of course it can be different for a server but the ratio will probably remain simillar. The simplest reason I can think of (there are other too) is that there are deamons whose startup is CPU bound (Apache? Samba?) and I/O bound (most of them probably... I know about CUPS which starts without any disc activity and probably also no CPU usage I guess it just waits for printers enumeration). -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
Tomasz Pala wrote: > On Sun, Dec 11, 2005 at 16:10:19 +0100, Jakub Piotr Cłapa wrote: > >> The startup time with init-ng is proved to be less than a half compared >> to plain SysVinit. > > With 3-6 months uptimes it's irrevelant if restart due to new kernel > takes 5 or 10 minutes. > > My conclusion coming from this discussion is that's desktop solution, > not server one. Am I right? It's certainly more useful on a desktop but should not break anything (if done right) on a server. Our target is to have rc-scripts that can work in either solutuion. (so just like plain old SysVinit does or using some new stuff) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
Tomasz Pala wrote: > On Sun, Dec 11, 2005 at 08:52:36 -0500, Andrew A. Gill wrote: > >> That's a very ugly solution. I haven't been following this >> init.d discussion too closely, but what you're proposing is >> ugly. > > Daemons shouldn't die and they don't without any reason. I've got only > one broken - ospf, if you have more you should revise system > configuration and hardware. > Generally speaking there's no common need for watching over services, > thus I don't see much interest in switching startup scripts. NMB dies when it runs out of network interfaces. That's stupid but is considered a feature by samba developers... Supervising daemons could allow creating an easy GUI control panel for them, informing the admin about problems. The startup time with init-ng is proved to be less than a half compared to plain SysVinit. -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
Denis Ovsienko wrote: > Hi > I have a working 2.0 installed. How can I switch it to 3.0 to continue > learning ways to incorporate /etc/net into PLD? That would probably require some hacking. You could try to install Th from scratch into a chroot on another partition and than try to boot from it. It should be more secure than installing from scratch. -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ANN: Closing AC
[EMAIL PROTECTED] wrote: > Dnia Sat, 10 Dec 2005 22:34:31 +0100, Adam Gołębiowski > <[EMAIL PROTECTED]> napisał: > >> In case you didn't notice, NEST was disbaned some time ago. >> > > In deed I didn't - so it was? Didn't know that - sry > > Nevertheless don't make a second NEST out of TH!? NEST was something different from what was proposed for Th. -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: geany.spec (NEW) - added
Kamil Kosiński wrote: > On Mon, 21 Nov 2005 07:35:56 +0100 > Kamil Kosiński <[EMAIL PROTECTED]> wrote: > >> On Mon, 21 Nov 2005 06:52:12 +0100 >> aredridel <[EMAIL PROTECTED]> wrote: >> >> NFY >> >> 1. adapter >> 2. cleanups >> 3. s/GTK/GTK+2 >> 4. read configure.in, there are more deps ! >> 5. fix desktop file (Categories , s/GTK/GTK+2) >> 6. unpackaged files > > ...as always, somebody else did your job. And what's the problem? I'm afraid that if it doesn't bother her (she might not use the menu at all just like me) it's not her responsibility to fix it. It's always good work to commit a spec (even quite a raw one) because it's easier to work with something that's already there than to start from scratch. -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: ipw2100.spec - 1.1.3 - what about ieee80211 ?
areq wrote: > Author: areq Date: Sun Nov 13 21:46:07 2005 GMT > Module: SPECS Tag: HEAD > Log message: > - 1.1.3 > - what about ieee80211 ? Separate spec and package. (already in CVS as kernel-net-ieee80211 AFAIR) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: Mesa.spec - add glut - take libGL from the DRI build (I gue...
Jakub Bogusz wrote: > On Fri, Oct 21, 2005 at 03:01:42AM +0200, jpc wrote: >> Author: jpc Date: Fri Oct 21 01:01:42 2005 GMT >> Module: SPECS Tag: HEAD >> Log message: >> - add glut > > Is it better than this built from glut.spec? > glut is rarely used, so there is no need to include it in base package > with GL libs. I'll check but probably not. It is used by ./glxgears and that's the reason I've added it in the first place. I'll fix this. -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: xorg-app-x11perf.spec - removed outdated man patch, fixed a...
Jakub Bogusz wrote:
> On Fri, Oct 21, 2005 at 11:47:38AM +0200, Jakub Piotr Cłapa wrote:
>> qboosh wrote:
>>> Author: qboosh Date: Fri Oct 21 05:56:58 2005 GMT
>>> Module: SPECS Tag: HEAD
>>> Log message:
>>> - removed outdated man patch, fixed appmandir
>> And what's the difference between 1x and 1? (why all X packages use ?x
>> by default?)
>
> We don't (and never did) have %{_mandir}/man?x dirs.
> And they are not present in man.config.
That's what I thought. Maybe it would be a good idea to add them?
--
Regards,
Jakub Piotr Cłapa
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: xorg-app-x11perf.spec - removed outdated man patch, fixed a...
qboosh wrote: > Author: qboosh Date: Fri Oct 21 05:56:58 2005 GMT > Module: SPECS Tag: HEAD > Log message: > - removed outdated man patch, fixed appmandir And what's the difference between 1x and 1? (why all X packages use ?x by default?) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: Mesa.spec - add glut - take libGL from the DRI build (I gue...
jpc wrote: > - take libGL from the DRI build (I guess this could make a difference > but I can't get anything more than software rendering and no output > from LIBGL_DEBUG=verbose) Help? I'm totally confused with this thing. Anybody has some more insight into how Mesa DRI+libGL should be built? -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
X.org modular tree and XFree86-devel dependencies
We have to switch to modular X in Th but probably won't do so in Ac. Now, what do we do with dependencies? I would suggest switching to modular ones (and giving proper P: in X11.spec) everywhere (also in Ac). -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: kernel-extra-go7007.spec - port hotplug usermap to the new ...
jpc wrote: > Author: jpc Date: Wed Oct 19 00:02:54 2005 GMT > Module: SPECS Tag: HEAD > Log message: > - port hotplug usermap to the new udev based mechanism > - rel 3 && STBR Może ktoś mógłby puścić do Ac? (działa zarówno ze starym hotplugiem, jak i z udevem) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: udev.spec - add a helper script from Mandriva (does it need...
jpc wrote:
> +# from Mandriva CVS:
> +#
> http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/udev/udev_import_usermap?rev=1.5
> +Source7: udev_import_usermap
This can be useful when one wants to port some legacy hotplug usermaps
to udev rules painlessly. Maybe it shouldn't be installed even?
> +# Needed for the automatic module loading w/o hotplug to work
> +# see:
> +# http://qa.mandrivalinux.com/twiki/bin/view/Main/Udev
> +# http://lwn.net/Articles/123932/
> +Source8: %{name}-modprobe.rules
It works for me (should be coldplug capable too upon call to udevstart).
Do we switch to this stuff (and add O: hotplug?)
Needs kernel.hotplug=/sbin/udevsend
> @@ -217,6 +227,7 @@
> %config(noreplace) %verify(not size mtime md5) %{_sysconfdir}/udev/udev.conf
> %config(noreplace) %verify(not size mtime md5)
> %{_sysconfdir}/udev/rules.d/50-udev.rules
> %config(noreplace) %verify(not size mtime md5)
> %{_sysconfdir}/udev/rules.d/999-firmware.rules
> +%config(noreplace) %verify(not size mtime md5)
> %{_sysconfdir}/udev/rules.d/999-modprobe.rules
> %config(noreplace) %verify(not size mtime md5) %{_sysconfdir}/scsi_id.config
Why are these files noreplace? The sysadmin can override this with his
own rules by adding his own files with smaller numbers. (while still
allowing upstream updates)
--
Regards,
Jakub Piotr Cłapa
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: ipw2200.spec - addd a patch fixing dhcpcd broadcasts
jpc wrote: > Author: jpc Date: Fri Sep 16 13:04:38 2005 GMT > Module: SPECS Tag: HEAD > Log message: > - addd a patch fixing dhcpcd broadcasts If someone could confirm that it works on kernels < 2.6.13 (I guess it should) then I STBR (after doing an rel up). -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
[RFC] /usr/src/linux dir naming
I think this dirs should be named using %{version}-%{release} just like
the modules one currently are.
This way we can put things into /usr/src/linux/include/
(%{_kernelsrcdir} won't work here, because the files will vanish without
notice with the kernel upgrade)
--
Regards,
Jakub Piotr Cłapa
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn...
Tomasz Pala wrote: > On Sun, Sep 11, 2005 at 12:33:55 +0200, Jakub Piotr Cłapa wrote: > >>You can use zsh clever autocompletion in our SPECS/? > > Yes. > > ~/rpm/SPECS: cvs ci [tab] > modified file > aptitude.spec lefthand-platform.spec mc-mp.spec sbcl.spec > w32codec.spec > dpkg.spec man.spec mutt.spec vice.spec > wv2.spec > giFT.spec maxima.specrpm.spec vim.spec > It was way too slow on my machine (maybe I'll give it another try now). -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn...
Paweł Sakowski wrote:
> On Fri, 2005-09-09 at 09:40 +0100, wrobell wrote:
>
>>[svn log] -> few days please.
>
> While we're at revolutionary ideas...
>
> Currently %changelog doesn't really correspond to the CVS commit log. It
> is subject to truncation, editing (adding CAN entries, fixing typos,
> rewording). Furthermore, at some points it (here both changelog and
> commit log) simply restates the change made ("added BR foo-devel"), at
> others it has nothing to do with the change made ("rel 3. Nothing really
> changed in this spec, but that other patch got really improved"). Some
> places it just adds useless noise to the spec ("trying to do foo",
> "another attempt to do foo", "foo won't work anyway, reverting last 2
> commits") or just document flame wars ("last commit was issued by an
> idiot").
>
> So, the crazy idea is to give up automatic %changelog generation and
> treat it more like a NEWS file (i.e. document important changes, not
> each invidual commit). I would imagine that a new %changelog entry would
> be added for each new release and state the reason that the new release
> is a Good Thing, rather than document each change (nobody really cares
> about "spaces->tabs"). Note: it's just a gut feeling that this is the
> kind of information that people reading the %changelog are actually
> looking for. I myself am not sure what exactly I need from the
> changelog, and it's important that a changelog isn't manually writter
> Ars Gratia Artis, but it actually brings useful information to the
> developers. If it turns out that the commit logs bear close resemblance
> to the information useful to the developers, the above idea is obviously
> pointless (I'm not that evil to make people write the same thing twice
> in the {commit ,%change}log).
IMHO developers need this info mostly on the pld-cvs list and not in the
spec file. (and certainly not in the binary RPM) svn log -r1:HEAD gives
a really nice changelog (together with the changes in the patches).
--
Regards,
Jakub Piotr Cłapa
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
Jan Rekorajski wrote: > On Sat, 10 Sep 2005, Arkadiusz Miskiewicz wrote: > >>On Saturday 10 of September 2005 12:48, Jan Rekorajski wrote: >> >>>On Fri, 09 Sep 2005, Arkadiusz Miskiewicz wrote: >>> >>>>svn: see how creating diff between release and branch of kdebase package >>>>is: svn diff svn://anonsvn.kde.org/home/kde/tags/KDE/3.4.2/kdebase \ >>>>svn://anonsvn.kde.org/home/kde/branches/KDE/3.4/kdebase \ >>>> >>>>>kdebase-branch.diff >>>> >>>>_without_ having anything beside svn client locally >>> >>>Side note about command line - it's what pisses me the most in svn, the >>>requirement to type whole long URLs. I don't need to know them, it's the >>>scm job to remember root dir for a repository/module. >> >>svn remembers the urls in the same way as cvs. >> >>mkdir /tmp/whatever; cd /tmp/whatever; cvs up -r TAG file >>won't work. you still need to specify whole >>-d:pserver:[EMAIL PROTECTED]:/somethingelse > > I think you didn't get my point. With cvs I do cvs up once and then > I have ':pserver:[EMAIL PROTECTED]:/somethingelse' in CVS/Root > and I don't have to specify it anymore. With svn every time I want some > tag/branch I must specify the whole URL for that tag or branch. > Any svn command that has something to do with tag/branch requires URLs. > No such requirement with cvs. > > What's interesting is that svn keeps this info in .svn/ and does not use > it. Sick. If you checkout tags/ and branches/ (probably empty) than you won't need to type the URLs. The URLs are only needed when you want to do server-side cp or mv (which is not possible with CVS at all). -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn...
Tomasz Pala wrote: > Indeed. But my zsh tells me which files has been modified after i press > tab having 'cvs ci' on command line. You can use zsh clever autocompletion in our SPECS/? -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
Paweł Sakowski wrote: > On Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: > >>At the cost of keeping ALL tags/branches locally. You're joking. >> >>[EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS >>959MSOURCES >>63M SPECS > > > Obviously svn makes no sense with such file organization (in two > directories). To allow reasonable branching, each package would have to > have a directory of its own. Which is a good idea anyway, but probably > it's not worth changing now. But it would be a really big problem for people like qboosh. Probably the best choice would be to design something ourselves. ;-) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: go7007-hotplug.patch (NEW) - a patch for the hotplug scri...
Patrys :: Patryk Zawadzki wrote: > Here it looks like pure cosmetics (no execution prior to testing $?) but > it is more convenient to save it so if one adds one more instruction in > the conditional block it continues to work. That's what I though (but OTOH I changed it after getting a syslog message that the loading failed with code 0). The comparison ([) is not changing $? because it is builtin? And what if a standalone version of [ was used? -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: go7007-hotplug.patch (NEW) - a patch for the hotplug scri...
jpc wrote: > Index: SOURCES/go7007-hotplug.patch > diff -u /dev/null SOURCES/go7007-hotplug.patch:1.1 > --- /dev/null Mon Aug 29 14:13:55 2005 > +++ SOURCES/go7007-hotplug.patch Mon Aug 29 14:13:50 2005 > @@ -0,0 +1,16 @@ > +--- wis-go7007-linux-0.9.6/hotplug/wis-ezusb.in~ 2005-08-04 > 04:04:01.0 +0200 > wis-go7007-linux-0.9.6/hotplug/wis-ezusb.in 2005-08-28 > 20:02:17.147394816 +0200 > +@@ -84,10 +84,11 @@ > + fi > + > + $LOADER $FLAGS -I $FIRMWARE > ++$RETVAL=$? > + > +-if [ $? -gt 0 ]; then > ++if [ $RETVAL -gt 0 ]; then > + if [ -x /usr/bin/logger ]; then > +-/usr/bin/logger -t $0 "error $? returned by $LOADER $FLAGS -I > $FIRMWARE" > ++/usr/bin/logger -t $0 "error $RETVAL returned by $LOADER $FLAGS -I > $FIRMWARE" > + fi > + exit 1 > + fi Is this change needed or just cosmetic? (I'm the one who wrote this but I'm not really sure ;) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Q: PLD rc-scripts and /etc/net
Adam Gołębiowski wrote: > On Mon, Aug 29, 2005 at 06:05:24PM +0400, Denis Ovsienko wrote: > >>I want to try incorporating my project (http://etcnet.org/) into PLD. Whom can >>I send patches/ideas to? > > Can we discuss (potential) advantages of etcnet over our network > configuration first? I think it's not necessary (only insightful) and could be done in parallel with the implementation. PLD is about choice, isn't it? (and probably there are people who would like to use etcnet because e.g. they are already used to it, so why not?) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Q: PLD rc-scripts and /etc/net
Denis Ovsienko wrote: > Hi > I want to try incorporating my project (http://etcnet.org/) into PLD. Whom can > I send patches/ideas to? It is probably a good idea to use this list. Our rc-scripts have a separate list <[EMAIL PROTECTED]> but I think there are more people interested in this than just the rc-scripts team. Any objections? -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: passwdgen
Jacek Konieczny wrote: > On Sat, Aug 06, 2005 at 09:21:07PM +0200, Jakub Piotr Cłapa wrote: > >>>Another question is: does /dev/random have to be so slow? Are any patches >>>applied to it's code in PLD kernel that could slow it down? It's just I >>>don't >>>believe that author of passwdgen wrote a program that needs hours to produce >>>a 10 character password on average system... >> >>You can feed it and it will produce much more. Generating entropy based >>only on normal computer usage is not so easy. >> >>There were two programs which could feed the kernel with entropy from a >>v4l source or from a soundcard maybe try these?... > > > Some of modern computer systems (including modern PC machines) have > integrated hardware entropy sources. Unfortunately those drivers don't > add the entropy to /dev/random, but provide other device. And maybe you could cat this data into /dev/random? -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: passwdgen
Tomasz Grobelny wrote: > Dnia sobota 06 sierpnia 2005 19:26, Michal Moskal napisał: > >>On 8/6/05, Tomasz Grobelny <[EMAIL PROTECTED]> wrote: >> >>>Dnia sobota 06 sierpnia 2005 18:49, Michal Moskal napisał: >>> >>>>On 8/6/05, Tomasz Grobelny <[EMAIL PROTECTED]> wrote: >>>> >>>>>3. If /dev/urandom is supposed to be less secure but it is secure >>>>>enough (in current kernel implementation) should passwdgen use it? >>>>>Yes, because it works. No, because it could be insecure if kernel >>>>>behaviour changes. Other opinions? >>>> >>>>It cannot change to be less secure. It's part of the kernel API. >>> >>>Does the API define how data coming from /dev/urandom is generated? >> >>man urandom: >> >> When read, /dev/urandom device will return as many bytes as >>are requested. As a result, if there is not sufficient entropy in the >>entropy pool, the returned values are theoretically vulnerable to a >>cryptographic attack on the algorithms used by the driver. Knowledge of >>how to do this is not available in the current non-classified liter- ature, >>but it is theoretically possible that such an attack may exist. If this is >>a concern in your application, use /dev/random instead. > > But it doesn't say how data is generated. It just says that in some > circumstances it may be of lower security. But still we don't know how often > it can happen, how much lower the security will be and so on. It is up to > implementation, not API. > Another question is: does /dev/random have to be so slow? Are any patches > applied to it's code in PLD kernel that could slow it down? It's just I don't > believe that author of passwdgen wrote a program that needs hours to produce > a 10 character password on average system... You can feed it and it will produce much more. Generating entropy based only on normal computer usage is not so easy. There were two programs which could feed the kernel with entropy from a v4l source or from a soundcard maybe try these?... -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: vtk-pld.spec - dropped outdated comment
adamg wrote: > Author: adamgDate: Sat Jul 30 17:21:14 2005 GMT > Module: SPECS Tag: HEAD > Log message: > - dropped outdated comment I'm afraid the link is now outdated as well... -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
,,Forwardowanie IP'' za NAT
Sorry za repost z users, ale tam mi się nie udało uzyskać odpowiedzi... Jak to powinno być zrobione najbardziej poprawnie? iputils2, iptables? Mam siec, ktora chce wcisnac za maskarade (aktualnie wszyscy maja publiczne IP) i firewall, ale na kilku komputerach chcialbym to publiczne IP zachować. Co ustawic na routerze, zeby uzyskac taki efekt? Probowalem jakies proste regulki ip route, ale efekt byl raczej mizerny (pingowal komputer z poziomu bramki, ale z innych miejsc bramka odpowiadala, ze no route to ). Z góry dziękuję za pomoc. :) -- z wyrazami szacunku, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: libfwbuilder.spec, fwbuilder.spec - updated to 2.0.7 ; STBR
Fryderyk Dziarmagowski wrote: > On Mon, 6 Jun 2005 11:03:01 +0300 > "Elan Ruusamäe" <[EMAIL PROTECTED]> wrote: > >>please also update patches, they don't apply >> >>Patch #0 (libfwbuilder-configure.patch): >>+ patch -p1 -s >>+ < /home/builder/rpm/SOURCES/libfwbuilder-configure.patch >>1 out of 1 hunk FAILED -- saving rejects to file qmake.inc.in.rej >>error: Bad exit status from /var/tmp/rpm-tmp.73961 (%prep) > > paszczus was already warned about his development methods. as we see, > without expected results. Kill him, yeah! . -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: gajim.spec (NEW) - new spec - tried both 0.7 and latest sna...
jpc wrote: > Author: jpc Date: Thu Jun 2 23:03:56 2005 GMT > Module: SPECS Tag: HEAD > Log message: > - new spec > - tried both 0.7 and latest snap and both hang trying to connect > could someone confirm it? Anyone? :-) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
