[gentoo-dev] Re: RFC: 0-day bump requests
I'd like to add a few words from the users perspective: - 1) How do you feel when you receive an early version bump request? I hope developers are not annoyed - well, sometimes the words chosen are maybe a bit too offensive. I like these bump requests. I add myself as a CC and wait for some email in my inbox saying it's in the tree like most devs like to express it. Unfortunatly, i still have to wait half on hour, until the ebuild is available in the mirrors. Here's my little theory why there are these 0-day bump requests: Gentoo Maintainers seem to be very different. There are packages (opera for example) where we're offered the latest of the latest (even betas and pre-releases and stuff), and new versions are in portage before you've read the news on your favourite news-site. And on the other hand, there are packages like filezilla (to just name an example) where it took ages to get a new version. In addition, filezilla is one of the softwares that shouts at you: there is a new version of me available. get it now! And on the third hand (damn, humans only have two) there are important releases like pidgin 2.4.3 which has fixed the ICQ login issue. You saw the bump-request coming, didn't you? 2) If you had your way, would you discourage users from filing early version bump requests? - Oh please don't discourage bump-requests, even if they are 0-day. I like them because I CC to them. Regards, Sven -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [portage] download as-feature
In an ebuild, i'd like to specify an download as-filename. That means, out there, there is a file called http://host/myprogram-1.2.3/patch01; which i'd like to download as myprogram-1.2.3-patch01. http://bugs.gentoo.org/show_bug.cgi?id=177863 We're planning to support that in a coming EAPI (didn't make it into EAPI 1). Thanks for the hint. signature.asc Description: OpenPGP digital signature
[gentoo-dev] [portage] download as-feature
Hi, so a while back, i already had the problem. And just now, i ran into the problem again: In an ebuild, i'd like to specify an download as-filename. That means, out there, there is a file called http://host/myprogram-1.2.3/patch01; which i'd like to download as myprogram-1.2.3-patch01. Of course, there are multiple files out there: http://host/myprogram-1.2.1/patch01 http://host/myprogram-1.2.3/patch01 http://other.host/other-program-2.1.3/patch01 But current portage versions would download them all to /usr/portage/distfiles/patch01 which leads to a conflict. Of course, some collisions are intentional. But some are not, but cannot be avoided. Of course, this features needs some new SRC_URI-Syntax. Maybe something like SRC_URI=http://host/filename|download-as-finename. Do you think, this feature makes sense? (I want to discuss, before i make an RFE in BugZilla) Greetings, Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
There are many more ebuilds than just hal which fail with a compressed pci.ids file. And many of them are non-obvious. It took me more than I little bit of effort after the zlib USE flag was first added to the pciutils ebuild to figure out why so many packages where failing... Oh! Really? Which ones? So it seems, there are many many handwritten parsers out there? signature.asc Description: OpenPGP digital signature
[gentoo-dev] why? pciutils with zlib use-flag went stable on x86
Hi, so today, pciutils-2.2.4-r3 went stable on x86. It's a known issue, that pciutils compiled with zlib use-flag turned on (which is default) doesn't work with the version of hal, which is currently stable on x86. So at the moment, hal-0.5.9-r1 is stable on x86. It went stable weeks or even months ago. Now, pciutils-2.2.4-r3 is compiled with zlib use-flag turned on. There are now warning, errors, or any other messages about the zlib use-flag - well, until you recompile hal. The hal-ebuild checks, whether pciutils has been built with or without the zlib use-flag. But what is this check worth, if people have already upgraded hal weeks ago and the uncompatibility between pciutils and hal is now unnoticed? Why did you provocate this breakage? This is not a good idea, IMHO. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
Why did you provocate this breakage? This is not a good idea, IMHO. No. And many gave up getting this sensible again. As is, the default USE flags for a desktop profile lead to a compilation failure when unattended due to this, which is very very bad. I'm not even complaining about that. I will get a message, that i have to edit /etc/portage/package.use. So i do that, and after that i'm happy and everything compiles. But now, x86 users out there, will upgrade pciutils. They will not get any message about the breakage. They will not realize what's wrong. The hal-maintainers did their job: they checked, whether the zlib use-flag is set properly for pciutils. But this check is not executed, since hal has not been revbumbed on x86. And the pciutils-maintainers? They should check, where hal is installed - or maybe they should simply check the hal use-flag. And then, they should output a message, that the zlib use-flag would actually do harm. But the ebuild doesn't do that. So i think, right now, during these hours, clueless x86 gentoo users will upgrade their pciutils, not even realizing, that should do that with disabled zlib use-flag. I'm becoming a little sarcastic, but i hope, the problems with disharmony causes, will be noticed soon by others. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
Why did you provocate this breakage? Which breakage? It didn't install a gzipped pci.ids here. That is with USE=hal. Crap... Oh! So USE=hal forces pciutils not to use zlib? And so the check, which the hal ebuild performs, should be modified to check for USE=hal rather than for USE=!zlib ? signature.asc Description: OpenPGP digital signature
[gentoo-dev] USB disks - idea/question
Hi, so as you plugin a USB-disk, the kernel will recognize it, and it will be called sda, sdb, sdc or whatever ... I don't like that - why doesn't it get some more usefull device-name? Some device name, that a) indicates, that it is usb (for example put them to /dev/usb) and b) uses a numering not depending on how many harddisk there are in the system So for example /dev/usb/uda could be a symlink to /dev/sdb, /dev/usb/uda1 a symlink to /dev/sdb1 etc. (In this case, sda would be a normal harddisk, which is the reason why the usb-device is sdb) So i don't know any other distribution doing it like that. So what do you think? - is it possible? - is it a good idea? - is it such a good idea, so that gentoo becomes the first distribution doing it? - is it a bad idea to differ from all the other distros out there? Thanks, Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: USB disks - idea/question
Raymond Lewis Rebbeck schrieb: On Saturday, 23 December 2006 2:40, Sven Köhler wrote: Hi, so as you plugin a USB-disk, the kernel will recognize it, and it will be called sda, sdb, sdc or whatever ... I don't like that - why doesn't it get some more usefull device-name? Some device name, that a) indicates, that it is usb (for example put them to /dev/usb) and b) uses a numering not depending on how many harddisk there are in the system So for example /dev/usb/uda could be a symlink to /dev/sdb, /dev/usb/uda1 a symlink to /dev/sdb1 etc. (In this case, sda would be a normal harddisk, which is the reason why the usb-device is sdb) So i don't know any other distribution doing it like that. So what do you think? - is it possible? - is it a good idea? - is it such a good idea, so that gentoo becomes the first distribution doing it? - is it a bad idea to differ from all the other distros out there? Thanks, Sven Take a look at the contents of /dev/disk/ or if you don't like that, read up on writing your own udev rules and you can give devices whatever device node you want. /dev/disk is tooo fine grained. Imagine, i would be an administrator of lots of Linux-PCs in an unversity. What do i know about the label, uuid, path or id of the usb-stick that the user plugs into an arbitrary USB-plug of the computer? Well, not enough to use /dev/disk actually: i don't know the label i don't know the exact path i don't know the id and i guess i also don't know the uuid. So if i wanted to create a mountpoint for the first three usb mass storage devices (asuming, they only have one partition, as usual), i wouldn't be abled to do it. I will write my own udev-rules then - that's alright for me. Thanks for the hints/suggestions to all who answered! Greetings, Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] udev coldplugging and /etc/init.d/modules
Hi, when does udev load all the modules and does coldplug? Is it happening before /etc/init.d/modules? If yes, than i would like to shout: are you crazy? Well, until udev became stable, /etc/modules.autoload.d/kernel-2.? was a good place, to load modules in a specific order - before coldplug. Unfortunatly, the order of loading of modules defines the ordner of the network-interfaces (if you different types of network cards). So can you imagine, loading the modules before udev's coldplug happens? Greetings, Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: udev coldplugging and /etc/init.d/modules
Unfortunatly, the order of loading of modules defines the ordner of the network-interfaces (if you different types of network cards). This is what udev's interface renaming capability is for. Define names for your interfaces according to their MAC address, for example, and all is good. It's also more reliable than relying on the order of module loading to get it right. OK, Damn. Here i have a lack of knowledge. So what do i have to do, to configure udev that way? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: udev coldplugging and /etc/init.d/modules
As others have said, look at using udev to name your network devices in a persistant manner, it's the best solution. Yes, i agree. But i have thought about it, and i wonder, if it's going to work if: 1. udev loads the modules which results in a natural order: saying eth0 and eth1 are used. 2. my udev-rules say, that the network-card which has the natural name eth1 has to be called eth0 Will udev rename the card eth1 to eth0 and the card eth0 to eth1? Maybe udev also loads the modules in a way, so that the cards don't get any natural name by the kernel and instead, the udev-daemon has the full power to assign the names. signature.asc Description: OpenPGP digital signature
[gentoo-dev] /etc/udev/rules.d nightmare - orphaned files in /etc
Hi, i had some orphaned files in /etc/udev/rules.d. Namely 40-fuse.rules and 60-fuse.rules. The files were never removed, since they are protected - aren't they? So that is _very_, _very_ unpractical, because the older your gentoo gets, the more of such orphaned files you get. Have you ever thought about sollutions of that problem? It's not a real problem, that these files are orphaned - but they are neither removed nor renamed, so they stay in place and in one or the other way, they may start to disturb. So how about renaming them from file to ._cfgsave_file? Anyway, this really asks for a sollution. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: baselayout-1.13 going into ~ARCH soon
In 1.13, we've removed the variable from /etc/conf.d/rc and it's now forced to /lib/rcscripts/init.d which is safe as /lib is always on the same partition as /. From a filesystem usage point of view though, storing actively changing state data on /lib is ugly. The tmpfs /lib/rcscripts/init.d overlay solution for a ro / works, but as long as tmpfs magic is needed, can't it be written to /var after localmount? After reading all the concerns and doubt and things, i ask myself: why not keep in a tmpfs? Well, it can be swapped out too, and it isn't too much data anyway, is it? The most disturbing thing to me, would be yet another entry when i watch the list mountpoints. signature.asc Description: OpenPGP digital signature
[gentoo-dev] why is net.eth0 started, even though it's not in any runlevel?
Hi, when i load the module for my network-card, then baselayout thinks, that it's a good idea to a) start net.eth0 even though it's not in any runlevel and b) start net.eth0 in runlevel boot. So that's something, that i don't really understand. I think, that the following behaviour would be more more intuitive: a) check if net.eth0 is really configured to be started within this boot (for example it wouldn't be nice, if net.eth0 is started, even though we're booting into runlevel nonetwork) b) schedule net.eth0 to be started later, when we really enter the runlevel default for which net.eth0 is configured I think, you will actually tell me to use RC_PLUG_SERVICES in /etc/conf.d/rc to disable hotplug triggered started of net.eth0. But does it really solve everything? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: why is net.eth0 started, even though it's not in any runlevel?
when i load the module for my network-card, then baselayout thinks, that it's a good idea to a) start net.eth0 even though it's not in any runlevel and b) start net.eth0 in runlevel boot. yes, the default behavior is to do hot/cold plugging That is not a problem. The problem is, that the admin loses control over the runlevels. if you dont like that, you're free to: I think, you will actually tell me to use RC_PLUG_SERVICES in /etc/conf.d/rc to disable hotplug triggered started of net.eth0. But does it really solve everything? i disable hot/cold plugging completely myself i see, another sollution could be: instead of having tweo states per service and runlevel (enabled, disabled), gentoo could introduce a tristate-logic: services can be disabled, enabled or they can be set to auto. These states have the following meaning: disabled: the service does not start and will not be started by any hot/coldplugging enabled: the service is started on boot (and maybe not by hot/cludplugging) auto: the service started by hot/coldplugging things signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: X.Org 7.1 is Stable
X.Org 7.1 has been released from its binary driver jail to the (un?)stable masses! Does it build? Only on Tuesdays! Does it run? Often! Will it damage your system? I like cheese! Hmm, xorg-server-1.1* is stable now, but xorg-x11-7.1 is not. Did you forget that ebuild? ;-) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: How default route should be set by pppd
I discovered that ppp-2.4.4 set a default route without a gateway. It is totally fine from IP routing point of view (the simple fact that route is through the point-to-point link is enough to know the next hop), except that openswan's %defaultroute need a default gateway in order to work. I'm about to apply a patch that would reverse to the old way of setting the default route. Any objections? Why not? Such routes work perfectly here. I also use them for my PPTP tunnel: route add -net 1.2.3.4/24 dev ppp1 Works perfectly! I think it simply means: take all IP-packets with destination 1.2.3.4/24 and send them out through interface ppp1. We know such routes from local network-interfaces. Actually, i also always thought, that i must specify a gateway. But it seems, i was wrong. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: How default route should be set by pppd
default dev ppp0 scope link instead default via a.b.c.d dev ppp0. And? What the difference? For the P-t-P connection, there is not difference. There is only one destination, you can send the packets to: the ppp-server on the other side. Only for normal network-connections (eth0, ...), you have to tell the kernel, which host in the subnet he has to send the packets to, because usually there are many of them. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: media-gfx/imagemagick needs a temp maintainer
So before PerlMagick becomes independant of ImageMagick's configure, upstream must change a few things. Has it changed that much recently? Because it *was* seperate for aeons and aeons before this. Installing perlmagick via use flag is a recent edition in the scheme of things. I'm sorry, but how sure are you about this? Have you ever looked into Makefile.PL in the past? Or have you even taken a look at the Makefile.PL.in is it existed? It shows that many of the -l-options are generated by configure. (Makefile.PL.in is template for configure - you surely know that) Or are we talking about some seperate PerlMagick-Distribution? I'm talking about the PerlMagick which comes with imagemagick's tarball. Actually, Makefile.PL should use pkgconfig or whatever is available to detect all those -l options - or actually it's also sufficient to only do -lMagick - who knows? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: media-gfx/imagemagick needs a temp maintainer
the maintainer of media-gfx/imagemagick sekretarz is not responding to bugmail and the package has two open security bugs. https://bugs.gentoo.org/show_bug.cgi?id=143533 https://bugs.gentoo.org/show_bug.cgi?id=144091 Anyone willing to help take care of this package please CC yourself on the bugs and provide a bump. Not to forget that one: https://bugs.gentoo.org/show_bug.cgi?id=121142 Well, it's not as important as security fixed, but well - if the new imagemagick-version, which became stabel recently, would have a new version for the libMagick.so, then users would have a broken perl-module again. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: media-gfx/imagemagick needs a temp maintainer
the maintainer of media-gfx/imagemagick sekretarz is not responding to bugmail and the package has two open security bugs. https://bugs.gentoo.org/show_bug.cgi?id=143533 https://bugs.gentoo.org/show_bug.cgi?id=144091 Anyone willing to help take care of this package please CC yourself on the bugs and provide a bump. Not to forget that one: https://bugs.gentoo.org/show_bug.cgi?id=121142 Well, it's not as important as security fixed, but well - if the new imagemagick-version, which became stabel recently, would have a new version for the libMagick.so, then users would have a broken perl-module again. Makes me wonder if we shouldn't just resurect the perlmagic ebuild again and be done with it. The Makefile.PL gets recreated by ImageMagick's configure. Normally, it contains a huge list of libraries in the linker call. If lots of use-flags are turned off, we might run into problems if we simply use the Makefile.PL (which exists, but as i said, it _normally_ gets re-created when running configure). So before PerlMagick becomes independant of ImageMagick's configure, upstream must change a few things. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Why you use Gentoo [user]
So, wondering why people use Gentoo. Put [dev] or something if you're an actual gentoo dev and [user] if you're a user. Doesn't need to be fancy, you can put community or something if that's all you want. All responses off list please. Thanks. Hi, so i'm using Gentoo because of the flexibility and because there is no support for SuSE Linux 8 has exprired-thing. Gentoo systems live on, somehow. A new openssl series, a new gcc, a new glibc - hey! who cares? My Gentoo-system lives on. I don't have to upgrade from SuSE 10.0 to 10.1 or something. Gentoo has the right tools: revdep-rebuild and so on! Simply great work! And oh: PostgreSQL 8.0 is not stable yet? No problem with Gentoo! I just unmask it, and the rest of system keeps using the stable x86-packages. What did you say? You cannot just take the PostGreSQL 8.0 DEB from Debian unstable and install it on your stable SuSE or Debian? It depends on the newer unstable glibc package? LOL! That all the packages are compiled brings so many advantages sometimes. But of course it takes time to install and maintain Gentoo - more time than SuSE or Debian of course. Then this great great baselayout! It's simply brilliant! And it's sooo easy to write your own ebuilds! No ./configure --prefix=/path/to/my_sofware-mess anymore! I write my own ebuilds and the software i need gets installed like any other package. Greetings, Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] I'm concerned about a bug (#121142, imagemagick)
Hi, it's this bug: https://bugs.gentoo.org/show_bug.cgi?id=121142 There's no comment by the maintainer for a while. I wrote the patches that are needed to fix the problem. They work fine as far as i can tell. So what's wrong wrong here? I don't want to sell my patches to anyone. But i'd like to see that bug fixed! It exists for several versions now, and the sollution is now available - i even explained what and why i did what i did in the patches. So can somebody take care of this? I understand, if the maintainer is on holidays, does not have much time at the moment and so on - but not enough time for just a comment? Greetings, Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: I'm concerned about a bug (#121142, imagemagick)
There's no comment by the maintainer for a while. I wrote the patches that are needed to fix the problem. They work fine as far as i can tell. Don't feel too bad - I frequently post patches to bugs reported on the same day and ask for feedback. Some of which are now over a year old without any feedback from the reporter. Sadly, true... People are busy with other things too often. This issue is very annoying, perhaps someone from graphics herd should pick this up and commit it (yes, it works for me as well). Hmm, so i've uploaded new patches. They have the advantage, that they don't require patching PerlMagick/Makefile.am and therefor the ebuild does not require running eautoreconf and can use more or less vanilla sources. Perhaps i will do the legwork and try to convince some developers to submit some patches upstream, so that future releases of ImageMagick are more Gentoo-friendly. Greetings, Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: net-misc/bcm4400 going away
net-misc/bcm4400 is a kernel driver built as an external package through portage. The codebase which this package use has been discontinued upstream. The upstream replacement (which is not in Portage directly) is simply a copy of the in-kernel b44 driver code. For this reason we are suggesting everyone migrates to the b44 in-kernel driver (I guess net-misc/bcm4400 doesn't really have any users anyway...). As i said in Bugzilla already: I had problems with the in-kernel driver some kernel-versions ago (like 2.6.15) and since then, i'm using the bcm4400 which worked much much better concerning details like getting an address via dhcp and such things. Since yesterday, i'm now testing/using the in-kernel driver of 2.6.17.11 and as far as i can see, it works great. So hopefully no problems come up again. signature.asc Description: OpenPGP digital signature
[gentoo-dev] 2006.1 server profile
Hey you Gentoo-Developers! On gentoo.org, in the great announcement of Gentoo 2006.1, it says: The most popular architectures now use GCC 4.1, glibc 2.4 and baselayout 1.12.1, as well as including a new profile layout, with separate desktop and server profiles. So i took you at your word, but what do i get when i use the profile /usr/portage/profiles/default-linux/x86/2006.1/server/ ? I get this message: This profile has not been tested thoroughly and is not considered to be a supported server profile at this time. For a supported server profile, please check the Hardened project (http://hadrened.gentoo.org). And at least to me, it seems to be the opposite of what has been announced. (Beside that, there is a spelling mistake: it should read hardened, not hadrened) Just my disappointed impression. Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Make FEATURES=test the default
I'd like to suggest we make FEATURES=test (and therefore USE=test) the default behaviour, rather than the opt-in we currently have. Far too many packages fail their test phase. I have a related question, but first a comment: I like the idea, that packages run their self-tests before they get marked stable. And if it should become default and a user doesn't want it, he can disable it. So what? So my question is: where's the difference between USE=test and FEATURES=test ? So FEATURES=test means, that portage runs src_test(), right? So what does USE=test mean? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Making dobin, doexe, doins, doman, dodoc die by default
This came up in Bug 138792 [dobin etc. should automatically die on failure] It needs more discussion on the mailing lists. Some excerpts from the bug: The proposal from Paul Bredbury: Hi, I propose that the following ebuild commands themselves *die* on failure, because the vast majority of the time the emerge might as well be considered a failure if such commands fail. dobin, dosbin, doexe So what do you think? Since it does not seem to be too popular, to let dobin, etc. die, i would suggest writing a big fat red QA: command 'dobin xyz' failed on the screen, so that even the last user notices that. Perhaps also writing those QA-warnings to emerge.log? Is that aready done at the moment? If not, i would suggest that - and actually i would rather like that dobin, etc. die on error. Well, but some people here claim, that the ebuilds are not tested that much, before they go into portage. Well, that's another decision: what should gentoo's quality be like? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: using specific gcc-version in ebuild
I've been thinking about this recently. What qemu does is compile a C implementation of the target processor's instruction set into an object file when qemu is built, then at run-time (JIT time) it cut-n-pastes bits of that object file when it compiles the target executable into native code that can be executed directly in the emulator. This is pretty cool, as it means you have a cross-platform target emulator that is fast because it leverages the compiler to write the emulation code, without having to maintain separate implementations for each target. However it does rely on the ability to snip the function prologue/epilogue reliably so you can stitch stuff together (in particular the return instruction is eliminated), and with gcc-4 this is no longer possible because the return is not always and only at the end of the function. I think the change to gcc that causes this is one of the reasons the major revision number was increased. The reason for describing this is to illustrate that qemu is not broken as such; it just relies on implementation detail of the pre-4 gcc series. Since gcc-4 doesn't provide any option to force code generation to fit the requirements of qemu, the compilation of the affected code must use gcc-3 (which it does with a very specific set of CFLAGS). Note; the majority of qemu can be compiled with gcc-4 just fine, however the target implementation objects have to be built with gcc-3 because gcc-4 does not provide an option to get the old gcc-3 behaviour. You take the words out of my mouth. That is exactly, what i'm after. Actually i know, that there are aware of problems that may be caused by using different compilers for different parts of software. But for qemu, this is possibly a must. While gentoo-ebuilds will still complain and force people to switch gcc by hand, other distros may simply offer a qemu built with a different gcc-version than the system-wide one. Since we already have slotted gcc working just fine, it seems reasonable to me that we could support packages requiring the existence of more than one compiler version (although I'm not sure portage DEPENDs will cope - I'm guessing: DEPEND=sys-devel/gcc-4 =sys-devel/gcc-4 won't be interpreted to mean both a pre-4 and a post-4 compiler are required). I think, this does what you don't expect it to do. I remember a bug, where a maintainer wanted to depend on a package, but only a certain version-interval. He used exactly something like you wrote it above. In the end, two versions of the package were installed, and some people agreed on the necessity for a syntax for a version-interval. (which is still not in portage 2.1 afaik) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: using specific gcc-version in ebuild
then it's broken by design ... sure the idea about how qemu goes about its emulation is pretty goddamn cool, but gcc has never said that you can rely on certain behavior very right! but you cannot change the world :-( signature.asc Description: OpenPGP digital signature
[gentoo-dev] using specific gcc-version in ebuild
Hi, i just wanted to ask, if the is an eclass or something else, that enables me to temporarly select a certain gcc-version? or perhaps just finding the path to the gcc and g++ executables of a specific gcc-versions (like gcc-3.*)? some software, like qemu and others, are simply not compatible with gcc 4.x and they will not become compatible due to severe conceptional issues. So is there already something i could use? Thanks, Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: using specific gcc-version in ebuild
some software, like qemu and others, are simply not compatible with gcc 4.x and they will not become compatible due to severe conceptional issues. then they stay broken ... add a warning to the ebuild if `gcc-major-version` is 4 (see toolchain-funcs.eclass) Hmm, but ... there is the possibility to have multiple gcc versions installed. So why not set CC and/or CXX variables inside the ebuild, and then compile the app with the right gcc-version? At this point, it just bugs me, that gentoo is staying below its potential. Well, hmmm, you might want to say, that there will be trouble because of applications/libraries linked to different libstdc++ versions - or something else. I'm always willing to learn, but this really bugs me, because gentoo really has potential for what's needed in this situation. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: confusing ppp/rp-pppoe setup
/etc/ppp/plugins/rp-pppoe.so - /usr/lib/pppd/2.4.2/rp-pppoe.so Is this symlink needed? And why is it installed by rp-pppoe? (And is the /etc/ppp/plugins dir needed at all? What do plugins do in /etc/ppp/plugins? Don't they belong to /usr/lib/pppd/2.4.2/ ?) That is the place where pppoe-server search for the plugin. *grmpf* silly pppoe-server :-( Btw, the PPPoE server is the only useful part of net-dialup/rp-pppoe from Gentoo pov, the client part being surclassed by the generic pppd.sh net module available in baselayout-1.12*. Using it right now. Works very nice! rp-pppoe plugin had been within ppp tarball for quite some time (see for how long from upstream cvsweb at http://cvs.samba.org/cgi-bin/cvsweb/ppp/pppd/plugins/rp-pppoe/). It has been contributed by RoaringPenguin but from that day on, it has been maintained by Paul MacKerras (the ppp upstream). Maybe is just me, but I consider ppp to be the upstream when it comes to rp-pppoe pppd's plugin. OK, so i'm a little bit scared, that it's maintained by two parties now. The plugin.c from rp-pppoe 3.8 differs slightly from the plugins.c included in ppp 2.4.2. Didn't check the plugin.c of ppp 2.4.3 yet. So as long as i don't experience any bugs, it will stick with the one included in ppp 2.4.2 signature.asc Description: OpenPGP digital signature
[gentoo-dev] confusing ppp/rp-pppoe setup
Hi, at the moment, /usr/lib/pppd/2.4.2/rp-pppoe.so is installed by net-dialup/ppp - nothing special - well, it's not a very recent version. In the syslog it says: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2 On the other hand, i've got net-dialup/rp-pppoe-3.8 installed and it installs a symlink: /etc/ppp/plugins/rp-pppoe.so - /usr/lib/pppd/2.4.2/rp-pppoe.so Is this symlink needed? And why is it installed by rp-pppoe? (And is the /etc/ppp/plugins dir needed at all? What do plugins do in /etc/ppp/plugins? Don't they belong to /usr/lib/pppd/2.4.2/ ?) Well, yet another question: ppp-2.4.2 now includes the rp-pppoe.so plugins from rp-pppoe - do the ppp-people maintain that module by themselfs now? Or do they just download the plugin from the rp-pppoe-people and include it in their sources? I can imagine a ppp-ebuild that downloads a more recent version of rp-pppoe and builds the rp-pppoe.so-plugins directly from the rp-pppoe sources instead of using the ppp-sources. So what's going on there? I'd be happy about some comment from the maintainers. Greetings Sven -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Modular X: VIDEO_CARDS=ati moved to mach64, r128, radeon
Hi, The obvious symptom when you don't have any valid VIDEO_CARDS set will be that the xorg-x11 ebuild tries to pull in everything. Warnings or die()'s about this change are useless, they will be too late because all the drivers will have already been built at that point. but doesn't portage provide two kinds of dependencies: One, where the dependencies are installed prior to the package, and one, where the dependencies are (or at least can be) install after the package itself? Would it harm anything, if the drivers become a dependency of the second kind? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Metabuild dependency types
Would it harm anything, if the drivers become a dependency of the second kind? It would mean that you could have the xorg-x11 metabuild installed and yet still not have a complete installation, if the emerge failed after it was installed. Yes, you're right. I missed that point. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: who renamed adsl-start to pppoe-start and why
May I suggest reading the fine handbook? http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4chap=3#doc_chap4 Yes, it's beautiful, but it doesn't tell you in which file to enter the lines : config_eth0=( adsl ) adsl_user_eth0=username Where do you put them ? And yes, I have had a look in /etc/ppp all I can see is pppoe.conf , which doesn't look like that. Well, that's obvious, at least to me: /etc/conf.d/net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
I also noticed the --oneshot fix. i noted this already elsewhere in the thread dont you read all of the e-mails !? ??? I just wanted to say Thank you for both fixes. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
I have no clue, what bootstrap.sh is for anymore. For me, Installing gentoo was always like this: Ok, let me remind all. Stage 1 is a minimal system that is mainly built statically with the sole purpose of being suitable to build a working system from. It contains a cripled compiler as one of the first things it does is make a proper one. After that the original compiler should be gone. While some recompiling is needed because of circular dependencies between libc and gcc, this should be no issue. After the bootstrap has been run, one should have a proper minimal building environment that should be able to build all packages (except for some assumptions on available tools). This minimal environment is called stage 2. Stage 2 should not contain any trace of the bootstrap compiler. If the bootstrap compiler was a 3.3.x version and the final one a 3.4.x version, there should be no 3.3.x version remaining. Be aware though that if the profile does not offer a 3.4 compiler the final will be a 3.3 compiler. If desired the profile should be changed before running bootstrap.sh I think that i clearly explained several times, that bootstrap.sh installs gcc 3.4 _without_ removing the crippled gcc 3.3 that came with stage1. Mike Frysinger is talking about choice and ignores me if i tell him, that the emerge -e system uses the crippled gcc 3.3 for the first 10 packages until emerge -e system finally rebuilds gcc 3.3 (only due to some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc 3.3). Mike is telling me, that the 2006.0 tarballs will contain gcc-3.4. Then he's telling me, that the problem, that Im trying to point out, is going to vanish with the release of the 2006.0 tarballs. Well, yes, until the next gcc-slot becomes stable. So the problem is not fixed, just moved to the future again. If a stage1 install does not remove a 3.3.x bootstrap compiler when a 3.4 is used as the main, that is a bug in the bootstrap script. As such it should be fixed. So i see that you seem to agree with me! The crippled gcc contained in the stage1 has to be removed by bootstrap.sh - and this is not done automatically by the steps that bootstrap.sh performs. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
Mike Frysinger is talking about choice and ignores me if i tell him, that the emerge -e system uses the crippled gcc 3.3 for the first 10 packages until emerge -e system finally rebuilds gcc 3.3 (only due to some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc 3.3). i didnt ignore you, i told you that's the intended behavior neither you nor portage changed the compile thus it remained at 3.3 So let me summarize that again: You say, that it's the intended behaviour, that bootstrap.sh keeps the crippled gcc 3.3 intact and as the default compiler. signature.asc Description: OpenPGP digital signature
[gentoo-dev] bootstrapping since gcc 3.4 is stable
Hi,
bootstrap.sh installs gcc 3.4! So far so good, but gcc 3.3 is not
unmerged. The consequence is, that emerge -e system installs gcc 3.4
and then afterwards gcc 3.3 instead of libstdc++-v3.
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
so that a clean system is built with gcc 3.4 only!
Greetings
Sven
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] bootstrapping since gcc 3.4 is stable
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
that's a bad idea imo
let the user decide which gcc they wish to have
But doesn't bootstrap.sh rebuild gcc? I have to take a look again, but i
think bootstrap.sh rebuilt gcc 3.4 only - not 3.3.
gcc 3.3 was only rebuilt during emerge -e system.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] bootstrapping since gcc 3.4 is stable
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
that's a bad idea imo
let the user decide which gcc they wish to have
So i understand what you're trying to tell me, but bootstrap.sh makes
the choice already:
bootstrap.sh only rebuilds gcc 3.4
(i looked that up in my emerge.log)
gcc 3.3 is only rebuild (and thereby updated) by emerge -e system.
so that a clean system is built with gcc 3.4 only!
it wouldnt anyways as the version of gcc isnt changed unless the user does so
so unless you ran `gcc-config 3.4.4`, your gcc version would still be 3.3.x
Right, and it will be the gcc 3.3 included in the stage1 tarball - even
if a new gcc 3.3 version is available. So if the user wants to use gcc
3.3, he has to manually update gcc (for example to have features not
included in the gcc from the stage1 tarball).
For example my stage1 inclueded gcc 3.3.5* - but 3.3.6 is already stable.
So no matter if the user wants gcc 3.3 or gcc 3.4, the user has to do
something manually to get a proper gentoo.
If i may suggest something, then i would recomm that the user is abled
to specify the gcc installed by bootstrap.sh like this:
bootstrap.sh --gccspec =sys-devel/gcc-3.3*
The default should be the newest gcc.
In the above example, bootstrap.sh installs GCCV=sys-devel/gcc-3.3.6
After that, bootstrap.sh could unmerge the gcc included in the stage1 by
emerge -C $GCCV $GCCV
Greetings
Sven
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
so that a clean system is built with gcc 3.4 only!
Nope. We don't want to remove that choice from the user. We are
working now towards the 2006.0 release, which means GCC 3.3 will not be
present in the stage1 tarball. Basically, wait for 2006.0, or follow
the standard steps to switch compilers yourself. It's not like we're
forcing you to keep both compilers. ;]
As i wrote in my other post:
there is no choice! boostrap.sh does what it does:
- installs gcc 3.4
- leaves the gcc 3.3 from the stage1 tarball unchanged
So actually the first packages compiled by emerge -e system are
compiled with the gcc 3.3 which came with the stage1 tarball.
And that emerge -e system updates gcc 3.3 - well, that is only a
side-effect of other things!
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
that sounds rather unlikely, if gcc-3.4 was installed `emerge -e system` would have rebuilt it, not the 3.3 version (unless there is a dep on 3.4 in system). Does this have something to do with it? gcc-3.4.4-r1.ebuild: PDEPEND=|| ( app-admin/eselect-compiler sys-devel/gcc-config ) x86? ( !nocxx? ( !elibc_uclibc? ( !build? ( || ( sys-libs/libstdc++-v3 =sys-devel/gcc-3.3* ) ) ) ) ) I think so. Because gcc 3.3 is installed, portage chooses gcc 3.3 instead of libstdc++-v3. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
at any rate, this will all fix itself when 2006.0 is released OK, i give up. IMHO, i would expect that /usr/portage/scripts/bootstrap.sh; emerge -e system results in a system, that has a certain integrity with a minimum of manual steps. (gentoo install being as easy as possible) At the moment, /usr/portage/scripts/bootstrap.sh; emerge -e system produces a system, that is IMHO unexpected for most users. That's not a problem for me. So excuse me that i wanted gentoo-installation to be more simple. Greetings Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
Seems like a bit ranting to me. Why do you use unsupported installation method if you want it simple? I don't know about Sven, but the reasons I prefer the unsupported installation method is all outlined here: I have no clue, what bootstrap.sh is for anymore. For me, Installing gentoo was always like this: - you get a minimal system in form of a stage1 tarball - you then extend that system with bootstrap.sh to a system ready for further emerging - then you do emerge -e system to get a basic gentoo system I expected the result of these steps to be a clean system. What do i mean with a clean system? Actually i thought, that i mean the result of a emerge -e system - but i know now, that this is not what i mean. For example emerge -e system sometimes choses to install gcc-3.3 instead of the default libstdc++-v3. So what i mean with a clean system is a system produced by emerge -e system which acts, as if nothing would have been installed yet. Mike is telling me, that the 2006.0 tarballs will contain gcc-3.4. Then he's telling me, that the problem, that Im trying to point out, is going to vanish with the release of the 2006.0 tarballs. Well, yes, until the next gcc-slot becomes stable. So the problem is not fixed, just moved to the future again. Actually I'm told, that there's no automatic mechanism to get a clean gentoo system. So i'm told, that i have to take a stage3 tarball, and upgrade it to a clean system. If i follow that advice, i have to upgrade glibc, gcc, python and perhaps many more, clean the system from packages in old slots, and then run an emerge -e world (which compiles glibc, gcc, python again). Pretty much work for a beginnner! And there's pretty much of experience needed. Actually, the moment when there's an upgrade to glibc and gcc, than there's no advantage in taking a stage3 - the whole upgrading the stage3-thing will take as long as using a stage1. Why? because i have to upgrade glibc and gcc - and that is basically what bootstrap.sh does too. Greetings Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] emerge --update has problem with slotted packages?
Hi, so look at this: # equery l |grep sun-jdk dev-java/sun-jdk-1.4.2.10 dev-java/sun-jdk-1.5.0.06-r2 # emerge -up sun-jdk These are the packages that I would merge, in order: Calculating dependencies ...done! # emerge --oneshot =dev-java/sun-jdk-1.4* -p These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuildfU ] dev-java/sun-jdk-1.4.2.10-r2 [1.4.2.10] So portage does not list sun-jdk-1.4.2.10-r2 as an update - only if i specify it manually. That is - well - suboptimal. I'd like to know about any update within the same SLOT(s) as the installed package(s). Is this a known problem? Thanks Sven -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env
init.d scripts should have a pure env given to them ... which means, they should be run with `env -i` and have only whitelisted variables given to them (and everything that appears in /etc/conf.d/$service /etc/conf.d/rc and /etc/rc.conf) ... Now that may be too few variables. At least the variable LANG (or whatever the system-admin may chose to set) could be seen as a system-wide language-setting. It could be intentional, that at least some variables are available to the started server-processes. Especially a system-wide language-setting would be a good idea. After all, there's one point: The 2 possible situations (init-script started by root-shell, init-script started at by init-process) because of at least 2 reasons: - less side-effects - and of course the reason vapier mentiones: after all, you wouldnt want something like apache having all those vars in its env because they'd show up in php script env which means available to the public signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: why does gcc-3.4.x depend on gcc-3.3.x / libstdc++?
I must say I have been wondering about this for a while too. A solution might be add some sort of flag to packages that are binary, and then let portage install libstdc++ the first time you install this kind of package. You mean, like have binary packages depend on virtual/libstdc++-SOMEVERSION and have virtual/libstdc++ provided by gcc or the split-out libstdc++ ebuild? Some packages event depend on libstdc++-v3 even if gcc-3.3 is installed. I suggested virtuals for each libstdc++-version a long time ago since they are provided by either gcc or seperate libstdc++ ebuilds. It was rejected by i think vapier or azarah. Furthermore, i suggested that portage may analyse installed binaries for dependency on a specific libstc++ version and it may record an additional depency for such packages. This would solve the emerge depclean uninstalls in-use libstdc++ library easily. Of course, this might need heavy changes to portage. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env
Perhaps the init script loader should be changed such that the environment variables from the shell calling the script are ignored, and an environment equal to that when being called by init is used. Definitely. There shouldn't be two different environments depending on whether a init-script is run from the command-line or by the init-process. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env
The init script will not see those variables when it is run by /sbin/rc which is in turn run by init which is what happens on boot. The environment is empty then, and if you want to reproduce it accurately for your tests, you should do: env -i /etc/init.d/test restart It does see variables in /etc/rc.conf though: lion ~ # echo LANGTEST=testme /etc/rc.conf lion ~ # env -i /etc/init.d/test restart * Caching service dependencies ... [ ok ] LANGTEST=testme set | grep LANG And the init-script will also see the variables from /etc/conf.d/test But i cannot says, that i like the design. Should init.d-scripts see the env-variables from the current environment? I don't think so - even if it's usually root's environment. /sbin/rc could clear the environment and source /etc/profile.env instead. That would be pretty clever i think. An init-script would always run within the same environment no matter whether it's run by init or root's shell. How about that? signature.asc Description: OpenPGP digital signature
[gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env
Hi, i just wrote an init.d-script and i thought that the LANG variable was inherited since it set system-wide in /etc/env.d/02locale and therefor is also found in /etc/profile.env Now i noticed, that LANG isn't set for the process started by my init.d-script. So what's the intension to ignore /etc/profile.env for init.d-script and what's the gentoo-way of loading the all or specific variabled from /etc/profile.env? Thx Sven signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Fixing the TERM mess
The termcap method is provided by libtermcap-compat. Most applications which use this method only do so as an option for systems where terminfo is not available -- for example, for Vim, terminfo vs termcap is a compile-time option. The termcap database is limited, generally out of date and mostly unmaintained. It will likely not remain in the tree for much longer (bug #103105). Take a look at ncurses. ncurses even comes with a termcap.h in /usr/include. I think ncurses is source-compatible with termcap and offers the features needed to acces different terminal types. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Fixing the TERM mess
See, certain terminal emulators lie about their TERM setting. Usually it's things that aren't xterm pretending to be an xterm, although rxvt sometimes crops up too. Examples of things pretending to be xterm include Konsole, Gnome Terminal. The logic behind it goes like this: * We don't understand this 'terminfo' thing, but we want our terminal to work with programs which use ncurses. * We've implemented xterm-style colour sequences and some basic cursor movement. * Therefore, we shall set TERM=xterm. This is not a good idea. See, real xterm supports a hell of a lot of fancy voodoo. It and rxvt-unicode are two of the most fully featured terminal emulators (from a terminal capability point of view) out there. None of these cheap knockoffs that claim to be xterm come anywhere near close to supporting full xterm capabilities. I fully agree with you, but ... did xterm support the full feature-set right from the start? So what happens if i've got a box running an old xterm and then do an ssh-session to a newer box where the application thinks that xterm support some fency new feature? After the all, the whole mess can IMHO only be cleared up, if there's something like a universal terminal-type, and the application could ask the terminal for it's feature-set. So i'm not aware if this is possible, but this seems to be the only _really_ reliable extensible way to do this. I don't see the point in define lots of all new terminal-types. Of course this isn't and a short-term sollution and would have to be implemented by all the terminal-emulators that lie about their terminal-type. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: where goes Gentoo?
In my humble opinion, Gentoo is missing too many points to be an enterprise Linux. We commit to a live tree. We don't have true QA, testing or tinderbox. We don't have paid staff, alpha/beta/rc cycles. We don't really have product lifecycles, since we don't generally backport fixes to older versions, requiring instead for people to update to a more recent release. We don't have, and probably will never be able to offer, support contracts. We support as wide a range of hardware as the upstream kernel, plus hardware that requires external drivers; we don't have access to a great deal of the hardware for which we provide drivers. We understand when real life gets in the way of bug-fixing, because all our developers are volunteers. QA is a problem. Bugs get fixed, but often they are only fixed in ~x86 versions, not in the stable x86 series. For example baselayout: there are lot of ~x86 - miles ahead of that is marked x86. Maintainers think, it's sufficient to only fix the most recent version. How do they legitimate that? This one is easy. A stable package's ebuild should not change. Period. I agree with you there - though sometimes, stable ebuilds are changed - even without changing the version-number. To fix the stable version, means that a new revision of the latest stable version would need to be made, and that revision would need to be tested, before it would go to stable. The only real exception to this is security bugs. Also, in many cases, the bug in question requires changes that are simply not feasible easily in the current stable version, but quite easy in the latest version. It really boils down to this: If you're having an issue with a package in Gentoo and it is fixed in the latest ~arch version, then you should *use* the ~arch version (remember, it doesn't mean unstable it means testing) and you should report back to the maintainers that this is working for you so that they can get it moved into stable quicker. We don't have the staff or the time to backport every fix to every stable version. Remember that in many cases the latest stable version varies between architectures. I chose baselayout for a particular reason. There is baselayout 1.9, 1.11 and 1.12. (i think there was 1.10 too - some time ago - perhaps) I i reported bugs - as usual - but the bug was fixed for 1.11 or 1.12 (i can't remeber, it was about a year ago). The problem: the fix was not backported to 1.9 (which was stable at that time). Since baselayout is a very important part of Gentoo, i didn't think that it would be a good idea, to upgrade my x86-version 1.9 to a ~x86-version 1.11. So i would have expected that such changes would go into a new 1.9-version which could have become stable after some testing - but they didn't. So patches the scripts manually - well, and easy task, although i had to pay attention so they my changes weren't overwritten. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: upgrade's and rc-scripts
Out of curiousity, has any put any thought into some automated method or hook for allowing restarting of rc-scripts on upgrade/re-emerge of a package? Other question is if any such hook is even needed. So... thoughts? I don't really have any input on it, aside from I'd like to gather what people want/think would be useful. Another good idea, would be pending jobs list. Many ebuilds provide imports instructions like you can now delete this or that config-file or like you must immediatly run this or that. These usually scroll by while there're nobody watching the screen and/or they cannot be read completely, since they scroll away too fast. Apropos config-files: what about config-files that are provided by the old-version of an ebuild but have been moved or removed by the new version? etc-update doesn't know about them. So /etc/ will be full of useless config-files after some time. I'd consider automatic restarting a less important problem. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Unmasking of gentoolkit-0.2.1_pre3
Unless there are objections, I am planning on unmasking gentoolkit-0.2.1_pre3 this weekend. This build of gentoolkit contains the new version of revdep-rebuild. This version has been in the tree and package masked since 12 June. During that time, I have not received any bug reports and the feedback that I have seen from the gentoo-user mailing list has been positive. Last time i used revdep-rebuild, i saw that revdep-rebuild does check things twice, since therere symlinks like /usr/X11R6/lib to /usr/lib. It this fixed in the new version? Thx Sven signature.asc Description: OpenPGP digital signature
