[arch-dev-public] initscripts in testing
Hi i put new initscripts for both arches to testing. they should fix those bugs: http://bugs.archlinux.org/task/5740 http://bugs.archlinux.org/task/6237 http://bugs.archlinux.org/task/7165 http://bugs.archlinux.org/task/7554 http://bugs.archlinux.org/task/7641 there are some feature requests which i didn't implemented yet comments from your side please: http://bugs.archlinux.org/task/7369 http://bugs.archlinux.org/task/7714 http://bugs.archlinux.org/task/7267 probably not implement / closing requests: http://bugs.archlinux.org/task/5324 finally next step bump to next release name: we need a new release name :) suggestions please, i think the last name suggestion was "Hardcore". greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Tobias Powalowski Verzonden: donderdag 18 oktober 2007 10:11 Aan: Public mailing list for ArchLinux development Onderwerp: [arch-dev-public] initscripts in testing
Hi i put new initscripts for both arches to testing. they should fix those bugs: http://bugs.archlinux.org/task/5740 http://bugs.archlinux.org/task/6237 http://bugs.archlinux.org/task/7165 http://bugs.archlinux.org/task/7554 http://bugs.archlinux.org/task/7641
there are some feature requests which i didn't implemented yet comments from your side please: http://bugs.archlinux.org/task/7369 http://bugs.archlinux.org/task/7714 http://bugs.archlinux.org/task/7267
probably not implement / closing requests: http://bugs.archlinux.org/task/5324
finally next step bump to next release name: we need a new release name :) suggestions please, i think the last name suggestion was "Hardcore".
About the "lo" fix: there's a comment in rc.conf about disabling lo now. Did you think about users who don't add "network" to DAEMONS? IMHO rc.sysinit should always enable the lo interface, unless it is specifically disabled (look for interfaces=(!lo) or !network in DAEMONS). Yes, this is inconsistent with the way we work in arch, but it will lower the amount of bugreports we get for this, while still giving people control over their lo interface if they want to disable it on purpose.
On Thu, Oct 18, 2007 at 11:05:32AM +0200, Jan de Groot wrote:
About the "lo" fix: there's a comment in rc.conf about disabling lo now. Did you think about users who don't add "network" to DAEMONS?
IMHO rc.sysinit should always enable the lo interface, unless it is specifically disabled (look for interfaces=(!lo) or !network in DAEMONS). Yes, this is inconsistent with the way we work in arch, but it will lower the amount of bugreports we get for this, while still giving people control over their lo interface if they want to disable it on purpose.
I agree. I think we've always had lo enabled by default, and I see little reason to change that right now. It'll just cause a lot of headaches for like 90% of people by adding a little nuance that they're unlikely to know about. -S
On 10/18/07, Simo Leone <simo@archlinux.org> wrote:
On Thu, Oct 18, 2007 at 11:05:32AM +0200, Jan de Groot wrote:
About the "lo" fix: there's a comment in rc.conf about disabling lo now. Did you think about users who don't add "network" to DAEMONS?
IMHO rc.sysinit should always enable the lo interface, unless it is specifically disabled (look for interfaces=(!lo) or !network in DAEMONS). Yes, this is inconsistent with the way we work in arch, but it will lower the amount of bugreports we get for this, while still giving people control over their lo interface if they want to disable it on purpose.
I agree. I think we've always had lo enabled by default, and I see little reason to change that right now. It'll just cause a lot of headaches for like 90% of people by adding a little nuance that they're unlikely to know about.
Agreed. In addition, could you make sure 'isatty' is part of this package? It somehow got lost recently and I use it in some personal scripts.
On 10/18/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/18/07, Simo Leone <simo@archlinux.org> wrote:
On Thu, Oct 18, 2007 at 11:05:32AM +0200, Jan de Groot wrote:
About the "lo" fix: there's a comment in rc.conf about disabling lo now. Did you think about users who don't add "network" to DAEMONS?
IMHO rc.sysinit should always enable the lo interface, unless it is specifically disabled (look for interfaces=(!lo) or !network in DAEMONS). Yes, this is inconsistent with the way we work in arch, but it will lower the amount of bugreports we get for this, while still giving people control over their lo interface if they want to disable it on purpose.
I agree. I think we've always had lo enabled by default, and I see little reason to change that right now. It'll just cause a lot of headaches for like 90% of people by adding a little nuance that they're unlikely to know about.
Agreed.
In addition, could you make sure 'isatty' is part of this package? It somehow got lost recently and I use it in some personal scripts.
Um...I killed this. It was pointless and not even full-featured. Try the test -t option. -Dan
On 10/18/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 10/18/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/18/07, Simo Leone <simo@archlinux.org> wrote:
On Thu, Oct 18, 2007 at 11:05:32AM +0200, Jan de Groot wrote:
About the "lo" fix: there's a comment in rc.conf about disabling lo now. Did you think about users who don't add "network" to DAEMONS?
IMHO rc.sysinit should always enable the lo interface, unless it is specifically disabled (look for interfaces=(!lo) or !network in DAEMONS). Yes, this is inconsistent with the way we work in arch, but it will lower the amount of bugreports we get for this, while still giving people control over their lo interface if they want to disable it on purpose.
I agree. I think we've always had lo enabled by default, and I see little reason to change that right now. It'll just cause a lot of headaches for like 90% of people by adding a little nuance that they're unlikely to know about.
Agreed.
In addition, could you make sure 'isatty' is part of this package? It somehow got lost recently and I use it in some personal scripts.
Um...I killed this. It was pointless and not even full-featured. Try the test -t option.
Well ok then, I kinda expected some mention of this in the logs, and didn't see it, so assumed it was an oversight. Could you 'cvs rm' the C file
On 10/18/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/18/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 10/18/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/18/07, Simo Leone <simo@archlinux.org> wrote:
On Thu, Oct 18, 2007 at 11:05:32AM +0200, Jan de Groot wrote:
About the "lo" fix: there's a comment in rc.conf about disabling lo now. Did you think about users who don't add "network" to DAEMONS?
IMHO rc.sysinit should always enable the lo interface, unless it is specifically disabled (look for interfaces=(!lo) or !network in DAEMONS). Yes, this is inconsistent with the way we work in arch, but it will lower the amount of bugreports we get for this, while still giving people control over their lo interface if they want to disable it on purpose.
I agree. I think we've always had lo enabled by default, and I see little reason to change that right now. It'll just cause a lot of headaches for like 90% of people by adding a little nuance that they're unlikely to know about.
Agreed.
In addition, could you make sure 'isatty' is part of this package? It somehow got lost recently and I use it in some personal scripts.
Um...I killed this. It was pointless and not even full-featured. Try the test -t option.
Well ok then, I kinda expected some mention of this in the logs, and didn't see it, so assumed it was an oversight.
Could you 'cvs rm' the C file
Sure, sorry about that. I know it came up on ML traffic somewhere, and when I asked people to test the new initscripts without it. http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/initscripts/rc.sysinit.diff?r1=1.108&r2=1.109 -Dan
On 10/18/07, Simo Leone <simo@archlinux.org> wrote:
On Thu, Oct 18, 2007 at 11:05:32AM +0200, Jan de Groot wrote:
About the "lo" fix: there's a comment in rc.conf about disabling lo now. Did you think about users who don't add "network" to DAEMONS?
IMHO rc.sysinit should always enable the lo interface, unless it is specifically disabled (look for interfaces=(!lo) or !network in DAEMONS). Yes, this is inconsistent with the way we work in arch, but it will lower the amount of bugreports we get for this, while still giving people control over their lo interface if they want to disable it on purpose.
I agree. I think we've always had lo enabled by default, and I see little reason to change that right now. It'll just cause a lot of headaches for like 90% of people by adding a little nuance that they're unlikely to know about.
-S
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
Two thoughts here, mostly for Tobias: * Version is 2007.08-4, shouldn't this be version 2007.10/11? * When you made the lo change, did you ensure it is backward compatable? Having lo in your network array shouldn't cause an error now, because every current user will have it. -Dan
On 10/18/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 10/18/07, Simo Leone <simo@archlinux.org> wrote:
On Thu, Oct 18, 2007 at 11:05:32AM +0200, Jan de Groot wrote:
About the "lo" fix: there's a comment in rc.conf about disabling lo now. Did you think about users who don't add "network" to DAEMONS?
IMHO rc.sysinit should always enable the lo interface, unless it is specifically disabled (look for interfaces=(!lo) or !network in DAEMONS). Yes, this is inconsistent with the way we work in arch, but it will lower the amount of bugreports we get for this, while still giving people control over their lo interface if they want to disable it on purpose.
I agree. I think we've always had lo enabled by default, and I see little reason to change that right now. It'll just cause a lot of headaches for like 90% of people by adding a little nuance that they're unlikely to know about.
-S
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
Two thoughts here, mostly for Tobias: * Version is 2007.08-4, shouldn't this be version 2007.10/11? * When you made the lo change, did you ensure it is backward compatable? Having lo in your network array shouldn't cause an error now, because every current user will have it.
Third thought. We should treat the initscripts as a real code project. That is, place them beside the rest of the code and create real tarballs.
Aaron Griffin schrieb:
Third thought. We should treat the initscripts as a real code project. That is, place them beside the rest of the code and create real tarballs.
Agreed. Tell that to the guy who has permissions to create a new GIT repository. I think his name was Aaron.
On 10/19/07, Thomas Bächler <thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
Third thought. We should treat the initscripts as a real code project. That is, place them beside the rest of the code and create real tarballs.
Agreed. Tell that to the guy who has permissions to create a new GIT repository. I think his name was Aaron.
I'll pull the CVS history sometime today so we can have some backlog in GIT. Post this release, we'll get it in a repository and do development from there, but I agree with tpowa that we should at least wait until this release is out to do shifting like that. -Dan
On 10/19/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 10/19/07, Thomas Bächler <thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
Third thought. We should treat the initscripts as a real code project. That is, place them beside the rest of the code and create real tarballs.
Agreed. Tell that to the guy who has permissions to create a new GIT repository. I think his name was Aaron.
I'll pull the CVS history sometime today so we can have some backlog in GIT. Post this release, we'll get it in a repository and do development from there, but I agree with tpowa that we should at least wait until this release is out to do shifting like that.
Hey Thomas- thanks for using the new GIT repo already, glad to see it is being put to good use. Can you ensure that when you make a tarball from it you tag the release? (git tag 2007.11 <sha1>) It would help in the future when we want to look back at certain points in time, and I tried as best I could to get all the old release points tagged as well. And I noticed your whitespace commit- if you enable the pre-commit hook in your local repository, then you can prevent these things from happening. -Dan
Dan McGee schrieb:
Hey Thomas- thanks for using the new GIT repo already, glad to see it is being put to good use. Can you ensure that when you make a tarball from it you tag the release? (git tag 2007.11 <sha1>) It would help in the future when we want to look back at certain points in time, and I tried as best I could to get all the old release points tagged as well.
See the thread below, tags will likely have 2007.11-1 as version numbers. I guess I can omit the sha1 if I want to tag my current HEAD.
And I noticed your whitespace commit- if you enable the pre-commit hook in your local repository, then you can prevent these things from happening.
It wasn't my commit, I saw the whitespace in a warning after I did git-am with Roman's patch: http://projects.archlinux.org/git/?p=initscripts.git;a=commit;h=59f89b4a25fb...
On 10/21/07, Thomas Bächler <thomas@archlinux.org> wrote:
Dan McGee schrieb:
Hey Thomas- thanks for using the new GIT repo already, glad to see it is being put to good use. Can you ensure that when you make a tarball from it you tag the release? (git tag 2007.11 <sha1>) It would help in the future when we want to look back at certain points in time, and I tried as best I could to get all the old release points tagged as well.
See the thread below, tags will likely have 2007.11-1 as version numbers. I guess I can omit the sha1 if I want to tag my current HEAD.
Yeah, I saw that thread a minute too late. I responded there.
And I noticed your whitespace commit- if you enable the pre-commit hook in your local repository, then you can prevent these things from happening.
It wasn't my commit, I saw the whitespace in a warning after I did git-am with Roman's patch: http://projects.archlinux.org/git/?p=initscripts.git;a=commit;h=59f89b4a25fb...
Ahh, then pre-applypatch is your friend then. -Dan
> > Two thoughts here, mostly for Tobias: > > * Version is 2007.08-4, shouldn't this be version 2007.10/11? > > * When you made the lo change, did you ensure it is backward > > compatable? Having lo in your network array shouldn't cause an error > > now, because every current user will have it. - the name wasn't changed because of the not yet updated release name. - it doesn't show errors during boot process and lo is up in ifconfig ( the lo change is not in -4 package it's just in cvs) > > Third thought. We should treat the initscripts as a real code project. > That is, place them beside the rest of the code and create real > tarballs. perhaps an idea when this fixing is finished an 2007.10/11 is released. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Dan McGee schrieb:
Two thoughts here, mostly for Tobias: * Version is 2007.08-4, shouldn't this be version 2007.10/11?
That's right. They should also include the new codename.
* When you made the lo change, did you ensure it is backward compatable? Having lo in your network array shouldn't cause an error now, because every current user will have it.
I wrote a few lines for rc.sysinit and sent them to tpowa. It just enabled lo with the default ifconfig line. If someone has lo in the network settings, it will be enabled again, so no harm is done. I think tpowa even included a check whether /sys/class/net/lo exists, so there won't be an error message when you boot a kernel with network disabled.
I wrote a few lines for rc.sysinit and sent them to tpowa. It just enabled lo with the default ifconfig line. If someone has lo in the network settings, it will be enabled again, so no harm is done.
I think the problem is more when you run /etc/rc.d/network stop than anything else... Jason
Jason Chu schrieb:
I wrote a few lines for rc.sysinit and sent them to tpowa. It just enabled lo with the default ifconfig line. If someone has lo in the network settings, it will be enabled again, so no harm is done.
I think the problem is more when you run /etc/rc.d/network stop than anything else...
We could advise people to remove 'lo' from their INTERFACES. It is removed by default in the new rc.conf.
Jan de Groot schrieb:
IMHO rc.sysinit should always enable the lo interface, unless it is specifically disabled (look for interfaces=(!lo) or !network in DAEMONS). Yes, this is inconsistent with the way we work in arch, but it will lower the amount of bugreports we get for this, while still giving people control over their lo interface if they want to disable it on purpose.
I agree on always bringing up lo. This should actually be hardcoded: Everybody needs lo, nobody needs it any differently. However, there should be no special handling of lo in rc.d/network in the way you propose, as this would make the scripts ugly and non-KISS. I don't see a problem with simply hardcoding this (you can put it right in the beginning, even before udev if you like).
On 10/18/07, Thomas Bächler <thomas@archlinux.org> wrote:
Jan de Groot schrieb:
IMHO rc.sysinit should always enable the lo interface, unless it is specifically disabled (look for interfaces=(!lo) or !network in DAEMONS). Yes, this is inconsistent with the way we work in arch, but it will lower the amount of bugreports we get for this, while still giving people control over their lo interface if they want to disable it on purpose.
I agree on always bringing up lo. This should actually be hardcoded: Everybody needs lo, nobody needs it any differently.
However, there should be no special handling of lo in rc.d/network in the way you propose, as this would make the scripts ugly and non-KISS. I don't see a problem with simply hardcoding this (you can put it right in the beginning, even before udev if you like).
I agree with thomas here. It's going to be an edge case that we don't need lo. If someone doesn't need it, it's a oneliner for rc.local
participants (7)
-
Aaron Griffin
-
Dan McGee
-
Jan de Groot
-
Jason Chu
-
Simo Leone
-
Thomas Bächler
-
Tobias Powalowski