Re: [arch-general] Multithreaded XZ
Jan Alexander Steffens on Mon, 2014/12/22 08:07:
> On Dec 22, 2014 8:00 AM, "Christian Hesse" wrote:
> > For Arch packages there is nothing that requires repeatable output.
>
> Yes, there is. Package signatures are made using the compressed package.
> Delta packages work by patching the uncompressed package and then
> recompressing it. If the compressor works differently the verification of
> the product will fail. I'm not sure xdelta3 in smart enough to compensate,
> or if the needed information is even there.
Ah, ok... Never used delta packages. You are right then.
But the same applies for other compression options, no? How is gzip
compression speed (-1...9 --fast --best) handled?
--
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);}
pgpyY0BN9PnQz.pgp
Description: OpenPGP digital signature
Re: [arch-general] Multithreaded XZ
On Dec 22, 2014 8:00 AM, "Christian Hesse" wrote: > For Arch packages there is nothing that requires repeatable output. Yes, there is. Package signatures are made using the compressed package. Delta packages work by patching the uncompressed package and then recompressing it. If the compressor works differently the verification of the product will fail. I'm not sure xdelta3 in smart enough to compensate, or if the needed information is even there.
Re: [arch-general] Multithreaded XZ
Jan Alexander Steffens on Mon, 2014/12/22 04:08:
> On Mon, Dec 22, 2014 at 3:25 AM, Mark Lee wrote:
> > Now that xz is multithreaded (not available in Arch Repos yet); I was
> > wondering if package building and installing would, by default,
> > utilize multiple threads.
Sure. I do use the multi-threaded version since the end of 2011 with my
xz-git package [0] from AUR.
Worked perfectly since then.
> It won't, since the output of XZ in multi-threaded mode is different
> from single-threaded mode. This will break anything relying on getting
> repeatable output from compression.
Yes, the output is different (and usually a little larger) for streams larger
than block-size. But that does not matter. Every xz version can decompress
every xz-compressed stream - including those created with multi-threaded xz.
For Arch packages there is nothing that requires repeatable output.
Building a package will generate new output one way or another - even a
changed package file timestamp will change the output.
Or did I get you wrong here?
> I'm not even sure it's possible to
> run XZ in multi-threaded mode with a single thread. xz -T1 uses
> single-threaded mode. xz -T1 --block-size=24M is also different from
> xz -T2 --block-size=24M.
>
> Multi-threaded decompression also requires a stream created using
> multi-threaded mode.
Yes. But it falls back to single-threaded mode without complaints.
[0] https://aur.archlinux.org/packages/xz-git/
--
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);}
pgp5Lhbu19lxm.pgp
Description: OpenPGP digital signature
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
Am 21.12.2014 um 22:48 schrieb Leonid Isaev: > On Sun, Dec 21, 2014 at 09:49:42PM +0100, Sebastiaan Lokhorst wrote: >> Thanks everyone for your responses! It seems that gdisk is still favorable >> for advanced tasks, but fdisk is can be used for basic tasks, as are >> usually required by beginners. > > No, that was my point: for "advanced" tasks you need neither. I never read the > beginners' guide, and don't care how it is formatted. I am just trying to > un-confuse people regarding the whole GPT vs MBR thing... If you want to un-confuse people, you can really simplify the instructions by using only fdisk in the beginner's guide. Then you have the same tool for both GPT and MBR. >> This is not true. Some low-end modern machines completely drop legacy BIOS >> boot. So booting via UEFI is required, and thus GPT is required. > > I really doubt this. Are you saying that some vendors on purpose break such > things as booting from an external USB key? I have a firmware that boots from USB fine in UEFI mode, but _only_ if it is formatted with MBR - it won't boot from GPT USB disks. Confusing, right? signature.asc Description: OpenPGP digital signature
Re: [arch-general] dhcpcd not working after install from custom iso
On December 17, 2014 2:46:07 PM EST, "P. A. López-Valencia" wrote: > >On 17/12/14 09:22, Christian Demsar wrote: >> I had internet connection when installing from an iso I built using >the >> archiso tools, but dhcpcd isn't connecting any more (starting via >> sytemd). I've also had internet access in previous installs of >archlinux >> and FreeBSD, so I don't think there's anything wrong with the >hardware. >> >> [dmesg output] http://pastebin.com/vtVRid1Y >> [ip link output] http://pastebin.com/gaZxUCmf > >You say you configured your connection with systemd. Do you mean you >enabled dhcpd@enp2s0.service? I suggest you disable it and use >systemd-networkd instead. It is very simple. > >Create a file called /etc/systemd/network/enp2s0.network that contains: > >[Match] >Name=enp2s0 >[Network] >DHCP=v4 > >Enable and start systemd-networkd.service and reboot. Your link should >come up online. Thanks for the suggestion, but it turned out to be user error. I rechecked the hardware addresses, and enp1s0 was actually the dedicated nic I have registered. This is odd, since I tried both devices initially, and neither worked. It's working now, at any rate. Nothing wrong with dhcpcd at all. -- vixsomnis
Re: [arch-general] Multithreaded XZ
On Mon, Dec 22, 2014 at 3:25 AM, Mark Lee wrote: > Now that xz is multithreaded (not available in Arch Repos yet); I was > wondering if package building and installing would, by default, > utilize multiple threads. It won't, since the output of XZ in multi-threaded mode is different from single-threaded mode. This will break anything relying on getting repeatable output from compression. I'm not even sure it's possible to run XZ in multi-threaded mode with a single thread. xz -T1 uses single-threaded mode. xz -T1 --block-size=24M is also different from xz -T2 --block-size=24M. Multi-threaded decompression also requires a stream created using multi-threaded mode.
Re: [arch-general] Multithreaded XZ
On Sun, Dec 21, 2014 at 8:25 PM, Mark Lee wrote: > > Now that xz is multithreaded (not available in Arch Repos yet); I was > wondering if package building and installing would, by default, > utilize multiple threads. You can do it already - just set the environment variable XZ_OPTS="-T x" (where x is the number of threads) to support it once your xz upgrades. See man xz(1) under ENVIRONMENT. -te
[arch-general] Multithreaded XZ
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To All, Now that xz is multithreaded (not available in Arch Repos yet); I was wondering if package building and installing would, by default, utilize multiple threads. Regards, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlSXgRsACgkQZ/Z80n6+J/Yc6AD+ORs6WkeCmLwlpPEGF/TWGqBX D1YBmbZRocJ8YqtovT8A+wc9spnkCF37mD3WrTRTBs6cCyRDurCpMQX1ZUg87FpQ =sMcR -END PGP SIGNATURE-
Re: [arch-general] hp myroom
> On Thu, Sep 11, 2014 at 12:48 PM, Javier Vasquez
> wrote:
> Hi,
> ...
> With virtualRooms I don't have any problems getting whatever is shared from
> the virtual rooms.
>
> With myRoom I can use the VoIP functionality, I can chat, I can share
> desktop, and from my room I can also share desktop.
>
> Weird enough, I can not get what others share to me on myRoom, or others'
> room shares.
>
> What I see is something popping up really quick and disappearing in a blink
> of an eye.
>
> I'm not using any DE, just a plain WM (fluxbox), so perhaps it might be some
> configuration missing, or some permissions issue.
>
> I also attempted xhost+, with no success. Though I didn't expect anything
> great from that, given I don't need it for virtualRooms.
> ...
OK, just in case any one had similar problems the problem got fixed on
a later release of hpmyroom. Now it's working on plain fluxbox.
At the end latest PKGBUILD...
Thanks,
--
Javier
--
pkgname=hpmyroom
pkgver=10.0.0.0210
pkgrel=0
pkgdesc="HP MyRoom"
url="https://www.myroom.hp.com";
arch=('i686' 'x86_64')
license="custom"
provides=('hpmyroom')
if [ $CARCH = 'i686' ] ;
then
debarch=i386
md5sums=('87040242987e821642fda506bf1734eb')
depends=('libutil-linux' 'libxss' 'libxfixes' 'libxtst' 'alsa-lib'
'libpng12' 'libsm' 'libice' 'libxrender' 'fontconfig' 'freetype2'
'libxext' 'libx11' 'zlib' 'glibc' 'glib2' 'gcc-libs' 'libxi' 'expat'
'bzip2' 'libpng' 'harfbuzz' 'libxcb' 'pcre' 'libxau' 'libxdmcp'
'libpulse')
else
debarch=amd64
md5sums=('79040052c999f741f12d84d049958b8c')
depends=('lib32-util-linux' 'lib32-libxss' 'lib32-libxfixes'
'lib32-libxtst' 'lib32-alsa-lib' 'lib32-libpng12' 'lib32-libsm'
'lib32-libice' 'lib32-libxrender' 'lib32-fontconfig' 'lib32-freetype2'
'lib32-libxext' 'lib32-libx11' 'lib32-zlib' 'lib32-glibc'
'lib32-glib2' 'lib32-gcc-libs' 'lib32-libxi' 'lib32-expat'
'lib32-bzip2' 'lib32-libpng' 'lib32-harfbuzz' 'lib32-libxcb'
'lib32-pcre' 'lib32-libxau' 'lib32-libxdmcp' 'lib32-libpulse')
fi
source=(https://www.myroom.hp.com/downloadfiles/${pkgname}_v${pkgver}_${debarch}.deb)
package() {
ar x ${pkgname}_v${pkgver}_${debarch}.deb
tar xf data.tar.xz --no-same-permissions --no-overwrite-dir -C $pkgdir
chmod a-x $pkgdir/usr/share/applications/HP-myroom.desktop
chmod a-x $pkgdir/usr/share/hpmyroom/cacerts.pem
chmod a-x $pkgdir/usr/share/hpmyroom/Resources/*
}
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
2014-12-21 22:48 GMT+01:00 Leonid Isaev : > > This is not true. Some low-end modern machines completely drop legacy > BIOS > > boot. So booting via UEFI is required, and thus GPT is required. > > I really doubt this. Are you saying that some vendors on purpose break such > things as booting from an external USB key? > USB keys can also boot in UEFI mode, see for instance the Arch install medium. But only if the creator of the key included an UEFI boot file of course. An example of newer laptops not having legacy BIOS (or at least disabling it): [1]. An explanation that legacy BIOS is optional: [2]. Thanks, Sebastiaan [1] http://h30434.www3.hp.com/t5/Notebook-Operating-Systems-and-Software/Pavilion-11-x2-no-legacy-option-in-bios-settings/td-p/3756368 [2] https://embedded.communities.intel.com/servlet/JiveServlet/previewBody/6775-102-1-1846/AMI_Intro_to_UEFI_PUB.pdf (see page 8-9)
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On Sun, Dec 21, 2014 at 09:49:42PM +0100, Sebastiaan Lokhorst wrote: > Thanks everyone for your responses! It seems that gdisk is still favorable > for advanced tasks, but fdisk is can be used for basic tasks, as are > usually required by beginners. No, that was my point: for "advanced" tasks you need neither. I never read the beginners' guide, and don't care how it is formatted. I am just trying to un-confuse people regarding the whole GPT vs MBR thing... > 2014-12-21 20:54 GMT+01:00 Leonid Isaev : > > > Yes. The age of a machine has no relevance for deciding whether to use GPT > > (or > > UEFI in general). > > > > This is not true. Some low-end modern machines completely drop legacy BIOS > boot. So booting via UEFI is required, and thus GPT is required. I really doubt this. Are you saying that some vendors on purpose break such things as booting from an external USB key? For example, I have an ExoPC tablet running Arch 64bit. It is true, that there is no checkbox in UEFI config saying "legacy BIOS". However, GPT partitioning is _not_ required at all. So, I nuked the EFI partition, made the entire SSD a LUKS container, and happily boot with MBR. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpZ7h3Hq2SiM.pgp Description: PGP signature
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
Thanks everyone for your responses! It seems that gdisk is still favorable for advanced tasks, but fdisk is can be used for basic tasks, as are usually required by beginners. 2014-12-17 5:43 GMT+01:00 Stefan Höck : > > However, I think we still should consider having only UEFI in the > beginners guide and link to a separate wiki entry if somebody needs an > MBR partition. > I really like this idea but I think it is not quite the time yet. We're trying to simplify everything else though, so I hope that the Beginners' guide will be clearer anyway. 2014-12-21 20:54 GMT+01:00 Leonid Isaev : > Yes. The age of a machine has no relevance for deciding whether to use GPT > (or > UEFI in general). > This is not true. Some low-end modern machines completely drop legacy BIOS boot. So booting via UEFI is required, and thus GPT is required. Thanks, Sebastiaan
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On Tue, Dec 16, 2014 at 08:15:26PM +0100, Bardur Arantsson wrote: > On 2014-12-16 19:58, Sebastiaan Lokhorst wrote: > > Hello everyone, > > > > Since more than a year now, fdisk (provided by util-linux) has had GPT > > support. This theoretically makes gdisk a duplicate of fdisk, and we could > > replace gdisk with fdisk. > > > > Now, I'm not asking to drop gdisk or anything like that, but in an effort > > to clean up the Beginners' guide of the Arch Wiki, we want to use a single > > partitioning tool for both MBR and GPT partitioning instructions.[1] > > util-linux fdisk is able to provide this functionality, but we are not > > completely sure if it is stable by now (it should be, I think). > > Speaking from complete ignorance... do significant numbers of people > still use MBR for non-obsolete platforms/machines? Yes. The age of a machine has no relevance for deciding whether to use GPT (or UEFI in general). Whenever I use LVM and/or LUKS, I set it up over the block device (like /dev/sda), not partitions (like /dev/sda1). So, there is no partition table at all. In this case, using legacy BIOS saves me from lots of UEFI-related headache. And of course, this entire motto of GPT "we support 20TiB drives" is just silly... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgptzAdvSs8a9.pgp Description: PGP signature
Re: [arch-general] Booting ArchLinux with `initscripts` is now broken
Hmm... If the other message wen through, my apologies, it is completely wrong. On 19/12/14 17:13, Ciprian Dorin Craciun wrote: Hello all! I'm in a little bit of a pickle, and I would like to ask for some help with my particular setup. I haven't switched to `systemd` and I'm still booting my system with the old `initscripts` `/etc/rc.sysinit` and friends (except this all the packages are up-to-date). Before updating `systemd` from 216 to 217, it still worked. Arch switched to systemd two years ago. Using other init is not supported in core, so you are on your own. Yes, you can use any init system you wish but don't expect to get support for it except from a very small niche of stalwart users. And runit is far more exotic than SysV init. P.S.: Just to be clear, I don't want to start a systemd flame war. My reason for not using it is simple: I already use `runit` and custom scripts for all my services (except `udevd` and `agetty`), and my setup relies on somewhat modified `/etc/rc.d/functions` script for encrypted devices. You would be better off using Void Linux I think. Back up your custom setup and try with that. -- Pedro Alejandro López-Valencia http://about.me/palopezv/
Re: [arch-general] Booting ArchLinux with `initscripts` is now broken
On 19/12/14 17:13, Ciprian Dorin Craciun wrote: Hello all! I'm in a little bit of a pickle, and I would like to ask for some help with my particular setup. I haven't switched to `systemd` and I'm still booting my system with the old `initscripts` `/etc/rc.sysinit` and friends (except this all the packages are up-to-date). Before updating `systemd` from 216 to 217, it still worked. Using systemd in Arch Linux is not supported. If you want to, you are on your own. P.S.: Just to be clear, I don't want to start a systemd flame war. My reason for not using it is simple: I already use `runit` and custom scripts for all my services (except `udevd` and `agetty`), and my setup relies on somewhat modified `/etc/rc.d/functions` script for encrypted devices. Use Void Linux, you 'll get what you want. -- Pedro Alejandro López-Valencia http://about.me/palopezv/
