Re: Architectures where unaligned access is (not) OK?

[Riku Voipio]

On Fri, Nov 21, 2014 at 06:01:11PM +0100, Jakub Wilk wrote:
> * Felipe Sateler , 2014-11-21, 14:04:
> >Sparc is definitely not ok. For evidence, see #721617, liblo was
> >trying to fetch a double from a 4-byte aligned address. Experience
> >with liblo shows that other architectures are just fine (or at
> >least are just slower) with this type of unalignment.
> 
> IME, sprac buildds are the only ones where where unaligned access in
> a build-time test suite triggers SIGBUS/SIGSEGV.

On armel and armhf you can enable SIGBUS on unaligned access with:

echo 4 > /proc/cpu/alignment

Riku


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124090723.ga20...@afflict.kos.to

Re: Architectures where unaligned access is (not) OK?

[Riku Voipio]

On Sat, Nov 22, 2014 at 11:03:16PM +0100, Bastien ROUCARIES wrote:
> On Sat, Nov 22, 2014 at 10:37 PM, brian m. carlson
>  wrote:
> > On Sat, Nov 22, 2014 at 09:42:43PM +0100, Jakub Wilk wrote:
> >> * Henrique de Moraes Holschuh , 2014-11-21, 17:34:
> >> >i386:
> >> >   __asm__("pushf\norl $0x4,(%esp)\npopf");
> >>
> >> It works! Actually, it works so well it makes puts("hello world") die with
> >> SIGBUS. :-(
> >
> > Yeah, that's my experience, too.  glibc is not alignment check-safe on
> > i386 and amd64.  If you turn it on in an LD_PRELOAD using _init, it
> > segfaults before main.
 
> I have improved https://wiki.debian.org/ArchitectureSpecificsMemo fell
> free to add to it.

Thanks for updates. However, I'm not sure if the current unaligned
accesses letters make it clear:

Y=Yes, O=Often generally ok but ma fail in some specific case, T=Traps
may be fixed by kernel (super slow),M=Maybe generally not ok, N=No raise
SIGBUS. See detail below

Now, the M/T for armel/armhf/arm64 which is ambigous and misleading.
Better make if clear:

armel: no
armhf: yes (exceptions as listed by Leif)
arm64: yes (exceptions as listed by Leif)

And then link to Leif's mail rather than copy the text unattributed on
already long wikipage.

Riku


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124093825.gb20...@afflict.kos.to

Re: Architectures where unaligned access is (not) OK?

[Riku Voipio]

On Fri, Nov 21, 2014 at 02:40:01PM +, Wookey wrote:
> Whilst that is nice and correct I'm not sure the meaning is clear to a
> software engineer, which is: Don't do unaligned access on arm64. It's
> always inefficient, sometimes extremely inefficient, and sometimes
> won't work at all.

That's an exaggeration.

libav/ffmpeg for example has:

  fast_unaligned_if_any="aarch64 ppc x86"
  armv[6-8]*) enable fast_clz fast_unaligned ;;

So the developers consider unaligned accesses a faster option than
aligned on armv6+. Feel free to benchmark with and without the flag :)

I can understand CPU/cache designers pain in implementing unaligned access,
but reality is that ARMv7+ supports unaligned accesses quite well and this
sometimes allows software engineers sometimes to write more clean and
maintainable code. 

This doesn't mean that unaligned accesses make always sense. There is plenty
of unaligned accesses that could be converted to more clean code that does
aligned accesses... 
 
> arm64 simply doesn't permit unaligned access in the core. Some types
> of access are wrapped (in hardware) so that 2 access will get done and
> you are returned the relevant pieces of the result, but this doesn't
> apply to all access types and is obviously slower/energy
> inefficent. 

If your data is split over aligment boundaries, you will need multiple
memory accesses anyways. 

Riku


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124103056.gc20...@afflict.kos.to

Re: Age of built packages to be part of the jessie release?

[Svante Signell]

On Sat, 2014-11-22 at 15:36 +, Neil Williams wrote:
> On Sat, 22 Nov 2014 16:19:10 +0100
> Svante Signell  wrote:
> 
> > Hello,
> > 
> > I wonder how old a package build can be to be part of the release.
> > Some packages are built up to a year ago, and rebuilding them now
> > FTBFS. What to do, file a bug or accept status quo?
> > 
> > Thanks!
> 
> In summary: Everything released in Jessie must build on Jessie. That's
> why we have intermittent archive-wide rebuilds (which are typically
> only on amd64). We don't routinely rebuild the entire archive prior to
> the release but we need to be able to do so.
> 
> Criteria are:
> 
> * A package which FTBFS in a clean Jessie build environment and
> * on a release architecture and
> * where there is no existing bug and 
> * the package has previously built on that architecture
> 
> -> file a FTBFS RC bug with full build log.

Thanks for all replies not only this one. A question remains (for me):
How to build a package in a clean jessie environment? Seems like the
buildds are using sbuild. Is that the preferred way to try out a single
package, built on most buildds since 240 days. I'm currently running sid
boxes. The package at hand, lam, FTBFS at least on my amd64 box.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416829363.11764.286.ca...@g3620.my.own.domain

Re: packaging diaspora, final steps, looking for collaborators

[Alastair McKinstry]

Hi,

I'm not a Ruby programmer but I am a DD and I run a Diaspora pod
(diaspora.sceal.ie)  and am willing to help, particularly with
integration where possible.

Not sure how much time I can devote to this. I'm getting near the end of
my PhD and will be effectively disappearing for a while, but I'm here.

regards
Alastair

On 23/11/2014 20:13, Pirate Praveen wrote:
> Hi,
>
> We've been working on packaging diaspora since last 2+ years. It is
> written in ruby on rails framework and has 206 dependencies
> https://people.debian.org/~praveen/diasbar/ So far we packaged around
> 86% of the dependencies.
>
> Now I created a diaspora package with remaining dependencies uploaded in
> my people.debian.org account.
>
> You can follow the steps listed at https://wiki.debian.org/Diaspora to
> install it right now.
>
> I'm looking for some help to complete this packaging.
>
> Some tasks I need help are,
>
> 1. Complete packaging of remaining gem dependencies
>
> 2. Test the installation by going ahead with next steps listed at
> diaspora installation manual
>
> 3. Create debconf templates for pod configuration.
>
> 4. Help keep the gem versions in sync. If deb version of a library is
> older than required by diaspora (run 'bundle install --local' on a
> develop branch checkout of diaspora upstream), update the deb version.
> If debian already has a new version of a library, update the
> corresponding gem version in diaspora.
>
> 5. Create a tracker to check the dependency status in debian with
> diaspora develop branch.
>
> Once diaspora package is completed, this will be a boost to Freedom Box
> efforts. Hoping to get some collaborators in this final push.
>
> We hangout at #debian-diaspora on oftc.
>
> Thanks
> Praveen
>

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547319d9.1000...@sceal.ie

Re: Age of built packages to be part of the jessie release?

[Simon McVittie]

On 24/11/14 11:42, Svante Signell wrote:
> A question remains (for me):
> How to build a package in a clean jessie environment? Seems like the
> buildds are using sbuild.

Have a minimal jessie chroot with build-essential, and a minimum of
supporting tools to help with setup (I use cdebootstrap --flavour=build
and add sudo, vim, fakeroot and eatmydata, the latter because it makes
sbuild a lot faster); set it up in schroot; feed the .dsc to "sbuild -d
jessie". Add "-A" if you want to exercise building the Architecture:all
bits.

Note that Lucas Nussbaum recently built many packages (the entire
archive?) in jessie/amd64/sbuild using Debian's Amazon Web Services
credit, and opened bugs like
. If you
intend to do mass-bug-filing based on a similar rebuild campaign, your
time might be more effectively used by helping with Lucas'
infrastructure than by making your own mass-rebuild setup. I suspect
Lucas might already have a backlog of failed build logs for analysis and
bug-filing that you could help to process.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54732186.3030...@debian.org

Fwd: ITP: cruft-ng -- program that finds any cruft built up on your system / rewrite in C

[Alexandre Detiste]

Hi,

Here is my ITP for my rewrite of cruft's engine.

It reuses the same rule-set an produce the same output.

I put Q.A. in CC because some people use it a bit like "piuparts"
to see if there are not leftover files from removed packages.
(or from hasty "sudo make install")

I uploaded it to mentors.d.o:

http://mentors.debian.net/package/cruft-ng

Please comment :-)


Alexandre Detiste

--  Message transmis  --
Objet : ITP: cruft-ng -- program that finds any cruft built up on your system / 
rewrite in C
Date : vendredi 21 novembre 2014, 11:12:29
De : Alexandre Detiste 
 À : Debian Bug Tracking System 

Package: wnpp
Severity: wishlist

Dear Maintainers,

*Package Name : cruft-ng
  Version : 0.1
  Upstream Author : Alexandre Detiste (this is a native package).
*URL :  https://github.com/a-detiste/cruft-ng
*License : GPL-2+ 
*Description : program that finds any cruft built up on your system
   I've been using "cruft" for years, and I've packaged the last
   uploads needed to refresh the rule set.

   My main "itch to scratch" was that tool - while usefull for
   individual house-keeping & package debugging (like piuparts) -
   was sooo slow...

   I rewrote it in C++; but that's mostly C + strings + vector.
   This is my first C program in 13 years, you may find
   it a bit lame; patches are welcome.

   It is rouglhy 15 to 30 times fasters.

   Original cruft is a shell script that calls a myriad 
   of sub-processes.

   While not yet feature complete; I find it already usefull;
   this enabled me to fix "cruft" ruleset iteratively,
   without waiting hours.

   This version also solves some original cruft bugs:
   #50731 , #429602 , #492001

   This is mostly done, the only bit missing are a proper
   Makefile & and a man page.

   The first version would "Depends: cruft (< 0.9.20) | cruft-common"

   Then, after Jessie is released, cruft would be split in
   cruft + cruft-common .

   This way users can install both and even diff the results
   of both tools, as they are character compatible.

Alexandre Detiste

signature.asc
Description: This is a digitally signed message part.

Re: ITP: cruft-ng -- program that finds any cruft built up on your system / rewrite in C

[Mattia Rizzolo]

On Mon Nov 24 2014 at 1:33:16 PM Alexandre Detiste <
alexandre.deti...@gmail.com> wrote:

> Hi,
>
> Here is my ITP for my rewrite of cruft's engine.
>
> It reuses the same rule-set an produce the same output.
>
> I put Q.A. in CC because some people use it a bit like "piuparts"
> to see if there are not leftover files from removed packages.
> (or from hasty "sudo make install")
>
> I uploaded it to mentors.d.o:


I think you might want to email debian-mentors, with a sponsorship request
(an RFS bug), rather than debian-devel, that is intended as a mailing list
for technical discussions.
See https://mentors.debian.net/sponsors

Re: Age of built packages to be part of the jessie release?

[Matthew Vernon]

Simon McVittie  writes:

> On 24/11/14 11:42, Svante Signell wrote:
> > A question remains (for me):
> > How to build a package in a clean jessie environment? Seems like the
> > buildds are using sbuild.
> 
> Have a minimal jessie chroot with build-essential, and a minimum of
> supporting tools to help with setup (I use cdebootstrap --flavour=build
> and add sudo, vim, fakeroot and eatmydata, the latter because it makes
> sbuild a lot faster); set it up in schroot; feed the .dsc to "sbuild -d
> jessie". Add "-A" if you want to exercise building the Architecture:all
> bits.

Why not use sbuild-createchroot? I find it's a nice and easy way to
create chroots for building things.

Regards,

Matthew 

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5btx1owtid@chiark.greenend.org.uk

Re: New dash in experimental showing up a widespread bashism in configure scripts

[Gerrit Pape]

On Sat, Nov 08, 2014 at 11:57:58AM +, Jonathan de Boyne Pollard wrote:
> Gerrit Pape:
> >Hi, I'd very appreciate help on  tracking down the failures and do
> > the appropriate analysis, reportbug, patch drafting, and the like, as
> > my time for this is quite limited.
> 
> I took a handful of packages as a sample, and the problem could be
> traced to the same bug, over and over, in almost all cases.  Here's
> the first error building fizmo_0.7.9-1 from your logs:
> 
> ./configure: 2340: test: xyes: unexpected operator

Hi Jonathan,

thanks for looking into it.  Sven Joachim already pointed to the right
direction: I re-enabled LINENO support in this very upload, to check
whether things got better since #582952.  But this isn't the case.

Raphael Geissert found out that autoconf checks for LINENO support in
/bin/sh and forces the use of /bin/bash if LINENO support is absent.  If
it finds LINENO support it uses /bin/sh which then exposes all those
bashisms.

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582952#83

-2 in experimental disables LINENO support again.

Best Regards, Gerrit.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141124153005.15130.qm...@8487efc8d37b28.315fe32.mid.smarden.org

Bug#770846: ITP: python-os-client-config -- OpenStack client configuation library

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-os-client-config
  Version : 0.3.0
  Upstream Author : Monty Taylor 
* URL : http://github.com/stackforge/os-client-config
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack client configuation library

 Os-client-config is a library for collecting client configuration for using an
 OpenStack cloud in a consistent and comprehensive manner. It will find cloud
 config for as few as 1 cloud and as many as you want to put in a config file.
 It will read environment variables and config files, and it also contains some
 vendor specific default values so that you don't have to know extra info to
 use OpenStack
 .
 os-client-config honors all of the normal OS_* variables. It does not provide
 backwards compatibility to service-specific variables such as NOVA_USERNAME.
 .
 If you have environment variables and no config files, os-client-config will
 produce a cloud config object named "openstack" containing your values from
 the environment.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141124162404.25648.83131.report...@buzig.gplhost.com

Re: Architectures where unaligned access is (not) OK?

[Bastien ROUCARIES]

On Mon, Nov 24, 2014 at 10:38 AM, Riku Voipio  wrote:
> On Sat, Nov 22, 2014 at 11:03:16PM +0100, Bastien ROUCARIES wrote:
>> On Sat, Nov 22, 2014 at 10:37 PM, brian m. carlson
>>  wrote:
>> > On Sat, Nov 22, 2014 at 09:42:43PM +0100, Jakub Wilk wrote:
>> >> * Henrique de Moraes Holschuh , 2014-11-21, 17:34:
>> >> >i386:
>> >> >   __asm__("pushf\norl $0x4,(%esp)\npopf");
>> >>
>> >> It works! Actually, it works so well it makes puts("hello world") die with
>> >> SIGBUS. :-(
>> >
>> > Yeah, that's my experience, too.  glibc is not alignment check-safe on
>> > i386 and amd64.  If you turn it on in an LD_PRELOAD using _init, it
>> > segfaults before main.
>
>> I have improved https://wiki.debian.org/ArchitectureSpecificsMemo fell
>> free to add to it.
>
> Thanks for updates. However, I'm not sure if the current unaligned
> accesses letters make it clear:
>
> Y=Yes, O=Often generally ok but ma fail in some specific case, T=Traps
> may be fixed by kernel (super slow),M=Maybe generally not ok, N=No 
> raise
> SIGBUS. See detail below

i am open to suggestion

> Now, the M/T for armel/armhf/arm64 which is ambigous and misleading.
> Better make if clear:
>
> armel: no

No = sigbus ? or trap ?
> armhf: yes (exceptions as listed by Leif)
So it is often like i386
> arm64: yes (exceptions as listed by Leif)
often
>
> And then link to Leif's mail rather than copy the text unattributed on
> already long wikipage.

OK will add link. But I think the page will grow with fpu stuff...

> Riku


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cae2spaa-sbo8j8rpnvo2ogqzcftwr4_ztardoxtytemqvac...@mail.gmail.com

Re: systemd breaking display manager - no way to force?

[Gunnar Wolf]

Agustin Martin dijo [Fri, Nov 21, 2014 at 11:51:53AM +0100]:
> > > Is there *any* way to *force* systemd to start lightdm ...?
> > 
> > I have a hunch the bug is actually in lxdm (specifically the service 
> > file). It should be simple to verify:
> > 
> > - purge lxdm (remove might do it as well, but just for good measure)
> > - reconfigure lightdm (to make sure display-manager.service symlink 
> >   points to lightdm.service)
> 
> Although I am still using sysvinit I have both display managers installed
> in this sid box and to my surprise, 
> 
> /etc/systemd/system/display-manager.service
> 
> symlink is not present here, although
> 
> /lib/systemd/system/lightdm.service
> /lib/systemd/system/lxdm.service
> /lib/systemd/system/gdm3.service
> 
> are available. 
> 
> Norbert, what happens at your box? If the symlink is present, where does
> it point to?

Hi Agustin,

In my Sid machine:

$ ls -l /etc/systemd/system/display-manager.service 
lrwxrwxrwx 1 root root 35 Oct 28 12:33 
/etc/systemd/system/display-manager.service -> 
/lib/systemd/system/lightdm.service
$ systemctl status lightdm.service 
● lightdm.service - Light Display Manager
   Loaded: loaded (/lib/systemd/system/lightdm.service; enabled)
   Active: active (running) since Fri 2014-10-31 15:18:50 CST; 3 weeks 2 days 
ago
 Docs: man:lightdm(1)
 Main PID: 5268 (lightdm)
   CGroup: /system.slice/lightdm.service
   ├─ 5268 /usr/sbin/lightdm
   └─25408 /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 
-nolisten tcp vt7 -novtswitch

I only have one display manager installed, though, and cannot say what
would happen with others.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124162820.gd24...@gwolf.org

Re: systemd breaking display manager - no way to force?

[Simon McVittie]

On 21/11/14 00:45, Norbert Preining wrote:
> so here we are, after the freeze, and systemd stubbornly rejects
> to start lightdm, my default display manager, and in turn tries
> to start lxdm, which does not work because it is not selected as
> default display manager. (Bug reported to systemd already)

I diagnosed this as a bug in lxdm's interaction with
display-manager.service arbitration (basically, lxdm's postinst was
trampling over part of the mechanism for running the single selected
*dm). Sjoerd agreed and reassigned it to lxdm.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770404

This is not a jessie blocker, because lxdm was not in jessie at freeze
time, so it will presumably never get there.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54736291.9080...@debian.org

Re: systemd, fstab, noauto and nofail

[Noel Torres]

On Monday, 24 de November de 2014 07:33:38 Matthias Urlichs escribió:
> Hi,
> 
> Noel Torres:
> > Anyway I see that you do not use the noauto option. Is that on purpose?
> 
> What? It's the very first option.

My fault. My eyes looked for "defaults,noauto" while I was searching for just 
"noauto".
> 
> In any case, I can see why three entries for the same mountpoint don't
> exactly fit systemd's view of the world -- I wouldn't get that idea either,
> since "mount /media/photos" doesn't know which device to check.
> 
> Thus, I'd fix this problem in a different way -- either with an udev rule
> that sets an appropriate symlink and/or outright mounts the volume when
> something gets inserted, or with udisksctl, or by telling your desktop
> environment to auto-mount.

Agreed, I would have used udev as well. Problem is that udev documentation is 
not as widely spread as fstab documentation, and also not as easy.

Anyway, systemd getting into the Admin's way is a bug. Everytime an app does 
that, it is a failure either in the app, or in the developer's view of the 
world.

Not the same for the regular users, tough. There usually Admin wants users to 
be unable to do this or that.

Regards

Noel
er Envite


signature.asc
Description: This is a digitally signed message part.

Re: systemd breaking display manager - no way to force?

[Agustin Martin]

On Mon, Nov 24, 2014 at 10:28:20AM -0600, Gunnar Wolf wrote:
> Agustin Martin dijo [Fri, Nov 21, 2014 at 11:51:53AM +0100]:
> > > > Is there *any* way to *force* systemd to start lightdm ...?
> > > 
> > > I have a hunch the bug is actually in lxdm (specifically the service 
> > > file). It should be simple to verify:
> > > 
> > > - purge lxdm (remove might do it as well, but just for good measure)
> > > - reconfigure lightdm (to make sure display-manager.service symlink 
> > >   points to lightdm.service)
> > 
> > Although I am still using sysvinit I have both display managers installed
> > in this sid box and to my surprise, 
> > 
> > /etc/systemd/system/display-manager.service
> > 
> > symlink is not present here, although
> > 
> > /lib/systemd/system/lightdm.service
> > /lib/systemd/system/lxdm.service
> > /lib/systemd/system/gdm3.service
> > 
> > are available. 
> > 
> > Norbert, what happens at your box? If the symlink is present, where does
> > it point to?
> 
> Hi Agustin,
> 
> In my Sid machine:
> 
> $ ls -l /etc/systemd/system/display-manager.service 
> lrwxrwxrwx 1 root root 35 Oct 28 12:33 
> /etc/systemd/system/display-manager.service -> 
> /lib/systemd/system/lightdm.service
> $ systemctl status lightdm.service 
> ● lightdm.service - Light Display Manager
>Loaded: loaded (/lib/systemd/system/lightdm.service; enabled)
>Active: active (running) since Fri 2014-10-31 15:18:50 CST; 3 weeks 2 days 
> ago
>  Docs: man:lightdm(1)
>  Main PID: 5268 (lightdm)
>CGroup: /system.slice/lightdm.service
>├─ 5268 /usr/sbin/lightdm
>└─25408 /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 
> -nolisten tcp vt7 -novtswitch
> 
> I only have one display manager installed, though, and cannot say what
> would happen with others.

Hi, Gunnar, 

Noticed later that there is no real problem here, sorry for the noise,

It happens that I also have wdm installed here and is default in this
particular box. Since wdm does not ship a wdm.service (#761642), symlink is not
done, as expected. This indeed shows that current symlink handling mechanism
also works in this case.

Regards,

-- 
Agustin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124170127.ga3...@agmartin.aq.upm.es

Re: Age of built packages to be part of the jessie release?

[Manuel A. Fernandez Montecelo]

2014-11-23 14:27 Stuart Prescott:

Svante Signell wrote:


I wonder how old a package build can be to be part of the release. Some
packages are built up to a year ago, and rebuilding them now FTBFS.


As others have noted already, there are period archive rebuilds to check
what would now ftbfs.

Slightly orthogonal to your question, "up to a year ago" doesn't come close,
actually... 42% of source packages in jessie were uploaded over a year ago,
25% over two years ago, 15% over three years ago, 9% over four years ago.
Fun fact: there are 64 source packages in jessie that are over 10 years old.

Age of source packages in each release:

http://ircbots.debian.net/stats/package_ages.png

(note: this is based on source package uploads; binNMUs not included)


Not nicely backed with hard data as you have here, but from my random
observations looking at the state of many packages over many years (in BSPs,
architecture bootstrapping, etc), I reached similar conclusions.


Would it make sense to trigger rebuilds (or binNMUs, or actions to the same
effect) for all packages in a given architecture when there are important
changes in the toolchain, e.g. the default GCC bumps to a new major version [1]?

For me it makes a lot of sense to have most of the archive rebuilt at that time,
and these newly compiled packages migrated at some point to testing to be
present in the next release.

With the current method it seems that we only check if it FTBFS, and packages
only get recompiled if there are new uploads or binNMUs.  But actually
recompiling and moving it to the archive will reveal changes in runtime
behaviour, and thus bugs might be caught/reported/hopefully-fixed sooner.  In
some occasions there might even be some bugs fixed (if the compiler of years ago
was buggy) or performance improvements.

I do not know if there are significant drawbacks, for example if it would be
very taxing to have everything built in a short period of time (especially for
less powerful architectures) -- not only for hardware, but delays to other
packages who are uploaded at the same time.  Or if there are other fundamental
problems that I did not consider.

In summary, if there's a cheap (esp. in humanpower) way to achieve this, I think
that it would be worth doing it.


[1] Packages depending on other language compilers/interpreters will have
   different needs and methods to approach them.


Cheers.
--
Manuel A. Fernandez Montecelo 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124185606.ga29...@reva.itsari.org

Re: The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2

[Gerrit Pape]

On Sat, Oct 25, 2014 at 09:34:50AM +, Gerrit Pape wrote:
> On Wed, Oct 22, 2014 at 09:20:46AM +, Gerrit Pape wrote:
> > On Tue, Oct 21, 2014 at 08:29:54AM -0400, Nikolay Hristov wrote:
> > > Setting up runit (2.1.2-1) ...
> > > grep: /etc/inittab: No such file or directory
> > > grep: /etc/inittab: No such file or directory
> > > cp: cannot stat ‘/etc/inittab’: No such file or directory
> > > dpkg: error processing package runit (--configure):
> > >  subprocess installed post-installation script returned error exit status 
> > > 1
> > > Errors were encountered while processing:
> > >  runit
> > > E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> > Since ages runit hooks into /etc/inittab to provide system wide service
> > supervision.  As long as sysvinit provided /etc/inittab and was
> > essential this simply worked.  Now on fresh jessie install, no
> > /etc/inittab is created at all.  While this alone wouldn't be a problem,
> > because runit provides a simple systemd unit after I learned that
> > there's no backward compatibility to the /etc/inittab interface, it is a
> > problem when switching such an installation from systemd to sysvinit:
> > 
> > When switching to sysvinit, the /etc/inittab file is created, but
> > doesn't include the lines enabling the runit supervision.  After reboot
> > runit supervision will not be enabled, although the package is
> > installed.  This would be a grave bug as other packages depend on this
> > assumption.
> > 
> > Any idea on how to fix this?
> 
> This is far from ideal, but the only easy fix I came up with until now
> is to copy debian/share/inittab* from the sysvinit source package, as
> well as the debian/rules logic to install a system-specific inittab
> template and the postinst logic to create /etc/inittab if it does not
> exist, into the runit package.
> 
> A better fix certainly will need more thoughts, coordination, and
> testing, which I'm afraid I can't work on currently.  Anyone?

This is not yet resolved, unfortunately.  It currently affects at least
two packages and a minor number of dependencies:
https://bugs.debian.org/766187 and https://bugs.debian.org/767933

Suggestions I got are (1) check whether /etc/inittab exists before
adding the service, continue if it doesn't exist, and (2)
https://bugs.debian.org/767933#46

(1) seems not to be the solution.  When installing default jessie, then
installing runit or daemontools-run, and afterwards sysvinit-core, the
service supervision will be disabled.  There may be a package in jessie
that implements (1), I'm not sure what isdnutils does these days.

Better than (2) would be to make the existence of /etc/inittab still
essential for jessie, by moving the corresponding code from
sysvinit-core into the essential init package.  What do you think?

Regards, Gerrit.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141124214112.1510.qm...@c2b2b269944a4a.315fe32.mid.smarden.org

Re: The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2

[Simon McVittie]

On 24/11/14 21:41, Gerrit Pape wrote:
> Better than (2) would be to make the existence of /etc/inittab still
> essential for jessie, by moving the corresponding code from
> sysvinit-core into the essential init package.  What do you think?

If you go this route, I think initscripts might be a better home for
inittab. It is depended on by all our supported pid 1 implementations -
sysvinit-core, systemd-sysv (via systemd) and upstart - and comes from
the same source package as sysvinit, which init does not.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5473ac71.7030...@debian.org

Bug#770889: ITP: python-pymysql -- Pure-Python MySQL driver

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-pymysql
  Version : 0.6.2
  Upstream Author : Marcel Rodrigues 
* URL : https://github.com/PyMySQL/PyMySQL/
* License : Expat
  Programming Lang: Python
  Description : Pure-Python MySQL driver

 This package contains a pure-Python MySQL client library. The goal of PyMySQL
 is to be a drop-in replacement for MySQLdb and work on CPython, PyPy,
 IronPython and Jython.

This is yet another new dependency for OpenStack. Note that this package is
interesting because it has Python 3 support.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141124222343.1733.63379.report...@buzig.gplhost.com