Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-08-15 at 16:34 -0700, Chris Gianelloni wrote: > I would expect it to act like any other Linux box and get a new address > via dhcp, or, if I wasn't using dhcp, sit on the old address, even > though it is now incorrect, until I changed it. A netplug event should > trigger dhcp events, but not necessarily the services all dropping. > After all, I've seen netplug do some funny things, like false positives > on disconnection and such. I'd much rather my connection drop for a > second and come back up, so all my packets can simply retransmit and > everything continues, than have the services also decide to go down and > refuse to resume any open connections when the connection comes back up. > TCP has retransmission for a reason. Let's not break it if we don't > have to do so. A vote for NO then? Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-08-15 at 16:31 -0700, Chris Gianelloni wrote: > On Wed, 2007-08-15 at 14:10 +0100, Roy Marples wrote: > > At this point, the process freezes for a LONG time that can't be > > interupted because as the cable has already been unplugged it can't > > unmount (if anyone knows how to actually return ASAP I'd like to know > > that too). > > umount -l Didn't actually solve what I was seeing - had no visible effect. That was a few months ago, maybe I should try again. > The problem that I see here is that most sane people don't allow sshd > and other services to listen on * and instead force them to listen on > the proper interface/IP address. With this, I would end up with sshd > not starting on my remote servers after a reboot, causing me to have to > call the data center and get some remote hands on my box. Something I > hate to do. Trust me. I'd blame you. :P So in other words you should be putting this in /etc/conf.d/sshd RC_NEED="net.eth1" Or the interface that defines the address that sshd binds to. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Cryptsetup changes
Am Mittwoch, 15. August 2007 schrieb ext Benjamin Smee: > it works with baselayout-1. I rechecked again yesterday evening, to make sure I didn't overlook something. No, it doesn't, at least for me. > So please file a bug. Done. http://bugs.gentoo.org/show_bug.cgi?id=189073 Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Wanheimerstraße 68 | Web: http://www.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] emerge feature suggestions
On 8/15/07, Vaeth <[EMAIL PROTECTED]> wrote: > On Tue, 14 Aug 2007, Alec Warner wrote: > > On 8/13/07, Nathan Smith <[EMAIL PROTECTED]> wrote: > > > > > > I suppose this comes down to weighing the utility of such a feature > > > against the amount of effort which would go into adding it to Portage. > > > > Its trivial to implement, but I think its a long standing decision of > > the portage team to not do it. > > Please allow me to give some arguments why maybe this decision should be > thought over once more: > > > We typically don't write things for emerge that touch your > > /etc/portage files (aside from updates/) > > Which is good. > There is no need to change such a file for the required feature > (only oppositely: Without the feature, the user is forced to change > this files) > > > We also don' t like one-offs. We used to recommend people do stuff like > > "ACCEPT_KEYWORDS=~x86 emerge foo" > > or > > "USE='foo bar baz' emerge foo" > > > > which both suck because the next time you use emerge > > your settings are lost. > > With the second claim I completely agree: > It is good to not recommend such things in general (in particular, > not to an unexperienced user). > However, I cannot see why one-offs should be bad in general: > There are always cases where people *intentionally* want one-offs. > For USE or ACCEPT_KEYWORDS, this might simply be for a (temporary) > testing purpose. However, concerning the selection of packages which are > updated there are more serious reasons why one might want a one-off. > Some examples: > 1. You want to upgrade a machine, but also a new version of >openoffice would be installed for which you currently do not >have the bandwidth to download or the time to install. >So you want to emerge -NDu world except for openoffice. >Of course, one might argue that you should then put the new version >of openoffice in /etc/portage/package.mask, but actually, you would >like to see openoffice in the next emerge command again - in fact, >when you call emerge next time you might even have forgotten that >you had masked openoffice the previous time for a temporary reason. > 2. You want to upgrade a machine which should do something in the >next 24 hours (e.g. record a movie) and you suspect that the >suggested upgrade of e.g. expat might break the application without >a revdep-rebuild. So you want to emerge -NDu world except for >expat. (And, of course, you will want to emerge expat next time). > 3. You have reached your band-limit for this month and so cannot afford >to download the new kernel sources until next week. So you want to >emerge -fDu world except for the new kernel (and perhaps later >emerge -Du world except for the new kernel). > 4. You want to upgrade on your laptop 100 binary packages. However, >since your laptop has only a small harddisk, these 100 *.tbz2's do >not fit all on your laptop - you should exclude 3 or 4 of the large >ones in the first step and then can install these large ones >in the second step. > > In all of the above cases you usually want that the corresponding > packages are contained in the next emerge -NDu world; you just want > to exclude the packages for one particular call of emerge. Ahh but that is a lie. You want to exclude the package from the depgraph until whatever reason you had is gone. Typically it's 1 emerge run, sometimes it's 100's, I don't think you can necessarily limit the number of emerge runs in any of the use cases. In the case of bandwidth limitations, you want to not download the kernel until you have more bandwidth available. Are you going to remember to exclude the kernel sources every time you run an emerge that might pull in kernel-sources? God knows I wouldn't remember ;) So the point of this discussion is that specifying things that affect the resultant depgraph are bad unless they have useful functionality. ROOT and CONFIG_ROOT are two such options, but afaik those can also be set in make.conf (have to read the code to check). > But why force the user to hack to achieve a reasonable goal? > The files in /etc/portage/* should IMHO be well cared by the user > and not be misused for temporary hacks. > Moreover, if you modify e.g. package.mask just to get one of the tasks > in the above example done, it is easy to forget to undo > this modification after the emerge. Well I wouldn't say making a wrapper around emerge is a 'hack'. It's not like it requires editing the code. Your latter example about not removing the mask is mitigated by using a tool (mask, run emerge, unmask). If you want to talk about how emerge sucks as a tool to manage /etc/portage/* then I'll wholeheartedly agree with you. Feel free to write some. But emerge is not an /etc/portage/* manager. -Alec -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-08-15 at 17:34 +0100, Roy Marples wrote: > On Wed, 2007-08-15 at 17:07 +0100, Graham Murray wrote: > > To avoid that problem, do not stop net.ethN when the cable is > > pulled. When the cable is re-inserted then (if it has not been left > > disconnected for too long) if the services have not stopped, TCP > > sessions may still be active. > > So what do you think would happen if I unplug cable A and plug in cable > B? Both are on separate networks. I would expect it to act like any other Linux box and get a new address via dhcp, or, if I wasn't using dhcp, sit on the old address, even though it is now incorrect, until I changed it. A netplug event should trigger dhcp events, but not necessarily the services all dropping. After all, I've seen netplug do some funny things, like false positives on disconnection and such. I'd much rather my connection drop for a second and come back up, so all my packets can simply retransmit and everything continues, than have the services also decide to go down and refuse to resume any open connections when the connection comes back up. TCP has retransmission for a reason. Let's not break it if we don't have to do so. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-08-15 at 14:10 +0100, Roy Marples wrote: > At this point, the process freezes for a LONG time that can't be > interupted because as the cable has already been unplugged it can't > unmount (if anyone knows how to actually return ASAP I'd like to know > that too). umount -l The problem that I see here is that most sane people don't allow sshd and other services to listen on * and instead force them to listen on the proper interface/IP address. With this, I would end up with sshd not starting on my remote servers after a reboot, causing me to have to call the data center and get some remote hands on my box. Something I hate to do. Trust me. I'd blame you. :P -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wednesday 15 Aug 2007, Roy Marples wrote: > If say you have nfs mounts, one network cable and then unplug the cable > you get this :- >netplug calls net.eth0 stop >net.eth0 stop calls netmount stop >netmount stop tries to unmount the nfs mounts Perhaps it should be seen the other way round... It's netmount who doesn't like to depend strictly when net.eth0 comes down. If you change networks by changing the cable from network A to network B, then you should do a netmount restart, as netmount would require you to do so. For other services, the dependency is respected. Bottom line, the initscript itself could decide to fulfill the dependency (start/stop), not the framework (baselayout itself). > We should only start services like openvpn, ssh, dns, etc when we have a > working network devices aside from the loopback. It would work as expected... Arturo -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Porting app-portage/maintainer-helper to GTK+
Dnia 15-08-2007, śro o godzinie 13:09 -0400, Luis Francisco Araujo napisał(a): > > Count me in! o/ And don't forget we play in one team ;-) -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Porting app-portage/maintainer-helper to GTK+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Faulhammer wrote: > Hi, > > Maybe some of you have already seen app-portage/maintainer-helper from > Jokey. It is written for Qt, but I was just happy to replace the last > Qt app with something agnostic/GTK+ based on my system. Unluckily I > have no real idea about GTK+ and it would be nice, if someone could > help Jokey to port it to GTK+. > > http://dev.gentoo.org/~jokey/screenies/mhelper-versionbump.png> > http://dev.gentoo.org/~jokey/screenies/mhelper.png> > > V-Li > Count me in! o/ - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGwzMuBCmRZan6aegRApAWAKC8abj3Ny2ChmyOZuwJyzbo1JmpOQCgxkuW hnHsKhPYY7AjYWqlliwaAoo= =YKBN -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-08-15 at 17:07 +0100, Graham Murray wrote: > To avoid that problem, do not stop net.ethN when the cable is > pulled. When the cable is re-inserted then (if it has not been left > disconnected for too long) if the services have not stopped, TCP > sessions may still be active. So what do you think would happen if I unplug cable A and plug in cable B? Both are on separate networks. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Cryptsetup changes
Graham Murray wrote: Mike Auty <[EMAIL PROTECTED]> writes: Could you please describe the problem you faced? From the detail you gave, it sounds as though you might not have moved /etc/conf.d/cryptfs to /etc/conf.d/dmcrypt. I had a problem. I moved /etc/conf.d/cryptfs to /etc/conf.d/dmcrypt, but none of the encrypted mounts happened on re-boot. I found that running 'cryptsetup luksOpen /dev/hhh mountname' segfaulted (but cryptsetup --help displayed help). But when I ran it using gdb (and using set args to set the identical command line) it worked correctly. I will be investigating more later, but for now I have re-emerged cryptsetup-luks 1.0.4-r3 and all works well again. Could be related to bug #163803. http://bugs.gentoo.org/show_bug.cgi?id=163803 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Cryptsetup changes
Mike Auty <[EMAIL PROTECTED]> writes: > Could you please describe the problem you faced? From the detail you > gave, it sounds as though you might not have moved /etc/conf.d/cryptfs > to /etc/conf.d/dmcrypt. I had a problem. I moved /etc/conf.d/cryptfs to /etc/conf.d/dmcrypt, but none of the encrypted mounts happened on re-boot. I found that running 'cryptsetup luksOpen /dev/hhh mountname' segfaulted (but cryptsetup --help displayed help). But when I ran it using gdb (and using set args to set the identical command line) it worked correctly. I will be investigating more later, but for now I have re-emerged cryptsetup-luks 1.0.4-r3 and all works well again. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
Roy Marples <[EMAIL PROTECTED]> writes: > If say you have nfs mounts, one network cable and then unplug the cable > you get this :- >netplug calls net.eth0 stop >net.eth0 stop calls netmount stop >netmount stop tries to unmount the nfs mounts > At this point, the process freezes for a LONG time that can't be > interupted because as the cable has already been unplugged it can't > unmount (if anyone knows how to actually return ASAP I'd like to know > that too). > With the default to NO the act of pulling the cable simply stops > net.eth0 and the services stay up and things continue nicely. To avoid that problem, do not stop net.ethN when the cable is pulled. When the cable is re-inserted then (if it has not been left disconnected for too long) if the services have not stopped, TCP sessions may still be active. If the user manually stops an interface, by all means stop the services depending on it but (a) Do not make the interface stop automatically when the cable is disconnected, (b) It would be nice if there was a single command which could restart all the dependencies which were stopped. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-15-08 at 15:02 +0100, Roy Marples wrote: > On Wed, 2007-08-15 at 10:09 -0400, Olivier Crête wrote: > > I believe services that don't bind to a specific address should probably > > only depend on net.lo, not net. > > Well, they can actually depend on a specific net service too. > For example, I have this on my home server in /etc/conf.d/lighttpd > RC_NEED="net.vpn" > > You can add those RC_NEED/USE/AFTER/BEFORE directives to any conf.d/ > file and it will append to the stuff in the init script. If you can do that, then well, everything else should just depend on net.lo (and not wait for service plugging then). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-08-15 at 10:09 -0400, Olivier Crête wrote: > I believe services that don't bind to a specific address should probably > only depend on net.lo, not net. Well, they can actually depend on a specific net service too. For example, I have this on my home server in /etc/conf.d/lighttpd RC_NEED="net.vpn" You can add those RC_NEED/USE/AFTER/BEFORE directives to any conf.d/ file and it will append to the stuff in the init script. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-15-08 at 14:10 +0100, Roy Marples wrote: > OK, so whilst we're gearing up for hopefully the last baselayout-2 > release candidate I thought I would pose to the list a question I've > been struggling with for some time. > > Should hotplugged services affect dependencies by default? > (Note, this is not about enabling hotplugged services by default which > is another topic for debate. Want to talk about that, start a new thread > - but save your breath as I have a laptop and think hotplugging is > good :P) > > By default we've always been YES. But I'm starting now that this should > be NO. I believe services that don't bind to a specific address should probably only depend on net.lo, not net. So then we separate this that really need the network (and probably only a specific interface and then the user should modify the script to depend on that interface) and those that use the network, but don't really need it (like sshd, etc). That said, I now use networkmanager (to be able to easily select wifi networks), I don't know how integrated into the whole baselayout-2. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
I suppose I should mention that the setting in baselayout-2 I'm talking about is RC_DEPEND_STRICT if you want to toggle it to see. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Should hotplugged services affect dependencies by default?
OK, so whilst we're gearing up for hopefully the last baselayout-2 release candidate I thought I would pose to the list a question I've been struggling with for some time. Should hotplugged services affect dependencies by default? (Note, this is not about enabling hotplugged services by default which is another topic for debate. Want to talk about that, start a new thread - but save your breath as I have a laptop and think hotplugging is good :P) By default we've always been YES. But I'm starting now that this should be NO. Rationale for NO Services like openvpn, ssh, dns, etc don't actually care about specific interfaces or addresses as such as they just bind to *. dns may infact be configured to use a resolver that isn't libc so it should be active anway. If say you have nfs mounts, one network cable and then unplug the cable you get this :- netplug calls net.eth0 stop net.eth0 stop calls netmount stop netmount stop tries to unmount the nfs mounts At this point, the process freezes for a LONG time that can't be interupted because as the cable has already been unplugged it can't unmount (if anyone knows how to actually return ASAP I'd like to know that too). With the default to NO the act of pulling the cable simply stops net.eth0 and the services stay up and things continue nicely. For baselayout-1 users, this is the equivalent of having RC_STRICT_NET_CHECKING=lo which a lot of people I've been talking to recently have asked where it is in baselayout-2 Rationale for YES We should only start services like openvpn, ssh, dns, etc when we have a working network devices aside from the loopback. This is the nearest we get to the default baselayout-1 option for RC_STRICT_NET_CHECKING=no Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Cryptsetup changes
heya, On Wednesday 15 August 2007 12:26:32 Dirk Heinrichs wrote: > Yes, did it. And added dmcrypt to the boot runlevel. don't unless you're running baselayout-2 > But it doesn't. While booting, the dmcrypt init script says it works on bl > 2 only, mappings are not created. Why is this change needed anyway, the > current mechanism works fine. It does work, or rather it works for everyone else that's tested it and on my 4 testbeds with setups from a password through to a usbdrive with keys gpg encrypted on it. > The cryptsetup ebuild doesn't provide > > /lib/rcscripts/addons/dm-crypt-start.sh > /lib/rcscripts/addons/dm-crypt-stop.sh look at lines 80-83. I'm not sure what you've done but it sounds like you have a few things confused. File a bug and I'll be happy to help. regards, -- Benjamin Smee (strerror) net-mail/netmon/forensics/crypto Fingerprint: 497F 5E98 1FA0 C313 EA0B 08C7 004A 66ED 448B E78C -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Cryptsetup changes
On Wednesday 15 August 2007 11:56:55 Donnie Berkholz wrote: > On 11:15 Wed 15 Aug , Mike Auty wrote: > > Could you please describe the problem you faced? From the detail you > > gave, it sounds as though you might not have moved /etc/conf.d/cryptfs > > to /etc/conf.d/dmcrypt. There's currently several ewarn lines saying > > that this must be done before the package will continue to work. The > > idea is that the package should work with both baselayout-1.12 and > > baselayout-2, so it therefore should not need hardmasking. > > Is there some reason you can't do this automatically in the ebuild? It > ought not to hurt bl-1 compat to have two copies of the file. fair point. I was thinking more about baselayout-2 migration when I wrote it. I'll have a look at it later and see what's the most sensible way of doing it. thanks, -- Benjamin Smee (strerror) net-mail/netmon/forensics/crypto Fingerprint: 497F 5E98 1FA0 C313 EA0B 08C7 004A 66ED 448B E78C -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Cryptsetup changes
heya, On Wednesday 15 August 2007 07:01:12 Dirk Heinrichs wrote: > Am Dienstag, 14. August 2007 schrieb ext Benjamin Smee: > I'm not a developer, but since I was already bitten by this, a few comments: > > >=cryptsetup-1.0.5 as -luks will be deprecated soon. > > Don't do this until upgrading/replacing will be seemless. wasn't planning on, just giving everyone notice that it is coming... > Shouldn't it have a hint, then. baselayout-2 is still hard masked and > replacing cryptsetup-luks with cryptsetup made my laptop simply unbootable, > because the mechanism for creating the mappuings has changed and the > dmcrypt initscript just printed a message that it will only work with > baselayout 2. But that was _way_ to late. it works with baselayout-1. > Please hard mask cryptsetup as long as baselayout 2 is, or fix it to work > with bl 1, too. I'm not hardmasking it as it works with both on my testbeds. So please file a bug. -- Benjamin Smee (strerror) net-mail/netmon/forensics/crypto Fingerprint: 497F 5E98 1FA0 C313 EA0B 08C7 004A 66ED 448B E78C -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Cryptsetup changes
On 11:15 Wed 15 Aug , Mike Auty wrote: > Could you please describe the problem you faced? From the detail you > gave, it sounds as though you might not have moved /etc/conf.d/cryptfs > to /etc/conf.d/dmcrypt. There's currently several ewarn lines saying > that this must be done before the package will continue to work. The > idea is that the package should work with both baselayout-1.12 and > baselayout-2, so it therefore should not need hardmasking. Is there some reason you can't do this automatically in the ebuild? It ought not to hurt bl-1 compat to have two copies of the file. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Cryptsetup changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dirk, Could you please describe the problem you faced? From the detail you gave, it sounds as though you might not have moved /etc/conf.d/cryptfs to /etc/conf.d/dmcrypt. There's currently several ewarn lines saying that this must be done before the package will continue to work. The idea is that the package should work with both baselayout-1.12 and baselayout-2, so it therefore should not need hardmasking. Could you please provide a few more details and/or file a bug report so that we can figure out what exactly went wrong? If it was something other than the move from cryptfs to dmcrypt then we should investigate, and we'll need as much information as you can provide us to help get it solved. Thanks very much, Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGwtJQu7rWomwgFXoRAmvWAKCWqguvu98OVrV/CSUSU3Uz26jd5ACfZfNe UKrhItE7ETb7XVW3UWlwNIk= =7gz/ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Porting app-portage/maintainer-helper to GTK+
Hi, Maybe some of you have already seen app-portage/maintainer-helper from Jokey. It is written for Qt, but I was just happy to replace the last Qt app with something agnostic/GTK+ based on my system. Unluckily I have no real idea about GTK+ and it would be nice, if someone could help Jokey to port it to GTK+. http://dev.gentoo.org/~jokey/screenies/mhelper-versionbump.png> http://dev.gentoo.org/~jokey/screenies/mhelper.png> V-Li -- http://www.gentoo.org/ http://www.faulhammer.org/ http://www.gnupg.org/ signature.asc Description: PGP signature
[gentoo-dev] Last rites for www-apps/ids
# Gunnar Wrobel <[EMAIL PROTECTED]> (15 Aug 2007) # Has open security bugs and upstream seems to be dead # http://bugs.gentoo.org/show_bug.cgi?id=158698 www-apps/ids will be removed in 30 days as usual if nobody objects. -- Gunnar WrobelGentoo Developer __C_o_n_t_a_c_t__ Mail: [EMAIL PROTECTED] WWW: http://www.gunnarwrobel.de IRC: #gentoo-web at freenode.org _ -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: kde startet nicht mehr
Christian Faulhammer <[EMAIL PROTECTED]>: [...] Sorry guys, was for -user-de V-Li -- http://www.gentoo.org/ http://www.faulhammer.org/ http://www.gnupg.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: kde startet nicht mehr
Volker Katz <[EMAIL PROTECTED]>: > > Sind sie nicht vorhanden, dann die Pakete xset und xsetroot > > nachinstallieren (und ggf. einen Bugreport erstellen über fehlende > > Abhängigkeiten). xset und xsetroot werden in den Skripten aufgerufen, haben aber am Ende keinen Effekt. > Allerdings ist mir noch etwas aufgefallen: > Diese Fehlermeldung hatte ich ja schon gepostet: > DCOPClient::attachInternal. Attach failed Could not open network > socket Wie sieht deine Datei /etc/hosts aus? V-Li -- http://www.gentoo.org/ http://www.faulhammer.org/ http://www.gnupg.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Cryptsetup changes
Am Mittwoch, 15. August 2007 schrieb ext Duncan: > So baselayout-2 hard-masking isn't likely to be an issue for much longer. Well, for me it was an issue yesterday. Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Wanheimerstraße 68 | Web: http://www.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Cryptsetup changes
Duncan <[EMAIL PROTECTED]>: > So baselayout-2 hard-masking isn't likely to be an issue for much > longer. As long as it bl-2 is hard masked, all packages depending on it, should be too. V-Li -- http://www.gentoo.org/ http://www.faulhammer.org/ http://www.gnupg.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: Cryptsetup changes
Dirk Heinrichs <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 15 Aug 2007 08:01:12 +0200: > Please hard mask cryptsetup as long as baselayout 2 is, or fix it to > work with bl 1, too. See the "baselayout-2 stabilization plans" thread from July 21, and http://bugs.gentoo.org/show_bug.cgi?id=187487 . Briefly, baselayout-2 is already considered ~arch material and has already been ~arch keyworded by a number of archs. When they've all keyworded it, it'll be unmasked to all of them together. So baselayout-2 hard-masking isn't likely to be an issue for much longer. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] emerge feature suggestions
On Tue, 14 Aug 2007, Alec Warner wrote: > On 8/13/07, Nathan Smith <[EMAIL PROTECTED]> wrote: > > > > I suppose this comes down to weighing the utility of such a feature > > against the amount of effort which would go into adding it to Portage. > > Its trivial to implement, but I think its a long standing decision of > the portage team to not do it. Please allow me to give some arguments why maybe this decision should be thought over once more: > We typically don't write things for emerge that touch your > /etc/portage files (aside from updates/) Which is good. There is no need to change such a file for the required feature (only oppositely: Without the feature, the user is forced to change this files) > We also don' t like one-offs. We used to recommend people do stuff like > "ACCEPT_KEYWORDS=~x86 emerge foo" > or > "USE='foo bar baz' emerge foo" > > which both suck because the next time you use emerge > your settings are lost. With the second claim I completely agree: It is good to not recommend such things in general (in particular, not to an unexperienced user). However, I cannot see why one-offs should be bad in general: There are always cases where people *intentionally* want one-offs. For USE or ACCEPT_KEYWORDS, this might simply be for a (temporary) testing purpose. However, concerning the selection of packages which are updated there are more serious reasons why one might want a one-off. Some examples: 1. You want to upgrade a machine, but also a new version of openoffice would be installed for which you currently do not have the bandwidth to download or the time to install. So you want to emerge -NDu world except for openoffice. Of course, one might argue that you should then put the new version of openoffice in /etc/portage/package.mask, but actually, you would like to see openoffice in the next emerge command again - in fact, when you call emerge next time you might even have forgotten that you had masked openoffice the previous time for a temporary reason. 2. You want to upgrade a machine which should do something in the next 24 hours (e.g. record a movie) and you suspect that the suggested upgrade of e.g. expat might break the application without a revdep-rebuild. So you want to emerge -NDu world except for expat. (And, of course, you will want to emerge expat next time). 3. You have reached your band-limit for this month and so cannot afford to download the new kernel sources until next week. So you want to emerge -fDu world except for the new kernel (and perhaps later emerge -Du world except for the new kernel). 4. You want to upgrade on your laptop 100 binary packages. However, since your laptop has only a small harddisk, these 100 *.tbz2's do not fit all on your laptop - you should exclude 3 or 4 of the large ones in the first step and then can install these large ones in the second step. In all of the above cases you usually want that the corresponding packages are contained in the next emerge -NDu world; you just want to exclude the packages for one particular call of emerge. Of course, currently this can be done with some hacks: > Echoing crap to to package.mask or running a utility that does it is > pretty easy imho. But why force the user to hack to achieve a reasonable goal? The files in /etc/portage/* should IMHO be well cared by the user and not be misused for temporary hacks. Moreover, if you modify e.g. package.mask just to get one of the tasks in the above example done, it is easy to forget to undo this modification after the emerge. -- [EMAIL PROTECTED] mailing list
