From nobody Sat Jan 20 12:10:13 2024 X-Original-To: dev-commits-ports-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4THFgl54sbz56ywC; Sat, 20 Jan 2024 12:10:59 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4THFgl30LXz4bFX; Sat, 20 Jan 2024 12:10:59 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-f54.google.com with SMTP id 46e09a7af769-6de424cef01so826314a34.2; Sat, 20 Jan 2024 04:10:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705752658; x=1706357458; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6B8awKeyXuWQEg+fRm98AZ5OH6EJcQdfbiquVsiUC98=; b=duiLBjAZOGAotjgIdRG91cWHsLw5K29TlrudQly4m0SQorw3krdtFsnF9xSSrdQXh6 w5f/aeZcIQroIv9vvyjakRSjTIMlkrKO/RT4l2XtYrL1UqBsIqXNyVdjEdEKCYU9/pYF T4j2Y2tW8bH0vjFFT7nIanT+RSBvR9P2VCgTPimNHsZ5Qsql+h3QetjnhsjsLz9EvgOA PeDayV+2FrmbgWN6fRUUmgt2Up5udmooQpeBFrQpP4iw3+HeumiCYAJ9cqlVdJwR3sqB I05sIKhBPqssEDo1Uh2SfOAlwUQ4rZlFr9cCNLFb7KJlY9GE3LNswdmaqo8AyI63mDU7 7bWg== X-Gm-Message-State: AOJu0YxeZtYYraeA5JJYX4FJQm9Fga6+ft0at7o4+taSpHqmKpMgPe9T LDVjWUW9kX25s+VmcXvowr9/ttFuWRVY7h8yhbjISrZsNmyYLGlOuvsEjqLP X-Google-Smtp-Source: AGHT+IECm0YEP7qxF/3NJEZoeNchE2thd6/PQDvrmBTietRPFxaXYkbVZcOCUXI7w1cO0112x0tC9A== X-Received: by 2002:a05:6830:18dc:b0:6d8:74f5:dc38 with SMTP id v28-20020a05683018dc00b006d874f5dc38mr1182763ote.9.1705752657956; Sat, 20 Jan 2024 04:10:57 -0800 (PST) Received: from mail-oa1-f43.google.com (mail-oa1-f43.google.com. [209.85.160.43]) by smtp.gmail.com with ESMTPSA id w8-20020a4aaf08000000b00594d8d19d5csm3301834oon.38.2024.01.20.04.10.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 20 Jan 2024 04:10:57 -0800 (PST) Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-2108e106947so1005099fac.3; Sat, 20 Jan 2024 04:10:57 -0800 (PST) X-Received: by 2002:a05:6358:ee44:b0:175:8c20:cad with SMTP id ik4-20020a056358ee4400b001758c200cadmr737590rwb.0.1705752657389; Sat, 20 Jan 2024 04:10:57 -0800 (PST) List-Id: Commit messages for all branches of the ports repository List-Archive: https://lists.freebsd.org/archives/dev-commits-ports-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-ports-all@freebsd.org X-BeenThere: dev-commits-ports-all@freebsd.org MIME-Version: 1.0 References: <202401200042.40K0gNmu053279@gitrepo.freebsd.org> <240f4c88-582d-4da4-ba92-50d11ddfade3@freebsd.org> <6e13868f-8910-4468-9e1d-2a231a0723ca@freebsd.org> In-Reply-To: <6e13868f-8910-4468-9e1d-2a231a0723ca@freebsd.org> From: Gleb Popov Date: Sat, 20 Jan 2024 15:10:13 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: git: 589aaaeb09b7 - main - multimedia/libvpx: update 1.14.0 To: Vladimir Druzenko Cc: ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4THFgl30LXz4bFX X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] On Sat, Jan 20, 2024 at 2:40=E2=80=AFPM Vladimir Druzenko = wrote: > > 20.01.2024 14:10, Mathieu Arnold =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Sat, Jan 20, 2024 at 12:07:03PM +0300, Vladimir Druzenko wrote: > >> Can we make some kind of schedule for mass bumps of huge ports? > >> Users who build from ports can schedule upgrade and prevent build some= thing > >> very big "2 days in a row". > >> Even if you use binary packages, updating for example virtualbox will = entail > >> a restart (savestate/start) of all virtual machines, and this must be > >> planned in advance. > >> If this already exists, please point to it. > >> Thanks! > > Hi, > > > > I am not sure what you are complaining about. > > On the one side, it seems that you want to build things yourself and to > > have everything up-to-date and you upgrade every day. > > On the other side it seems that you would like to have things not > > updated so you don't have to rebuild things every day. > > > > If you absolutely want to upgrade every day by yourself, then, well, yo= u > > have to expect to rebuild things, large and small two days in a row onc= e > > in a while... > > > > Use binary packages, there, I fixed the rebuild every day problem you > > have. > > > > Then you say that if virtualbox gets an update, you need to restart > > your virtual machines, and that it is a problem. > > Well, it is only a problem if you have the absolute need to upgrade as > > soon as possible. > > And in that case, it is your problem. > > Most of the time, the virtualbox updates are not critical security > > issues and they can be planned on your side for when it is convenient > > for you. > > > > In any way, nobody forces you to upgrade as soon as there is an update > > of a port, but in the same way, nothing is going to force the rest of u= s > > to not commit to ports because it is inconvenient for you... > > Complaining? Why do you think so? > I just ask about possibility to planning. If no - maybe create one? Maybe= somebody have ideas how to do this better and etc? I doubt it'd possible to implement. How a committer would be supposed to know when he's clear to push "big" update and when he should wait a bit? Now multiply this by the number of "big" ports and you'll see that everyone start to fight for a "push quant" like hundreds of threads fight for CPU cores. > It isn't "complaining". > Maybe my poor English is the issue=E2=80=A6 > > About virtualbox: I planned update several days ago for yesterday, but to= day I got bump. Same for firefox - just updated and now I must do it again = or get "problems" with prepare update for my ports (freerdp* depends on ffm= peg). If I had known about today's mass bump, I would have planned update f= or today instead of yesterday. And keep a lot of time=E2=80=A6 > I don't need update as soon as possible, but I need to know how long (app= roximately) I must wait before next mass bump for planning update. I don't quite get it what's the problem, assuming you're using pouriere. Recompiling some stuff will just update packages in a repository, you don't need to do `pkg upgrade` after that.