Re: Validating tarballs against git repositories

[Ingo Jürgensmann]

Am 30.03.2024 um 08:56 schrieb Lucas Nussbaum :

> Yes. In that specific case, the original xz maintainer (Lasse Collin)
> was socially-pressed by a likely fake person (Jigar Kumar) to do the
> "right thing" and hand over maintenance.
> https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.html

In his reply to that mail Lasse writes in 
https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html:

> It's also good to keep in mind that this is an unpaid hobby project.


This reminds me of https://xkcd.com/2347/ - and I think that’s getting a more 
common threat vector for FLOSS: pick up some random lib that is widely used, 
insert some malicious code and have fun. Then also imagine stuff that automates 
builds in other ways like docker containers, Ruby, Rust, pip that pull stuff 
from the network and installs it without further checks. 

I hope (and am confident) that Debian as a project will react accordingly to 
prevent this happening again. 

But as a society (that is widely using FLOSS) I would also hope that our 
developers will get proper funding instead of requiring them to maintain such 
software in their spare time. 

-- 
Ciao...  //Web: http://blog.windfluechter.net
  Ingo \X/ XMPP/Jabber:   i...@jhookipa.net

gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ingo Jürgensmann]

Am 10.09.2019 um 07:50 schrieb Florian Lohoff :

> On Mon, Sep 09, 2019 at 03:31:37PM +0200, Bjørn Mork wrote:
>> I for one, do trust my ISPs a lot more than I trust Cloudflare or
>> Google, simply based on the jurisdiction.
> There are tons of setups which are fine tuned for latency because they
> are behind sat links etc or low bandwidth landlines. They have dns
> caches with prefetching to reduce typical resolve latency down to sub
> milliseconds although your RTT to google/cloudflare is >1000ms.
> 
> Switching from your systems resolver fed by DHCP to DoH in Firefox will
> make the resolve latency go from sub ms to multiple seconds as the
> HTTP/TLS handshake will take multiple RTT. This will effectively break
> ANY setup behind Sat links e.g. for example all cruise ships at
> sea.

I can confirm (based on experiences on my day job) that this can be a real 
problem and affecting thousands and hundredthousands of users.

Having the *option* to use DoH is maybe a good idea, but making it the default 
is not. 

-- 
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net

gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Re: Usage of real m68k hardware

[Ingo Jürgensmann]

Am 17.04.2018 um 19:15 schrieb Thorsten Glaser :

>> Yes, of course. But Andreas hit a nerve with this on me. This project
>> has cost me lots of blood, tears and sweat and if someone is asking
>> for it to be completely thrown out out of nothing, I'm getting a bit
>> stressed out.
> I completely agree here. While I’m no longer involved with the
> m68k port specifically, after having spent THREE YEARS of blood,
> sweat and pain to resurrect it, there are several reasons:

I’m still very thankful for your efforts! Really!

> • I have come to actually like that, having been a die-hard 8088
>  user in my childhood, and found the people and community very
>  interesting
>  ‣ there are fun projects like a PCI bridge, which allows using
>a PCI Radeon graphics card with LCDs at 1900x12something
>resolution, currently with GEM/AES only, not yet in Linux

Actually there are some nice developments like 
http://www.apollo-accelerators.com/ to increase the speed of m68k for quite a 
few bugs. 

> • it sends a signal, and the wrong signal in my eyes, that
>  everything not-mainstream is not worth to be supported
>  ‣ specialisation is for downstreams, Debian should stay universal
>  ‣ read up on monoculture in agriculture and why everyone, by now,
>thinks it’s a bad idea
>⇒ hint: Meltdown/Spectre…

Yes, I think this is the main problem since m68k has been kicked out as a 
release arch. This whole second class architecture is a mistake, IMHO. Another 
approach would have been better, like focussing on being release-ready only for 
base and other essential packages, but not the whole archive. 
This effectively killed m68k in the long run. Other archs followed then. 

> • I found Debian ports very useful to gain deep insight on
>  how Debian and all of its components work, and can recommend
>  porting a new or resurrecting an old architecture to everyone
>  wishing to peek below the surface

That’s maybe the only positive thing that evolved in the aftermaths of kicking 
out m68k: a parallel infrastructure was developped that could act without all 
those complicated formalisms of official buildds (at least in the early days). 
But I think this could have been achieved without kicking archs out of Debian. 

I think especially m68k did a great job in teaching many DDs how to deal with 
autobuilders and such. Buildd & co were built, because of m68k and Debian. The 
very first buildd was running on kullervo. 

> On the more technical side, while Adrian’s buildds are qemu,
> I’ve continued running an ARAnyM (also emulation, but different
> and thanks to Doko even FPU-complete) buildd for as long as the
> system it was hosted on allowed me to do so. (That GPLhost domU
> is currently unusable because of spontaneous reboots and other
> problems. I might look into running one on some other system;
> I have a couple of VMs on my workplace desktop but can’t use
> those as they are bridged into the company LAN.)

I’m still not a big fan of emulated buildds. ;-) 
But I have to admit that they are way faster than the old, real hardware.

> We also have a number of Amiga and Atari and I believe at least
> one or two Macintosh systems which, at one point or the other,
> are or were in use as buildds and/or porterboxen.

Well, the last info from buildd.net database: 

buildd=# select name, model, cpu, ram from status where arch='m68k';
name|   model   |  cpu   | ram
+---++-
 washi  | Atari Falcon CT60 | 68060/66   | 256
 prometheus | Aranym/distcc | 733MHz PowerPC | 256
 minthe | Aranym| 8*Xeon 2G  | 768
 phoebe | Aranym| 8*Xeon 2G  | 768
 hobbes | Atari Falcon CT60 | 68060/95   | 512
 merlin | Amiga 1200| 68030/56   |  64
 elgar  | Amiga 4000| 68060/50   | 128
 kullervo   | Amiga 3000UX  | 68060/50   | 128
 crest  | Amiga 4000| 68060/50   | 128
 pacman | ARAnyM| VM040/240  | 512
 vivaldi| Amiga 4000T   | 68060/50   | 384
 theia  | Aranym| Dual 1.8 GHz   | 750
 wario  | ARAnyM| VM040/180  | 768
 zlin3  | Aranym| i386   |  64
 spice  | Amiga 3000| 68040/40   | 320
 aahz   | Amiga 2000| 68060/50   | 128
 akire  | Amiga 2000| 68060/50   | 128
 ara5   | ARAnyM| VM040/170  | 782
 arrakis| Amiga 3000| 68060/50   | 384
 kirby  | ARAnyM| VM040/214  | 512
 pikachu| ARAnyM| VM040/200  | 768
(21 rows)

At least crest, akire and elgar might be still online, maybe kullervo as well, 
but Christian can comment on this, while spice, arrakis & vivaldi are currently 
offline as in powered off or has a NIC that is currently not supported by Linux 
(spice).

I’m not totally opposed in powering on one or two machines again, but 

Re: Usage of real m68k hardware

[Ingo Jürgensmann]

On 28.03.2018 08:38, Andreas Tille wrote:


I conclude that the Debian project is running no real m68k hardware any
more (please correct me if I'm wrong) and we are possibly doing a
service for some users who potentially also run qemu (wild guess of
mine).  I'm wondering when it might be time to fully drop a hardware
port instead of draining developer time for ethernity.


Well, officially Debian has no real m68k hardware anymore, because the 
project decided to official drop m68k as a release arch and DSA no 
longer admins kullervo. Correct me if I'm wrong.


Alas, there is still m68k hardware around. Kullervo should be under 
control of Christian Steigies and then there should be some more m68k 
machines under control of Adrian.


My 3 Amigas are currently turned off or currently lack the support of my 
new X-Surf 100 NIC in the netinstall image provided by Adrian.


In September there is a m68k meeting planned at Linux Hotel in Essen. 
So, the m68k port is still alive and kicking! :-)


--
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Re: debian.org RTC: announcing XMPP, SIP presence and more

[Ingo Jürgensmann]

Am 21.11.2015 um 13:50 schrieb Pirate Praveen <prav...@onenetbeyond.org>:

> On 2015, നവംബർ 21 5:20:27 PM IST, "Ingo Jürgensmann" 
> <i...@2014.bluespice.org> wrote:
> >Maybe someone can setup a service or tool that logs into your old XMPP
> >contact and either forwards incoming messages from your old XMPP
> >account to the new one or gives the other users some kind of automated
> >notification that you can reached now at the other address…
> There is an xep for sharing contacts, no idea which clients support it though.
> http://xmpp.org/extensions/xep-0144.html

Well, sharing contacts is one thing. In most cases you can export your roster 
and import it somewhere else, but the main problem is that you need all your 
contacts to use your new XMPP instead of your old. That’s the real problem, I 
think. 

-- 
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Re: debian.org RTC: announcing XMPP, SIP presence and more

[Ingo Jürgensmann]

Am 21.11.2015 um 12:31 schrieb Stefano Zacchiroli :

> - Do we offer any reasonable guarantee about the long term availability
>  of the XMPP service, e.g., for people that stop being Debian Project
>  Members?
> 
>  I guess the answer here is "no", and it's a reasonable one. But we
>  should be clear on the matter, as it might affect people's decision on
>  whether switching to @debian.org as their main XMPP contact or not.

I would expect that only active DD/Contributors/… are reachable via a 
debian.org XMPP address. The same as it is for mail addresses. 

> - Can you recommend best practices and/or tools for migrating from a
>  primary XMPP identity to a new one?
> 
>  I (shamefully) still use an @gmail.com address as my main XMPP
>  identity and I've been looking into migrating away since quite a
>  while. But I've hundreds of contact there and I don't really know how
>  to minimize their (and mine) pain during a migration. If anyone have
>  tips, I'll be very glad to hear about them.

This, indeed, is an interesting question and challenging task. I’ve been using 
the below mentioned XMPP address for years now, but since I migrated from 
Openfire to Prosody I’m able to provide an XMPP address for every domain I 
host. Having one single point of contact (mail address) for mail, XMPP and SIP 
is what users usually want. I see this at my work place as well: people don’t 
like to tell others „you can reach me by mail at this address, but when you 
want me to contact by Jabber then use the other address, oh, and when you want 
to call me, then use another address…“ They usually want to tell others „Hey, 
you can reach me at this address…“ (no matter of which protocol you are using).

So, migrating XMPP contacts is difficult and I have no better idea than writing 
them a message that you moved over to a new address. This is similar to the 
migration process when getting a new cell phone number. 
Maybe someone can setup a service or tool that logs into your old XMPP contact 
and either forwards incoming messages from your old XMPP account to the new one 
or gives the other users some kind of automated notification that you can 
reached now at the other address… 

But in the end I expect people to be reached until their mail address, 
regardless of which protocol I want to use. This will take some time, but I 
think it’s the way to go. So the service Daniel set up with XMPP and RTC is the 
right thing. Huge leap forward for Debian, I think! :-) 

-- 
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Re: Bits from ARM porters

[Ingo Jürgensmann]

Am 03.12.2013 um 13:40 schrieb Thorsten Glaser t...@debian.org:

 I’d love to have a bit more incentive to get people like Ingo, who
 has been doing m68k buildd work for, I believe, a decade, to become

Hmmm, since March 2001, if my archive serves me correctly. 

 at least a Debian member. On the other hand, while some of these
 people (porters) will need packaging skills and should attempt to
 become full uploading DD, some (buildd admins) will need more or
 less only trust and some limited technical skills (ofc they should
 be welcome to do more), so we shouldn’t put the barrier *too* high.

Hmm, hmmm, h... 
Trying to convince me to become a DD is as old as running Arrakis as second 
m68k buildd to Kullervo. Over 12 years now. Back then it would have been easy: 
just say Yes, I want to be a DD, here's my gpg key!
Because I didn't want to do any packaging at all, it became impossible at some 
point until DMs and such were introduced. Somewhen I decided to apply, but 
wasn't applied an AM for about a whole year, which led me to revoke my 
application with great disappointment.

 I’d really like to get everyone who’s got root on the m68k buildds,
 or physical access to it¹, to be a member of the project, though…

Well, this would be the only reason for me that would justify a new 
application: establishing some degree of trust, well, more official trust 
relationship than now. But beyond that... well, I don't know if it makes sense 
to become a DD in a big effort. 
Actually, I'm not against it, but I have no problem with not being one. If 
others think it would make sense, then it's perfectly fine for me to re-apply 
if I won't face the same trouble again. 

When being a DD I could imagine to work on merging Buildd.Net into Debian 
infrastructure and improve it, if that would be appreciated... 

That being said: becoming a DD would be ok for me, but would it be ok with the 
project as well? The scope of my work would be rather limited, I think... 

-- 
Ciao...//  Fon: 0381-2744150
  Ingo   \X/   http://blog.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: wanna-build / how to sort packages on buildds?

[Ingo Jürgensmann]

On Sun, 1 May 2011 01:36:38 +0200, Andreas Barth wrote:


Sometimes we have a few packages we don't want to build on a certain
buildds. Sometimes this is because this package needs lots of ram. Or
it takes quite long and would waste the parallel building a machine
supports. Or whatever else. Of course a package could be in more than
one category.


Yes, you're facing basically the same problem I tried to address in 
2000/2001 when doing my renderserver and later for what Multibuild was 
intended to do as well. ;-)



Now, what I would like to do is to write that down in a central file
with categories.


I would recommend to use a database, really.


That is, to mark packages as builds only with more than one gigabyte
of ram. And to mark buildds as has 6 cores, only ... ram - so
that I don't need to copy entries from buildd to buildd, but just say
that new machine is the same class as ..., and that's it.


Another category would be fast disk/raid. There are some packages 
with lots of disk accesses. When you can schedule those packages to a 
buildd that has faster disk access like in having multiple spindles for 
faster seeks, you can minimize build times as well. We faced that 
problem on m68k particularly on IDE vs SCSI disks on Amigas, as IDE was 
dog slow. Another example there was the faster disks on Amigas vs slower 
SCSI disks in Apple machines.


Now my question is just: How to do that efficient? I.e. how would 
such

a configuration file look like, and how the code to distribute the
package on the most fitting buildd(s)? (I.e. it's better to waste 5
out of 6 cores than to not build a package at all, but a package
needing at least 1g ram can't build on a buildd with only 512mb - but
no package should starve in the end.)
Ideas? Suggestions? Code?


Look at my update-buildd.net from Buildd.net, which I used to collect 
data from the buildds such as RAM, kernel, uptime, used swap and such 
(http://buildd.net/cgi/hostpackages.cgi?unstable_arch=m68ksearchtype=arrakis). 
I store this information into the database and also the build times of 
the packages. With this dataset it should be possible to have the 
wanna-buildd schedule packages in such a way to minimize the build times 
because you can decide which buildd is the most suitable buildd for the 
next package.


--
Ciao...//  Fon: 0381-2744150
  Ingo   \X/   http://blog.windfluechter.net

gpg pubkey: http://www.juergensmann.de/ij_public_key.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/f423f24d7f17a3abe30510a870357...@muaddib.hro.localnet

Buildd.Net - to be shutdown soon

[Ingo Jürgensmann]

Crossposting from my blog[0]: 

For over 6 years now I've been running Buildd.Net[1] as a service for 
additional information about Debian autobuilder network[2]. The reason for 
running Buildd.Net was simple: until then there was a web interface running on 
kullervo.debian.org, but generating the webpage took more and more time on that 
m68k box as Debian was growing in number of packages. That webpage was always a 
nice plus for m68k over other architectures and it was often asked for having 
such a page for those other archs as well. With taking over the webpage from 
kullervo the other archs were added as well and Buildd.Net was born. 

Buildd.Net was open for other archs and flavours, as I called the different 
dists like unstable, non-free or even volatile or skolelinux. Buildd.Net was 
always buildd centric, contrary to buildd.debian.org, which is more package 
centric. Yes: was - as I'm shutting down Buildd.Net soon. 

The reason for this is a change of interest after m68k has been removed from 
Debian because of the Vancouver proposal. Vancouver caused the death of m68k. 
Well, anyway. Without being an official Debian arch, the development on m68k 
came to an end. There was no progress anymore and on the other hand there were 
changes in the backend of the Debian autobuilder network, which made changes on 
Buildd.Net necessary. Requests for help in maintaining to adopt the changes 
were fruitless. The changes that Buildd.Net is needing are beyond my capability 
of programming.

And as a consequence I'm going to shutdown Buildd.Net in the near future. Not 
entirely, but significantly. It will return to its origins: being a m68k (and 
m32r) autobuilder informational page instead of trying to follow up the whole 
Debian autobuilder network. Just for the chance that m68k will be revived again 
somewhen. 
Andreas Barth told me that most of the functions of Buildd.Net is available on 
buildd.debian.org as well, although not yet visible. I offered cooperation and 
help when he wants to implement Buildd.Net functionality into 
buildd.debian.org. I still believe that Buildd.Net is offering a worthwhile 
alternative view of the autobuilder network. But, as I already said, I can't 
maintain Buildd.Net code source any longer on my own. So I better shut the 
service down instead of delivering a broken service any longer, if there's 
noone interested in helping. 

Anyway, I hope that you all enjoyed the service in the past!

[0] 
http://blog.windfluechter.net/archives/932-Buildd.Net-to-be-shutdown-soon.html
[1] http://www.buildd.net
[2] http://buildd.debian.org

-- 
Ciao...//  Fon: 0381-2744150
 Ingo   \X/   http://blog.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/d3f5aa38-0ca9-43e4-a47d-8ddf54cfc...@2010.bluespice.org

RfD: Version conflicts when updating Drupal in Debian

[Ingo Jürgensmann]

Hi!

Drupal, both version 5 and version 6, is a popular CMS and is in the Debian
archive. Upstream regularly releases security updates, which is a good
thing. 
Unfortunately Debians packaging is lagging behind. No, I don't want to blame
the maintainer, who is doing a good job anyway. The problem is a different
versioning between Drupal upstream and Debian packaging. 

For example the drupal6 package is version 6.6-1.1 while the problem which
lead to 6.6-1.1 was fixed in upstream version 6.7. 
This in itself is not a real issue as it is the way how Debian works or is
handling security issues. 
The problem comes with Drupals own checks. Since drupal6 the 3rd party update
module from drupal5 was included into drupal6 core. With this addition to
Drupal Core Modules the user/admin is now informed about (security) updates
of installed modules, which is a good thing for security as well. 

But now there's a warning everytime an admin of a Drupal site about pending
security issues logs in: 

|There is a security update available for your version of Drupal. To ensure
|the security of your server, you should update immediately! See the
|available updates page for more information.

On the update page: 

|Drupal 6.6  Security update required!
|Recommended version:   6.8 (2008-Dez-11)   
|
|* Download
|* Release notes
|
|Security update:   6.7 (2008-Dez-10)   
|
|* Download
|* Release notes
|
|Includes: Block, Blog, Color, Comment, Content translation, Database
|logging, Filter, Forum, Help, Locale, Menu, Node, OpenID, PHP filter, Path,
|Ping, Profile, Search, Statistics, System, Taxonomy, Tracker, Trigger,
|Update status, Upload, User

This is not only annoying but also irritating because of different
versioning between what Drupal says itself and what is installed by Debian.
(Well, yes, Debian seems to lag behind one version atm ;)

So, how can this be solved so that our users are not irritated everytime
they visit their own Drupal sites?

-- 
Ciao...//  Fon: 0381-2744150 
  Ingo   \X/   http://blog.windfluechter.net

gpg pubkey: http://www.juergensmann.de/ij_public_key.asc


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org