reprepro complains about the generated pbuilder debian.tar.gz archive md5 - md5

I have configured a private APT repository (using resources on internet like http://inodes.org/2009/09/14/building-a-private-ppa-on-ubuntu/) and I'm uploading for the first time my package containing the sources of my C++ application.
So reprepro repository is empty.
I use the following command in order to start the build:
sudo reprepro -V -b /srv/reprepro processincoming incoming
Then the build start, a lot of output is genearated and I can see that pbuilder is compiling the project source code and everything is fine. I can even find in the result/ folder debian packages etc...
But the build failed with a POST_BUILD_FAILED because it seems that pbuilder has changed the douane-testing_0.8.1-apt1.debian.tar.gz file and the md5 sum is now different as shown here:
File "pool/main/d/douane-testing/douane-testing_0.8.1-apt1.debian.tar.gz" is already registered with different checksums!
md5 expected: 97257ae2c5790b84ed7bb1b412f1d518, got: df78f88b97cadc10bc0a73bf86442838
sha1 expected: ae93c44593e821696f72bee4d91ce4b6f261e529, got: d6f910ca5707ec92cb71601a4f4c72db0e5f18d9
sha256 expected: c3fac5ed112f89a8ed8d4137b34f173990d8a4b82b6212d1e0ada1cddc869b0e, got: ebdcc9ead44ea0dd99f2dc87decffcc5e3efaee64a8f62f54aec556ac19d579c
size expected: 2334, got: 2344
There have been errors!
I don't understand why it is failing as when I compare the 2 packages (having those md5 sums) the content is strictly the same (I used a diff tool but no differences and no new or removed files).
The only thing I can see is that the archive from pbuild is bigger of 10 Bytes than the orginal one I have uploaded:
On my development machine, the file with the md5 97257ae2c5790b84ed7bb1b412f1d518 :
-rw-r--r-- 1 zedtux zedtux 2334 Feb 3 23:38 douane-testing_0.8.1-apt1.debian.tar.gz
On my server, the file with the md5 df78f88b97cadc10bc0a73bf86442838 :
-rw-r--r-- 1 root root 2344 Feb 5 00:58 douane-testing_0.8.1-apt1.debian.tar.gz
I have pbuild version 0.213 on my server.
What could be the reason of this behavior and how can I fix it ?
Edit
I'm suspecting an issue with the GPG key which looks missing and then files aren't signed so md5sum is different.
During the build process I have the following lines:
I: Extracting source
gpgv: Signature made Wed Feb 5 22:04:37 2014 UTC using RSA key ID 9474CF36
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./douane-testing_0.8.1-apt1.dsc
Edit 2
I have tried to find the command to create manually the .debian.tar.gz file.
The best I've found is the following:
tar cv debian | gzip --no-name --rsyncable -9 > douane-testing_0.8.1-apt1.debian.tar.gz
I don't get the same result than dpkg-source but I tried the same command on my server (I should at least have the same size) but it's not matching...
Could it be that Debian and Ubuntu aren't compressing the same way ?

Finally after some evenings of research I found the solution on launchpad.net !
Found the solution. By default pbuilder calls dpkg-buildpackage like so:
DEBBUILDOPTS="$DEBBUILDOPTS -rfakeroot"
dpkg-buildpackage -us -uc $DEBBUILDOPTS
That causes dpkg-buildpackage to rebuild the diff.gz and .dsc files. Add a -b in there, and it won't. It also means the resulting .changes file will only reference the .deb file. Which is what you want, I think.
The easy solution is to add a line to your .pbuilderrc:
DEBBUILDOPTS="-b"

My previous answer is alright but is not complete.
Then I had the issue that reprepro complains about the source tarball (.orig.tar.xz).
But it was normal as I wasn't doing the packages correctly.
I have written a bash script which I'm executing in VM for each Ubuntu series.
This script was always doing everything from scratch, and was using dh_make --createorig argument and here is the issue.
The correct way is to generate once (for example on Ubuntu precise) and then re-use the .orig.tar.xz file and no more use the --createorig argument of dh_make.
I hope this could help someone :-)

Related

LateX on Mac: Texmaker can't find installed package

I have a Mac and just installed LaTeX and the editor Texmaker. To use the Arial font I installed it via MiKTeX Console. I also found out that by doing so, the files for the installed packages lay here:
"/Users/Mirko/Library/Application Support/MiKTeX/texmfs/install/tex/latex"
My problem is that the Editor (TeXMaker) still doesn't find the Arial-Font.
Here is my Code:
\documentclass[pdftex,openany,11pt,twoside,a4dutch]{report}
\usepackage{uarial}
\usepackage{csquotes}
\usepackage[ngerman]{babel}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{csquotes} % Setzen von Anführungsstrichen
\begin{document}
This is a test.
\end{document}
and here is the Error:
! LaTeX Error: File `uarial.sty' not found.Type X to quit or <RETURN> to proceed,or enter new name. (Default extension: sty)Enter file name:! Emergency stop.<read > \usepackage
But the folder arial and the file arial.sty are in the above mentioned folder.
In the MikTeX-Console I already entered the folder to Directories > Settings
I thankful for every help!
Thanks and greetings!
Here is the log-file from TexMaker:
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) (preloaded format=pdflatex 2019.10.27) 27 OCT 2019 13:34
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
**test.tex
(./test.tex
LaTeX2e <2018-12-01>
(/usr/local/texlive/2019/texmf-dist/tex/latex/base/report.cls
Document Class: report 2018/09/03 v1.4i Standard LaTeX document class
(/usr/local/texlive/2019/texmf-dist/tex/latex/base/size11.clo
File: size11.clo 2018/09/03 v1.4i Standard LaTeX file (size option)
)
\c#part=\count80
\c#chapter=\count81
\c#section=\count82
\c#subsection=\count83
\c#subsubsection=\count84
\c#paragraph=\count85
\c#subparagraph=\count86
\c#figure=\count87
\c#table=\count88
\abovecaptionskip=\skip41
\belowcaptionskip=\skip42
\bibindent=\dimen102
)
! LaTeX Error: File `uarial.sty' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
<read *>
l.5 \usepackage
{csquotes}^^M
*** (cannot \read from terminal in nonstop modes)
Here is how much of TeX's memory you used:
221 strings out of 492616
2365 string characters out of 6129480
60608 words of memory out of 5000000
4231 multiletter control sequences out of 15000+600000
3940 words of font info for 15 fonts, out of 8000000 for 9000
1141 hyphenation exceptions out of 8191
21i,0n,22p,110b,36s stack positions out of 5000i,500n,10000p,200000b,80000s
! ==> Fatal error occurred, no output PDF file produced!
As you can see from the first line of the log file
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019)
texmaker is not using the miktex distribution for which you installed the uarial package, but a texlive distribution which seems to be also installed on your computer. In the long run it would be best to only have a single tex distribution on your computer to avoid such problems. For mac I would suggest to keep the texlive distribution and get rid of miktex, because texlive is used by most mac users and therefore well tested compared to miktex for mac.
Now you could force texmaker to use your miktex installation by modifying the texmaker preferences, but the easier way to use Arial in your document is to switch from pdflatex to xelatex or lualatex and directly use the arial font installed on your computer
% !TeX TS-program = xelatex
\documentclass[openany,11pt,twoside,a4dutch]{report}
\usepackage{fontspec}
\setmainfont{Arial}
\usepackage[ngerman]{babel}
\usepackage[utf8]{inputenc}
\usepackage{csquotes}
\begin{document}
This is a test.
\end{document}

What is the difference between kobject, device_create and my code?

I am currently reading a book entitled "Linux device drivers" from O'Reilly.
Thing is that this book imo isn't really a guide on how to write drivers but it instead explains all the apis and their prinicples.
So I tried writing a small driver -which doesn't do anything interesting -with what I read so far.
Thing is:
I don't know which file I can execute cat on or echo to in order to invoke my callback functions
it looks nothing like all the other code snippets I found online
The different pieces of code:
my code (https://paste.ubuntu.com/p/8tVyTJTPBQ/)
creates:
$ls /sys/module/main/
oresize holders initsize initstate notes refcnt sections srcversion taint uevent
no new entry in /dev
code snippet using device_create: https://paste.ubuntu.com/p/cJxjdyXjhX/ source
creates:
$ ls /sys/module/main/
coresize holders initsize initstate notes refcnt sections srcversion taint uevent
$ ls -l /dev/ebbchar
crw------- 1 root root 238, 0 Mai 28 07:52 /dev/ebbchar
code using kobjects: https://paste.ubuntu.com/p/nt3XvZs7vF/ source
creates:
$ls -l /sys/kernel/
drwxr-xr-x 2 root root 0 Dec 17 16:29 etx_sysfs
I can see that my code successfully created a bunch of files under /sys/kernel. Now what is the difference in endgoal between my code and the two other snippets? Should I use device_create/kobjects or maybe none of those? The book I am reading doesn't mention anywhere the functions used by the 2 other pieces of code. So not sure which way I am supposed to follow...
Thanks_xe
device_create() creates a device and registers it with sysfs, and create necessary kobjects.
To create necessary kobjects, kobject-related functions(kobject_init(), kobject_add(), ...) are called in device_create().
If you need to create a device, you should call one of device creation functions like device_create().
Answering your question of how to keep up with latest api- Most api if renamed or updated retain similar name and reside mostly in the same header file so a quick grep on the source or easier is http://elixir.bootlin.com/ and search the source doc for a particular function in the Linux release you are working on. if you cant find the API in that release then go through the header to find the new API as the name will almost be the same for example when you will read the Timer chapter , you will find that setup_timer() has been changed to timer_setup(). and few other changes here and there.
If you feel like you can keep up with the latest discussion by subscribing to the kernel maillist or reading the documentation.

Alpine APK Package Repositories, how are the checksums calculated?

I'm trying to work out how the pull checksum for packages is calculated within Alpine APK package repositories. The documentation regarding the format is lacking in any detail.
When I run apk index -o APKINDEX.unsigned.tar.gz *.apk which generates the repository. When you extract the txt file from inside the gz, it contains the following...
C:Q17KXT6xFVWz4EZDIbkcvXQ/uz9ys=
P:redis-server
V:3.2.3-0
A:noarch
S:2784844
I:102400
T:An advanced key-value store
U:http://redis.io/
L:
D:linux-headers
I'm interested in how the very first line is generated. I've tried to read the actual source that's used to generate this, but I'm not a C programmer, so it's hard for me to comprehend as it jumps all over the place.
The two files mentioned in the documentation are database.c and package.c.
Incase this somewhat helps, the original APK file has these various hashes...
CRC32 = ac17ea88
MD5 = a035ecf940a67a6572ff40afad4f396a
SHA1 = eca5d3eb11555b3e0464321b91cbd743fbb3f72b
SHA256 = 24bc1f03409b0856d84758d6d44b2f04737bbc260815c525581258a5b4bf6df4
The pull checksum is the sha1sum of the second tar.gz file in the apk file, containing the .PKGINFO file.
The Alpine APK package is actually a concatenation in disguise of 3 tar.gz files.
We can split the package below using gunzip-split into 3 .gz files, then rename them to .tar.gz
./gunzip-split -s -o ./out/ strace-5.14-r0.apk
mv ./out/file_1.gz ./out/file_1.tar.gz
mv ./out/file_2.gz ./out/file_2.tar.gz
mv ./out/file_3.gz ./out/file_3.tar.gz
sha1sum ./out/file_2.tar.gz
7a266425df7bfd7ce9a42c71a015ea2ae5715838 out/file_2.tar.gz
tar tvf out/file_2.tar.gz
-rw-r--r-- root/root 702 2021-09-03 01:34 .PKGINFO
In the case of the strace package the checksum value can be derived as above:
apk index strace-5.14-r0.apk -o APKINDEX.tar.gz
tar xvf APKINDEX.tar.gz
cat APKINDEX
echo eiZkJd97/XzppCxxoBXqKuVxWDg=|base64 -d|xxd
00000000: 7a26 6425 df7b fd7c e9a4 2c71 a015 ea2a z&d%.{.|..,q...*
00000010: e571 5838 .qX8
When comparing them we see that they match.
References
https://github.com/martencassel/apk-tools/blob/master/README.md
https://gitlab.com/cg909/gunzip-split/-/releases
https://lists.alpinelinux.org/~alpine/devel/%3C257B6969-21FD-4D51-A8EC-95CB95CEF365%40ferrisellis.com%3E#%3C20180309152107.472e4144#vostro.util.wtbts.net%3E
So...
/* Internal cointainer for MD5 or SHA1 */
struct apk_checksum {
unsigned char data[20];
unsigned char type;
};
Basically take the C: value then chop off the Q from the front then base 64 decode. Chop off the last value (type which defaults to SHA1) then you have your sha1. This appears to be made of the CONTENTS of the package but that would take further looking into it.
You need to look here: https://git.alpinelinux.org/cgit/apk-tools/tree/src/blob.c#n492
It is apk_blob_pull_csum
First 'Q' stands for encoding
Next '1' stands for SHA1
Looks like this checksum is made database.c in apk_db_unpack_pkg:
apk_sign_ctx_init(&ctx.sctx, APK_SIGN_VERIFY_IDENTITY, &pkg->csum, db->keys_fd);
tar = apk_bstream_gunzip_mpart(bs, apk_sign_ctx_mpart_cb, &ctx.sctx);
r = apk_tar_parse(tar, apk_db_install_archive_entry, &ctx, TRUE, &db->id_cache);
but I'm not sure, because I failed to trace this code.
It is really not easy to understand what are they doing.

rpm and Yum don't believe a package is installed after Chef installs

Running chef-solo (Installing Chef Omnibus (12.3)) on centos6.6
My recipe has the following simple code:
package 'cloud-init' do
action :install
end
log 'rpm-qi' do
message `rpm -qi cloud-init`
level :warn
end
log 'yum list' do
message `yum list cloud-init`
level :warn
end
But it outputs the following:
- install version 0.7.5-10.el6.centos.2 of package cloud-init
* log[rpm-qi] action write[2015-07-16T16:46:35+00:00] WARN: package cloud-init is not installed
[2015-07-16T16:46:35+00:00] WARN: Loaded plugins: fastestmirror, presto
Available Packages
cloud-init.x86_64 0.7.5-10.el6.centos.2 extras
I am at a loss as to why rpm/yum and actually rpmquery don't see the package as installed.
EDIT: To clarify I am specifically looking for the following string post package install to then apply a change to the file (I understand this is not a very chef way to do something I am happy to accept suggestions):
rpmquery -l cloud-init | grep 'distros/__init__.py$'
I have found that by using the following:
install_report = shell_out('yum install -y cloud-init').stdout
cloudinit_source = shell_out("rpmquery -l cloud-init | grep 'distros/__init__.py$'").stdout
I can then get the file I am looking for and perform
Chef::Util::FileEdit.new(cloudinit_source.chomp(''))
The file moves based on the distribution but I need to edit that file specifically with in place changes.
Untested code, just to give the idea:
package 'cloud-init' do
action :install
notifies :run,"ruby_block[update_cloud_init]"
end
ruby_block 'update_cloud_init' do
block do
cloudinit_source = shell_out("rpmquery -l cloud-init | grep 'distros/__init__.py$'").stdout
rc = Chef::Util::FileEdit.new(cloudinit_source.chomp(''))
rc.search_file_replace_line(/^what to find$/,
"replacement datas for the line")
rc.write_file
end
end
ruby_block example taken and adapted from here
I would better go using a template to manage the whole file, what I don't understand is why you don't know where it will be at first...
Previous answer
I assume it's a compile vs converge problem. at the time the message is stored (and so your command is executed) the package is not already installed.
Chef run in two phase, compile then converge.
At compile time it build a collection of resources and at converge time it execute code for the resource to get them in the described state.
When your log resource is compiled, the ugly back-ticks are evaluated, at this time there's a package resource in the collection but the resource has not been executed, so the output is correct.
I don't understand what you want to achieve with those log resources at all.
If you want to test your node state after chef-run use a handler maybe calling ServerSpec as in Test-Kitchen.

During apachectl start getting open shared object file: No such file or directory

After successfully installation of Apache2(2.4.4) i tried to start https server but i am getting below error
bimlesh#server:/usr/local/apache2/bin$ ./apachectl start
httpd: Syntax error on line 71 of /usr/local/apache2/conf/httpd.conf: Cannot load modules/mod_authn_core.so into server: /usr/local/apache2/modules/mod_authn_core.so: cannot open shared object file: No such file or directory
bimlesh#server:/usr/local/apache2/bin$
I looked at /usr/local/apache2/modules/ and really those .so files are not available.
Can anyone please help that how to get rid off.
if i look at /usr/local/apache2/modules/ folder then i see:(no .so files available)
bimlesh#server:/usr/local/apache2/bin$ ls ../modules/
httpd.exp mod_authn_file.a mod_cache_disk.a mod_file_cache.a mod_logio.la mod_ratelimit.a mod_socache_dbm.la
mod_access_compat.a mod_authn_file.la mod_cache_disk.la mod_file_cache.la mod_mime.a mod_ratelimit.la mod_socache_memcache.a
mod_access_compat.la mod_authn_socache.a mod_cache.la mod_filter.a mod_mime.la mod_remoteip.a mod_socache_memcache.la
mod_actions.a mod_authn_socache.la mod_cgid.a mod_filter.la mod_negotiation.a mod_remoteip.la mod_socache_shmcb.a
mod_actions.la mod_authz_core.a mod_cgid.la mod_headers.a mod_negotiation.la mod_reqtimeout.a mod_socache_shmcb.la
mod_alias.a mod_authz_core.la mod_dav.a mod_headers.la mod_proxy.a mod_reqtimeout.la mod_speling.a
mod_alias.la mod_authz_dbd.a mod_dav_fs.a mod_include.a mod_proxy_ajp.a mod_request.a mod_speling.la
mod_allowmethods.a mod_authz_dbd.la mod_dav_fs.la mod_include.la mod_proxy_ajp.la mod_request.la mod_status.a
mod_allowmethods.la mod_authz_dbm.a mod_dav.la mod_info.a mod_proxy_balancer.a mod_rewrite.a mod_status.la
mod_auth_basic.a mod_authz_dbm.la mod_dbd.a mod_info.la mod_proxy_balancer.la mod_rewrite.la mod_substitute.a
mod_auth_basic.la mod_authz_groupfile.a mod_dbd.la mod_lbmethod_bybusyness.a mod_proxy_connect.a mod_sed.a mod_substitute.la
mod_auth_digest.a mod_authz_groupfile.la mod_deflate.a mod_lbmethod_bybusyness.la mod_proxy_connect.la mod_sed.la mod_unique_id.a
mod_auth_digest.la mod_authz_host.a mod_deflate.la mod_lbmethod_byrequests.a mod_proxy_express.a mod_session.a mod_unique_id.la
mod_auth_form.a mod_authz_host.la mod_dir.a mod_lbmethod_byrequests.la mod_proxy_express.la mod_session_cookie.a mod_unixd.a
mod_auth_form.la mod_authz_owner.a mod_dir.la mod_lbmethod_bytraffic.a mod_proxy_fcgi.a mod_session_cookie.la mod_unixd.la
mod_authn_anon.a mod_authz_owner.la mod_dumpio.a mod_lbmethod_bytraffic.la mod_proxy_fcgi.la mod_session_dbd.a mod_userdir.a
mod_authn_anon.la mod_authz_user.a mod_dumpio.la mod_lbmethod_heartbeat.a mod_proxy_ftp.a mod_session_dbd.la mod_userdir.la
mod_authn_core.a mod_authz_user.la mod_env.a mod_lbmethod_heartbeat.la mod_proxy_ftp.la mod_session.la mod_version.a
mod_authn_core.la mod_autoindex.a mod_env.la mod_log_config.a mod_proxy_http.a mod_setenvif.a mod_version.la
mod_authn_dbd.a mod_autoindex.la mod_expires.a mod_log_config.la mod_proxy_http.la mod_setenvif.la mod_vhost_alias.a
mod_authn_dbd.la mod_buffer.a mod_expires.la mod_log_debug.a mod_proxy.la mod_slotmem_shm.a mod_vhost_alias.la
mod_authn_dbm.a mod_buffer.la mod_ext_filter.a mod_log_debug.la mod_proxy_scgi.a mod_slotmem_shm.la
mod_authn_dbm.la mod_cache.a mod_ext_filter.la mod_logio.a mod_proxy_scgi.la mod_socache_dbm.a
bimlesh#server:/usr/local/apache2/bin$
Run
find / -type f -name mod_authn_core.so
or install updatedb ( mlocate, slocate, findutils or sth ) if needed and run
updatedb
and then ( or before )
locate mod_authn_core.so
To find out if these files are somewere else than they should be, and possibly fix location with symbolic link or moving files where they're expected to be.
If there is no file you need, you may need to comment it in httpd.conf ( if it's specific module ), or (re)install apache package(s). I believe mod_authn_core should be in basic package, not in separate module though. Possibly someone removed it blindly or accidentally, or some intruder messed up with system, or disk got broken or whatever else.
PS. Modules usually are under "lib" e.g. /usr/local/lib/apache2 or /usr/lib/apache2, or /usr/lib/apache2/modules or similar, not in /usr/local/apache2/modules, though it usually depends on compilation of package..
You might also run
apache2ctl -t -D DUMP_VHOSTS
to find out what modules were compiled as shared or static. You should also include information about distribution, and note you're building/installing from source.
Also, have look here: http://httpd.apache.org/docs/2.4/install.html#configure

Resources