Re: [arch-general] netctl provides wifi-menu which is unusable
> To: arch-general@archlinux.org > From: 31337h4c...@gmail.com > Date: Thu, 27 Feb 2014 04:44:20 + > Subject: Re: [arch-general] netctl provides wifi-menu which is unusable > > Nowaker gmail.com> writes: > >> >> Hey, >> >> Why does netctl provide /usr/bin/wifi-menu which is unusable at all, >> given the fact it needs /usr/bin/dialog to operate, and this is not a >> hard dependency of the package? >> >> I don't really get a point of providing a binary/script that doesn't >> work at all. What is it in the package for? >> >> If adding a dependency on dialog (big deal - 200KB) is not an option, >> why not extract wifi-menu to a separate package? This sounds like the >> best approach - the package could depend not only on dialog, but also on >> wpa_supplicant, dhcpcd and other package that anyone installs anyway to >> get wifi-menu working. >> > Have you looked at netctl's optional dependencies? It lists dialog along > with the message "for the menu based wifi assistant". The other packages > like dhcpcd and wpa_supplicant are also optional dependencies. He knows it's an optional dep. He filed a bug report and specifically said "No, optdepend is not desired.". The bug report was immediately closed as an optional dep is correct. I've really got to wonder what the rational is here, he doesn't want to pay attention to pacman's output, maybe?
Re: [arch-general] netctl provides wifi-menu which is unusable
Nowaker gmail.com> writes: > > Hey, > > Why does netctl provide /usr/bin/wifi-menu which is unusable at all, > given the fact it needs /usr/bin/dialog to operate, and this is not a > hard dependency of the package? > > I don't really get a point of providing a binary/script that doesn't > work at all. What is it in the package for? > > If adding a dependency on dialog (big deal - 200KB) is not an option, > why not extract wifi-menu to a separate package? This sounds like the > best approach - the package could depend not only on dialog, but also on > wpa_supplicant, dhcpcd and other package that anyone installs anyway to > get wifi-menu working. > Have you looked at netctl's optional dependencies? It lists dialog along with the message "for the menu based wifi assistant". The other packages like dhcpcd and wpa_supplicant are also optional dependencies.
Re: [arch-general] netctl provides wifi-menu which is unusable
On Wed, Feb 26, 2014 at 08:56:34PM -0600, Garrett Hopper wrote: > This would be great. It's always annoyed me that it's sitting there > unusable. > I don't usually play this card, but netcl takes up 7 kilobytes of disk space---an infinitesimal amount relative to many core *NIX utils---and only runs when executed by a user. Yes, I know that coreutils gets used a whole lot more than wifi-menu, but still... How much simpler can you get in this case? You could ditch netctl entirely and just use wpa_supplicant directly, provided you're not bothered by a wifi connection program that includes an interactive shell you may never use. As for dialog, If it is a dependency for netclt that's not explicitly declared, then a bug report should be filed (if one isn't already; there's a big systemd update coming not long from now, so netctl may be getting updated soon as well and the devs may already be on this).
Re: [arch-general] netctl provides wifi-menu which is unusable
This would be great. It's always annoyed me that it's sitting there unusable. On Wed, Feb 26, 2014 at 7:49 PM, Toyam Cox wrote: > Wifi-menu as a separate package makes the most sense, avoids the issue of > some netctl users not wanting wifi-menu, being able to configure their > networks themselves or using something else to search for wifi networks. > > > On Wed, Feb 26, 2014 at 8:35 PM, Daniel Leining > wrote: > > > Yeah, I agree on this. It should be a dependency of netctl, or wifi-menu > be > > a separate package with dialog as a dependency. > > > > Just my two cents. > > > > > > -- > - Toyam >
Re: [arch-general] netctl provides wifi-menu which is unusable
Wifi-menu as a separate package makes the most sense, avoids the issue of some netctl users not wanting wifi-menu, being able to configure their networks themselves or using something else to search for wifi networks. On Wed, Feb 26, 2014 at 8:35 PM, Daniel Leining wrote: > Yeah, I agree on this. It should be a dependency of netctl, or wifi-menu be > a separate package with dialog as a dependency. > > Just my two cents. > -- - Toyam
Re: [arch-general] netctl provides wifi-menu which is unusable
Yeah, I agree on this. It should be a dependency of netctl, or wifi-menu be a separate package with dialog as a dependency. Just my two cents.
[arch-general] netctl provides wifi-menu which is unusable
Hey, Why does netctl provide /usr/bin/wifi-menu which is unusable at all, given the fact it needs /usr/bin/dialog to operate, and this is not a hard dependency of the package? I don't really get a point of providing a binary/script that doesn't work at all. What is it in the package for? If adding a dependency on dialog (big deal - 200KB) is not an option, why not extract wifi-menu to a separate package? This sounds like the best approach - the package could depend not only on dialog, but also on wpa_supplicant, dhcpcd and other package that anyone installs anyway to get wifi-menu working. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
Re: [arch-general] Any way to change .PKGINFO post build w/o Rebuilding?
On Wed, 26 Feb 2014 15:06:36 -0600 "David C. Rankin" wrote: > On 02/26/2014 05:45 AM, Gesh wrote: > > A naïve reading of [1] suggests that makepkg -R should do the trick. > > However, as I'm away from my computer, I can't test > > this. > > Gesh > > [1] - https://www.archlinux.org/pacman/makepkg.8.html > > With just about every other package, that is OK, but not in the case of > tdebase. There are files autogenerated during Make and copied to 'pkg' that > are not present if makepkg -R is called (makepkg wipes out 'pkg' before > repackaging -- so in this case it will not work). That is what prompted this > manual question. Thanks though. Why is this a problem? If you have a build directory in src/, then autogenerated files are there, so makepkg -R will reexec package() which will copy those files again. If make(1) copies those files directly, i.e. not being instructed by the PKGBUILD, then your package is broken. Cheers, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Any way to change .PKGINFO post build w/o Rebuilding?
Op 26 feb. 2014 22:06 schreef "David C. Rankin" < drankina...@suddenlinkmail.com> het volgende: > > On 02/26/2014 05:45 AM, Gesh wrote: > > A naïve reading of [1] suggests that makepkg -R should do the trick. > > However, as I'm away from my computer, I can't test > > this. > > Gesh > > [1] - https://www.archlinux.org/pacman/makepkg.8.html > > With just about every other package, that is OK, but not in the case of tdebase. > There are files autogenerated during Make and copied to 'pkg' that are not > present if makepkg -R is called (makepkg wipes out 'pkg' before repackaging -- > so in this case it will not work). That is what prompted this manual question. > Thanks though. [...] Karol's reply pointed to repkg. A script by Xyne that basically exactly what you want. I didn't completely check it, but it ends with a call to bsdtar to (re)create the pkg. So using tar directly to unpack and repack should work fine ;-). mvg, Guus
Re: [arch-general] Any way to change .PKGINFO post build w/o Rebuilding?
On 02/26/2014 05:45 AM, Gesh wrote:
> A naïve reading of [1] suggests that makepkg -R should do the trick.
> However, as I'm away from my computer, I can't test
> this.
> Gesh
> [1] - https://www.archlinux.org/pacman/makepkg.8.html
With just about every other package, that is OK, but not in the case of tdebase.
There are files autogenerated during Make and copied to 'pkg' that are not
present if makepkg -R is called (makepkg wipes out 'pkg' before repackaging --
so in this case it will not work). That is what prompted this manual question.
Thanks though.
I tried manually editing Provides= and Replaces= and it would not work. Maybe I
had it wrong. If the existing package is 'tde-tdebase' and I create a new
package for testing 'tde-tdebase-systemd', how do I configure the
Provides/Replaces variable in the PKGBUILD file. I understood it to be:
pkgname='tde-tdebase-systemd'
provides=('tdebase' 'tde-tdebase')
replaces=('trinity-tdebase' 'tde-tdebase')
Is this not correct for the package 'tde-tdebase-systemd' to install and take
the place of 'tde-tdebase'?
In the .PKGINFO file, I modified it and attempted the install with:
replaces = trinity-tdebase
replaces = tde-tdebase
provides = tdebase
provides = tde-tdebase
It failed with the same error of each file conflicting. To get around it, I just
dropped to console and did
# pacman -Rdd tde-tdebase
# pacman -U tde-tdebase-systemd-R14preRC1-1-i686.pkg.tar.xz
That worked, but I am curious if manually changing .PKGINFO is possible.
--
David C. Rankin, J.D.,P.E.
Re: [arch-general] [arch-dev-public] systemd 209 in [testing]
On 02/20/2014 11:33 AM, Dave Reisner wrote: Hi all, I'm working on packaging the systemd 209 release, and I expect to have Good news. My problems ith 209 resolved after updating to 210. thank you!
Re: [arch-general] Bridge interface with netctl
On Wed, Feb 26, 2014 at 1:37 PM, arnaud gaboury wrote: > -- >> >> Now: >> * Populate the iptables FORWARD chain to route traffic from your physical >> interface to the bridge and back. > > I missed totally this part of the setup. I must admit this topic is a > little bit new to me. > Will try to go this way. > > The more I read and try with various set up, the less I understand and the more I break my container :-( I first managed to solve this empty /etc/resolve.conf by using /etc/resolveconf.conf facility. But now, on the container, with the netctl and network files cited before, I can not connect to network anymore. *The weird part is that inside the container, the "$ ip addr " command does not return br0, but only lo. No idea why. * Then, when testing various kind of netctl profiles, I remarked using a static IP in my bridge profile breaks immediately the connection to network on host. At first, I thought it had to do with my empty /etc/resolve.conf, but nada. This file stays now correct. So I am now with 24 hours of more work and a broken network on container! Nice job.
Re: [arch-general] Bridge interface with netctl
-- > > Now: > * Populate the iptables FORWARD chain to route traffic from your physical > interface to the bridge and back. I missed totally this part of the setup. I must admit this topic is a little bit new to me. Will try to go this way. -- google.com/+arnaudgabourygabx
[arch-general] gfortran upgrade => recompile packages
All the time when gfortran is bumped version, all fortran modules (file with .mod extensions) in other packages must be recompiled because module definitions are changed in the new compiler gfortran. Example : netcdf-fortran is broke currently if one try compile this code module test use netcdf end module test gfortran -I/usr/include -c test.f90 test.f90:2.7: use netcdf 1 Fatal Error: Cannot read module file 'netcdf.mod' opened at (1), because it was created by a different version of GNU Fortran
Re: [arch-general] Any way to change .PKGINFO post build w/o Rebuilding?
On February 26, 2014 10:52:43 AM GMT+02:00, Karol Blazewicz wrote: >On Wed, Feb 26, 2014 at 9:35 AM, Emil Lundberg > wrote: >> I don't mean to be rude, but have you tried it? Pacman packages are >> tar.gz archives, so my guess is it's possible >> >> /Emil. >> >> On Wed, Feb 26, 2014 at 4:13 PM, David C. Rankin >> wrote: >>> All, >>> >>> I patched tdebase for the logind-multiseat patch as was applied to >>> kde-workspace for Arch kde4. Doing so, I forgot to change the >provides= >>> replaces= information. Now the new package will not install due to >every file >>> conflicting with an existing file. The new file is named >'tde-tdebase-systemd' >>> and it replaces a package named 'tde-tdebase'. Can I decompress the >package and >>> manually edit the .PKGINFO file and then recompress the file and >have it work? >>> The package is unsigned if that makes any difference. What is >currently in the >>> .PKGINFO file is: >>> >>> # Generated by makepkg 4.1.2 >>> # using fakeroot version 1.20 >>> # Wed Feb 26 06:24:01 UTC 2014 >>> pkgname = tde-tdebase-systemd >>> pkgver = R14preRC1-1 >>> pkgdesc = Trinity Desktop Enviroment base components - TDE upstream >GIT >>> url = http://scm.trinitydesktop.org/scm/git/tdebase >>> builddate = 1393395841 >>> packager = David C. Rankin < drankinatty at gmail dot com > >>> size = 78513152 >>> arch = i686 >>> license = GPL >>> replaces = trinity-tdebase >>> >>> provides = tdebase >>> provides = tde-tdebase >>> >>> I think the change needed is: >>> >>> replaces = tde-tdebase >>> replaces = trinity-tdebase >>> provides = tdebase >>> provides = tde-tdebase >>> >>> Does this have a chance of working or should I just bite the >bullet and >>> rebuild the package? >>> >>> -- >>> David C. Rankin, J.D.,P.E. > >Try https://bbs.archlinux.org/viewtopic.php?pid=1285524 A naïve reading of [1] suggests that makepkg -R should do the trick. However, as I'm away from my computer, I can't test this. Gesh [1] - https://www.archlinux.org/pacman/makepkg.8.html
Re: [arch-general] Any way to change .PKGINFO post build w/o Rebuilding?
On Wed, Feb 26, 2014 at 9:35 AM, Emil Lundberg wrote: > I don't mean to be rude, but have you tried it? Pacman packages are > tar.gz archives, so my guess is it's possible > > /Emil. > > On Wed, Feb 26, 2014 at 4:13 PM, David C. Rankin > wrote: >> All, >> >> I patched tdebase for the logind-multiseat patch as was applied to >> kde-workspace for Arch kde4. Doing so, I forgot to change the provides= >> replaces= information. Now the new package will not install due to every file >> conflicting with an existing file. The new file is named >> 'tde-tdebase-systemd' >> and it replaces a package named 'tde-tdebase'. Can I decompress the package >> and >> manually edit the .PKGINFO file and then recompress the file and have it >> work? >> The package is unsigned if that makes any difference. What is currently in >> the >> .PKGINFO file is: >> >> # Generated by makepkg 4.1.2 >> # using fakeroot version 1.20 >> # Wed Feb 26 06:24:01 UTC 2014 >> pkgname = tde-tdebase-systemd >> pkgver = R14preRC1-1 >> pkgdesc = Trinity Desktop Enviroment base components - TDE upstream GIT >> url = http://scm.trinitydesktop.org/scm/git/tdebase >> builddate = 1393395841 >> packager = David C. Rankin < drankinatty at gmail dot com > >> size = 78513152 >> arch = i686 >> license = GPL >> replaces = trinity-tdebase >> >> provides = tdebase >> provides = tde-tdebase >> >> I think the change needed is: >> >> replaces = tde-tdebase >> replaces = trinity-tdebase >> provides = tdebase >> provides = tde-tdebase >> >> Does this have a chance of working or should I just bite the bullet and >> rebuild the package? >> >> -- >> David C. Rankin, J.D.,P.E. Try https://bbs.archlinux.org/viewtopic.php?pid=1285524
Re: [arch-general] Any way to change .PKGINFO post build w/o Rebuilding?
I don't mean to be rude, but have you tried it? Pacman packages are tar.gz archives, so my guess is it's possible /Emil. On Wed, Feb 26, 2014 at 4:13 PM, David C. Rankin wrote: > All, > > I patched tdebase for the logind-multiseat patch as was applied to > kde-workspace for Arch kde4. Doing so, I forgot to change the provides= > replaces= information. Now the new package will not install due to every file > conflicting with an existing file. The new file is named 'tde-tdebase-systemd' > and it replaces a package named 'tde-tdebase'. Can I decompress the package > and > manually edit the .PKGINFO file and then recompress the file and have it work? > The package is unsigned if that makes any difference. What is currently in the > .PKGINFO file is: > > # Generated by makepkg 4.1.2 > # using fakeroot version 1.20 > # Wed Feb 26 06:24:01 UTC 2014 > pkgname = tde-tdebase-systemd > pkgver = R14preRC1-1 > pkgdesc = Trinity Desktop Enviroment base components - TDE upstream GIT > url = http://scm.trinitydesktop.org/scm/git/tdebase > builddate = 1393395841 > packager = David C. Rankin < drankinatty at gmail dot com > > size = 78513152 > arch = i686 > license = GPL > replaces = trinity-tdebase > > provides = tdebase > provides = tde-tdebase > > I think the change needed is: > > replaces = tde-tdebase > replaces = trinity-tdebase > provides = tdebase > provides = tde-tdebase > > Does this have a chance of working or should I just bite the bullet and > rebuild the package? > > -- > David C. Rankin, J.D.,P.E.
Re: [arch-general] Bridge interface with netctl
> > This profile is wrong. Here is the right one: > --- > $ cat /etc/netctl/lxc_lan_bridge > Description="LAN bridge for LXC containers" > Connection=bridge > Interface=br0 > SkipNoCarrier="yes" > BindsToInterfaces=() > IP=static > Address=(10.137.0.1/24) > --- > Also, since you are running systemd >= 209, you can use networkd. Here are the > config files: > --- > $ cat /etc/systemd/network/lxc_bridge.netdev > [NetDev] > Name=br0 > Kind=bridge > $ cat /etc/systemd/network/lxc_bridge.network > [Match] > Name=br0 > > [Network] > Description=LAN bridge for LXC containers > DHCP=false > > [Address] > Address=10.137.0.1/24 > --- For now, I have a working setup, but I am not satisfied and I think I can improve it. *** % cat /etc/netctl/dhcp-hortensia Description='A basic dhcp ethernet connection' Interface=enp7s0 Connection=ethernet IP=dhcp * This profile is enable and start at boot. Then I manually # start bridge-hortensia *** % cat /etc/netctl/bridge-hortensia Description="Example Bridge connection" Interface=br0 Connection=bridge BindsToInterfaces=(enp7s0) IP=dhcp *** What puzzles me is that IF I enable the bridge profile, my system boots with a borken network with an empty /etc/resolv.conf. I would like to overcome this issue. Shall I go static ? Shall I start a specific profile before the other one? Why my resolv.conf is left empty when enabling both profiles ? then my systemd-networkd : ** % cat /etc/systemd/network/70-dahlia.netdev [Match] #Host=dahlia Virtualization=container [NetDev] Name=br0 Kind=bridge *** gabx@hortensia ➤➤ ~ % cat /etc/systemd/network/80-dahlia.network [Match] Virtualization=container MACAddress=14:da:e9:b5:7a:88 [Network] DHCP=yes [Address] Address=192.168.1.94 [Route] Gateway=192.168.1.254 ** Nothing on the container side, no netctl profile. This set up leave me with a working network. I can for example http://my_public_ip and then be on the nginx welcome page. But again this set up doesn't sound very academic neither solid to me. last: % ip addr 2: enp7s0: mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000 link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff inet6 fe80::16da:e9ff:feb5:7a88/64 scope link valid_lft forever preferred_lft forever 4: br0: mtu 1500 qdisc noqueue state UP group default link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff inet 192.168.1.94/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::16da:e9ff:feb5:7a88/64 scope link valid_lft forever preferred_lft forever As you can see, 192.168.1.94/24 is attached to br0, but no IP for my eth interface. Thank you for your help fine tuning this set up. It took me lots of reading and work (yes) to find a way to setup correctly the container network (and other). Documentation on container administered by systemd-nspawn are spare if non existent. I am left with the systemd man page and systemd-dev mailing list for lonely friends.
