Re: RFC: endorse debian-mentors as entrance to our infrastructure projects
Hey again, Jonas Meurer: >>> So here's the idea we came up with: We could explicitely broaden the >>> scope of debian-mentors to include any questions regarding Debian >>> infrastructure software. >>> That basicly would mean to explicitely mention "questions on >>> infrastruc-ture projects" in our docs about debian-mentors. >>> Additionally, when the infrastructure teams don't have time to mentor >>> new contributors, they could point them to debian-mentors. >>> >>> My hope is that having debian-mentors as an endorsed entry point for >>> diving into Debian infrastructure would lower the entry barrier >>> significantly for new contributors who'd like to dive into our >>> infrastructure software projects. >> >> Next step will be to update the documentation about debian-mentors: >> >> Once this is done, it should be announced on more popular channels. Misc >> Developer News[4] would be a good one and maybe also a dedicated mail to >> debian-devel-announce? >> >> [4] https://wiki.debian.org/DeveloperNews >> >> I think the key to success here is that people in Debian (especially >> those in infrastructure/service teams) have to adapt to the practice of >> pointing newbies with their questions to debian-mentors. > > Will do that once the list description got updated. Since the mailinglist description got updated very quickly I went ahead and added a paragraph about the broadened debian-mentors scope to DeveloperNews: https://wiki.debian.org/DeveloperNews#Scope_of_debian-mentors_broadened_to_help_with_infrastructure_questions Again, feel free to review and improve :) Cheers jonas signature.asc Description: OpenPGP digital signature
Re: RFC: endorse debian-mentors as entrance to our infrastructure projects
Hello, Jonas Meurer: > Jonas Meurer: >> So here's the idea we came up with: We could explicitely broaden the >> scope of debian-mentors to include any questions regarding Debian >> infrastructure software. >> That basicly would mean to explicitely mention "questions on >> infrastruc-ture projects" in our docs about debian-mentors. >> Additionally, when the infrastructure teams don't have time to mentor >> new contributors, they could point them to debian-mentors. >> >> My hope is that having debian-mentors as an endorsed entry point for >> diving into Debian infrastructure would lower the entry barrier >> significantly for new contributors who'd like to dive into our >> infrastructure software projects. > > Next step will be to update the documentation about debian-mentors: > > * Update the DebianMentorsFaq wiki page[1] and make it explicit that > questions about Debian infrastructure projects and services are > on-topic. I finally found some time to update the DebianMentorsFaq. Would be great if some native english speakers could review (and improve) it: https://wiki.debian.org/DebianMentorsFaq?action=diff=69=70 > * Update the debian-mentors list description[2]. I filed bugreport #931634 and asked to update the list description: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931634 > * Maybe add a shore paragraph about the scope of the debian-mentors > channels to the startpage of mentors.debian.net? While it's a separate > service, it probably is an entry point for prospective contributors. Maybe that one should be left as is for now, as the whole purpose of mentors.debian.net is to coordinate sponsored package uploads. > Once this is done, it should be announced on more popular channels. Misc > Developer News[4] would be a good one and maybe also a dedicated mail to > debian-devel-announce? > > [4] https://wiki.debian.org/DeveloperNews > > I think the key to success here is that people in Debian (especially > those in infrastructure/service teams) have to adapt to the practice of > pointing newbies with their questions to debian-mentors. Will do that once the list description got updated. Cheers jonas signature.asc Description: OpenPGP digital signature
Bug#931634: lists.debian.org: Update description for debian-mentors@lists.d.o
Package: lists.debian.org Severity: normal Hello, as discussed on debian-project and debian-mentors [1], the scope of debian-mentors@lists.d.o was broadened to explicitely include questions regarding Debian infrastructure projects. The DebianMentorsFaq already has been updated accordingly [2, 3] To reflect this broadened scope, the description of the debian-mentors mailinglist on lists.debian.org should be changed to: > *Helping newbie developers* > Newbie Debian contributors can seek help with packaging and infrastructure > projects as well as other developer-related issues here. > > This list is not meant for users' questions, but for new contributors'! > > This list is not moderated; posting is allowed by anyone. > > List FAQ: https://wiki.debian.org/DebianMentorsFaq > > Posting address: debian-mentors@lists.debian.org Thanks a lot for your work, listmasters! Cheers jonas
Re: webapp packaging
Hey Wookey, In general, I think that we should aim for webapps being accessible (and usable) out-of-the-box after installation while still allowing later customization by admins. Wookey: > The app consists of one main program file (boc.pl), a config file, > and a set of resource files (html, images and some internal perl > modules). > > Upstream intends all the files to be dropped into one location which > is made cgi-executable (for *.pl), (and www-data readable) but this > doesn't really fit very well with debian policy/default config, where > the config file in in /etc and the the cgi-bin file is in > /usr/lib/cgi-bin and the rest is in /usr/share/package. Yeah, I would place the different parts of the webapp exactly the way you described it on the filesystem. > It also uses a git repo as a data store. (which needs to be r/w by > www-data). The root of that is set in the config file. > > So. To my questions: > > 1) This won't work without cgi enabled in apache. Cgi (mod_cgi or > mod_cgid) is installed but disabled in a fresh install of > apache. However none of the packages I looked at that install things > in /usr/lib/cgi-bin turns mod_cgi or mod_cgid on. Is it in fact policy > that packages should not enable webserver features like this, and it > has to be an admin task? Currently I have a postinst that works out > which module is needed (with a2query -M) and then enables it with > a2enmod. Should it in fact not do this? It's pretty common for webapps to activate/deactivate Apache2 modules in postinst. So I don't see a problem with your app doing it. Quite the contrary, the package would be useless without the module, so I think that you *should* activate it in postinst. I do the same in my (admitted rather rusty) package 'lurker'. > 2) Where should a default data dir for a web-app live? > /var/www/package? /var/lib/package? Somewhere else? And for the app > itself? dwww puts stuff in /var/www/dwww and /usr/share/dwww as well > as the binary in /usr/lib/cgi-bin. I'm really not quite sure how one > decides what goes where. That would be /var/lib/package. At least that would be the case if the data dir doesn't have to live in the webservers document root. > 3) There is some tension between heavily debianfying such a package > (so it just works after install and looks debian-packagey' and leaving > it more like upstream 'all in one dir, sort out your own config'. One > doesn't know how the webserver will be set up (vhosts etc). Especially > if having things in different dirs meand significnat patching of > upstream - that seems like a maintenance burden and potential > bug-source. I definitely think it's worth the effort nevertheless. If we aim for packaging webapps at all in Debian, then we should make it easier for the admin compared to installing the upstream version in a vhost docroot. > 4) It's nicer (in 2019) to have a URL like http://localhost/package/ > or http://localhost/package/boc.pl than one with cgi-bin in it: > http://localhost/cgi-bin/boc.pl Is there policy on this or other > guidelines? Other packages seem to do all sorts of things. I think there's no clear guideline on this and the decision is left to you. if it's a single CGI file, I would probably provide an Alias /package that points to this CGI file. In general, providing a webserver config include file (in case of Apache under /etc/apache2/conf-available/) is very helpful. Many webapps ask via debconf whether the webserver should be configured automatically. You might want to consider this. Again, you might want to take a look at lurker (or mailman-suite) source package for an example. If the admin decides to auto-configure the webserver during installation, then the config include file will be activated globally (therefore being available on all vhosts). If the admin doesn't want this, they can manually include the config include file in the desired vhost. > 5) Should a package support other web-server configs than apache? That'd be really nice! We try to do so for nginx at least in mailman-suite. Unfortunately, last time I looked, the tools to manage config include files where not in place yet in the Debian nginx packages. Maybe that changed in the meantime. Cheers jonas signature.asc Description: OpenPGP digital signature
Re: RFC: endorse debian-mentors as entrance to our infrastructure projects
Hi again, Jonas Meurer: > So here's the idea we came up with: We could explicitely broaden the > scope of debian-mentors to include any questions regarding Debian > infrastructure software. > That basicly would mean to explicitely mention "questions on > infrastruc-ture projects" in our docs about debian-mentors. > Additionally, when the infrastructure teams don't have time to mentor > new contributors, they could point them to debian-mentors. > > My hope is that having debian-mentors as an endorsed entry point for > diving into Debian infrastructure would lower the entry barrier > significantly for new contributors who'd like to dive into our > infrastructure software projects. Thanks a lot to everybody involved in the discussion so far. Apparently there's some support for the idea, so I'll try to drive it forward. Next step will be to update the documentation about debian-mentors: * Update the DebianMentorsFaq wiki page[1] and make it explicit that questions about Debian infrastructure projects and services are on-topic. * Update the debian-mentors list description[2]. * Maybe add a shore paragraph about the scope of the debian-mentors channels to the startpage of mentors.debian.net? While it's a separate service, it probably is an entry point for prospective contributors. * I already updated the description about #debian-mentors on the IRC wiki page[3]. [1] https://wiki.debian.org/DebianMentorsFaq [2] https://lists.debian.org/debian-mentors/ [3] https://wiki.debian.org/IRC I'll try to take care of this within the next days. Nevertheless, help would be appreciated ;) Are there any places that I'm missing? Once this is done, it should be announced on more popular channels. Misc Developer News[4] would be a good one and maybe also a dedicated mail to debian-devel-announce? [4] https://wiki.debian.org/DeveloperNews I think the key to success here is that people in Debian (especially those in infrastructure/service teams) have to adapt to the practice of pointing newbies with their questions to debian-mentors. Paul Wise: > As someone who is regularly answering mentors questions, is a DSA > member, a wiki admin, maintainer of the derivatives services and > contributor to some of the QA services, I would be happy to answer any > infrastructure questions that come up on debian-mentors. That's fantastic news. Thanks a lot for being open to it and offering help :) Sam Hartman: > I wonder whether it might be a good idea to write down which > infrastructure services people in the mentors community are most able > to help with. I don't think, that's necessary - or even helpful. Also, it would mean that some kind of "experts" for infrastructure projects would have to volunteer for ansering questions on debian-mentors, which in my eyes makes the whole idea way to complicated. I think we should give it a try without explicitely documenting *which* infrastructure services will be supported by debian-mentors. As Paul said, people on debian-mentors might be able to help with research and looking up things in case they don't know the answers themselves - something that's already very useful for new contributers that tend to get lost in the huge Debian ecosystem ;) Cheers jonas signature.asc Description: OpenPGP digital signature
RFC: endorse debian-mentors as entrance to our infrastructure projects
Hi, During MiniDebConf in Hamburg, I had an interesting conversation about the question of how we can attract more people to contribute to Debian infrastructure projects. There seems to be some consensus that such infrastructure projects are the ones in Debian that most badly need more contributors. [1] At the same time, our infrastructure projects/teams have a rather high entry barrier. Apparently, one reason is that understaffed teams with high workload usually lack the time and ressources to mentor new contributors. At the same time we have a fantastic entrance area for new contributors when it comes to packaging questions: the debian-mentors channels (IRC channel and mailinglist) both stand out with a nice and welcoming atmosphere that actively encourages new contributors to ask their questions. So here's the idea we came up with: We could explicitely broaden the scope of debian-mentors to include any questions regarding Debian infrastructure software. That basicly would mean to explicitely mention "questions on infrastruc-ture projects" in our docs about debian-mentors. Additionally, when the infrastructure teams don't have time to mentor new contributors, they could point them to debian-mentors. My hope is that having debian-mentors as an endorsed entry point for diving into Debian infrastructure would lower the entry barrier significantly for new contributors who'd like to dive into our infrastructure software projects. What do you think about this proposal? Cheers jonas [1] Let me give two examples for such "infrastructure projects": */ Many in Debian agree that Debbugs could need some love, but still it's developed and maintained largely by one brave soul. */ The concept of bikeshed keeps popping up for years and usually gets a lot of affirmation. Still, only one developer worked on it so far and nobody else stepped up to implement a working solution. signature.asc Description: OpenPGP digital signature
Re: How do you delete a sbuild an sbuild chroot and start over?
Am 03.08.2016 um 06:20 schrieb Sean Whitton:
> On Tue, Aug 02, 2016 at 11:06:31PM -0500, Paul Elliott wrote:
>> Sometimes a user gets a sbuild chroot so screwed up that it does not
>> work anymore, and the user has no idea how to fix it, because he does not
>> know what he did wrong.
>>
>> He wants to start over from scratch.
>>
>> The problem is, it is not documented the correct way to delete
>> the chroot and tar ball. The users want to put sbuild back to
>> the way it was just after sbuild was installed.
>>
>>
>> What is the proper way to do that?
>
> Asking for a friend? ;)
>
> Assuming you used the suggestions for making the chroot on the sbuild
> wiki page, this should do it:
>
> # rm -rf /srv/chroot/* /etc/sbuild/chroot/*-sbuild
> /etc/schroot/chroot.d/*-sbuild
Please note that this will delete *all* chroots and their configuration.
I woud prefer something like:
SCHROOT=unstable-amd64-sbuild
SCHROOT_DIR=$(readlink -e /etc/sbuild/${SCHROOT})
rm -r ${SCHROOT_DIR} /etc/sbuild/${SCHROOT} \
/etc/schroot/chroot.d/$[SCHROOT}-*
Afterwards you can start over by creating a fresh version of the schroot
with sbuild-createchroot as documented on the wiki page[1].
Cheers,
jonas
[1] https://wiki.debian.org/sbuild
> If you didn't use the suggestions on the wiki page, just start nuking
> stuff in those three directories.
>
signature.asc
Description: OpenPGP digital signature
Re: shell kung-fu with set -e, return codes and i/o redirection in while read ... loop
On 20/07/2009 Boyd Stephen Smith Jr. wrote:
In 20090719235708.gb22...@resivo.wgnet.de, Jonas Meurer wrote:
- in cryptdisks_{start|stop} only one device is setup anyway. here I
simply don't use set -e and check for the error code instead.
While I understand your goal here, I think you should try and accomplish it
while leaving the entire script set -e. It helps prevent errors from
cascading. Even if you are checking return values for everything now, you
might not be so disciplined with changes in the future.
i see your point and indeed i already reverted the change to not set -e
the scripts. instead I now use a if statement for the invokation of
handle_crypttab_line_{start,stop}, do post-cryptsetup stuff (umount)
directly in the while loop, and exit with log_action_end_msg $ret at the
end of the while loop. that way the script always stops inside the while
loop, with or without error.
greetings,
jonas
signature.asc
Description: Digital signature
shell kung-fu with set -e, return codes and i/o redirection in while read ... loop
Hello,
in the cryptsetup init and cryptdists_{start|stop} scripts we use some
shell magic with set -e, while read ... done and input/output
redirection. i have to admit that this magic demonstrated me the limits
of my shell scripting skills.
the code in question is:
set -e
...
egrep -v ^[[:space:]]*(#|$) $TABFILE | while read dst src key opts; do
...
handle_crypttab_line_start $dst $src $key $opts 3
...
done 31
and the bugs that I try to fix are:
#524173
cryptdisk_start target doesn't return a sensible exit code on failure.
#524485
cryptdisks_start incorrectly reports failure
now let me try to explain the problem:
cryptdisks_start is a script that takes a target name as single argument
and starts this cryptdisks target with the options from /etc/crypttab.
many functions are shared in /lib/cryptsetup/cryptdisks.functions for
cryptdisks_{start|stop} and the cryptdisks initscripts.
cryptdisks_start at the moment always exits with error code 0 (success),
even if errors occured (target not found in /etc/crypttab, failed to
start, ...), and even worse, it doesn't even detect correctly whether
the target was found or not.
so the script needs to be changed to exit the while loop with
information about whether
- the target was found in crypttab
- the target setup succeeded or not
for the first one I only see one solution: add a counter to the while
loop which checks for $count -ge $valid_crypttab_lines.
for the second one I first thought that wrapping the complete while
loop with ret=$(while read ... done) would be an option, but
unfortunately that doesn't work due to input redirection to/from
filedescripter 3 (3, 31) ...
so second thought was to use return codes inside the while loop and
check for them after the while loop. but that failed due to 'set -e'
being set. therefore any return code != 0 caused the script to stop
immediately instead of just exiting the while loop.
now I see the option to set -e only inside the while loop, but I would
like to have other opinions about that idea before actually implementing
it. tests on my system gave me the impression that it works as expected:
count=0
tablen=$(egrep -v ^[[:space:]]*(#|$) $TABFILE | /usr/bin/wc -l)
egrep -v ^[[:space:]]*(#|$) $TABFILE | while read dst src key opts; do
set -e
count=$(( $count + 1 ))
if [ $1 = $dst ]; then
handle_crypttab_line_start $dst $src $key $opts 3
exit $?
fi
if [ $count -ge $tablen ]; then
device_msg $1 failed, not found in crypttab
exit 1
fi
done 31
ret=$?
...
log_action_end_msg $ret
only one issue remains that still doesn't work as expected:
if handle_crypttab_line_start fails with a warning, it still returns 0
(success) as return code. unfortunately I don't see an option t change
that one.
in initscripts it would be fatal for handle_crypttab_line_start to exit
with any return code != 0 as that would cause the whole initscript to
stop instead of processing the remaining crypt targets.
maybe the best solution would be to rewrite the whole story, but I don't
even have an idea how to do it better.
thanks in advance for any comments.
greetings,
jonas
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: shell kung-fu with set -e, return codes and i/o redirection in while read ... loop
Hello, On 19/07/2009 Chow Loong Jin wrote: On Sunday 19,July,2009 07:45 PM, Jonas Meurer wrote: so the script needs to be changed to exit the while loop with information about whether - the target was found in crypttab You already have that information. In the snippet of code: found=no egrep -v ^[[:space:]]*(#|$) $TABFILE | while read dst src key opts; do if [ $1 = $dst ]; then found=yes handle_crypttab_line_start $dst $src $key $opts 3 exit 0 fi done 31 Note the value of the variable found. If it's yes, it was found, otherwise it's not. no, unfortunately not. the while read ... loop opens a subshell, thus the found=yes inside is pointless. greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: shell kung-fu with set -e, return codes and i/o redirection in while read ... loop
On 19/07/2009 Boyd Stephen Smith Jr. wrote:
In 20090719114552.ga15...@resivo.wgnet.de, Jonas Meurer wrote:
so second thought was to use return codes inside the while loop and
check for them after the while loop. but that failed due to 'set -e'
being set. therefore any return code != 0 caused the script to stop
immediately instead of just exiting the while loop.
If you use the command in an if/while/until statement, it can fail without
terminating the script, even when the -e shell option is set. You might
be able to use something like:
while something; do
if cmd_that_can_fail; then :; else
# Just can check $? if you want
# to know the exact return code.
# Print a warning, but
continue
fi
done
ah, that indeed is an option. I now solved the issue the following way:
- in cryptdisks_{start|stop} only one device is setup anyway. here I
simply don't use set -e and check for the error code instead.
- in cryptdisks initscript set -e is set, and handle_crypttab_line_start
is wrapped in an if statement:
handle_crypttab_line_start $dst $src $key $opts 3 || true
greetings,
jonas
signature.asc
Description: Digital signature
how to exclude python (test-)modules from byte-compilation with dh_pycentral
Hello, At preparing zope2.11.3 packages, I found several python (test-)modules that do have python2.5/python2.6 code. This code is mostly for checking python2.5/python2.6 support, and thus isn't relevant for the functionality of zope itself. Zope2.11.3 still requires python2.4, so when the package is installed, python-central exits with a byte-compiling error, see below. Is there any possiblity to exclude/ignore the modules in question at byte-compilation time? I found -X for dh_pycentral, but that one doesn't seem to do what I expected it to do. Another solution would be to completely remove the test modules in question, but that would require a lot of work, as at least the mechanize module (last error) is used in several other test modules of zope2.11.3, and I don't want to remove all/most test modules after all. here are the errors I do get: Setting up zope2.11 (2.11.3-1) ... Compiling /usr/lib/zope2.11/lib/python/RestrictedPython/tests/before_and_after25.py ... File /usr/lib/zope2.11/lib/python/RestrictedPython/tests/before_and_after25.py, line 30 x.y = y.z if y.z else y.x ^ SyntaxError: invalid syntax Compiling /usr/lib/zope2.11/lib/python/RestrictedPython/tests/before_and_after26.py ... File /usr/lib/zope2.11/lib/python/RestrictedPython/tests/before_and_after26.py, line 30 with whatever as x: ^ SyntaxError: invalid syntax Compiling /usr/lib/zope2.11/lib/python/RestrictedPython/tests/security_in_syntax26.py ... File /usr/lib/zope2.11/lib/python/RestrictedPython/tests/security_in_syntax26.py, line 6 with x as _leading_underscore: ^ SyntaxError: invalid syntax Compiling /usr/lib/zope2.11/lib/python/mechanize/_firefox3cookiejar.py ... File /usr/lib/zope2.11/lib/python/mechanize/_firefox3cookiejar.py, line 91 yield row SyntaxError: 'yield' not allowed in a 'try' block with a 'finally' clause greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: how to exclude python (test-)modules from byte-compilation with dh_pycentral
Hello, On 02/07/2009 Piotr Ożarowski wrote: [Jonas Meurer, 2009-07-02] At preparing zope2.11.3 packages, I found several python (test-)modules that do have python2.5/python2.6 code. This code is mostly for checking python2.5/python2.6 support, and thus isn't relevant for the functionality of zope itself. Zope2.11.3 still requires python2.4, so when the package is installed, python-central exits with a byte-compiling error, see below. Is there any possiblity to exclude/ignore the modules in question at byte-compilation time? I found -X for dh_pycentral, but that one doesn't seem to do what I expected it to do. if these tests are the only parts that require newer Python version (if not, simply bump XS-Python-Version or debian/pyversions) - while building the package you can loop over all requested Python versions and remove files that you don't want to be used with specific Python version - see python-beaker[1] package for an example. Your helper tool will detect this and do the right thing at install time. [...] PS consider switching to python-support or we'll force you to do this in few months ;-) thanks for the last suggestion. I finally noticed that python-support already supports to exclude python files from being byte-compiled. After all the following seems to do exactly what I want: dh_pysupport -pzope2.11 -V 2.4 -Xlib/python/RestrictedPython/tests -Xlib/python/mechanize/_firefox3cookiejar.py /usr/lib/zope2.11 greetings, jonas signature.asc Description: Digital signature
Re: how to check for binary compability?
Hey Jan,
thanks a lot for the detailed analysis :-)
On 26/05/2009 Jan C. Nordholz wrote:
[_ZN8DwStringixEj]
that symbol is defined in mimelib/mimelib/string.h as
] inline char DwString::operator [] (size_t aPos)
It is pulled in by mimelib/param.cpp because of
] void DwParameter::Parse()
] {
] [...]
] if (len 2 mValue[0] == '\'' mValue[len-1] == '\'') {
] [...]
(mValue is a DwString member of class DwParameter)
But g++ doesn't really inline inline header functions (sic):
[...]
Instead, it makes them weak global symbols:
] (LENNY)r...@apocatequil:/BUILD/kdepim-3.5.9/mimelib# nm -D
../obj-i486-linux-gnu/mimelib/.libs/libmimelib.so | grep ixEj
] 000299c0 W _ZN8DwStringixEj
However, this does not depend on the application of your patch. In fact, I get
this weak symbol with and without your 1.1.2 diff... What environment did you
compile your standalone libmimelib in (e.g. do you pass '-finline' to g++)?
You can find the current version of my packages at
http://people.debian.org/~mejo/mimelib1/. I built the packages in a
up-to-date amd64 debian/sid pbuilder environment. As you can see in the
build log at mimelib1_1.1.4-1_amd64.build, no -finline is passed to g++.
Regarding the original question: Anyone who would like to use that function
would have to include mimelib/string.h anyway, so dropping the symbol from
the library (however you managed to do that) should be safe.
great, so I don't need to bump the soname just because the private symbol
was removed.
so only one question remains for me: do I need to bump the soname or at
least provide a symbols file for added library symbols? or can I simply
ignore them as well?
the final diff of 'objdump -T /usr/lib/libmimelib.so.1 | grep \\.text |
cut -b62-' from 1.1.2_kde to my 1.1.4 packages is:
+_Z17delete_rep_safelyP11DwStringRep
+_Z17new_rep_referenceP11DwStringRep
+_Z8mem_copyPKcmPc
+_ZN13DwFieldParserD1Ev
+_ZN14DwEntityParserD1Ev
+_ZN8DwBinhexD0Ev
+_ZN8DwBinhexD1Ev
+_ZN8DwBinhexD2Ev
+_ZN8DwString2atEm
+_ZNK8DwString2atEm
-_ZN8DwStringixEm
-mkstemps
-strlcat
-strlcpy
as you can see, I have patched mimelib 1.1.2 further with some patches
from kde, but these only add new symbols and don't remove any.
greetings,
jonas
signature.asc
Description: Digital signature
Re: how to check for binary compability?
Hey, On 27/05/2009 Russ Allbery wrote: Jonas Meurer jo...@freesources.org writes: so only one question remains for me: do I need to bump the soname or at least provide a symbols file for added library symbols? or can I simply ignore them as well? You should not bump the SONAME. You should bump the shlibs dependency (as generated by dh_makeshlibs if you're using debhelper) to the new version of the package, though, since binaries built against the new library might not work with the old library. You could also provide a symbols file with appropriate version numbers for when each symbol was introduced, but symbols files are optional (and can be tricky with C++ since the symbol names can vary per architecture). great, thanks a lot for your excellent help. i just uploaded mimelib1 1.1.4-1 to debian/unstable. greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: how to check for binary compability?
Hey,
First thanks for your very valuable answers, they helped me a lot.
On 25/05/2009 Russ Allbery wrote:
Jonas Meurer jo...@freesources.org writes:
At packaging mimelib1 from standalone-source I patched the sources to
use strncpy/strncat instead of strlcpy/strlcpy along with several
other changes.
Now I tried to check for binary compability with libmimelib1c2a packages
from kdepim 3.5.9 sources. To do that, I compared the output of
'objdump -T /usr/lib/libmimelib.so.1 | grep \\.text | cut -b62-'
Unfortunately there are differences. Now I simply don't know if these
differences render the package binary incompatible, or whether they
don't matter at all.
Additions do not break binary compatibility in shared libraries, so the
only concern is with the removals:
does this mean that symbol additions can be simply ignored? or is
something like a symbols file required?
-strlcpy
-mkstemps
-strlcat
these ones clearly come from kdelibs-3.5.10.dfsg.1/kdecore/fakes.c, which
was included in mimelib 1.1.2 from kdepim-3.5.9 in order to provide
strlcat and strlcpy.
-_ZN8DwStringixEm
i don't understand that one at all. I cannot find anything with the
string 'ZN8DwStringixEm' in either kdepim or kdelibs sources.
The new version of the library is no longer exporting its internal
portability functions. This is good -- libraries should not export
unrelated symbols. However, if any of its dependencies happened to
depend on those internal symbols (using the versions provided by the
library lazily rather than providing their own), you would break them.
lurker is the only package that depends on mimelib1 in debian, and that
one clearly doesn't use private symbols from mimelib1. We cannot know
about custom software though.
I don't have a good feel for how likely that is for this particular
library. In general, removal of internal symbols that were never part
of the public API is often done without a bump in the SONAME and just
fixing any dependent packages that break, but ideally it's nice to know
what might break. Debian Developers with access to the Lintian lab on
gluck can search through the objdump output for clues, although we don't
have a simple script to do that. I'm not sure what to recommend to
people who don't have access to a fully populated Lintian lab.
More concerning is the last symbol removal, which indicates that the
library has removed:
DwString::operator[](unsigned long)
which was present in the previous version. Is this also an internal
symbol or was it part of the published API?
to be honest, I don't know. at least it is not been used in lurker. I
don't even understand which change caused the symbol to disappear.
DwString::operator is defined in mimelib/mimelib/string.h, and no change
was made to that header file at all.
I attached the diff from kdepim-3.5.9/mimelib sources to mimelib 1.1.2
standalone sources (without documentation changes).
greetings,
jonas
diff -rNu ../other/kdepim3/kdepim-3.5.9/mimelib/Makefile.am mimelib1-1.1.2/mimelib/Makefile.am
--- ../other/kdepim3/kdepim-3.5.9/mimelib/Makefile.am 2005-09-10 10:24:49.0 +0200
+++ mimelib1-1.1.2/mimelib/Makefile.am 2009-04-27 17:11:08.0 +0200
@@ -57,7 +57,7 @@
uuencode.cpp \
binhex.cpp
-libmimelib_la_LDFLAGS = -L$(kde_libraries) -lkdefakes -version-info 1:1 -no-undefined
+libmimelib_la_LDFLAGS = -version-info 1:1
check_PROGRAMS = test_boyermor
diff -rNu ../other/kdepim3/kdepim-3.5.9/mimelib/mimelib/config.h mimelib1-1.1.2/mimelib/mimelib/config.h
--- ../other/kdepim3/kdepim-3.5.9/mimelib/mimelib/config.h 2007-05-14 09:54:54.0 +0200
+++ mimelib1-1.1.2/mimelib/mimelib/config.h 2009-04-27 18:04:46.0 +0200
@@ -123,8 +123,7 @@
# define DW_EXPORT __declspec(dllimport)
# endif
#else
-# include kdepimmacros.h
-# define DW_EXPORT KDE_EXPORT
+# define DW_EXPORT
#endif
//-
diff -rNu ../other/kdepim3/kdepim-3.5.9/mimelib/nntp.cpp mimelib1-1.1.2/mimelib/nntp.cpp
--- ../other/kdepim3/kdepim-3.5.9/mimelib/nntp.cpp 2007-05-14 09:54:54.0 +0200
+++ mimelib1-1.1.2/mimelib/nntp.cpp 2009-04-27 18:17:31.0 +0200
@@ -113,7 +113,7 @@
snprintf(mSendBuffer, SEND_BUFFER_SIZE, ARTICLE %d\r\n, aArticleNum);
}
else {
-strlcpy(mSendBuffer, ARTICLE\r\n, SEND_BUFFER_SIZE);
+strcpy(mSendBuffer, ARTICLE\r\n);
}
DBG_NNTP_STMT(cout C: mSendBuffer flush;)
int bufferLen = strlen(mSendBuffer);
@@ -137,9 +137,9 @@
// error!
return mReplyCode;
}
-strlcpy(mSendBuffer, ARTICLE , SEND_BUFFER_SIZE);
-strlcat(mSendBuffer, aMsgId, SEND_BUFFER_SIZE);
-strlcat(mSendBuffer, \r\n, SEND_BUFFER_SIZE);
+strcpy(mSendBuffer, ARTICLE );
+strncat(mSendBuffer, aMsgId, 80);
+strcat(mSendBuffer, \r\n);
DBG_NNTP_STMT(cout C: mSendBuffer flush;)
int bufferLen
Re: how to check for binary compability?
Hello,
On 26/05/2009 Boyd Stephen Smith Jr. wrote:
In 20090526113058.ga5...@resivo.wgnet.de, Jonas Meurer wrote:
On 25/05/2009 Russ Allbery wrote:
More concerning is the last symbol removal, which indicates that the
library has removed:
DwString::operator[](unsigned long)
DwString::operator is defined in mimelib/mimelib/string.h, and no change
was made to that header file at all.
'DwString::operator' isn't defined anywhere. operator is a C++ keyword
used
for operator overloading. It is always followed by some operator punctuation
(e.g.: +, -, [], (), =) to indicate which operator is being overloaded. The
function in question is 'DwString::operator[]' specifically the overload that
takes an 'unsigned long' as an argument (and based on the rules of operator
overloading, has to be a member function of DwString.)
You diff doesn't show this change, so I'm not exactly sure why the function
is
no longer exported (or present).
maybe this symbol is connected with the include of kdepimmacros.h? at
least that's the only change from 1.1.2_kde to stanalone 1.1.2 appart
from strl{cpy,cat} - strnc{cpy,cat}.
greetings,
jonas
signature.asc
Description: Digital signature
how to check for binary compability?
Hello again, This is the third time I'm writing to debian-mentors. I don't know why nobody replied to my former mails, but maybe I didn't describe the problem good enough, or the answers to my questions where to obvious. At packaging mimelib1 from standalone-source I patched the sources to use strncpy/strncat instead of strlcpy/strlcpy along with several other changes. Now I tried to check for binary compability with libmimelib1c2a packages from kdepim 3.5.9 sources. To do that, I compared the output of 'objdump -T /usr/lib/libmimelib.so.1 | grep \\.text | cut -b62-' Unfortunately there are differences. Now I simply don't know if these differences render the package binary incompatible, or whether they don't matter at all. The patches against mimelib sources don't change any struct or functions to my knowledge. Now what to do about it? should I simply bump the soname and binary package names (from 1 to 2) and request binNMUs for reverse depends? Or is there a way to keep ABI compability with the help of something like a symbols file? I attached the diff for output of objdump -T. diff is between the libmimelib1c2a package from kdepim 3.5.9 sources (debian/lenny), and my own standalone source package with no source changes other than strlcat/strlcpy - strncat/strncpy. greetings, jonas --- objdump_sid_libmimelib1c2a_1.1.2_kde2009-04-27 16:44:22.0 +0200 +++ objdump_sid_libmimelib1c2a_1.1.22009-04-28 15:00:15.0 +0200 @@ -68,7 +68,6 @@ _ZN7DwGroup5ParseEv _ZNK11DwPopClient17MultiLineResponseEv _ZN9DwHeaders18ContentDescriptionEv -strlcpy _ZN10DwBodyPartC2ERK8DwEntity _ZN10DwDateTime4InitEv _ZN13DwFieldParserC2ERK8DwString @@ -152,7 +151,6 @@ _ZN12DwNntpClient7ArticleEi _ZN9DwHeaders8AssembleEv _ZN10DwBodyPartaSERKS_ -mkstemps _ZNK11DwMechanism15_PrintDebugInfoERSo _ZN10DwUuencode11SetFileModeEt _ZNK7DwMsgId6DomainEv @@ -222,6 +220,7 @@ _ZNK8DwString4findEPKcm _ZN13DwMailboxList8CopyListEPK9DwMailbox _ZNK8DwString17find_first_not_ofEPKcmm +_ZN13DwFieldParserD1Ev _ZgtRK8DwStringS1_ _ZltPKcRK8DwString _ZN17DwDispositionType19DeleteParameterListEv @@ -230,6 +229,7 @@ _ZN13DwAddressListC2ERKS_ _ZN8DwStringD1Ev _ZplcRK8DwString +_Z17new_rep_referenceP11DwStringRep _ZN12DwBoyerMooreC2ERK8DwString _ZN9DwMessageaSERKS_ _ZN6DwBody5ParseEv @@ -296,6 +296,7 @@ _ZN17DwRfc822TokenizerppEv _ZNK7DwGroup11MailboxListEv _ZNK9DwMailbox15CheckInvariantsEv +_ZNK8DwString2atEm _ZN7DwGroupC1Ev _ZN6DwBodyC1ERK8DwStringP18DwMessageComponent _ZN8DwStringD2Ev @@ -398,6 +399,7 @@ _ZN11DwMediaTypeC1ERKS_ _ZNK17DwDispositionType5CloneEv _ZltRK8DwStringPKc +_Z17delete_rep_safelyP11DwStringRep _Z10DwFinalizev _ZNK11DwParameter5CloneEv _ZN8DwString10TakeBufferEPcmmm @@ -550,7 +552,6 @@ _ZN7DwField15SetFieldNameStrERK8DwString _ZNK8DwString8max_sizeEv _ZN10DwBodyPartC2ERKS_ -strlcat _ZN15DwHeadersParser9NextFieldEP8DwString _ZN9DwMailboxD1Ev _ZNK8DwString12find_last_ofEPKcm @@ -606,6 +607,7 @@ _ZN9DwMailboxD2Ev _ZN11DwMechanism12EnumToStringEv _ZN8DwString7replaceEmmRKS_ +_ZN14DwEntityParserD1Ev _ZNK9DwHeaders10HasControlEv _ZN8DwString6resizeEmc _ZN8DwString6appendERKS_ @@ -722,9 +724,11 @@ _ZNK10DwDateTime15CheckInvariantsEv _ZN12DwNntpClient8PGetLineEPPcPi _ZN6DwTextD2Ev +_Z8mem_copyPKcmPc _ZN12DwNntpClient7ArticleEPKc _ZN11DwPopClient22PGetSingleLineResponseEv _ZNK9DwHeaders15HasDistributionEv +_ZN8DwString2atEm _ZN9DwMailboxC2Ev _ZN11DwMediaType10SetTypeStrERK8DwString _ZN18DwMessageComponentC2Ev @@ -872,7 +876,6 @@ _ZNK9DwMailbox8FullNameEv _ZNK9DwHeaders12HasInReplyToEv _Z9DwToCrEolRK8DwStringRS_ -_ZN8DwStringixEm _ZN7DwMsgIdC1Ev _ZN12DwNntpClientC2Ev _ZNK8DwEntity4BodyEv -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
mimelib1: need help with library symbols, soname, etc.
Hello again, I'm still in the process of preparing mimelib1 packages for debian unstable. Now I realized that the packages which I prepare do have slightly different symbols than the old libmimelib1c2a package from kdepim/3.5.9-1. I tracked down the changes to some changes/patches I applied to the library sources, but I don't know what to do about it. First, I don't know much about the whole topic library, symbols, shlibs, soname etc. I compared the output of 'objdump -T /usr/lib/libmimelib.so.1 | grep \\.text | cut -b62-' for libmimelib1c2a from debian/testing (built from kdepim/3.5.9-1) and the packages that I prepared. The first change I made to the sources is replacing strlcat/strlcpy with strncat/strncpy. That change already produced a diff to the output of objdump, see below. Now what to do about it? should I simply bump the soname and binary package names (from 1 to 2), request binNMUs for packages that do depend on libmimelib1c2a and and forget about the whole issue? Or is there a way to keep ABI compability with the help of a symbols file? greetings, jonas --- objdump_sid_libmimelib1c2a_1.1.2_kde2009-04-27 16:44:22.0 +0200 +++ objdump_sid_libmimelib1c2a_1.1.22009-04-28 15:00:15.0 +0200 @@ -68,7 +68,6 @@ _ZN7DwGroup5ParseEv _ZNK11DwPopClient17MultiLineResponseEv _ZN9DwHeaders18ContentDescriptionEv -strlcpy _ZN10DwBodyPartC2ERK8DwEntity _ZN10DwDateTime4InitEv _ZN13DwFieldParserC2ERK8DwString @@ -152,7 +151,6 @@ _ZN12DwNntpClient7ArticleEi _ZN9DwHeaders8AssembleEv _ZN10DwBodyPartaSERKS_ -mkstemps _ZNK11DwMechanism15_PrintDebugInfoERSo _ZN10DwUuencode11SetFileModeEt _ZNK7DwMsgId6DomainEv @@ -222,6 +220,7 @@ _ZNK8DwString4findEPKcm _ZN13DwMailboxList8CopyListEPK9DwMailbox _ZNK8DwString17find_first_not_ofEPKcmm +_ZN13DwFieldParserD1Ev _ZgtRK8DwStringS1_ _ZltPKcRK8DwString _ZN17DwDispositionType19DeleteParameterListEv @@ -230,6 +229,7 @@ _ZN13DwAddressListC2ERKS_ _ZN8DwStringD1Ev _ZplcRK8DwString +_Z17new_rep_referenceP11DwStringRep _ZN12DwBoyerMooreC2ERK8DwString _ZN9DwMessageaSERKS_ _ZN6DwBody5ParseEv @@ -296,6 +296,7 @@ _ZN17DwRfc822TokenizerppEv _ZNK7DwGroup11MailboxListEv _ZNK9DwMailbox15CheckInvariantsEv +_ZNK8DwString2atEm _ZN7DwGroupC1Ev _ZN6DwBodyC1ERK8DwStringP18DwMessageComponent _ZN8DwStringD2Ev @@ -398,6 +399,7 @@ _ZN11DwMediaTypeC1ERKS_ _ZNK17DwDispositionType5CloneEv _ZltRK8DwStringPKc +_Z17delete_rep_safelyP11DwStringRep _Z10DwFinalizev _ZNK11DwParameter5CloneEv _ZN8DwString10TakeBufferEPcmmm @@ -550,7 +552,6 @@ _ZN7DwField15SetFieldNameStrERK8DwString _ZNK8DwString8max_sizeEv _ZN10DwBodyPartC2ERKS_ -strlcat _ZN15DwHeadersParser9NextFieldEP8DwString _ZN9DwMailboxD1Ev _ZNK8DwString12find_last_ofEPKcm @@ -606,6 +607,7 @@ _ZN9DwMailboxD2Ev _ZN11DwMechanism12EnumToStringEv _ZN8DwString7replaceEmmRKS_ +_ZN14DwEntityParserD1Ev _ZNK9DwHeaders10HasControlEv _ZN8DwString6resizeEmc _ZN8DwString6appendERKS_ @@ -722,9 +724,11 @@ _ZNK10DwDateTime15CheckInvariantsEv _ZN12DwNntpClient8PGetLineEPPcPi _ZN6DwTextD2Ev +_Z8mem_copyPKcmPc _ZN12DwNntpClient7ArticleEPKc _ZN11DwPopClient22PGetSingleLineResponseEv _ZNK9DwHeaders15HasDistributionEv +_ZN8DwString2atEm _ZN9DwMailboxC2Ev _ZN11DwMediaType10SetTypeStrERK8DwString _ZN18DwMessageComponentC2Ev @@ -872,7 +876,6 @@ _ZNK9DwMailbox8FullNameEv _ZNK9DwHeaders12HasInReplyToEv _Z9DwToCrEolRK8DwStringRS_ -_ZN8DwStringixEm _ZN7DwMsgIdC1Ev _ZN12DwNntpClientC2Ev _ZNK8DwEntity4BodyEv -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
mimelib1 once again: library symbols, shlibs and soname
Hello again, I'm still in the process of preparing mimelib1 packages for debian unstable. Now I realized that the packages which I prepare do have slightly different symbols than the old libmimelib1c2a package from kdepim/3.5.9-1. I tracked down the changes to some changes/patches I applied to the library sources, but I don't know what to do about it. First, I don't know much about the whole topic library, symbols, shlibs, soname etc. I compared the output of 'objdump -T /usr/lib/libmimelib.so.1 | grep \\.text | cut -b62-' for libmimelib1c2a from debian/testing (built from kdepim/3.5.9-1) and the packages that I prepared. The first change I made to the sources is replacing strlcat/strlcpy with strncat/strncpy. That change already produced a diff to the output of objdump, see below. Now what to do about it? should I simply bump the soname and binary package names (from 1 to 2), request binNMUs for packages that do depend on libmimelib1c2a and and forget about the whole issue? Or is there a way to keep ABI compability with the help of a symbols file? greetings, jonas --- objdump_sid_libmimelib1c2a_1.1.2_kde2009-04-27 16:44:22.0 +0200 +++ objdump_sid_libmimelib1c2a_1.1.22009-04-28 15:00:15.0 +0200 @@ -68,7 +68,6 @@ _ZN7DwGroup5ParseEv _ZNK11DwPopClient17MultiLineResponseEv _ZN9DwHeaders18ContentDescriptionEv -strlcpy _ZN10DwBodyPartC2ERK8DwEntity _ZN10DwDateTime4InitEv _ZN13DwFieldParserC2ERK8DwString @@ -152,7 +151,6 @@ _ZN12DwNntpClient7ArticleEi _ZN9DwHeaders8AssembleEv _ZN10DwBodyPartaSERKS_ -mkstemps _ZNK11DwMechanism15_PrintDebugInfoERSo _ZN10DwUuencode11SetFileModeEt _ZNK7DwMsgId6DomainEv @@ -222,6 +220,7 @@ _ZNK8DwString4findEPKcm _ZN13DwMailboxList8CopyListEPK9DwMailbox _ZNK8DwString17find_first_not_ofEPKcmm +_ZN13DwFieldParserD1Ev _ZgtRK8DwStringS1_ _ZltPKcRK8DwString _ZN17DwDispositionType19DeleteParameterListEv @@ -230,6 +229,7 @@ _ZN13DwAddressListC2ERKS_ _ZN8DwStringD1Ev _ZplcRK8DwString +_Z17new_rep_referenceP11DwStringRep _ZN12DwBoyerMooreC2ERK8DwString _ZN9DwMessageaSERKS_ _ZN6DwBody5ParseEv @@ -296,6 +296,7 @@ _ZN17DwRfc822TokenizerppEv _ZNK7DwGroup11MailboxListEv _ZNK9DwMailbox15CheckInvariantsEv +_ZNK8DwString2atEm _ZN7DwGroupC1Ev _ZN6DwBodyC1ERK8DwStringP18DwMessageComponent _ZN8DwStringD2Ev @@ -398,6 +399,7 @@ _ZN11DwMediaTypeC1ERKS_ _ZNK17DwDispositionType5CloneEv _ZltRK8DwStringPKc +_Z17delete_rep_safelyP11DwStringRep _Z10DwFinalizev _ZNK11DwParameter5CloneEv _ZN8DwString10TakeBufferEPcmmm @@ -550,7 +552,6 @@ _ZN7DwField15SetFieldNameStrERK8DwString _ZNK8DwString8max_sizeEv _ZN10DwBodyPartC2ERKS_ -strlcat _ZN15DwHeadersParser9NextFieldEP8DwString _ZN9DwMailboxD1Ev _ZNK8DwString12find_last_ofEPKcm @@ -606,6 +607,7 @@ _ZN9DwMailboxD2Ev _ZN11DwMechanism12EnumToStringEv _ZN8DwString7replaceEmmRKS_ +_ZN14DwEntityParserD1Ev _ZNK9DwHeaders10HasControlEv _ZN8DwString6resizeEmc _ZN8DwString6appendERKS_ @@ -722,9 +724,11 @@ _ZNK10DwDateTime15CheckInvariantsEv _ZN12DwNntpClient8PGetLineEPPcPi _ZN6DwTextD2Ev +_Z8mem_copyPKcmPc _ZN12DwNntpClient7ArticleEPKc _ZN11DwPopClient22PGetSingleLineResponseEv _ZNK9DwHeaders15HasDistributionEv +_ZN8DwString2atEm _ZN9DwMailboxC2Ev _ZN11DwMediaType10SetTypeStrERK8DwString _ZN18DwMessageComponentC2Ev @@ -872,7 +876,6 @@ _ZNK9DwMailbox8FullNameEv _ZNK9DwHeaders12HasInReplyToEv _Z9DwToCrEolRK8DwStringRS_ -_ZN8DwStringixEm _ZN7DwMsgIdC1Ev _ZN12DwNntpClientC2Ev _ZNK8DwEntity4BodyEv -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: questions regarding libmimelib1 as seperate source package
On 25/04/2009 Sven Joachim wrote: On 2009-04-25 09:26 +0200, Boyd Stephen Smith Jr. wrote: In 20090425001917.gb6...@resivo.wgnet.de, Jonas Meurer wrote: Ok, I see your point. I'll change the package to be non-native again. But how about all the links to upstream places that lintian expects? like the Homepage field in debian/control, the watch file etc ... *shrug* They could point to specific part of the Debian infrastructure used for maintaining the project. Perhaps a project etc. on http://alioth.debian.org/? I think that's only useful if the library itself is maintained there. I don't see a reason to maintain mimelib1 on alioth yet. Thus I set the Homepage field to http://websvn.kde.org/trunk/KDE/kdepim/mimelib/ I'm not sure what the policy is, but lintian overrides might also be appropriate. There is no need for that, adding a watch file containing only a comment about the situation is enough. Great, that's what I did now. Thanks for the advice. greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to build-depend on linux-headers
Hey, On 27/04/2009 Luca Niccoli wrote: in a package I'm preparing I need to build depend on linux headers, but if I just put linux-headers in debian/control lintian shrieks virtual-package-depends-without-real-package-depends The problem is that AFAICS all the real packages in question are either version-specific (linux-headers-2.6.29-1-all) or architecture specific (linux-headers-2.6-amd64). What should I do? Depend on all possible architecture specific packages, ORred after linux-headers? Or on just one of them, and when the buildd won't be able to satisfy the dependency it will pick a suitable version? But in this case, why bother putting a real package dependency if it can't be satisfied on most architectures? I'm not absolutely sure about it, but linux-libc-dev might be the answer to your questions. greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
questions regarding libmimelib1 as seperate source package
Hello, I intend to maintain libmimelib1 as a seperate source package now that kdepim 3.5.9 has been removed from debian/unstable. I finally do have a working package, but before I upload it to debian/unstable, I'd like somebody else to take a look at it. In particular, I'm unsure about the following issues: - I packaged mimelib as a native debian package as no real upstream package does exist any more. Several different tarballs, all different from each other, are available from the web, but the only one that is (more or less) actively maintained is the one in kdepim. Is it appropriative to package libmimelib1 as native debian package? - lintian complains about a missing symbols file. I don't know whether a symobls file is really necessary for the library. In fact, I don't know much about symbols, so maybe someone can give me advice here. - I bumbed the library version to 1.1.4 and kept soname libmimelib.so.1 from the libmimelib1c2a package. The source changes I made where simple strlcpy() - strncpy() migration, so a soname bump should not be necessary. - The library package's name is 'libmimelib1', and it has Replaces, Conflicts and Provides headers for libmimelib1c2a. I also build a libmimelib1c2a dummy transitional package that depends on libmimelib1. - I created the toplevel Makefile.am and configure.in on my own, and in fact this is the first time I have to code autotools stuff on my own. So I would highly appreciate comments about these and the configure target in debian/rules :-) You can find the packages at http://people.debian.org/~mejo/mimelib/ greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: questions regarding libmimelib1 as seperate source package
On 24/04/2009 Russ Allbery wrote: Jonas Meurer jo...@freesources.org writes: - I bumbed the library version to 1.1.4 and kept soname libmimelib.so.1 from the libmimelib1c2a package. The source changes I made where simple strlcpy() - strncpy() migration, so a soname bump should not be necessary. Just to double-check, you added explicit nul termination for all strings as an additional line of code when making that change, correct? (I personally prefer to ship a replacement strlcpy function rather than using strncpy, since the strncpy semantics are rather broken.) Yes, exactly. I already had considered to use the strlcpy/strlcat functions from kdelibs/kdecore/fakes.c, but then in a conversation with ron on #debian-devel regarding that issue he advised me to use standard functions instead. It seems like people tend be enthusiastic about either of the solutions. Unfortunately ron discovered a far worse issue. The way str[ln]cat() is used in mimelib makes it very error-prone to buffer overflows: #define SEND_BUFFER_SIZE 1024 ... mSendBuffer = new char[SEND_BUFFER_SIZE]; ... strlcpy(mSendBuffer, PASS , SEND_BUFFER_SIZE); strlcat(mSendBuffer, aPasswd, SEND_BUFFER_SIZE); strlcat(mSendBuffer, \r\n, SEND_BUFFER_SIZE); this without any santising code for aPasswd causes mSendBuffer to be overflowable for at least strlen(PASS ) + strlen(\r\n). ron suggested to migrate the code to c++ std::string, but I fear that I don't have the skills to do that in a safe and secure manner. greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: questions regarding libmimelib1 as seperate source package
On 24/04/2009 Russ Allbery wrote: Jonas Meurer jo...@freesources.org writes: Unfortunately ron discovered a far worse issue. The way str[ln]cat() is used in mimelib makes it very error-prone to buffer overflows: #define SEND_BUFFER_SIZE 1024 ... mSendBuffer = new char[SEND_BUFFER_SIZE]; ... strlcpy(mSendBuffer, PASS , SEND_BUFFER_SIZE); strlcat(mSendBuffer, aPasswd, SEND_BUFFER_SIZE); strlcat(mSendBuffer, \r\n, SEND_BUFFER_SIZE); this without any santising code for aPasswd causes mSendBuffer to be overflowable for at least strlen(PASS ) + strlen(\r\n). That code is safe from a buffer overflow perspective using strlcpy and strlcat, but may not end the buffer with \r\n. Indeed, you're correct. I didn't realize that up to now. strlcat here is very different to strncat. strlcat uses something like SEND_BUFFER_SIZE - strlen(mSendBuffer) as limit, while strncat uses SEND_BUFFER_SIZE all the time, and that way is error-prone to buffer-overflows. That indeed is a good reason to revert all my changes from strlcpy/strlcat to strncpy/strncat and instead use the strlcpy/strlcat defines from kdecore/fakes.c. But in that case I've a simple question: if I put both defines into a seperate c source file strl___.c, how do I teach the autotools to use this file when compiling nntp.cpp, pop.cpp and uuencode.cpp? greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: questions regarding libmimelib1 as seperate source package
On 24/04/2009 Boyd Stephen Smith Jr. wrote: In 20090424190226.gb6...@resivo.wgnet.de, Jonas Meurer wrote: - I packaged mimelib as a native debian package as no real upstream package does exist any more. That's not a good enough reason. Could the sources be useful in a non- Debian-derived distribution such as openSUSE, CentOS, Slax, or Arch? If so, Debian can be upstream but still produce non-native packages. Packages should be non-native unless they are fairly Debian-specific. Ok, I see your point. I'll change the package to be non-native again. But how about all the links to upstream places that lintian expects? like the Homepage field in debian/control, the watch file etc ... Shall I simply add lintian overrides for these, or is there a better way to teach lintian that upstream doesn't exist? greetings, jonas signature.asc Description: Digital signature
Re: questions regarding libmimelib1 as seperate source package
On 24/04/2009 Russ Allbery wrote: Jonas Meurer jo...@freesources.org writes: But in that case I've a simple question: if I put both defines into a seperate c source file strl___.c, how do I teach the autotools to use this file when compiling nntp.cpp, pop.cpp and uuencode.cpp? AC_REPLACE_FUNCS([strlcpy strlcat]) in configure.ac and then include LTLIBOBJS in the list of objects that go into the shared library in your Makefile.am. Ok, thanks for the pointers. But I just saw that one of the countless mimelib tarballs that you find in the web already uses strncat in a secure manner. It santizes the size given to strncat properly to make buffer overflows impossible. Thus I decided to go that way. Thanks a lot anyway for your help. I updated the package sources at http://people.debian.org/~mejo/mimelib/ greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: questions regarding libmimelib1 as seperate source package
On 25/04/2009 Paul Wise wrote: On Sat, Apr 25, 2009 at 3:02 AM, Jonas Meurer jo...@freesources.org wrote: I intend to maintain libmimelib1 as a seperate source package now that kdepim 3.5.9 has been removed from debian/unstable. What does lurker link against on other distros that have moved to KDE4? I don't know, but a quick check gives: ubuntu intrepid: still has lurker 2.1-10, unresolvable depends redhat/fedora: cannot find lurker in their package databases at all gentoo: ebuild uses a local copy of a mimelib tarball I cannot find information about lurker in other distros. at least opensuse does have lurker for sure, but I'm unfamilar with their package information pages, so I didn't find relevant information. greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
mimelib 1.1.2 packages: strlcpy/strlcat vs. strcpy/strcat
Hello, I plan to package libmimelib 1.1.2 for debian/unstable. Until now this has been built/provided by kdepim from kde3, but as part of the kde4 transition kdepim3 has been removed from debian/unstable. Still lurker depends on libmimelib1c2a, and migrating to libmimelib4 is not an option as it would introduce tons of kdelibs dependencies that lurker doesn't need at all. So I copied kdepim-3.5.9/mimelib/ from the kdepim 3.5.9-5 source package in order to build a standalone source package from it. Now I've one problem: kde developers have patched mimelib heavily since it has been added to kdepim, and one of the changes is to use strlcpy/strlcat at some places. Unfortunately, strlcpy/strlcat seems not to be available on a standard linux system. Only stncpy/strncat and strcpy/strcat are. The original standalone mimelib used strcpy/strcat, but mimelib is in fact unmaintained upstream since 1997, so there is no real upstream version available. Instead I found more than five different patched versions of mimelib in the web, all of them differing a lot. I would like to package the kdepim 3.5.9 version of mimelib. So what to do? As far as I understand, there are three possibilities: - patch mimelib from kdepim to use strcpy/strcat again, but I guess this is not a good idea as strcpy/strcat seem to be insecure. - patch mimelib from kdepim to use strncpy/strncat instead of strlcpy/strlcat. - define strlcpy/strlcat in a custom header file and include that one where appropriate. I don't know enough about this topic to make a decision on my own. Thus I ask you for advice. greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
change group password in batch mode
hello, for lurker i need to set the lurker system group password in postinst. unfortunately there seems to be no way for changing group passwords in batch mode. for system user passwords 'chpasswd' exists, but i cannot find an equivalent for system group passwords. would it be generally useful? if yes, i could try to create a patch for the shadow package to ship a 'chgpasswd' binary. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timeout function in cryptsetup init script
On 30/01/2006 Jan C. Nordholz wrote: Hi, indeed, it sounds exactly like what i'm searching for. but unfortunately it looks like cryptsetup does not have support for reading the password from stdin or command-line. ah, I see, it is using getpass(3) if no keyfile has been specified. Hmm, after having a glance at the source code, the easiest thing seems to patch the source to accept a new command-line option to specify a different input fd. The rest of the code (lib/setup.c:get_key(), most importantly) should work without a change. maybe then the best would be to add support for a --timeout option, instead of supporting another (insecure) input fd. Shall I try to wrap something up? if you like, that would be great. i've not much experiences with coding c(++). ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: files for an initscript that is run before mountall.sh
On 29/01/2006 Henrique de Moraes Holschuh wrote:
On Mon, 30 Jan 2006, Jonas Meurer wrote:
now my question is, where should i place the check scripts instead?
is /lib/cryptsetup/{pre,post}check correct?
Yes.
thanks.
...
jonas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
timeout function in cryptsetup init script
hello, i'dd like to implement a timeout function into cryptdisks, an init script for cryptsetup. cryptsetup is run for every entry in /etc/crypttab. It unlocks a encrypted partition with either a keyfile or a passphrase. the passphrase prompt should have a timeout, as otherwise boot of headless machines would hang forever. i've already implemented a simple solution with /usr/bin/timeout from the timeout package, but it requires the timeout package to be installed, and the binary is in /usr/bin. cryptsetup is run before local filesystems are mounted, thus both /usr and /var may not be available. so what i really need, is a POSIX shell timeout function, that kills cryptsetup after X seconds if cryptsetup is not already finished. it mustn't depend on any binary in /usr, and it needs to allow interactive password typing. i've absolutely no idea about how to implement that, thus i mailed to this list. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
files for an initscript that is run before mountall.sh
hello,
cryptdisks, the initscript for cryptsetup, runs some checks over the
dm-crypt device after creating it (for example it can check for a
filesystem).
currenctly the check scripts are stored in
/usr/share/cryptsetup/prechecks and postchecks, but unfortunately /usr
is often a seperate local filesystem, and cryptdisks is run before
mountall.sh. Thus the checks on systems with a /usr filesystem cannot
be run at boot time.
now my question is, where should i place the check scripts instead?
is /lib/cryptsetup/{pre,post}check correct?
...
jonas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf problem
On 17/05/2003 Joey Hess wrote: $3 is empty, the previous version is in $2 Oh, thanks a lot ;) bye mejo -- Efficiency and progess is ours one more Now that we have the Neutron bomb It's nice and quick and clean and gets things done Kill kill kill kill kill the poor tonight
debconf problem
Hello, I've some problems with my package lurker. You can find the source of my actuall packaging version at http://people.freesources.org/~jonas/lurker/ My problems: The database format from lurker 0.6 to lurker 0.7 changed, but upstream provides a convert-script. I want to inform people if they upgrade from 0.6 to 0.7 (there is also an older entry for upgrades from 0.1* to 0.6). I have in debian/lurker.config: [...] while [ $STATE != 0 -a $STATE != 4 ]; do case $STATE in [...] 3) case $1 in configure) if dpkg --compare-versions $3 = 0.1g then db_input high lurker/upgrade01_info || true elif dpkg --compare-versions $3 = 0.5 then db_input high lurker/upgrade06_info || true fi ;; esac ;; esac but it doesn't show the upgrade message if I upgrade from 0.6 to 0.7. does someone have an idea? bye mejo -- Efficiency and progess is ours one more Now that we have the Neutron bomb It's nice and quick and clean and gets things done Kill kill kill kill kill the poor tonight
Re: debconf problem
On 16/05/2003 Joe Nahmias wrote: if dpkg --compare-versions $3 = 0.1g then db_input high lurker/upgrade01_info || true db_go elif dpkg --compare-versions $3 = 0.5 then db_input high lurker/upgrade06_info || true db_go [...] You need to call db_go after all the db_input's to tell debconf to ask the questions. I have at the end of the config script: if db_go; then STATE=$(($STATE + 1)) else STATE=$(($STATE - 1)) fi that should do the relating stuff, am I right? so, that cannot be the problem. But I get the feeling that $3 is the problem. bye mejo -- Efficiency and progess is ours one more Now that we have the Neutron bomb It's nice and quick and clean and gets things done Kill kill kill kill kill the poor tonight
Re: sponsor for btn4ws gimp-perl plug-in needed
On 22/02/2003 Jan Dittberner wrote: I packaged my gimp-perl plugin btn4ws.pl and need a sponsor to include it in the debian distribution. The package is available at http://www.dittberner.info/file/btn4ws_0.6-1_all.deb Normally a sponsor doesn't need the .deb. He needs .orig.tar.gz, .diff.gz and .dsc. You should _never_ only provide a .deb. According to the debian free software guidelines, you have to provide always the sources. And the sources are .orig.tar.gz (which should be the original source package), .diff.gz and .dsc (both are created at dpkg-buildpackage). bye mejo -- Efficiency and progess is ours one more Now that we have the Neutron bomb It's nice and quick and clean and gets things done Kill kill kill kill kill the poor tonight -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sponsor for btn4ws gimp-perl plug-in needed
On 22/02/2003 Jan Dittberner wrote: I packaged my gimp-perl plugin btn4ws.pl and need a sponsor to include it in the debian distribution. The package is available at http://www.dittberner.info/file/btn4ws_0.6-1_all.deb Normally a sponsor doesn't need the .deb. He needs .orig.tar.gz, .diff.gz and .dsc. You should _never_ only provide a .deb. According to the debian free software guidelines, you have to provide always the sources. And the sources are .orig.tar.gz (which should be the original source package), .diff.gz and .dsc (both are created at dpkg-buildpackage). bye mejo -- Efficiency and progess is ours one more Now that we have the Neutron bomb It's nice and quick and clean and gets things done Kill kill kill kill kill the poor tonight
how long does it take to find an AM
Hello, I started my NM-process at the 5. July 2002, and it was checked by my advocate at the 10. July 2002. Now 25 days (more than 3 weeks) passed, and still no AM contacted me. I know that the NM-team has a hard job, but I just want to ask how long you have to wait normally at the moment. My advocate had to wait about 1 week, but this is a few years ago, I think. What about idle-time now? bye mejo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
how long does it take to find an AM
Hello, I started my NM-process at the 5. July 2002, and it was checked by my advocate at the 10. July 2002. Now 25 days (more than 3 weeks) passed, and still no AM contacted me. I know that the NM-team has a hard job, but I just want to ask how long you have to wait normally at the moment. My advocate had to wait about 1 week, but this is a few years ago, I think. What about idle-time now? bye mejo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: advocate for gween
On Mon, May 20, 2002 at 10:23:22PM +0200, Jonas Meurer wrote: I have build a debian-package of gween (gween.freesources.org). Would anyone be advocate for me? I don't have a signed key at the moment (I [...] I found a sponsor. Now gween is in debian and I will start my nm-process in the next time. bye mejo -- NT makes the easy stuff easy, and the rest impossible. Unix makes everything possible, but nothing too easy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
advocate for gween
Hello, I have build a debian-package of gween (gween.freesources.org). gween is a web engine based on php. It replaces the template-system and helps administrating php webpages. You already can find it with adding this to your sources.list: deb http://apt.freesources.org/debian sid main deb-src http://apt.freesources.org/debian sid main I already read debian-policy and developers-reference. Now I'm at reading the new-maintainers-guide. Would anyone be advocate for me? I don't have a signed key at the moment (I think in the next month), and I don't feel good enough to register for nm-process. I would like to have gween in debian so that I can learn a bit and then as fast as possible I will start the nm-process. Thanks a lot Jonas PS: You also can find me at opn as mejo (#debian-devel, #fHG and #debian.de) -- We'll try to make different mistakes this time -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
