Static linking: pkgconfig vs libtool
Dear Debian Developers! In the application I am taking part in, I am trying to create a configuration script to be able to provide two deliverables: dynamically-linked executable and statically-linked. The first problem I faced is that it is difficult to explore what should be the list of libraries for static linking (as I have to provide the list of libraries which are direct dependencies as well as indirect). I know this problem is solved with libtool (which consumes the information from *.la) and with pkg-config (which consumes the information from *.pc). The problems I faced: * General question. What is the current trend: to use libtool or pkg-config? For me it is easier to use pkg-config CLI, rather then re-write autoconf scripts to fit libtool ideology (maybe I don't need to, fixme). * Some libraries (e.g. GraphicsMagick) does not provide the list of libraries for statis linking via .pc (compare 'pkg-config --static --libs GraphicsMagick++' and 'GraphicsMagick++-config --libs'). Should it be fired as a bug for GraphicsMagick package? * Some libraries (e.g.) do not follow the agreement for .NET/CLI (http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-pkg-config-file) which I think is also good to follow for common libraries: - xfprint4-4.6.1 package contains xfprint-1.0.pc (expected: xfprint4.pc or xfprint4.pc -symlink-> xfprint4-4.6.1.pc) - libxml2-dev package contains libxml-2.0.pc (expected: libxml2.pc or libxml2.pc -symlink-> libxml2-2.7.7.pc) I have posted this question also to stackoverflow (http://stackoverflow.com/questions/3932742/static-library-auto-discovery-and-linking) but I haven't got a complete answer, so I kindly ask the Debian community to help me. Thank you in advance! -- With best regards, Dmitry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce6ec61.7030...@mail.ru
Re: Static linking: pkgconfig vs libtool
On 19.11.2010 22:51, Russ Allbery wrote: > Dmitry Katsubo writes: > >> The first problem I faced is that it is difficult to explore what should >> be the list of libraries for static linking (as I have to provide the >> list of libraries which are direct dependencies as well as indirect). I >> know this problem is solved with libtool (which consumes the information >> from *.la) and with pkg-config (which consumes the information from >> *.pc). The problems I faced: > >> * General question. What is the current trend: to use libtool or >> pkg-config? For me it is easier to use pkg-config CLI, rather then >> re-write autoconf scripts to fit libtool ideology (maybe I don't need >> to, fixme). > > pkg-config is much superior to libtool, since libtool includes all the > libraries on dynamic links as well, which creates unwanted shared library > dependencies and causes other problems. Because of that, the trend in > Debian is to empty that information from libtool *.la files or not ship > them at all, making them useless for static linking information. > >> * Some libraries (e.g. GraphicsMagick) does not provide the list of >> libraries for statis linking via .pc (compare 'pkg-config --static >> --libs GraphicsMagick++' and 'GraphicsMagick++-config --libs'). Should >> it be fired as a bug for GraphicsMagick package? > > I think it's reasonable to consider that a bug, although it's probably a > minor one and it may be closed wontfix if the GraphicsMagick maintainers > aren't interested in supporting static linking. (A lot of upstreams just > don't care about static linking and aren't willing to support it.) > >> * Some libraries (e.g.) do not follow the agreement for .NET/CLI >> (http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-pkg-config-file) >> which I think is also good to follow for common libraries: >> - xfprint4-4.6.1 package contains xfprint-1.0.pc (expected: xfprint4.pc >> or xfprint4.pc -symlink-> xfprint4-4.6.1.pc) >> - libxml2-dev package contains libxml-2.0.pc (expected: libxml2.pc or >> libxml2.pc -symlink-> libxml2-2.7.7.pc) > > Er, what does an agreement for .NET/CLI have to do with pkg-config files > for libraries written in C? I don't see any relevance of that packaging > documentation to the libraries you list. > > The pkg-config configuration file name is not, in general, going to be > determinable from the Debian package name. Russ, thank you for comments. To answer your question I quote only one important section from the document I've referred: === quote === 3.2.4 pkg-config File Many libraries deliver a .pc file for use by the pkg-config helper utility, which aids other libraries and applications to link against libraries. All GAC library packages should have a pkg-config .pc file located in /usr/lib/pkgconfig. The filename must be named: package-X.Y.pc including the versioning. The version must reflect the same X.Y version as the package name. There must also be a symlink without the version to the latest version, as follows: from package.pc to package-X.Y.pc === end of quote === What I think is important, that X.Y somehow correlates with package version. OK, it could be "API version", but API might not change, while some important information changes (e.g. the list of static libraries). For example, a) libtiff-1.0 is linked against libjpeg-1.0 b) libtiff-1.1 is linked against libjpeg-1.1 and also libm. Obviously, libtiff-1.0 and libtiff-1.1 should provide libtiff-1.0.pc and libtiff-1.1.pc correspondingly, even if libtiff's public API has not changed. If *.pc files are not following the version of the package, I wonder how versions should be assigned and incremented, and what are the criteria for that. What is also important, that there is a symlink without the version, e.g. libtiff.pc --> libtiff-1.1.pc (points to the latest installed version). It helps to use the "latest available" information, without a need to discover actual version. So I wonder, if there are any polices, that regulate above mentioned, similar to .NET/CLI policies I've quoted. Thank you in advance! -- With best regards, Dmitry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cea89dc.3030...@mail.ru
dh_shlibdeps warnings concerning undefined OpenMP symbols
Dear developers, I have the question concerning the following dh_shlibdeps warning, which is triggered for library that is compiled witn OpenMP support: >dh_shlibdeps > dpkg-shlibdeps: warning: symbol GOMP_critical_start used by > debian/libosra0/usr/lib/libosra.so.0.0.10308 found in none of the libraries. > dpkg-shlibdeps: warning: symbol GOMP_parallel_start used by > debian/libosra0/usr/lib/libosra.so.0.0.10308 found in none of the libraries. > dpkg-shlibdeps: warning: symbol omp_get_num_threads used by > debian/libosra0/usr/lib/libosra.so.0.0.10308 found in none of the libraries. > dpkg-shlibdeps: warning: symbol GOMP_critical_end used by > debian/libosra0/usr/lib/libosra.so.0.0.10308 found in none of the libraries. > dpkg-shlibdeps: warning: symbol omp_get_thread_num used by > debian/libosra0/usr/lib/libosra.so.0.0.10308 found in none of the libraries. The mentioned symbols are exported from libgomp (a part of gcc-4.4 package), which is correctly linked to the SO: # ldd ./src/libosra_java.so | grep gomp libgomp.so.1 => /usr/lib/libgomp.so.1 (0xb68df000) What should I do to suppress this warning? Or should it be silently ignored? Thanks in advance. -- With best regards, Dmitry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d94a68e.7060...@mail.ru
Re: dh_shlibdeps warnings concerning undefined OpenMP symbols
On 31.03.2011 18:20, Cyril Brulebois wrote: > you may want to check through objdump -x $foo.so|grep NEEDED; ldd > shows recursive dependencies. > > KiBi. KiBi, thanks for the hint. It turned out that libgomp is not listed as direct dependency of my library. Does it mean I have to put "gcc-4.4" into debian/control -> Depends and add "-lgomp" to LIBS explicitly during the linking stage? Another problem that arises here: I autodetect OpenMP support using AC_OPENMP() autoconf macro. So if OpenMP is detected, then it is used, otherwise - not (optional enabled by default dependency). How to play correctly in this situation? libgraphicsmagick3 is also compiled with OpenMP support (/usr/lib/libGraphicsMagick.a has omp_get_* and GOMP_* symbols undefined), however it does not depend on "gcc-4.4". -- With best regards, Dmitry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d94d795.4000...@mail.ru
Re: dh_shlibdeps warnings concerning undefined OpenMP symbols
On 31.03.2011 22:16, Jakub Wilk wrote:
>> You do need -lgomp.
>
> You normally don't (need to) link to gomp explicitly. My wild guess is:
> Dmitry used -fopenmp while compiling *.o, but not when linking the
> shared library.
Exactly! Thank you, Jakub, for nice guess.
AC_OPENMP() macro documentation looks to be a bit incomplete (e.g. if it
provides $OPENMP_LDFLAGS I wouldn't mess things), so I believe the
correct sequence looks like this:
AC_OPENMP()
CPPFLAGS="${OPENMP_CFLAGS} ${CPPFLAGS}"
CXXFLAGS="${OPENMP_CXXFLAGS} ${CXXFLAGS}"
LDFLAGS="${OPENMP_CXXFLAGS} ${LDFLAGS}"
I also was suggested this resource:
> http://wiki.debian.org/ToolChain/DSOLinking#Unresolved_symbols_in_shared_libraries
which explains that this warning is raised, when the dependency chain is
like "A -> B -> C", and A needs symbols from C, but has no direct
dependency "A -> C" (which should be introduced as Brian also mentioned).
Thanks a lot for help.
--
With best regards,
Dmitry
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d958b0b.1010...@mail.ru
Re: dh_shlibdeps warnings concerning undefined OpenMP symbols
On 31.03.2011 22:16, Jakub Wilk wrote:
>> You do need -lgomp.
>
> You normally don't (need to) link to gomp explicitly. My wild guess is:
> Dmitry used -fopenmp while compiling *.o, but not when linking the
> shared library.
Exactly! Thank you, Jakub, for nice guess.
AC_OPENMP() macro documentation looks to be a bit incomplete (e.g. if it
provides $OPENMP_LDFLAGS I wouldn't mess things), so I believe the
correct sequence looks like this:
AC_OPENMP()
CPPFLAGS="${OPENMP_CFLAGS} ${CPPFLAGS}"
CXXFLAGS="${OPENMP_CXXFLAGS} ${CXXFLAGS}"
LDFLAGS="${OPENMP_CXXFLAGS} ${LDFLAGS}"
On 01.04.2011 14:47, Jakub Wilk wrote:
> I don't think there's anything wrong with this macro. CXXFLAGS should be
> used both for compiling and linking. At least this is what GNU make do
> by default:
>
> $ make -p 2>/dev/null | grep 'LINK.cc = '
> LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
Thank you! It looks like I need to use $(LINK.cc) to link the .so library.
I also was suggested this resource:
> http://wiki.debian.org/ToolChain/DSOLinking#Unresolved_symbols_in_shared_libraries
which explains that this warning is raised, when the dependency chain is
like "A -> B -> C", and A needs symbols from C, but has no direct
dependency "A -> C" (which should be introduced as Brian also mentioned).
Thanks a lot for help to everyone!
--
With best regards,
Dmitry
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d9acf08.4010...@mail.ru
Find out what symbols in dynamic library have not been compiled with -fPIC
Dear Debian developers, When trying to create a package that includes the library, I am reported the following error by lintian: E: libosra1: shlib-with-non-pic-code usr/lib/libosra.so I understand what the problem is about, but I would like to know which *functions* in resulting .so are not compiled without -fPIC. src$ readelf -d libosra.so | grep TEXTREL 0x0016 (TEXTREL)0x0 What next? I need to see violating symbols e.g. 00153e5d23 OBJECT WEAK DEFAULT 13 _ZTSN9OpenBabel9AliasData 00120dc0 295 FUNCGLOBAL DEFAULT 11 _ZN3UCS16to_nearest_digit 0011f260 277 FUNCGLOBAL DEFAULT 11 OCRAD_close Thanks for any help. -- With best regards, Dmitry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/549b384c.6010...@mail.ru
Re: Find out what symbols in dynamic library have not been compiled with -fPIC
On 24/12/2014 23:25, Mike Hommey wrote:
> Install the elfutils package and use eu-findtextrel, it's sometimes
> wrong, but it should get you started. The manual way to do this is to
> crossreference the output of readelf -r with the symbol table and
> readelf -l.
Thanks, Mike, that helped a lot.
P.S. For someone looking for complete solution to locate violating
symbols and search for static libraries they came from:
> eu-findtextrel libtest.so | sort -u | perl -ne 'while (<>) { while (/the
> function \x27(\w+)\x27/g) { print "$1\n"} }' | while read i; do scanelf -l -A
> -s $i | grep $i; done
--
With best regards,
Dmitry
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/549f5b03.60...@mail.ru
Should .a library contains non-reallocatable code?
Dear Debian Developers, I wonder what is the current state-of-art concerning the code in .a library (archive for static linking). Should it contain PIC code? Situation: Dynamic (.so) library needs to be linked against such (.a) library. Thank you for any advises and your opinion in advance. On 23/01/2015 17:44, Antonio Diaz Diaz wrote: > Hello Alexander and Dmitry, > > Alexander Alemayhu wrote: >> forwarding a thread I had with Dmitry regarding [#]774164. >> What do you think? > > Libocrad is available only in static form because it is just a very > immature hack. Basically I add functions as users ask for them. It meets > about all the requirements in section 8.3 "Static libraries" of > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > > Ocrad itself is very immature. I can't guarantee any stability. > > Moreover, AFAIK, compiling the sources twice (once without PIC for > CLI and another time with PIC for .a) is not trivial. Different names > are needed for the two versions of the object files. > > BTW, libocrad.a is *not* used to create ocrad CLI. libocrad.a is just > ocrad with an incomplete programming interface instead of a CLI. > > > Best regards, > Antonio. > > -- Forwarded message -- > From: Dmitry Katsubo > Date: 2015-01-10 15:39 GMT+01:00 > Subject: Re: Bug#774164: libocrad-dev: libocrad.a contains non-reallocatable > code > To: Alexander Alemayhu > > On 06/01/2015 22:54, Alexander Alemayhu wrote: >> It might take me some time to make a change, because of work. >> Please also note I have not made Debian libraries before, so it >> might take me some time to do it properly. If you can't wait and >> would like to be the change, please send a patch or pull request >> :) >> >> I had a little chat with my neighbour and he had some useful links >> to share which should give more information on Debian best >> practices. >> >> Thanks. >> >> See below: >> >> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html >> https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-libraries > > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html > > Thanks for the links! > > In particular this one: > > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#staticonlylibs > > says > > "providing -fPIC versions of static libraries for linking with > shared libraries is a bad sign, because the "unstable interface" is > now exported through another library's stable library interface", > which is true, but without -fPIC the resulting shared library is unusable. > > Ideally of course would be that OCRAD is split into light-weight > command-line and dynamic library library, but I am sure that adds more > organizational work -- would it be worth? Try to ask the OCRAD > community if they would be happy to have OCRAD also as dynamic library > (which can also be wrapped into Perl/Java/etc bridges). > > -- > With best regards, > Dmitry -- With best regards, Dmitry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54df4008.20...@mail.ru
Core dumps are instantly removed
Dear Debian developers, Hopefully you can easily help me with my confusion. I would like to collect / keep core dumps in the system. For that I use systemd-coredump package which is configured as following: === cut /etc/systemd/coredump.conf === [Coredump] Storage=external MaxUse=5G === cut === Then I have created a script to send core dump report daily to root: === cut /etc/cron.daily/coredump === YESTERDAY=`date --date="1 day ago" +%Y-%m-%d` MESSAGE=`coredumpctl list --no-pager -r -S $YESTERDAY -U $(date +%Y-%m-%d) 2> /dev/null` && (echo "$MESSAGE"; echo -e "\nLast core dump info:\n"; coredumpctl info --no-pager; echo -e "\nCore dumps:\n"; ls -l /var/lib/systemd/coredump; ) | mail -s "Core dumps created yesterday $YESTERDAY" root === cut === What I get is: === cut === TIMEPID UID GID SIG COREFILE EXE Tue 2019-12-10 11:27:26 CET2537 1003 100 5 missing /usr/bin/light-locker Last core dump info: PID: 2537 (light-locker) ... Signal: 5 (TRAP) Timestamp: Tue 2019-12-10 11:27:25 CET (20h ago) Command Line: light-locker Executable: /usr/bin/light-locker ... Storage: /var/lib/systemd/coredump/core.light-locker.1003.810304...157597364500.lz4 (inaccessible) Message: Process 2537 (light-locker) of user 1003 dumped core. Stack trace of thread 2537: #0 0x7fde22515c75 n/a (libglib-2.0.so.0) #1 0x7fde22516d0d g_log_default_handler (libglib-2.0.so.0) #2 0x7fde22516f5f g_logv (libglib-2.0.so.0) #3 0x7fde2251714f g_log (libglib-2.0.so.0) #4 0x563b0e2f30a3 n/a (light-locker) #5 0x7fde22615107 g_type_create_instance (libgobject-2.0.so.0) ... Core dumps: total 0 === cut === As one can see, stack trace is somehow captured by coredumpctl (where it gets it from?) but core file is not there. I would like core dump files to be preserved for (say) 10 days. light-locker generates really tiny core dump when I start it from console: === cut === $ /usr/bin/light-locker Trace/breakpoint trap (core dumped) # ls -l /var/lib/systemd/coredump/ -rw-r-+ 1 root root 884992 Dec 13 14:16 core.light-locker.1003.8103...157624301300.lz4 === cut === Also I am aware about this setting: === cut /usr/lib/tmpfiles.d/systemd.conf === d /var/lib/systemd/coredump 0755 root root 3d === cut === but it configures the directory to be cleaned in three days while they are removed sooner. Any ideas? Thanks in advance! P.S. I have read: https://wiki.debian.org/HowToGetABacktrace#Core_dump https://wiki.archlinux.org/index.php/Core_dump but didn't find the answer. -- With best regards, Dmitry
Linux kernels v3.18.x and v4.2.x in sid
Dear Debian developers, I wonder if somebody knows what are the plans for packaging kernels 3.18.x and 4.2.x? 3.18 was released long time ago, and I think it is mature. 4.2.x would be nice to play with. I have searched here: > https://packages.debian.org/search?suite=all&searchon=names&keywords=kernel-image but found nothing. Maybe there is some blocking issue? Anyway, even if something does not work well, would be nice to see latest kernels in e.g. sid repo. Alternatively I can try a kernel from Ubuntu: http://kernel.ubuntu.com/~kernel-ppa/mainline/ but I am not sure if that would be a right way to do. -- With best regards, Dmitry
Re: Linux kernels v3.18.x and v4.2.x in sid
On 23/10/2015 22:43, James Cowgill wrote: > Hi, > > On Wed, 2015-10-21 at 12:35 +0200, Dmitry Katsubo wrote: >> Dear Debian developers, >> >> I wonder if somebody knows what are the plans for packaging >> kernels 3.18.x and 4.2.x? 3.18 was released long time ago, and I >> think it is mature. 4.2.x would be nice to play with. I have >> searched here: >> >>> https://packages.debian.org/search?suite=all&searchon=names&keywords=kernel-image > >>> > 4.2.3 is already in unstable. Have a look at this page at the list > of package versions on the left: > https://tracker.debian.org/pkg/linux > > The kernel image packages are called "linux-image-". > The packages called "kernel-image-" are used by the > debian installer but not for full installations. > > If you specifically want 3.18, you can download it from > snapshot.debian.org. http://snapshot.debian.org/package/linux/ Thanks, James! I tried to search for "linux-image" but it finds only kernels from squeeze and wheezy repos: > https://packages.debian.org/search?suite=all&arch=any&searchon=names&keywords=linux-image Perhaps > there is some trick with that UI interface. Anyway, I read a note on http://snapshot.debian.org/ concerning how to add snapshots repository to apt-get. I have added the following to /etc/apt/sources.list: > deb http://snapshot.debian.org/archive/debian/20150208T160746Z/ sid > main deb-src > http://snapshot.debian.org/archive/debian/20150208T160746Z/ sid > main deb > http://snapshot.debian.org/archive/debian/20150208T160746Z/ jessie > main deb-src > http://snapshot.debian.org/archive/debian/20150208T160746Z/ jessie > main and run "apt-get -o Acquire::Check-Valid-Until=false update": > Get:3 http://snapshot.debian.org sid/main Translation-en [4,829 > kB] Get:4 http://snapshot.debian.org sid/main Sources [7,576 kB] > Get:5 http://snapshot.debian.org sid/main i386 Packages [7,117 kB] > Get:6 http://snapshot.debian.org jessie/main Translation-en [4,605 > kB] Get:7 http://snapshot.debian.org jessie/main Sources [7,149 > kB] Get:8 http://snapshot.debian.org jessie/main i386 Packages > [6,794 kB] Fetched 37.5 MB in 38s Reading package lists... Done Still no 3.18.6 in the output of "apt-cache search linux-image". What I did wrong? Does it matter what repo to pick up? Also from what I see, the latest 3.18 kernel in snapshot repo is 3.18.6, however kernel.org has releases up to 3.18.22. Is it because the kernel was superseded by 3.19 so there are no more builds for 3.18 branch? Will it be OK then to take 3.19.6 kernel from stability point of view? -- With best regards, Dmitry
Re: Linux kernels v3.18.x and v4.2.x in sid
On 24/10/2015 14:56, James Cowgill wrote: > On Sat, 2015-10-24 at 01:02 +0200, Dmitry Katsubo wrote: >> On 23/10/2015 22:43, James Cowgill wrote: >>> If you specifically want 3.18, you can download it from >>> snapshot.debian.org. http://snapshot.debian.org/package/linux/ >> >> Thanks, James! I tried to search for "linux-image" but it finds >> only kernels from squeeze and wheezy repos: >> >>> https://packages.debian.org/search?suite=all&arch=any&searchon=names&keywords=linux-image > >>> > I think this was already mentioned, but since the search generated > too many results, only the first 100 were given. If you set the > suite to sid then you might find what you are looking for. I agree in general, but when one limits the search to say "sid", it shows no kernel for i686 (for example): > https://packages.debian.org/search?suite=sid&arch=any&searchon=names&keywords=linux-image If > one can show me the way to search via Web (by providing a link), I will appreciate. I can of course, do the same using apt-cache, but I usually start from Web and then I can see what repository to enable in sources.list - I think that way is the most handy. >> Still no 3.18.6 in the output of "apt-cache search linux-image". >> What I did wrong? Does it matter what repo to pick up? > > 3.18 was only ever in experimental, so you need to replace sid > with experimental in your sources line. Aha, thanks! That was not easy to guess. After adding experimental to sources.list > deb http://snapshot.debian.org/archive/debian/20150208T160746Z/ > experimental main I got the following: > # apt-get -o Acquire::Check-Valid-Until=false update # apt-cache > search linux-image ... linux-image-3.18.0-trunk-686-pae - Linux > 3.18 for modern PCs > > # apt-get install linux-image-3.18.0-trunk-686-pae Get:3 > http://snapshot.debian.org/archive/debian/20150208/ > experimental/main linux-image-3.18.0-trunk-686-pae i386 > 3.18.5-1~exp1 Surprise, as this page http://snapshot.debian.org/package/linux/3.18.6-1~exp1/ states that version 3.18.6-1~exp1 should be in that snapshot. Finally I have downloaded .deb and installed from local file :) >> Also from what I see, the latest 3.18 kernel in snapshot repo is >> 3.18.6, however kernel.org has releases up to 3.18.22. Is it >> because the kernel was superseded by 3.19 so there are no more >> builds for 3.18 branch? > > Yes Thanks for this information, James. >> Will it be OK then to take 3.19.6 kernel from stability point of >> view? > > If you want something which gets updated and gets bug fixes, you > shouldn't be using snapshot.d.o and instead use a kernel from the > main archive. Install "linux-image-amd64" to get the latest one > from sid. I would be happy to. However it does not allow me to use the latest kernel from 3.x branch (3.16 is now 1 year old). -- With best regards, Dmitry
Re: Linux kernels v3.18.x and v4.2.x in sid
On 2015-10-25 07:11, Adam Borowski wrote:
> On Sat, Oct 24, 2015 at 10:59:47PM +0100, Simon McVittie wrote:
>> On 24/10/15 22:17, Dmitry Katsubo wrote:
>>> I would be happy to. However it does not allow me to use the latest
>>> kernel from 3.x branch (3.16 is now 1 year old).
>>
>> All Debian stable releases are intended to be used with the latest
>> kernel from the same suite. For Debian 8 that's the 3.16.y series, which
>> has long term support from Canonical, and receives security and
>> stability bug fixes in the Debian stable and security archives.
Hm, kernel.org says that 3.18 is the long-term support kernel.
>> If you have hardware or software requirements that mean the stable
>> kernel is unsuitable for you, then the next most stable option is to use
>> the latest kernel from the corresponding backports repository. For
>> Debian 8 that's jessie-backports, which currently has Linux 4.2.y.
Thanks for the information that 4.2.x is backported. Actually what is
also important for me is the availability of btrfs-tools v4.2.x, which
is now available in sid. Perhaps there are plans to backport btrfs-tools
as well (or how does it happen with kernel-dependant utilities)?
>> Anything in snapshots.debian.org is entirely "as is"; if it has critical
>> bugs, they will never be fixed. Do not use snapshots.debian.org on
>> production systems.
>
> If you insist on using a 3.* kernel but 3.16 is too old for you, 3.18 _is_ a
> long-term support release, maintained by Sasha Levin until Jan 2017.
> You'd just need to compile it yourself. It's available from:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> branch linux-3.18.y.
>
> To do that, apt-get install kernel-package then:
> cp /boot/config-${your_old_kernel_version} .config
> make menuconfig #edit the config to your heart's content
> make-kpkg --rootcmd fakeroot --initrd -j`grep ^processor /proc/cpuinfo|wc -l`
> linux-image
> make-kpkg --rootcmd fakeroot --initrd -j`grep ^processor /proc/cpuinfo|wc -l`
> linux-headers
Compilation of the kernel is an option, but as builds are available in
snapshots, there is no strong need in that. Thanks for advise anyway. I
used to another way of compiling the kernel
$ apt-get source linux-image-3.2.0-4-686-pae; cd linux-3.2.35
$ fakeroot make -f debian/rules.gen binary-arch_i386_none_686-pae
which assures that all Debian-specific patches are applied on the top of
vanilla kernel. I am not sure if that is still preferable for latest
kernels.
--
With best regards,
Dmitry
Re: Linux kernels v3.18.x and v4.2.x in sid
On 27/10/2015 10:31, Ian Campbell wrote: >> Hm, kernel.org says that 3.18 is the long-term support kernel. > > I'm afraid that LTS from kernel.org != stable support from Debian. > > Debian typically picks a single kernel version for a stable release and > supports it for the lifetime of that release. Of course the LTS support > from kernel.org for that particular version is valuable in achieving > that. For Jessie the chosen release is 3.16 (LTS in this case is by > Canonical not kernel.org) I got it, many thanks for the information. Branch 3.18 at kernel.org has now version 3.18.22 and will keep on increasing. Does it mean that Debian team ports commits from 3.18.x to 3.16 branch to provide LTS for it? > For the testing and unstable releases the Debian kernel team typically > tracks the regular mainline kernel releases (perhaps one or two behind > depending on $factors) with a view to arriving at a suitable LTS kernel > at some appropriate point before the freeze for the next Debian > release. > > Experimental is usually tracking upstream rcs more closely. > > This is why testing+unstable currently have moved on to 4.2 and > experimental has a 4.3 rc in it and 3.18 is no longer current in any > suite. -- With best regards, Dmitry
