Re: [arch-general] [RFC, after the fact] initscripts config
On Mon, Jul 23, 2012 at 12:46:52 +0200, Tom Gundersen wrote: > > 4.2) To be clear, is there going to be a separate configuration for > > the HARDWARECLOCK and TIMEZONE variables? > > There already are. That's the problem. HARDWARECLOCK is configured in > the third line of /etc/adjtime (see hwclock(8)), TIMEZONE is > configured by pointing the /etc/localtime symlink at what you want. What should it look like for people previously using "any other value" for HARDWARECLOCK? (for virtualization setups where there is no hardware clock) The manpage no longer mentions the "any other value" option, and hwclock(8) does not say anything about virtual systems either. Geert -- geert.hendrickx.be :: ge...@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
[arch-general] [arch-projects] [initscripts] [GIT] Arch Linux initscripts repository branch master updated. 2012.07.5-3-gf670511
Tom: >From your latest update to the initscripts in the git repo. This makes sure that systemd supports some initscripts API's. With this patch, systemd will: * Parse and use DAEMONS and MODULES from rc.conf * Run rc.local and rc.local.shutdown on boot and shutdown respectively I have everything working but my network with I load manually. I'm using journalctl etc instead of syslog Since systemd parses the rc.conf file now the only thing I should need in the daemons line is [ network ]. Is that correct? I tried to shoot the message below to you on the arch-projects list, but don't have access on that list to send you mail, so here it is. Tom: Good job. The one suggestion I have comes from my bent for making sure people don't miss things. I would estimate 90 to 95 percent of Arch users wouldn't miss and most others won't unless they are in a hurry (me). Would you consider it over the top to change the following line The local timezone is configured by symlinking /etc/localtime to the correct zoneinfo file under to The local timezone is configured by *symlinking* /etc/localtime to the correct zoneinfo file under making symlinking show up in bold text. Myra -- Life's fun when your sick and psychotic!
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2012 02:53 PM, Tom Gundersen wrote: > > Please file bugs if you think there are errors. Sometimes > "Type=forking" is the right thing to do. If the daemon is not > socket/dbus actiavted, then Type=forking is the only way to know if > a service has finished starting. > I am indeed finding in many cases I have to use 'forking'. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEzBnAAoJELT202JKF+xpJiQQAJwNawMLQsz1kBBv1aIvH/bM jx5jI9WWhVSv1x573c8hY04Yw3AUEBdHahvljOlzpQgVbtT9iHAdRvl2tl0S6PgV 2C9aKsdIyJQOLqHXCSI11FxSWv+qcbxuoj1TOzHvqLe2bBpWOCGz+FeXsjRvfbCq B4wLzcLYbsTSg/sQdkVW0AK9rupT1ahvDQNAFDMBTRvw6SEZtxqgLgcCndjLVKv0 u9v8rX5LEwklaowiWEDO/mTmij6XW4U3IM1WUG2DZnCBMHxqJegxGCQLyRq1pqn/ A5chjn2ppRhAQkzgX8WfCNCoGzgZ2rt1TNRhwYeeeosjkn5eIqzZu4qeTQlyOaiO j8175VdZ9uJ/0OkH6ZGUqKmuL6pyUGBcByjGxjdM8ctU0ol78BULVueZA2RVYR2+ xGQwr4JVlfuG1Euw4+yp9egUuB0FNRWp+vrcPcpFjbjQ9W8VhyUD7OslniUnaaNt Qe/0eBgq/gHlu8FDY/kf+h9031cFCzO+7hFs0wBmg5ziwTaSi5A/LN0o+AbBlOtq T5u+WXyTAej4ZmUGTfdWPQdW+VK77GI2vJMqzeEy9pizXmVx3LUFFPTDnknyaYC/ SsJ4dd6Q1G8Ko6mkQB0DYdpBpfBDwiscGK61xnZCvBTC1uHZ38fvNV8g694PVcMF Jftob66pCfB81/sfU8gi =plbc -END PGP SIGNATURE-
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2012 02:24 PM, Damjan wrote: > > I don't know what's that "kill dictd" but if it's a subprocess > started from your java program, systemd can handle it too. It puts > every service in its own CGroup so it know all the processes > started from that service. See man systemd.kill KillMode= > It turns out I do need KillSignal= for my memcached jobs. But when I include it in the service file it complains: Unknown lvalue 'Kill-Signal' in section 'Service'. Ignoring. I'm not understanding, then, where you put this. Thanks! - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEzAjAAoJELT202JKF+xpte0QAJWCiklk7gUi6uHXczxV5xnn B4ydHLUN8VMolWHh9keneHXKEPct5NtiILkT9vC6yGrldqGHtPhhwfIVwcXXeVGT OBB4zbujn/OAivjBtOd8gyQ4MxTmwbxterPc7VCku1IOcFLU8aSgNsFX8+EpM+hD pTVOv7gYCSZKqZbhq8sPC4cd+V/a/zoUM8ZIqLnbjFHd4ctMfFkEuz8aLh8cfEDO znnQUcL9ZiVsfBrBZJeauTpxPNKvvMdcC9SEXV8jggkZyr4Dm88kB9F/x/EeGij9 mzs/qxf1pSxiq1FZvn2VF5SKtyGMwr67qcJyooUugy/wDBZEuWRRsnkDcEVS5jP+ /0bcyQt65fijUQwih7FULQaZrQcutDzy6CwfbbDh/v3BXxxNiJ8RYiFGc0eXVqOd vK2bezZ1M155dWBvcfZkwmTN2jeo1vLQqOCpKa7Lem/FfrTUAff/W7l8zaH0QZHP 2NemIIjM+jwJWc1ZYaMMw6N2vHJsSupaJl4ZWHxME8G2HCj+0myhEJ287/1MnRWh 43bpoId8RC9rqE6OihJ8sU0boa+W+JzNleBI6UfJPIo9gQLa7n0wTYB2FenM7M8L Gtm8GHGCnmAEw1ohZL1Af5qidcJO6lKHDsAAzfhKFc4imora/oarPCpj8FUW13Pr MdQ9TBpofqHT1Qqv4ZbI =+oRJ -END PGP SIGNATURE-
[arch-general] System hangs at "Booting the kernel" upon drive addition
Hello, I have a system which is hanging during boot at the line "Booting the kernel" when I have a drive connected to either port of the PCI-Express SATA card I recently installed (chipset ASM1061). When a drive is not connected to the card, the system boots normally, and connecting the drive to the card after booting leads to no errors or other problems. I am running the latest version of linux and linux-headers in the core repository. It is worth noting that I also have an identical SATA card in the same system with two drives identical to the one in question connected to it. This setup has operated smoothly for about six months. Cheers, pants.
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
On Fri, Jul 27, 2012 at 4:53 PM, Tom Gundersen wrote: > On Fri, Jul 27, 2012 at 11:39 PM, C Anthony Risinger wrote: >> for example, i modify several .service files -- even ones that are >> shipped upstream -- because they are pointlessly configured as >> `forking` when they could be much better integrated (ddclient, dhcpd, >> hostapd, SEVERAL unfortunately) ... >> >> eg, in general, PID files are not needed anymore, and logs should go >> to STDOUT. so ... set the daemon to FOREGROUND, and DON'T redirect >> output (see man systemd.exec for stdout/err options, among others). > > Please file bugs if you think there are errors. Sometimes > "Type=forking" is the right thing to do. If the daemon is not > socket/dbus actiavted, then Type=forking is the only way to know if a > service has finished starting. ah, you/Mantas are probably correct here -- i didn't think about such cases -- i don't seem to be using anything in such a way to be negatively affected. for most of my custom stuff i've tried to use out-of-band triggers like sysfs files appearing/etc ... will explore this more, thanks. >> ExecStop=-/bin/kill $MAINPID > > Hm, this should be uneccesary, no? If no ExecStop is configured the > process will get a SIGTERM when the service is stopped. ah yes, right right ... i mainly wanted to demonstrate the simplicity of "not thinking in terms of rc.d scripts" ... which is now even simpler thanks to your "you don't need anything at all" :-) hard to get much more concise than "nothing". -- C Anthony
Re: [arch-general] Joining mp3's --> Floating point exceptionffmpeg
On Thu, Jul 26, 2012 at 8:14 PM, Nelson Marambio wrote: > Well, the cat-concept was the one I tried before - it may work fine for mp3s > with CBR, but with VBR it fails because you get an inaccurate track length. There are several tools to recalculate the VBR header; `mp3diags` is one of them. -- Mantas Mikulėnas
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
On 07/27/2012 02:24 PM, Damjan wrote:
>> So now that I've got a network through systemd, I ran into
>> trouble with some daemon service files that I crafted by hand.
>>
>> None of the following directives will work (culled from different
>> files):
>>
>> ExecStartPre=cd /etc/solr
>
> Use: WorkingDirectory=
>
>> ExecStart=$JAVA_HOME/bin/java -jar $JAVA_OPTS start.jar
>> $JETTY_OPTS >> /var/log/jetty.log 2>&1
>
> You shouldn't redirect stdout/stderr, let systemd handle it
>
> see StandardInput=, StandardOutput=, StandardError= in man
> systemd.exec
>
>
>> ExecStop=kill `pidof -o %PPID /usr/sbin/dictd` 2>/dev/null
>> 1>/dev/null
>
> I don't know what's that "kill dictd" but if it's a subprocess
> started from your java program, systemd can handle it too. It puts
> every service in its own CGroup so it know all the processes
> started from that service. See man systemd.kill KillMode=
>
Thanks for all the help here. 'cause I'm clueless.
Here's what I've got for dictd (which seems like a relatively simple
case):
[Unit]
Description=Dict Server
After=network.target
[Service]
Type=simple
EnvironmentFile=/etc/conf.d/dictd
ExecStart=/usr/sbin/dictd ${DICTD_ARGS} -- ${DICTD_EARGS}
Restart=always
[Install]
WantedBy=multi-user.target
Is this making sense?
Thanks!
- --
David Benfell
benf...@parts-unknown.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQExIdAAoJELT202JKF+xpbPIP/R1KB2d62nnil+BF1rLrz5oB
Fu9AtOodoS9IQnj1duM+PNDbSa55ePuL/HsoNEgRQ2PxrR906DhrHciIP3VeT01M
Ll2MX44nvsCpn+s4zDjJMxIy5F5yp0UWSrG1zPNmYLoTH4Zd50JyNCYq0xrj+9kM
K1qPI/RRHNYJXZJ31dih3D0AV3l8iGzjzfIn+toYQsy+KDjRkg8+73ZPoIpmYACt
DdraX+25QxAV6H91eFj27sk101Q6NG4GER3VeZbxTAIYTnOsfEEZjlFDslSXaLV3
OCVZGHkbuKxxMDFphm84S52oVRkFy8XJagJ76+DeMbwH7a44f/Q31dV8hXqrJiIT
EBFJEes1GtkiatmMM9UREaVsE45cFAcVdGA+NWsy6/j0P8E8y9tfGSCytIChEZcr
yn0sSFITuAi8kSgePD0KpTKV6lZlGoqkWfIeoeXtY0oXVJDx3O1s9CS3N5I5mp1i
YI33cXbcpWpvKRsSvOPdeT5gDyQubAkLwWq+dFZ2C3WRDh6eIkeEyQEnpjJUlYSb
GmFHJR1je3Z96kOdcr8EUwci+T6F4oTu2iXFWrcWggPHi8xIjsm+2dvRI/9VJ8iT
U6w1RU4wbk8wB0e+EzehcziXpufeYrpQF5LF6TMOAEeN8A4yVjUcTf7/URRAU1IK
tBliDW0dTGJl8U920mZ3
=yv1o
-END PGP SIGNATURE-
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
On Fri, Jul 27, 2012 at 11:39 PM, C Anthony Risinger wrote: > for example, i modify several .service files -- even ones that are > shipped upstream -- because they are pointlessly configured as > `forking` when they could be much better integrated (ddclient, dhcpd, > hostapd, SEVERAL unfortunately) ... > > eg, in general, PID files are not needed anymore, and logs should go > to STDOUT. so ... set the daemon to FOREGROUND, and DON'T redirect > output (see man systemd.exec for stdout/err options, among others). Please file bugs if you think there are errors. Sometimes "Type=forking" is the right thing to do. If the daemon is not socket/dbus actiavted, then Type=forking is the only way to know if a service has finished starting. > ExecStop=-/bin/kill $MAINPID Hm, this should be uneccesary, no? If no ExecStop is configured the process will get a SIGTERM when the service is stopped. -t
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
On Sat, Jul 28, 2012 at 12:39 AM, C Anthony Risinger wrote: > also note that you likely want to simply run the service differently > that you had previously. > > for example, i modify several .service files -- even ones that are > shipped upstream -- because they are pointlessly configured as > `forking` when they could be much better integrated (ddclient, dhcpd, > hostapd, SEVERAL unfortunately) ... They are often configured as Type=forking because they only fork after performing some form of initialization (e.g. dhcpcd [the client] might fork only after actually receiving a DHCP lease), and systemd will interpret this as a signal that the service has now started, without having to add systemd-specific sd_notify(). -- Mantas Mikulėnas
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
On Fri, Jul 27, 2012 at 4:04 PM, David Benfell
wrote:
> On 07/27/2012 02:01 PM, Tom Gundersen wrote:
>>
>> Not really, as far as I know. However, it seems that it is common
>> to put "helper scripts" that are shipped with systemd in
>> /usr/lib/systemd/ and those shipped with udev in /usr/lib/udev/,
>> so for user-created helper scripts, I think I'd put them in
>> /etc/systemd/.
>>
> That works for me. With some intervening logic to monitor the
> jobs--since systemd won't be able to monitor them itself--I think I
> can pull this off.
also note that you likely want to simply run the service differently
that you had previously.
for example, i modify several .service files -- even ones that are
shipped upstream -- because they are pointlessly configured as
`forking` when they could be much better integrated (ddclient, dhcpd,
hostapd, SEVERAL unfortunately) ...
eg, in general, PID files are not needed anymore, and logs should go
to STDOUT. so ... set the daemon to FOREGROUND, and DON'T redirect
output (see man systemd.exec for stdout/err options, among others).
... then you can just:
ExecStop=-/bin/kill $MAINPID
.. and be done with it :-)
part of succeeding with systemd is recognizing that 3/4 of the @#$%
-required- before is not only -unnecessary-, but now a hindrance!
other notes from your pasted unit file:
- Exec* requires absolute paths to binaries
- $JAVA_OPTS is different from ${JAVA_OPTS}; the former is subjected
to word-splitting while the latter is not (see man bash)
--
C Anthony
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
So now that I've got a network through systemd, I ran into trouble with some daemon service files that I crafted by hand. None of the following directives will work (culled from different files): ExecStartPre=cd /etc/solr Use: WorkingDirectory= ExecStart=$JAVA_HOME/bin/java -jar $JAVA_OPTS start.jar $JETTY_OPTS >> /var/log/jetty.log 2>&1 You shouldn't redirect stdout/stderr, let systemd handle it see StandardInput=, StandardOutput=, StandardError= in man systemd.exec > ExecStop=kill `pidof -o %PPID /usr/sbin/dictd` 2>/dev/null 1>/dev/null I don't know what's that "kill dictd" but if it's a subprocess started from your java program, systemd can handle it too. It puts every service in its own CGroup so it know all the processes started from that service. See man systemd.kill KillMode= -- дамјан
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2012 02:01 PM, Tom Gundersen wrote: > > Not really, as far as I know. However, it seems that it is common > to put "helper scripts" that are shipped with systemd in > /usr/lib/systemd/ and those shipped with udev in /usr/lib/udev/, > so for user-created helper scripts, I think I'd put them in > /etc/systemd/. > That works for me. With some intervening logic to monitor the jobs--since systemd won't be able to monitor them itself--I think I can pull this off. Thanks! - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEwJmAAoJELT202JKF+xp2EoP/RG8BI3mqw+BP3XdZtWusrct z/OTNGkwoZw9FuKLBGY9e5T1jbuZfAh/9nEwkgXSEqgglLTffo4KewNbPgqlv+X4 ziBSSFeYxL0dlgu2eNa2KNI+2mDg3UcF8bIUFxPf2y8IfdmGeNta1jjC7cIESoLz EWrZx8Ukf7hRrgcxn6PY//ET19FOxvx1Rs43Cwd7MhGES/bZBkKLYhg18eJaCBLN 4U/m1R1xRBbzkfqaW3gGsi1lHPnlHy9jeG8j82IbCImoW12mHR6XSgV6qAnJOMyu xcxHU+pagCy7U8SPs/KM3CGXebQ3UJeDS1383vPubljzxdjiTu3gj1EpBk9jh1G9 FAO0GDMtBq422RaF9wHLwLhX19leDusAEX/mU1m4d35MpOOd7mHkWK7Q6A7zmZbE prhjXUDilRX2uW3jTQDONLVaEn4Q4x9Dw0bpSbYTIQdDJ8Nnc2kJQL0ULuUAnvXX NRAg+sE+DEAQRDKI28VKXM0DmWlNSewJ9tbASqCh+SD43KCs0RhHmlQfKM/WGPkh YEp0oB4C1Ek2DqiZFJXcZLdJpaTiQIGrRsBLrIDFYVQH3V0zXVO24ZpK+GeT4h1Y MTaS3vng0CnzvAevDqbaPwRNVi5dk3sObLTyoQMq3gSKi5pIxLbnP6ORqVhbzKXI vz4XEPIvJXjMsfMdOnug =JJNz -END PGP SIGNATURE-
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
On Fri, Jul 27, 2012 at 10:52 PM, David Benfell wrote: > So now that I've got a network through systemd, I ran into trouble > with some daemon service files that I crafted by hand. > > None of the following directives will work (culled from different files): > > ExecStartPre=cd /etc/solr > ExecStart=$JAVA_HOME/bin/java -jar $JAVA_OPTS start.jar $JETTY_OPTS >> > /var/log/jetty.log 2>&1 > ExecStop=kill `pidof -o %PPID /usr/sbin/dictd` 2>/dev/null 1>/dev/null > > Basically lots of things that would be normal in a shell are > problematic. Yup, Exec* does not accept shell syntax, but does accept some variable substitution (see systemd.service(5) for details). > So I need to create separate scripts to start and stop > some daemons. I'm thinking I definitely do not want to use /etc/rc.d > for this (I had to back out and go back to init and /etc/rc.d is still > in use for that). > > Is there some consensus on where such scripts should go? Not really, as far as I know. However, it seems that it is common to put "helper scripts" that are shipped with systemd in /usr/lib/systemd/ and those shipped with udev in /usr/lib/udev/, so for user-created helper scripts, I think I'd put them in /etc/systemd/. -t
[arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, So now that I've got a network through systemd, I ran into trouble with some daemon service files that I crafted by hand. None of the following directives will work (culled from different files): ExecStartPre=cd /etc/solr ExecStart=$JAVA_HOME/bin/java -jar $JAVA_OPTS start.jar $JETTY_OPTS >> /var/log/jetty.log 2>&1 ExecStop=kill `pidof -o %PPID /usr/sbin/dictd` 2>/dev/null 1>/dev/null Basically lots of things that would be normal in a shell are problematic. So I need to create separate scripts to start and stop some daemons. I'm thinking I definitely do not want to use /etc/rc.d for this (I had to back out and go back to init and /etc/rc.d is still in use for that). Is there some consensus on where such scripts should go? - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEv+RAAoJELT202JKF+xp9rAP/1+hg9rapqIp8xI01vJ6Uvyd twIXA5bD3LvGS36FkCTmapdpcNKxGzCgxIoXcST0Qe1uJsrFboTl7LGJ14dmBBqg 05tqpvg6Vv4/tv+ac4S6dIO9uY0SmyzZoQMue5B0cvGvEAb7vcdh+dCjru0/YGis 8Nzsyyv3c/hJE43GIL4buz46cqKhcJqQyJAs8xXBbM50uchr2vpOQ6F2COMs196C 4NeLnPut4Gc5xZJd0cJmS/cqAYd7CYH0UX6gGYfxo9GT+CVoLJmnSeooNiRZZBAN uO/Fq7azsN8jRBWynmS0Ckqt5Dx1ErPyW/J2uj3UinMbg2XeOK2cLbmYAsmWyLIu 9fnWfsllHXEs+phbk4qUerojHDH4p/IQAyNV2FsiLVQmAV0FXKZB39NaM+7ws7z4 X9xbRcWKM8kTAflmPdiaGGmDJ7v8E0yhaB/0IbTbAhM2HDQxUVvgpHZFSyiQbR8T pED90wLp2iv10Jl16K/GRdn6GjMLS4QVftAWdPUyfR9NlLV/wPGVsB4jVmTmLzM5 jw0JJvKyrybZvJP0l/G/mUX+0KxHHcSQaldhTL2q5jlD+ZbHOda1inwgH5Dq+eJ2 ruJDNXYIy0Jy7fa1J3Wh+9FRk9LEo9VEdoQhPzjjhYXZ4qnkwRd5etmUun99v6/2 FX8jWC4EAX6Gb0gq9Fxh =zGji -END PGP SIGNATURE-
Re: [arch-general] Testing question
On Fri, Jul 27, 2012 at 9:20 PM, Florian Pritz wrote:
> On 27.07.2012 22:11, Leonidas Spyropoulos wrote:
>> Is there a way to enable the testing repo and install updates (with
>> pacman -Suyy) from the other repositories and only install updates
>> from testing if I explicitly mention it with some pacman command?
>
> Move [testing] below [extra] and [core] in pacman.conf. Do the same for
> [community-testing] and use pacman -S testing/whatever to install stuff.
right, I read on the wiki this is not recommended so I guess I will
stick to the normal repos for now.
No time to fix the pc due to testing..
>
> Just remember that you can run into problems if you do that, since this
> is somewhat similar to incomplete updates and pacman won't automatically
> pull newer dependencies from [testing].
>
> --
> Florian Pritz
>
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
Re: [arch-general] systemd network configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/26/2012 09:19 AM, C Anthony Risinger wrote: (that it worked for him. Does anyone know how to fix Thunderbird's quoting so that it actually quotes?) Okay, so this will be a real shocker. I was wrong. It works for me as well. Unsurprisingly, I have encountered other difficulties, but these are potentially topics for new threads. It looks to me like C Anthony's approach is a correct approach for network setups that don't fit into the standard netcfg/network paradigm. Thanks! - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEvwuAAoJELT202JKF+xpw+sP/3i/wu5Oh0JD8LkdLE/EgNn0 prjCNDg1GuncQxVcr7pYOwpTUw6XkNdyIxmIxgNt0XlbYb+gdjdHlaTxvuT7Trok AX7pLZh+4++/4y7YB6Al9ZRaGSv0ZdKkJzT/bkg1aJc3tutylaP7CwYdxL9Pjl/L UYLgMGrTEV47HdKGVYw43lnurx7fM1IOcv8ARevV+xYMGvNtNthteDHdXX+peekb Rpc7+5wYlBvCb/BUWSN1Ip2Cp1gTg+fjGL1bbQNXx/EJbaqVKB+QmxG1PReLp3o9 kmwkqv52pvoQhhCdZSyiFgtzPmcv4Vnk6OfIH1oNmCPfe6JLdK1lmRXi2TInu+Is CAcfXI+FbyMRXokPRwLaDieC4oUVghOCQScAYVeVpyz5Er1zlbMd5mgNG4ZIpy24 ZFb9BGurCSym/Xa6BPtq7hDuVg9KeucGqJZimLT8UEYboSvq/z5LrrGzKTTF/SoO qItlzf/Dd671y5dCXxhXTYyQWa83FEtzZCnuqUlxqVVu5v7Y2tXnIkqeObm9LnR9 4znZPk6IeewbqKAg8/sFsg1O+hEP2B/bbgjteGuqIuHzadohqDQPRBzToQobcrpR iYVPzpcofP4cXhfsIvMiKMmbkM/cAO3d5HsEfE/5e66u6IEpWVHMXC0KqZCtQjlS liPhVyl6DZaMvyKdPUbC =LZt2 -END PGP SIGNATURE-
Re: [arch-general] Testing question
On 27.07.2012 22:11, Leonidas Spyropoulos wrote: > Is there a way to enable the testing repo and install updates (with > pacman -Suyy) from the other repositories and only install updates > from testing if I explicitly mention it with some pacman command? Move [testing] below [extra] and [core] in pacman.conf. Do the same for [community-testing] and use pacman -S testing/whatever to install stuff. Just remember that you can run into problems if you do that, since this is somewhat similar to incomplete updates and pacman won't automatically pull newer dependencies from [testing]. -- Florian Pritz signature.asc Description: OpenPGP digital signature
Re: [arch-general] Testing question
You should never cherry pick updatates. It is all or nothing. Altought you can use syntax -S repo/pkgname. But if you are going to do that remember that I will be slaughtered for sharing this information, if you go complaining about how that broke your system. As long as you dont install system libs you should be relatively safe.
[arch-general] Testing question
Hey list,
Is there a way to enable the testing repo and install updates (with
pacman -Suyy) from the other repositories and only install updates
from testing if I explicitly mention it with some pacman command?
Thanks
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
Re: [arch-general] BIND 9 problem
tracepath dimitrisze.com:
1: 192.168.1.300.038ms pmtu 1500
1: 192.168.1.1 0.529ms asymm 2
1: 192.168.1.1 0.517ms asymm 2
2: no reply
3: no reply
ping dimitrisze.com:
PING dimitrisze.com (158.255.215.159) 56(84) bytes of data.
64 bytes from 159-215-255-158.static.edis.at (158.255.215.159): icmp_req=1
ttl=49 time=99.5 ms
64 bytes from 159-215-255-158.static.edis.at (158.255.215.159): icmp_req=2
ttl=49 time=105 ms
--- dimitrisze.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 99.507/102.559/105.611/3.052 ms
dig dimitrisze.com:
; <<>> DiG 9.9.1-P2 <<>> dimitrisze.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11827
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dimitrisze.com.IN A
;; ANSWER SECTION:
dimitrisze.com. 2369IN A 158.255.215.159
;; Query time: 65 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 27 20:06:55 2012
;; MSG SIZE rcvd: 59
WTF? ping & dig ok, but tracepath reports no reply!
--
(\_ /) copy the bunny to your profile
(0.o ) to help him achieve world domination.
(> <) come join the dark side.
/_|_\ (we have cookies.)
On Fri, Jul 27, 2012 at 10:44 PM, Damjan wrote:
> all my confs/zones: http://pastebin.com/z23HRyAh
>>> the ONLY thing altered in the confs is the domain
>>>
>>
>> 1. You are missing a $ORIGIN line at the top of your zone file:
>>
>> $ORIGIN dimitrisze.com.
>>
>> (Don't forget the dot after "com"!)
>>
>
> That $ORIGIN is implied by bind from the
> zone "dimitrisze.com" IN { ... }
> setting, so it's not necessary.
>
> I've avoided it usually since it allows me to have the same zone file for
> two zones that need to be kept in lock-step, for ex. domain.info and
> domain.com
>
>
> --
> дамјан
>
Re: [arch-general] [signoff] btrfs-progs
On Fri, Jul 27, 2012 at 9:03 PM, Tom Gundersen wrote:
> On Fri, Jul 27, 2012 at 10:00 PM, Jameson wrote:
>> On Fri, Jul 27, 2012 at 3:51 PM, Tom Gundersen wrote:
>>> On Fri, Jul 27, 2012 at 9:48 PM, Jameson wrote:
On Fri, Jul 27, 2012 at 3:32 PM, Leonidas Spyropoulos
wrote:
> Unfortunately none of my computers have multi-device btrfs now, used
> to have one for testing a couple of years ago
I have a multi-device volume, but I'm running systemd. I can validate
that btrfs-progs in testing didn't break my volume being mounted
automatically on a reboot.
>>>
>>> I assume you are then using the btrfs hook in mkinitcpio? Did you
>>> regenerate it before you rebooted? (mkinitcpio -p linux).
>>
>> Yep
>>
>> =-Jameson
>
> Thanks!
Tested btrfs-progs from testing in 64bit arch, produced image and
hook. I don't have a multi device though.
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
Re: [arch-general] [signoff] btrfs-progs
On Fri, Jul 27, 2012 at 10:00 PM, Jameson wrote: > On Fri, Jul 27, 2012 at 3:51 PM, Tom Gundersen wrote: >> On Fri, Jul 27, 2012 at 9:48 PM, Jameson wrote: >>> On Fri, Jul 27, 2012 at 3:32 PM, Leonidas Spyropoulos >>> wrote: Unfortunately none of my computers have multi-device btrfs now, used to have one for testing a couple of years ago >>> >>> I have a multi-device volume, but I'm running systemd. I can validate >>> that btrfs-progs in testing didn't break my volume being mounted >>> automatically on a reboot. >> >> I assume you are then using the btrfs hook in mkinitcpio? Did you >> regenerate it before you rebooted? (mkinitcpio -p linux). > > Yep > > =-Jameson Thanks!
Re: [arch-general] [signoff] btrfs-progs
On Fri, Jul 27, 2012 at 3:51 PM, Tom Gundersen wrote: > On Fri, Jul 27, 2012 at 9:48 PM, Jameson wrote: >> On Fri, Jul 27, 2012 at 3:32 PM, Leonidas Spyropoulos >> wrote: >>> Unfortunately none of my computers have multi-device btrfs now, used >>> to have one for testing a couple of years ago >> >> I have a multi-device volume, but I'm running systemd. I can validate >> that btrfs-progs in testing didn't break my volume being mounted >> automatically on a reboot. > > I assume you are then using the btrfs hook in mkinitcpio? Did you > regenerate it before you rebooted? (mkinitcpio -p linux). Yep =-Jameson
Re: [arch-general] [signoff] btrfs-progs
Hi, I installed btrfs-progs from testing and regenerated the image using mkinitcpio. It works fine and my btrfs volume is still being mounted correctly. I use systemd though and don't have any multi device btrfs volume either. On Sat, Jul 28, 2012 at 1:22 AM, Matthew Monaco wrote: > On 07/27/2012 01:04 PM, Tom Gundersen wrote: >> Hi guys, >> >> Seems not many of us yet use btrfs, I therefore would like to ask if >> any users can signoff on the btrfs-progs in testing (i.e. verify that >> the package appears to work). >> >> In particular, I'm interested to hear if someone who uses btrfs-progs >> and initscripts from testing could verify that the multi-device >> support still works? If you have the btrfs hook in your initramfs, >> then please enable udev too and regenerate the image to verify that >> that also still works. >> >> For those who are interested: the change we made was to scan btrfs >> devices for multi-device support using udev rules as the devices >> appear rather than doing it unconditionally after "all the devices >> should be ready". This approach should hopefully be more reliable than >> the old one. >> >> Cheers, >> >> Tom >> > > Last night in a fit of insomnia I decided to run btrfs-convert on my ext4 > root. > No problems at all so far =) > -- Aurko Roy GPG key: 0x20C5BC31 Fingerprint:76B4 9677 15BE 731D 1949 85BA 2A31 B442 20C5 BC31
Re: [arch-general] [signoff] btrfs-progs
On 07/27/2012 01:04 PM, Tom Gundersen wrote: > Hi guys, > > Seems not many of us yet use btrfs, I therefore would like to ask if > any users can signoff on the btrfs-progs in testing (i.e. verify that > the package appears to work). > > In particular, I'm interested to hear if someone who uses btrfs-progs > and initscripts from testing could verify that the multi-device > support still works? If you have the btrfs hook in your initramfs, > then please enable udev too and regenerate the image to verify that > that also still works. > > For those who are interested: the change we made was to scan btrfs > devices for multi-device support using udev rules as the devices > appear rather than doing it unconditionally after "all the devices > should be ready". This approach should hopefully be more reliable than > the old one. > > Cheers, > > Tom > Last night in a fit of insomnia I decided to run btrfs-convert on my ext4 root. No problems at all so far =) signature.asc Description: OpenPGP digital signature
Re: [arch-general] [signoff] btrfs-progs
On Fri, Jul 27, 2012 at 9:48 PM, Jameson wrote: > On Fri, Jul 27, 2012 at 3:32 PM, Leonidas Spyropoulos > wrote: >> Unfortunately none of my computers have multi-device btrfs now, used >> to have one for testing a couple of years ago > > I have a multi-device volume, but I'm running systemd. I can validate > that btrfs-progs in testing didn't break my volume being mounted > automatically on a reboot. I assume you are then using the btrfs hook in mkinitcpio? Did you regenerate it before you rebooted? (mkinitcpio -p linux). -t
Re: [arch-general] [signoff] btrfs-progs
On Fri, Jul 27, 2012 at 3:32 PM, Leonidas Spyropoulos wrote: > Unfortunately none of my computers have multi-device btrfs now, used > to have one for testing a couple of years ago I have a multi-device volume, but I'm running systemd. I can validate that btrfs-progs in testing didn't break my volume being mounted automatically on a reboot. =-Jameson
Re: [arch-general] BIND 9 problem
all my confs/zones: http://pastebin.com/z23HRyAh
the ONLY thing altered in the confs is the domain
1. You are missing a $ORIGIN line at the top of your zone file:
$ORIGIN dimitrisze.com.
(Don't forget the dot after "com"!)
That $ORIGIN is implied by bind from the
zone "dimitrisze.com" IN { ... }
setting, so it's not necessary.
I've avoided it usually since it allows me to have the same zone file
for two zones that need to be kept in lock-step, for ex. domain.info and
domain.com
--
дамјан
Re: [arch-general] [signoff] btrfs-progs
On Fri, Jul 27, 2012 at 8:04 PM, Tom Gundersen wrote:
> Hi guys,
>
> Seems not many of us yet use btrfs, I therefore would like to ask if
> any users can signoff on the btrfs-progs in testing (i.e. verify that
> the package appears to work).
I use btrfs for 3 years now the last 2 is my root and home partitions
(with regular backups).
I am not using testing repository, I can enable it and test
btrfs-progs. I usually just compile and install btrfs-progs from
Hugo's repository with latest patches.
>
> In particular, I'm interested to hear if someone who uses btrfs-progs
> and initscripts from testing could verify that the multi-device
> support still works? If you have the btrfs hook in your initramfs,
> then please enable udev too and regenerate the image to verify that
> that also still works.
Unfortunately none of my computers have multi-device btrfs now, used
to have one for testing a couple of years ago
>
> For those who are interested: the change we made was to scan btrfs
> devices for multi-device support using udev rules as the devices
> appear rather than doing it unconditionally after "all the devices
> should be ready". This approach should hopefully be more reliable than
> the old one.
>
> Cheers,
>
> Tom
Let me know if I can otherwise help.
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
Re: [arch-general] BIND 9 problem
I thought that it would be translated to my public ip... :P A dig proved that I was wrong, I fixed it, but now I have to wait 2 hours (TTL 7200) to update the zone? -- (\_ /) copy the bunny to your profile (0.o ) to help him achieve world domination. (> <) come join the dark side. /_|_\ (we have cookies.) On Fri, Jul 27, 2012 at 9:54 PM, Mantas Mikulėnas wrote: > On Fri, Jul 27, 2012 at 9:35 PM, Δημήτρης Ζέρβας <01tto...@gmail.com> > wrote: > > is the IP 0.0.0.0 ok? or do I have to change it to the actual public IP > > Why would you want to have 0.0.0.0 in DNS anyway? If you don't want to > have a "www" or "imap" or other subdomains, just delete them > completely... (But for "ns1", you must use the real public address of > the server.) > > -- > Mantas Mikulėnas >
[arch-general] [signoff] btrfs-progs
Hi guys, Seems not many of us yet use btrfs, I therefore would like to ask if any users can signoff on the btrfs-progs in testing (i.e. verify that the package appears to work). In particular, I'm interested to hear if someone who uses btrfs-progs and initscripts from testing could verify that the multi-device support still works? If you have the btrfs hook in your initramfs, then please enable udev too and regenerate the image to verify that that also still works. For those who are interested: the change we made was to scan btrfs devices for multi-device support using udev rules as the devices appear rather than doing it unconditionally after "all the devices should be ready". This approach should hopefully be more reliable than the old one. Cheers, Tom
Re: [arch-general] BIND 9 problem
On Fri, Jul 27, 2012 at 9:35 PM, Δημήτρης Ζέρβας <01tto...@gmail.com> wrote: > is the IP 0.0.0.0 ok? or do I have to change it to the actual public IP Why would you want to have 0.0.0.0 in DNS anyway? If you don't want to have a "www" or "imap" or other subdomains, just delete them completely... (But for "ns1", you must use the real public address of the server.) -- Mantas Mikulėnas
Re: [arch-general] BIND 9 problem
is the IP 0.0.0.0 ok? or do I have to change it to the actual public IP (it's static, so it won't be a problem) -- (\_ /) copy the bunny to your profile (0.o ) to help him achieve world domination. (> <) come join the dark side. /_|_\ (we have cookies.) On Fri, Jul 27, 2012 at 9:29 PM, Δημήτρης Ζέρβας <01tto...@gmail.com> wrote: > thanks a million man... > yes, you're right, domains are public :P > didn't know about named-check*! > > > -- > (\_ /) copy the bunny to your profile > (0.o ) to help him achieve world domination. > (> <) come join the dark side. > /_|_\ (we have cookies.) > > > > On Fri, Jul 27, 2012 at 7:17 PM, Mantas Mikulėnas wrote: > >> On Fri, Jul 27, 2012 at 5:55 PM, Δημήτρης Ζέρβας <01tto...@gmail.com> >> wrote: >> > I'm trying to set up my own DNS server but I can't... >> > I registered ns1.mydomain.com as a nameserver and I ponted it to my >> VPS's >> > IP. >> > the I listed ns1.mydomain.com as the nameserver of mydomain.com. >> > >> > I don't know if I've done something wrong with my registrar or my >> > zones/configs are wrong... >> > the logs are absolutely empty! >> > >> > all my confs/zones: http://pastebin.com/z23HRyAh >> > the ONLY thing altered in the confs is the domain >> >> 1. You are missing a $ORIGIN line at the top of your zone file: >> >> $ORIGIN dimitrisze.com. >> >> (Don't forget the dot after "com"!) >> >> 2. Your SOA record has a wrong MNAME (master DNS server name) field – >> it should point to a DNS server such as "ns1.mydomain.com." (or just >> "ns1" if you have $ORIGIN), not to the domain itself. >> >> 3. Your SOA field is missing the RNAME (responsible person name) field >> between MNAME and the serial number. It should point to an email >> address in DNS syntax, e.g. "01ttouch.gmail.com." or >> "hostmaster.mydomain.com." (or just "hostmaster"). >> >> http://pastebin.com/xPMzG8m2 should be correct. Use "named-checkzone" >> to verify zone files: >> >> named-checkzone mydomain.com/etc/named/domain-enabled/mydomain.com.db >> >> By the way, hiding the domain is 1) pointless since domain names are >> public anyway, 2) makes it much harder to answer such questions when I >> cannot look at the real information with `dig` and such. (You forgot >> to change line 63, though.) >> >> Also, using "notify no" is a poor idea – makes DNS updates a bit slower. >> >> -- >> Mantas Mikulėnas >> > >
Re: [arch-general] BIND 9 problem
thanks a million man... yes, you're right, domains are public :P didn't know about named-check*! -- (\_ /) copy the bunny to your profile (0.o ) to help him achieve world domination. (> <) come join the dark side. /_|_\ (we have cookies.) On Fri, Jul 27, 2012 at 7:17 PM, Mantas Mikulėnas wrote: > On Fri, Jul 27, 2012 at 5:55 PM, Δημήτρης Ζέρβας <01tto...@gmail.com> > wrote: > > I'm trying to set up my own DNS server but I can't... > > I registered ns1.mydomain.com as a nameserver and I ponted it to my > VPS's > > IP. > > the I listed ns1.mydomain.com as the nameserver of mydomain.com. > > > > I don't know if I've done something wrong with my registrar or my > > zones/configs are wrong... > > the logs are absolutely empty! > > > > all my confs/zones: http://pastebin.com/z23HRyAh > > the ONLY thing altered in the confs is the domain > > 1. You are missing a $ORIGIN line at the top of your zone file: > > $ORIGIN dimitrisze.com. > > (Don't forget the dot after "com"!) > > 2. Your SOA record has a wrong MNAME (master DNS server name) field – > it should point to a DNS server such as "ns1.mydomain.com." (or just > "ns1" if you have $ORIGIN), not to the domain itself. > > 3. Your SOA field is missing the RNAME (responsible person name) field > between MNAME and the serial number. It should point to an email > address in DNS syntax, e.g. "01ttouch.gmail.com." or > "hostmaster.mydomain.com." (or just "hostmaster"). > > http://pastebin.com/xPMzG8m2 should be correct. Use "named-checkzone" > to verify zone files: > > named-checkzone mydomain.com /etc/named/domain-enabled/mydomain.com.db > > By the way, hiding the domain is 1) pointless since domain names are > public anyway, 2) makes it much harder to answer such questions when I > cannot look at the real information with `dig` and such. (You forgot > to change line 63, though.) > > Also, using "notify no" is a poor idea – makes DNS updates a bit slower. > > -- > Mantas Mikulėnas >
Re: [arch-general] BIND 9 problem
On Fri, Jul 27, 2012 at 5:55 PM, Δημήτρης Ζέρβας <01tto...@gmail.com> wrote: > I'm trying to set up my own DNS server but I can't... > I registered ns1.mydomain.com as a nameserver and I ponted it to my VPS's > IP. > the I listed ns1.mydomain.com as the nameserver of mydomain.com. > > I don't know if I've done something wrong with my registrar or my > zones/configs are wrong... > the logs are absolutely empty! > > all my confs/zones: http://pastebin.com/z23HRyAh > the ONLY thing altered in the confs is the domain 1. You are missing a $ORIGIN line at the top of your zone file: $ORIGIN dimitrisze.com. (Don't forget the dot after "com"!) 2. Your SOA record has a wrong MNAME (master DNS server name) field – it should point to a DNS server such as "ns1.mydomain.com." (or just "ns1" if you have $ORIGIN), not to the domain itself. 3. Your SOA field is missing the RNAME (responsible person name) field between MNAME and the serial number. It should point to an email address in DNS syntax, e.g. "01ttouch.gmail.com." or "hostmaster.mydomain.com." (or just "hostmaster"). http://pastebin.com/xPMzG8m2 should be correct. Use "named-checkzone" to verify zone files: named-checkzone mydomain.com /etc/named/domain-enabled/mydomain.com.db By the way, hiding the domain is 1) pointless since domain names are public anyway, 2) makes it much harder to answer such questions when I cannot look at the real information with `dig` and such. (You forgot to change line 63, though.) Also, using "notify no" is a poor idea – makes DNS updates a bit slower. -- Mantas Mikulėnas
[arch-general] BIND 9 problem
hello, I'm trying to set up my own DNS server but I can't... I registered ns1.mydomain.com as a nameserver and I ponted it to my VPS's IP. the I listed ns1.mydomain.com as the nameserver of mydomain.com. I don't know if I've done something wrong with my registrar or my zones/configs are wrong... the logs are absolutely empty! all my confs/zones: http://pastebin.com/z23HRyAh the ONLY thing altered in the confs is the domain thank you in advance! -- (\_ /) copy the bunny to your profile (0.o ) to help him achieve world domination. (> <) come join the dark side. /_|_\ (we have cookies.)
Re: [arch-general] fish 2.0.0b2 in [community-testing]
On Thu, Jul 26, 2012 at 8:20 AM, Bartłomiej Piotrowski wrote: > As you probably know, fish release available in [community] is very old. > Code hasn't been updated since 2009. Official website doesn't work > currently, but there was the info that development is stalled. > > Alex Søndergaard suggested switching to Ridiculous Fish' fork[1]. It > provides almost identical set of features, but I'm not sure about > compatibility, that's why it goes to [community-testing] first. > > Current release "beta2" is rather pacman unfriendly, but incoming stable > release will be versioned as "2.0", so say hello to fish-2.0b2. > > Happy testing! > > [1] http://ridiculousfish.com/shell/ Thank you for packaging this gem. I follow the development of fish rather closely and I can say that the fish community, including the original author [1] treats this new fork as official. Development was moved over to github as the fish-shell-git AUR package reflects this. ridiculousfish and siteshwar have rewritten the code: "It's all in (sane) C++. No more string_buffer_t, array_list_t, or hash_table_t, and no more halloc!" [2]. [1] http://www.mail-archive.com/fish-users@lists.sourceforge.net/msg03063.html [2] http://www.mail-archive.com/fish-users@lists.sourceforge.net/msg03044.html
Re: [arch-general] Systemd : Analysis of reactions of Users
On 27/07/12 15:45, Stephen E. Baker wrote: > On 27/07/2012 9:29 AM, Mike wrote: >> On 27/07/12 13:57, Nicolas Sebrecht wrote: >>> The 27/07/12, Mike wrote: >>> I'm aware of that, but that doesn't mean one can't fix them. Nobody said, that the code base of sysvinit shouldn't be modified. >>> It would have been fixed for a long time if it were easy enough. :-) >>> >> Uhm there are init systems available that are baesd on or using sysvinit >> or at least are trying to stay compatible (e.g. upstart), without >> reinventing >> the wheel or declare the unix philosophy obsolote. >> > AFAIK systemd is trying to stay backwards compatible at least in the > sense that upstart is. It can parse old initscripts, and there is > even a target in archlinux that will read your DAEMONS array so you > can pretend you never switched. All this other stuff is just a more > powerful option in systemd that people can move to as they're ready. Not exactly, upstart is an relativly easy to handle sysvinit replacement, systemd is a lot more work. I don't want to pretend anything, systemd doesn't suit my needs, but I have no problems maintaining an init system on my own. I don't care if Arch would declare systemd as default today ;)
Re: [arch-general] Systemd : Analysis of reactions of Users
On Jul 27, 2012 3:57 PM, "Tom Gundersen" wrote: > > > On Jul 27, 2012 3:25 PM, "Jameson" wrote: > > > > On Thu, Jul 26, 2012 at 6:21 PM, Myra Nelson wrote: > > > quickly adapt to these types of changes. Many don't seem to grasp the > > > concept that both systems are still supported. In my case because of > > > my bull head and set ways, I still use the /etc/rc.d/network script > > > for starting my network and let systemd do the rest. With the current > > > > I'd recommend either netcfg, or networkmanager for networking under > > systemd depending on your needs. They each suit me well, and are well > > documented on the wiki. > > > > =-Jameson > > Yet hardly no one seems to be working on those systems outside of their respective distros. Makes one wonder... Sorry, answered the wrong message. This was aimed at the alternative init systems.
Re: [arch-general] Systemd : Analysis of reactions of Users
On Jul 27, 2012 3:25 PM, "Jameson" wrote: > > On Thu, Jul 26, 2012 at 6:21 PM, Myra Nelson wrote: > > quickly adapt to these types of changes. Many don't seem to grasp the > > concept that both systems are still supported. In my case because of > > my bull head and set ways, I still use the /etc/rc.d/network script > > for starting my network and let systemd do the rest. With the current > > I'd recommend either netcfg, or networkmanager for networking under > systemd depending on your needs. They each suit me well, and are well > documented on the wiki. > > =-Jameson Yet hardly no one seems to be working on those systems outside of their respective distros. Makes one wonder...
Re: [arch-general] Systemd : Analysis of reactions of Users
On Jul 27, 2012 3:16 PM, "Kevin Chadwick" wrote: > > > > May be this is a silly question but: will there be a general announcement > > > when systemd became officially adopted? > > > > That would be announced, yes. > > As you have said the timescale for initscripts being replaced by > systemd comes down to the challenges of maintenance and I guess this > is a question for that day as systemd is obviously a moving target but > as I would expect like ipv6 some people think systemd, event starts and > parallelism and it's binary size are more mature and sane than I do > (Of course without those users these things will have no chance of > becoming mature, compilation bug free, improved, unix-like, secure and > completely hackable in my eyes). > > I expect those maintenance challenges coem down to working for every > package so can even an unmaintained initscripts package be kept for > those of us who want to maintain just the scripts we use or do you > expect openrc to be a better base to work from or do you think a > switch to another tiny init binary distro to then be a better option? I don't see any reason for initscripts to stop working (might be that stuff like gnome will require systemd at some point, but that's our of our hands). Especially if the people who are so adamantly against systemd contribute to initscripts (by way of testing and bug reports). Oddly, that does not seem to happen much. Cheers, Tom
Re: [arch-general] Systemd : Analysis of reactions of Users
On 27/07/2012 9:29 AM, Mike wrote: On 27/07/12 13:57, Nicolas Sebrecht wrote: The 27/07/12, Mike wrote: I'm aware of that, but that doesn't mean one can't fix them. Nobody said, that the code base of sysvinit shouldn't be modified. It would have been fixed for a long time if it were easy enough. :-) Uhm there are init systems available that are baesd on or using sysvinit or at least are trying to stay compatible (e.g. upstart), without reinventing the wheel or declare the unix philosophy obsolote. AFAIK systemd is trying to stay backwards compatible at least in the sense that upstart is. It can parse old initscripts, and there is even a target in archlinux that will read your DAEMONS array so you can pretend you never switched. All this other stuff is just a more powerful option in systemd that people can move to as they're ready.
Re: [arch-general] Systemd : Analysis of reactions of Users
On 27/07/12 13:57, Nicolas Sebrecht wrote: > The 27/07/12, Mike wrote: > >> I'm aware of that, but that doesn't mean one can't fix them. Nobody >> said, that the code base of sysvinit shouldn't be modified. > It would have been fixed for a long time if it were easy enough. :-) > Uhm there are init systems available that are baesd on or using sysvinit or at least are trying to stay compatible (e.g. upstart), without reinventing the wheel or declare the unix philosophy obsolote.
Re: [arch-general] Systemd : Analysis of reactions of Users
On Thu, Jul 26, 2012 at 6:21 PM, Myra Nelson wrote: > quickly adapt to these types of changes. Many don't seem to grasp the > concept that both systems are still supported. In my case because of > my bull head and set ways, I still use the /etc/rc.d/network script > for starting my network and let systemd do the rest. With the current I'd recommend either netcfg, or networkmanager for networking under systemd depending on your needs. They each suit me well, and are well documented on the wiki. =-Jameson
Re: [arch-general] Systemd : Analysis of reactions of Users
> > May be this is a silly question but: will there be a general announcement > > when systemd became officially adopted? > > That would be announced, yes. As you have said the timescale for initscripts being replaced by systemd comes down to the challenges of maintenance and I guess this is a question for that day as systemd is obviously a moving target but as I would expect like ipv6 some people think systemd, event starts and parallelism and it's binary size are more mature and sane than I do (Of course without those users these things will have no chance of becoming mature, compilation bug free, improved, unix-like, secure and completely hackable in my eyes). I expect those maintenance challenges coem down to working for every package so can even an unmaintained initscripts package be kept for those of us who want to maintain just the scripts we use or do you expect openrc to be a better base to work from or do you think a switch to another tiny init binary distro to then be a better option? Thanks, Kc -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
[arch-general] Re: Systemd : Analysis of reactions of Users
The 27/07/12, Mike wrote: > I'm aware of that, but that doesn't mean one can't fix them. Nobody > said, that the code base of sysvinit shouldn't be modified. It would have been fixed for a long time if it were easy enough. :-) -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 23/07/12, Kevin Chadwick wrote: > Ignoring systemctl output which is still less clear and slowed me down. I don't agree. > Show what daemons will be running if you were to boot a filesystem > which isn't running and tell me it's as quick to work out on a systemd > system. http://fedoraproject.org/wiki/How_to_debug_Systemd_problems http://0pointer.de/blog/projects/self-documented-boot.html -- Nicolas Sebrecht
Re: [arch-general] Systemd : Analysis of reactions of Users
On 27/07/12 09:18, Nicolas Sebrecht wrote: > The 27/07/12, Mike wrote: > >> Instead of fixing such problems we need something new that's broken too? > You have to know that fixing was tried more than once with various > approaches along time. Parallelism is one of the best-known of these > failed attempts. Smart logs, correct error reporting are other examples. > > It's very hard to fix all the issues of init scripts. Some issues even > appeared to be nearly impossible to solve. > I'm aware of that, but that doesn't mean one can't fix them. Nobody said, that the code base of sysvinit shouldn't be modified. The problem with parallelism is to make sure that all dependencies are met. That works in systemd if and only if the unit files are done right (tm), this isn't any different to, e.g. upstart
[arch-general] Problems with mouse and keyboard on X
Hello, I am new to archlinux, coming from gentoo, and have successful installed the system so far. Now I have the problem that when I start X by using startx or startxfce4 (I have only tried this two) I have no keyboard or mouse. I can solve the problem by disconnecting and reconnecting mouse and keyboard. After that everything works fine until I restart my computer. To rule out problems with access rights I even used startx as root, but the same problem exisits. I suspect that something is wrong with udev (as I use evdev for mouse and keyboard) but so far I am not able to locate it. Has anyone some idea or lead for me? Greetings Sebastian Beßler
Re: [arch-general] How do you extract version from pacman?
Oon-Ee Ng on Fri, 2012/07/27 11:33:
> Thanks to Morris and Christian (karol too, but rather not have an
> additional package). Can't seem to find a reference to this specific
> behaviour on the pacman manpage, unfortunately, but it'll simplify my
> script.
>
> Looks like there's no way not to have the last -4 included though, but
> since that's version reference and quite important, I guess no way
> around me having to sed it out. Thanks again =)
Or use cut for that as well:
$ pacman -Q virtualbox | cut -d' ' -f2 | cut -d- -f1
4.1.18
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
Re: [arch-general] Systemd : Analysis of reactions of Users
On Jul 27, 2012 6:21 AM, "Martin Cigorraga" wrote: > > May be this is a silly question but: will there be a general announcement > when systemd became officially adopted? That would be announced, yes. > As T. G. said in the Dev list: > "If a move should happen, I suggest waiting a bit longer until more unit > files have been added to our various packages. And to allow some more time > to see if problems crop up." > > I'm as a final user would like to make the leap ony after systemd is already > adopted as the new AL official init manager. > > Kind regards, > Martin > > -- > -msx
[arch-general] Re: Systemd : Analysis of reactions of Users
The 27/07/12, Mike wrote: > Instead of fixing such problems we need something new that's broken too? You have to know that fixing was tried more than once with various approaches along time. Parallelism is one of the best-known of these failed attempts. Smart logs, correct error reporting are other examples. It's very hard to fix all the issues of init scripts. Some issues even appeared to be nearly impossible to solve. -- Nicolas Sebrecht
