Re: Compile Kernel 32 bits on an 64 bits machine: initramfs
I acknowledge that this is a late answer, hope it still helps. On Mon, Jun 08, 2015 at 05:45:52PM +0100, pietrop wrote: > I am running a Debian 8 machine and I need to compile a 32 bits kernel > using this system, I have managed to compile the kernel using the > package linux-source-3.16 and it boots fine exporting CFLAGS=-m32 > to cross compile. > > Basically: > > export CFLAGS=-m32 > make > make modules_install > make install What looks like a successful cross compile, is horribly broken. The kernel build involves many more architecture specific things than invoking a compiler. So merely adding -m32 to CFLAGS gets you some parts build for amd64 and others for i386. I'm surprised it worked at all. > What's your reckon ? If my thought is correct where could I find a > pre-generated initramfs to use with such kernel version, or do you have > any other solution ? Projects differ in how they do cross compilation and for Linux there are two key aspects to going cross. You set two variables when invoking make. The keys to set are ARCH= and CROSS_COMPILE=. I don't know the correct value for ARCH of hand, because it seems to be the same for amd64 and i386: x86, so there likely is another fiddle to distinguish them. You should set CROSS_COMPILE to "i586-linux-gnu-" and ensure that you have such a toolchain. One way to get that toolchain (and yes, it is more than just i586-linux-gnu-gcc) when you already do have multilib is to use Guillem's fake cross toolchains. See https://lists.debian.org/debian-devel/2013/08/msg00305.html for details. For more information on cross compiling Linux, see the comments in the toplevel Makefile. Helmut
Bug#795298: #795298 RFS: roxterm/3.1.3-1
❦ 12 août 2015 20:16 +0100, Tony Houghton : >> Oops, please wait until I change it to 3.1.4-1. I overlooked the appdata >> file in #795217. It contains some outdated content so I need to change >> it upstream. > > OK, 3.1.4-1 is ready now. The dget command is now: > > dget -x > http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_3.1.4-1.dsc Did you contact your regular sponsor? I see you put him in copy of your message but it is unclear if you have previously tried to reach him and he was unresponsive. -- Debian package sponsoring guidelines: http://vincent.bernat.im/en/debian-package-sponsoring.html signature.asc Description: PGP signature
Bug#795298: #795298 RFS: roxterm/3.1.3-1
Oops, please wait until I change it to 3.1.4-1. I overlooked the appdata file in #795217. It contains some outdated content so I need to change it upstream.
Bug#795298: #795298 RFS: roxterm/3.1.3-1
On 12/08/15 19:39, Tony Houghton wrote: Oops, please wait until I change it to 3.1.4-1. I overlooked the appdata file in #795217. It contains some outdated content so I need to change it upstream. OK, 3.1.4-1 is ready now. The dget command is now: dget -x http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_3.1.4-1.dsc and the ChangeLog since the last release is: roxterm (3.1.4-1) unstable; urgency=medium * Make --fork wait until dbus service name has been acquired. * Fixed child-exited signal handler for vte-2.91's new signature. * Support named user sessions. * Removed profile option for initial number of tabs. * Updated roxterm.svg's and roxterm.appdata.xml.in's licence and copyright (Closes: #795217). * debian/control: Changed descriptions and dependencies of dummy packages to prevent lintian warnings. * Added lintian overrides for warnings about dummy dbg packages. -- Tony Houghton Wed, 12 Aug 2015 19:54:53 +0100
Bug#795298: RFS: roxterm/3.1.3-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "roxterm" * Package name: roxterm Version : 3.1.3-1 Upstream Author : Tony Houghton * URL : http://roxterm.sourceforge.net * License : GPL2+ Section : x11 It builds these binary packages: roxterm - Multi-tabbed GTK+/VTE terminal emulator - binaries roxterm-data - Multi-tabbed GTK+/VTE terminal emulator - data files roxterm-dbg - Debugging symbols for roxterm roxterm-gtk2 - Transitional package to updgrade roxterm-gtk2 to roxterm roxterm-gtk2-dbg - Transitional package to updgrade roxterm-gtk2-dbg to roxterm-dbg roxterm-gtk3 - Transitional package to updgrade roxterm-gtk3 to roxterm roxterm-gtk3-dbg - Transitional package to updgrade roxterm-gtk3-dbg to roxterm-dbg To access further information about this package, please visit the following URL: http://mentors.debian.net/package/roxterm Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_3.1.3-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: roxterm (3.1.3-1) unstable; urgency=medium * Make --fork wait until dbus service name has been acquired. * Fixed child-exited signal handler for vte-2.91's new signature. * Support named user sessions. * Removed profile option for initial number of tabs. * Updated SVG icon's licence and copyright (Closes: #795217). * debian/control: Changed descriptions and dependencies of dummy packages to prevent lintian warnings. * Added lintian overrides for warnings about dummy dbg packages. -- Tony Houghton Wed, 12 Aug 2015 18:13:04 +0100 Regards, Tony Houghton
Re: Broken tar invocation in mk-origtargz
Hi,
Am Mittwoch, den 12.08.2015, 14:25 -0300 schrieb Fernando Toledo:
> El 11/08/15 a las 16:31, Joachim Breitner escribió:
> > Hi,
> >
> > Am Sonntag, den 09.08.2015, 14:33 +0200 schrieb Felix Natter:
> > > I don't mind fixing this (in the next few days), but also see no
> > > problem in filing a tag=newcomer bug against devscripts
> > > ("[mk-origtargz]") for fixing in debconf, mentioning the
> > > workaround. (This is a pretty bad bug, but it's already broken in
> > > jessie, so it probably doesn't matter whether it's fixed tomorrow
> > > or next month)
> >
> > I wanted to know if uscan can handle pandoc, so I just fixed it:
> > http://anonscm.debian.org/cgit/collab
> > -maint/devscripts.git/commit/?id=13f5c48414547b627501d782aa502d3b91
> > 6bb0b7
> >
> > Greetings, Joachim
> >
> thanks,
>
> this fix will backported to jessie?
I believe James regularly backports devscripts, so once a version with
the fix is released and backported, then yes.
Greetings,
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
signature.asc
Description: This is a digitally signed message part
Re: Broken tar invocation in mk-origtargz
El 11/08/15 a las 16:31, Joachim Breitner escribió:
> Hi,
>
> Am Sonntag, den 09.08.2015, 14:33 +0200 schrieb Felix Natter:
>> I don't mind fixing this (in the next few days), but also see no
>> problem in filing a tag=newcomer bug against devscripts
>> ("[mk-origtargz]") for fixing in debconf, mentioning the
>> workaround. (This is a pretty bad bug, but it's already broken in
>> jessie, so it probably doesn't matter whether it's fixed tomorrow
>> or next month)
>
> I wanted to know if uscan can handle pandoc, so I just fixed it:
> http://anonscm.debian.org/cgit/collab-maint/devscripts.git/commit/?id=13f5c48414547b627501d782aa502d3b916bb0b7
>
> Greetings, Joachim
>
thanks,
this fix will backported to jessie?
--
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar
Bug#781927: collab-maint
Hello Antti, FWIW collab-maint a.k.a. Aloith can be used by non-DM and non-DD. Having Aloith account is enough. Cheers Geert Stappers P.S. Sorry for not replying on the e-mail of last week. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150812113422.gm18...@rosa.stappers.it
Introduce wrapper package of linuxbrew into Debian
Hi mentors, Weeks ago I intended to package linuxbrew, the missing package manager, which is a fork of Homebrew (Mac OS X). Linuxbrew it's Formula update is managed by git, hence initially I found it tricky to manage original linuxbrew with gbp tools, for these reason: * if original linuxbrew (including its Formulas) is provided, the dquilt will fall into a tough situation. that is to say, if I patched the upstream linuxbrew, then when user's about to run $ brew update then the git will complain the dquilt patched linuxbrew is dirty, that is bad. * security issues are handled by upstream, and it's update period is much faster than debian package upload period. Maybe it's not wise to provide the whole, original linuxbrew, and providing just a wrapper package is better, since that will be easy to maintain. After a discussion [1] with linuxbrew maintainer I think providing just a wrapper package is the best solution. The wrapper package I refered was already uploaded to mentors[2], but I don't know if this is proper, so I didn't file RFS. You can get the source here: http://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20150804-1.dsc The wrapper package includes: 1. the (ruby) install script from upstream 2. a shell wrapper for linuxbrew wrote by myself Any advice ? Thank you :-) The ITP of linuxbrew is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792642 [1] https://github.com/Homebrew/linuxbrew/issues/495 [2] http://mentors.debian.net/package/linuxbrew-wrapper -- .''`. Lumin : :' : `. `' `-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A signature.asc Description: This is a digitally signed message part
Re: Need help to fix hardening-no-relro and hardening-no-relro
PS: Just find out it is the debugging symbol taking all that space, so I re-enable the stackprotector. 2015-08-12 16:11 GMT+08:00, Alex Vong : > Hi Jean-Michel, > > Thanks for reminding me that overriding isn't safe. > > Now I use `DEB_BUILD_MAINT_OPTIONS = hardening=-stackprotector' to > remove `-fstack-protector-strong' since it makes the binary 10 times > the size without the flag. The DEB_*_MAINT_* seems like a better way > to manipulate flags since new flags can be added without me doing > anything as you said. Maybe Lintian should add a new warning: > Overrding *FLAGS in debian/rules. > > Cheers, > Alex > > 2015-08-11 23:12 GMT+08:00, Jean-Michel Vourgère : >> Alex Vong wrote: >>> Maybe overriding CFLAGS and CPPFLAGS but not LDFLAGS will solve FTBFS. >>> >>> For example in debian/rules, >>> >>> CFLAGS = '-Ofoo' >>> CPPFLAGS = '-Dfoo' >>> LDFLAGS += '-lfoo' >>> >>> override_dh_auto_configure: >>> dh_auto_configure -- --enable-foo >> >> This is wrong. You should *not* overwrite default CFLAGS / CPPFLAGS and >> so on. This is precisely what usually results in poor hardening. Just >> imaging what will happen if tomorrow there is a new flag to set? >> >> If you really need to add some stuff, you can use >> DEB_CFLAGS_MAINT_APPEND, and similar. See dpkg-buildflags(1). >> >> >> -- >> To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact >> listmas...@lists.debian.org >> Archive: https://lists.debian.org/55ca10f6.2090...@debian.org >> >> > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADrxHD-sB9_0CG=ttykpkzagkykhzq4wepjxueo51vj2fsw...@mail.gmail.com
Re: Need help to fix hardening-no-relro and hardening-no-relro
Hi Jean-Michel, Thanks for reminding me that overriding isn't safe. Now I use `DEB_BUILD_MAINT_OPTIONS = hardening=-stackprotector' to remove `-fstack-protector-strong' since it makes the binary 10 times the size without the flag. The DEB_*_MAINT_* seems like a better way to manipulate flags since new flags can be added without me doing anything as you said. Maybe Lintian should add a new warning: Overrding *FLAGS in debian/rules. Cheers, Alex 2015-08-11 23:12 GMT+08:00, Jean-Michel Vourgère : > Alex Vong wrote: >> Maybe overriding CFLAGS and CPPFLAGS but not LDFLAGS will solve FTBFS. >> >> For example in debian/rules, >> >> CFLAGS = '-Ofoo' >> CPPFLAGS = '-Dfoo' >> LDFLAGS += '-lfoo' >> >> override_dh_auto_configure: >> dh_auto_configure -- --enable-foo > > This is wrong. You should *not* overwrite default CFLAGS / CPPFLAGS and > so on. This is precisely what usually results in poor hardening. Just > imaging what will happen if tomorrow there is a new flag to set? > > If you really need to add some stuff, you can use > DEB_CFLAGS_MAINT_APPEND, and similar. See dpkg-buildflags(1). > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/55ca10f6.2090...@debian.org > > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadrxhd9xgg+em4d77rvg9kh3zprx5qn8ftzm3auckduouaz...@mail.gmail.com
Re: Depend on a package from an other arch
On 2015-08-12 09:48, Niels Thykier wrote: > [...] >> > > Hi Bertrand, > > Neither solution will work. This is an artefact of how the testing > migration code handles arch:all packages. > > Please file a bug against release.debian.org requesting help with this. > > Thanks, > ~Niels > > > Actually, in hindsight - it might be easier just to make the package an 32bit package (and override the tag from lintian about abusing /usr/share). Users wanting to install your package will have to have (kfreebsd-)i386 as a foreign architecture anyway. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55cafc6a.8090...@thykier.net
Re: Depend on a package from an other arch
On 2015-08-12 09:26, Bertrand Marc wrote: > Dear mentors, > > I am trying to fix Debian bug #783875 [1]: playonlinux (which is arch > independant) should depend on the 32 bits version of wine. Therefore I > added a dependency on wine32|wine32-development, but it seems the > package will not migrate to testing [2], because wine32 is not available > on amd64. > > If I understand correctly, I should instead add a dependency on > wine32:any | wine32-development:any and ask the wine maintainer to move > to multiarch:allowed. But the best source on this subject is an Ubuntu > one [3]. I cannot find any reliable Debian source about this. > > Could you confirm that I understand this correctly ? Or do you know any > package with a dependency on a package from an other arch ? > > Thanks, > Bertrand > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783875 > [2] https://packages.qa.debian.org/p/playonlinux.html > [3] https://wiki.ubuntu.com/MultiarchSpec > Hi Bertrand, Neither solution will work. This is an artefact of how the testing migration code handles arch:all packages. Please file a bug against release.debian.org requesting help with this. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55cafa63.9020...@thykier.net
Depend on a package from an other arch
Dear mentors, I am trying to fix Debian bug #783875 [1]: playonlinux (which is arch independant) should depend on the 32 bits version of wine. Therefore I added a dependency on wine32|wine32-development, but it seems the package will not migrate to testing [2], because wine32 is not available on amd64. If I understand correctly, I should instead add a dependency on wine32:any | wine32-development:any and ask the wine maintainer to move to multiarch:allowed. But the best source on this subject is an Ubuntu one [3]. I cannot find any reliable Debian source about this. Could you confirm that I understand this correctly ? Or do you know any package with a dependency on a package from an other arch ? Thanks, Bertrand [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783875 [2] https://packages.qa.debian.org/p/playonlinux.html [3] https://wiki.ubuntu.com/MultiarchSpec signature.asc Description: OpenPGP digital signature
